All right, let's take a look at a network topology here that involves tunnels
and make sure we
understand how tunneling architecture comes together, especially around the
concept of
recursive routing.
So our topology here is that we have OSPF running across the overlay, and then
down here in the
underlay we're running EIGRP.
So router one and router three, they're running both of these routing protocols
, whereas router
two is only running EIGRP.
So we also have to understand that we're advertising all connected routes into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we also have to understand that we're advertising all connected routes into
both routing protocols.
That is not ideal because that means that I'm taking this 10.1.1.0 subnet and
advertising
it into EIGRP.
Well router two doesn't need to know about this.
If both of these are doing this, then that means that I'm actually learning
about both
of the overlay subnets on router two, whereas normally that wouldn't be needed.
And so this is not a particularly ideal situation, a setup.
So answer the following questions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So answer the following questions.
Question number one here, given the current topology is routing recursion
expected, why
or why not?
Well any time routing recursion occurs, we know that we are taking the tunnel
destination,
probably this physical address, and we're advertising it across the tunnel.
And here's the key point.
Number one, I advertise it, but number two, I decide to take it.
If I add the tunnel destination into my routing table to say that the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I add the tunnel destination into my routing table to say that the
destination needs to
go out the tunnel interface, that's a problem.
That's what causes recursive routing and we don't want that.
In this situation, do we expect this?
Well we've just said that we're advertising all of the connected routes.
So number one is true.
I'm taking this physical interface that's in the underlay and I'm advertising
it into
the overlay, which is not good.
So here's the question, do we see number two take place?
And in this situation, believe it or not, the answer should be no. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in this situation, believe it or not, the answer should be no.
Now this does rely on a couple of assumptions, the biggest of which is that we
have not changed
administrative distance, but router one's routing table is going to be
determined based
on, as we've said before, a couple of these other tables.
So we have an EIGRP table known as the topology table, we have an OSPF database
, and both
of them are going to claim to have a particular route, this 192.168.23 subnet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of them are going to claim to have a particular route, this 192.168.23 subnet.
So router one is trying to decide how do I get to this subnet?
I have routes from both routing protocols and based on administrative distance,
EIGRP
being 90, OSPF being 110, I would favor the EIGRP route, which actually goes
into the
underlay.
So even though we're setting up a recursive routing challenge, the answer here
is actually
no.
We're not going to expect recursive routing simply because we happen to see
that the
administrative distance is aligning in our favor. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
administrative distance is aligning in our favor.
If these routing protocols were flipped, well then we would see recursive
routing because
we would prefer EIGRP in either scenario and if EIGRP says to go through the
tunnel, then
we would take that path.
Now question number two, without changing routing protocols, what is a
recommended change to
this setup?
So we keep OSPF and EIGRP where they are, what should we change?
Well the good news is recursive routing is not occurring, but we are still
setting ourselves
up for failure here if something were to change in the future. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up for failure here if something were to change in the future.
So what should we change?
Well we should stop advertising this underlay route into the overlay.
Overlay routes should only go to overlay devices and underlay to underlay.
So this is what we would want to change.
If we're going to change anything, it would be stop advertising all connected
routes into
both routing protocols, only advertise underlay routes to EIGRP and only
advertise overlay
routes to OSPF, even though both of these routers, router one and router three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
routes to OSPF, even though both of these routers, router one and router three
are running
both routing protocols, we can make sure that we are keeping it clean.
Now if we want to really make it clean, here's where number three comes in,
which is asking
hey how could we use VRFs in order to really clean this up?
Well VRFs create two completely different routing domains and this is one
application,
especially in modern architectures where we might actually want to deploy VRFs
within
an enterprise and that is to separate out overlay and underlay.
So I could create a VRF here in the underlay and that would be a completely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I could create a VRF here in the underlay and that would be a completely
different routing
domain.
EIGRP would operate within that VRF.
I wouldn't need to worry about accidentally advertising overlay routes into EIG
RP because
they just don't exist in that routing domain.
And then of course I could also create a VRF that spans the entire overlay,
making sure
that the tunnel and those connected subnets are all part of that VRF. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that the tunnel and those connected subnets are all part of that VRF.
So we've got ways to keep this environment clean.
This is going to again especially come into play when we talk about LISP and
the XLAN
and other tunneling mechanisms, but do keep in mind that we want to make sure
we're
keeping our overlay completely segmented from our underlay when we're using
tunnel architectures.
It'll keep things clean, but it will also help to prevent that recursive
routing issue
from occurring.
And just in case the administrative distance situation doesn't work out in our
favor.
I hope this has been informative for you and I'd like to thank you for viewing.