So now that we've had the opportunity to learn about LISP and learn about VXLAN,
let's go ahead and talk about SD-Access. So what is SD-Access? It refers to
software-defined access and it's Cisco's implementation of software-defined
networking. And so there's a lot of aspects that go along with that, but one
of the things is is that using SD-Access and setting up the SD-Access
environment is going to require what? It's going to require LISP. It's going to
require VXLAN. It's going to require Identity Services Engine. It's going to
require DNA Center. So someone asked a while ago about where DNA Center fits
into it. Well, DNA Center is going to be your management, monitoring, maintaining
system for configuration, verification, troubleshooting of the entire environment.
Okay. So if we remind ourselves how traditional networking is designed,
we've got our Layer 2 and our Layer 3 boundaries. And we already talked about
the issues today. Biggest issues we run into is that users are bound to their
physical location because their location is based on their network ID.
And as such, their security is based on their network ID as well. And therefore,
security is bound to that location. So if users move, then we have problems. If
cybercriminals get into the environment, well, then it's possible they can infect
that entire environment, that entire section, that entire Sun and VLAN
broadcasting. And potentially move laterally if they find weaknesses in our controls,
our policies that we are managing on a device-by-device basis at the distribution layer.
So SD-AXIS changes all of that. Because with SD-AXIS now, we have the ability to have
centralized management and control, centralized policy and security. And we have the ability to
have flexibility. We have the ability to have scalability. We have the ability to
use something like TrustSec now to ensure that no matter who you are, where you are,
what you are doing, you are going to be bound by security policies that are designed for you
and what it is you do, depending on what device you're using on top of that.
So just like we talked about with LISP, just like we talked about with VXLAN, we are going to have
to move our Layer 2, Layer 3 boundary for SD-AXIS down here. That's why we had that discussion when
we were talking about LISP. So yes, everybody is. And this is the best way to implement it.
You don't have to. Could you leave the Layer 2, Layer 3 boundary like this if you wanted to? Sure,
you could. But you're not going to get the true results that you want to get out of something
like this. So it requires a little bit of an underlying network design change. So
replacing those AXIS layer switches with multi-layer switches at the AXIS layer.
And then having everybody directly connected to their default gateways. And now you can get rid
of spanning tree protocol in this part of your environment. And you're doing routing. Routing
right down to the AXIS layer. So your Layer 3 environment is bigger now. And you're routing
from all these different endpoints in that fabric that you have set up. So we don't need first
operating protocols. We don't need trunks. We don't need spanning tree protocol. There's a lot
of services here now we can eliminate. And then we can implement Layer 3 Ether channel bundles,
Layer 3 Ether channel bundles, Layer 3 Ether, Layer 3 Ether, all throughout those environments
because these are all routed ports. We're routing. We're running OSPF, EIGRP, or ISPS.
And we get a much better network when it's all said and done. One that can converge faster
because spanning tree isn't okay. It's not that great even if you're running multiple spanning
tree protocol or a rapid spanning tree protocol, right? And we can't utilize all our links as
efficiently as we could with routing. So a lot better in this case. And we're directly connected
to our default gateways as well. So let's talk about the AXIS layers here that we have for SD
access. So you've got the concept of the underlay and you've got the concept of the overlay. You
really need to ensure you understand these for the certification exam. So what is the underlay?
That is your physical network. So if we looked at this right now, as is, we would say this is our
underlay. This is our physical network. This is how everybody is connected together. That essentially
is your underlay. So your underlay is dedicated to the physical devices and ultimately the
forwarding of traffic. So your underlay is made up of your routers, your switches,
and a lot of other different devices, services, and features and routing protocols
that are going to be utilized in order to move traffic from point A to point B.
It's going to be simple. It's going to be scalable. It's going to be resilient.
And it's going to be the foundation for all communication between all devices in the
environment. So building the solid underlay is your primary concern when developing SD access.
So what does that mean? Making sure that all of these routers, for example, let's say we're
running OSPF, OSPF, OSPF, OSPF, OSPF, OSPF, OSPF, and they can all reach each other. But let's not
forget here, we are not going to be running OSPF on any of these end user networks anymore. We're
not going to be running OSPF on any of these end user networks. So remember in our OSPF discussion,
I said, do we have to enable OSPF on the SVIs? And we're like, yeah, we have to, we have to. Yes,
of course, because we want the other routers to know how to get there. Okay, well, in SD access,
the answer is no. Oh, yeah. And it goes back to what we talked about during LISP.
I am no longer routing to the destination networks, right? I'm routing to the
RLOC of that LISP router, or we're routing to the VTEP of the VXLAN tunnel.
Same thing, same device. So the LISP ITR ETR with its RLOC is the same thing as the VTEP device
using the IP address of the RLOC. So in the end, right, that's what we're routing. We're
running from there to there. So when you think about the underlay now, the underlay is really
what? From a routing standpoint, we're just routing in this environment. And then if we
want to leave that environment, then we're going to what? We're going to those non-LISP sites,
remember, through our PETRs and our PITRs, which would be right there as an example, all right?
So just keep that in mind. That's your underlay. That has to be built properly first, or the rest
doesn't matter. It's not going to work. So then you have your overlay that you are going to build,
and you can have more than one overlay. Let's be clear about that because the overlay is going to
be the virtualized environments that you build on top of the physical underlay. So for example,
remember we had a discussion on VRFs. When we had our discussion on VRFs,
we said that we could have our physical routers now compartmentalized or isolated into different
routers, and each of those routers would be responsible for something specific. So for
example, you are creating a virtualized environment. So would we still use potentially VRFs
here in our overlays? Absolutely. So that way there, we can have virtualized routed environments
on top of already our physical environment if that's what we needed to accomplish.
And in the end, if you look at the diagram that we have here underneath,
you'll see that this router is the same as this one in the virtualized environment.
This one is the same as this one in the virtualized environment, and this one is this
one in the virtualized environment. Why? Because they are participating in the virtualized environment.
Notice these ones are not. So if we go back to here just to kind of get a better representation
of it from this perspective, these routers would not be part of the virtualized environment. We
would not see them in the virtualized environment. What do we see? We see these in the virtualized
environment, and that's what that diagram is showing to you. So in the virtualized environment,
I have my VTEP, and it knows that a VTEP is over here. Well, if I want to go from here to here,
I have to go from this VTEP to this VTEP, this RLOC to that RLOC. And so the virtualized
environments can be anything I want to make them to be when it's all said and done.
And so by controlling that virtualized environment now, folks, does that mean that we can actually
build different types of secure networks on top of the physical network and therefore really
isolate and control our traffic in a more virtualized way than ever before and compartmentalize
traffic in a virtualized way? Absolutely. Absolutely. So this allows you to break free
of the handcuffs that have been put on you as networking and security professionals
because of relying on the physical network controlling what you can do.
We are now abstracting the real network from the physical network. The real network is the overlay,
the virtualization. We call it the fabric. So the fabric is the term that goes along with the
overlay. Remember that. And that fabrics or fabrics that we create gives us the isolation
for all of those virtual networks that we want to have and keep those all independent
of the underlying physical network. So again, no matter where you are,
your identity does not change and therefore the policies applied can follow you everywhere
and the network can dynamically adjust depending on where people are when they are there.
I'll give you another example of an overlay network that we've already talked about.
GRE tunnels. That's an overlay network. Think about it. The internet is the underlay.
The GRE tunnel is your overlay. So this is not a foreign concept to you, folks.
You've already seen the concept as overlays and underlays. GRE is a good example. An IPsec site
to site VPN tunnel, underlay and overlay. The internet is the underlay and your IPsec tunnel
is the overlay. So technically speaking, can we say that 802.1Q trunking is a type of overlay?
What would you say? 802.1Q trunking, is that a type of overlay? Seems like it, right? Exactly.
So this is not a new concept for any of you because everything you've already done that
had some type of tagging, encapsulation, virtualization, you are just building overlays
on top of a physical network. But now we're getting even crazier with these overlay networks
where we're having a true separation between the physical side of things
and the virtual side of things. Now, the fabric. We have the fabric data plane. We have the fabric
control plane. We have the fabric policy plane. What's behind door number one? I want you all
to guess right now. You actually know the answer to this because I mentioned it before.
What do you think we use as the protocol or the solution or the service in the data plane? Chat
in your answer. Take a guess if you don't know. VXLAN is the correct answer. Remember the fabric
data plane. Now, Jeffrey, you said ISIS. ISIS would be used where? In the underlay. OSPF would
be used in the underlay. The IGRP would be used in the underlay as an example. But remember,
the term fabric goes with overlay. And so, therefore, fabric data plane would be one of our
overlay technologies. And that overlay technology is what? Is VXLAN in this case, right? So,
Jeffrey, I'm really, really glad you typed in ISIS because I was able to say what I said.
Because I wouldn't have said that if you hadn't typed that in. So, this is really good. This
helps everybody out because that is such an important concept for the exam. The concept
of fabric. When we say fabric, we're talking about the overlay. So, what's in the overlay
versus the underlay? So, thank you so much for answering that way. I know you did it on purpose
just so I could do what I needed to do. Appreciate it. So, fabric data plane used for forwarding,
right? Forwarding from here to here, from here to here. So, we say VXLAN, why? We have our what?
We have our VTEPs as an example in our data plane. VTEP, VXLAN,
encapsulating our packets. So, we can go from point A to point B over top, over top of what?
Over top of the underlay. So, we have VXLAN with what? GPO. So, what does GPO mean? It stands for
Group Policy Extensions. So, why do we have VXLAN with GPO? Because traditional VXLAN doesn't
support something that we need here with SD Access. And you know what that thing is that
we need to support? Security Group Tags, which are part of what? TrustSec. So, that's why we
have our VXLAN with Group Policy Extensions. Group Policy Extensions allows us to add more fields
to the virtual network identifiers. So, that way there, we can add in our security group tags and
other things that are allowed with the Group Policy Extensions. But the most important thing
there for you to recognize is with Group Policy Extensions, we can support what? TrustSec and
security group tags that go along with TrustSec. Okay. So, that is our fabric data plane,
VXLAN with GPO, encapsulating packets, point A to point B. Got to know that.
What about our control plane? Right. So, our control plane is going to be LISP.
LISP. Now, what is the control plane, right, that we're using in our
control plane that we're going to go ahead and use in our underlay, right? We're still using
EIGRP, OSPF, BGP for the routing process and stuff like that. Well,
in the control plane for the fabric, we got LISP that we're using.
So, used for building the tables needed by the data plane, mapping and resolving users and
devices, creating using LISP. So, we talked about before that LISP is both control plane and data
plane. That is true, but not for SD-Access. For SD-Access, we're only using the control plane
part of it. So, encapsulation is done by VXLAN, whereas the decision-making process of
what VTEP we need to go to based on what? A database of information on the mapping server
will ultimately be used to tell VXLAN what it needs to do to encapsulate.
So, the decisions that are made by LISP are then used by VXLAN to do the encapsulation.
So, that's what we mean by control plane in that case. So, LISP is going to be used for what?
Mapping and resolving endpoints. VXLAN is going to be used for building the tunnels,
encapsulating the traffic. And in actual fabric policy plane, you've seen this word already today,
TRUSTSEC. Security group tags and group-based policies are used to translate the business
intent into the network policies. So, we use TRUSTSEC and Identity Services Engine to accomplish
that. And remember earlier I said that in your SD-Access environment, especially when traffic is
flowing from devices to other devices, like maybe users to servers within your fabric,
within your organization, then if all of your equipment supports larger MTU sizes,
the recommended MTU size for SD-Access is 9100, not 1500. So, that means you can configure every
single interface on your SD-Access supported devices to an MTU of 9100 and even have your
end stations build packets that are 9100 in size, maximum 9100 in size.
Give or take, all right? Give or take. Because if you exceeded 9100, you got to do fragmentation,
which is not allowed anyways. We wouldn't want fragmentation anyways. So, we want the packets
built the right size, but it gives you the opportunity, right, to do all that encapsulation
you need without having to worry then in that particular case. But always remember that
having an MTU of 9100 only works if all devices from PC to server support it. Because if there's
one link along that entire path that's 1500, then it breaks down. You can't do it.
So, that's why a lot of people talk about, especially in my CCNA class, they bring up,
oh, MTU of 9100, right? We can totally go ahead and do that. It's like, well, no, wait.
If your users are going to the internet to do things, the internet's using 1500, not 9100. So,
you can't do that in your environment. If your traffic leaves, you got to do 1500 or less for
traffic that's leaving in your environment. Until the entire internet goes to 9100 and everyone
supports 9100, we can't do it. So, for traffic internally, 9100, no problem. But you still have
to deal with the fact that any traffic that's leaving the environment, leaving your fabric,
going somewhere else that doesn't support it, you're going to have to handle that differently
and make sure that you're not transmitting anything greater than what the maximum transmission
size would be if somebody went to the internet, like 1500. All right. So, now we have to play a
game of who's who. Any one of these can show up on your certification exam. It's a long list of
things you need to know for SD access. But good news is that you have to know basically what that
is and what it does. That's it. What it is, what it does at a very, very high level.
So, the idea here is for you to get the main key points for me about each and every single one of
these. This is Cisco's official diagram. I don't really like it. I don't. So, I've taken this exact
same information and I put it on ours. Because I really like how this is, because this is more
realistic when I look at this than when I look at it this way. So, let's go ahead and do this.
All right. We're going to take our time here. This one, start off with this one here.
You know, if I star it, folks, if I star it and I leave it starred,
take that as a hint.
That's all I can tell you. Can't say any more without getting in trouble.
Endpoints. I really don't have to say a whole lot about this, do I?
Endpoint is what? An end user device. Any type of end user device.
Or an internet of thing device. Or any device that sends and receives traffic as an end point.
That's your end user device. Inside of what? Inside of your fabric. So, a PC, in this case,
is my end user device. A phone could be my end user. A camera could be my end user device.
A camera could be my end user device. End point, I should say. Not end point.
Printers, end points. Servers, end points. If the server is inside your fabric. In this case,
my servers are outside of my fabric. Let's keep that in mind. My servers are in a different
fabric. They're in the ACI, the application centric infrastructure, instead of my SD access
fabric. They're in a different fabric. So, this would be my data center fabric over here. We call
ACI. This over here is my SD access fabric. Any device sending or receiving traffic.
A fabric edge node. Fabric edge node. Let me write out here what a fabric edge node is. Fabric
edge node. There it is. This would be a device that is physically in our underlay,
but it actually participates in the overlay as well. It can be an access layer device or a
distribution layer device, depending on where your layer two layer boundary is. In this case,
our layer two boundary is here. Layer two, three boundaries here. So, it is my access layer device
that is my fabric edge node, which is the recommended best practice.
And the fabric edge node is responsible for connecting your wired and wireless end points
to the SD access fabric and forwarding their traffic.
So, what does a fabric edge node do? Connect your end points to the SD access fabric.
So, in the world of Lisp, folks, what do we call the fabric edge node in the world of Lisp?
We call it an XTR. Right? So, it can be an ITR or an ETR, exactly. What do we call it in, oh,
and sorry, and John, what does the EXTR in the, or what does the XTR have? That's right.
You chatted it in. It has an RLOC. That's what it has. Perfect. I'm glad you're recognizing that.
Wonderful. And in the world of VXLAN, what do we call this, folks?
Three different names for the exact same thing.
What does a fabric edge node do? Everything the XTR does and everything the VTEP does.
That's your fabric edge node. And it ultimately connects the wired and wireless end points to the
SD access fabric and forwards their traffic by doing what? Encapsulation and decapsulation.
The fabric edge node is therefore your default gateway. So, you are essentially directly
connected to your default gateway, meaning you do not need a first competency protocol here.
In addition to that, folks, this is where things get awesome. This is like some mind-warping
technology. It is actually what we call an Anycast Layer 3 gateway as well. What does that mean?
It means that we can have a common gateway IP address and MAC address for every single one of
these. But when your device, for example, somebody, let's say this is your home network.
If this is your home network and you move down here and you connect down here, you're no longer
in your home network. You still need a default gateway for your subnet down here, don't you?
You do. Because if you're still 10.0.0.10 down here, and this is the 10.0.0.0 slash 24 network
up here, and this network down here is 10.0.0. It's a totally different network. How does this device,
how in the world does this device be your default gateway? It can dynamically configure itself
with an IP address to be used as your default gateway. Wow. Yeah.
So, that gateway address is instantiated as a switched virtual interface
with an IP address and a MAC address that can be utilized when needed. And then when nobody's there
that needs it, it gets torn down. Built as needed. That's incredible. That is some good stuff.
I get pretty excited here and use non-work safe words. I got to be careful.
All right. So, you've got the idea of that. You actually know more than you need to know right now.
In regards to this stuff. So, that's good. That's good. I like to give people more because then they
really start to understand what's going on here. Okay. So, now let's talk about our fabric
intermediate node. So, the fabric intermediate node. Let's talk about this one next. I'll put
the one I'm talking about. I'll go ahead and put an arrow beside it. And then I'll erase
it when I'm done talking about it. If I put a star, make sure you remember it.
Okay. So, what's a fabric intermediate node? So, this is an example of a fabric intermediate node.
This is an example of a fabric intermediate node. This is an example of a fabric intermediate node.
All right. So, this would be an example of a fabric edge node. Let's put that down there as
well. Fabric edge node. Intermediate, intermediate, intermediate edge. So,
what is a fabric intermediate node? It is a 100% purely underlay device. Meaning, it is not
actually participating in the fabric. It's not participating in the fabric. So, for example,
is this running LISP? Nope. Is it running VXLAN? Nope. Nope. Nope. But what is it running? Yeah,
maybe OSPF, ISIS, or EIGRP, right? So, your fabric edge node would be running LISP, VXLAN,
and your dynamic routing protocol. Whereas these ones only need to run your dynamic routing
protocol. That's it. This one would be running your dynamic routing protocol plus LISP and VXLAN.
Fabric border node.
Fabric border node is, again, part of your underlay. Obviously, all of these devices are part
of our underlay. But it is participating in the overlay as well. And what it does is it connects
your fabric to places outside of your fabric. So, it connects your fabric to non-fabric sites.
So, this would be a non-fabric site. This would be a non-fabric site.
So, this would be a fabric border node as an example. This would be a fabric border node as
an example. Let's get that B better. Fabric border node. There we go. So, just out of curiosity,
folks, in the world of LISP, what do we call a fabric border node?
A peter and a piter. That's right. A PXTR. Wonderful. Wonderful. Good job. And in the world
of VXLAN, okay, so we'd have an RLOC for that as well. Remember, RLOCs for that as well. And then,
in the world of VXLAN, what do you think we call the fabric border node in the world of VXLAN?
Anybody want to take a guess? Take a guess. If you don't know, take a guess. Type something in.
It's the VTAP. That's it. It's just a VTAP. It's a virtual tunnel endpoint. That's it.
So, in the world of VXLAN, it's still called a VTAP, right? So, in the world of SDAccess,
we got fabric border node, fabric edge node. We called XTRs and PXTRs in the world of
LISP and VTAPs in the world of VXLAN. I know. So confusing, isn't it? But this is what I'm
trying to help you. I'm trying to help you get the confusion out of you by diagramming it this way.
I was never taught this way, and it took me so long to grasp this stuff because I went through
so many official Cisco papers, documents, videos, and it was like, I don't get it.
Then you start diagramming it out, and you're like, oh, that's all that's going on here. It's
the same names for the same things, just trying to add massive confusion. If you can get around
the confusion, it's actually pretty simple when it's all said and done. But it takes time. It
took me a while, right? And once I got through it, I'm like, okay, I get it.
All right. Fabric control plane node. Fabric control plane node. Control plane node. Oh,
sounds to me like a server of some type. So, it could be. It could be, for example,
a server we have set up in our data center, maybe. That would be our fabric control plane node,
or it could even be, for example, something in here. So, it doesn't even have to be like a
fabric edge node or a fabric border node. It doesn't even have to be running like Lisp,
for example, per se, like our fabric edge nodes do, our fabric border nodes. But if we make it
our fabric control plane node, then it's going to what? Run Lisp. But what's it going to become?
What's it going to become in the world of Lisp? Mapping server, mapping resolver. That's right.
Mapping server, mapping resolver. Good job, Conrad. There you go. So,
a fabric control plane node is what? It's a mapping system that manages the endpoint
IDs to device relationships and stores information in a centralized local database.
Any device in your fabric, you can make it that. Could be even a device outside your fabric.
Right, but if it's outside your fabric, you'd have to leak routes and do route leaking and
different things like that to accomplish your objective. But that's okay. That's okay.
Okay, the purpose, what? Learn where everyone lives. So, that way, the edge devices can figure
out where to send the data they're trying to forge. So, whether it's a fabric border node
or a fabric edge node, they need to contact what? The fabric control plane node,
which RLOC to send the traffic to. Which RLOC to send the traffic to. So,
that goes back to our Lisp discussion. So, we call it the fabric control plane node here.
We call it the mapping server, the map resolver in the world of Lisp. Same thing.
Fabric wireless LAN controller.
A fabric wireless LAN controller would be what? A wireless LAN controller that is fabric-enabled
and therefore, is part of your physical underlay, but it has the ability to manage the fabric-enabled
access points that you have. So, that's what a fabric wireless LAN controller would be.
It has the ability to manage the fabric-enabled access points that you have. The fabric-enabled
access points. So, you would need fabric-enabled access points, and then you have a fabric-enabled
wireless LAN controller, and that fabric-enabled wireless LAN controller has the ability to do
what? That's so important. Forward client registrations and all roaming information
to who? To the fabric control plane node. And it would also be responsible for the radio
resource management of all those fabric-enabled access points. So, that fabric wireless LAN
controller, right, has an extra job compared to what? A non-fabric-enabled wireless LAN
controller. And what's its extra job? Remember this. Update the fabric control plane node where
all those wireless devices happen to be connected to. So, just like the cellular network. If you
hop from what? Access point to access point to access point, something needs to update the
controller about the fact that you keep moving from what? From tower to tower to tower to tower
to tower. Same idea, right? So, in this case, the access points tell the wireless LAN controller,
and the wireless LAN controller tells our fabric control plane node.
And then you got your fabric access points. So, as we said, our fabric access points,
right, these are wireless access points that are fabric-enabled. They're part of the overlay.
They connect wireless clients to the fabric.
Specifically, our fabric-enabled SSIDs.
They have the ability to update who? The wireless LAN controller. So,
whether the wireless LAN controller can update the fabric control plane node.
And they have the ability to encapsulate our user's traffic into what? VXLAN.
And there's one thing I want you to realize.
This is from a document, a Cisco document. I'm just going to state it.
You don't have to go read the document, but it's on wireless SD access document. It's pretty big,
but the end thing is this, and it's just like a little sub-note I just want to share with you.
When you're dealing with fabric access points, access points are placed in what we call
local mode. Access points are placed in what we call local mode and must connect directly
to the fabric edge node, our fabric edge switch.
So, like you see here, there's my access point directly connected to my fabric edge node.
And what do we place the access point in? Local mode. That might be beneficial to your future.
But I don't want you to go out there and read an entire document on setting up access points for
SD access fabric just for one sentence, okay?
Access points are placed in local mode and must connect directly to the fabric edge switch.
Do the fabric access points do both VXLAN and CAPWAP?
So, yeah, we still have to understand we need our proper tunneling. So, remember CAPWAP is control,
VXLAN is data, right? Think about that. Yeah, CAPWAP is control, VXLAN is data.
Yeah, yeah. Okay, you figured that out even before I answered it. You're like,
yeah, never mind. Forget it. Perfect. Thanks, Conrad. But, you know, great question, right?
Because maybe you're not the only one who's thinking that way, right? Yeah, it's true.
Like, what about everything else? Well, again, control plane versus data plane, right? Absolutely.
Woo, DNA Center. Hey, somebody was asking about DNA Center. Hey,
where does DNA Center fit in all this? There it is. It's part of SD access.
So, DNA Center, that's what that symbol is right there, DNA Center.
So, what is DNA Center in the world of SD access? So, DNA Center is your centralized
command and control option for management, administration, automation, programmability,
monitoring, assurance, workflows, you name it. Like, everything. Everything.
And we're not going to cover DNA Center here live. We don't. But in your videos, I do have
a discussion on DNA Center to get you ready for the certification exam. It's about 34 minutes long.
So, you don't learn about DNA Center in this course, except for an overview.
There are courses and exams designed for that. That's not what I wanted. Wrong button. Right?
So, we're not going to cover that here. But what I want you to remember is,
if any questions about DNA Center come up, always remember, DNA Center is your centralized command
and control center for what? Things like management, administration, automation,
programmability, monitoring, assurance, workflows, all of that, and a whole lot more.
The great thing, though, is that if DNA Center ever loses connectivity to your fabric,
the devices are still able to connect and use the fabric. Let me repeat that. If DNA Center
ever loses connectivity, devices are still able to connect and use the fabric. But one of the
things you will lose in that case are things like your analytical data and assurance.
So, if DNA Center is down, you're going to lose the analytical data and assurance data at that
point in time. Like, I mean, you're not going to have the ability to collect that because DNA
Center is not there to do that. But you still have the opportunity, what? Connect to the fabric,
join the fabric, and stuff like that, which is good. That's good. Thank you. Thank goodness Cisco
has designed it that way. All right. Identity Services Engine. We already talked about how
Identity Service Engine plays a role in something like TrustSec. It's required for TrustSec. And
what is Identity Service Engine? It's the authentication, authorization, and accounting
solution. It's your policy enforcer, your security solution for what? Everything in the world of
Cisco, specifically for SD Access. It's your security solution for everything in the world of
Cisco, specifically for SD Access. Whether you're using SD Access or not, folks, you can use
Identity Services Engine. It's a really great product, right? But it's a really great, great
product when you're doing it in SD Access. And it's going to be responsible for what? Dynamic
endpoint to group mappings, policy definitions, Cisco TrustSec. We can integrate it and access it
from DNA Center as well. That's a huge bonus. So, if you're using DNA Center and ICE, we can work
with them together. They provide our security group tags for this environment. Because remember,
when we have TrustSec set up, when you connect to your Fabric Edge node, you get your security
group tag. So, not only are you registered in the fabric, but you get your security group tag
identified. So, that way, you are going to have those policies applied to you through that security
group tag. Fusion Router. What is a Fusion Router?
There are going to be certain services in your environment that need to be shared.
Can anybody give me an example of a service that might be shared by many different users,
by many different sites, by many different parts of your network? Just give me one example
of any type of service that might need to be shared by everyone. Okay, DNS is one. Anybody
got another one? DHCP, another one? Nice, John. I was just thinking of that going,
I wonder if anybody's going to get NTP. NTP, exactly. Yep. What about Identity Services Engine?
Yep. What about DNA Center? Yep. You know, different things like that. Okay. So,
those are typically going to be resources that are where? Outside of the actual fabric. They
might be in a totally different fabric, like in the ACI fabric. So, they are outside of my
SD access fabric. So, it could be ICE, it could be even a wireless LAN controller,
it could be DNA Center. They are outside of my fabric. So, over here, for example, in this
scenario, DHCP, DNS, NTP. So, shared services. So, the thing is, is these shared services are
in a totally different network, right? They're in their own network, they're in their own fabric.
How do we interconnect some sort of isolated network, some sort of isolated fabric with
something else? Well, we know we're going to go through those fabric border nodes now
to go to someplace outside. But the thing is, is that we need to have a router that has the ability
to leak, for example, from one network to another virtualized network. So, if we have ourselves set
up, let's say, with – oh, my gosh, there's that word again. I used it a while ago, and I forgot
why I'm having trouble with that word today.
This is embarrassing. VRFs. VRFs. There we go. VRFs. Gosh. So, let's say you have VRFs.
You have all these different isolated environments with different VRFs.
How are you going to have traffic in this shared environment, which is a different VRF,
be usable in your other VRFs? Fusion router. Fusion router. So, your fusion router is a
router that has the ability to leak traffic from one, for example, VRF, one isolated environment,
one virtual environment to another environment.
Okay. That's what I want you to remember for the exam.
So, in this case, could it be our fabric border node that's also being the fusion router? Yes,
it could be. Same device. And then, lastly, we have what is called an extended node.
So, what is an extended node? So, what is an extended node? So, what is an extended node?
So, what is an extended node? So, it is possible in some scenarios,
you are going to want to extend your fabric beyond, let's say, this device
and connect a non-fabric device to it and have other devices connected to it. So, let's say,
for example, we had a switch connected here, and you have users connected to this switch.
We have extended the fabric, but the problem is that switch might not actually be a fabric-enabled
switch. So, it's a non-fabric layer-2 access switch, as an example, and we've connected a
bunch of devices to it. The thing is, is that we want to be able to
extend out, extend out that fabric down into that non-fabric layer-2 switch. So,
non-fabric layer-2 switch. So, we call the extended node, right, this device that extended
the fabric – or, sorry, extended node. So, this one here, pardon me, would be the extended node
that extends the fabric downstream to that non-fabric layer-2 switch. And how do we do that?
Here's the key word, 802.1Q. So, using 802.1Q tagging, we have the ability to extend
that fabric downstream to that non-fabric layer-2 switch. So, now we have layer-2 port extension
while providing segmentation, group-based policies to the actual endpoints that are
connected to that switch further down. So, we can connect now fabric-mode access points
to that environment as well, to that switch if we had to, and we've been able to extend that down
using 802.1Q to accomplish that. So, by using 802.1Q and putting in the values that are necessary in
that tagging of 802.1Q, we'll be able to do that properly. So, just keep that in mind. Any scenario
that talks about adding a non-fabric layer-2 switch to your fabric, but wanting to extend
the fabric through that non-fabric layer-2 switch, just think extended node as your answer.
That's your goal for the exam. Pick these out of a lineup and knock them out of the park.
All right. One final thing, and that is layer-2 flooding.
Folks, if I'm in a subnet, if I'm in a VLAN, and I'm in a broadcast domain, and I send out
an unknown unicast frame, or I send out a broadcast frame, where does it go? Where does it go?
It goes to everyone in the same subnet, VLAN, and broadcast domain.
So, if I'm here in my site, and let's say this is 10.0.0.0 slash 24. This is VLAN 10.
And there's some user down here. I'll just use this user down here and say you are 10.0.0.9.
Let's say that is the device I want to talk to. Let's say that is the device I want to talk to.
So, I build my package, source IP me, destination IP you. How do I get your IP address? DNS.
DNS. Then I have to build a frame. Source MAC me, destination MAC you.
How do I get your MAC address? We know that if you send out an ARP request,
it only goes to everybody in the same subnet, VLAN, and broadcast domain,
and it will not be forwarded across layer-2 connections.
So, how am I going to get your MAC address? Well, that's where VXLAN
shines as well. So, remember our VTEPS?
All right. We are going to have to make sure that we properly forward all, all
broadcast traffic where it needs to go when it happens, and flood all unknown unicast traffic
where it needs to go, or else it doesn't work. Our communication, it breaks down. So, with VXLAN,
there's a concept of it's called layer-2 flooding. So, with layer-2 flooding within VXLAN,
we can take those unknown unicast messages and those broadcast messages, and we'll be able to
build those VTEP tunnels that are necessary to reach all the nodes in the same subnet,
VLAN, broadcast domain, regardless of where they are. Now, again, you might be saying,
well, how do you figure that out? Well, think about this device here,
would ultimately have to reach out to the control plane node and identify every single device
that would normally be in here, but not,
and figure out where they are. So, if it gets a listing back of this, this, this, this, and this,
let's say there's five devices that are not in their home network, they're elsewhere.
Well, now you know that, okay, there's five, where are they? Let's say two of them are here,
let's say two of them are connected here, and one of them's connected there.
So, that means they're going to have to do a tunnel from here to here for two of them,
a tunnel from here to here for two of them, and a tunnel from here to here for one of them,
and therefore send it out over VXLAN.
And that way there, they all get that ART message.
Okay, but then again, right, if you think about it with even more, right, granular control of all of
this and understanding what happens, if I am really trying to figure out the MAC address of
this exact device, well then what? This device knows who I'm trying to, because it can look
into that message, right? It could look into the message and say, oh, I'm trying to find
10.0.0.9. You reach out to the control plane node and it says 10.0.0.9 is here.
So, then all I have to do is flood it to there and nowhere else, right? So, that previous example I
gave you where it gets flooded everywhere isn't necessarily going to happen. It might be even
better than that, whereby you know exactly, because the ART message has the address.
So, if you know who you're trying to reach, then we might only need one VTEP tunnel. But if you
don't, if it's just a pure broadcast of FFFFF, well then we're going to have to send it to everyone,
no matter what, if we don't know the actual IP. So, for example, when you think about contacting
a DHCP server, source IP, destination IP, they're unknown. Well, in that case,
they're going to have to flood it everywhere in order to accomplish that. Or do I?
No. Why? See, when we think about really how these technologies work,
with DHCP, we got what? We have our helper address. So, if you reach your default gateway,
then your helper address is going to do what for you? Your helper address is going to ultimately
send you to the DHCP server, right? So, you have to really think about it from the perspective of
the technology. Okay, when this happens, what's going to occur in that scenario? Versus when that
happens, what's going to occur in that scenario? And that's really how you're truly going to start
understanding all this stuff. It's by just breaking it down bit by bit, step by step.
Whenever you have a question about it, you're like, hey, what about this? Check it out. We'll
do a little bit of research, find out about it. But know that layer two flooding is going to be
used with VXLAN to ensure that you can get those unknown unicasts or those broadcast messages
to the other parts of the network where those other users might reside that are part of that
same subnet VLAN broadcast domain. That's what you want to take away from that discussion.
How is that for SD access? How many of you are like, wow, that is incredible?
Or wow, I really don't ever want to have to deal with that.
Regardless, though, it's some pretty incredible technology where you think about the number of
people that have come together to ultimately figure out how to get all this to work.
I'm not at that level. I am not at that level to be able to come up with this stuff,
which is beautiful stuff. Yeah, incredible, intimidating, exciting. Conrad, you're right.
All those terms at the same time. So again, let's remind ourselves what we need to know for the
exam. I encourage you to be able to what? Pick terms and definitions out of a lineup
when it comes to SD access. That is your goal.