All right, so what we have here is we've got a few things
to make sure we're aware of here,
as I just said in the last video.
What we're gonna do is we're going to take out this link
between Edge 11 and the MPLS circuit.
We're going to make sure that we get EIGRP running
between Edge 13 and Router 134.
That should already be in place from our previous skill,
so we'll take a look at that.
But this is what we have to get going here,
is we have to get Edge 14 running EIGRP as well,
so that it can learn about this 90.90.90.90.
That's a loopback on Router 134,
but essentially it represents a subnet.
We'll go ahead and just call that subnet 90
for the sake of brevity,
so I don't have to say the whole thing every single time.
And the only other thing to keep in mind
is that, again, we have T-Lock extension,
so the internet is connected to Edge 14,
but it's going through 13,
So when we want to take out the internet for Edge,
let's say just Edge 13,
if I were to take out this link,
it would actually also take out Edge 14.
Its connection to the internet runs through Edge 13,
so we can't just shut down that link.
That's why we'll go ahead and just shut down
the tunnel interface in order to emulate an outage.
So let's go ahead and make this configuration happen.
We're going to start by getting EIGRP running
here on Edge 14.
So I'm going to do a config dash T,
and then enable the router process.
So again, we just give it a name.
We've used CBT in the past, we'll just use that here.
And then I have to specify this long command,
so I have to specify the address family,
as well as the fact that it's Unicast,
and then the VRF, and then the autonomous system.
And we're using autonomous system 10 for this.
And then I also have to specify this topology base command.
And then lastly, I can engage the network statement.
So that would be 10.10.13.14 is the Edge 14 interface
with a wildcard mask of all zeros
to only activate that specific interface.
So let's go ahead and exit out of EIGRP config
and get onto the SD-WAN side, specifically in OMP.
And what we're, whoops, address family IPV4.
And then what we're going to do is advertise EIGRP
back into, or yeah, advertise it into OMP, actually.
So there we go.
So we're going to commit that.
All right, and we'll go ahead and end here.
And just make sure everything is working.
We can already see in the log messages
that we have an EIGRP neighbor up here.
So if I do a show IP EIGRP, okay.
EIGRP, and then the VRF, and then neighbors.
We should see the both neighbors
because by activating EIGRP on the subnet,
Edges 13 and 14 have just formed EIGRP neighbors
with each other as well.
All out gig three, all right, that's looking good.
So from here, if I do a show IP route and then VRF 10,
I should see that that 90, subnet 90 does exist.
And indeed it does.
If I were to ping it, we should get a response.
Just keep in mind that we have to do this on VRF 10.
All right, and we're good to go.
So now we're going to go make those small changes.
We have to shut down the link between Edge 11 and the MPLS.
And then we also need to make sure
that the cost is increased on Edge 14.
Since we're on Edge 14, let's go ahead and do that.
I'll do a config T, get onto interface,
gigabit ethernet three,
and I'm going to set a relatively low bandwidth of 1000.
So just to mark that down on our diagram here,
this link here has a bandwidth of 1000,
which is a lower relative bandwidth compared to Edge 13.
So this path should not look, whoops,
as appealing as the path through Edge 13
when they both advertise up to the SD-WAN controller.
So that's well and good,
but we also need to not knock out this link.
So let's go ahead and switch over to SD-WAN manager
So we're going to open up our templates here,
go to the feature template that manages that interface.
That would be this MPLS interface.
So I'm going to edit this.
Now keep in mind, if I'm going to shut it down globally,
then that's going to shut it down on both Edges 11 and 12.
If I wanted to make it device specific, then I could.
We're going to be shutting down gigabit ethernet two here.
I could make it device specific,
but I'm just going to shut it down on both
because in our lab environment, it doesn't matter.
So I'm going to update this
and then say, yes, we're sure we want to push this down.
So once this looks like it succeeded,
then we'll confirm at the CLI
that those interfaces are in a shutdown state.
In fact, let's go ahead and just switch over to that
and we will watch it in action when it comes up,
when the link goes down.
All right, so now we're on Edge 11 here
and we do see that these line protocols are going down.
So if I do a show IP int brief,
I should see that gig ethernet two,
which has the MPLS subnet by the way, just to confirm that,
but is administratively down.
So if I do a show SD-WAN BFD sessions,
I should only see that I have connections now
through biz internet.
I don't have any connections anymore via MPLS.
So that is looking good.
We should all be working at this point.
Everything that we wanted to be working
should actually be in place.
So what was the effect?
Well, again, we turned sites 11 and 12,
in our case site 11, into a single circuit site.
These are very common in real world wide area networks.
And so it's not a stretch to suggest
that we might see this in our actual environments.
We also made it so Edge 13 has a favorable route
to subnet 90 via router 134.
So let's go ahead and check the routing table here.
So if I do a show IP route VRF 10,
let's see what this is running through.
So I have 90.90.90, subnet 90, via Edge 13.
Where is my path through Edge 14?
Without this bandwidth statement,
we would have seen two routes here,
but instead I'm only seeing one.
The reason for that is simply because Edge 14's path
is not getting advertised down.
Let's confirm that.
If I do a show SD-WAN OMP routes,
and I look at the subnet 90 entry,
right here, we see that we're only getting a path now.
And I know this is really hard to read
because of the resolution that we're running,
but we're essentially saying that we've got a path here
through MPLS, which is invalid.
So MPLS doesn't work because I don't have a path
to the T-lock.
And then I have another one here that is working.
That's what the CIR is for.
So still part of subnet 90 here.
This one's installed through Biz Internet.
But we notice right from here, we get into another subnet.
I don't have a path in any of this through Edge 14.
I only have two paths through Edge 13.
The path through Edge 14 isn't actually working right now,
or isn't getting advertised.
Let's just confirm real quick that it would get advertised
if not for that bandwidth statement.
So we'll do an interface gigabit ethernet three.
We'll do a no bandwidth 1000 and commit that.
So at this point now, these two paths
to subnet 90 should be equal.
So whoops, wrong one.
Let's go back to Edge 11 here,
take a look at our routing table.
And now we do see that we have those paths
through 14 and 13.
I do see that 90.90.90.90 has paths through 13 and 14.
So that one bandwidth statement
is what's going to cause the problem here.
As soon as it's an inferior path,
the SD-WAN controller looks at that and says,
well, I'm only supposed to send the best path.
I have two best paths, both from Edge 13,
one from the internet, one from MPLS.
So I'm only going to send those down.
So let's go and get that back into place.
I'm gonna come back here,
give it the inferior bandwidth statement and commit it.
And now we'll go back to Edge 11 here
and make sure that we only have one path again, and we do.
All right, so we already see the problem.
If this internet path goes down, I only have one route.
And furthermore, if I look at the OMP routing table,
I only have paths through Edge 13,
and one of those paths is through MPLS.
So that's not going to save me in theory.
So let's go ahead and just make sure that that is the case.
I'm going to get onto Edge 13,
which I've been logged out of.
I'm going to do a config T
and get onto that tunnel interface.
In fact, just to make sure,
let's do a show ip int brief.
Want to make sure we shut down the right one.
And so tunnel zero is our internet circuit here.
This is the internet subnet.
So I'm going to get onto interface,
tunnel zero,
and do a shutdown.
And then we need to commit it.
Okay, so at this point,
we have shut down the internet link for Edge 13.
So now I'm going to go back to Edge 11 here,
do a show SD-WAN OMP routes.
What do we think happened here?
Well, what we think happened is probably
that we still only have these two paths
because SD-WAN controller is telling us
that we've got an MPLS path and an internet path,
but notice already the internet path is now invalid
because I don't have access to it.
If I do a show SD-WAN BFD sessions,
we will see that we're trying to form a connection
to biz internet,
well, specifically to Edge 13 via biz internet.
My Edge 14 connection is still online.
We only shut down the tunnel interface on Edge 13.
So that T-Lock extension is still working.
And yet if I do a check on the routing table,
we see we don't have a route to subnet 90.
So simply because Edge 13 had an internet failure,
we lost our path to subnet 90.
This is the problem with our configuration.
And again, this can show up in the real world.
We have to be very careful and cognizant
of where this might show up.
Now, keep in mind, if Edge 13 and 14
and all of our dual Edge sites,
if they all have equal paths to all the subnets,
then this doesn't matter
because we saw when we had equal cost paths
that I had all four of those paths being sent down to me
from SD-WAN controller.
But if I have unequal cost paths,
then this is where the sending of backup path
is going to be required for these single circuit sites.
So if we don't have any single circuit sites
in our environment,
then it's something we don't have to worry about.
But clearly if we combine a few
of these situational configurations,
it's going to cause us problems.
So what are we going to do?
Well, we're going to solve this problem
by configuring backup paths.
We'll get onto our SD-WAN controller here,
do a config space T,
get into our OMP configuration
and simply enter this command, send backup paths.
I'm going to hit enter and commit this configuration.
And now let's see what happened.
I'm going to come back to Edge 11,
check the routing table and look at that right away.
We already have a route.
Where did that route come from?
Well, it's telling me to go through Edge 14.
It's telling me,
well, we don't have the other information here.
Let's go ahead and check the T-locks.
So we'll go ahead and go into our OMP table
and take a look at that.
And now we see that we do have all four paths
that can be advertised.
So we know that two of these are superior.
These are the superior ones.
And yet SD-WAN controller is advertising
the next best path, they're inferior,
tied with each other,
but inferior relative to Edge 13,
and yet they're still getting advertised.
Because this is sitting in my OMP table,
even if I have, I know this is tricky to see,
but we've got an invalid path here,
invalid and invalid.
These three are invalid and yet I still have one
that's getting installed.
And it's getting installed via Edge 14,
biz internet.
So that is a required configuration
in order for us to make it work
in this particular failure scenario.
Now, last thing before we move on
is just to make sure we undo the failure scenario.
So I'm gonna get back onto Edge 13 here,
and I'm going to do a no shutdown on tunnel zero,
and then say commit.
with everything back online,
and even with send backup paths still enabled,
what do we expect to happen here on Edge 11?
Well, when I check the routing table,
we might expect that, well, I've got all these routes,
maybe I'm still load balancing,
but I'm not going to load balance.
The reason for that is because Edge 13's path
is still superior.
I should still prefer it over Edge 14.
And yet, if this route were to be lost,
we know that in the OMP table,
that at this point we have all four of these entries.
We're just going to prefer Edge 13 when it's online,
and we can install the Edge 14 path
if Edge 13 goes offline for any reason.