Alright, as always, we like to pause our progress and just make sure we solidify some concepts and potentially identify any areas of weakness or maybe even target some things that we have forgotten.
So we're going to do a couple quizzes here about OMP and routing, and then we'll take a look specifically at some path selection scenarios to make sure that we remember how that process works.
So first up, we have an OMP quiz. There are nine questions here. So question number one, what are the three route types in OMP?
So as always, take a moment to pause the video if you need time to answer, but we're going to go through this one here and the answers are going to be A, C, and F.
So remember, we have three main types of routes in OMP, one of which is known as either an OMP route or a V route.
So if we see one or the other, we're really talking about the same thing. Never forget that.
That little V is not virtual. It stands for a Viptela route. So we are referring to these more often these days as OMP routes, but you will still see V route show up every now and again.
We also have the T-lock route that tells us all kinds of information about the T-locks, including the IP addresses that we can use in order to get to a T-lock that's very important in the OMP world.
And then service route as well. That is going to help us out with service chaining, a concept we'll explore in more detail later on.
But as we talked about, it's the idea that if I want to maybe send a packet that came in that's destined for this host over here.
Yeah, the destination address says to send it here, but maybe my policy says to send it up to this firewall first.
So I send it up to the firewall, and so it's the sort of out of order packet processing that can occur in an SD-WAN environment.
This concept exists in a lot of our software defined networking architectures.
So no, there's no such thing as an O-route. R-locks are something that maybe you've studied in the world of Cisco LISP, but that would be routing locator, but we have transport locators in SD-WAN.
And then you might say, well, we could have static routes in an SD-WAN environment, and that is true.
But it's the same concept as an EIGRP route, or a BGP route, or an OSPF route, where these are going to be embedded inside the OMP route.
So the OMP routes carry the subnet, and it tells us where we learned it.
Did we learn it from a static route? That will be an attribute within the V-route or the OMP route.
So A, C, and F would be our answers here.
Speaking of attributes, question number two, match the OMP attribute to its route type.
So remember, we just looked at the three different OMP routes or route types.
Each route type has a list of attributes, and some of those get duplicated, like site ID, for example.
It would be one that shows up in multiples of those types of routes.
But when we're looking at these attributes, they only show up in a single route type.
So what would these attributes belong to?
Well, origin protocol, this is going to belong to an OMP route or a V-route.
As I just mentioned, we said it includes information as far as where we learned it from.
If it was a static route, that would show up here.
If it was a connected route or an OSPF route, it would show up within the origin protocol.
That's going to be part of our service routes.
It's going to tell us what type of service that is.
There are a couple of predetermined values, but we can also use custom values there.
Public and private IP4 addresses is going to be part of the TLOC route,
because this is how we learn how to connect to a remote TLOC.
The weight is also going to be inside of the TLOC route.
That's going to allow us to determine or help us determine maybe whether I want to go one path or the other
when we're evaluating different TLOCs.
The color is also part of the TLOC.
Then the preference, this one's a little bit interesting.
We do actually have this as showing up in two, because we have an OMP preference and we have a TLOC preference.
The OMP preference shows up in the OMP route type.
The TLOC preference shows up in the TLOC route type.
Again, all of those lists were provided down here in this skill.
Feel free to go back and check that out if you want to grab that complete list.
This whole concept of path selection, we're going to have to dive even deeper into this by the end of this review skill,
because it's so important.
We're going to have all kinds of devices on the network,
possibly not only sharing that they have connectivity to a subnet,
but also that they have connectivity via different TLOCs, for example.
If we have two routers and four TLOCs,
then our poor SD-WAN controller up here is going to get four different options
that other devices or other edges could use to connect to subnet A.
We have to choose the best path, and that's where the path selection criteria comes in.
If all four of these are equal, but maybe I've got to configure to only send two routes,
at that point I'm going to need some tiebreakers.
They can be arbitrary because from what matters most, from a routing perspective, they're all completely equal.
What are those tiebreakers?
Again, they're going to be arbitrary.
One of them is going to be the private IP address.
That truly is saying, hey, we've just got to decide who has the lower IP address,
Path source, this is actually the first thing we're going to take a look at.
Did I learn this from an edge, or did I learn it from another controller?
Because if I'm a controller and I learned it from another controller,
then I'm going to move that down the priority list.
I'd really rather have routes that I learned directly from edges, so that's what path source means.
And then we have system IP, which is like a private IP address,
and it should also help us resolve tiebreaker status.
Now, if we want the order that we go in, we start with path source, then we look at system IP.
Path source will get us down to an edge or maybe a few edges.
System IP, because they're unique, will always get us down to one edge,
but one edge might have two TLOCs on there.
And if I can only use one of those, then I'm going to look, lastly, at the private IP address,
which should be unique on that specific edge device.
So at that point, we should not have the possibility of having a tie.
One thing to keep in mind in all of this is that with the tiebreakers, we're looking for the lower value.
The lower value is going to be considered superior.
Remember, in that whole path selection process, that everything should really be lower,
other than if we are looking specifically at preference.
So preference values are treated as the higher, the better.
But everything else is going to be lower. I want lower metrics.
I want lower administrative distance values, which ties to origin protocol, for example.
And so we've got lots of other things to consider in the path selection process.
And just keep in mind that, generally speaking, if we can't remember, let's go with the lower is the better,
knowing that preference should be the only exception to that rule.
Question number four, what limit determines the number of routes that will be installed by the receiving edge?
So we just gave that scenario where we have the controller.
We've got a couple of routers here, edges. We've got a bunch of TLOCs.
We might be sending as many as four or six or eight different paths to a subnet over here, subnet A, I suppose.
And so we need to know how many this remote edge is going to install.
So we have two different parts of this process.
The first part of the process is how many am I going to send from the controller?
That is determined by the send path limit.
But we have a different limit here, known as the ECMP limit, which determines how many I actually end up installing.
So this amount, I could actually configure this for, let's say, eight, and then I could send all six of these.
Or if it was configured for six, I suppose that would work as well.
But if I only have this set to the default of four, then I'm only going to see four paths installed.
So as far as it being installed by the receiving edge, that would be B, the ECMP limit.
Question number five, which of these route attributes is ignored by the SD-WAN controller when ordering routes?
All right, so we keep coming back to this scenario where we're getting a bunch of route advertisements across different edges, across different TLOCs.
And it has to, first of all, decide the order and determine which route is considered best.
Now, there can be ties here.
I could have three that are considered the best or four that are considered the best.
But even if I get eight paths and I'm only going to advertise four, I'm still going to order all eight in here.
I'm just going to pay attention to which ones I'm allowed to send, which, as we said previously, is based on that send path limit.
But we have seen that there would be potentially a problem if we were to squelch some of these paths if we're looking at a particular attribute.
And that attribute would be the TLOC preference.
Here's the scenario.
It's connected to transport one.
We have transport two down here.
I really want everybody to use this path, so I'm going to increase the TLOC preference.
That's what its purpose is for.
Great.
So I send both of these paths to the controller.
The controller is going to order them with the TLOC preference considered to be the best path.
But what happens if it only advertises this one and it doesn't advertise the second one?
Remember, this is going to transport one mechanism, and I want everybody to use that if they have access to that.
And that's the key is what if they don't?
Because if this device over here, let's say I only have access to transport mechanism two and I only send the T1 path,
then it doesn't have a way to send to whatever subnet we're advertising over here.
but OMP preference is, and origin protocol, all of these other ones are actually considered and can cause the same problem.
But TLOC preference, which is a very common deployment in this type of scenario, we at least want to rule that one out.
So as far as which one gets ignored by the controller, again, this is just by the controller.
We're trying to determine what the best path is.
We're not going to pay attention to the TLOC preference.
Instead, we're still going to advertise both of these routes down to the edge, and the edge will now see,
whoops, because it doesn't have a path to transport mechanism one, that we do have a path that we can use to get to subnet A.
All right, question six, what does graceful restart accomplish?
So pause the video again and just make sure that we can read through all these options and figure out what exactly it's going to do here.
In our case, we're likely talking about OMP peers.
Although graceful restart is used by lots of other routing protocols, like OSPF, for example, can use graceful restart.
And so, yeah, in the context of SD-WAN, we're probably talking OMP, but the concept is the same.
The idea here is that we are connected, we are sending each other routes, and we're sending each other traffic.
The routes are the control plane traffic, and the traffic itself is at the data plane.
In a traditional networking environment without graceful restart, if I have to restart the control plane on the edge on the left,
then we would tear down the peering relationship, and therefore not only tear down the control plane, but also the data plane.
Meaning that while the control plane is refreshing, I can't send data traffic.
Well, this doesn't necessarily make sense in traditional networking where these peers are directly attached,
let alone in an environment, which is what we actually have with SD-WAN, where the control plane is out of band from the data plane.
So imagine if the controller went down and we said, okay, well, we're going to go ahead and tear down the data plane.
It makes even less sense in a SD-WAN environment compared to the more classic infrastructure.
In SD-WAN with OMP, we definitely wouldn't want to use this.
So yes, we can use graceful restart to prevent this from happening on the left, and we can use it on the right.
And on the right, we're going to have very long timers because I should be able to send traffic to my remote edge for a very long time,
even if that controller is having problems coming back up.
So we'll talk about timers coming up, but what is the answer here?
Well, the idea is B here. It's that the data plane stays up with the control plane or when, I guess I should say, when the control plane goes down.
Question seven, an SD-WAN support tech wants to ensure that OMP peers send keep-alives every 200 seconds, which timer should be adjusted.
We talked about this back when we learned about timers just very recently, a few skills ago.
And it's interesting because there is no way to directly affect the keep-alive timer, directly configure the keep-alive timer,
but we can indirectly configure it using the hold time.
So remember, when we're talking about the hold time, keep-alives will always be sent at one third of the hold time interval.
So if we're looking at it and we know that the hold time is set to 300 seconds, which is the default,
then that means that the keep-alives are being sent every 100 seconds.
So now we have this bonus question of what should we use for the value?
And again, if I just do my math, I'm going to take my keep-alive timer and multiply it by three and figure out that I should be using a hold time of 600 seconds.
So that is how we think through keep-alives and understanding how that is affected by the hold time.
And generally speaking, we care more about the hold time than the individual keep-alives,
but it does also help us remember that we're looking for three missed keep-alives before we decide that we're going to tear a peering down.
Question eight, a tech configures the following OMP timers.
Our end of rib is 600, graceful restart at 54,000.
Yes, that's 54,000.
Hold time, 450, advertisement interval, five seconds.
We've increased all of these timers from the default.
So an error occurs during the config commit.
What is the error and how is it resolved?
Well, we could look at it and say, well, maybe hold time can't be 450 seconds, but it can be.
The ranges for all of these are very, very large.
Even 54,000 is within the scope of the timers we can configure for graceful restart.
So what could that error be?
Well, assuredly it's going to have to do with the fact that I'm changing the graceful restart timer,
and we need to think about that IPSec rekey timer.
Remember, whatever the graceful restart timer is, the IPSec rekey timer needs to be double that value,
which means in this case it needs to be 108,000 seconds.
So if we are going to fix this issue, we could say, well, we need to reduce this back down to the default,
or we could say we need to increase this to 108,000.
The default, and I already said that we're increasing all these, but remember the default is 43,200,
which means that the default for the rekey timer is double that at 86,400.
That would be 12 hours and 24 hours respectively, and respectfully.
We are definitely wanting to make sure we understand these timers and what they're doing,
and so the answer here is how do I resolve it really is to set the IPSec rekey timer, increase it to 108,000.
This is an important concept, and fortunately Cisco makes it so that we will see an error,
and we will not be allowed to commit a change to the graceful restart timer if the IPSec rekey timer is not also adjusted to match.
All right, last question in this quiz.
A service tech wants the SD-WAN edge to wait double the default time for an SD-WAN controller to finish a graceful restart.
So we're talking about that graceful restart timer again.
What would accomplish this task?
So we've got a number of options here.
We're either setting the controller or the edge, and we're either setting it to 43,200 or 86,400.
So what is the default?
Well, we just said what the default timer is.
It is 43,200 seconds.
Everything is in seconds, but we can translate that to say that's 12 hours long.
So I want it to wait double the amount of time.
So what's going to accomplish it?
Well, I need to set it to 24 hours, or I could just double the amount of seconds here
and say that we need to set it to 86,400.
So we're not setting it to either of these, so that would remove A and C from the equation.
So next, we need to pay attention to which side we configure it on,
which is the whole reason why we're asking this question.
Because if I want the edge to wait, I need to configure the controller.
B here is the answer.
We talked about this as well.
Let's just say it's the controller since that's the scenario.
If the controller is configured with a timer other than the default, so in our case 86,400,
it informs the other side that this is how long to wait.
So if we want the edge to wait 86,400,
then I need to configure the controller to inform the edge to wait that long.
So yeah, we might assume that if I want the edge to wait, I configure the edge,
but it's actually the opposite.
I need it to be configured on the controller in order for the edge to change its behavior.
So that brings us to the end of our OMP quiz.
If you marked or got any of these questions wrong or kind of forgot the concepts,
I'm sure it takes some good notes.
But again, jot down the skill where we talked about that
and feel free to go back and review it.
Otherwise, when you're ready, let's move on to the next quiz, this one about routing.