We've looked at how software defined access handles traffic flow, but we've
made an assumption this whole time that the hosts were already known. So let's
remember how this works. We have a fabric edge node here on the left. We have a
fabric edge node here on the right. We have a packet coming in from one
endpoint.
We'll call this endpoint 1 here, coming in on FE1 and then endpoint 2 on the
right connected to FE2. And so what we have is we have a frame that is getting WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
right connected to FE2. And so what we have is we have a frame that is getting
sent out sourced from endpoint 1 destined for endpoint 2. And so we know
that we need to understand where endpoint 2 is. Fabric edge node 1
doesn't necessarily know this. Maybe it already has it cached, but let's just
assume it doesn't. So we're going to go to the control plane node. The control
plane node is a Cisco device that is going to maintain the mappings. Remember WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
plane node is a Cisco device that is going to maintain the mappings. Remember
of our endpoint IDs that map to the routing locator. So this EID to R-lock
mapping. And these are a bunch of Lisp terms because that's what we're using at
the control plane. So FE1 fabric edge node 1 is going to send the map request
to
the control plane node. We're going to get a map reply back that says, hey, if
you're trying to get to endpoint 2, try sending to fabric edge 2. Now keep in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you're trying to get to endpoint 2, try sending to fabric edge 2. Now keep in
mind that within the SD access world, this response might actually get
redirected
and the response comes from over here to say that FE2 directly responds and
says that it has endpoint 2. It depends on how we configure our SD access
environment. But either way, now this question mark becomes, I guess, an
exclamation point, and FE1 fabric edge node 1 now knows where endpoint 2 is.
Now again, we're going to record this in cache and say that endpoint 2 is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now again, we're going to record this in cache and say that endpoint 2 is
mapped
to the routing locator for fabric edge 2. So this cache is going to keep that
in
mind for up to 24 hours. So the assumption here is that outside of wireless
roaming,
and we'll talk about wireless roaming later, but outside of that endpoint 2
probably isn't going to be moving around a whole lot. A lot of our wired
clients and wireless stations don't actually move. And so keeping this cache WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
clients and wireless stations don't actually move. And so keeping this cache
for 24 hours is usually considered to be pretty safe. And if it does move for
any
reason, then we will update the cache. And that's all handled by the fabric, no
problem. But the idea here is we don't want to have to go through the whole
control plane process just to learn where this endpoint is. And so every time
another frame shows up destined for endpoint 2, this cache entry is going to
get reset. So remember, it's 24 hours of inactivity, not after 24 hours of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
get reset. So remember, it's 24 hours of inactivity, not after 24 hours of
initially learning it. At that point, we would drop the entry from the cache,
because probably maybe that endpoint dropped off the network. And so we
shouldn't assume that it's still there. If nobody's tried talking to it for
again, 24 hours. So at this point, we understand that we are going to use that
VX land tunnel between our fabric edge nodes, we're going to encapsulate it,
send that frame over to fabric edge 2, and then it will get delivered. And that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
send that frame over to fabric edge 2, and then it will get delivered. And that
is how our fabric traffic flow works. But here's the question that we want to
ask, where did this entry come from? How does the control plane node know where
endpoint 2 is? And so we need to understand that there is a registration
process involved. Now, there is a few other Lisp terms to be aware of. First of
all, we have the ingress tunneling router or the ITR. And then we have the e WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
all, we have the ingress tunneling router or the ITR. And then we have the e
gress
tunneling router or the ETR. The key focus here is not on the word router,
because these are probably catalyst 9K switches in our fabric environment. And
so again, Lisp was developed for the internet. And so we have this router word
that we are trying to apply to switches. The focus instead should be on the I,
which stands for ingress, and the E, which stands for egress. The word ingress WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which stands for ingress, and the E, which stands for egress. The word ingress
is
referring to the fact that it's coming into the fabric, and the word egress is
saying we're coming out of the fabric. So that's interesting, because if I were
to send a response frame from endpoint 2 back to endpoint 1, I'm coming into
the
fabric on this side and coming out of the fabric the other way, and that is
true.
The phrase and term ITR and ETR, these are relative terms relative to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The phrase and term ITR and ETR, these are relative terms relative to the
specific traffic flow we're talking about. Meaning if endpoint 1 is talking to
endpoint 2, ITR and ETR as we have labeled. If it's going the other way, then
now
Fe2 operates as the I, I, T, R, and Fe1 operates as the E, T, R. So they can go
both directions and oftentimes they do. And so we will also see these referred
to
as XTRs, just meaning that they do both functions. So why do we bring this up? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as XTRs, just meaning that they do both functions. So why do we bring this up?
Well, because this endpoint 2 is attaching to a particular device, and because
endpoint 2 is going to be targeted by other communications, we typically are
referring to its attached device as its ETR, because the rest of the network
needs
to know where it is. But again, we can think of it in whatever terms we want,
just be aware that endpoint 2 is going to have a device that it's attaching to. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just be aware that endpoint 2 is going to have a device that it's attaching to.
So in our case, with the ITR and the ETR set, we have to keep in mind a few
things. First of all, remember that on ingress, our frames are going to get put
into the into the VXLAN world and that VXLAN headers going to carry some
important information. For example, it's going to have the tagged policy on ing
ress.
And if we think back to that policy plane type of model, this is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we think back to that policy plane type of model, this is going to
involve a scalable group tag, as well as a virtual network identifier. And so
the
this ties back to the scalable groups and the virtual networks, which are
essentially VRFs for macro segmentation and scalable groups for micro segment
ation.
But remember, we're not enforcing the security policy here. The enforcement
happens here on egress. So our policy enforcement is going to be the
responsibility of the ETR. Furthermore, it's this device over on the right. In WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
responsibility of the ETR. Furthermore, it's this device over on the right. In
our
case, again, the ETR that is responsible for identifying and registering the
attached endpoints. So one of the key parts of this conversation is how does
the control plane know where to find all of these different endpoints? How does
it know that these endpoint IDs are mapped to specific R locks? Well, that is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it know that these endpoint IDs are mapped to specific R locks? Well, that is
the responsibility of this device here. Again, the ETR in our scenario. And it
's
going to perform a map register operation by sending a packet to the control
plane
node. It's letting it know that, Hey, I have a new endpoint identifier. And in
our
case, in the SDA world, this is typically going to be a slash 32 route. We can
't
advertise the slash 24 route because in SD access, we've got the same subnets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
advertise the slash 24 route because in SD access, we've got the same subnets
everywhere. We could have dozens of other fabric edge nodes. And they all have
this exact same subnet, because it's our access layer inside of our campus. And
so
we can't share the slash 24 route that shared everywhere. But rather, we want
to
share the specific endpoint identifier. And so that's why we're advertising
slash 32 routes to the control plane node. So this completes the picture at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
slash 32 routes to the control plane node. So this completes the picture at
this point, we would find that a new ITR, maybe down here, a packet arrives.
This
is now our ITR for this particular traffic flow. And it needs to know where
endpoint two is. And so now it's going to send its own map request message to
the
control plane node, it'll get a map response back from somebody, neither the
control plane node or fabric edge to. But because the control plane node now
knows where this attached endpoint lives, it can respond back. And that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
knows where this attached endpoint lives, it can respond back. And that's
thanks
to the map register message that was sent, once that packet first or once that
endpoint first attached to the fabric.
[no audio]