Great lesson @ReneMolenaar.
Given that VXLAN is riding on IP, are there any potential loops or storms within the bridge domain?
Hello Ahmed
Great question! Since VXLAN encapsulates Layer 2 frames into UDP datagrams, it effectively turns Layer 2 domains into Layer 3 traffic. This essentially means that the underlying physical network only sees IP traffic and is not aware of the MAC addresses from the VXLAN.
As a result, the more traditional Layer 2 issues like loops or broadcast storms are not a concern within the VXLAN fabric itself. This is because the underlay network is not aware of the Layer 2 topology and VXLAN does not use STP for loop prevention. Indeed, the underlay network uses layer 3 routing instead of layer 2 (i.e. STP).
However, there are other potential sources of loops or storms that are specific to VXLAN. For example, Broadcast Unknown unicast, and Multicast (BUM) traffic is flooded across the VXLAN fabric to all VTEPs participating in the same VXLAN segment (VNIs). If the VXLAN fabric is not deployed correctly, this traffic may cause problems. Split horizon filtering and Designated Forwarder (DFs) are used to help prevent some of these issues.
Similarly, other VXLAN control plane issues as well as multicast issues in the underlay, and the underlay routing itself can all be sources of potential loops. However, these are not due to Layer 2 issues, but they are inherent to VXLAN and the mechanisms that make it work.
Strictly speaking, the traditional potential problems with loops and broadcast storms you see in Layer 2 are not a concern on the VXLAN fabric due to the encapsulation of the Layer 2 frames within a Layer 3 underlay.
I hope this has been helpful!
Laz
Im no expert on VXLAN and am just starting to learn it, but there were a couple confusing points in Packet Walkthrough is Step 5:
-
The destination host (192.168.2.102) is presumably on the same subnet but the 3rd octet may confuse people to think its on a different subnet. I would include the subnet mask in the illustration or just change the 3rd octet on the destination host to be a â1â
-
The entire VXLAN Packet/Frame still has and outer Ethernet header so it can traverse the underlay correctly, I would also include that in the illustration.
Otherwise, great article, it was veru easy to read and understand.
Hello Chris
Thanks for this feedback. About number 1, Indeed, I think there is a typo in the diagram as well, since the SRC IP appears as 192.168.2.101 on the right side. For number 2, it is true that the VXLAN Packet/Frame has an outer Ethernet header too. I will let Rene know to take a look and consider making changes for clarification.
Thanks again for the feedback!
Laz
Hi, I have some questions to confirm.
Because of server virtualization, the number of addresses in the MAC address tables of our switches has grown exponentially. Before server virtualization, a switch only had to learn one MAC address per switchport. With server virtualization, we run many virtual machines (VM) or containers on a single physical server. Each VM has a virtual NIC and a virtual MAC address. The switch has to learn many MAC addresses on a single switchport.
How does VXLAN fix this problem?
Switches will still connect to the servers and learn the VMâs MAC addresses, or not?
Second question - this image here. The underlay is L3.
The original IP/Ethernet headers are packaged up with a new IP and UDP headers added which the switches use to route the traffic properly via the underlay. Shouldnât there also be an additional Ethernet header? The inside header contains the MAC of the destination host while the outside ethernet header should contain the MAC of the next-hop on the L3 underlay (VTEP2).
And the final question
VTEP IP interfaces are like RLOCs in LISP, those make sense. The VNI Interfaces are the switchports to which a specific VNI is assigned? Like with a VLAN in traditional topologies.
And to confirm, VNIs are basically like VLANs, correct? Just a VXLAN concept in comparison with the traditional VLAN concept.
Thank you!
David
Hello David
Yes, each individual switches still connect to the servers and learn the VMâs MAC addresses. But those MAC addresses remain local to that switch and to other VTEPs that share the same VNI. In a conventional Layer 2 network, any connected switches that share the same VLAN, including core switches, will also have to learn those MAC addresses. And if you have a Layer 2 network segment spanning multiple switches, each switch must learn the MAC addresses of the VMs connected to all switches that share that VLAN! With VXLAN, the network core doesnât need to learn those MAC addresses. This is because MAC address learning is confined to the overlay network.
Yes, there is an additional Layer 2 header that may be Ethernet, or may be something else, depending on the underlying technology. This was not added to the diagram because it has no direct influence on the operation of VXLAN. And the communication between VTEP1 and VTEP2 takes place at layer 3, which means that you may have multiple routing hops between those devices, in which case the Layer 2 header will change from hop to hop. So yes, there is a Layer 2 header that goes there, but for the reasons I mentioned, it is not explicitly shown.
The VNI interfaces shown in the diagram are indeed access ports that are assigned to a particular Layer 2 network segment. They are indeed analogous to traditional VLANs. And VNIs do correspond to a Layer 2 network segment, just like VLANs do yes.
I hope this has been helpful!
Laz
Hello Jaimes
A conventional switching implementation with VLANs uses the MAC address table in the switch to learn MAC addresses and map them to particular interfaces. This goes for both the access ports and the trunk ports of the switches involved. That way, in any topology, when a frame enters a switch, the destination MAC address will be looked up in the MAC address table, and will egress from the corresponding access or trunk port found in the MAC address table.
With VXLAN, you need a way to map a destination MAC address to a remote VTEP. You canât use the MAC address table for this, since it will not be populated with VTEP information. You need a mechanism for this mapping because you are still operating at Layer 2, so the MAC address is still the element used for this purpose.
So, a VTEP will maintain a VXLAN mapping, which is a forwarding table within its memory that will correspond destination MAC addresses with the IP address of the remote VTEP on which that MAC address resides. For example:
When S1 sends a frame to S2, it puts the destination MAC address of S2 in the destination MAC address field of the Ethernet frame. When LEAF1 receives this, it looks up this destination MAC address in its VXLAN forwarding table, and finds the IP address of LEAF2 as the destination VTEP. Thatâs how VXLAN knows where to send such a frame.
But the question is, how does a VTEP learn about these MAC address to VTEP IP mappings and how does it create them? There are several ways to do this, and they are listed in the lesson. Does that make sense?
I hope this has been helpful!
Laz
Hello Laz.
A quick question. Can devices in different virtual networks (VNs) communicate somehow?
Another question is, in SDA, is it correct to say that VNs provide macrosegmentation and scalable groups microsegmentation?
Thank you.
David