- [Narrator] With traditional Ethernet switches,
we can support a little over 4,000 VLANs.
The reason is, the VLAN field is 12 bits long,
it's going to give us just over 4,000 VLANs,
but in today's networks we might have a data center
with lots of virtualization and need to isolate
several virtual machines from other virtual machines,
we could easily run out of VLANs.
Well, the great news is, virtual extensible LANs,
or VXLANs can come to the rescue.
They let us have over 16,000,000
different identifiers instead of just 4,000.
And the way VXLANs can do that is by encapsulating
our Layer 2 or even Layer 3 traffic
and adding a VXLAN network identifier.
That's called a VNI, and this VNI field is 24 bits long,
that's what gives us those 16,000,000 plus
VXLAN network identifiers.
Those VXLANs can run over
our existing physical network infrastructure.
The existing physical network infrastructure
is referred to as an underlay network.
Here we see 12 different switches
and they're physically connected, as you see here,
and this makes up the underlay network.
But we could create logical tunnels
between specific switches to create
and an entirely different topology.
Here, we're using that same physical underlay network
but we're logically creating tunnels
between select switches to create
a totally different topology.
And that's our overlay network.
We typically see this in data centers
where we use a spine/leaf design.
We've got our nodes like our servers connecting
to leaf switches, and those leaf switches
they interconnect by going through a spine.
The spine switches allow any leaf switch
to get to any other leaf switch in only a single hop.
We just have to go through one spine switch
because every leaf switch is connected
to every spine switch.
And the device that does our VXLAN encapsulation
is called a virtual Ethernet module, or VEM,
and each VEM has an IP address.
It can have more than one, but it's got
at least one IP address that we're going to use
to communicate over this routed network.
And the IP address, it's assigned to a special interface
called a VTEP, which stands for VXLAN tunnel endpoint.
Each VTEP is associated with one or more VNIs.
VTEPs on diffferent switches, they can temporarily
bring up a tunnel and pass traffic between themselves.
By the way, another benefit that VXLANs give us
is that if we're sending traffic over a port channel
where we've got multiple links
making up a single logical link,
instead of just using one link, the VXLAN switches
know how to load balance that traffic
across all the different links in the port channel.
That can dramatically reduce congestion in the data center.
But an issue we have is what do we do with traffic
for which we don't know the destination?
On a regular switched infrastructure,
a switch that doesn't know how to get to a destination,
it's going to send out an ARP for broadcast, perhaps.
What about multicasts?
What about unknown unicasts?
What if we don't know where somebody lives,
how do we get to them?
Well, for that type of traffic, called BUM traffic
for broadcast, unknown unicast and multicast,
we've got different approaches for handling that,
but we're going to consider in this example
using multicast.
That's a very popular approach.
What we can do is have these different VTEPs
join a multicast group.
You might be wondering, do we have to have
a multicast group for each VNI?
And, no we don't.
We can have multiple VNIs belonging
to the same multicast group,
because the VEMs themselves, they're going to look
at the VNI identifier before sending the traffic out,
and it can see even though it received it over
this multicast group, it's going to see that, oh, yeah,
this is destined for different VNI,
I don't sent it out of this port,
so it's totally fine to have multiple VNIs associated
with the same multicast group.
Let's walk through an example of how this is going to work.
In the table you see on screen,
that table is being maintained
by leaf switch one, LEAF-SW1.
And what we want to do here is we want server one
to communicate with server two.
How do we do this?
Well, server one is going to send out an ARP for broadcast
because it knows it wants to get to 10.1.1.200,
but it doesn't know the MAC address,
so it sends out an ARP broadcast,
and when that frame goes into leaf switch one,
it's going to make an entry in its table that says,
"Hey, I just learned that the all-A's MAC address
"lives off of port Ethernet 1/1,
"and that switch also has a mapping table that says VLAN 10,
"to which server 1 belongs, maps to VNI 100010."
So, now we have a VNI identifier,
not just a VLAN identifier.
The way we're going to get to that
is go out of Ethernet 1/1.
Well, we just sent broadcast traffic
into this leaf switch one.
What's it going to do with that?
Well, for that BUM traffic,
remember broadcast, unknown unicast and multicast?
We're going to send that out to a multicast group
that our other switches joined.
And leaf switch three sees that
because it's a member of that multicast group,
we're pretending that the group number is 239.1.1.10.
When it gets that broadcast ARP, sent via multicast,
it's going to flood it out all of its other ports
so it's going to go down to server two,
and server two says, "Yup, that's me."
And it says. "My MAC address is the all-B's MAC address",
and it goes back to leaf switch three.
And switch three now knows that the 10.1.1.200
IP address with the all-B's MAC address
lives off of port Ethernet 1/1,
so its going to respond to the other VTEP and say,
"Hey if you want to get
"to the all-B's MAC address, come to me.
"Come to 192.168.1.33, that's my VTEP IP address."
And it sends that information over to leaf switch one.
And leaf switch one is going to make an entry in its table
that says "If I want to get to the all-B's MAC address,
"which lives in VNI 100010, I want to go to a VTEP
IP address of 192.168.1.33, and it's going to send the result
of the all-B's MAC address down to server one.
So, now, when server one wants to communicate
with server two, it's going to sent traffic to a destination
IP address of 10.1.1.200, which by the way
is in the same VLAN even though we're separated by a router.
It's going to say "I want to go to that MAC IP address",
and leaf switch one is going to say,
"According to my table the all-B's MAC address
"is available via VTEP 192.168.1.33".
So leaf switch one is going to form a VTEP tunnel
with leaf switch three, it's going to send that traffic
over there, leaf switch three is going to send it
out to server two.
And that's a look at how VXLAN communication
is going to be able to allow different devices
that live on the same subnet, the same VLAN,
to communicate with one another across a routed network.
And it's very useful in a data center to have
all those extra identifiers because, as we discussed,
we could run out of VLANs,
but we're probably not going to run out
of VXLAN network identifiers.