4

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.

  • 1
    That doesn't really make any sense. A VNI is equivalent to a VLAN. You wouldn't want all VLANs to be sent across one VLAN interface. That would leak VLANs and cause all sorts of problems. A VXLAN interface can have multiple VNIs, just like a trunk interface can have multiple VLANs. – Ron Maupin Feb 17 '17 at 0:29
  • 1
    In the Cisco world (which also supports EVPN, native L3 over VXLAN and a bunch of other really useful features) there's the notion of Q-in-VNI which can take a native dot1q trunk and carry all of the available VLAN's within it. – rnxrx Feb 17 '17 at 2:57
  • I think Q-in-VNI might be what I want, I'll look into it. – John Mar 6 '17 at 21:12
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 16 '17 at 22:07
5

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.

0

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.