<Course

IP Tunneling
Title>

LY
N
O
SE
U
AL
N
R
TE
IN
IP Tunneling

LY
N
O
SE
U
AL

What Is an IP Tunnel?
N

In its most basic form, an IP tunnel is a communications channel between two different networks.
The networks joined by an IP tunnel are often geographically dispersed and have no native routing
R

path between one another. Because no native routing paths exist between the remote networks, a
transport network, such as the Internet, is required to allow the tunnel to form and IP
TE

communications to occur.
IP tunnels require a tunneling protocol, which can provide secure or unsecure communications,
depending on the protocol selected. Tunneling protocols can use data encryption to transport
insecure payload protocols over a public network (such as the Internet), thereby providing VPN
functionality. IP Security (IPsec) has an end-to-end transport mode but can also operate in a
IN

tunneling mode through a trusted security gateway. We cover IPsec in detail in other training courses.
In this material, we highlight GRE and IP-IP, which are unsecure tunneling protocols.

2 www.juniper.net
 IP Tunneling

LY
N
O
SE
U
AL

Tunneling IP Packets
N

As a packet enters an IP tunnel, the tunneling protocol encapsulates the entire packet, including the
header. Once the packet is encapsulated, it is forwarded by the encapsulating router, known as the
R

encapsulator, to the next hop in the path toward the remote tunnel endpoint. Once the packet is
received by the remote tunnel endpoint, known as the decapsulator, the packet is de-encapsulated
TE

and forwarded based on the original header contents. The tunnel endpoints typically reside at the
edge of the source and destination networks and between the source or destination network and the
transport IP network (often the Internet). A router can serve as a encapsulator and decapsulator at
the same time.
IN

www.juniper.net 3
IP Tunneling

LY
N
O
SE
U
AL

Uses of IP Tunnels: Part 1

N

By default, only IP traffic using routable IP addresses is permitted through the Internet. Routable IP
addresses are defined by the Internet Assigned Numbers Authority (IANA). Examples of nonroutable
R

IP addresses include the private IP address ranges defined in RFC 1918.

As the slide indicates, you can use IP tunnels to route non-IP traffic, such as IPX or AppleTalk, or IP
TE

traffic with nonroutable IP addresses over a public network, such as the Internet. Note that Junos
operating system does not support IPX or AppleTalk. We highlight other uses of IP tunnels on the next
slide.
IN

4 www.juniper.net
 IP Tunneling

LY
N
O
SE
U
AL

Uses of IP Tunnels: Part 2

N

Another use of IP tunnels is to incorporate a redundant link to be used during failure scenarios. An IP
tunnel is a logical point-to-point link between the tunnel end-points and is capable of the same
R

functions as any other link. In other words, a tunnel interface can serve as a next hop for static
routes or participate in the network’s IGP. Note that routing protocols might prefer a tunnel over a
TE

physical link because the tunnel appears to be a one-hop link with the lowest cost path. In reality,
however, tunnels involve multiple hops and are generally more costly than other paths. You can
ensure the IP tunnel serves as the backup path through administrative settings such as cost and
route preference.
Other uses of IP tunnels exist; however, they are not covered on the slides. You can use IP tunnels to
IN

bypass simple firewall rules because the original IP header contents are hidden from most transit
devices (those devices between the tunnel end-points). You can also use IP tunnels to tunnel IPv6
traffic between remote IPv6 networks.

www.juniper.net 5
IP Tunneling

LY
N
O
SE
U
AL

Generic Routing Encapsulation

N

GRE is a tunneling protocol that can encapsulate a wide variety of Network Layer protocol packet
types inside IP tunnels, creating a virtual point-to-point link between the routers at remote ends of
R

the tunnel. As indicated on the slide, GRE tunnels are used to tunnel IP traffic as well as non-IP
traffic, such as IPX and AppleTalk. In addition to the referenced protocol packet types, GRE tunnels
TE

are also commonly used to tunnel IPv6 and MPLS protocol traffic over an IP transport network. In
these situations, GRE tunnels connect isolated IPv6 networks and serve in place of the tunnels
normally created by the RSVP and the LDP, respectively. Detailed coverage of tunneling IPv6 and
MPLS traffic is beyond the scope of this material.
To encapsulate a GRE packet in an IP packet, a GRE header and an outer IP header are added. The
IN

GRE header and outer IP header add an additional 24 bytes of overhead to the packet. The outer
header includes the source IP address, the entry point of the tunnel, and the destination IP
address—the exit point of the tunnel. The inner packet (also known as the payload packet) is not
modified, except the time-to-live (TTL) field, which is decremented. The TTL field must be
decremented to ensure that the packet does not live forever. GRE packets that are encapsulated in
IP packets use IP protocol type 47.
Although GRE was originally developed by Cisco Systems, it is now a standard and is supported by
many vendors, including Juniper Networks. RFC 1702 defines GRE over IPv4 networks.
Continued on next page.

