So the way I like to draw this out is to represent a layer three interface with
a dot here.
So we've got this layer three architecture between these two layer three
devices.
But meanwhile, I am creating an overlay that allows me to have a network here
with a host.
Let's say this is just host A operating on subnet A, but then we've also got
this network
over here with a different host B. But again, this is all the same subnet sub WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over here with a different host B. But again, this is all the same subnet sub
net A here
and subnet A here. With traditional networking, this is impossible. We can't
actually have
that. Both of these devices would claim to have access to subnet A. And only
one of
them would really win out and potentially both of them would win out as they
talk to
different parts of the network. So some of that traffic would land here and
other that
traffic would land here, it would just be a disaster. What we can do with VXLAN
, if VXLAN
is an option here to form a tunnel, is we can sort of put this dotted line WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is an option here to form a tunnel, is we can sort of put this dotted line
between the
two networks. And now we see that host A and host B are both part of the same
network
segment. And those are being shared via these two different devices, thanks to
the VXLAN
tunnel. So this is all again, thanks to VXLAN, which does stand for the virtual
extensible
local area network. So how exactly does it accomplish this? I mean, what
exactly is
VXLAN doing? Well, as with all tunneling mechanisms, it is a form of encaps WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
VXLAN doing? Well, as with all tunneling mechanisms, it is a form of encaps
ulation. And encapsulation,
typically within the OSI model, we understand we take layer two encapsulate
layer three
into that and which has already encapsulated layer four and all of these things
. But we're
talking about tunneling, we add extra encapsulation. And VXLAN specifically is
going to be known
as Mac in UDP, actually technically we're right IP slash UDP here. So what we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as Mac in UDP, actually technically we're right IP slash UDP here. So what we
're looking
at is encapsulating not only the Mac address, but we're going to use IP and UDP
in order
to do that. And specifically, we're going to use UDP or 4789. But once again,
as always,
we might need to make sure that that port is open if we're passing through a
layer three
device, that is filtering ports. So we're going to see an increase in MTU here.
The increase
in MTU is going to go up by 50 bytes. So long as we're not carrying a dot one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in MTU is going to go up by 50 bytes. So long as we're not carrying a dot one
queue header.
For the most part, we don't do that within VXLAN. Just understand if we add
four bytes
to the ethernet frame that we're carrying, and we're carrying that dot one
queue header
with us, it would be 54 bytes. So 54 with 802.1 queue. But for the most part,
we don't
actually need this extra tag. For the most part, we don't carry the 802.1 queue WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
actually need this extra tag. For the most part, we don't carry the 802.1 queue
within
VXLAN. There's really just not a strong use case for doing so. Because the VX
LAN identifier
carries the VLAN identifier sort of within it. So all that to say, understand
that we
do need to increase VMTU. And once again, that VXLAN identifier is very
important. So
sometimes called a VXLAN network identifier, virtual network identifier. But
either way,
it's that VNI or sometimes the VNID that we talk about having 24 bits. So now WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's that VNI or sometimes the VNID that we talk about having 24 bits. So now
what we
can do is we can expand our data centers and expand our environments to say
that now we've
got plenty of these identifiers. And so that creates again that 16.7 million
network segments.
We don't have to worry about running out of VLAN IDs for very large
environments. So
what this ends up looking like is this. We take the entire layer two frame, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what this ends up looking like is this. We take the entire layer two frame,
meaning that
we've got the ethernet header still in there. And then whatever we're carrying
in here,
probably IP or IP version four, IP version six, TCP or UDP at layer four,
whatever the
payload ends up being in here. So we've got lots and lots of data inside this
layer two
frame. And by the way, don't forget that we've got that FCS at the end. So we
've got the
entire thing. And then what we're going to do is we're going to treat this like WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
entire thing. And then what we're going to do is we're going to treat this like
it's
itself a payload for VXLAN. And so what we're going to do is we're going to add
on a VX
LAN header. And that VXLAN header is eight bytes. But we've got to then add on
a new
outer IP header and outer layer four header as well. So this is where we say it
's an
IP and UDP, because we're going to add a UDP header here, which is another
eight bytes.
And then we're going to have to add an outer IP header. So that's 20 bytes. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we're going to have to add an outer IP header. So that's 20 bytes. So
that's up
to 36 at this point. And then we have finally our outer ethernet header, which
comes at
an additional 14 bytes, 12 of which is the source and destination MAC address.
So this
is where we can see that we need an additional 50 bytes. And we add that all up
. And if we
wanted the dot one queue header inside of, well, in here at this point, then
that would
actually add four extra bytes. Because this payload, before we encapsulated it, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
actually add four extra bytes. Because this payload, before we encapsulated it,
this was
fully ready for the 1500 bytes of, or you know, for using Jumbo frames fine,
but just
in a standard environment, that would be the 1500 bytes. And ethernet, header
and trailer,
those don't count towards and you know, the, the MTU themselves. Well, now that
they're
part of the payload, they do. And so that's why we need to count the extra
headers. And
if we want to think of it this way, the headers again, maybe the headers don't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we want to think of it this way, the headers again, maybe the headers don't
count up here.
But it's the inner headers that do because they're now part of the payload or
like this.
So however, when I think of it is fine. But again, we do see that we need an
additional
50 bytes. So we've created a bit of a monster of a frame that we're going to
send from one
device to another. So these devices have a name, by the way, at this point,
they are
known as virtual tunnel endpoints, otherwise known as V taps. The V taps are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
known as virtual tunnel endpoints, otherwise known as V taps. The V taps are
one of two
things we can think of them. Typically, the V taps are referred to as the end
points themselves,
the device. So this device here, for example, would be a V tap. And so with
this device over
here, we have two different switches running the X land. And each of them would
be known
as a V tap. We can also think of the V tap as the actual IP interface. And we
'll see
conversations and white papers talking about both of these. But the reality is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
conversations and white papers talking about both of these. But the reality is
that just
like with any other tunnel, such as GRE tunnels, we're going to need to form
the VX land tunnel
from one layer three interface to another. So this is typically going to be a
loopback interface
on the device. So here's my physical switch. Here's another physical switch.
And we're forming
the VX land tunnel via loopback from one device to the other. Now our V taps WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the VX land tunnel via loopback from one device to the other. Now our V taps
are switches. Now,
if we think of it like that, are going to have not only a virtual interface
like this, but we're
also going to have what's known as a local area network interface. And that
would be the
connection into the layer two world. This world is going to continue to use V
lands,
which is kind of interesting because yeah, we've got all these identifiers, the
16.7 million WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
16.7 million
identifiers between our switches. But southbound of one of these switches, this
is itself still a
classic layer two domain, meaning we can only still have those 4000 identifiers
. Now, I don't
know about you, 4000 identifiers on a single switch. That's plenty for me. I
don't think
I we're not even going to have that many ports. We could not possibly use 4000
identifiers on a
single physical switch. Meanwhile, the VX land in the middle, this identifier WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
single physical switch. Meanwhile, the VX land in the middle, this identifier
that VNI is sort of
the glue that connects two different V land identifiers. And what's interesting
is in the V
land world or the VX land world, rather, we can find that we can glue together
two different V
land IDs. So going back to the top left here, VX land, maybe we have an
identifier of 10567.
This is the VNI or the V-NID for this connection. When a packet gets sent and
encapsulated in VX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
encapsulated in VX
land, it's going to include this identifier. So the receiving switch knows
which layer two
domain to connect together. But meanwhile, what V land identifiers are on each
one of these
network segments? We might say, well, let's just go ahead and assign VLAN 105
or something like that
to the VLAN identifier or to the VLAN on the left. So, okay, so if I'm tagging
traffic coming in
here, it would have to be VLAN 105. But what about the switch on the right? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here, it would have to be VLAN 105. But what about the switch on the right?
Well, we say, well,
of course, it would have to be 105, right? Well, it doesn't. This could be 1536
. It doesn't matter
that these don't match because remember what we said, for the most part, we don
't actually include
the tag. And this is one of the reasons why, because if I'm going to have these
identifiers,
there we go, if we're going to have these different identifiers, where they
have to lock in and be
the exact same identifier, I've kind of eliminated the value of having all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the exact same identifier, I've kind of eliminated the value of having all of
these different VNI's.
Instead, what I've done is I've freed up each switch to use its VLAN
identifiers,
however it wants. So, I can assign VLAN 105 to this network here, and then this
switch over here
has the total freedom to do whatever it wants with its VLAN identifiers. And so
, it decides to assign
1536 here. Again, if I lock it in to say 105 must be used over here, well, then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1536 here. Again, if I lock it in to say 105 must be used over here, well, then
it kind of has to
be used everywhere. And so, if I have to kind of use it everywhere, then I've
locked up that one
VLAN identifier everywhere. And again, I'm going to quickly run out again. I
can't just say I'm
going to lock up the 4000 VLAN identifiers, because that's what I'm trying to
get away from.
So, this is why we say we have 4000 on each switch. I have 4000 here and 4000
here. I can use
them however I want. And also, coming back to this term, the VNI is what glues WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
them however I want. And also, coming back to this term, the VNI is what glues
them together,
and allows the switches to know, hey, I just received this identifier from VX
LAN, and I know
that that belongs on my side to VLAN 1536. And I don't care that the other side
thinks that it
belongs to their VLAN 105, so long that it's these network segments that I'm
connecting together.
Now, a very important part about VXLAN is to understand that VXLAN only exists WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, a very important part about VXLAN is to understand that VXLAN only exists
as a data plane
protocol. This is a data plane only situation. Now, if we think about it, what
we usually have
is we have a control plane that feeds information
into a device that allows it to perform data plane operations, meaning I bring
a packet into
this port, and I know to send it out this port. So, data plane operations are
enabled by the control WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
enabled by the control
plane. But we just said that we don't have this control plane, meaning I don't
have a bunch of
information as to being fed to me as to where to send this information. So,
what do we do here?
Well, we could ask the same question about Ethernet. How does Ethernet work?
Because Ethernet
certainly has data plane operations, but we don't have a protocol sharing where
all the MAC addresses
are. Well, the way Ethernet works is exactly how VXLAN is going to work. It's
going to use a flood WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to use a flood
and learn methodology, meaning that when that first packet arrives, I am going
to send it out all of
my interfaces. And when we think about what we're really saying here is I'm
sending it to all of my
VXLAN peers. So, I'm going to flood that. And in our case, because we're
flooding it across layer
three to all of my peers, I'm going to rely on multicast in order to do this.
If I multicast
it to all my peers, it gets flooded out all the ports. And eventually, I am WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it to all my peers, it gets flooded out all the ports. And eventually, I am
going to receive a
response. And once I receive a response, I am going to track this. And so, I
still will store a data
table so that I can eventually become more efficient. But we do see that this
is not super
efficient on its own. VXLAN is going to rely on flood and learn, and then there
's going to be a
whole lot of flooding before the learning occurs. So, what are our options here
? Well, VXLAN does,
unlike Ethernet, allow us to be paired up. So, we can pair up VXLAN with a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
unlike Ethernet, allow us to be paired up. So, we can pair up VXLAN with a
control plane protocol.
And we have several that we can take a look at here. Typically, multi protocol
BGP is going to be
a popular choice. We use this pretty much any time we're configuring this
ourselves. If we're not
using a pre-packaged software-defined networking solution, we're probably going
to use multi-protocol
BGP, which is known as BGP EVPN. So, Ethernet VPN is how we refer to that. Now, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
BGP, which is known as BGP EVPN. So, Ethernet VPN is how we refer to that. Now,
we also have a
couple of Cisco options. First of all, application-centric infrastructure,
which is Cisco's SDN
software or SDN platform for the data center. This is going to use a different
protocol known
as the Council of Oracle Protocol or Koop. And furthermore, importantly, as we
keep coming back to,
software-defined access also does not want to rely on flood and learn. So, what
does software
define access use? It uses LISP at the control plane. And so, VXLAN itself can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
define access use? It uses LISP at the control plane. And so, VXLAN itself can
operate without a
control plane, but we definitely want to map a control plane to it, which just
overall increases
is the efficiency of VXLAN operations.