So we have now built out a software defined access fabric.
We have our fabric edge nodes here and these edge nodes are going to play host
to the subnets
that exist in our normal network.
Remember the edge nodes are going to be the access layer switches.
So in our access closets we now have edge switches and these are now connecting
to one another
via a layer 3 underlay.
And so a packet now shows up keeping in mind that we are talking about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so a packet now shows up keeping in mind that we are talking about
potentially extending
subnets among our different access closets just like we do in a traditional
layer 2 design.
And so we might have a packet from host A destined for host B and they're on
the same subnet.
Maybe this is 10 to 100 to 0 to 0/24.
So if now our destination is for a host that is not attached to this edge WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if now our destination is for a host that is not attached to this edge
device, further
more it is going to be connected to a device that is layer 3 segmented on the
other side
of this fabric.
So the question is how does it know where to send this packet, the packet that
just arrived
on its downstream interface, it needs to know where to send this packet and
there could
be dozens of other edge devices that are out here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
be dozens of other edge devices that are out here.
So it could be any one of these other edge switches.
Do we just send it to all of them and hope for the best?
Certainly I suppose that would be an option but it wouldn't be a very efficient
one.
Now when we think about forwarding decisions, if we want to forward traffic in
a traditional
network, how do we do this?
Well in a traditional layer 3 environment, I need routes.
I need routes everywhere. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I need routes everywhere.
And in a lot of our organizational routing tables, we're going to find that we
rely heavily
on a default route because the default route will tell me what to do if I don't
happen
to have a more specific route.
So this is important because if we think about it, this can amount to a lot of
routes
in the routing table.
Now in an organizational subnet, we might have a few hundred, maybe dozens, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now in an organizational subnet, we might have a few hundred, maybe dozens,
maybe hundreds,
maybe thousands of routes or subnets in the routing table.
But look at what just happened.
We now have a shared subnet.
I'm not talking about knowing just where this slash 24 is.
Yeah I can learn a lot of slash 24 and still manage that just fine on a switch.
I need to know where this host is.
This host is effectively a slash 32 route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This host is effectively a slash 32 route.
And if I have a subnet like a slash 24, I might have 250 slash 32 hosts
throughout this
network and that's going to be true for every one of my subnets.
So does this architecture scale particularly well and the answer is no.
I don't necessarily want to have routes everywhere.
First of all, if we're talking about knowing where all these slash 32 routes
are, a default
route isn't going to help me.
I'm not going to be able to just forward it to let's say this edge node up here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm not going to be able to just forward it to let's say this edge node up here
, call
that my default route and hope for the best.
Now I have to forward to this specific edge node so it can get to this specific
host.
That means that I need to in theory based on traditional networking, routing
and switching,
I would need to know where every single slash 32 in the network is.
This is a push methodology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is a push methodology.
I would push all of these routes everywhere in the network.
And this is how our networks today work.
If I have a traditional layer three architecture, I'm going to run something
like OSPF or EIGRP
and I am proactively pushing subnet information everywhere.
So unless I'm going to rely on a default route, I now have all of the routes in
my environment.
And so this works well again at the scale that most of our organizations work WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so this works well again at the scale that most of our organizations work
on.
And now that we're talking about learning potentially where every single host
lives in the
environment, we're going to have some massive scaling issues.
It's going to require us to have a lot of slash 32 routes.
So rather than use this push methodology of saying everyone's going to know
where all of
the routes are, we're going to switch this over.
And we're going to have a poll methodology where we can learn our routes on an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're going to have a poll methodology where we can learn our routes on an
as needed basis.
This means that until a packet shows up destined for host B, I'm not going to
know where B lives.
I don't need to proactively have that information, along with the thousands of
other hosts in my
network, I just need to know where to learn.
And I'm going to rely on a database of information in order to learn where that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I'm going to rely on a database of information in order to learn where that
is.
This whole mechanism set is going to rely on a protocol known as the locator ID
separator
protocol or Lisp.
Lisp is a Cisco proprietary protocol and it was developed for the service
provider space.
And here we are saying, you know what, we can also apply this to software
defined access.
What we need is we need a database, a database that can sit here accessible in
the underlay, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the underlay,
so accessible by all of these edge devices.
And that database needs to know all of the host to edge mappings.
This edge that we're talking about here, this edge device, where we're really
saying is
I need an IP address that I can tell everyone, hey, if you want to get to a
particular host,
like host B, send it to this edge's loopback IP address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like host B, send it to this edge's loopback IP address.
This IP address in the Lisp world is known as a routing locator or an R lock.
So basically if this edge device has an IP address of 10.1.1.1, then our
database is going
to say that if we have a packet destined for host B, that we should send it to
10.1.1.1.
This is the mapping that we're talking about here of saying that a host address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is the mapping that we're talking about here of saying that a host address
, the slash
32 route, is mapped to a specific R lock or ultimately a specific fabric edge
node.
In Lisp, this database is known as a map server or a map resolver.
And we're going to cover a lot more about Lisp in greater details later on in
this course.
But for now, just some Lisp terms are being tossed around here, like the R lock
is the IP
address.
The map server, map resolver is this database concept and in our SDA WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The map server, map resolver is this database concept and in our SDA
environment, we're
going to refer to this as the control plane node.
And that is exactly what this device is here in the fabric.
This database is our CP node in the SDA architecture.
So back to the original scenario.
We had said that host A sends a packet with a destination address of B. And it
lands
on this fabric edge and it says, I don't know where B is.
And that's because we're not proactively pushing that information to the edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's because we're not proactively pushing that information to the edge.
So instead, this edge has to go out and send a request to say, hey, I'd like to
know where
host B lives.
I'm going to get my answer here.
And this is why we call this a pole methodology.
I'm pulling this information down from the map server, the map resolver, the
control
plane node, whatever one of all this database and SDA terms is the control
plane node.
So I'm going to pull that information down from the control plane node.
And now I know that I'm supposed to send it over here to this edge node. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now I know that I'm supposed to send it over here to this edge node.
The problem is I now need to send it to that edge node.
But if the destination in my packet is this host, how do I send it to a
different destination?
While second destination is going to require a tunnel.
I need to build a tunnel between edge nodes here so that my actual destination
is this device
in the outer header.
But this tunnel can't just be any tunnel mechanism. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But this tunnel can't just be any tunnel mechanism.
It needs to carry this layer to information since we are stretching this subnet
between
the two locations.
And so in the next video, we're going to explore how we can leverage VXLAN in
order to make
this tunnel mechanism happen.
[BLANK_AUDIO]