What we want to do here is talk through the concept of recursive routing.
So if we're building a tunnel environment, in fact, the scenario here says an
engineer
configured the environment and is now seeing recursive routing.
So we need to understand what causes it and make sure that we can talk through
potential
solutions.
So scenario or question number one here, the engineer proposes a change to the
OSPF cost.
So we want to change the cost of OSPF probably on these links here or
potentially even the
tunnel interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tunnel interface.
But either way, the question is, will this work?
The reason why the details don't matter a whole lot is because we can already
answer
the question, this is not going to work.
Changing OSPF cost doesn't matter because the issue here is that we're going to
be receiving
these underlay routes across the overlay and EIGRP.
So changing OSPF cost isn't going to fix the issue.
It's not going to impact the fact that EIGRP has administrative distance of 90.
OSPF has administrative distance of 110. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
OSPF has administrative distance of 110.
And so if I see these routes, let's say we've got routes A, B, C, and D here.
So if I think that routes C and D are better known through EIGRP, it doesn't
matter what
the OSPF cost is, I'm always going to favor EIGRP.
Now question number two says, okay, it's almost like a follow up, right?
Like, okay, so the cost isn't going to fix it.
But what if we change the OSPF administrative distance on routers one and two?
So now rather than saying it's 110, we say that it's 80. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now rather than saying it's 110, we say that it's 80.
Will this work?
Believe it or not, the answer is yes, this would actually work because now if I
'm getting,
if I understand that routes C and D can be reached via both directions, the
reason why
I'm favoring EIGRP to start with is because the administrative distance is more
favorable.
So this is a lower number.
But now OSPF has the lower number.
So I will actually favor going out towards OSPF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I will actually favor going out towards OSPF.
So this actually is a solution.
It's not an ideal solution, but it totally would work.
And it's again, making sure we understand what's going on that would lead us to
being
able to draw that conclusion.
Now number three here, how could VRS be used to fix the issue?
We walked through this exact scenario in a lab and we said, hey, you know what
we're
going to do is we're just going to turn this whole domain into its own VRF.
So now OSPF runs as part of a different VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now OSPF runs as part of a different VRF.
We'll call this VRF you for the underlay.
And because this VRF now is managing all of OSPF, it's managing its own routing
tables.
Now this possibility of CND existing in the overlay, it's impossible.
It can't exist in the overlay, not unless we somehow glue these VRFs together.
And so as long as these VRFs truly remain separated, CND will never be known WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so as long as these VRFs truly remain separated, CND will never be known
outside
of that VRF.
Now remember, we have to use that special tunnel VRF command to make sure that
the tunnel
is actually built from the underlay perspective, even though the tunnel must
remain as part
of the overlay VRF or potentially the default VRF.
But this is again a pretty good fail-safe, a protection mechanism is to make
sure that
the underlay is part of its own VRF.
I'd say that's a pretty good solution.
But number four is what drives at the root cause of the issue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But number four is what drives at the root cause of the issue.
It's what we just talked about.
The root cause of the issue is that for whatever reason, we are taking CND and
we're actually
advertising it into the overlay.
The VRF prevents this.
The VRF says that's not possible and that's good.
But we don't need a VRF to do that.
We could just simply stop advertising it.
Then we don't have to worry about it.
And same thing over here.
I'm assuming I must be advertising A and B into the overlay this way. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm assuming I must be advertising A and B into the overlay this way.
And once again, stop that.
Just stop advertising the underlay routes into the overlay and we won't have
recursive
routing.
So again, just walking through this real quick, changing cost and changing
bandwidth and changing
any of those kinds of things from a metrics perspective that's only going to
work if these
are the same routing protocols.
OSPF and OSPF or EIGRP and EIGRP.
Changing the cost and metrics regardless of what the goal is, if there's two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Changing the cost and metrics regardless of what the goal is, if there's two
different
routing protocols at play, that's just not going to work.
Changing a Ministry of Distance is an option.
It's not an ideal one, but it is an option.
Certainly the biggest solution is making sure we don't advertise our routes
into overlay
and underlay and vice versa.
And yes, a VRF is a great protection mechanism to help us manage that.