VXLAN has been around for a while, so how do router vendors support it? Well, let’s use a dead simple topology to test them out.
Our setup today:
- All routers connected to the same dumb switch using IP range 169.254.0.0/24
- Multicast signaling on address 239.0.0.1, No PIM
- VXLAN UDP port 4789
- Network 10.0.0.0/24 on VNI 5000 (layer 3 termination / inter-VXLAN routing)
Generic Linux
Tested version: Debian 10, Linux kernel 4.19.0
Linux runs just fine with the most simple setup across all operating systems we tested. VXLAN VTEP is implemented as a layer 2 tunnel device which means you can either put it into a bridge or just assign IPs to it.
1 2 3 4 5 |
ip link set ens3 up ip addr add 169.254.0.1/24 dev ens3 ip -6 link add vxlan1 type vxlan id 5000 dstport 4789 local 169.254.0.1 group 239.0.0.1 dev ens3 ttl 1 ip link set vxlan1 up ip addr add 10.0.0.1/24 dev vxlan1 |
Notes:
- Support IPv6 underlay (yes!)
- UDP port is 8472 by default
- TTL is 1 by default
References:
VyOS
Tested version: 1.2.5, Linux kernel 4.19.106
VyOS is basically Linux with a better config interface, so there isn’t much difference.
1 2 3 4 5 6 |
set interfaces ethernet eth0 address 169.254.0.5/24 set interfaces vxlan vxlan1 address 10.0.0.5/24 set interfaces vxlan vxlan1 group 239.0.0.1 set interfaces vxlan vxlan1 link eth0 set interfaces vxlan vxlan1 remote-port 4789 set interfaces vxlan vxlan1 vni 5000 |
Notes:
- UDP port is 8472 by default
- If you forget to set the remote-port on interface creation, you have to delete the interface, commit, create the interface again
References:
Cisco IOS XE
Tested version: 16.12.3
IOS XE’s command line user experience and internal design is a mess, and the documentation is bad in many aspects. IOS XE does not support running layer 3 over a VXLAN VTEP (yes, it self identifies as a router) so here’s a config for bridging the VTEP with an ethernet port.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
ip multicast-routing distributed interface GigabitEthernet1 no shutdown ip address 169.254.0.2 255.255.255.0 interface GigabitEthernet2 no shutdown service instance 1 ethernet interface nve1 no shutdown source-interface GigabitEthernet1 vxlan udp port 4789 member vni 5000 mcast-group 239.0.0.1 bridge-domain 1 member vni 5000 member GigabitEthernet2 service-instance 1 |
To bridge the VTEP with a tagged VLAN on an ethernet port, you can’t just create a VLAN subinterface and bridge it. Instead, you need a service instance like this:
1 2 3 4 5 |
interface GigabitEthernet2 service-instance interface 100 ethernet bridge-domain 100 encapsulation dot1q 100 rewrite ingress tag pop 1 symmetric |
Notes:
- All Cisco documentation write VXLAN as “VxLAN” which is not correct and triggers my OCD
- You can only use VNI 4096-16777215 (obviously a result of bad software engineering)
- IPv6 multicast group for underlay network is not supported
- You can’t configure IP/IPv6 address on NVE interface
- No inter-VXLAN routing, and adding BVI/BDI/Loopback to the bridge domain won’t work
- One device supports 8000 bridge domains at most
- IOS XE for catalyst switches does not support multicast VXLAN but support inter-VXLAN routing
Also I noticed that there will be a Tunnel interface automatically configured for every NVE interface, the tunnel interface will copy the IP address from NVE’s source interface.
References:
Cisco ASA
Tested version: 9.10.1
In my past experience, ASAs are little devices with some odd personalities that I had a hard time getting used to. However configuring VXLAN on the ASA turned out to be very simple.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
vxlan port 4789 interface GigabitEthernet0/0 no shutdown nameif outside security-level 0 ip address 169.254.0.3 255.255.255.0 interface vni5000 no shutdown segment-id 5000 nameif inside security-level 100 ip address 10.0.0.3 255.255.255.0 vtep-nve 1 nve 1 encapsulation vxlan source-interface outside default-mcast-group 239.0.0.1 |
Notes:
- Smart license means $$$
- IPv6 multicast group for underlay network is not supported
- No PBR support (and a lot of other protocols/features, but routing on ASA has always been weird so I’d not bother mentioning them)
- Only 1 NVE instance per context for now
- You can have only 10000 VNI interfaces per context
- To make a physical interface only able to accept VXLAN traffic, you can use the nve-only command
References:
Junos OS for Juniper EX/QFX/MX
Juniper like to overdesign everything. Their design is sometimes very useful, but make network designing complicated.
Configuration for vQFX:
1 2 3 4 5 6 7 8 |
set interfaces xe-0/0/0 unit 0 family inet address 169.254.0.7/24 set interfaces irb unit 5000 family inet address 10.0.0.7/24 set interfaces lo0 unit 0 family inet address 169.254.0.7/24 set switch-options vtep-source-interface lo0.0 set vlans VXLAN1 vlan-id 100 set vlans VXLAN1 l3-interface irb.5000 set vlans VXLAN1 vxlan vni 5000 set vlans VXLAN1 vxlan multicast-group 239.0.0.1 |
Notes:
- Junos OS must use an IP configured on the loopback interface as the VTEP source IP address
- Only one interface on a device can receive and parse VXLAN packets
- IPv6 multicast group for underlay network is not supported
- If you need to run inter-VXLAN routing, you need to configure irb-interface on the vlan interface, and you must configure a vlan-id for every irb-interface enabled vlan interface, which limits the available vlan interface count to 4092
- Why 4092? because don’t use vlan-id 1 and 2 on the VXLAN vlan interface, these are cursed numbers
- The ability to run inter-VXLAN routing differs from device to device
- SRX devices do not support VXLAN
- If you are using vQFX for lab purposes, please use version 15.1X53-D60.4; other versions (no matter higher or lower) have problems on VXLAN, RSVP, EoMPLS (l2circuit), etc.
References:
- VXLAN MULTICAST
- Examples: Manually Configuring VXLANs on QFX Series and EX4600 Switches
- VXLAN Constraints on QFX Series and EX Series Switches
MikroTik RouterOS
Tested version: 7.1 beta 1
RouterOS is the latest one to support VXLAN and the support is limited to their cutting-edge development version. But let’s try it out, shall we?
The config is as simple as Linux. (Well, I guess they are using the stock Linux implementation of VXLAN tunnel.) I’m using the new slash/seperated/config/grammar here.
1 2 3 |
/ip/address/add address=169.254.0.6/24 interface=ether1 /interface/vxlan/add name=vxlan1 interface=ether1 group=239.0.0.1 mtu=1450 port=4789 vni=5000 /ip/address/add interface=vxlan1 address=10.0.0.6/24 |
Notes:
- UDP port is 8472 by default
- You must set a MTU for VXLAN interface because the default value 1500 is not going to work (for an underlay network with MTU 1500, the VXLAN MTU is 1450)
Conclusion
Although BGP EVPN is the future, unicast/multicast EVPN is still handy for small-scale, autonomous deployments without a dedicated controller or something. Enterprise solutions tend to overlook the simple needs and require a lot just to make everything work. Also enterprise solutions tend to have very bad software quality. On the contrary, Linux implements VXLAN in a simple and elegant way, but its inability to atomically save and restore network config added some management overhead to the operation guys.