Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Configuring Tunnel Interfaces on MX Series Routers and PTX Series Routers

Tunnel Interfaces: Overview and Use Cases

This document provides an overview of IP tunneling features on routers with Junos OS and Junos OS Evolved and describes the appropriate tunneling models for different deployment scenarios.

Network operators often require the ability to transport payload traffic across heterogeneous transport networks. This requirement is typically addressed using tunneling technologies such as IPsec, MPLS, and IP-based tunnels, including GRE, IP-IP, MPLS over UDP, and VXLAN.

IPsec operates at the network layer and enables secure transmission of packets over untrusted networks. It encapsulates the original packet within an outer IP header and provides encryption and replay protection. These security features introduce additional processing overhead.

In contrast, overlay tunneling mechanisms such as GRE, IP-IP, MPLS over UDP, and VXLAN are primarily designed for traffic transport and routing in environments where IPsec-level security is not required.

Junos OS and Junos OS Evolved (Junos EVO) support multiple tunneling mechanisms across routing platforms. These include GRE, IP-IP, MPLS over UDP, VXLAN, and IPsec. MPLS is the preferred technology for high-speed backbone forwarding. However, IP tunneling is still required when the underlying infrastructure does not support MPLS forwarding or when secure MPLS transport is not needed. For example, in data centers, traffic from server-hosted virtual or containerized routers is tunneled to gateway nodes using overlay tunnels. IP tunneling is also widely used in non-MPLS transport networks, where it serves as the primary overlay mechanism across large-scale IP fabric backbones.

These tunneling features are supported on multiple routing platforms. The supported tunneling capabilities and scale vary by platform and underlying hardware architecture. For more information, see Feature Explorer.

The following table outlines the main types of overlay tunnels, the associated technology stacks available in the Junos OS and Junos OS Evolved platforms, and related use cases.

Table 1: Tunnels Types on Routers with Junos OS and Junos OS Evolved and Supported Use Cases

Tunnel Type

Platform

Bandwidth Enforcement

Encapsulation

De-encapsulation

Tunnel Interface

Dynamic Signaling

Use Case

Interface-based (gr-/ip-)

MX, ACX

Yes

GRE, IP-IP

GRE, IP-IP

Yes

No

Traffic steering and mirroring

FTI

MX, PTX EVO, ACX7000

No

GRE, UDP, IP-IP

GRE, UDP, IP-IP

Yes

No

Dynamic routing over tunnels

FTI via JET API

MX

No

GRE, UDP, IP-IP, VXLAN

GRE, UDP, IP-IP, VXLAN

Yes

No (controller-driven)

Large-scale data center edge deployments supporting overlay connectivity between cloud users and cloud workloads.

Interface-Based Dynamic GRE

MX, ACX

No

GRE

GRE

Yes (gr- auto-created)

Yes (BGP)

A dynamic GRE overlay where gr-interfaces are automatically created for each tunnel through BGP next-hop resolution.

Next-Hop-Based Dynamic

MX, PTX

No

GRE (MX), MPLS-over-UDP, IP-IP, VXLAN Type-5

MPLS-over-UDP, IP-IP, VXLAN Type-5

No

Yes

Data center gateway, DCI, scale overlay

Firewall Filter-Based

MX, PTX EVO

No

GRE, GRE-in-UDP

GRE, IP-IP, GRE-in-UDP

No

No

Selective traffic encapsulation/de-encap sulation on data center gateways.

Junos OS and Junos OS Evolved based routing platforms support different kinds of overlay tunnels that can mainly be categorized as:

  • Interface-based tunnels

  • Dynamic Tunnels

  • Firewall filter-based tunnels

Interface-Based Tunnels

Interface-based tunnels must be explicitly configured, and their parameters must match at both tunnel endpoints. Examples include gr-, ip-, and lt- logical interfaces, as well as Flexible Tunnel Interfaces (FTIs). The key distinction is that gr- and ip- interfaces support per-tunnel bandwidth enforcement, whereas FTIs do not. In contrast, FTIs support a broader range of encapsulation types, depending on the specific platform.

