Issue Building an IP GRE Tunnel

[John Saldana]

I'm trying to build a tunnel accross the internet and seem to be having an issue with actually being able to ping accross the tunnel. Router 1 is a terrestrial link; Router 2 is a satlink with ping times avg'ing 600ms. Both routers are able to ping each other without issue. Not sure if someone can give me some pointers?

Router 1 - 1.1.1.1

interface Tunnel0
 bandwidth 1024
 ip address 172.0.0.1 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 keepalive 5 2
 tunnel source FastEthernet0/0
 tunnel destination 2.2.2.2

Tunnel0 is up, line protocol is down
  Hardware is Tunnel
  Internet address is 172.0.0.1/24
  MTU 1514 bytes, BW 1024 Kbit/sec, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (5 sec), retries 2
  Tunnel source 1.1.1.1 (FastEthernet0/0), destination 2.2.2.2
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255
  Fast tunneling enabled
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input 00:00:02, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     38426 packets input, 1847564 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     131069 packets output, 6297012 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out


Nov 27 00:33:23: Tunnel0: sending keepalive, 2.2.2.2->1.1.1.1 (len=24 ttl=255), counter=25
Nov 27 00:33:23: Tunnel0: GRE/IP encapsulated 1.1.1.1->2.2.2.2 (linktype=7, len=48)
Nov 27 00:33:23: Tunnel0 count tx, adding 24 encap bytes

Router 2 - 2.2.2.2

interface Tunnel0
 description ### VPN Tunnel ###
 bandwidth 1024
 ip address 172.0.0.2 255.255.255.0
 ip mtu 1400
 ip tcp adjust-mss 1360
 keepalive 5 2
 tunnel source GigabitEthernet0
 tunnel destination 1.1.1.1

Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Description: ### VPN Tunnel ###
  Internet address is 172.0.0.2/24
  MTU 17916 bytes, BW 1024 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (5 sec), retries 2
  Tunnel source 2.2.2.2 (GigabitEthernet0), destination 1.1.1.1
   Tunnel Subblocks:
      src-track:
         Tunnel0 source tracking subblock associated with GigabitEthernet0
          Set of tunnels with source GigabitEthernet0, 1 member (includes iterators), on interface <OK>
  Tunnel protocol/transport GRE/IP
    Key disabled, sequencing disabled
    Checksumming of packets disabled
  Tunnel TTL 255, Fast tunneling enabled
  Tunnel transport MTU 1476 bytes
  Tunnel transmit bandwidth 8000 (kbps)
  Tunnel receive bandwidth 8000 (kbps)
  Last input never, output 00:00:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1338 packets output, 64224 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out


*Nov 27 04:12:05.019: Tunnel0: sending keepalive, 1.1.1.1->2.2.2.2 (len=24 ttl=255), counter=1
*Nov 27 04:12:05.019: Tunnel0: GRE/IP encapsulated 2.2.2.2->1.1.1.1 (linktype=7, len=48)
*Nov 27 04:12:05.019: Tunnel0 count tx, adding 0 encap bytes
*Nov 27 04:12:05.635: Tunnel0: GRE/IP (PS) to decaps 1.1.1.1->2.2.2.2 (tbl=0,"default" len=24 ttl=242)
*Nov 27 04:12:05.635: Tunnel0: keepalive received, 1.1.1.1->2.2.2.2 (len=24 ttl=242), resetting counter


Thanks,


John

[Richard Burts]

Paul

While it was not the original focus of this discussion the topic of GRE tunnel keepalives gets pretty interesting. So let me go a bit further. First let me talk about an aspect of GRE keepalives that many people do not know and that may be a bit surprising - the configuration does not need to match at both ends. For most of us the understanding of keepalive on point to point connections is based on keepalives for PPP or HDLC where keepalives must be configured on both ends or on neither end. That is not the case with GRE keepalives. As your test demonstrates it is quite fine to configure keepalives on one end and not keepalives on the other end. The tunnel will come up and work fine in this configuration  - as long as the keepalive works successfully on the end where it is configured.

But if GRE keepalive is configured on one end and if the keepalive is not successful (as I suspect is the case for the original poster) then that end will go into the UP/DOWN state and the tunnel will not pass traffic.

So how does the GRE keepalive work? Cisco was quite smart in this implementation and came up with an implementation where each end operates independently and where an end that is not configured for keepalive will send to its peer the messages that the peer needs to implement the keepalive function. First a reminder about how GRE works - the router sending a GRE packet will take some packet that is the payload and encapsulate it in a new header where the destination and source addresses are the addresses of the peers. When a router receives an IP packet on the GRE interface it strips off the GRE header (where the destination and source addresses are the peer) and forwards the original payload using the original destination address. Cisco uses this logic to implement the keepalive. The original payload packet for the keepalive is an IP packet where the destination address is the address of the router originating the keepalive. The router encapsulates this packet for GRE and sends it to the peer. The peer receives the GRE packet, strips off the GRE header, and uses the original destination address to forward the packet back to the original GRE router. Note that in this process the other peer is not aware that the packet it is forwarding is a keepalive. So it will forward the keepalive response whether or not it is configured for keepalives.

So to summarize:

- GRE keepalives are not required but are an option that can be used.

- a router with a GRE tunnel without keepalives will mark the tunnel interface as UP/UP as long as it has a viable route to the tunnel destination address.

-  the peers on the GRE tunnel do not have to agree about using keepalives. One peer can configure keepalives and the other peer not configure keepalives and the tunnel can work fine.

- if a router configures a GRE tunnel with keepalives it will mark the tunnel interface as UP/UP if it receives the response to the keepalive that it sent. But if a router configures a GRE tunnel with keepalives it will mark the tunnel interface as UP/DOWN if it does not receive the response to keepalive packets that it sends.

HTH

Rick