Introduction to Virtual Extensible LAN (VXLAN)

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.

I received periodic topic discussions via email, but for some reason when I click the link I’m unable to access.

Thanks
Tim

Hi Timothy

Thanks for sharing that, I’ll let @ReneMolenaar know.

Laz

I fixed this, somehow a draft post got published :slight_smile: 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 ?

  1. Spine-leaf topology solved the Spanning tree issue. STP is not an issue in VxLAN.
  2. Limited amount of VLANs : This is the essential why vxlan needs.
  3. 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.

Hello Ramachandra

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…

I hope this has been helpful!

Laz

Thanks Laz for explaining it.

1 Like