Configuring Tunnel Interfaces on MX Series Routers and PTX Series Routers

• Interface (gr-, lt-, and ip-​​​)-based tunnels —You can configure interface-based tunnels when the bandwidth profile enforcement is required​. ​The GRE tunnels support IPv4, IPv6, MPLS, ISO, and Ethernet payload, whereas the IP-IP tunnels support IPv4 and IPv6 payload.

  You can configure interface-based tunnels to implement:

  • Tunneling over an IP network with bandwidth enforcement per tunnel. For example, toward the remote site.

  • Steering for DDoS cleaning.

  • Mirroring to remote destinations.

  During the GRE process, after the GRE header is added to the packet, the packet is looped back to the same Packet Forwarding Engine for a second lookup. The packet enters the ingress pipeline back through the loopback interface, which has a limited bandwidth of 400G. The encapsulated packet is then forwarded to the destination.

  GRE tunnel de-encapsulation is implemented by inline tunnel termination and does not use the loopback stream. However, the overall packet performance of the Packet Forwarding Engine is impacted due to extra fabric hops as the traffic flow switches from one Packet Forwarding Engine to another.

• Flexible tunnel interfaces (FTIs)—You can configure FTIs when the bandwidth profile enforcement is not required. FTIs support both IPv4 and IPv6 payload. You can configure FTIs to implement:

  • Mirroring to remote destinations.

  • IP fabrics with IP-IP overlays.

  • Steering for DDoS cleaning.

  The packet performance is reduced due to the extra lookup after encapsulation and de-encapsulation.

• Dynamic tunnels—You can configure dynamic tunnels to design data center gateways.

  In the dynamic tunnels implementation with loopback avoidance, the packet performance is reduced due to the extra lookup after an encapsulation or de-encapsulation.

• Firewall filter-based tunnels— These tunnels support:

  • GRE and GRE in UDP encapsulation.

  • GRE, IP-IP, and GRE in UDP de-encapsulation.

  You can configure firewall filter-based tunnels to design data center gateways.

  You can configure GRE-based encapsualtion and de-encapsulation using a firewall filter action without using a tunnel interface. Encapsulation and de-encapsulation happens at the Packet Forwarding Engine which processes the filter. MX Series routers support firewall filters at:

  • Interface level on input (executed on the ingress Packet Forwarding Engine)

  • Interface level on output (executed on the egress Packet Forwarding Engine)

  • Forwarding table level (either before route lookup or after route lookup). In both cases, the filter is executed on the ingress PFE

  In this scenario, the packet performance is reduced due to the extra lookup after encapsulation. In case of de-encapsulation, the packet performance is reduced due to the filter configuration.

Tunnel Interfaces on PTX10001-36MR, PTX10004, PTX10008, and PTX10016-Overview

This section provides information about configuring tunnel interfaces to implement different features on PTX10001-36MR, PTX10004, PTX10008, and PTX10016 routers with Junos OS Evolved.

• Flexible tunnel interfaces (FTIs)—You can configure FTI-based tunnels to implement:

  • Steering for DDoS cleaning.

  • De-encapsulation for all dynamic tunnels use cases.

  These tunnels support GRE, UDP, and IP-IP encapsulation and de-encapsulation options. The reduction in the packet performance depends on the encapsulation option. Encapsulation supports flattened next-hop topology..

  You can configure GRE tunnels on flexible tunnel interfaces. When you enable the tunnel-termination statement at the [edit interfaces fti0 unit unit-number family (inet | inet6)] hierearchy, tunnels are terminated on the WAN interface before any other actions, such as sampling, port mirroring, or filtering, are applied.

