All right, time for another quiz.
This time on list and vxland.
And this time from the beginning,
we can say that there are seven questions, not eight.
Question number one, how does list create
a pole-based control plane where routes aren't pushed everywhere?
Well, one thing we have to consider with traditional routing
and the way our networks work is that if I have a route,
let's say down here, for subnet A,
that I'm going to push that route into the environment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that I'm going to push that route into the environment
and it's going to be propagated everywhere.
This is, again, the push methodology,
where I'm pushing this route everywhere
so everybody has every single route in case they need it.
And so it creates a scenario where every single route
is known in every single routing table
within the routing domain.
So if we have 1,000 routes, this isn't that big of a deal
because most Cisco devices can handle 1,000 routes just fine.
But what if we have 100,000 routes?
Or, like on the internet, what if we're approaching a million routes? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or, like on the internet, what if we're approaching a million routes?
This gets to be problematic.
Routers can't process through that many routes very easily.
It's going to require a tremendous amount of memory,
a tremendous amount of resources,
and we want to make our networking environments
as efficient as possible.
And so this is why Cisco developed LISP
was to say, hey, the internet is becoming untenable.
The number of routes on the internet approaching a million,
that's not good for anybody.
We don't want to have to deploy massive routers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We don't want to have to deploy massive routers
throughout the entire internet
so that everybody can have all 1 million routes.
Instead, let's create a scenario
where we learn routes on an as needed basis.
And that is the idea of this pull-based mechanism.
So here's how this works.
Remember, if we've got a router here,
we've got a packet coming in that's destined for subnet A.
Now, if this router doesn't have a route for A,
it doesn't know where A is, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it doesn't know where A is,
well, it might be able to follow maybe an aggregated route
or the default route,
but if it doesn't have a default route,
then it's just going to have to drop the packet.
Well, not so with LISP.
When we're creating the LISP environment,
we have a control plane mechanism.
And let's say we have this environment now
with 100,000 routes.
Well, these 100,000 routes no longer need to be known
by everybody.
We're not going to push them all over the place
and make sure everybody has them just in case.
This in-case methodology WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This in-case methodology
is no longer what we're going to go with.
Instead, we're going to share those 100,000 routes
with the control plane.
And now we can embrace this as needed concept
where I go out to the control plane
and I pull the routes that I need.
So I find out where A lives
and then I can send it on towards the rest of the network.
Now, if I'm going to send this into the network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, if I'm going to send this into the network
with a destination of A,
but these devices in here don't have 100,000 routes
and they also don't know where A lives,
well, then how does it get to the other side?
Well, then that's where the concept
of a tunnel comes into play.
And so LISP has two planes of operation.
We have the control plane.
We also have a data plane of operation here.
And this tunnel mechanism is going to be established
to the remote device that hosts A WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the remote device that hosts A
or at least has a path to A.
And so these devices in the middle,
they're part of the underlay
and what does the underlay have to know?
The underlay just has to know how to get
to the tunnel destinations.
And so instead of 100,000 routes,
maybe it has 100 routes or 1,000 routes,
something very manageable.
And so I don't have to worry about them needing
to look at destination A.
They look at the outer IP header.
And because of LISP, we now have this underlay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And because of LISP, we now have this underlay
that manages far fewer routes
and now we can have much smaller routers in the middle
that are very quickly forwarding traffic,
which is the goal of LISP.
All right, question number two.
So why isn't the LISP tunneling mechanism used in Cisco SDA?
As we mentioned there, SDA,
or as we have mentioned many times, SDA or SD access,
this is going to use LISP for the control plane mechanism, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is going to use LISP for the control plane mechanism,
but LISP at the data plane, we're not going to use this.
We love the pole methodology
and we want to use the pole methodology
throughout our SDA campus fabric.
So why aren't we using the data plane of LISP?
Well, the reason for that is because
the tunnels are layer three baits.
And if I'm going to communicate between two access closets,
so access closet one and access closet two,
if I'm going to make them layer three segmented, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if I'm going to make them layer three segmented,
then I could just do that with a layer three access topology.
I don't require SD access in order to do that.
What I'm trying to do is make it
so that we have layer two everywhere.
And with an SDA fabric, I can accomplish that,
but not with the LISP data plane.
Instead, I'm going to need something layer two driven.
This is layer three driven.
I need a layer two tunneling mechanism
in order to get from access closet one to access closet two, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in order to get from access closet one to access closet two,
and that is going to be where I use VXLAN.
So SD access is a combination of LISP at the control plane,
VXLAN at the data plane,
and let's not forget Cisco trussec at the policy plane.
All right, next question.
Identify each of the LISP roles
that match to the following descriptions.
So we've got a lot of LISP roles.
We should absolutely have a sense
of which type of device is doing what
inside of the LISP framework.
So number one here, forming the LISP tunnels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So number one here, forming the LISP tunnels.
Well, that would be that edge device
going to the other edge device and forming this tunnel,
and it's not talking about
the different underlay devices in here.
So when we're talking about this,
these are known as,
which sometimes referred to as an XTR,
but specifically it would be an egress tunneling router
or an ingress tunneling router.
The reason why we say XTR here
is because if traffic is flowing this way,
this would be the ingress tunneling router,
and the other side would be the egress tunneling router.
But naturally, if the packet's going the other way, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But naturally, if the packet's going the other way,
then we have to flip those roles,
which isn't the most,
it creates a little bit of inconsistency,
sometimes not the most convenient thing,
but at the same time,
that's why we have a term here we can use the XTR.
Now, next, the IP address of the host or subnet,
this is known as an endpoint identifier or an EID.
And keep in mind that this device over here at the far end
is going to have a destination
or really an identity point that we know the EID WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or really an identity point that we know the EID
it belongs to.
I've got an EID out here, for example,
and that's going to be known as the routing locator
or the R-lock.
So the concept of splitting off the routing locator
from the endpoint identifier,
this is where this locator ID separation,
the LIS of Lisp, that's where that comes from,
is now I'm no longer routing towards the endpoint identifier,
I'm really routing towards the R-lock.
Now, what receives registration?
I will say these two right here,
this is going to be what trips us up the most, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is going to be what trips us up the most,
receiving registrations for new networks,
this is known as the map server,
whereas receiving the pull requests, essentially,
to find out, hey, where in the world
are these endpoint identifiers,
this is the responsibility of the map resolver.
In a lot of situations, especially small deployments,
and yes, in SDXs, these two devices get combined into one,
in fact, an SDXs, this gets combined
into the control plane node,
and we just have a single device doing both operations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and we just have a single device doing both operations.
But in large Lisp deployments,
these get deployed as individual devices.
For the sake of scaling out,
we might see many of these devices,
but ultimately we should try to keep track
of which device is responsible for which operation.
Lastly, sharing routes with non- Lisp networks,
that would be the responsibility of the proxy,
ITR or ETR, and so, as with all things,
not everybody in the world is using Lisp, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
not everybody in the world is using Lisp,
and so we've got this whole Lisp domain
that consists of the underlay and edge devices here
that have all kinds of networks that are hanging off of them,
but eventually we might have to go out of the Lisp domain,
and so that would be a device that sits here,
known as the proxy, again, ETR, ITR, XTR,
whatever we wanna call it.
So the proxy XTR here is going to be responsible
not only for advertising our Lisp routes
into the rest of the world,
'cause we do have to convert back to a push mindset, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
'cause we do have to convert back to a push mindset,
so I'm gonna have to push those routes out of the Lisp world,
and then I have to worry about bringing traffic in
and sending traffic out, and again,
into and out of the Lisp domain.
So that is how the Lisp roles come together.
Let's make sure we have a sense of what all of these roles
and responsibilities are and how it all comes together.
Question number four, how many bytes of overhead are added
when using VX land to carry layer two frames?
Well, the best way to figure this out
is to really again map everything out here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is to really again map everything out here,
and what we find is that we have our 1,500 potentially,
the max payload for standard frames, 1,500 bytes,
that doesn't include the Ethernet header here.
And so our Ethernet header is going to be an extra 14 bytes,
and then we have to have a VX land header in here,
and that is only eight bytes.
Then we place this into UDP, which is another eight bytes,
and then of course we need an outer IP header, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then of course we need an outer IP header,
and so that's going to be 20 bytes.
Now again, Ethernet, yeah, we do have another Ethernet header
to add on here in the FCS at the end,
but these don't count towards layer two MTU.
The fact that we have an Ethernet header inside,
though that does count because now it's part
of the overall payload.
So how much do we have to worry about here?
Well, you know, this is 16 plus 14 is 30 plus 20, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, you know, this is 16 plus 14 is 30 plus 20,
that would be 50 bytes.
With a slight caveat that if we want to include
the plus four bytes for our VLAN tags,
then we would have to consider this as a 54 byte increase.
But this is typically not used.
We typically don't worry about this
because we don't usually need to carry the VLAN ID,
and nor do we want to, as we talked about quite a bit,
but at the same time, just be aware it's either 50 or 54 bytes,
depending on when, whether we are carrying the tag. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
depending on when, whether we are carrying the tag.
Next question, what is the glue that connects layer two domains
between V-tips and how many identifiers can be used?
There's a lot to unpack with this question,
to make sure we understand the concepts here.
So VXLAN is going to form a tunnel
from one device to another,
and these devices have names,
they are known as VXLAN tunnel endpoints
or virtual tunnel endpoints,
that would be the V-type concept.
So we're talking about multiple V-tips
and forming a VXLAN tunnel between them. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and forming a VXLAN tunnel between them.
Now, typically what happens here is we extend this down
into a layer two domain,
and so maybe this is 10.100.0/24,
and so we have a host here, that's .1,
we have a host over here, that's .2.
That's part of the same broadcast domain,
and VXLAN is the reason for that
because it carries layer two,
and so we can use that dotted line
to show that yes, .1 and .2
are both part of the same layer two domain, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
are both part of the same layer two domain,
even though this whole world up here is layer three.
VXLAN is tunneling layer two through that.
So let's go back to the question here,
what's the glue that connects the two domains?
Technically we could say VXLAN,
but really what we're looking for here
is that virtual network identifier,
which is usually referred to as a VNI or possibly a VNI.
So the VNI is an identifier,
and importantly it's a 24-bit identifier.
So 24-bits gives us a whole lot of values, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So 24-bits gives us a whole lot of values,
supports up to 16.7 million different identifiers,
that's two to the 24th power,
and we no longer need to worry now
about running out of VLANs in our space
because now we can support 4,000 VLANs here,
we can support 4,000 VLANs here,
and I can even glue together VLAN 101 with VLAN 511
if I so desire.
It basically means that VLAN IDs are now local concepts. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It basically means that VLAN IDs are now local concepts.
So the VNI, this is what is globally significant.
I can't repeat the use of the VNI
because if I do then our switches are going to get confused,
but because again, in theory,
I'm not carrying the VLAN tag here.
In fact, I'm not carrying the VLAN tag
means that as long as a packet comes in on VLAN 101,
I strip off 101, I just send that packet across
with this VNI, this switch receives it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with this VNI, this switch receives it
and knows to send it out VLAN 511,
that's why we can get away with this.
And again, the VNI is the glue that holds it all together.
Question number six,
how does VXLAN natively perform learning
for remote endpoints and how does it perform learning
in Cisco SD Access?
So how do we go about learning things with VXLAN?
VXLAN is a data plane only protocol.
What this means is that it doesn't have a mechanism WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What this means is that it doesn't have a mechanism
for sharing, learning and different identifiers.
So the concept of proactively learning requires
a control plane where we share something with each other,
share routes, share MAC addresses, it doesn't matter.
There's sharing is going to require control plane operation
and we just set its data plane only.
So it can't proactively learn, but it can reactively learn. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it can't proactively learn, but it can reactively learn.
And so the way we reactively learn
is to rely on flood and learn.
It's exactly how we learn at layer two.
So it fits well with VXLAN, which is a layer two concept.
So I'm going to have VXLAN tunnels
to all these other devices here, or these other V-tips.
And when I receive a packet of the destination I don't know,
I'm going to have to flood this out.
And because this is a layer three domain in here,
I flood it out using multicast. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I flood it out using multicast.
So I multicast it, I send it out to all of these other V-tips,
one of them, well, actually all of them
are going to forward it out all of their ports
because it becomes a broadcast at that point.
Now one of them actually has the host attached.
And so hopefully we receive a packet back.
And because we receive the packet back, now we can learn,
hey, next time I get a packet in,
I'm just going to send it directly to this other switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm just going to send it directly to this other switch.
So VXLAN does figure it out eventually,
and it figures it out thanks to flooding and learning.
But it does not proactively share information.
Now does this work?
Of course, is it efficient?
Of course not.
And so we'd really rather be efficient
and establish something at the control plane.
VXLAN supports many options.
It supports multi protocol BGP.
Cisco ACI uses that console of Oracle protocol or Koop.
And then importantly in SDA,
this is where we're going to use Lisp. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is where we're going to use Lisp.
Lisp at the control plane.
We don't use Lisp at the data plane.
We use VXLAN, but VXLAN doesn't have a control plane,
so we need one, and so we use Lisp,
and it all works out really well in the end.
So that is how we perform not only native learning,
but also how we perform proactive learning
in software defined access.
All right, question number seven, the last one.
Match the Lisp roles with the SD access node types. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Match the Lisp roles with the SD access node types.
So remember, software defined access, it's using Lisp,
but it's going to use its own terms.
It doesn't want to use Lisp terms.
That's more of a service provider concept.
Instead, Cisco developed a bunch of SDA terms,
and we're going to use those,
even though they're really code
for what we're running underneath.
And what we're running underneath
is indeed Lisp and VXLAN.
So the control plane node.
From a Lisp perspective, this is going to run that MSMR,
the map server, map resolver here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the map server, map resolver here.
The MSMR is going to run on the same device
like we indicated,
and it's going to run on the control plane node.
All my fabric edge nodes here,
these are going to be the XTRs,
and when the, I'll just say XTR,
when the fabric edge node receives a packet,
it's going to pull the as needed route down
to the endpoint identifier,
and it's going to form a tunnel
across to the other fabric edge node.
The fabric border node is going to be the proxy XTR. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The fabric border node is going to be the proxy XTR.
It's going to serve the device that again,
advertises, pushes the Lisp routes,
in our case the SDA routes,
out of the SDA environment,
it also handles traffic into and out of SDA.
So that brings us to the end of our review
on virtualization technologies.
Again, the quizzes and the challenges were designed
to make it so that we could maybe remember certain details
about how all of this comes together.
But when it's time to review how to do the configuration WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But when it's time to review how to do the configuration
for a GRE or IPSec and recursive routing,
then be sure to go back to those individual skills
and perform the lab in those skills.
We can do it now or do it at the end of the course,
but either way it's going to be very important
that we take some amount of time
to review the configuration of those technologies as well.
I hope this has been informative for you,
and I'd like to thank you for viewing.