Well next up is forming GRE tunnels and so the topology we're going to use for
this is going to involve routers 3 and 4 and they're going to hop through
routers
1 and 2 down here we'll call this the underlay and we're going to form this
tunnel connection between the two routers and we've got some subnets back
here and the idea is that we are going to want to form an EIGRP relationship
across this tunnel so this will be some amount of EIGRP happening. So from a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
across this tunnel so this will be some amount of EIGRP happening. So from a
subnet perspective we are going to see that we've got a 10.0.13.0 all these are
/24, 10.0.24.0.4 for router 4.3 for router 3 and we're going to use these as
our tunnel source and destination interfaces so we're going to communicate
through this physical underlay network and form a logical tunnel connection and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
through this physical underlay network and form a logical tunnel connection and
this tunnel is going to be 10.0.34.0 with again .3 and .4 on the tunnel
interface. So the way we form GRE tunnels is truly by forming a tunnel
interface it's
sort of like creating a loop back I can just create whatever tunnel interfaces
I
want and then I have to tell the tunnel how to actually form connections. So
let's go ahead and do that here. I'm going to start on router 3 and on router
3 do a config T and get onto a tunnel interface. So I can just do T0 I can type WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
3 do a config T and get onto a tunnel interface. So I can just do T0 I can type
tunnel if I want to I can pick a number depending on the platform. We've got
some
very high quantities of numbers here as options. I'm just going to be boring
and
choose interface tunnel 0 and then from here I can apply an IP address just
like
I would any other interface. So this is again 10.0.34.3 and we said that is a
/24. But at this point the tunnel has to know how to connect and so I'm going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
/24. But at this point the tunnel has to know how to connect and so I'm going
to
say tunnel source to specify how I'm going to source this traffic. I do a
question mark we'll see that I can specify an IP address right up here at
the top which is how I usually like to do it. It feels a lot more intentional
to
choose the IP address because that way I can make sure it matches the
destination
of the remote tunnel. But we can also specify a physical interface here I could
do gigabit 1/0 is that interface but I am just going to specify 10.0.13.3 as
the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the
source and for the destination it has to be an IP address because I can't
specify
the interface of the remote device so that would be 10.0.24.4. So from here I'm
going to just make sure that I can ping the tunnel destination from my source
which I
specified is 10.0.13.3. All right good. So I can ping from this interface on
the
left to this interface on the right from a physical perspective. Probably
should
have checked that earlier but hey now we know for sure that it's going to work. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
have checked that earlier but hey now we know for sure that it's going to work.
But if I do a show interface tunnel 0 here it's showing up and up right now
it's probably going to switch over to up down. The tunnel interface is like to
be
optimistic and when we first configure them it tries to be in an upstate and
the reality is that it will eventually realize that the other side is not
configured. So let's go and configure the other side router 4 here interface t0 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configured. So let's go and configure the other side router 4 here interface t0
again IP address 10.0.34.4/24. And this is where I can specify
tunnel source again I'll just do the IP address. That's how I prefer to do it.
And then tunnel destination 13.3. And that should be it. And here we go tunnel
is
changed to up and so show interface tunnel 0. This is showing up let's go
over to router 3 here looks like router 3 never actually took the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over to router 3 here looks like router 3 never actually took the tunnel
interface
down so that's not a bad thing. Let's see if we can ping across the tunnel. So
I
should be able to ping 34.4 because that is a directly connected route and I
can.
What do I mean by directly connected route? Well again router 3 and router 4
are not directly adjacent and I'm not running a routing protocol that's
advertising this tunnel subnet. So I can't just ping router 4 because it's
directly connected and yet I can because it's air quotes directly connected it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
directly connected and yet I can because it's air quotes directly connected it
's
directly connected via the tunnel subnet. If I do a show IP route here we will
see that the tunnel subnet dot 34 right here is now a directly connected
route on both sides. And so we have formed this tunnel and the way that it
works is I
send my encapsulated traffic into the underlay router 1 and router 2 are going
to see the
destination of 10 0 24 dot 4 not caring that I'm trying to send it to 34 dot 4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
destination of 10 0 24 dot 4 not caring that I'm trying to send it to 34 dot 4.
And so they see 24 dot 4 they know how to get to 24 dot 4 because we're running
OSPF on those routers and it eventually lands on router 4
encapsulates it see it's destined for its tunnel interface. So that is exactly
how
tunneling is configured and how we can go about doing this. So we want to also
go
ahead and establish routing across this. If I do a show IP
eigrp neighbor on router 3 I do see a connection that would actually be router WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
eigrp neighbor on router 3 I do see a connection that would actually be router
5 I think on the other side router 5 yes so router 5 is hanging out over here
forming an eigrp connection here eigrp but we want eigrp to go everywhere and
across the tunnel.
So fortunately GRE supports that we're going to now configure eigrp to form a
relationship
across the tunnel. So I can get on to router eigrp and I'm running autonomous WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
across the tunnel. So I can get on to router eigrp and I'm running autonomous
system 10 in this
environment and I can add that as a network statement network 10 dot 34 dot 3
all zeros for the wildcard mask to specify only want to activate the interface
that has
that exact IP address on it again that's how I like to do my network statements
for eigrp
and then router 4 router eigrp autonomous system 10 network 10 dot 0 dot 34 dot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and then router 4 router eigrp autonomous system 10 network 10 dot 0 dot 34 dot
4 all zeros.
So now yep very quickly eigrp is very very fast so if I do a show IP eigrp
neighbor for
router 4 I now see that I've got a connection going the other way that would be
router 6 over on the
right and then we have a neighbor across the tunnel. So very cool we are taking
routes all the way
over here from router 5 sharing it to router 3 across the tunnel to router 4
and again router 1
and router 2 are not at all aware of any of the routes being shared across that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and router 2 are not at all aware of any of the routes being shared across that
tunnel. So if I
do a show IP route eigrp we'll see that we've got some loopbacks in here from
router 5 and router 6
and again physically the routing information is being shared across the under
lay but logically
it bypasses the underlay. So if I go over to router 1 for example I mean I'm
not even running eigrp
so if I do a show what was I doing to do there show yeah IP eigrp neighbor hold WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so if I do a show what was I doing to do there show yeah IP eigrp neighbor hold
up there we go
and I got nothing. So if I do a show IP route I would not expect to see the 5s
or the 6s in there
for those loopback addresses and indeed I don't the underlay is completely
unaware. So at this
point one thing to keep in mind that we had mentioned earlier if I do a show
interface on the tunnel
t0 here notice that the delay is set to 50 000 microseconds that is really high
and the bandwidth is
set to 100 kilobits per second even though we're running across the gig it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set to 100 kilobits per second even though we're running across the gig it's
set to 100k not even
100 megs 100k. Why are the bandwidth and delay set to being so bad? Well the
reason for that is
because Cisco is trying to anticipate a scenario where we do run eigrp over the
underlay and so if
router 3 is running eigrp to router 1 and router 4 then all of a sudden I'm
going to be sharing
my underlay routes via the overlay. I will be telling router 4 that hey just so WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
my underlay routes via the overlay. I will be telling router 4 that hey just so
you know I've got
this great 10.0.13 subnet attached to me. Router 4 we know recursive routing
can happen if we see
the tunnel destination through the tunnel. We can't loop that around we have to
see separate routes
there and so Cisco is trying to prevent that scenario so if we were truly to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
there and so Cisco is trying to prevent that scenario so if we were truly to
take our routes
here and let's just say I advertise it both ways I advertise it this way and I
advertise it this
way. Well at that point router 4 running eigrp both directions would have to
decide which of those
routes to accept. Well which ones are going to accept if it's just running the
same routing
protocol everywhere? Going to be the one with the best metric. The Cisco is
trying to say hey this
tunnel is a bad choice. We don't want to use this tunnel unless it's the only
other path and so the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
other path and so the
idea here is simply that if we do have an underlay path, a path outside the
tunnel we should always
take that which is usually what we want to do. So we're saying hey this is a
really bad path
it's really bad because we have bad bandwidth and bad delay and therefore
router 4 will continue
to send this way even if we do accidentally advertise a route that we shouldn't
have advertised. Clean
up our drawing here a little bit and so that's something to keep in mind there.
Now it's important WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now it's important
to recognize that tunnels support VRFs and they support them in two different
ways. First of all
I can place this tunnel into a VRF if I wanted to. Let's just showcase this
here. So I could do a
config T interface tunnel 0 and do my VRF forwarding command and now I could
actually place the tunnel
interface into a separate VRF entirely. Here's what's interesting. I might also
have a situation
where I place the underlay into a separate VRF and this is just a little bit of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where I place the underlay into a separate VRF and this is just a little bit of
a spoiler alert here
exactly what we're going to do in the coming challenge. I'm going to create an
underlay VRF
to make sure that I don't create recursive routing. It's a great security
mechanism for this type
of scenario. The question is how do I tell a tunnel interface here that's part
of one VRF,
part of the default VRF, to use an interface that's in a completely different
VRF? Well fortunately WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
VRF? Well fortunately
Cisco does actually give us a command for this and it is VRF tunnel VRF and
then I can specify the
VRF for forming the tunnel without changing the VRF that the tunnel belongs to.
Now I can use both
of these commands. I can place the tunnel into a VRF and I can tell the tunnel
to use a completely
different VRF for forming the tunnel. So keep this in mind as we go into the
next lab challenge
this is going to be very very important. Now one last thing has to do with MTU. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this is going to be very very important. Now one last thing has to do with MTU.
So if I were to
actually let's just go ahead and switch over to router 5 here. So router 5
should be able to
ping router 6 and indeed it can. It's going across the tunnel to be clear. So
if I were to say let's
ping this with an MTU of 1500. Oops. Alright so let's bring this back up
because I accidentally
hit control W which actually closes the window whereas if you're actually using WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hit control W which actually closes the window whereas if you're actually using
an iOS device it
deletes a word. So naturally I was saying MTU 500 or 1500 and I should have
said size 1500
and now we sent a ping that actually uses 1500 bytes. So here's the question.
Did this get
fragmented by going across the tunnel? Well the way to find that out is by
setting the do not
fragment bit. So I can say DF bit here and now we're getting MTU responses WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
fragment bit. So I can say DF bit here and now we're getting MTU responses
through ICMP saying hey
that is too big to pass through without fragmenting. So we were fragmenting.
These are getting
fragmented. When we said hey don't fragment then we see the problem. If I were
to say let's just do
1400. Yeah it still went through no problem. So clearly there's a problem with
sending a 1500
byte packet across the tunnel. So the question is how do we fix this? There's a
lot of misinformation WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lot of misinformation
that exists around how to fix this. If I were to do a show interface tunnel
zero we see that this
tunnel interface has a really weird MTU that was generated. So I could get on
there and get
onto the tunnel interface and say hey I want to change this MTU. Yeah MTU and I
'm going to call
this I could do 1500 but what we'll find is that it needs to be 1476. Why 1476? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this I could do 1500 but what we'll find is that it needs to be 1476. Why 1476?
Well think about
the math. We have said that GRE takes four bytes and the second IP header takes
20 bytes. So that's
a total of 24 additional bytes. So we have to configure for 1476 at max. So is
that going to solve
our problem? If I do a show interface tunnel we see yeah the MTU here is listed
as a layer two MTU.
It's not the layer three MTU. So show run interface tunnel zero and there's our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's not the layer three MTU. So show run interface tunnel zero and there's our
layer three MTU. So
pay attention to that. So now did that solve our problem? It did not. Why didn
't it solve our problem?
Well because this command doesn't actually prevent fragmentation. It just
changes when fragmentation
occurs. If we think about it getting it at the tunnel interface says that hey
our MTU this is going
to exceed our MTU we'd better fragment it before we send it on. If the MTU were
1500 on the tunnel WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1500 on the tunnel
the tunnel would have no problem with this. It would encapsulate it send to the
physical interface
at 1524 and the physical interface says oh I need to fragment it. And so it's
just sort of an order
of operations here and it is usually better to fragment it on a physical
interface rather than
on a logical tunnel interface. It's just better from a resources perspective.
So we will get better
performance this way but fragmentation is still occurring. So what is the
solution? How do we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
solution? How do we
prevent fragmentation? The way we do that is by actually increasing the MTU to
1524 on the underlay.
If we can do that and have it just pass through without fragmenting then at
that point we're good
to go so long as the system allows us to change the MTU on the tunnel interface
to prevent being
fragmented there. But just be aware that this command setting the MTU to 1476
does nothing to
prevent fragmentation but it does change how fragmentation occurs on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
prevent fragmentation but it does change how fragmentation occurs on the
platform.