6 www.juniper.net
 IP Tunneling
IP-IP
IP-IP is a tunneling protocol used to encapsulate one IP packet in another IP packet. To encapsulate
an IP packet using IP-IP encapsulation, an outer IP header is inserted before the packet's existing IP
header. The additional IP header adds 20 bytes of overhead to the packet. The outer IP header
source and destination addresses identify the tunnel endpoints. The inner IP header source and
destination addresses identify the original sender and recipient of the datagram, respectively. The
encapsulator does not change the inner IP header, except to decrement the time to live (TTL), and it
remains unchanged during its delivery to the tunnel endpoint.
Because IP-IP tunnels can tunnel only IP traffic, they are not as commonly used as GRE tunnels,
which can tunnel both IP and non-IP traffic. IP-IP encapsulation is defined in RFC 2003.

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 7
IP Tunneling

LY
N
O
SE
U
AL

Tunnel Requirements: Part 1

N

You must define a tunnel interface on each endpoint of the tunnel. If you use a GRE tunnel, you
define a tunnel interface in the form of gr-x/y/z, where x/y/z represents the placement of the
R

interface card used for tunneling services. On some Junos devices, the tunneling services are
performed by the software rather than a hardware component, such as a physical interface card
TE

(PIC). In platforms where the tunneling services are performed in software, use gr-0/0/0 as the
tunnel interface. Similarly, if you use an IP-IP tunnel, you must define a tunnel interface in the form of
ip-x/y/z, where x/y/z represents the placement of the tunneling services interface card. Not all
Junos devices support GRE and IP-IP tunnel interfaces; in some cases, they might have special
hardware requirements or configuration considerations. Check your product-specific documentation
IN

for support information.

You can configure multiple logical units for each GRE or IP-IP interface, and you can configure only
one tunnel per unit. Each tunnel interface is a point-to-point interface. You must specify the tunnel’s
destination and source addresses. All other statements are optional. We cover tunnel interface
configuration later in this material.

8 www.juniper.net
 IP Tunneling

LY
N
O
SE
U
AL

Tunnel Requirements: Part 2

N

The slide illustrates other requirements for proper GRE and IP-IP tunnel operations. As indicated on
the slide, the tunnel endpoints must have a valid route to the remote tunnel endpoint. This route
R

must resolve to the physical next hop in the path toward the remote tunnel endpoint and cannot use
the tunnel as the next hop.
TE

Similarly, the intermediary devices, located in the forwarding path between the tunnel endpoints,
must be able to route to each of the tunnel endpoints. Note that the tunnel is often established using
the loopback address assigned to the tunnel endpoints. Using loopback addresses rather than IP
addresses assigned to physical interfaces on the tunnel endpoints provides added some
redundancy when multiple paths between the tunnel endpoints exist.
IN

The tunnel endpoints also need a route to direct traffic destined to the remote subnet into the
tunnel. This route uses the tunnel interface as the next hop. We provide a sample configuration for a
route that directs traffic through a tunnel on a subsequent slide.

www.juniper.net 9
IP Tunneling

LY
N
O
SE
U
AL

Tunnel Considerations: Part 1

N

By default, GRE and IP-IP tunnels are completely stateless, which means the tunnel endpoints do not
know about the state or availability of the remote tunnel endpoint. Consequently, the local tunnel
R

endpoint does not have the ability to bring the GRE tunnel interface down if the remote endpoint is
unreachable. The inability to mark an interface down when the remote tunnel endpoint is
TE

unavailable means that any associated routes dependant on that interface (such as static routes)
remain in the routing table whether or not the tunnel is actually usable. The described behavior can
cause problems in certain situations.
Continued on next page.
IN

10 www.juniper.net
 IP Tunneling
Tunnel Considerations: Part 1 (contd.)
Some implementations of GRE support a keepalive mechanism to monitor the health and availability
of the tunnel endpoints. Using keepalives to monitor the tunnel can greatly reduce the potential risks
of sending traffic through stateless tunnels. The following is a configuration example of a GRE
keepalive:
[edit]
user@host# show
protocols {
oam {
gre-tunnel {
interface gr-1/1/10.1 {
keepalive-time 10;

LY
hold-time 30;
}
}
}

N
}
When configuring the keepalive, you must specify the family inet statement at the [edit
interfaces interface-name unit unit] hierarchy level. The hold time must also be twice

O
the keepalive time. GRE keepalives are supported on the M Series and MX Series devices.
You can also use Bidirectional Forwarding Detection (BFD) in conjunction with GRE tunnels to help
accomplish the same basic functionality. We cover BFD in detail in the “High Availability” material.

