We have a goal in mind with this conversation and that's to understand
how a controller or how an edge device, either way, how they decide which path is
best. As we explored in the previous video, we are going to aggregate a bunch
of routes to a particular subnet and we need to decide which one is best. Now
this could be a tie. We could end up with, as we saw, two, three, four, six, a hundred,
I don't know, however many paths that we end up aggregating. They could all be
tied. They could all be seen as best, at which point we're going to send out some
number of those according to the send path limit. But the question is that we
have to answer in this conversation is how do we decide which path is actually
best to a particular subnet? And the answer lies here in our OMP path
selection criteria. Now when we evaluate the OMP path selection criteria, we're
going to find, if we look at Cisco documentation, that they inject a few
additional parameters that we're not going to dive into detail here for
because it really a lot of those are for advanced or maybe very corner case types
of scenarios. Our goal is to understand primarily what drives the path
selection criteria, and we've got the six primary ones listed here, and then also
understand how we as network admins can start to manipulate that. And so we need
to understand which of these parameters are tunable, what we can configure them,
and which ones are based on the network and how the routes are learned. So at the
start of OMP path selection, we're going to find that route validity is the first
thing that we're going to look at. Specifically, can I actually use this
route? Now we could argue that this shouldn't be part of the path selection
criteria. That should just be part of any criteria for evaluating a route. But
here's the important thing about this and why it's on our list. When we look at
OMP routes, remember what the next hop is. The next hop is not an IP address, it is
a T-lock. And so when we say is the route valid, is it reachable, we're really
asking if the T-lock is reachable. Because if the T-lock goes down for any
reason, and it's not accessible even though we're receiving a route that's
being advertised to us that says the route is reachable via a particular T-
lock as the next hop, well if that T-lock isn't reachable, then we might as well
not even consider that as part of our evaluation. Which makes a whole lot of
sense. That's why we're starting with this. First of all, can we actually get to
the route? Just keep in mind how we evaluate that. It's about whether the T-
lock is reachable. Next is the active status. Now the active status has to do
with this concept of OMP graceful restart. We haven't covered this yet and
the reason for that is it's a little bit more of an advanced OMP
configuration. We want to cover it once we understand how OMP works. But the idea
of graceful restart, there we go, graceful restart is that I can shut down
my control plane but keep my data plane online. So maybe I'm going to power cycle
the edge device for a maybe some kind of maintenance or upgrade or something
along those lines. Well I am going to lose my control plane, which is how I
share all of these routes, but the data plane might as well stay online and
allow traffic to come in and out of this device. There's been a massive shift in
the industry over the last decade to include this concept of data plane
operations through some kind of restart and a lot of Cisco platforms support
this. So the concept of graceful restart, depending on your experience, may be new
or may not be new. It's not an SD-WAN specific technology. But the idea here is
if a router is in this space or in this maybe mode of operation here where we're
in the middle of a graceful restart, then any routes learned from this device are
going to be marked as stale. So we're either active or stale and we want to be
active with our OMP routes. Now if you, again depending on your experience, you
think about EIGRP. EIGRP, when it puts a route into active, that's not a good
thing. That means that the route is not stable, it's actively being
propagated, trying to figure out how to get there. We're trying to see if we
still have a path to that route. That's what it means by active in an EIGRP
sense. In OMP it means something very different. It means that we are actually
in steady-state operation. That the edge is available, its control plane is
online, and everything is good. That's what active means. If the data plane is
online but the control plane is not, then it's marked as stale. So if we have a
bunch of routes brought in and a few of them are stale, they're going to lose at
this stage of the evaluation. We're gonna say, okay, well even though all the other
criteria is fine, the fact that these two routes are stale means that we won't
consider them to be the best. So that is an important part of this path
selection process. Now OMP preference and TLOC preference, these are two very
important parts of the path selection criteria. As I've mentioned a few
times, it's because we as admins need to be able to perform traffic engineering,
which means directing traffic out certain links. If I want to have some
amount of control over that, I'm probably going to use one of these two
mechanisms. So what exactly are we saying here? Well these are two different values
that essentially say how high of a priority a path should have. So if I'm an
edge, and let's say we have two edges here and they're both attached to the
same subnet, and maybe one of these is a little bit better than the other. Maybe
it's better hardware, maybe the links have better bandwidth. These are all
things that OMP doesn't by default take into account. We as admins have to step
in and take it into account. So if I'm seeing these two edges, let's say it's
just edges one and two, and they're both advertising to the SD-WAN controller,
they're going to by default send with preferences of zero. Meanwhile, I as the
admin could get onto one of these devices. We just said edge one is the
superior device for one reason or another. And so when we're advertising
subnet A here to the controller, now I could actually say that I want to
advertise this with a preference of 10. Now we have two different options for
preference. Let's just call this an OMP preference of 10. So OMP preference of 10
is higher than the default of zero, and therefore it's going to win. An important
part of this process, for better or worse, is knowing that some of these values in
our selection criteria are better when they're low, and some are better when
they're high. We'll talk about that later on as well, but with preference the
higher value always wins, and the default value is zero. So make no mistake, if we
have a higher preference value, then that means that we're going to see that as a
better path. Now what this does is when I have another edge over here, I'm only
going to receive again the best path to subnet A, which means I'm only going to
receive one route, because now these are no longer tied, they're no longer equal
cost, but instead edge one has the superior path. This is why we emphasized
so much in the last video about equal cost paths, because we still are getting
two routes, and we might expect to advertise two routes, but we're not going
to do that. We're going to advertise the best, and now we actually have one. So why
do we have two different preference values? Well I mentioned this is the OMP
preference, and that's good for comparing two different edges, because these
clearly have two different OMP values. But what happens if I actually have two
T-locks that are being advertised by edge one? Well now, because it's an OMP
process, this is more of a preference, this is more of a global
conversation, so both of these are going to be marked with an OMP preference of
10. So what can I do here to say that I want to use this link over the other?
Well I can't use OMP preference, because that applies to our edge one. What I can
do is use T-lock preference, and now the T-lock preference I could increase
beyond zero. So maybe the top link is zero T-lock preference, and down here I
could mark this as a 10 in it from a T-lock perspective. So basically it
allows us to compare between T-locks here on the same edge device. Now
importantly, notice the order of operations here. OMP preference will
always win out over T-lock preference, so even if we have a second link down here
with a T-lock preference of 100, it's not going to override the OMP preference of
10 coming from edge one. However, when we're looking at it within the same edge
and all links are being advertised with the same OMP preference, now I
can differentiate between my links using T-lock preference. So again, OMP
preference, T-lock preference, these are very important. We're going to see a lot
of examples of this, we're going to configure this, and so let's spend some
time making sure we fully understand the difference as well as the order of
operation here within path selection. So next we're going to talk about origin
type and origin metric. So these two concepts are related to one another. The
concept of origin is asking how did we learn the route? I'm just gonna write how
learned. So for example, did we learn the route via a connected subnet? This
example down here, we see that subnet A is connected to edges one and two, so it
should be directly connected. But what happens if I have a router or an edge
device, and yeah maybe I've got some connected subnets here, but I also have a
downstream layer 3 device. Well maybe this is a static route that I've
configured on my edge here, so this is the edge on the left, so I've configured
a static route to point down to a bunch of routes. Or maybe I'm running OSPF
between these devices, maybe I'm running EIGRP or BGP and so on and so forth. So
if all of these are considered equal at this point, it's a valid route, all routes
are active, the preference values are all the same, well we still want to attempt
to differentiate between our routes. And so the origin type is how we're next
going to accomplish this, or at least attempt to differentiate our routes. And
what we'll find here is for the most part the order matches the administrative
distance values that appear on Cisco devices, with a few exceptions. So let's
go ahead and go through these. So first of all, connected types will always be
preferred the most. If it's directly connected, we definitely want to consider
trusting that this edge has a good path to it, it's directly connected after all.
tend to trust those as well. And so a static route would be next preferred.
Then we have EIGRP summary routes, and again we notice that this is falling in
line with administrative distance because connected routes have an
administrative distance of 0, static 1, EIGRP summary 5. Next up is EBGP, which
administrative distance wise is 20. Then EIGRP, which is 90. OSPF, which is 110. And
here's where things start to get just a little bit different. So ISIS does come
in after OSPF at 115, but this is going to be an L1 type of route. We then see
EIGRP external in here, which has an administrative distance of 170. Then we
have an OSPF external, which is interesting because by default on Cisco
devices, this has the same administrative distance as OSPF. But here we're
separating them out, so that's very important for us to notice. And then I'll
continue over here, ISIS L2 routes, so we split those off as well. And then IBGP,
which should be down at the bottom because it has administrative distance of
200, falls here down low. And then unknown wraps up, which also matches what
we do with administrative distance. If for any reason we don't know how we
learned a route, it's going to be considered the worst. So what if we have
two edges that have knowledge of subnet A, but the reason they have knowledge of
subnet A is because one of these has an EIGRP connection, one of them has an
OSPF connection, and they're learning about subnet A in this fashion. Well when
they advertise the subnet to vSmart or to the controller, they're going to
include the fact that I learned this via EIGRP and I learned this via OSPF. The
controller is going to look at that and say, well even though everything else
over here is the same, I am going to only advertise the EIGRP path. So everybody's
going to want to come in this way because the subnet was learned via EIGRP.
Kind of interesting, and we could argue that's a little bit of a tiebreaker
because it doesn't necessarily mean it has the best path, but it is taking
something into account. And we trust EIGRP more than we would trust for
example OSPF, that's just Cisco logic, but also certainly more than something like
IBGP. And so that's the logic here of using and storing this information by
the way in OMP. This comes back to the fact that OMP is an information carrying
protocol. We don't just carry the the route, we carry a lot of information. We
can include things like, hey I learned this via OSPF, and that's pretty cool
that we can not only transmit that, but then also the controller can make
decisions based on that. Now the origin metric is probably what we'd maybe
assume from here, which is that if I learned something via OSPF, then I'm also
going to include the cost. If I learned something via EIGRP, then I'm going to
include the metric, and a lot of these protocols have ways of including metrics.
Now if they're both connected, then the metric isn't going to be valuable there,
but we might actually be able to tell the difference between a route based on
the metric. So going back to our example up here, what if both of these were OSPF
learned? Well now I can include the cost. So if this device has an OSPF cost of
100 to get to subnet A, and this device has a cost of 150, well we want cost to
be lower, and so we would actually prefer again this top path over the bottom path.
This time they're both OSPF, but one actually does have a better metric or
better cost to get to subnet A. Now it's worth noting that we might have a
multi-region fabric. If we have a multi-region fabric, we covered these
early on in the course, the concept is that we have a core region, and then
maybe I've got a region that's in Europe, and a region that's in the US, or
Australia, but there's just in different regions. And so all of these devices, and
all of these devices, we're not going to form direct connections between our
regions. Instead we form connections to the core in order to get to one another,
meanwhile we've got all kinds of connections within the region. So that
was the concept of a multi-region fabric. If we're running multi-region fabric,
then there are some criteria in here that would affect the region. So we're
going to include parameters that will help us to determine best pathing as
part of a multi-region fabric. That is certainly considered more advanced SD-WAN
configuration, and so it goes beyond the scope of this exam in this course, but be
aware if you're managing a multi-region fabric that there are other parameters
that you're going to want to be familiar with. Now we might get to the very end of
this entire process, and we might still be tied. And if I am only advertising
connected routes, and I'm not modifying preference, then certainly it's very
likely. In fact in our lab environment currently all of our routes are in a
tied status. So how do we get to a point then that we can create an ordered list
if we have evaluated everything that we know to evaluate, and yet we still don't
have differentiation among these different paths? Well at this
point we're going to need the concept of arbitrary tiebreakers. Arbitrary meaning
that it's not going to actually be based on anything meaningful, instead it's just
a way for us to order routes that have the same path cost, if we want to call it
that. So in the next video we're going to be taking a look at those arbitrary
tiebreakers, and how that allows us to create a ordered list.