Introduction to Virtual Extensible LAN (VXLAN)

Lessons Discussion
43

Hello Suprit

Ha! Yes, that was a typo, I’ve fixed it, thanks…

The detailed process is described in section 6 Control Plane of the lesson.

Specifically, it states that the MAC addresses are learned via the VTEP devices using various control plane solutions. Four options are described in the lesson, but one of them is actually configured and detailed. The method is called VXLAN with multicast underlay. This is actually the method used by the VXLAN standard. This is also known as a multicast flood and learn solution.

Here’s how it works:

  • Each VNI maps to a multicast group.
  • The VTEP devices join the multicast group.
  • When VTEP1 receives the ARP request, it transmits it to the multicast group.
  • VTEP2 receives the ARP request and learns the MAC address of H1.
  • VTEP2 stores the MAC address of H1 and the IP address of VTEP1 in the mapping table.
  • When VTEP2 receives the ARP reply from H2, it uses the information in the mapping table to send a unicast packet to VTEP1.

Remember the VTEP devices, even though they are Layer 3 devices, they transport a Layer 2 network (the overlay) over a Layer 3 network (the underlay). From the point of view of the hosts, this is still a Layer 2 network, so as far as they are concerned, the ARP request is being sent normally. So the ARP request isn’t blocked at the VTEP, but is tunneled through to the host at the other site.
So the ARP request is transmitted to the multicast group using multicast mechanisms on the underlay network. Does that make sense?

I hope this has been helpful!

Laz

44

Hello Laz,
Thanks for explanation.
I still have some doubt related to related to how does VTEP1 know that the ARP request it has received should be forwarded/transmitted to the multicast group? Because we have done mapping?
Also, I need to preform this lab which might solve my doubt.
Thanks,
Suprit

45

Hello Suprit

If you take a look at this lesson, you will see how the VTEPs are configured:

You will notice that on the interface facing the hosts, there is the following configuration:

VTEP1(config)#interface GigabitEthernet 2
VTEP1(config-if)#service instance 1 ethernet
VTEP1(config-if-srv)#encapsulation untagged
VTEP1(config-if-srv)#exit
VTEP1(config-if)#exit

We also have additional configuration parameters that are used to combine the physical interface with the service instance, allowing for the tunneling of ARP requests (and other communication between remote sites).

VTEP1(config)#bridge-domain 1
VTEP1(config-bdomain)#member vni 5012
VTEP1(config-bdomain)#member GigabitEthernet 2 service-instance 1

It is this configuration that causes the VTEP to receive any ARP request, encapsulate it and send it to the remote site. As you correctly stated, I believe that if you lab this up, many of your doubts will be resolved. If you do this, let us know how you get along, and let us know if we can help further.

I hope this has been helpful!

Laz

46

Hi,
why vxlan requires MP-BGP
Thanks

47

Hello Sims

With VXLAN each VTEP has a VXLAN mapping table, or a forwarding table that maps destination MAC addresses to a remote VTP IP address. This mapping however and the learning of MAC addresses requires a particular mechanism to be achieved. There are several ways in which this can be done in a VXLAN environment. One of these ways is to use MP-BGP EVPN. The other ways to do it include:

  • VXLAN with static unicast VXLAN tunnels
  • VXLAN with multicast underlay
  • VXLAN with LISP

So you don’t require MP-BGP if you choose a different methodology.

Actually, MP-BGP is a popular choice, especially for datacenters and private clouds where VXLAN is deployed. MP-BGP is specially designed to carry additional information for use with various protocols. That’s why it is called Multiprotocol (MP) BGP. It supports multiple address families and is capable of exchanging control information for various Layer 2 and Layer 3 protocols.

In a VXLAN deployment, MP-BGP can be used as a control plane protocol to distribute and manage the VXLAN mapping tables, across the participating devices.

Therefore MP-BGP can be used to create and distribute VXLAN mapping tables.

I hope this has been helpful!

Laz

48

Hi Laz,