SE
U
AL
N
R
TE
IN

www.juniper.net 11
IP Tunneling

LY
N
O
SE
U
AL

Tunnel Considerations: Part 2

N

The IP protocol was designed to be used over a variety of interface types. Although the maximum
length of an IP packet is 64 KB, most interface types enforce a significantly smaller maximum packet
R

size, known as a maximum transmission unit (MTU). The MTU used depends on the interface type.
The IP protocol accommodates different MTU values by allowing routers to fragment IP packets as
TE

necessary. The host receiving fragmented packets is responsible for reassembling the fragments
back into the original packet.
IP fragmentation involves breaking a packet into several pieces that can later be reassembled. The
IP source, destination, identification, total length, and fragment offset fields, along with the more
fragments and don’t fragment flags in the IP header, are used for IP fragmentation and reassembly.
IN

When two devices communicate using TCP, they determine the maximum segment size (MSS)
permitted over the end-to-end communications path. Typically, the MSS turns out to be 1500 bytes,
which is the maximum amount of payload in an Ethernet frame. This approach works well until
overhead is added somewhere between the communicating devices, such as in the case of IP-IP and
GRE tunnels where additional headers are added. When packets traverse a GRE tunnel, for example,
the maximum packet size is reduced from 1500 to 1476 to account for the additional overhead of
24 bytes (4-byte GRE header + 20-byte IP header).
Continued on next page.

12 www.juniper.net
 IP Tunneling
Tunnel Considerations: Part 2 (contd.)
In this situation, if either host sends a packet that is larger than 1476, the packet must be
fragmented (typically by one of the tunnel endpoints) to cross the tunnel. Unfortunately, the hosts do
not realize this fact, because they have only communicated with one another and agreed upon the
1500 value.
If the transmitting host sets the don't fragment (DF) bit, the router drops the packet and typically
sends an Internet Control Message Protocol (ICMP) message informing the sender to use smaller
packets.
To avoid this problem, you can increase the MTU for the tunnel. We recommend that you set the MTU
for a tunnel to 1524 or better. On some Junos devices, you can also enable the
clear-dont-fragment configuration option, which clears the DF bit and allows fragmentation to
occur. For support details, refer to the technical publications for your specific product. We cover

LY
tunnel interface configuration options later in this material.

N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 13
IP Tunneling

LY
N
O
SE
U
AL

Tunnel Considerations: Part 3

N

Each tunnel endpoint must have a valid route to the remote tunnel endpoint. For proper tunnel
operations, this route must resolve to the physical next hop in the end-to-end communications path
R

and should never use a recursive route, which is a route for which the best path to the remote tunnel
endpoint is through the tunnel itself. If a tunnel endpoint uses the tunnel as the best path to the
TE

remote tunnel endpoint, the tunnel interface bounces and becomes unusable.
We recommend you configure static routes on the tunnel endpoints for the destination tunnel
endpoint to avoid problems caused by recursive routing.
IN

14 www.juniper.net
 IP Tunneling

LY
N
O
SE
U
AL

Objectives and Topology

N

The slide introduces the case study for implementing a GRE tunnel. Note that the steps outlined in
this case study are equally applicable to IP-IP tunnels. We cover the configuration and verification
R

steps on subsequent slides.

TE
IN

www.juniper.net 15
IP Tunneling

LY
N
O
SE
U
AL

Defining the Tunnel Interface

N

The slide illustrates basic GRE interface configurations used to process IPv4 packets. In addition to
the basic configuration options listed on the slide, you can also configure some additional options.
R

The following is a list of some of the tunnel options:

• copy-tos-to-outer-ip-header: Unlike IP-IP tunnels, GRE tunnels do not copy
TE

the type of service (ToS) bits to the outer IP header by default. To have the RE copy the
inner ToS bits to the outer IP header on packets sent by the RE, include the
copy-tos-to-outer-ip-header statement at the logical unit hierarchy level of a
GRE interface.
IN

• allow-fragmentation: By default, the GRE-encapsulated packets are dropped if

the packet size exceeds the MTU setting of the egress interface. Use the
allow-fragmentation option to enable fragmentation of GRE-encapsulated
packets regardless of MTU value.
Continued on next page.

16 www.juniper.net
 IP Tunneling
Defining the Tunnel Interface (contd.)
• reassemble-packets: On GRE tunnel interfaces only, you can enable the
reassembly of fragmented tunnel packets.
• key: You can assign a key value to identify an individual traffic flow within a GRE
tunnel, as defined in RFC 2890. However, only one key is allowed for each tunnel
source and destination pair. Each IPv4 packet entering the tunnel is encapsulated
with the GRE tunnel key value. Each IPv4 packet exiting the tunnel is verified by the
GRE tunnel key value and de-encapsulated. Packets that do not match the
configured key value are dropped by the router. The key number can be 0 through
4,294,967,295. You must configure the same GRE tunnel key value on both tunnel
endpoints.
• clear-dont-fragment-bit: By default, IPv4 traffic transmitted over GRE tunnels

