Implement IPv4 tunneling and Generic Routing Encapsulation (GRE)

IP Tunneling

IP tunnels are used within a network to transport one network protocol within another network protocol, typical IP. IP tunnels are often used for connecting two disjoint IP networks that don’t have a native routing path to each other. They create a logical path between each end point. Some examples of IP tunnels are;

  • IPSec VPN tunnel, connecting remote sites to each other securely over an untrusted network, ie; Internet.
  • GRE tunnels, connecting remote sites over another network.
  • IPv6 to IPv4 tunnels, sending IPv6 traffic over an IPv4 network.
  • IPv4 to IPv6 tunnels, sending IPv4 traffic over an IPv6 network.

In IP tunnelling, every IP packet, including addressing information of its source and destination IP networks, is encapsulated within another packet format native to the transit network.

The outer IP header Source Address and Destination Address identify the “endpoints” of the tunnel. The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. The inner IP header is not changed by the encapsulator, except to decrement the TTL.

GRE tunneling

Generic routing encapsulation (GRE) defines a method of tunneling data from one router to
another. To tunnel the traffic, the sending router encapsulates packets of one networking protocol, called the passenger protocol, inside packets of another protocol, called the transport protocol, transporting these packets to another router. The receiving router de-encapsulates and forwards the original passenger protocol packets. This process allows the routers in the network to forward traffic that might not be natively supported by the intervening routers. For instance, if some routers did not support IP multicast, the IP multicast traffic could be tunneled from one router to another using IP unicast packets.

GRE tunnels are useful for a variety of tasks. From the  network standpoint, GRE tunnel traffic is considered GRE; that is, it’s not IP unicast or  multicast or IPsec or whatever else is being encapsulated. Therefore, you can use GRE to tunnel traffic that might not otherwise be able to traverse the network.

GRE tunnels can also be used to encapsulate traffic so that the traffic inside the tunnel is  unaware of the network topology. Regardless of the number of network hops between the source and destination, the traffic passing over the tunnel sees it as a single hop. Because tunnels hide the network topology, the actual traffic path across a network is also unimportant to the traffic inside the tunnel. If loopback addresses are used for source and destination addresses, the tunnel provides connectivity between the source and destination as long as there is any available route between the loopbacks. Even if the normal egress interface were to go down, traffic across the tunnel could continue to flow, if there is a route to the tunnel destination in the routing table.

In the most general case, a system has a packet that needs to be encapsulated and delivered to some destination. We will call this the payload packet. The payload is first encapsulated in a GRE packet. The resulting GRE packet can then be encapsulated in some other protocol and then forwarded. We will call this outer protocol the delivery protocol.

The GRE packet header has the form;

  • Checksum Present: If this bit is set to 1 then the Checksum and the Reserved1 fields are  present and the Checksum field contains valid information.
  • Reserved0: A receiver must discard a packet where any of the first 5bits within this filed (field is made up of 12bits) are set to non-zero.
  • Version: This field must always be set to 0.
  • Protocol Type: Contains the protocol type of the payload packet.
  • Checksum: Contains the IP (one’s complement) checksum sum of the all the 16 bit words in the GRE header and the payload packet.
  • Reserved1: Field is reserved for future use.

GRE packets which are encapsulated within IP will use IP protocol type 47

The GRE tunnel keepalive mechanism gives the ability for one side to originate and receive keepalive packets to and from a remote router even if the remote router does not support GRE keepalives. For GRE keepalives, the sender pre-builds the keepalive response packet inside the original keepalive request packet so that the remote end only needs to do standard GRE decapsulation of the outer GRE IP header and then forward the inner IP GRE packet. GRE tunnel keepalives timers on each side are independent and do not have to match. The problem with the configuration of keepalives only on one side of the tunnel is that only the router that has keepalives configured marks its tunnel interface as down if the keepalive timer expires. The GRE tunnel interface on the other side, where keepalives are not configured, remains up even if the other side of the tunnel is down. The tunnel can become a black-hole for packets directed into the tunnel from the side that did not have keepalives configured.

Three reasons for a GRE tunnel to shut down:

  1. There is no route to the tunnel destination address.
  2. The interface that anchors the tunnel source is down.
  3. The route to the tunnel destination address is through the tunnel itself. “%TUN-5-RECURDOWN:Tunnel0

With the above three reasons for tunnel shut down are problems local to the router at the tunnel endpoints and do not cover problems in the intervening network.

Also if the two routers tunnel modes do not match, the tunnel interface can still stay in an up/ip state but the routers cannot forward packets because of the mismatch encapsulation.

GRE Tunnel configuration;

On Router1 apply the following configuration;

Router1(config)#interface tunnel 0
Router1(config-if)#tunnel source 10.0.0.1
Router1(config-if)#tunnel destination 10.0.0.5Router should have a route to this address, but not through the tunnel interface itself!
Router1(config-if)#keepalive ?
<0-32767>  Keepalive period (default 10 seconds)
<cr>
Router1(config-if)#keepalive 5 ?
<1-255>  Keepalive retries
<cr>
Router1(config-if)#keepalive 5 2
Router1(config-if)#tunnel mode gre ipthis is the default mode on tunnel interfaces
Router1(config-if)#ip address 65.0.0.1 255.255.255.0 – Payload protocol

On Router2 apply the following configuration;

Router2(config)#interface tunnel 0
Router2(config-if)#tunnel source 10.0.0.5
Router2(config-if)#tunnel destination 10.0.0.1Router should have a route to this address, but not through the tunnel interface itself!
Router2(config-if)#keepalive 5 2
Router2(config-if)#tunnel mode gre ipthis is the default mode on tunnel interfaces
Router2(config-if)#ip address 65.0.0.2 255.255.255.0 – Payload protocol

You can also configure the tunnel source interface as been a local interface found on the router, physical or logical, and not just as an IP address;

Router(config-if)#tunnel source ?
A.B.C.D            ip address
Async              Async interface
BVI                Bridge-Group Virtual Interface
CDMA-Ix            CDMA Ix interface
CTunnel            CTunnel interface
Dialer             Dialer interface
FastEthernet       FastEthernet IEEE 802.3
Lex                Lex interface
Loopback           Loopback interface
MFR                Multilink Frame Relay bundle interface
Multilink          Multilink-group interface
Null               Null interface
Port-channel       Ethernet Channel of interfaces
Serial             Serial
Tunnel             Tunnel interface
Vif                PGM Multicast Host interface
Virtual-PPP        Virtual PPP interface
Virtual-Template   Virtual Template interface
Virtual-TokenRing  Virtual TokenRing
X:X:X:X::X         IPv6 address
XTagATM            Extended Tag ATM interface

But you destination will always need to be an IP address, that the router knows how to get to before the tunnel is brought up;

Router(config-if)#tunnel destination ?
Hostname or A.B.C.D  ip address or host name
X:X:X:X::X           IPv6 address