Understanding GRE Loopback-Avoidance Mode and GRE-Only Tunnel Services Scaling

Benefits

• GRE Tunnel Loopback Avoidance-Reduce packet-forwarding overhead on the PFE by eliminating loopback recirculation for GRE encapsulation. This lowers bandwidth consumption on the hosting line card and can improve headend tunnel efficiency.

• High-Scale GRE Interfaces-Increase GRE interface scale by allowing up to 16,000 IFLs per gr- interface and up to 32,000 GRE IFLs per chassis. This scale enables deployments that map large numbers of services or subscribers to individual GRE interfaces.

Loopback Avoidance (Loopback‑less GRE Encapsulation)

When you enable loopback‑less encapsulation on a GRE physical interface using the no-tunnel-services option, at the [edit interfaces gr-x/y/z ]hierarchy, GRE encapsulation is performed inline on the PFE. The packet is immediately forwarded based on the outer IP header without recirculating through a loopback outgoing interface.

In this mode, the forwarding context switches directly from the inner header to the outer header within a single pipeline pass. This eliminates the need for a second parse and lookup stage that is otherwise required when packets traverse a loopback interface.

GRE decapsulation already operates inline; therefore, the primary behavioral change applies to the headend (encapsulation) path. By avoiding loopback processing and GRE‑specific queuing stages in the tunnel‑services path, loopback‑less encapsulation reduces loopback bandwidth consumption and improves forwarding efficiency.

GRE Logical Interface Scaling

To increase GRE logical interface scale, you must explicitly allocate tunnel‑services resources to GRE by configuring GRE‑only modes at the chassis, PIC, or tunnel‑port level.

At the PIC level, configure the following command to restrict a PIC to GRE interfaces only:

set chassis fpc fpc-slot pic pic-slot tunnel-services interface-type gr

When configured, the system removes other tunnel interface types from that PIC and allocates the full logical interface and cookie resources exclusively to GRE.

On platforms that support per–tunnel‑port configuration, you can further refine this allocation by dedicating individual tunnel ports to GRE:

set chassis fpc fpc-slot pic pic-slot tunnel-services tunnel-port tp-slot interface-type gr

This allows selected ports to operate in GRE‑only mode while leaving other ports available for mixed tunnel types.

In GRE‑only mode, the system supports:

• Up to 16,000 GRE logical interfaces per gr-physical interface
• Up to 32,000 GRE logical interfaces per chassis, distributed across eligible PICs and tunnel ports

At the PIC level, bandwidth configuration is optional. If not explicitly configured, a default bandwidth of 400 Gbps is applied. However, in the per-tunnel-port level, configuring bandwidth is mandatory.

QoS Considerations for GRE Traffic

QoS semantics for GRE traffic are controlled using a combination of ToS/DSCP copy settings, static traffic‑class configuration on GRE logical units, and firewall‑based classification.

Behavior aggregate (BA) classifiers are not supported on GRE logical interfaces. As a result, firewall filters must be used for traffic classification.

When operating in loopback‑less mode, carefully consider where firewall filters, policers, and sampling points are applied. Depending on the processing stage, these features may see either the inner packet headers or the outer GRE headers along the forwarding path.

Observe the following guidelines while configuring (gr-) interfaces

• You can configure GRE logical interfaces under the inet, inet6, and bridge families.

• You can deploy GRE logical interface as part of a routing instance.

• On headend traffic, you can copy inner markings to the outer header using the command set interfaces gr-fpc/pic/port unit unit tunnel copy-tos-to-outer-ip-header.

• For IPv4 transit GRE, you can additionally enable copy-tos-to-outer-ip-header-transit on the GRE unit, together with the command set chassis copy-tos-to-outer service-type gre. When you need fixed markings, apply the command set interfaces gr-fpc/pic/port unit unit tunnel traffic-class value to stamp a static DSCP or traffic class on the outer header.

• You can use inline J-Flow and port mirroring on the media interfaces that carry GRE traffic, and you can deploy GRE logical interfaces in inet, inet6, and bridge families and within routing instances and logical systems.

• Filters and policers at the fast-tap or real-time transport (RTT) context continue to see the original headers (pre-encapsulation or pre-decapsulation) because the packet is not re-parsed after encapsulation, while filters applied on the egress logical interface see the new headers (post-encapsulation or post-decapsulation) and police based on the final packet length.

• Firewall log entries and mirrored packets on egress reflect the encapsulated form, whereas input-side logging and mirroring see the decapsulated or pre-encapsulation packet. Family any mirroring is not supported on GRE logical interfaces.

• Because you bypass the GRE tunnel-services queues in loopback-less mode, you cannot use hierarchical scheduling, per-unit scheduling, or queue statistics on the gr- physical interface or its logical interfaces. Instead, the system queues and schedules traffic on the final WAN interface. The system enforces this by rejecting configurations such as hierarchical-scheduler on the GRE physical interface, reassemble-packets and tunnel allow-fragmentation on the GRE unit, and force-control-packets-on-transit-path when no-tunnel-services is present.