FTIs can also be programmed using the Juniper Extension Toolkit (JET) API for controller-based deployments, a capability that is currently supported only on MX Series platforms.

Interface-based tunnels are used to carry payload traffic across IP networks and to direct packets toward various security and service functions, such as DDoS mitigation and traffic mirroring to remote sites. For each tunnel, operators must explicitly configure the source and destination addresses, along with the encapsulation type. At both ends of the tunnel, logical tunnel interfaces are provisioned so that dynamic or static routing—as well as service routing—can be configured over these interfaces.

GRE and IP-IP Tunnel Interfaces

Interface-based tunnels require explicit per-tunnel configuration, and all tunnel parameters must match at both endpoints. These tunnels are used to encapsulate and transport payload traffic over IP networks for use cases such as traffic steering, remote mirroring, and security service insertion (for example, DDoS mitigation).

You can configure interface-based tunnels when per-tunnel bandwidth enforcement is required. The following interface types are supported:

  • gr- interfaces (GRE tunnels)—Support IPv4, IPv6, MPLS, ISO, and Ethernet payloads.
  • ip- interfaces (IP-IP tunnels)—Support IPv4 and IPv6 payloads.
  • lt- interfaces (logical tunnels)—Used for stitching traffic between routing instances or logical systems within the same device.

Each tunnel must be explicitly configured with the source, destination, and encapsulation type. A logical tunnel interface is created at each endpoint to enable static or dynamic routing over the tunnel.

Interface-based tunnels are commonly used for:

  • Transporting traffic to remote sites with bandwidth enforcement
  • Steering traffic to security services such as DDoS scrubbing
  • Mirroring traffic to remote monitoring or analysis systems

Flexible Tunnel Interfaces (FTI)

Flexible Tunnel Interfaces (FTIs) require explicit configuration and are used when per-tunnel bandwidth enforcement is not required.

FTIs support multiple encapsulation types (such as GRE, IP-IP, and UDP), depending on the platform. They also support routing protocols (for example, BGP, OSPF, IS-IS, LDP, RSVP, and BFD), enabling traffic received from multiple customer edge devices to be transported across provider networks over tunnel overlays.

Unlike gr- and ip- interfaces, FTIs do not support per-tunnel bandwidth policing. However, they provide greater flexibility in encapsulation and forwarding behavior, including controller-driven or platform-optimized forwarding pipelines.

Common use cases include:

  • Traffic steering for DDoS mitigation
  • Remote traffic mirroring
  • IP fabric overlays using IP-IP tunnels
  • De-encapsulation for dynamic tunnel use cases (platform dependent)

FTIs use the loopback interface to support use cases such as mirroring traffic to remote destinations. After encapsulation, traffic is forwarded through the loopback interface on the ingress Packet Forwarding Engine and then sent to the final destination, including SR‑TE paths. The loopback interface has a bandwidth limit of 400 Gbps.

FTIs support GRE, IP-IP, and UDP encapsulation, configured using the tunnel encapsulation (gre | ipip | udp) statement under the [edit interfaces fti0 unit <unit-number>] hierarchy. Both source and destination addresses must be specified, and variable prefix masks are not supported.

Enabling tunnel-termination converts the tunnel to de-encapsulation-only mode and disables encapsulation. De-encapsulation can also be performed using firewall filters, which recirculate packets for inner header lookup and may introduce additional overhead. In contrast, inline tunnel termination processes packets in a single pass, improving performance. For unidirectional (termination-only) operation, configure tunnel-termination under the tunnel encapsulation hierarchy.

The following example shows how to configure tunnel termination with the device loopback address as the tunnel source.

The source address can be omitted, indicating that the tunnel terminates on the configured destination address. Optionally, tunnel-routing-instance specifies that, after de-encapsulation, the inner IP lookup uses the VRF ID of the routing instance.

The source lookup unit processes the de-encapsulated packets. The lookup key includes the IPv4 or IPv6 destination address and, optionally, the L3VPN address. If the first lookup succeeds, the tunnel is terminated. Otherwise, a second lookup is performed using the source address and the result of the first lookup. If this succeeds, the tunnel is terminated.

