Well, we still have a very important issue to resolve.
And let's just go right back to that same topology,
give or take, where we have the internet,
we have MPLS, we have an edge on the left here
that only has connection to the internet.
And then we have a dual site or dual edge site over here
where each one of these edges has connectivity
to both of these transports.
So we just saw that OMP is designed
to pass multiple paths regardless of T-Lock preference.
So I might say that this has T-Lock preference
higher on MPLS, it doesn't matter,
I'm still going to send all four routes down
and T-Lock preference is evaluated here
and that we know that it gives priority though
to T-Lock reachability.
And that's really important
because even if MPLS links are preferred,
I still need to be able to see
that there's internet links and MPLS links
so that I can cross off the MPLS links
say I can't reach them, those T-Locks specifically
and therefore I'm going to install the internet routes.
But there is still a potential here
where instead of advertising all four,
we only advertise the two MPLS links
or something along those lines.
That could be really bad for us.
So let's see what exactly happens here,
how exactly it goes down.
And so let's say that we've got
a layer three device downstream
and now we're running EIGRP.
So these are, we're no longer talking
about a connected subnet anymore.
Subnet A is way over here,
it's hanging off a different layer three device,
this is just running EIGRP to these two nodes
and remember EIGRP uses a metric
just like OSPF uses cost
and we wanna take the lowest metric link.
And so let's just say that we have,
I'm just gonna assign some arbitrary values here
but let's say that we have a link
with a metric of 10,000 up here
and 100,000 down here.
So we know that EIGRP uses these metrics
that are way higher numbers than OSPF costs, that's fine,
only matters relative to other EIGRP links.
Now also remember that when we advertise our routes,
our ability to get to, for example, subnet A,
I'm advertising this to the controller,
there are two things that we might take into account
besides TLog preference.
We've got OMP preference
and right now we're just running the default
of zero for that.
And then we also have origin type
which tells us how did I learn the route?
Well, both of these are learning EIGRP via EIGRP.
So origin type, these are the same.
So these are equal in our scenario
but lastly, we have origin metric
and we can see that origin metric
is unequal between the two.
Let's go ahead and assign some numbers here.
So we've got edge 100 on the left,
we have edges 200 and 201 on the right.
So we can look at this and say that edge 200
that I can reach it in 10,000
whereas edge 201 is going to say
I can reach it at 100,000.
And I can do this via internet or MPLS, internet or MPLS.
So at this point, based on everything we know,
what is going to be advertised down to the other edge?
This is something we need to pause and think about
because before with TLOC preference,
because everything else was equal
before we got origin metric involved.
If everything else was equal but TLOC preference,
we still sent all four routes down, all four paths down
so that edge 100 could make its decisions
based on TLOC reachability.
Well, at this point, we are not going to do that.
We are only going to send two routes down.
And the reason for that is because I have two routes
So that's the bad news.
I am not going to advertise the two routes
that are not considered best, which isn't great.
Right away, we would argue that this is probably not ideal
because this is supposed to be a redundant path.
I have dual edges for a reason.
Like, yeah, it would be nice if this link goes down
that subnet A can still get out,
but we also want people to be able to get in
through this redundant path.
And as of right now, I'm advertising the paths via edge 200.
I'm not advertising the paths via 201.
This edge and all other edges,
they're not even going to know
that there is a redundant path.
So we already see that that's a problem.
So that's the bad news.
Here's the good news.
Notice what I am advertising here as best.
I'm going to get the same choice here.
I'm going to get an internet path and an MPLS path,
and I'm going to choose the internet path,
which means that I am going to now send directly
to edge 200 in order to get to subnet A.
And as of the moment that all of this is advertised,
life is good.
Everything is working fine, subnet A,
and well, we assume we've got like subnet B
hanging off over here.
Subnet A and subnet B can communicate with each other
no problem whatsoever.
So what is the problem?
It's not ideal.
I don't have this redundant path in my routing table,
but right now I don't need it.
Do I?
Well, here's the problem.
What happens if we have a failure?
And specifically, what happens if edge 200 here
loses its internet link?
So at this point, it's going to withdraw the fact
that it can, you know, I've got subnet A
and you can reach it via my internet T-lock.
That's going to get withdrawn,
which means that we're only going to advertise
one route down.
The other route's going to get pulled.
And now instead of evaluating both of these,
that's not going to happen.
We're only going to get an MPLS link.
That's the only thing that's left here.
These are still not considered best.
This MPLS path is considered best
because of the origin metric.
And now I'm going to get one route that I cannot reach
because T-lock reachability is not only
a path selection criteria,
it's also a very important part
about being able to send traffic.
I have no way to get to this T-lock
because I don't have connection to the MPLS cloud.
Pretty fascinating situation here.
And there's a few things that contribute to it.
First of all, we see that I've got a device
that only has a single T-lock connection.
We also have a situation where we're trying
to direct traffic into one of these or the other.
If I wasn't allowing this metric to be different,
and if I wanted to make sure all four of these were equal,
then this wouldn't be a problem.
But the fact that they aren't equal
and I have this situation over here and I have a failure,
this is what leads to the problem.
So we might look at this and say,
okay, well, a lot has to go wrong.
Is this really that big of a deal?
Well, does a lot have to go wrong though?
I mean, I really just have to have a fairly standard setup.
Like we said, we've got a dual edge site
with different metrics to different subnets.
And we have remote edges that only have a single T-lock
because maybe they only have an internet circuit
and I can't affordably or maybe can't at all
get an MPLS circuit out there.
So this isn't that far fetched of a scenario.
And so again, when everything's online, that's great.
But if I lose that one internet connection,
I've got three other paths into that site,
one of which is right there.
It's absolutely accessible by the site.
And we're going to say,
well, it's probably not going to happen.
Yeah, I don't think that's gonna fly very well.
So we need a solution.
Unfortunately, we do have a solution for this
and it is known as backup paths.
We have the option to send the next best path
and the next best path only.
So we can send the next best path
So up here, when we say that we're going to evaluate
this 10K set of a pair of routes
versus this 100K pair of routes,
well, now we'll just draw down here.
We've got an internet link at 10K
and we have an MPLS link at 10K
and we have an internet link at 100K
and an MPLS link at 100K.
So normally we would draw a line in the sand here.
In fact, we still would.
We'd still call this the best path
and this down here would be the next best.
Now, very importantly,
notice how we lumped tied routes together.
So these two routes are tied.
They together are best.
This isn't best and this is next best.
We're not playing those games.
They are tied, therefore they're together
considered to be the best path,
which means that I look down to the next set
of either tied routes or the next best route.
And I look at this together
and say that these two are tied as next best.
So in our scenario here,
the next best would be the 100K paths.
And I'm going to advertise those.
I'm gonna send them in those advertisements to the edges.
So what's the net result of this?
Well, the net result is that edge 100 here
is now going to receive two sets of routes.
It's going to receive an internet at 10K
and an MPLS at 10K
and it's going to receive an internet at 100K
and an MPLS at 100K.
Now again, in steady state operation,
where everything's online,
we're going to disregard the next best.
We're going to keep them in our information.
We're not going to install them in the routing table
nor am I going to install the MPLS.
So these arrows right in here
that show we're going between edges 100 and 200,
that's all good.
But in the scenario where this top route ends up going down
because TLockReachability is down
and I still can't use the MPLS link,
well now I can look at the backup paths.
And I do see that I've got an internet connection
there as part of the backup.
So now I can send via the internet down to edge 201,
really down the internet link.
Let's draw it like that.
Now I can go that way to get to edge 201
and still get to subnet A because that link is there.
So this is quite a scenario.
But again, it's very important for us to walk through this
and recognize what causes the problem
and then how enabling backup paths is going to help us.
Now I might ask,
why isn't backup paths just enabled by default?
Why do I have to explicitly enable that?
Well, because in a perfect SD-WAN world,
everybody has two TLOCKs is really what it comes down to.
We've got TLOCKs everywhere.
We've got this overlay network.
And again, that's just our perfect world
or perfect design from an SD-WAN perspective.
And if that was the case,
backup paths would be completely useless
other than we'd be propagating information
that's never going to be used.
It's never going to be leveraged.
And so we don't want a messy environment.
We wanna keep our environment clean
and only share routes that are possibly going to get used.
So that's why backup paths aren't enabled by default.
But as soon as we see a scenario like this,
where we've got especially edges out there
then we wanna take a look at our dual edge sites
and make sure that all of those routes
are considered equal.
And if they're not considered equal,
now that's a time to go ahead and deploy our backup paths.
Just keep in mind that TLOCK preference
isn't able to cause this problem
for the reasons we discussed.
Instead, it's these up here,
the preference, the type, the metric
that can create unequal paths.
That's what can cause this issue.