Juniper MX204

Juniper MX: Simple static VXLAN configuration

Posted by

On most VXLAN deployments, you’ll want to be using EVPN to distribute MAC addresses between devices. However, if you’re doing something small such as wanting to span an L2 link across an L3 network (e.g. The Internet) then a simple static configuration is quick to do. In my case, I wanted to create an L2 circuit from a firewall, across The Internet, to a Linux based router.

Juniper MX manual VXLAN implementation uses flood-and-learn to discover MAC addresses. If a MAC address is not found in its table (show ethernet-switching table) then it will flood the packet to all statically configured VTEPs. Once it gets a packet from a particular MAC address, it will store that MAC address against the VTEP in its table and only send subsequent packets to that address. Broadcast and Multicast traffic is flooded to all VTEPs.

You’ll need to bridge a standard VLAN with a VXLAN VNI. Take the following network:

VXLAN Network

Servers are connected to a switch on VLAN 185. The switch is trunked to the MX on interface ae0. The MX’s loopback (lo0.0) IP is and you want to create a VXLAN VNI (185) to a Linux router at

First, configure your source interface as your loopback and configure your list of static VTEPs:

switch-options {
    vtep-source-interface lo0.0;
    remote-vtep-list [ ];

Next configure VLAN 185 on ae0 as a vlan-bridge interface:

interfaces {
    ae0 {
        encapsulation flexible-ethernet-services;
        unit 185 {
            description "My VXLAN";
            encapsulation vlan-bridge;
            vlan-id 185;

Now configure a bridge domain which bridges VLAN 185 on ae0 (ae0.185) with VXLAN VNI 185:

bridge-domains {
    my-vxlan {
        vlan-id 185;
        interface ae0.185;
        vxlan {
            vni 185;

And that’s it. You should now have a L2 tunnel between Servers and Linux Router.


  1. Do you know is this possible on a vMX I’m trying this and getting
    flexible-ethernet encapsulation not allowed on untagged interfaces

  2. I don’t quite understand the L3 connection between the MX and the Linux Router. They need to be reachable over L3/IP but I see that the loopback is used as the vtep source interface. Can anyone explain this to me?

    1. This is a confusing concept, I will admit. It’s best practice to assign an IP address (an RFC1918 IP or a Public IP) to your loopback interface and use this as the source address for your BGP sessions, VXLAN, etc. rather than use a specific interface IP. That is because the destination address may be reachable via a number of different interfaces either as ECMP or with primary/backup routes in the route table. You would ordinarily advertise the loopback IP onto your L3 backbone (or The Internet) with OSPF and/or BGP such that the rest of the network knows that your loopback IP is reachable via which interfaces.

      That said, if your network is super-simple and you only have 1 possible route into and out of your router than you can use a real interface as the source.

      1. Appreciate the response. On a QFX5120, only a loopback device can be used as the `vtep-source-interface`:

        austin@data-sw-02# set routing-instances vx1 vtep-source-interface xe-0/0/48.0
        error: interface-name: ‘xe-0/0/48.0’: Prefix must be lo

        austin@data-sw-02# set switch-options vtep-source-interface xe-0/0/48.0
        error: interface-name: ‘xe-0/0/48.0’: Prefix must be lo

        On a point to point connection between VTEPs (no routing protocols), I have a hard time understanding how to configure it with this limitation. Since the loopback interface will not be in the same network as the actual vtep interface, would I need to set up static routes in both Linux land and on the JunOS somehow? I understand the linux side, wondering if you had any advice for the JunOS side.

        1. Ok, makes sense. Let’s say your QFX to Linux link subnet is with .1 being the QFX and .2 being the Linux server. I’d assign an arbitrary private IP outside of any of your other subnets to the lo0.0 (e.g The QFX will already know how to reach (as it’s directly connected). All you’d then need to do is fix the return path by setting a static route on Linux to via

Leave a Reply

Your email address will not be published. Required fields are marked *