When tunnel-termination is enabled under [edit interfaces fti0 unit unit-number], tunnels are terminated on the WAN interface before actions such as sampling, port mirroring, or filtering.

To terminate tunnels on an incoming interface, configure tunnel-termination under [edit interfaces et <fpc>/<pic>/<port> unit unit-number].

Programmable Flexible Tunnel Interfaces via JET API

FTIs can be configured using JET APIs with GRE, IP-IP, and UDP encapsulation, allowing a controller to program tunnel interfaces directly into the forwarding plane over a gRPC connection without involving the routing protocol stack. VXLAN encapsulation is also supported.

One or more controllers program tunnel encapsulation profiles for outgoing traffic and de-encapsulation profiles for incoming traffic into the forwarding plane of the gateway device. A static route can also be programmed to point to a tunnel encapsulation profile for outgoing traffic. The controller communicates with the gateway device using JET APIs over gRPC.

When static routes are configured to point to API-programmed tunnel interfaces, no control plane protocols run over the tunnel. The controller acts as the single source of truth for tunnel state. If a tunnel interface is removed, the associated routes become inactive and are withdrawn from the forwarding plane.

Dynamic Tunnels

Interface-Based Dynamic GRE Tunnels

When a dynamic GRE tunnel is configured, a corresponding logical interface is automatically created for each tunnel. This behavior is known as interface-based dynamic tunnel mode and is the default method for dynamic tunnel creation.

A gr- interface is instantiated when BGP resolves a protocol next-hop that falls within the configured dynamic tunnel destination prefix range. It is automatically removed when no routes reference that tunnel destination.

Next-Hop-Based Dynamic Tunnels

Next-hop-based dynamic tunnels enable overlay networking over IP transport networks without requiring a tunnel interface for each endpoint. The system supports multiple overlay encapsulation types, including IP-IP, MPLS over UDP, MPLS over GRE, and VXLAN (EVPN Type-5). These tunnels rely on signaling through a dynamic routing protocol, typically BGP.

A dynamic tunnel is established when dynamic tunnel–specific attributes, such as encapsulation extended communities (for example, 0x8 for VXLAN or 0x030c:64512:13 for MPLS over UDP), are received from a remote peer along with IPv4 or IPv6 prefixes.

Prefixes received from a remote peer are installed in the forwarding plane as tunnel composite next hops (TCNH), with the destination pointing to remote tunnel endpoints. If the remote endpoint stops advertising these prefixes, the corresponding TCNH entries are removed from the forwarding plane, and the associated dynamic tunnel entries are also deleted.

Unlike interface-based dynamic GRE tunnels, next-hop-based dynamic tunnels do not create a logical interface for each tunnel. Tunnel endpoints are automatically managed, and no manual configuration is required to add or remove them.

Encapsulation options for next-hop-based dynamic tunnels are optimized for scale and for efficient hashing and load balancing across the transport network. While MPLS over GRE was initially supported, encapsulation types such as MPLS over UDP and VXLAN (EVPN Type-5) are widely used to improve hashing behavior and flow-based load balancing across ingress and transit nodes.

Firewall Filter-Based Tunnels

Firewall filter–based tunnels provide tunneling without requiring a dedicated tunnel interface. Packet encapsulation and de-encapsulation are performed in the forwarding plane using firewall filter actions, making tunnel behavior dependent on configured filter policies.

Encapsulation and de-encapsulation are defined within firewall filter terms and their associated actions. The resulting tunnel behavior is determined by the filter match conditions.

Firewall filter–based tunnels support encapsulation and de-encapsulation using GRE and GRE-in-UDP. In addition, de-encapsulation can also be performed for IP-IP and MPLS over UDP traffic. Filters can be applied at ingress or egress on an interface, as well as within the forwarding table.

These tunnels are typically used to transport transit traffic. Routing protocol sessions are not supported over firewall filter–based tunnels. Tunnel operation is unidirectional, and a corresponding filter must be configured for traffic in the reverse direction.

A single firewall filter can terminate multiple tunnels by using different match conditions across filter terms. Tunnel interfaces and filter-based de-encapsulation can coexist, with tunnel interface–based de-encapsulation taking precedence when both are configured.

