Configuring Unicast Tunnels
To configure a unicast tunnel, you configure a gr- interface (to use GRE encapsulation) or an ip- interface (to use IP-IP encapsulation) and include the tunnel and family statements:
You can configure these statements at the following hierarchy levels:
- [edit interfaces]
- [edit logical-systems logical-system-name interfaces]
You can configure multiple logical units for each GRE or IP-IP interface, and you can configure only one tunnel per unit.
 | Note: On M Series and T Series routers, you can configure the interface on a service PIC or a tunnel PIC. On MX Series routers, configure the interface on a Multiservices DPC. |
Each tunnel interface must be a point-to-point interface. Point to point is the default interface connection type, so you do not need to include the point-to-point statement in the logical interface configuration.
You must specify the tunnel’s destination and source addresses. The remaining statements are optional.
| Note: For transit packets exiting the tunnel, forwarding path features, such as reverse path forwarding (RPF), forwarding table filtering, source class usage, destination class usage, and stateless firewall filtering, are not supported on the interfaces you configure as tunnel sources, but are supported on tunnel-pic interfaces. However, class-of-service (CoS) information obtained from the GRE or IP-IP header is carried over the tunnel and is used by the re-entering packets. For more information, see the Junos OS Class of Service Configuration Guide. To prevent an invalid configuration, the Junos OS disallows setting the address specified by the source or destination statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number tunnel] hierarchy level to be the same as the interface’s own subnet address, specified by the address statement at the [edit interfaces gr-fpc/pic/port unit logical-unit-number family family-name] hierarchy level. |
To set the time-to-live (TTL) field that is included in the encapsulating header, include the ttl statement. If you explicitly configure a TTL value for the tunnel, you must configure it to be one larger than the number of hops in the tunnel. For example, if the tunnel has seven hops, you must configure a TTL value of 8.
You must configure at least one family on the logical interface. To enable MPLS over GRE tunnel interfaces, you must include the family mpls statement in the GRE interface configuration. In addition, you must include the appropriate statements at the [edit protocols] hierarchy level to enable Resource Reservation Protocol (RSVP), MPLS, and label-switched paths (LSPs) over GRE tunnels. Unicast tunnels are bidirectional.
A configured tunnel cannot go through Network Address Translation (NAT) at any point along the way to the destination. For more information, see Examples: Configuring Unicast Tunnels and the Junos OS MPLS Applications Configuration Guide.
For a GRE tunnel, the default is to set the ToS bits in the outer IP header to all zeros. To have the Routing Engine copy the ToS bits from the inner IP header to the outer, include the copy-tos-bits-to-outer-ip-header statement. (This inner-to-outer ToS bits copying is already the default behavior for IP-IP tunnels.)
For GRE tunnel interfaces on Adaptive Services or Multiservices interfaces, you can configure additional tunnel attributes, as described in the following sections:
Configuring a Key Number on GRE Tunnels
For Adaptive Services and Multiservices interfaces on M Series and T Series routers, you can assign a key value to identify an individual traffic flow within a GRE tunnel, as defined in RFC 2890, Key and Sequence Number Extensions to GRE. However, only one key is allowed for each tunnel source and destination pair.
Each IP version 4 (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. The Adaptive Services or Multiservices PIC drops packets that do not match the configured key value.
To assign a key value to a GRE tunnel interface, include the key statement:
You can include this statement at the following hierarchy levels:
- [edit interfaces interface-name unit logical-unit-number tunnel]
- [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number tunnel]
The key number can be 0 through 4,294,967,295. You must configure the same GRE tunnel key value on tunnel endpoints.
The following example illustrates the use of the key statement in a GRE tunnel configuration:
Enabling Fragmentation on GRE Tunnels
For GRE tunnel interfaces on Adaptive Services and Multiservices interfaces only, you can enable fragmentation of IPv4 packets in GRE tunnels.
By default, IPv4 traffic transmitted over GRE tunnels is not fragmented. To enable fragmentation of IPv4 packets in GRE tunnels, include the clear-dont-fragment-bit statement:
You can include this statement at the following hierarchy levels:
- [edit interfaces interface-name unit logical-unit-number]
- [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
When you include the clear-dont-fragment-bit statement in the configuration, the don’t-fragment (DF) bit is cleared on all packets, even packets that do not exceed the tunnel maximum transmission unit (MTU). If the packet’s size exceeds the tunnel’s MTU value, the packet is fragmented before encapsulation. If the packet’s size does not exceed the tunnel’s MTU value, the packet is not fragmented.
| Note: The Packet Forwarding Engine updates the IP identification field in the outer IP header of GRE-encapsulated packets, so that reassembly of the packets is possible after fragmentation. The previous CLI constraint check that required you to configure either the clear-dont-fragment-bit statement or a tunnel key with the allow-fragmentation statement is no longer enforced. |
You can also clear the DF bit in packets transmitted over IP Security (IPsec) tunnels. For more information, see Enabling IPsec Packet Fragmentation.
Specifying an MTU Setting for the Tunnel
To enable key numbers and fragmentation on GRE tunnels (as described in Configuring a Key Number on GRE Tunnels and Enabling Fragmentation on GRE Tunnels), you must also specify an MTU setting for the tunnel.
To specify an MTU setting for the tunnel, include the mtu statement:
You can include this statement at the following hierarchy levels:
- [edit interfaces gr-fpc/pic/port unit logical-unit-number family inet]
- [edit logical-system logical-system-name interfaces gr-fpc/pic/port unit logical-unit-number family inet]
For more information about MTU settings, see the Junos® OS Network Interfaces.
Configuring a GRE Tunnel to Copy ToS Bits to the Outer IP Header
Unlike IP-IP tunnels, GRE tunnels do not copy the ToS bits to the outer IP header by default. To have the Routing Engine copy the inner ToS bits to the outer IP header (which is required for some tunneled routing protocols) on packets sent by the Routing Engine, include the copy-tos-to-outer-ip-header statement at the logical unit hierarchy level of a GRE interface. This example copies the inner ToS bits to the outer IP header on a GRE tunnel:
Configuring Packet Reassembly
On GRE tunnel interfaces only, you can enable reassembly of fragmented tunnel packets. To activate this capability, include the reassemble-packets statement:
You can configure this statement at the following hierarchy levels:
- [edit interfaces interface-name unit logical-unit-number]
- [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
For each tunnel you configure on the interface, you can enable or disable fragmentation of GRE packets by including the allow-fragmentation or do-not-fragment statement:
You can configure these statements at the following hierarchy levels:
- [edit interfaces interface-name unit logical-unit-number tunnel]
- [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number tunnel]
If you configure allow-fragmentation on a tunnel, it clears the DF bit in the outer IP header, enabling post fragmentation of GRE-encapsulated packets if the packet size exceeds the maximum transmission unit (MTU) value for the egress interface. By default, packets that exceed the MTU size are dropped and post fragmentation of GRE packets is disabled.
| Note: Whenever you configure allow-fragmentation on a tunnel, you must also include either the tunnel key or the clear-dont-fragment-bit statement. This configuration enables the router to send affected packets to the PIC so that the correct IP header can be placed in the fragments. Otherwise, on the reassembly side some packets might be lost when fragments arrive in the PIC out of sequence at high speeds. |
