I think we've all been there. Sitting at your desk, frustrated, working on a network
design. Trying to figure out how to get some Virtual Machines into the same LAN segment,
even when there's a whole network between them.
What you really wish you could do, is run a Layer-2 LAN segment, over the top of your
existing network. I have good news my friend, This is one of the things that VxLAN does.
It helps simplify the underlying network, and reduces the need for spanning-tree, trunking,
and stretching VLANs. Virtual Machines can move between hosts on
different VLANs, all without the need to fiddle with different IP addresses.
And on top of it all, VxLAN is defined in RFC 7348, so it's standards based. There's
no need to lock in to a particular vendor.
Let me take a moment to briefly show you what we're going to cover in this series
In this video, we're going to get an overview of VxLAN, and have a look at the basics of
how it works. In part 2, we'll dig into the VxLAN headers,
and what they do. Part 3 introduces the spine/leaf topology,
which often goes hand-in-hand with VxLAN. Things will get really interesting in part
4, which shows us how addresses are learned. If you've heard about EVPN, this is the video for you
And if you want to see how it all fits together,
then you'll definitely want to see parts 5 and 6, where we'll configure some Nexus
9000 switches. Now let's get under the hood, and see how VxLAN works
Every VLAN has a VLAN ID. This ID is added to a frame to keep traffic unique. The VLAN
ID is 12-bits long, allowing around 4000 unique VLANs.
VxLAN is quite similar. Each VxLAN segment also has an identifier, called a VNI. This
is 24-bits long, which gives us around 16-million segments.
It is enough to give VLAN some sort of inferiority complex.
Just as with VLANs, traffic in one VNI is kept separate from every other VNI. If you
want to mix the traffic, you will need to use a router
You may think though, "4000 VLANs should be enough for anybody." Well, imagine that
you're providing services to customers. If you give each customer 8 VLANs, you can
only have 500 customers before the VLAN pool is exhausted. After that, you have to get
creative, and reuse VLAN ID's across different hardware, or use something like Q-in-Q.
This is where VxLAN helps. With 16-million addresses to choose from, you have unique
ID's for your customers across all your data centres or sites.
VxLAN creates virtual networks on top of the existing infrastructure. This makes it an
'overlay' technology. The infrastructure it runs on is called the underlay
The underlay network is all layer-3. All ports in the underlay are routed, so there is no
need for trunking or spanning-tree. Dynamic routing of some sort is used. OSPF
and EIGRP are good choices. IS-IS would be fine too. This makes good use of ECMP for
load-sharing and fast recovery. You could use BGP in the underlay, but this
can get quite complicated, so I won't get into it here.
VxLAN itself is the overlay network. Each VNI is a separate virtual network that runs
over the underlay. Each of these VNI's are called a bridge domain
To create this virtual network, traffic is encapsulated with UDP and IP before it is sent out
When it reaches the destination switch, it is decapsulated.
A hidden advantage to separating the overlay and underlay, is that the underlay can be
changed without needing to redesign the overlay. As long as there is IP connectivity from one
end of the underlay to the other, the overlay will be fine
This leaves us with a question. How does encapsulation work?
Switches and routers that participate in VxLAN has a special interface called a VTEP.
The VTEP provides the connection between the overlay and the underlay.
Each VTEP has an IP address in the underlay network. It also has one or more VNI's.
To deliver traffic from one host to another, a source and destination VTEP will create
a stateless tunnel. These tunnels exist only long enough to deliver the VxLAN frame
When a frame for a remote host reaches a switch, the frame is encapsulated in IP and UDP headers.
The switch then forwards the traffic over the underlay
But, how does the switch know which destination VTEP to send the traffic to? How does it even
find the other VTEPs? We'll investigate these questions and more
in part 4 of this series.
VxLAN can be supported on hardware or software. An advantage of this is that it can run on
a hypervisor like ESX or Hyper-V. This is the host-based method. The vSwitch
on the host has a VTEP, which encapsulates traffic from VM's before it touches any
physical switches. The physical switches just see IP traffic,
and are unaware of VxLAN. The advantage of this is a simplified physical
network, which can simply focus on transport. The VTEPs could also be on physical switches
or routers. An example of this is configuring VxLAN on a Nexus switch. This is called a
VxLAN gateway. The VMs send traffic, and the vSwitches pass
the traffic as normal. When the traffic arrives on the physical switch, the VTEP encapsulates
the frames. The advantage is that VxLAN may be implemented
in hardware, improving performance. Not all platforms support VxLAN in hardware, so watch
out when you're choosing your switches. Of course, a hybrid approach is possible.
This is where some devices are behind VxLAN gateways, and some hosts have VxLAN enabled natively
In the second part of this series, we're going to dig deeper into VxLAN headers and
encapsulation. Before moving on, please hit that like button,
and take a moment to subscribe. I'll see you in Part 2