• Flexible tunnel interfaces (FTIs) through a loopback—You can configure FTIs to implement mirroring to remote destinations​.

  On an FTI, after tunnel encapsulation, traffic is sent into the loopback interface (on the ingress Packet Forwarding Engine) and later to the ultimate destination. The destinations could include those behind segment routing–traffic engineered (SR-TE) next hops. The loopback interface has a limited bandwidth of 400G.

  You can configure GRE/IP-in-IP/UDP tunnel encapsulation on FTIs using the loopback interface. You can configure encapsulation by using the command tunnel encapsulation (gre|ipip|udp) source address destination address at the [edit interfaces fti0 unit unit-number hierarchy. You must consider the following points while configuring this feature:

  • Adding tunnel-termination makes the tunnel decap-only tunnel and encapsulation is disabled.

  • Specifying both the source and destination address is mandatory when you do not configure the command.

  • Configuring a variable prefix mask on the source address is not allowed

    When you configure a firewall filter for de-encapsulation, the frewall filter de-encapsulates the packets based on the configured match conditions and action. Then de-encapsulated packets are re-circulated back to ingress block to do inner header lookup and forwarded accordingly. However, tunnel termination is completed in a single pass of packet processing, thus providing performance improvement over filter based process.

    To enable termination only mode, where the tunnel is unidirectional, you can configure tunnel-termination at the [edit interfaces fti0 unit unit_number tunnel encapsulation (gre|ipip|udp)]hierarchy on the FTI.

    The source address can be excluded which indicates that the tunnel terminates on the configured destination address. The optional tunnel-routing-instance indicates that after de-encapsulation, the inner IP lookup is done with VRF ID corresponding to routing-instance.

    Packets to be de-encapsulated are processed in the source lookup unit. The search key contains the IPv4 or IPv6 destination address and optionally L3VPN address if the tunnel need not be terminated on all interfaces. If the first lookup is succesful, no more source lookup is needed and tunnel is terminated. If second lookup is needed on the source address, the source lookup unit does another lookup using source address and first lookup result as the key. If the second lookup is successful, the tunnel is terminated.

    When you enable the tunnel-termination statement at the [edit interfaces fti0 unit unit-number] hierarchy, tunnels are terminated on the WAN interface before any other actions, such as sampling, port mirroring, or filtering, are applied.

    To enable tunnel termination on the incoming interface configure tunnel-termination at the [edit interfaces et fpc/pic/port unit unit_number]

• Dynamic tunnels— You can configure dynamic tunnels to design:

  • IP fabrics.

  • IP overlays.

  • Data center gateways.

  These tunnels support IP-IP encapsulation.

  PTX Series routers with Junos OS Evolved, ​do not support dynamic tunnels for de-encapsulation.. Instead, you can use static FTI tunnels for de-encapsulation, without specifying the destination address. The tunnels are configured with the de-encapsulation-only option.

  You can configure next-hop-based dynamic UDP tunnels, also known as MPLS-over-UDP tunnels. Junos OS dynamically creates next hops to resolve the tunnel destination route. You can also use policy control to resolve MPLS-over-UDP tunnels over select IP prefixes. Because when the next-hops are enabled by default, the MPLS-over-UDP feature provides a scaling advantage for the number of IP tunnels supported on the router.

Tunnel Interfaces on PTX1000, PTX5000, and PTX10002-50C-Overview

This section provides information about configuring tunnel interfaces to implement different features on PTX1000, PTX5000, and PTX10002-50C routers with Junos OS Evolved.

• Flexible tunnel interfaces (FTIs)—You can configure FTIs to implement IP fabric. We prefer this option when we need to reach tunnel destinations through IP. These tunnels support:

  • GRE, UDP, and IP-IP encapsulation options.

  • UDP and IP-IP de-encapsulation options.

  The packet performance is reduced due to the extra lookup after encapsulation and de-encapsulation.

• Dynamic tunnels—You can configure dynamic tunnels to design data center gateway. The packet performance is reduced due to extra lookup after encapsulation and de-encapsulation.

• Firewall filter-based tunnels—You can configure firewall filter-based tunnels to implement egress peering engineering (EPE). The packet performance is reduced during encapsulation due to the extra lookup.

• Mirroring to remote destination— You can implement tunneling of mirrored packets to remote destinations. The packet performance is reduced during encapsulation due to the extra lookup.

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 an MX Series router 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 MX Series router and customer edge (CE) devices, such as routers and Ethernet switches.

On MX Series routers, you can mirror traffic arriving at tunnel interfaces 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-) on the MX Series router.

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 set up a configuration that mirrors the original packet as well as the packet with all encapsulations as it as it exits the interface out.

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 RoutersExample: 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