Tags

, , ,

Generic Routing Encapsulation –  It’s a way to encapsulate packets inside a transport protocol. GRE acts like PPP and it’s done between 2 endpoints, so we can throw almost any type of traffic inside a GRE Tunnel, this is also a way where New York and London can be neighbors through EIGRP or OSPF and they can form a relationship easily by the help of GRE Tunnel and IPSec, in case you want the traffic to be encrypted.

GRE is considered stateless, and what does this mean, it means that it does not keep track of the other end of the Tunnel by default, or in other words, the other end might be down but the local Tunnel Interface it’s still up.

There are few reasons why the State is Up and the Line Protocol is Down:

Tunnel1                    192.168.1.1     YES manual up                    down

1 – There is no route to the other end of the Tunnel, including a Default Route

2 – The Interface which serves as the Tunnel Source is Down

3 – The Tunnel Destination is through the Tunnel itself.

I will post an example below of a GRE Tunnel between 2 Routers and some other specifications:

20170604_181940

I got a GRE Tunnel established between R1 and R3.

Here’s the configuration:

R1#sh run int tun 1
!
interface Tunnel1
ip address 192.168.1.1 255.255.255.252
tunnel source Loopback0
tunnel destination 3.3.3.3
!
end

And on R3:

R3#sh run int tun 1
!
interface Tunnel1
ip address 192.168.1.2 255.255.255.252
tunnel source Loopback0
tunnel destination 1.1.1.1
!
end

I’m running EIGRP also on all interfaces on every Router. Let me show you, why did I mention in the begginning of this article that GRE it’s stateless. As you can see the Tunnel between R1 and R3 is established using R1’s source Loopback 0 1.1.1.1 and R3’s source and R1’s destination Loopback 0 3.3.3.3. The behaviour of the Tunnel itself is interesting as you’re trying different things with it.

The Tunnel Destination doesn’t need to be reachable, it just needs to be routable. So for example on these R1 and R3 if I have a default route or a static route to the Tunnel Destination, the Tunnel is UP/UP and stays fine and the connection is fine, when pinging the Tunnel Destination from Loopback source or from Tunnel itself.

I the case below I got a static route on R1 to R3’s Loopback. On R3 to R1’s Loopback. And on R2 to R1 and R3’s Loopbacks respectively.

All works fine, see below:

R1#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
R1#ping 3.3.3.3 source tun 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/55/56 ms

With the default configuration of the GRE Tunnel on both R1 and R3, when I shut down R3’s Loopback Interface, R1 simply doesn’t care and it keeps the Tunnel Up even when the Tunnel is down on R3 because the source interface of R3 is down itself:

R3:

R3(config)#int l0
R3(config-if)#sh
R3(config-if)#
*Jun 4 18:57:11.951: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Jun 4 18:57:12.951: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R3(config-if)#
*Jun 4 18:57:17.795: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
R3(config-if)# do sh int tun 1
Tunnel1 is up, line protocol is down

R1:

R1#sh int tun 1
Tunnel1 is up, line protocol is up

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

As we can see, R1 says the Tunnel is UP/UP but it cannot reach the other end, in this case R3 Tunnel IP Address 192.168.1.2.

Well, this is how GRE behaves with the default configuration. Now let’s do this:

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int tun 1
R1(config-if)#keepalive 3 3
R1(config-if)#
*Jun 4 19:03:12.859: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

OK, something happend, R1 sent 3 Keepalives in 9 seconds and nobody answered, so it turned down the Tunnel Interface Protocol:

R1(config-if)#do sh int tun 1
Tunnel1 is up, line protocol is down

This is interesting, because if I bring back up the Loopback Interface of R3 and shut down the Loopback Interface of R1, R3 will keep the Tunnel Up and only R1 will take down the Tunnel Interface Protocol.

R1(config-if)#int l0
R1(config-if)#sh
R1(config-if)#
*Jun 4 19:06:51.327: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Jun 4 19:06:51.875: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Jun 4 19:06:52.327: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down

R3#sh int tun 1
Tunnel1 is up, line protocol is up

Why is that ? Because R3 only responds to R1’s Keepalives sent every 3 seconds, but it does not send Keepalives itself to R1, to keep track of it. Let’s add the Keepalive to R3 under Tunnel Interface configuration:

First of all I will turn debug on R3:

R3#debug tunnel

R3#debug tunnel keepalive

R3(config)#int tun 1
R3(config-if)#keepalive 3 3
R3(config-if)#
*Jun 4 19:09:46.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=1
*Jun 4 19:09:46.255: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:46.255: Tunnel1 count tx, adding 0 encap bytes
R3(config-if)#
*Jun 4 19:09:49.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=2
*Jun 4 19:09:49.255: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:49.259: Tunnel1 count tx, adding 0 encap bytes
R3(config-if)#
*Jun 4 19:09:52.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=3
*Jun 4 19:09:52.259: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:52.259: Tunnel1 count tx, adding 0 encap bytes
R3(config-if)#
*Jun 4 19:09:55.255: Tunnel1: sending keepalive, 1.1.1.1->3.3.3.3 (len=24 ttl=2 55), counter=4
*Jun 4 19:09:55.255: Tunnel1: GRE/IP encapsulated 3.3.3.3->1.1.1.1 (linktype=7, len=48)
*Jun 4 19:09:55.259: Tunnel1 count tx, adding 0 encap bytes
*Jun 4 19:09:55.259: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, c hanged state to down

Fair enough, R3 sends every 3 seconds Keepalives to R1 and it repeats this 3 times, after 9 seconds it brings down the Tunnel Interface Protocol as we can see above.

Well, based on the above, this behaviour is not true in case when we running an IGP above all 3 Routers and not using Static Routing. I have removed the static routes and implemented the following configuration on all 3 Routers, where I said all interfaces to participate in EIGRP, including the Tunnel Interfaces:

conf t
router eigrp 1
network 0.0.0.0 255.255.255.255
end
!

Now when i shut down the L0 on R3, R1 sees this because of EIGRP, because R1 and R3 have formed a neighborship through the Tunnel, and when the L0 goes down on R2, the Tunnel Interface Protocol goes down as well and R1 sees this, as the neighbour R3 did not respond to its Hello messages so that’s why it pulls down the Tunnel Interface Protocol:
R3(config)#int l0
R3(config-if)#sh
R3(config-if)#
*Jun 4 19:29:30.811: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Jun 4 19:29:31.811: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R3(config-if)#
*Jun 4 19:29:34.479: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Jun 4 19:29:34.495: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.1 (Tunnel1) is down: interface down
R1#
*Jun 4 19:33:28.299: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.1.2 (Tunnel1) is down: holding time expired

So, it’s a good thing to use Keepalives in case you’re using a Default Route or a Static Route to the Tunnel Destination, this way you’ll know when something happend to the other end of the Tunnel and not send the traffic in vain. For this matter it is also a good idea to use PBR or IP SLA with tracking, but in case you got 2 ways to the Tunnel Destination, so you can set up the stuff in some ways that when let’s say the primary path for Tunnel fails, you’ll use another path to the Tunnel Destination.

Advertisements