Is the below correct in terms of a walkthrough of the ARP request and reply process via VXLAN using the same example in the lesson? It’s mentioned at the end of the lesson but just want to ensure the details are correct.

  • Step 1 - H1 sends ARP Request

    • H1 sends an ARP broadcast packet: SA MAC: H1 MAC | DST MAC: FFFF.FFFF.FFFF
    • When VTEP1 receives the ARP request, it encapsulates it into a UDP packet: SA IP: 1.1.1.1 | DA IP: 229.1.1.1
    • The packet is delivered to any hosts that joined multicast group 239.1.1.1
    • VTEP2 receives the encapsulated ARP request and makes an entry in the VXLAN forwarding table that shows the mapping of H1’s MAC address and VTEP1’s IP address
      VTEP IP MAC VNI
      1.1.1.1 H1 MAC 5012
    • VTEP2 also checks the VNI (5012) in the VXLAN header to decide if it has to be delivered on the interface or not
    • The packet is decapsulated and the ARP request is delivered to the host connected to the logical network VNI 5012 (H2)

  • Step 2 - H2 sends ARP reply

    • H2 replies to the ARP request with an ARP reply (unicast) SA MAC: H2 MAC, DA MAC: H1 MAC
    • VTEP2 receives the ARP unicast reply and performs a lookup in the VXLAN forwarding table and finds a match for the DST MAC address H1 MAC
      VTEP IP MAC VNI
      1.1.1.1 H1 MAC 5012
    • VTEP2 now knows that in order to deliver the packet to H1 MAC, it has to send it to VTEP with IP address 1.1.1.1
    • VTEP2 encapsulates it into a unicast packet: SA IP: 2.2.2.2 | DA IP: 1.1.1.1

  • Step 3 - H1 receives ARP reply

    • VTEP1 receives the encapsulated packet and makes an entry in the VXLAN forwarding table that shows the mapping of H2’s MAC address and VTEP2’s IP address
      VTEP IP MAC VNI
      2.2.2.2 H2 MAC 5012
    • VTEP1 also checks the VNI (5012) in the VXLAN header to decide if it has to be delivered on the interface or not
    • The packet is decapsulated and delivered to H1
49

Hello Bhawandeep

Yes, it looks good, you’ve added some more info into your description, which can be helpful to other readers as well.

Laz

1 Like
50

If I used the vlan id, with different vni, what would be the type of configuration for this scenario?

51

Hello Ediekes

Using the same VLAN ID with different VNIs is a common practice in large deployments where you want to provide L2 connectivity across different VXLAN segments.

To demonstrate how this is done, I’ll provide a basic example using Cisco Nexus switches, which are commonly used in data centers and support VXLAN configurations. However, keep in mind that the exact commands might vary depending on the platform and software version. This is a simplified configuration, and a production environment might have additional requirements.

  1. Configuring the NVE interface (this is the VXLAN tunnel interface):
interface nve1
  no shutdown
  source-interface loopback0
  member vni 123
    mcast-group 239.1.1.1
  member vni 321
    mcast-group 239.1.1.2
  1. Mapping VLAN to VNI:

For VNI 123:

vlan 456
  vn-segment 123

For VNI 321 (on another segment or even on the same switch if it’s serving multiple VXLAN segments):

vlan 456
  vn-segment 321
  1. Configure the physical interfaces as needed:
    For example, if you’re trunking this VLAN:
interface Ethernet1/1
  switchport mode trunk
  switchport trunk allowed vlan 456

Note that:

  • The multicast groups (mcast-group) configured in the example above represent the multicast group IP addresses used for multicast traffic handling in VXLAN. The IPs are just placeholders and should be replaced by actual multicast IPs suitable for the network.
  • You must also ensure proper IP routing between VTEP devices.
  • The actual configuration might vary depending on specific requirements, other features in use, and the exact hardware/software version.

For some more info on how to configure VXLAN, take a look at the folloing lesson:

I hope this has been helpful!

Laz

52

hello everything is fine?
I applied the aforementioned settings, but when I go to the vlan part to add another vni, I get the following error:

VLAN(1000) to VNI(5000) mapping already exists. Please remove the mapping by doing 'no vn-segment'
Warning: Enable double-wide arp-ether tcam carving if igmp snooping is enabled. Ignore if tcam carving is already configured.
53

Hello Ediekes

Thanks for getting back to us with your results! It seems I was a bit hasty in my response, let me clarify.

It turns out that even if you are using different VXLAN segments on the same switch or VTEP, you still cannot map a single VLAN to multiple VNIs on the same VTEP. The mapping of a single VLAN to multiple VNIs can only be achieved on different VTEPs.

Getting into some more detail, if you are using different VXLAN segments on the same VTEP, then each VXLAN segment will have its own unique VNI. Each VNI represents a distinct Layer 2 domain in the VXLAN overlay.

Here’s the key point to understand:

