Well now that we have a foundation for OMP path selection, it's time to dive a
bit deeper into how routes get advertised. When we think about a
traditional routing protocol, especially something along the lines of EIGRP or
OSPF, when we have a pair of routers we have a direct relationship with an
adjacent router like this. So whether again it's OSPF or EIGRP. Now the
underlying mechanisms for these are very different. OSPF is a link state
protocol. EIGRP is distance vector. And so it's a little bit different with how
they draw these conclusions, but at the same time the conclusion is usually the
same. If I'm trying to get to subnet A and I'm the router on the left, then I
know that I can get to subnet A through my adjacent peer. And the reason I know
this is because on some level I'm getting an advertisement that lets me
know this. And so what do I see as the next hop? Well I see my neighbor as the
next hop. The next hop is right here and importantly it's directly attached. Now
the reason I say it's directly attached is because it's part of the same layer
to domain or really part of the same subnet that I'm attached to. In fact OSPF
and EIGRP they use direct multicast messaging to form their neighborships
and adjacencies. And so there's a lot that gets wrapped up into this, but if
for example the control plane were to go down on this router it stops sending EIGRP
or OSPF hello messages. Well at that point I'm going to assume that the whole
device is unavailable. That X just directly overlapped there. We'll just
scribble it out. And so we know that that's not available and so I'm going to
seek an alternative path to get to subnet A if one exists. But this
architecture isn't what we have with our SD-WAN environment. Because instead of
direct peerings we have something like this where we have our edges in the SD-WAN
environment and the controller is really the control plane. So we know it's
operating as a route reflector. I send routes up to the controller it reflects
them back down and now I know that I'm able to form tunneled relationships to
one another and I know where subnet A lives. But this is really interesting
because now my next hop isn't the underlay directly attached router or
whatever device I'm directly attached to like we did over here. Instead I have a
distance to traverse to get to my next hop. And this concept is very important
as we dive deeper because with OMP the next hop as we've said is a T-lock. And
so let's go ahead and start to explore some implications about what exactly
happens in certain scenarios. And yeah we might even find that there are some
scenarios where traffic gets black holed because we can't actually get to a
subnet even though that subnet is available from a layer 3 perspective. So
let's zoom in a bit on this controller when it receives a route. So when we look
at the controller here we might have a scenario where we've got a pair of
routers and they share some connectivity to this subnet A. Maybe it's directly
connected at this point. And we have a couple of different transport mechanisms.
So typically what we see here is we've got T-locks that connect to one of the
transport mechanisms and T-locks that connect to the other transport mechanism.
Now keep in mind that this might require a T-lock extension. This T-lock right
here might actually connect this way again via that T-lock extension as we
covered. But in the end the overlay network is the same. It's this concept of
saying that yeah I'm forming tunnels. I'm able to form tunnels through the
transport mechanism and via this T-lock even though we all know it's going this
way from a layer 3 perspective that is now considered part of the underlay not
the overlay. Meanwhile maybe we have a router over here that is in a remote
part of the world and we've got internet and MPLS connectivity here for our two
transports and there's just no way that I can get MPLS to this remote site. So
instead I connect it in via the internet and give it a single T-lock. Maybe
there's just a few people at this side. It doesn't require a bunch of redundancy.
I just need connectivity into the environment. Again SD-WAN is very
flexible. This is going to work just fine. We're able to form tunnels. So we have
our tunnels formed this way and we're able to send traffic back and forth. So
now when I'm looking at let's say subnet B over here, subnet B and subnet A they
can communicate just fine via these tunnels. But this is the interesting part
here. If we think about it, we are getting an advertisement. Let's draw this
in a different color. An advertisement to the controller of four different paths
to subnet A and really what we're saying is subnet A is reachable via four
different T-locks. Now the controller as we've established is going to restrict
the amount of advertisements that it sends down to four. In this case we only
have four so that's fine. And it's going to send those four T-locks to this
remote site as long as they are all equal. Remember we're going to send the
best route or best routes. That potential plural matters a lot because we're going
to want to take a look at these four T-locks and order them and only send the
best one or two or three or four depending on how many there really are.
If there's only one route it's only going to send one but if all four are
the same then we're going to send all four. So far this should jive with what
we've been talking about. And so this router which only has a single T-lock
keep in mind is going to take a look at these four different routes. So it's got
routes one, two, three, and four. Two of these are going to be out the MPLS
circuits. We'll just say two internets and two MPLSs. And it's going to run its
own path selection criteria. Now part of the path selection criteria is that T-
lock reachability concept. Can I access the T-lock that is being advertised? You
and I can look at this diagram and say hey you know what it doesn't have
reachability to the MPLS T-lock so why even have those in the routing table? And
that's exactly what it's going to do as well. It's only going to install these
two routes because those are the two T-locks that are reachable. This internet
T-lock on the upper edge and the internet T-lock down here on the lower
edge. And that works out well because we have connectivity to these two
different T-locks. All of that is fantastic. But we have addressed the
possibility that this best routes we've got a way of differentiating among the
different routes and possibly selecting one or two best routes. And one of the
ways we can differentiate is with something called the T-lock preference.
So the T-lock preference is interesting. I can use it to differentiate between
two different T-locks. Now what if I want people to use MPLS as much as possible?
MPLS is a more reliable network in theory. Maybe the bandwidth is really
good. And so I decide to increase the T-lock preference on these T-locks. So
now my internet T-lock preference, we'll just call it TP here, T-lock preference.
Let's say that we make that, well we'll just leave that as the default which is
zero. And now the MPLS T-lock preference will make this 100. So this is more
preferable over the internet T-lock. So now the controller is going to receive
four T-locks except we are still evaluating what are the best routes and
now we're going to see that the MPLS routes, we'll just write MPLS and MPLS,
these should be considered best. And the internet routes are not considered best
anymore. So here's the question. Based on everything we know and understand, what's
going to happen here? What is the controller going to do? Is it going to
send down only the MPLS path? Because that would be really bad. If I only send
the two MPLS links, well now my routing table looks like this and we know that
I can't reach the MPLS side. That means that this edge on the left would not
have a way of getting to the subnet A just because I tried to tell
everyone to use MPLS first. Fortunately this is not what's going to happen. And
by the controller. It's going to be taken into account only by the edges. In other
words, we're still going to send all four routes down. Now you and I know that this
T-lock preference is an important part of path selection and so we might have
looked at that and said okay well that's a way to differentiate as we've said and
now we would only send those two routes. But hopefully we're seeing the
reason why we can't do that with T-lock preference. With T-lock preference the
controller doesn't know which T-locks which T-locks are available on this edge.
It doesn't have visibility into it. It's not taking that into account and
furthermore I might have another edge down here that only has an MPLS
connection. Or maybe that seems odd because we should have an internet
connection but you know whatever the situation is it's only got connectivity
to the other transport mechanism. And so because of that we don't know which T-
locks are available and so we still want to advertise all four. Then the
individual edges can sort it out and it'll sort it out in the exact same
fashion here. Yes the T-lock preference is higher on the MPLS side but that T-lock
reachability comes first. If I can't reach the T-lock I'm not even going to
consider it which means the internet edges or internet routes still get
installed on the edge. So our black hole crisis is resolved or is it? We know that
at this point T-lock preference can't cause a black hole issue where this edge
over here has no access to subnet A because of T-lock preference. That's a
good thing. But we do need to explore a couple other scenarios where this might
still happen based on a couple of the other parameters. So we'll take a look at
that coming up but for right now our big takeaway is that T-lock preference right
here is considered by the edges not the controller. And that's important and
makes sense because the controller doesn't know what the T-lock reach
ability is on the edges that it's advertising to.