|
0:00:12
|
So next, let's look at some cases that the tunnel can be used
|
|
0:00:17
|
to solve some of the previous problems we saw with the back-up interface
|
|
0:00:23
|
or with the routing over interfaces that do not have the Layer 2 status.
|
|
0:00:31
|
That is a good indication of the actual end-to-end reachability.
|
|
0:00:35
|
Now, we saw previously before, we solved this by using the enhanced object tracking feature.
|
|
0:00:42
|
Where we could set-up the router to ping the other end of the link.
|
|
0:00:45
|
Or we could do some sort of TCP or UDP operation to test reachability.
|
|
0:00:51
|
But before this was an option, one of the simple ways that you could make sure the link is actually up,
|
|
0:00:58
|
would be to configure a GRE tunnel between the end points.
|
|
0:01:04
|
So, we saw the case before that on router 5,
|
|
0:01:10
|
we had a primary route that was going to router 4 over the frame-relay.
|
|
0:01:17
|
And we had our back-up path that was supposed to be routing over this point-to-point link.
|
|
0:01:24
|
Now, when we do floating static routes or when we do the back-up interface,
|
|
0:01:29
|
the problem is that if router 4 looses it's interface,
|
|
0:01:33
|
it does not affect the line protocol status of router 5.
|
|
0:01:39
|
If router 5 was using a point-to-point sub-interface,
|
|
0:01:43
|
then that would be fine because the LMI is end-to-end.
|
|
0:01:46
|
The problem is that router 5 is using the main interface
|
|
0:01:50
|
whose line protocol is not going to be affected by the circuit status.
|
|
0:01:54
|
The circuit status being learned from LMI.
|
|
0:01:58
|
So, the previous solutions that we saw, one was to put back-up interface on router 4,
|
|
0:02:05
|
because router 4's sub-interface will track the line protocol status over to router 5.
|
|
0:02:11
|
The other option would be to configure some sort of IP SLA.
|
|
0:02:15
|
Then on rotuer 5, we send pings over to router 4's interface.
|
|
0:02:22
|
if we get a response back from that,
|
|
0:02:25
|
then we will install the static route that points out that interface.
|
|
0:02:29
|
If the pings fail, we're not gonna use that link.
|
|
0:02:32
|
Okay, we did that by automatically removing the static route from the table.
|
|
0:02:37
|
Now, in previous versions that did not support this,
|
|
0:02:41
|
GRE can be kind of a hack to get the same result.
|
|
0:02:46
|
What we're gonna do in this example, is between router 4 and router 5,
|
|
0:02:51
|
we have just static routing.
|
|
0:02:55
|
So, router 5 is gonna be having equal default routes
|
|
0:02:59
|
pointing out to frame-relay and the point-to-point link.
|
|
0:03:03
|
Over the frame-relay link, 4 and 5 are gonna configure a GRE tunnel,
|
|
0:03:10
|
that is used just to track the link availability.
|
|
0:03:15
|
So, whether the end-to-end reachability is actually there,
|
|
0:03:19
|
we want this to account for any potential failure case.
|
|
0:03:24
|
Whether it's on router 4's side, somewhere in the frame-relay cloud or on router 5's side.
|
|
0:03:31
|
The way that we can do this is simple enabling the keepalive feature under GRE,
|
|
0:03:37
|
which is a Layer 3 keepalive.
|
|
0:03:41
|
So, we're assuming that the Layer 3 packets are getting through,
|
|
0:03:44
|
then all of the Layer 1 and Layer 2 link statuses have to be correct in the transit path.
|
|
0:03:55
|
So, first, on router 4 and 5, I'm going to disable the dynamic routing.
|
|
0:04:01
|
So, let's remove our EIGRP process.
|
|
0:04:07
|
No router EIGRP 1.
|
|
0:04:13
|
From router 4, we should have connectivity to router 5 over the frame-relay.
|
|
0:04:19
|
And over the point-to-point link.
|
|
0:04:22
|
So, 155.10.0.5, that's the frame-relay.
|
|
0:04:27
|
155.10.45.5, that's the point-to-point link.
|
|
0:04:32
|
So,both of those interfaces are fine.
|
|
0:04:36
|
Next, we're going to configure a tunnel. We'll say, Interface Tunnel 45.
|
|
0:04:40
|
The tunnel source is my IP address that I have configured on the frame-relay interface.
|
|
0:04:47
|
The tunnel destination is router 5's frame-relay.
|
|
0:04:53
|
So, 155.10.0.5
|
|
0:04:56
|
And I want tunnel keepalives on here.
|
|
0:05:00
|
Let's say, "Keepalive every 2 seconds",
|
|
0:05:03
|
and I'll do three retries before the neighbor declares down.
|
|
0:05:13
|
On router 5, we'll essentially do the same thing.
|
|
0:05:15
|
Interface tunnel 45.
|
|
0:05:18
|
The tunnel source is my frame-relay interface.
|
|
0:05:23
|
The tunnel destination is router 4's frame-relay.
|
|
0:05:30
|
I have keepalives every 2 seconds with three retries.
|
|
0:05:35
|
Now, I don't need to configure any type of payload protocol.
|
|
0:05:39
|
Whether be IPv4, IPv6, etc.
|
|
0:05:42
|
Because we're only using the tunnel as a check in the routing table
|
|
0:05:49
|
to figure out, should we use the primary frame-relay link?
|
|
0:05:54
|
Or should we fail over to the secondary interface?
|
|
0:06:00
|
So, we should see that the line protocol of tunnel 45 is up if we have end-to-end connectivity.
|
|
0:06:08
|
So, let's say, "Show Run Interface Tunnel 45"
|
|
0:06:14
|
And the same thing on router 4. Show Run Interface Tunnel 45.
|
|
0:06:29
|
If we Show Run Interface Tunnel 45,
|
|
0:06:39
|
it says, "The keepalive is 2 seconds. Retry's are three."
|
|
0:06:46
|
Which should be fine. Let's say Show...
|
|
0:06:51
|
I don't believe there's a way that we can verify...
|
|
0:07:00
|
whether the keepalive is actually working or not.
|
|
0:07:01
|
Let's say Debug... Is there a tunnel debug?
|
|
0:07:05
|
Debug Tunnel Keepalives.
|
|
0:07:16
|
So, 4 is sending keepalives to 5.
|
|
0:07:22
|
Now, 5 is sending those to 4.
|
|
0:07:26
|
Let's see on 5. Debug Tunnel Keepalives.
|
|
0:07:37
|
And 4 is sending those to 5. So, the link should be up here.
|
|
0:07:56
|
So, this means one or two things then,
|
|
0:07:58
|
either I need the payload protocol or the timers for the keepalives are too small.
|
|
0:08:06
|
So, let's try this first. Let's go to the tunnel and say, No Keepalive
|
|
0:08:11
|
And then I'll change it to whatever the default values are.
|
|
0:08:15
|
So, I'm taking it off then turning back on.
|
|
0:08:17
|
If we Show Interface Tunnel 45,
|
|
0:08:21
|
it says, "The Keepalives are set to 10 seconds with 3 retry's."
|
|
0:08:27
|
Let's try the same thing on router 4 here.
|
|
0:08:32
|
So, on tunnel 45, No Keepalives and then Keepalives
|
|
0:08:49
|
Now, the tunnel protocol is up.
|
|
0:08:53
|
So, it's possible that it doesn't support timers that small,
|
|
0:09:01
|
which then is gonna mean that...
|
|
0:09:03
|
we would have convergence issues.
|
|
0:09:05
|
That eventually, this configuration is gonna work,
|
|
0:09:09
|
but it wouldn't be valid for any type of real high availability.
|
|
0:09:17
|
So, let's look on router 5 and do the same thing. Show IP Interface Brief.
|
|
0:09:21
|
It still says the tunnel is down.
|
|
0:09:29
|
Let's try this. Let's just add a subnet to it. We'll say, Interface Tunnel 45.
|
|
0:09:34
|
IP Address...
|
|
0:09:37
|
45.0.0.5.
|
|
0:09:41
|
And then, on router 4,
|
|
0:09:47
|
IP Address 45.0.0.4.
|
|
0:09:55
|
So, can I ping 45.0.0.5?
|
|
0:10:01
|
And I may need to shut this down and bring it back up on both sides.
|
|
0:10:27
|
So, it's been re-enabled here. Let's see now, can...
|
|
0:10:30
|
can we ping 45.0.0.4? Which we can. So, the tunnel is working.
|
|
0:10:36
|
We would not get a reply back from the ping if the tunnel wasn't up.
|
|
0:10:40
|
Let's see, that in 30 seconds, the line protocol should stay up.
|
|
0:10:44
|
If it goes down for some reason, it probably means that these routers need to be reloaded.
|
|
0:10:49
|
Because the keepalive, there's really not much configuration for it. It's just whether it's on or off.
|
|
0:10:55
|
So, if we Show IP Interface Brief, now, the tunnel is up.
|
|
0:11:02
|
Okay, the actual implementation of this is that we could go two different ways.
|
|
0:11:06
|
We could use it to do floating static routing,
|
|
0:11:11
|
or we could use it to do the Backup Interface.
|
|
0:11:15
|
In the Backup Interface variation, I would go to the tunnel
|
|
0:11:21
|
and say, "The Backup Interface...
|
|
0:11:25
|
is the secondary link."
|
|
0:11:29
|
So, in this case, the Backup Interface command doesn't go directly on the frame-relay.
|
|
0:11:33
|
It goes on the tunnel interface that is tracking the frame-relay.
|
|
0:11:40
|
Because now, if router 4 looses its frame-relay connection.
|
|
0:11:47
|
So, 4 has no longer reachability frame-relay cloud.
|
|
0:11:50
|
This then means...
|
|
0:11:53
|
that router 5 is not going to be able to reach that address
|
|
0:11:57
|
on router 4,
|
|
0:12:00
|
which in turn should cause the tunnel to go down,
|
|
0:12:05
|
because we no longer have reachability to 45.0.0.4.
|
|
0:12:11
|
And since we are running keepalives over the tunnel,
|
|
0:12:14
|
it means the line protocol, the tunnel is gonna go down,
|
|
0:12:17
|
which then it turn should activate the secondary link.
|
|
0:12:22
|
Again, really, the only issue with this is that it's gonna be slow to converge.
|
|
0:12:26
|
So, if we Show Interface Tunnel 45,
|
|
0:12:30
|
it's not until we have three retries of keepalives every 10 seconds that we're gonna figure this out.
|
|
0:12:39
|
So now, we did.
|
|
0:12:40
|
The tunnel goes down,
|
|
0:12:42
|
which means now, the secondary link is being activated.
|
|
0:12:47
|
Assuming that we have a route that points out serial 0/1/0,
|
|
0:12:53
|
then this is gonna be valid.
|
|
0:12:59
|
The other variation...
|
|
0:13:02
|
would be to actually route traffic out the tunnel.
|
|
0:13:06
|
So, if I were to say on router 5 that I had two default routes,
|
|
0:13:12
|
one that goes on...
|
|
0:13:15
|
tunnel 45.
|
|
0:13:17
|
One that goes on the point-to-point link.
|
|
0:13:23
|
Actually, the one with the point-to-point link, this would have a higher distance.
|
|
0:13:26
|
So, we'll say distance of 2, or whatever distance of 2 there.
|
|
0:13:31
|
So, the first...
|
|
0:13:34
|
route here, this would only be installed if the tunnel's line protocol was up.
|
|
0:13:42
|
The second one would only we installed if the first route is not installed.
|
|
0:13:49
|
Because it has the higher administrative distance.
|
|
0:13:53
|
The disadvantage then on this design,
|
|
0:13:56
|
so if we Do Show Run Include IP Route
|
|
0:14:03
|
is that when we're routing traffic over the tunnel,
|
|
0:14:07
|
we're adding additional encapsulation overhead.
|
|
0:14:11
|
So anytime we go over GRE,
|
|
0:14:14
|
just like we looked at before with the PPP over Ethernet, or the PPP over frame-relay,
|
|
0:14:19
|
it means that the payload MTU has to be lowered.
|
|
0:14:24
|
So, for each GRE encapsulation, then, it's gonna add the additional overhead.
|
|
0:14:32
|
Now, there is a question here...
|
|
0:14:37
|
"Could you draw a... What would the...
|
|
0:14:40
|
the packet encapsulation look like if we're doing GRE versus IP and IP?"
|
|
0:14:47
|
This, I don't know off hand what the frame format is, but let's look this up. Let's say...
|
|
0:14:54
|
GRE Packet Format.
|
|
0:14:59
|
And we'll assume that Wikipedia is right here.
|
|
0:15:01
|
And then...
|
|
0:15:04
|
IP in IP Tunnel...
|
|
0:15:10
|
Packet Format.
|
|
0:15:19
|
So... Let's see, if we look at the...
|
|
0:15:25
|
IP protocol number assignments
|
|
0:15:31
|
which should be on the IANA website.
|
|
0:15:37
|
Then, I wanna know what is the protocol number for IP and IP.
|
|
0:15:41
|
I know with GRE, GRE is 47 here.
|
|
0:15:46
|
But the IP and IP tunnel,
|
|
0:15:58
|
is... Is it this one, 4?
|
|
0:16:04
|
IP within IP encapsulation.
|
|
0:16:13
|
This document specifies a method by which an IP datagram maybe encapsulated (carried as a payload) within an IP datagram.
|
|
0:16:19
|
Now, the way that we could test this out...
|
|
0:16:22
|
would be to do the debug. So, let's go back to...
|
|
0:16:29
|
Let's go back to the command line here, and what I'm gonna do is on...
|
|
0:16:35
|
router 5,
|
|
0:16:39
|
I'm gonna configure on IP and IP tunnel that goes to router 6.
|
|
0:16:44
|
So, I need to know from 5's perspective, which way does it route traffic to get to 6?
|
|
0:16:54
|
So, from 5, let's say Trace 150.10.6.6.
|
|
0:17:02
|
Okay it goes to 4,
|
|
0:17:05
|
and then, 4 doesn't know what to do with it.
|
|
0:17:07
|
Okay, the reason why is that these neighbors stopped running EIGRP. So, let me run that again.
|
|
0:17:13
|
Router EIGRP 1.
|
|
0:17:15
|
Network 155.10.
|
|
0:17:27
|
Then, I'll trace to 150.10.6.6.
|
|
0:17:33
|
Okay, it says "I go to...
|
|
0:17:36
|
router 1 and 2,
|
|
0:17:40
|
then, to router 3, then to switch 1, then to router 6.
|
|
0:17:44
|
So, in either case, no matter where the packets are going in on the first hop, they're transiting router 3.
|
|
0:17:49
|
So, router 3, I'm gonna use this for my debug.
|
|
0:17:53
|
I don't wanna see EIGRP packets here.
|
|
0:17:57
|
So on router 3, I'm gonna create an access list.
|
|
0:18:00
|
So, Access List 101. That denies EIGRP.
|
|
0:18:05
|
And then, Access List 101 Permits IP Any Any.
|
|
0:18:10
|
I'l say, Debug IP Packet Detail 101.
|
|
0:18:16
|
Okay, next on router 5, I'm gonna configure the tunnel.
|
|
0:18:20
|
We'll say, Interface Tunnel 56.
|
|
0:18:26
|
IP address is 56.0.0.5.
|
|
0:18:32
|
The tunnel source is my loopback. The tunnel destination is...
|
|
0:18:38
|
6's loopback, but the tunnel mode...
|
|
0:18:43
|
is an IP over IP tunnel. So, it's not a GRE tunnel anymore.
|
|
0:18:50
|
Router 6 is gonna do the same thing.
|
|
0:18:53
|
Interface Tunnel 56. IP address is 56.0.0.6.
|
|
0:19:02
|
The tunnel source is my loopback zero. The tunnel destination is...
|
|
0:19:07
|
5's loopback.
|
|
0:19:10
|
Tunnel mode is IP and IP.
|
|
0:19:13
|
So now, we should know, if I can ping 56.0.0.5...
|
|
0:19:17
|
from router 6,
|
|
0:19:20
|
it means the tunnel is working.
|
|
0:19:33
|
Okay, the tunnel is not up.
|
|
0:19:35
|
Next thing I would wanna check here is probably what?
|
|
0:19:39
|
If I can send traffic over the tunnel itself,
|
|
0:19:43
|
I probably wanna know,
|
|
0:19:45
|
can I send it between what's supposed to be the tunnel end points.
|
|
0:19:49
|
So, my end point from router 6 is my local loopback.
|
|
0:19:53
|
I'm going to 5's loopback.
|
|
0:19:55
|
So, I wanna know, can I ping 5's loopback...
|
|
0:19:59
|
when I source traffic from my own?
|
|
0:20:04
|
And I can't. There's some sort of transport problem here.
|
|
0:20:07
|
Probably next thing I wanna check is do I actually have a route to that?
|
|
0:20:14
|
To 5's loopback.
|
|
0:20:16
|
Which I don't.
|
|
0:20:19
|
And in this case, it's because I didn't put the network statement under EIRGP.
|
|
0:20:27
|
I put the 155, I didn't put the 150 for the loopback.
|
|
0:20:30
|
So let's say on EIRGP 1,
|
|
0:20:33
|
Network 150.10.0.0.
|
|
0:20:38
|
0.0.255.255.255.
|
|
0:20:51
|
So, ideally, we should learn about...
|
|
0:20:55
|
5's loopback, and now, the tunnel is working.
|
|
0:20:58
|
Okay, so now, there's nothing wrong with the tunnel transit.
|
|
0:21:01
|
We should see now on router 3...
|
|
0:21:06
|
what the IP protocol number is.
|
|
0:21:09
|
So, in this case, it is 4.
|
|
0:21:13
|
So, that's what the RFC is referring to here, which is 2003.
|
|
0:21:17
|
So, let's see in here, does it show the actual packet format?
|
|
0:21:26
|
It says, "The outer IP header source address and destination address identified the end points."
|
|
0:21:32
|
Which is fine.
|
|
0:21:41
|
Don't they have just a diagram of it here?
|
|
0:21:46
|
No, they don't.
|
|
0:21:47
|
Let's see...
|
|
0:21:51
|
IP in IP header format...
|
|
0:22:01
|
about IP protocol 4.
|
|
0:22:05
|
Now, that would be for IPv4.
|
|
0:22:07
|
|
|
0:22:13
|
Let's try IP Protocol Number 4.
|
|
0:22:33
|
So, somewhere here, you would be able to find the packet format, but the key difference...
|
|
0:22:39
|
is that when you look at the...
|
|
0:22:44
|
the total structure of the packet. Let's say this first one is gonna be the GRE...
|
|
0:22:49
|
Packet.
|
|
0:22:51
|
And the second one is the IP and IP.
|
|
0:22:56
|
So, on the outer header, we have the IP...
|
|
0:23:03
|
GRE header, which is protocol number 47.
|
|
0:23:09
|
Followed by the inner IP packet, and then, the actual payload.
|
|
0:23:13
|
So, let's say it's web browsing traffic.
|
|
0:23:18
|
For the IP in IP tunnel,
|
|
0:23:22
|
the outer protocol would be 4. So, IPIP.
|
|
0:23:27
|
The inter-header is the original header, and then followed by the actual payload.
|
|
0:23:34
|
I wanna say that when you look at the second one...
|
|
0:23:38
|
with the packet format, I believe that this header is smaller encapsulation wise than the GRE header,
|
|
0:23:46
|
which makes the second option more efficient.
|
|
0:23:50
|
The problem though is that the payload of the IP and IP tunnel cannot be non-IP packets.
|
|
0:24:00
|
So, this would mean, if you wanted to tunnel IPv6,
|
|
0:24:05
|
or CLNS for IS-IS routing, or maybe some legacy stack like IPX,
|
|
0:24:12
|
these ones wouldn't work with the GRE tunnel,
|
|
0:24:16
|
because it's a generic encapsulation.
|
|
0:24:18
|
It would not work with the IP and IP tunnel.
|
|
0:24:23
|
The same difference would be true when we do IPv6 tunneling.
|
|
0:24:29
|
IPv6 over IP.
|
|
0:24:33
|
If we say Interface Tunnel 1.
|
|
0:24:36
|
The tunnel mode is IPv6 IP,
|
|
0:24:43
|
this means that the transport is IPv4.
|
|
0:24:49
|
The payload is only an IPv6 packet.
|
|
0:24:53
|
The case where this would be a problem...
|
|
0:24:57
|
is that if you're using IS-IS as your IPv6 routing protocol.
|
|
0:25:01
|
As your IPv6 IGP.
|
|
0:25:05
|
Because IS-IS is not an IP protocol, it's part of the CLNS stack.
|
|
0:25:09
|
So, when you look at the...
|
|
0:25:12
|
the routing protocol as the payload of the tunnel,
|
|
0:25:15
|
this mode would not support it.
|
|
0:25:18
|
Only the GRE mode would.
|
|
0:25:23
|
But other than that, the functionality is gonna be the same.
|
|
0:25:26
|
So, behind the scenes, they're encapsulatedly different,
|
|
0:25:28
|
but the end result is the same.
|
|
0:25:31
|
Now, the case where you might need to know this
|
|
0:25:34
|
is if you're doing some sort of security filtering.
|
|
0:25:37
|
So, if you have a GRE tunnel, or an IP and IP tunnel, or an IPv6 IP tunnel,
|
|
0:25:45
|
and you're doing an access list, or maybe Zone-Based Policy Firewall,
|
|
0:25:49
|
we would then need to manually permit this traffic through.
|
|
0:25:57
|
Then, likewise, the IPv6 IP tunnel,
|
|
0:26:01
|
that has its own protocol number. So, if we look at the...
|
|
0:26:05
|
again the IP Protocol Number Assignments,
|
|
0:26:17
|
number 41 is IPv6 IP.
|
|
0:26:23
|
So, if we said on the tunnel interface, in the tunnel mode, IPv6 IP,
|
|
0:26:27
|
then, it's using this number, 41.
|
|
0:26:30
|
If we don't say anything, then it's using 47,
|
|
0:26:34
|
which is the general or the generic routing encapsulation.
|