All right. Let's pause learning new things for just a moment as we step back and review what we've been learning, especially in regards to policy deployment.
So we're going to break this up a little bit. We're going to make sure we understand control policies on their own and the data policies on their own, really see the differences between them.
We're going to do a quiz and a challenge to make sure that we can not only talk about them, but also get in there and do some configuration.
So we're going to do these quizzes in the same fashion that we've done them before. I'm going to read the question.
Feel free to hit the pause button at that point so you can answer the question yourself.
And if you identify any areas of weakness this way, just recognizing that, hey, I couldn't answer that question or I don't really remember that subject very well.
Then note the source at the bottom that will tell us where in the course that we talked about it.
So you can go back and review any information that's necessary.
So we're going to jump right in. This quiz is seven questions. So question number one here.
What is the core function of an SD-WAN control policy?
So the fundamental difference here between a control policy and we're comparing this to a data policy is the fact that control policies impact the control plane.
Very, very important that we recognize the difference here, because when we're looking at traffic flow, traffic flow through an edge, that would be the data plane.
The question is, how does that edge know where to send things?
Well, we're going to receive OMP updates and those are part of the control plane.
So OMP populates the various tables and that tells the edge what to do with that information.
That's important for us to recognize because if, for example, we lose access to the control plane, all these tables should be relatively up to date.
And so we can continue to send traffic at the data plane.
Now, these tables, they are eventually going to start to age and get potentially out of date, especially if routes have changed out on the network.
And so eventually we are going to have to shut down the data plane.
But hopefully it can stay online for a while, especially given that our SD-WAN controller up here, it could go offline for quite a while, depending on what's going on if we're performing upgrades.
And so we want to keep that data flowing for as long as possible.
So that's a little bit more of a breakdown between control and data planes.
But recognizing that our control policies are going to especially be here, influence routing.
So this information that is being shared via OMP from the SD-WAN controller, we can filter that information or possibly just modify and edit it.
And at that point, we can more or less change the way that traffic flows in the environment simply thanks to changing things up at the control plane.
But it doesn't have to do or have anything to do with traffic shaping or security.
That would be traffic flows happening at the data plane, nor does it have anything to do with onboarding or edge devices.
Question number two, which mechanism is used to create groups of interest for control policy creation?
Well, the concept of groups of interest is very, very important when we're defining policies.
That has going to have everything to do with creating these lists.
Now, there's a lot of different lists.
We've got VPN lists and site lists and things like that.
We also have more traditional constructs like our constructs like prefix lists.
We could have TLOC lists.
And so we've got all kinds of different lists that we're going to be able to reference during the creation of our control and, by the way, data policies.
Both of them will use these lists.
We call them groups of interest.
And any time we create a policy, we remember that it's going to take us into the wizard, sort of that step-by-step guide.
And the very first thing we see would be the groups of interest and all of the lists that we can modify and edit there.
We don't have to go into the wizard to do that.
We can use those custom options at the top right to create the list at any time.
But creating these lists and having them at the ready is going to be very important for us as we're creating our different policies.
All right.
Question number three looks like a lot here.
When is a control policy enforced if it gets applied in the inbound direction?
So what we're focusing in on here is the direction concept.
We know that we apply control policies for the most part in inbound or outbound directions.
And the question is, whose perspective are we coming at from?
Yeah.
Whose perspective are we using to define inbound versus outbound?
The answer is that we're going to do everything from the perspective of the controller.
So if I'm receiving routing information via OMP, this is inbound because it's from the controller's perspective.
Meanwhile, if I'm sending OMP updates, this is going to be outbound from the controller.
So when we're looking at the answer choices here, we're not worried about anything that has to do with the edge.
That doesn't have anything to do with our direction.
It's, again, from the perspective of the controller.
Inbound is, again, when data arrives on the controller, not when it's sent out by the controller.
But we do have a bonus question down here, which is, which policy type is applied without a direction?
Well, we're talking about control policies and not applying a direction.
That would be VPN segmentation.
If we're creating a VPN segmentation policy, we don't need to apply that in a direction.
It's simply being pushed out and we're controlling which VPNs are allowed to be in place at the edges.
And, again, that's enforced by managing our OMP updates for those VPNs.
But, yeah, VPN segmentation policies, they do not require a direction.
We are simply applying them and then it will be enforced by the way that we send out our OMP updates.
All right, question number four.
What two pieces of information are filtered by the controller when a topology policy is applied?
So remember what topology policies really are.
It's really just a sort of a templatized version of us deploying custom control policies.
Custom control policies consist internally of route policies and TLOC policies.
So we can control which routes get advertised to certain sites.
We can control which TLOCs get advertised to certain sites.
All of this is fully within the realm of control because we can control what updates are being sent by OMP.
And because of that, I can use a default topology template like a hub and spoke and say,
okay, I'm going to allow maybe these edges to form TLOCs or to form tunnels really to the TLOCs at the hub site but not to other spokes.
And, by the way, that's also going to impact our routing information.
But either way, that would be just us going to the Cisco wizard and saying, yeah, I want to deploy a hub and spoke policy.
But I can do that on my own.
Now, how do I do it with custom control policies?
Well, I can do this by filtering out our routes, which are OMP routes or otherwise known as V routes.
These would be the routes for the subnets that are behind an SD-WAN edge.
Maybe they're directly attached or maybe I learned about them via OSPF or something like that.
But this subnet here, we'll call it subnet A in this diagram.
But these are the types of subnets that I can filter out because what I can do is when it advertises up to the controller,
the controller doesn't have to push it down to the other edges.
Now, in our case, we would push it down to the hub, but we would not push it to, I guess, there are two other sites here.
We wouldn't push it to the other sites.
This is how we create a situation where these edges don't know where that subnet is.
We effectively filtered it out by creating a custom control policy and filtering out individual routes.
We can also filter out T-lock routes or T-locks.
Simply by, again, saying, hey, I've got this T-lock.
I advertise it up and I advertise that T-lock to my hub site up here.
Well, now we're able to form a tunnel between our T-locks.
But because I didn't advertise it to these other edges, there's not going to be any kind of T-lock formed between them
because the other remote edges aren't going to be aware of this edge's T-lock and vice versa.
So all that to say, it's going to be OMP routes and T-lock routes that we're filtering out that the topology policy is going to be enforcing.
We throw out a hub and spoke topology.
We're going to find that we're not able to form tunnels to one another and we're not able to form traffic to one another.
And if I want to make it a little bit different and maybe allow traffic to flow between the sites,
then I would need to do a custom control policy, which gives me full control over some form of topology that I'm trying to deploy.
All right, just three more questions.
Question number five.
A tech has configured a hub and spoke topology via custom control policy, so everything we just talked about,
but the spoke networks can't communicate.
What can be done to enable this?
All right, so full disclosure, I just gave away some of this in the last explanation.
But just in case you're skipping the explanations, let's just kind of go over this real quick.
So we just said that we created a custom control policy.
Those custom control policies, they allow us to filter out routes and they allow us to filter out TLOCs.
Now, if I was using Cisco's topology to deploy hub and spoke topology, when I say what can be done to enable it,
there isn't anything that can be done.
I would need to completely change my approach and deploy a custom control policy from that perspective.
But because I already deployed a custom control policy, here's the good news.
I've filtered out the routes and I've filtered out the TLOCs, and that's why, using the same topology from the last quiz question,
that's why subnet A is not being advertised to the spokes.
They don't know where subnet A lives, and so unless they have some kind of default route that points to the hub,
which they might well actually have, they're not going to be able to communicate.
So maybe we don't want the tunnels in between these, but we would like them to be able to communicate.
So all we need to do is keep the enforcement of the TLOCs in place but get rid of the routing enforcement.
I don't need routing policies and filtering routes out in order to do this.
And furthermore, I might need to change and set the next hop.
Because recall what the problem is when we just ignore this and we say, hey, I'm not going to filter any routes out.
We're still going to have problems.
Why is that?
Because, sure, I'm now advertising that I have A and it points to, let's just call these TLOCs 2, 3, and 4, with TLOC 1 being up here.
So A is available via TLOC 2.
Well, by default, if I'm not filtering that, then the route that's being sent down is that A, subnet A, is available via TLOC 2.
Well, the problem is this site also doesn't know where TLOC 2 is because we filtered that out.
So we wouldn't form tunnels.
So this is where we also need to set the next hop to, say, TLOC 1.
So now if I say that A is available via TLOC 1, I know where A is and I know, that's an exclamation point, by the way, and I know where TLOC 1 is.
And because I know where both of those are, I can now send traffic to TLOC 1, hoping that it will get it eventually to subnet A.
So not only do we want to make sure we're not filtering routes, we also need to set the next hop.
That's a very important part of making this all work.
Or, again, we might be able to use a default route.
If that was your answer, then that certainly is going to help us apply this as well.
Question number six.
And, oh, boy, it's a scenario or a topology question here.
So observe the following topology.
This topology is set on the spoke site or A policy, I guess, is set on the spoke sites to list the hub TLOC as an intermediate.
That's a very important word because we're now referencing TLOC actions, including this one, which is TLOC action backup.
All right.
So recall how TLOC action works.
We're going to have an ultimate TLOC, and this ultimate TLOC is right here.
It is where we're trying to get to.
So, again, let's just define some terms here.
We're trying to get from spoke site to spoke site.
Actually, here we'll have, like, subnet A up here.
I don't think we'll need that, but subnet B and subnet C on spokes two and three here with TLOCs two and three.
So the problem here or what the challenge is is that we need to identify what are the ultimate and intermediate TLOCs.
The ultimate TLOC, if we're sending from B to C, is TLOC three here.
That would be the ultimate TLOC.
Furthermore, the intermediate TLOC is what we said or what has been confirmed is that we're listing the hub TLOC as intermediate.
So T1 is the intermediate TLOC.
Now, remember, when we specify a TLOC action, it is specifying the role of the intermediate.
So the role of the intermediate is actually the backup in this case, which means I am still sending directly to TLOC three.
So when we say what happens to spoke to folks traffic if the hub site is lost, we keep talking.
There's nothing holding us back here.
If we were maybe going through TLOC one, then maybe there would be something to have a conversation about.
But losing TLOC one and losing the hub site isn't going to impact anything when TLOC action is set to backup.
And so, again, anytime we're talking about TLOC action, make sure we can identify what is the ultimate TLOC, what is the intermediate TLOC.
And very importantly, remember that this TLOC action command defines the role of the intermediate, not of the ultimate TLOC.
So at this point, we would just say that traffic would continue to flow.
There would be no disruption.
Nor, by the way, would there be any change in the way that traffic was flowing before the failure.
All right, question number seven, and it is the last one.
It looks a little familiar.
We're observing the following topology.
If the TLOC action primary configuration was added instead, what is the flow of traffic?
So now we're, again, calling this subnet B, subnet C here.
And if TLOC action primary is in effect, well, if TLOC one here, let's make it the ultimate again.
Intermediate is TLOC one.
And so what is the role of the intermediate?
Well, now the role is primary.
So our traffic flow is going to look like this.
In steady state operation, it's going to go through TLOC one before getting to TLOC three.
So what is the flow of traffic during steady state operation, which just means during normal operation?
It's going to flow through TLOC one.
What about if the hub site is lost?
If the hub site is lost, then we will redirect because, again, I have both of these pieces of information.
This is what TLOC action brings for us.
We're able to now be passed from the controller to different TLOCs.
I didn't have that information before.
I only had the ultimate TLOC, but now I have both the ultimate and intermediate.
So if the intermediate is not available, I can use the ultimate TLOC directly,
Now, as a bonus question here, what if it's TLOC action strict?
Well, TLOC action strict in steady state would still send to our intermediate.
I think that's an important thing to keep in mind, that if we are using strict, we are going to forward to the intermediate.
Otherwise, why are we including it?
Remember, everything's from the perspective of intermediate, the intermediate TLOC.
And so if we say primary, that's referring to the intermediate.
If we say strict, that's referring to the intermediate.
So I'm strictly using the intermediate, and if it goes down, because I'm strictly using the intermediate,
I cannot use the ultimate link, which means that we actually drop traffic.
We do not start sending it to the ultimate TLOC.
So a few things to keep in mind there.
Again, know the difference between ultimate and intermediate TLOC,
and know that our TLOC action is always relative to the intermediate TLOC.
So that is an overview of our control policies, which impact the control plane.
They usually have something to do with OMP, the way we're sending information around.
Again, even with TLOC action here, it's whether or not OMP is sending a single TLOC, which it does by default,
or if it's going to send two TLOCs, at which point one's an ultimate and one's intermediate.
But that's all affected by OMP advertisements.
And so that's why this all fits under the umbrella of control policies.
Up next, we're going to do a little bit of a challenge with control policies,
and then from there we'll explore data policies in the same way.