This topic is to discuss the following lesson:
Hi Rene, this is a very good lesson on VXLAN, straight to the point and well written.
I’m particularly passionate to this topic because I worked on a VXLAN EVPN Fabric the last year and love this technology.
If I had done a lesson like this when I started It would have been easier to learn the topic…
3 Likes
Hi Rene,
How can we configure vxlan. Could you please explain.
1 Like
Hello Bikram
Take a look at the following lesson in order to further understand how to implement a VXLAN topology.
I hope this has been helpful!
Laz
This is the BEST explanation document on VXlan available on internet.
Hello Syed
Thanks so much for your positive feedback, it gives us the drive to continue to do our best!
Laz
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
Tim
Hello Timothy
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?
Thanks!
Laz
Laz,
Please see URL below.
https://forum.networklessons.com/t/cisco-csr1000v-vxlan-unicast-configuration/11433
I received periodic topic discussions via email, but for some reason when I click the link I’m unable to access.
Thanks
Tim
I fixed this, somehow a draft post got published 
Thanks for letting us know!
Hi
Thanks for this lesson.
<Traditional layer 2 networks have issues because of three main reasons:
Spanning-tree.
Limited amount of VLANs.
Large MAC address tables.>
My understanding is as follows. Could you please explain ?
- Spine-leaf topology solved the Spanning tree issue. STP is not an issue in VxLAN.
- Limited amount of VLANs : This is the essential why vxlan needs.
- Large MAC address tables : I’am not sure how vxlan solve this problem. This issue is common in virtualization.
Spine-leaf was not ip network. It becomes ip underlay to bind MAC learning to a multicast group and to deliver VxLAN frame efficiently. Is it true ?
Thanks
Michael
Hello Michael
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.
I hope this has been helpful!
Laz
Hello,
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 ?
Thank you.
Hello Ike
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 hope this has been helpful!
Laz
That is a typo indeed. I just fixed it, thanks!
1 Like
Thank you very much Laz for the clarify the issue.
1 Like
I believe there’s a typo in the diagram at 9:30 - the hosts IPs are shown as
192.168.1.101 should be -> 192.168.12.101
192.168.2.102 should be -> 192.168.12.102
Hello Doug
Thanks for pointing that out. I will let Rene know!
Laz
Hi Team,
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.