LY
is not fragmented. To enable fragmentation of IPv4 packets in GRE tunnels, include the
clear-dont-fragment-bit statement. This option clears the DF bit on all
packets—even packets that do not exceed the tunnel MTU. If the packet’s size exceeds
the tunnel’s MTU value, the packet is fragmented before encapsulation. If the packet’s

N
size does not exceed the tunnel’s MTU value, the packet is not fragmented.
In addition to the tunneling configuration options previously shown, you can also enable or disable

O
path MTU discovery for GRE and IP-IP tunnels under the [edit system internet-options]
hierarchy level, as follows:
[edit system internet-options]
user@R1# set ?
Possible completions:
... SE
gre-path-mtu-discovery Enable path MTU discovery for GRE tunnels
ipip-path-mtu-discovery Enable path MTU discovery for IP-IP tunnels
U
no-gre-path-mtu-discovery Don't enable path MTU discovery for GRE tunnels
no-ipip-path-mtu-discovery Don't enable path MTU discovery for IP-IP tunnels
...
AL

Path MTU discovery (PMTUD) is a technique used to determine the MTU size on a path between two
endpoints so that IP fragmentation does not occur. PMTUD sets the DF bit in the IP header of
outgoing packets. If an intermediary device on the path has an MTU smaller than the packet sent by
the tunnel endpoint, that device drops the packet and sends back an ICMP Fragmentation Needed
(type 3, Code 4) message containing its MTU. The received message allows the tunnel endpoint to
N

reduce its path MTU. The tunnel endpoint repeats this discovery process until the MTU is small
enough that packets can pass through the entire path without fragmentation.
R

Note that the configuration options for GRE and IP-IP tunnels can vary, and in some cases, might be
platform specific. Refer to the technical publications for your specific product for support
TE

information.
IN

www.juniper.net 17
IP Tunneling

LY
N
O
SE
U
AL

Defining the Required Routes

N

The slide illustrates the required routes on R1 and R2. As previously mentioned, each tunnel
endpoint must have a valid route to the remote tunnel endpoint. This route must resolve to the
R

physical next hop in the path toward the remote tunnel endpoint and cannot use the tunnel as the
next hop. The tunnel endpoints also need a route to direct traffic destined to the remote subnet in to
TE

the tunnel. In addition to the routing requirements for the tunnel endpoints, the intermediary devices
must be able to route to each of the tunnel endpoints, which often—and in this example—is the
loopback address assigned to the tunnel endpoints.
IN

18 www.juniper.net
 IP Tunneling

LY
N
O
SE
U
AL

Verifying Operations: Part 1

N

The slide illustrates the first step for verifying proper operation of a GRE or IP-IP tunnel. As shown in
the sample output on the slide, the gr-0/0/0.0 interface is up on both tunnel endpoints. Because
R

GRE and IP-IP tunnels are stateless, you should always check both sides to ensure that the tunnel
interfaces are up. In addition to checking the status of the tunnel interfaces, you should also perform
TE

the remainder of the verification steps outlined on the subsequent pages in this section.
IN

www.juniper.net 19
IP Tunneling

LY
N
O
SE
U
AL

Verifying Operations: Part 2

N

The slide illustrates the next step for verifying proper tunnel operations. We list the required routes
for the R1 device on the slide. The following is a similar output for R2:
R

user@R2> show route 192.168.1.1

TE

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

Restart Complete
+ = Active Route, - = Last Active, * = Both
IN

192.168.1.1/32 *[Static/5] 5d 21:02:26

> to 172.18.2.1 via ge-0/0/3.0

user@R2> show route 172.20.110.0/24

inet.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden)

Restart Complete
+ = Active Route, - = Last Active, * = Both

172.20.110.0/24 *[Static/5] 10:43:01

> via gr-0/0/0.0

20 www.juniper.net
 IP Tunneling

LY
N
O
SE
U
AL

Verifying Operations: Part 3

N

The slide illustrates the third and final recommended step for verifying tunnel operations. We
recommend you send traffic through the tunnel and confirm that the interface statistics increment
R

accordingly on the respective tunnel interface. In the example on the slide, we send traffic from R1
to a known user device on the remote subnet (172.20.111.10). Here, we use the source option
TE

with the ping operation to ensure that the return traffic also uses the GRE tunnel. Based on the
interface counters, we see that the sent and received traffic both use the GRE tunnel as expected.
IN

www.juniper.net 21