Use Cases for Tunnel-Based Deployments

Port Mirroring to Remote Destinations

You can use port mirroring for traffic analysis on routers and switches that, unlike hubs, do not broadcast packets to every port on the destination device. Port mirroring sends copies of all packets or policy-based sample packets to local or remote analyzers where you can monitor and analyze the data.

For a device configured as a provider edge (PE) router on the customer-facing edge of a service provider network, you can apply a Layer 2 port-mirroring firewall filter at the ingress and egress points to mirror the traffic between the router and customer edge (CE) devices, such as routers and Ethernet switches.

Traffic received on tunnel interfaces can be mirrored to multiple destinations. You specify two or more destinations in a next-hop group, define a firewall filter that references the next-hop group as the filter action, and then apply the filter to a logical tunnel interface (lt-) or virtual tunnel interfaces (vt-).

See Configuring Port Mirroring and Configuring Port Mirroring for Remote Destinations.

When the data path traverses a flexible tunnel interface (FTI)-based tunnel, the router sends the output packet with tunnel encapsulation. You can configure packet mirroring to capture both the original packet and the fully encapsulated packet as it exits the interface.

To enable mirroring based on a filter installed on the FTI:

  • You mark packets for mirroring using the policy action at the FTI. The router typically uses the policy action to select the egress rewrite rule, but in this case, it uses the policy action to mark interesting packets with an internal policy attribute, without any special rewrite rule configured.

  • You have the software intercept packets that match the specific policy on the egress WAN side and initiate the l2-mirror action. Packets are reported with Layer 2 header information, including tunnel encapsulation.

    See Example: Configuring Local Port Mirroring on PTX Routers and Example: Configuring Remote Port Mirroring on PTX Routers.

Data Center Gateways

Data center gateways interconnect the Internet or enterprise VPNs on one side and virtual machines hosted on servers on the other side. Overlay transport technologies such as MPLS-over-GRE or MPLS-over-UDP are part of a data center design. Host routes are communicated to the data center gateway from the SDN controller and imported into virtual routing and forwarding (VRF) or Internet routing contexts. The data center servers are reachable through next-hop-based dynamic tunnels. Tunnels are established on servers in the BGP route protocol next-hop resolution process.

As described in RFC 5549, IPv4 traffic is tunneled from CPE devices to IPv4-over-IPv6 gateways. These gateways are announced to CPE devices through anycast addresses. The gateway devices then create dynamic IPv4-over-IPv6 tunnels to remote CPE devices and advertise IPv4 aggregate routes to steer traffic. Route reflectors with programmable interfaces inject the tunnel information into the network. The route reflectors are connected through internal BGP (IBGP) to gateway routers, which advertise the IPv4 addresses of host routes with IPv6 addresses as the next hop.

The MPLS-over-UDP tunnel is handled as follows:

  1. After an MPLS-over-UDP tunnel is configured, a tunnel destination mask route with a tunnel composite next hop is created for the tunnel in the inet.3 routing table. This IP tunnel route is withdrawn only when the dynamic tunnel configuration is deleted.

    The tunnel composite next-hop attributes include the following:

    • When the Layer 3 VPN composite next hop is disabled—Source and destination address, encapsulation string, and VPN label.

    • When the Layer 3 VPN composite next hop and per-prefix VPN label allocation are enabled—Source address, destination address, and encapsulation string.

    • When the Layer 3 VPN composite next hop is enabled and the per-prefix VPN label allocation is disabled—Source address, destination address, and encapsulation string. The route in this case is added to the other VRF instance table with a secondary route.

  2. The provider edge (PE) devices are interconnected using an IBGP session. The IBGP route next hop to a remote BGP neighbor is the protocol next hop, which is resolved using the tunnel mask route with the tunnel next hop.

  3. After the protocol next hop is resolved over the tunnel composite next hop, indirect next hops with forwarding next hops are created.

  4. The tunnel composite next hop is used to forward the next hops of the indirect next hops.

See Example: Configuring Next-Hop-Based MPLS-Over-UDP Dynamic Tunnels and Example: Configuring Next-Hop-Based IP-Over-IP Dynamic Tunnels .