So, our situation is once again that a packet has arrived here on this edge
node, destined
for host B, and the edge node here reached out to the control plane node and
now has learned
where host B lives.
It lives on this edge over here and we used Lisp in order to learn that
information using
that pole methodology.
I have pulled that information down and now I know where to send it.
Well, here's the problem.
I have a packet with a destination of host B, which means I can send it here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I have a packet with a destination of host B, which means I can send it here
and in
a traditional network that would be no problem other than the fact that now
this device and
this device also need to know where host B is.
If I just forward this packet to this layer 3 device in the middle, it's going
to check
its own routing table for the destination host B and it's going to learn where
it is
and send it on.
So now we're asking these devices in the middle to have that full routing table
experience
that we just said we don't want. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we just said we don't want.
We don't want our edge devices to know all of that information and have to
store it all.
We have this database of information here on the control plane node instead and
so we'd
really rather not have to know that information.
And so that's exactly what we're going to want to build out here is a tunneling
mechanism
where these devices in the middle don't know where host B is and yet they will
happily facilitate
our communications path from edge device to edge device. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our communications path from edge device to edge device.
So what do they need to know?
Well, we had pointed out before that maybe this edge device here has an R lock
in list
terms or an IP address of 10.1.1.1.
So they don't need to know where B is but they do need to know where this is.
So they need to know where 10.1.1.1 is or have an equivalent subnet and that
information
needs to exist in both of their routing tables. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
needs to exist in both of their routing tables.
This way I can build a packet now that has a destination of 10.1.1.1, send it
into the
network and allow the network to carry it to the edge device.
But we have a problem, we have two different destinations.
I need them to look at this outer destination, this destination that I'm really
asking them
to look at and get me to this 10.1.1.1 and I don't want them looking at the
destination
that says I'm trying to get to host B because they don't know where B lives. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that says I'm trying to get to host B because they don't know where B lives.
Well we have a very simple way in the networking world in order to have
multiple destinations
and to only look at one of them, namely the outer one that just mentioned and
that would
be the concept of the tunnel.
So I can take my original frame here and this frame can be destined for 10,
well actually
this one will, we didn't give an IP address to host B. So it's destined for
host B. This
would be in the IP header here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
would be in the IP header here.
We still got our payload here of whatever information host A is just trying to
get over
to host B and we're going to wrap all of this up in a new header which has a
destination
of 10.1.1.1 and we're going to send this information out.
So now we are effectively building a tunnel through the SDA fabric to get to
the other side
and because these devices in the middle are not going to de-incapsulate it, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and because these devices in the middle are not going to de-incapsulate it,
they're only
going to look here at the outer header to try to get us to the ultimate
destination which
is B but they don't know where going to be because this is the inner header.
Now we've accomplished something pretty great.
Neither the edge nodes nor the nodes in the middle need to know where host B is
.
The only device that has to know where B is for all of this to work is the
control plane WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
node.
If the control plane node knows where all of these hosts are then the edge
nodes can pull
that information down on an as needed basis and meanwhile the underlay devices
in the
middle they don't ever need to know where host B lives nor do they need to know
where any
of the hosts live in this architecture.
But we once again come to another problem which is right here we have said that
we are
extending our subnets. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
extending our subnets.
If we're extending our subnets then this means that this is going to require a
layer
to tunnel because this is effectively saying we're going to stretch VLAN 10 or
maybe it's
VLAN 100 since we have a 100 in there but we'll call it VLAN 100 so VLAN 100
now needs
to stretch between these two edge devices which makes sense because remember
this is
a campus architecture and these are simply access layer switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a campus architecture and these are simply access layer switches.
If I'm building out my fabric we have said that we want my access switches to
all have
layer 2 connectivity among them even though they are now layer 3 separated by
whatever
these devices are here in the middle maybe it's just a pair of physical
distribution switches
that are now operating as a layer 3 underlay to connect my edge access layer
switches.
So because I want layer 2 to be extended I actually need to carry the ethernet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So because I want layer 2 to be extended I actually need to carry the ethernet
header as part
of this tunnel.
Notice I left that on there we are actually going to encapsulate the entirety
of the layer
2 frame.
Most tunnel mechanisms are layer 3 meaning they're not going to carry the ether
net frame they'll
just carry the inner TCP/IP or UDP/IP layer 3 header.
But in this case we do need to take the layer 2 header with us so we can carry
the entire
layer 2 frame.
If host A and host B for example are on the same subnet then I'm probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If host A and host B for example are on the same subnet then I'm probably
sending to host
B's MAC address.
I have a destination MAC address of host B and that needs to be maintained here
inside
the layer 2 frame.
So we need a layer 2 tunnel how are we going to do this?
So we're going to use a special protocol known as VXLAN.
Which looks a lot like VLAN except this X here actually stands for extensible
so it's
the virtual extensible local area network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the virtual extensible local area network.
VXLAN is a tunnel mechanism that can carry layer 2 information so it builds
actual layer
2 tunnels.
This tunnel therefore that we built up here between our edge devices this is
now going
to be a VXLAN tunnel.
Now specifically within the world of Cisco's SDA we're going to use a flavor of
VXLAN that
Cisco developed called VXLAN group policy option or GPO because we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco developed called VXLAN group policy option or GPO because we're going to
carry a
little bit of extra information and spoiler alert this is going to be the
scalable group
tag or the SGT which we'll be talking about in the next video.
We're also going to find that we maintain the QOS information we actually
migrate QOS
data from the inner header here and we place it into the outer header over here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
data from the inner header here and we place it into the outer header over here
.
That way our QOS tags and QOS policies get respected through the entire under
lay.
So the way VXLAN works is we're going to add a header right here in the middle
and this
is a 50 byte header.
This header is going to contain some very important information.
Most importantly it's going to carry our 24 bit VXLAN identifier which we call
a virtual network
identifier sometimes referred to as a VNID but usually especially in Cisco WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
identifier sometimes referred to as a VNID but usually especially in Cisco
documentation
we're going to see it as a VNI.
For bits this means we have 16.7 million different VXLAN identifiers that we
can use so that's
pretty cool and gives us plenty of options in SDA.
In SDA we don't need nearly that number but VXLAN is primarily developed for
data center
applications we're applying it to SDA and in the data center 16 million is a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
applications we're applying it to SDA and in the data center 16 million is a
great number
for us to have especially for a service provider with lots of customers.
Now importantly because we're adding 50 bytes and also importantly that there
is no fragmentation
supported by a VXLAN this means that our underlay must support at least 1550
bytes, 50 additional
bytes for Mtu.
So we need to make sure that our underlay supports that Mtu and hopefully in an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we need to make sure that our underlay supports that Mtu and hopefully in an
SDA environment
because it's all our own equipment building connections out to our Xs layer
switches this
shouldn't be a problem but we definitely need to take it into account if we're
building
this out ourselves.
So remember these layer three interfaces we said that this is a loop back
interface and
we're going to call this in the list world a routing locator or an RLock.
Well VXLAN also has a term for this it is known as a virtual tunneling endpoint WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well VXLAN also has a term for this it is known as a virtual tunneling endpoint
or a VTEP
so we're going to build these tunnels between VTEPs.
Just understand that we're talking ultimately about the same thing here.
We're talking about a layer three interface on these edge devices that are part
of the
underlay meaning that all of the underlay devices know how to reach it and from
a VXLAN
perspective we're going to build our tunnels from VTEP to VTEP.
So let's go all the way back to our example.
We know that we've got this packet that came in and now we're going to build
this outer WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this outer
header here in the tunnel that has a destination address of the remote VTEP.
I then send that packet into the underlay and the underlay only ever sees that
I'm trying
to get to the remote edge device.
So we forward this packet along the path and eventually it gets to the remote
device.
It decapsulates that packet.
It looks at the underlying inner layer to frame and says okay now I see that
this frame
is destined for host B and again because it's layer three we're looking at a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is destined for host B and again because it's layer three we're looking at a
MAC address
and I'm going to forward it down to the appropriate host.
In this fashion because we preserve the layer to header information we have
again stretched
this subnet we have stretched this VLAN between our edge devices even though we
are separated
by a layer three underlay.
[BLANK_AUDIO]