So we know that we can use GRE to carry our IP traffic.
And the question is, can we also use it to carry our routing protocol traffic?
And the answer is yes, we absolutely can.
This is going to be very helpful for us if we're trying to connect two
different networks
to one another.
So let's say we've got these two disparate networks with a bunch of devices and
subnets.
We'll say subnets A, B and C on the left.
Subnets D, E and F on the right.
And then we've got these routers here that have connections into those WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we've got these routers here that have connections into those
individual networks.
And then we're going to form a tunnel relationship here from one router to the
other.
At this point, everything I've drawn in yellow here, this is going to be part
of the overlay.
It's the network that we're trying to form, essentially, regardless of the
physical network
that we already have constructed.
The physical network we have constructed would be a bunch of routers down here.
And they're all connected to one another in various fashions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And they're all connected to one another in various fashions.
And so maybe it's something like this.
And this, once again, is known as the underlay.
So what we'd like to do is be able to advertise routes from one network to the
other.
So going back to our overlay network, let's say I want to run EIGRP as my
routing protocol
in this domain.
Well, I can run EIGRP and I can send my advertisements through the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, I can run EIGRP and I can send my advertisements through the tunnel
interface be received on
the other side.
So now I also know where D, E and F are on the left.
And if I advertise back the other direction, well, now I'm going to see that I
now know
where A, B and C are on my devices on the right.
So I have successfully shared routes between the two networks.
Now notice something very, very important, which ties to what we just talked
about in
the last video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the last video.
And that's that the underlay network has no clue where any of these networks
are, nor
does it need to know?
It just needs to know how to get from this router on the left to this router on
the right,
using one of the physical interfaces or potentially one of the loopback
interfaces.
But either way, we understand that we're going to have a layer three network
that needs to
converge.
As a result, we might well be running another routing protocol in here.
Maybe we're running OSPF.
It doesn't have to be the same one as the overlay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It doesn't have to be the same one as the overlay.
And so we're running OSPF and that forms convergence in this space and make
sure that
everybody knows where all of the layer three interfaces are, namely when a
packet comes
in for or into this router and it encapsulates, it needs to send it to the
tunnel interface
on the right, basically this logical interface.
Well that logical interface is it has to be accessible via a physical interface
.
Maybe it's this truly physical interface.
Maybe it's a loopback that is part of the physical device and it's part of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Maybe it's a loopback that is part of the physical device and it's part of the
underlay.
Either way, I just need to be able to get to that interface so that the router
can be encapsulate
that traffic.
So that is the responsibility of the underlay.
But this is going to lead us to a rather interesting scenario.
And the scenario is known as recursive routing.
This is a commonly cited scenario, especially when it comes to our encore
studies.
It's just something that Cisco expects us to be able to understand. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's just something that Cisco expects us to be able to understand.
Now in the real world, we're probably most likely to see this in a lab
environment truthfully
when we're playing around with tunnels and we probably are going to inject a
bad route
somewhere and cause this issue.
But it is certainly very easy to cause the issue.
We do not want to cause this in a production network, which is why we need to
know about
it.
So what exactly is this big issue?
Well it has to do with a very important rule that we need to make sure we
establish.
And that is that we cannot use our tunnel interface in order to access the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that is that we cannot use our tunnel interface in order to access the
tunnel destination.
What in the world are we talking about here?
Well let's diagram this out.
Let's say we have a simpler network than what we drew over on the left.
We just have a few routers connected here.
We want to form a tunnel relationship between routers one and three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We want to form a tunnel relationship between routers one and three.
And we have router two down here.
And let's just assign some IP addresses here.
We'll say that one, that two, that three, that four.
Now even though I use those sequentially, these would be two different subnets.
So this would be subnet A here and subnet B over on the right.
And then we've got some overlay networks on the other side of the tunnel.
So maybe subnets C and D, something like that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So maybe subnets C and D, something like that.
So I've got a packet that arrives on router one, source address from subnet C,
destination
address is going to be subnet D.
So that's great and all except we're going to encapsulate this.
And we need to send it across the tunnel.
Well in order for me to send it across the tunnel, I need to put, this is the
inner header
up here, I need the outer header to have a destination.
And this destination is going to be .4.
Which is this interface right here.
It's a physical interface.
It's part of the underlay.
I just need to make sure that I have a route to .4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I just need to make sure that I have a route to .4.
So router one's going to check its routing table.
And it's going to see that this .4, whatever the subnet is, maybe it's a slash
32, probably
more like a slash 30 or something like that.
But either way, this is going to be sent out its physical gig zero, zero
interface.
That would be this interface right here.
And it's got a next hop of router two.
Perfect.
All right, so I send that packet out to router two, and then I pass that up to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so I send that packet out to router two, and then I pass that up to
router three
and life is good.
So this would be a steady state type of situation.
Here's the question.
How exactly did I learn about this route?
Maybe I am doing something like running OSPF here in the underlay.
So this would be an OSPF route.
We have formed OSPF adjacencies here and here.
And so we know where all of these IP addresses and importantly, where all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we know where all of these IP addresses and importantly, where all of
these subnets
exist.
So again, that's perfectly fine.
This is steady state operation.
My routing table is good to go here.
But now let's say that this domain over on the right and this domain over on
the left,
that these are running EIGRP.
Because after all, we do need router one to know where subnet D is.
We need router three to know where subnet C is.
And there might be a lot of other subnets involved in all of this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there might be a lot of other subnets involved in all of this.
So how are they going to find out about this?
Well, we're going to form an EIGRP.
Neighborship across the tunnel interface, which is perfectly fine.
We just said we can enable routing across a GRE or across a tunnel interface.
And so we're going to advertise EIGRP routes across this.
So I'm going to advertise subnet D. And from router three, router one is going
to advertise
subnet C. And that's perfectly fine. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
subnet C. And that's perfectly fine.
Everything is good so far still.
But here's the question.
How exactly did we configure EIGRP?
Because sometimes EIGRP and other routing protocols will victim to this concept
of let's
advertise all routes.
That includes my connected routes.
That includes routes that are already being advertised by other protocols.
And so I might have told this EIGRP process to advertise everything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so I might have told this EIGRP process to advertise everything.
Well, router three is attached to subnet B. And so what if it actually advert
ises subnet
B across the tunnel?
Well, router one is going to receive that update, realize, oh, I can get to sub
net B.
And now remember, subnet B is right here.
Now, we probably should have just called it subnet B instead of a dot four
address.
But either way, we already have an entry for subnet B. It's via the physical
underlay,
heading to router two, learned it via OSPF.
Again, that is how it's supposed to be. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Again, that is how it's supposed to be.
But now I just learned about subnet B via EIGRP.
Well, what's the EIGRP going to, or what is that router going to do with an EIG
RP route
compared to OSPF?
Well, if I get the same subnet, I'm going to compare my administrative distance
values
with EIGRP has 90, OSPF has 110, and 90 is going to win because the lower
administrative
distance is better.
Now, I am saying I'm running OSPF in this case. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, I am saying I'm running OSPF in this case.
Maybe I have a floating static route, meaning that I've got a static route that
I manually
configure with an administrative distance of 200 or something like 250.
But either way, EIGRP will win over all of this.
So we're going to cross out our route here and change it.
And we're going to say, hey, guess what?
subnet B actually lives out the tunnel interface via router three.
And I learned that via EIGRP.
So that is a big problem because next time a packet tries to come in to router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that is a big problem because next time a packet tries to come in to router
one and
it's destined for the other side of the tunnel, well, it's going to want to
encapsulate this
and then figure out where to send it.
Well, it's supposed to send it out the tunnel interface.
Well, that doesn't make any sense.
It's almost like a chicken and egg problem here, which is, do I encapsulate it
first?
Do I send it first via the tunnel?
If I send it via the tunnel, then I've got to send it out the tunnel to get to
the other
side of the underlay, which doesn't make any sense. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
side of the underlay, which doesn't make any sense.
And what we're really doing here is we're crisscrossing our overlay and under
lay networks.
And this is a big, big problem.
This is going to break.
In fact, Cisco is running, just messaging back and forth.
It's going to recognize that this is a problem on the router.
This is going to actually generate an error message.
When that error message is going to cite the fact that there is recursive WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When that error message is going to cite the fact that there is recursive
routing.
And so because there's recursive routing happening, we are going to shut down
that tunnel interface.
Now this is not a hard shutdown situation where the tunnel interface is
actually down
down, but it is going to temporarily disable it until this issue rectifies
itself.
But here's the question.
Is it going to rectify itself?
Kind of yes, but also then kind of no. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Kind of yes, but also then kind of no.
In other words, this is going to go through a process here.
So first of all, we are going to exchange.
We've got an EIGRP route now, and we've got an OSPF route, and we're going to
choose
the EIGRP route.
Second of all, we're going to flag this error, and we're going to shut down our
tunnel interface,
which interestingly means that I'm going to lose my ERGRP route.
Because I just lost my ERGRP route, I am now back to an OSPF route, which means WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because I just lost my ERGRP route, I am now back to an OSPF route, which means
that I
can form my tunnel again.
So the tunnel connection will come back online, at which point we come all the
way back to
the start, at which point we exchange EIGRP messages.
I learn about this route via the tunnel, and I install it into my routing table
, and then
we progressively go through this looping process.
So this error is going to continuously appear, and appear, and appear, and
appear, and appear
over and over again, because we never break out of this loop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over and over again, because we never break out of this loop.
So that's why I say it kind of resolves itself, and that the tunnel is shut
down here, but
it also kind of doesn't because it'll never hit stability.
So this is certainly a problem that we need to address.
The question, with any of these kinds of situations, is how do we address it?
How do we prevent this recursive lookup issue?
So what's our prevention methods? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So what's our prevention methods?
Well, the first one is pretty simple.
We just look and see, well, what caused all of this problem?
Well, it's right here.
It's the fact that we decided to advertise an underlay route into the overlay.
And so the number one prevention is simply don't advertise the route into the
overlay.
Don't advertise underlay routes, we'll say, and especially the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Don't advertise underlay routes, we'll say, and especially the tunnel
destination.
Don't advertise those into the tunnel, and we'll say to tunnel neighbors.
This is the primary source of the problem.
If we just cut this off, then we should be good to go.
But what if, for whatever reason, we find ourselves in a sticky situation, we
can't
change the way our routing is being advertised, and we're facing this problem
in a production
network.
Well, then we're going to have to get a little bit clever. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, then we're going to have to get a little bit clever.
Now one thing we can do is compare OSPF and EIGRP, because if we're comparing
these two
routing protocols, then we know that we have an administrative distance issue
where OSPF
has a lower priority, I guess we could say a higher, higher, higher
administrative distance
of 110 versus EIGRP having 90.
And so this might be an administrative distance issue, or it could also be a
cost or metric
issue, because what if we're running EIGRP for both? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
issue, because what if we're running EIGRP for both?
Well, then I just need to make sure the tunnel has a very bad metric.
And if I'm running OSPF, then I need to make sure it has a very bad cost.
That way this path would still be preferred simply because the cost appears to
be shorter.
Now, Cisco tries to help us out with this.
This actually is the default setting for tunnel interfaces.
It's going to have a very poor metric and a very poor cost to try to help us
prevent
this issue for just happen to be running OSPF or EIGRP everywhere for the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this issue for just happen to be running OSPF or EIGRP everywhere for the
overlay or the
or and the overlay at the same time.
But we might still have to manipulate this, especially if we have multiple
tunnels or
something along those lines.
Now, lastly, we can start to put together all of the knowledge that we've been
obtaining,
and we could actually deploy a separate VRF to the overlay and a separate VRF
to the underlay.
This is pretty common in large network fabrics where we're heavily taking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is pretty common in large network fabrics where we're heavily taking
advantage of overlay
and underlay networks, especially with software defined networks.
So at that point, we have a completely separate routing domain.
And then at that point, we can't advertise from one to the other because the
interfaces
are locked to their specific VRFs.
So that would certainly be another solution as well.
But again, I do come back to the fact that if we can just not advertise that
tunnel destination
or again, the underlay network into the overlay, then at that point, we're not
going to have
this issue at all.
But we do need to be aware of it in case we see it in production networks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we do need to be aware of it in case we see it in production networks.
And of course, in case Cisco wants to make sure that we understand what's
happening here
and how to fix it.