On the same VTEP, you can certainly have multiple VNIs (representing multiple VXLAN segments or overlay L2 domains). Each of these VNIs can be associated with a different VLAN on the switch, maintaining the one-to-one mapping between VLAN and VNI. This allows the switch to differentiate traffic from different VLANs and encapsulate it with the correct VNI when sending it across the VXLAN tunnel.

However, you still cannot map a single VLAN to multiple VNIs on the same VTEP. If you did, the switch wouldn’t know which VNI to use when it needs to encapsulate traffic for that VLAN.

To visualize:

VLAN 10 → VNI 5000 (VXLAN Segment A)
VLAN 20 → VNI 6000 (VXLAN Segment B)
VLAN 30 → VNI 7000 (VXLAN Segment C)

On this switch (VTEP), traffic from VLAN 10 will be encapsulated with VNI 5000, VLAN 20 with VNI 6000, and so on. This maintains clear segmentation and encapsulation rules for the VXLAN overlay.

If your network design requires spreading or dividing a single VLAN across multiple VXLAN segments, you would need to consider splitting that VLAN into different subnets or smaller VLANs and then associating each with a unique VNI.

So the 4k VLANs in a single switch is still a limitation locally, but across the fabric, it is the VNI that is the important piece of information, and that can have 16 million + values…

I hope this has been helpful!

Laz

54

There is no updated notes about VXLAN configuration etc… what’s the point in continuing the subscription when there is no updated information

55

Hello @ethernet65535 ,

I’ll probably add more EVPN VXLAN material soon but creating material takes time and it’s not the only topic that needs to be covered.

If you need it right now, I’m afraid I can’t help.

Rene

1 Like
56

hi,

in what way does the vxlan help in increasing number of vlans when we still need to create a normal vlan and bind it to vni?

57

Hello Hilmi

Take a look at this NeworkLessons note on the topic of the mapping of VLANs to VNIs. If you have any further questions, let us know!

I hope this has been helpful!

Laz

58

Hello Laz,

If I have two DC, DC1 and DC2 that have following network.
DC1: 10.10.1.0/24, vlan10, firewall hosts gateway (layer3 vlan)
DC2: 10.20.1.0/24, vlan10, firewall hosts gateway (layer3 vlan)

Q1: What will be a best way to map vlan to vni? Should I use different vni or same vni when there is different network with same vlan# in different data center?

Q2: Can VM mobility be possible between two data center after implementing vxlan?

  • List item
    VM at DC1 with ip address 10.10.1.100 (vlan10)
    Gateway is 10.10.1.1 in DC1 FW
    System admin wants to temporary move VM to DC2
    DC2 also has vlan10 with different network, 10.20.1.0/24
    Each data center has switchport configured for VM with trunk allowed vlan 10

Will specific vlan and vni mapping be needed?

Thanks.

59

Hello Hyung

Typically, each VNI creates a broadcast domain within which you would create an IP subnet.
In this sense, the VNI plays the same role as a VLAN in the VXLAN world. The best way to map VLAN to VNI would be to use unique VNIs for each Layer 3 subnet you use. The VLAN numbers can be thought of as only “locally significant” in this case.

Now in your example here, you have two different subnets, so you would map a different VNI to each one, even though you’re (locally) using the same VLAN at each switch. For instance, you would map VLAN 10 in DC1 to VNI 5010 and VLAN 10 in DC2 to VNI 5020.

Yes, VM mobility is possible between two data centers after implementing VXLAN, but you will need to ensure that the Layer 2 domain has been configured (using VXLAN) to extend between the two data centers. If you want your VM to maintain the same IP address, you must ensure that the VNI that has been configured for the network to which the VM belongs (i.e 10.10.1.0/24) extends to DC2. This can be achieved through VXLAN which encapsulates Layer 2 frames in UDP datagrams allowing for the extension of Layer 2 domains over Layer 3 networks.

I hope this has been helpful!

Laz

60

Hi ReneMolenaar!
You have an error in the text, static ingress replication is a Data plane level, not a control plane, please fix it:
Other control plane options are static VXLAN tunnels, MP-BGP with EVPN, or VXLAN with LISP.

1 Like
62

You are right @nibble85 . I just fixed this. Thanks!

Rene

63

Hello Alex

Indeed static ingress replication is a data plane mechanism, as are static VXLAN tunnels. MP-BGP with EVPN and VXLAN with LISP are control plane operations. I will let Rene know to consider making the appropriate changes.

Thanks for pointing that out!

I hope this has been helpful!

Laz