I’m not sure if I posted this question to the correct topic area. My apology if I didn’t. I tried to access “Cisco CSR1000V VXLAN Unicast Configuration” a few minutes ago, but receive an error message. Below is the following error message from Firefox:
404 – Page not found
The page you trying to reach does not exist or has been moved. Please use the navigation menus, the search box, or try one of these instead:
Thanks for taking the time to share this with us. Can you clarify from where you tried to access this content? There is no lesson called “Cisco CSR1000V VXLAN Unicast Configuration.” Can you send us the page from which you tried to connect to the failed link?
First of all, we must make a distinction between VXLAN and spine-leaf. The first is a tunnelling protocol while the second is a network topology/architecture. They can work together, but they don’t necessarily have to be implemented together.
Actually, the spine-leaf topology doesn’t solve the inefficiency of STP. If you create an L2 spine-leaf topology, without any additional configuration parameters, STP will severely limit the available bandwidth. The solutions to the STP problem (regardless of the topology underneath) is:
to employ VXLAN
to break the network into smaller network segments/subnets
to introduce what is known as Transparent Interconnection of Lots of Links (TRILL) or shortest path bridging (SPB) to replace STP.
You can choose which solution to use depending on your requirements and what your equipment supports.
This is one of the basic problems that VXLAN solves, allowing extensively large datacenters to have more than the 4096 VLANs that normal Ethernet provides.
Because you are able to segment the datacenter network into tens of thousands of subnets, you can keep the number of hosts per subnet very small. The result is that the MAC address tables created for each subnet remain small.
Again, spine-leaf is a particular architecture, not necessarily associated with VXLAN. If you choose to use it, you can. If not, you don’t have to. But if you do, yes, it becomes the underlay routed network.
Thank you for the lesson. It is very informative. This is very new topic for me.
I have a question about VXLAN frame format. With those added headers, total MTU size should be beyond 1500bytes. How do VTEP devices handle this?
My other question is about Packet Walkthrough picture. It looks like in the picture Host1 is doing the tunneling and encapsulate the packet with the tunnel IP address. (192.168.12.101). Shouldn’t be the tunneling done by VTEP ?
That’s a very good observation, and yes, the underlay infrastructure must be configured in order to accommodate this overhead. The VXLAN RFC draft states the following:
VTEPs MUST not fragment VXLAN packets. Intermediate routers may
fragment encapsulated VXLAN packets due to the larger frame size.
The destination VTEP MAY silently discard such VXLAN fragments. To
ensure end to end traffic delivery without fragmentation, it is
RECOMMENDED that the MTUs (Maximum Transmission Units) across the
physical network infrastructure be set to a value that accommodates
the larger frame size due to the encapsulation. Other techniques
like Path MTU discovery (see [RFC1191 and [RFC1981]) MAY be used to
address this requirement as well.
Specifically, the underlay network must be able to accommodate at least 1554 bytes:
1518 (max) for the inner Ethernet frame
8 bytes for the VXLAN header
8 for the outer UDP header
20 bytes for the outer IPv4 header
Yes, you are correct, this seems to be a typo. I’ll let Rene know to correct this. Thanks for pointing that out!
I joined as a member to understand basic concepts in networking. The lessons are really helpful.
Coming to VxLan, i have one query.
In multisite environment, generally Stretched VLANs are needed for some clusters. At same time, it is not recommended. So what i understood using VxLAN we can overcome this.
Using VxLAN, we encapsulate L2 Frame and transport over L3 network across sites. While encapsulate the L2 Frame , the VTEP (virtual Tunnel Endpoint) IP and mac will be added as header . However, VTEP IP addresses mentioned both in Source & Target sites also shown as in “Same IP segment”. That means without routing the frame will be forwarded across sites. This will be faster. Is this understanding of mine is correct?
Then again, we need to have same IP segment both in source and target site for VTEP Devices right? is this also stretched across sites right? This will conflict the basic idea of stretched IP segment (VLAN) across sites ? Can you help to clarify this concept.
You’re right that best practice dictates that you don’t span your VLANs across multiple sites, however sometimes as you say, it is necessary. There’s really no “solution” to this, either you span your VLANs or you don’t. You must however try to keep it to a minimum.
What VXLAN provides is an underlay network that is composed of routers and switches, where in most cases, you will never have a VLAN span multiple sites. Site-to-site communication in the underlay network will take place using L3 communication with routing. However, the VXLAN in the overlay network, which is being tunneled over that underlay network, is still spanning multiple sites. So from the point of view of the overlay network, you still do have a broadcast domain (VLAN) that is spanning multiple sites. This cannot always be avoided, but it should be minimized as much as possible.
Typically in a campus network, you should be able to avoid it completely, however, it is in distributed datacenters that you most often need to span VLANs across sites. VXLAN doesn’t “solve” the issue, but it does provide you with a framework where you can more easily apply such a configuration. You should still do it sparingly…
In it you’ll find details about the headers and where they are added.
Remember that VXLANs use an overlay and an underlay network. The VXLAN header actually sits between the header information of the overlay and underlay networks. The underlay network carries the “tunneled” traffic and uses the UDP header with port 4789 or 8472 to carry that traffic.
Below you can see the headers involved with the implementation of the VXLAN.
Thanks, Rene for these videos, Do you always have to map a VLAN to a VNI ? how do vxlan make use of these 16 Millions VNIs when i have to map a VLAN to a vni. Please let me understand i am really confused about it. Thanks
Remember that the purpose of VXLANs is not only to surpass the limitation of 4K VLAN IDs, but also to add flexibility to deployments, allowing for the simpler spanning of VLANs across sites. When there is no need to expand beyond that 4K limit, typical customer deployments will use a 1:1 mapping of available VLANs for simplicity.
However, when scalability to reach beyond this limit is needed, then it is possible to do so by assigning the same VLAN IDs to multiple unique VNIs found on different VTEPs within the fabric. So for example, you could have
VLAN 456 mapped to VNI 123 using a subnet of 10.1.1.0/24
VLAN 456 mapped to VNI 321 using a subnet of 10.2.2.0/24
The same VLAN ID is used, but on different VNIs. You can theoretically have 16 million VNIs each having 4000+ VLANs mapped to them.
Typically, you would have one VNI on a single physical switch, so you do have a limitation of 4k per physical device, but that is typically not a limiting factor.