How to encapsulate all VLAN traffic inside VXLAN

Question

As I understand VXLAN, it looks like it should be able to encapsulate and properly route VLAN-tagged traffic.

However, in investigating how to actually configure VXLAN on network devices, it looks like vendors such as Cisco and Arista and Juniper do something like this:

• Set up the physical ethernet port as a VLAN access port on e.g. VLAN 100
• Configure a VLAN->VNI mapping which maps VLAN 100 to whatever VNI you want

For example, see the configuration at the end of https://eos.arista.com/vxlan-without-controller-for-network-virtualization-with-arista-physical-vteps/

However, I want to specify that all traffic, regardless of VLAN tag, which enters a physical port should be put on a specific VNI with no modification of VLAN tags at any point.

Am I misunderstanding the configuration in that example, or are there alternate ways to configure VXLAN? I'm particularly interested in Arista, so if anyone with Arista expertise can chime in, I would appreciate it.

Answer 1

I think you are confusing a couple of concepts. Looking at the last configuration section of the document you have linked:

7.2) VXLAN without CVX

Configuration on VTEPs:

!
vlan 100
vlan 200
!
interface Ethernet 1
  switchport access vlan 100
!
interface Ethernet 2
  switchport mode trunk
  switchport trunk allowed vlan 100,200
!
interface loopback 1
 ip address 1.1.1.1/32
!
interface Vxlan 1
  vxlan source-interface loopback 1
  vxlan vlan 100 vni 10100
  vxlan vlan 200 vni 10200
  vxlan vlan 100 flood vtep 2.2.2.2 4.4.4.4
  vxlan vlan 200 flood vtep 2.2.2.2 3.3.3.3 4.4.4.4
!

Notice that the VXLAN interface, Vxlan 1 has multiple VNIs, just like a trunk has multiple VLANs with tags. Basically, a VNI on a VXLAN is like a VLAN on a trunk. You shouldn't expect that an access interface allow any frames from tagged VLANs, nor should you expect a trunk interface to allow VLANs other than what it is configured to allow. Neither should a VNI have any traffic other than its corresponding VLAN, nor should a VXLAN interface allow traffic for VLANs for which it is not configured.

You really, really don't want frames with any VLAN tag coming into the access interface Ethernet 1. That could lead to security problems like VLAN hopping. One would hope that frames with VLAN tags coming into an access interface would be dropped as malformed.

Also, on interface Ethernet 2, the switchport trunk allowed vlan 100,200 instructs that all incoming frames except those tagged as VLAN 100 or VLAN 200 be dropped, and no frames except those in the two allowed VLANs be sent. Frames tagged with other VLAN numbers will be dropped.

The interface Vxlan 1 will send and receive traffic for VLANs 100 and 200, just like the trunk interface Ethernet 2.

Answer 2

The .1q tag is not sent across the L3 boundary, the mapping is done at encapsulation and at decapsulation. This allows for vlan translation or other use cases where you are not matching the vlan number at each vtep to the common VNI. Similar to what previous commenters have noted, for each vtep, the vlan to vni mapping is 1 to 1.

Per RFC 7348 6.1. Inner VLAN Tag Handling

Inner VLAN Tag Handling in VTEP and VXLAN gateway should conform to the following:

Decapsulated VXLAN frames with the inner VLAN tag SHOULD be discarded unless configured otherwise. On the encapsulation side, a VTEP SHOULD NOT include an inner VLAN tag on tunnel packets unless configured otherwise. When a VLAN-tagged packet is a candidate for VXLAN tunneling, the encapsulating VTEP SHOULD strip the VLAN tag unless configured otherwise.

In EVPN approaches there are methods to do vlan bundling services that behave similar to what you are asking for but there is another set of terminology to learn and implement on whatever platform you choose in regard to EVPN l2vpn services.

There may be a better way to do what you are looking for using a different encapsulation perhaps?