11: IP Tunnelling

Overview

An IP tunnel is a communications channel between two networks, over an IP network. The transport network is often the Internet. The tunnel can be secure or insecure, depending on the tunnelling protocol.

IP packets tunnelled over IP are referred to as IP-IP.

Tunnelling IP Packets

When a packet enters a tunnel, the whole packet, including the header, is encapsulated. Once it exits the tunnel, it is decapsulated.

Use of IP Tunnels

Traffic which cannot be routed over the Internet, such as RFC1918 addressed traffic, may be encapsulated in a tunnel. Tunnels can also be used as a backup link, in case an interior link fails, with an IGP running over the tunnel. Be aware that, as the tunnel appears as a one hop link to routing protocols, it may be preferred over an interior link when both are up.

IP tunnels can be used to bypass simple firewall rules, because the original IP header is hidden from most transit devices.

GRE and IP-IP Tunnels

Generic Routing Encapsulation (GRE) is a tunnelling protocol which can encapsulate many Network Layer Protocol (NLP) types. GRE can connect isolate IPv6, MPLS, and RFC1918 networks.

When packets are encapsulated, a GRE header, then an outer IP header, are added. These additional headers add 24 bytes of overhead. The inner packet, also called the payload, is not modified, except for the TTL field, which is decremented. GRE uses IP protocol number 47. GRE was developed by Cisco but is now standardised across vendors. RFC1702 defines GRE over IPv4.

IP-IP

A tunnelling protocol that encapsulates an IP packet inside an IP packet. The new IP header adds 20 bytes of overhead. The outer header identifies the tunnel endpoint. The inner header is not changed, except to decrement the TTL, as in GRE.

IP-IP tunnels can only tunnel IP traffic, so they are less commonly used than GRE. IP-IP is defined in RFC2003.

GRE and IP-IP Tunnel Requirements

In Junos, tunnel interfaces are defined using the gr-x/y/z naming standard. x/y/z represents the placement of the GRE tunnel on a PIC. Some Junos platforms do not have hardware support for GRE tunnels, so GRE tunnelling is accomplished in software. On such platforms, use gr-0/0/0 as the tunnel interface. IP-IP tunnels, similarly, use ip-x/y/z, or ip-0/0/0 for software only tunnels. A single tunnel can be configured on each logical interface of the tunnel interface.

Tunnel endpoints must have valid routes to reach their remote endpoints. The route must not use the tunnel as it next hop. All intermediary devices must also be able to route to the tunnel endpoints. It is common to use loopback addresses as tunnel endpoints.

GRE and IP-IP Tunnel Considerations

By default, GRE and IP-IP tunnels are stateless. This means that interfaces are not marked ‘down’ when the tunnel becomes unavailable. Any routes which use the tunnel will remain in the routing table when the tunnel is unavailable. Some implementations of GRE provide a keepalive mechanism.

protocols {
    oam {
        gre-tunnel {
            interface gr-1/1/10.1 {
                keepalive-time 10;
                hold-time 30;
             }
        }
    }
}

GRE keepalive is supported on Juniper M and MX series routers. Bidirectional Forwarding Detection (BFD) can also be used with GRE tunnels to accomplish the same functionality.

Although the maximum length of an IP packet is 64K, most interface types enforce a significantly smaller MTU. IP fragmentation and reassembly allows for longer packets to be broken up and transmitted. The MTU is usually 1500 bytes, however, GRE and IP-IP add overhead. With GRE, the MSS is 1476, allowing for the additional 24 bytes of overhead. Packets with the don’t fragment (DF) flag will be dropped, with an ICMP packet sent.

It is recommended that the MTU be set to 1524 or larger for links with tunnels over them. Ethernet support MTUs up to 1500 bytes. Gigabit Ethernet and later support jumbo frame of up to 9202 bytes. On some devices, clear-dont-fragment may also be set.

The route for the remote tunnel endpoint cannot use the tunnel interface as the next hop. If it does, the tunnel will bounce. This can happen when new routing information becomes available due to the tunnel being created, that would make the tunnel the preferred route to the other endpoint. To avoid this, it is recommended to use a very specific route with a low route preference

Deploying GRE and IP-IP Tunnels

In this example, a GRE tunnel is created to forward traffic between two 172.20.x.0/24 subnets, over a network that cannot route RFC1918 addresses.

Defining the Tunnel Interface

GRE and IP-IP tunnels are configured in much the same way. The source and destination are the public IP addresses of the tunnel endpoints. family inet is required to process IPv4 packets through the tunnel.

interfaces {
    gr-0/0/0 {
        unit 0 {
            tunnel {
                source ...;
                destination ...;
            }
            family inet;
        }
    }
}

There are many additional options which can be set on the tunnel. copy-tos-to-outer-ip-header copies the IP ToS field from the encapsulated packet to the GRE packet. This is already the default for IP-IP. allow-fragmentation enables fragmentation of GRE encapsulated packets regardless of the MTU value. reassemble-packets, on GRE interfaces, enables the reassembly of fragmented packets. key assigns a key to the GRE tunnel, to identify the individual traffic flow. The key is 4 bytes. clear-dont-fragment-bit clears the DNF bit in the original IPv4 packet to enable fragmentation within GRE tunnels.

Path MTU Discovery (PMTUD) can also be enabled or disabled for GRE or IP-IP. PMTUD determines the MTU of a path so that IP fragmentation does not occur. It sets the DNF bit on IP packets and listens for ICMP responses to learn the MTU. Configuration options vary between GRE and IP-IP, and apply to all tunnels of that type;

system {
    internet-options {
        gre-path-mtu-discovery;
        ipip-path-mtu-discovery;
        no-gre-path-mtu-discovery;
        no-ipip-path-mtu-discovery;
    }
}

Defining the Required Routes

Each router needs a route to the remote tunnel endpoint and a route to the subnet at the other end of the tunnel.

routing-options {
    static {
        route <ENDPOINT>/32 next-hop <GATEWAY>;
        route 172.20.110.0/24 next-hop gr-0/0/0.0;
    }
}

Verifying Operations

show interfaces gr-0/0/0 terse shows the status of the tunnel interfaces. Without GRE keepalives or another detection mechanism, there is no guarantee that the tunnel is actually operational. Both ends of the tunnel should be checked.

Routes between the tunnel endpoints, and the remote subnets, should also be checked.

Traffic should be sent through the tunnel and the interface statistics monitored. The ping command with the source set forces Junos to use the tunnel.

ping 172.20.111.10 rapid count 25 source 172.20.110.1

show interface gr-0/0/0.0 detail | find "traffic statistics"