On PTX10008 systems equipped with LC1201 line cards, GRE-tunneled traffic can experience uneven distribution across aggregated Ethernet (AE) member links or ECMP next hops if only the outer tunnel header is considered for load balancing. This imbalance can occur when many GRE tunnels or sessions share the same outer source and destination IP addresses, causing some links to become congested while others remain underutilized. Understanding how the hardware hash function evaluates both the outer and inner packet
fields helps engineers diagnose and resolve link-utilization imbalance when troubleshooting GRE traffic distribution on this platform.

• Uneven traffic distribution is observed across AE member links or ECMP
  paths carrying GRE-encapsulated traffic, even though the overall number
  of unique tunnels/sessions is high.
• Per-link packet/byte counters show significant deviation when compared
  across member links:

  show interfaces <ae-member-interface> extensive
  show interfaces ae0 statistics extensive
  

• Some member links run near capacity while others remain lightly loaded,
  despite similar member-link bandwidth.
• The imbalance is most noticeable when traffic consists of many GRE
  tunnels/sessions that share the same outer IP address pair, and/or when
  inner payloads are fragmented.

By default, Junos uses an "enhanced hash key" algorithm that computes the
load-balancing hash using fields from both the outer and inner packet
for GRE-encapsulated traffic (not just the outer header):

• Outer fields: source/destination MAC and IP (IPv4/IPv6), VLAN, MPLS
  label, Layer 4 ports, and the GRE key/protocol fields.
• Inner fields (when the inner packet is not fragmented): source/
  destination IP, IPv6 flow label, MPLS label, Layer 4 (TCP/UDP/SCTP)
  ports, and (for GRE-in-GRE) the inner GRE key/protocol fields.
• GTP tunnel-ID and VXLAN fields are supported by the hardware but are
  not enabled by default on this platform.

This means multiple GRE tunnels sharing the same outer IP pair are still
load-balanced effectively, since the inner-packet fields add entropy to the
hash. However:

• Fragmented packets (outer or inner) lose access to Layer 4 port
  fields for hashing, which can reduce distribution quality specifically
  for fragmented GRE traffic.
• On PTX10001-36MR, LC1201, and LC1202 (used in PTX10004/PTX10008/
  PTX10016 chassis), only 256 hash buckets are supported per ECMP next
  hop. This limits the granularity of load-balancing, especially on AE
  bundles with a very large number of member links, where deviation can be
  more noticeable than on platforms supporting more buckets.
• If significant deviation is seen with a very large number of flows
  already well spread across inner-packet fields, enabling adaptive load
  balancing may not help — adaptive load balancing is most effective for a
  mix of large ("fat") and small ("thin") flows, not for rebalancing an
  already-even, high-flow-count distribution.

If uneven link utilization is observed, verify that inner-packet traffic
has sufficient diversity in source/destination IP and Layer 4 ports, and
consider reducing fragmentation of GRE-encapsulated traffic where possible
to preserve full hash entropy.

• Multiple GRE tunnels or sessions sharing the same outer IP pair will still be load-balanced effectively across member links/ECMP paths, because inner-packet fields are factored in — provided the inner packet is a standard IPv4/IPv6/TCP/UDP flow.
• Fragmented packets (either the outer GRE packet or the inner payload) lose access to the inner Layer 4 port fields for hashing, since those offsets aren't available in a fragment — this can reduce hash entropy specifically for fragmented GRE traffic.
• ECMP bucket scale limit: PTX10001-36MR, LC1201, and LC1202 (in PTX10004/10008/10016 chassis) support a maximum of 256 hash buckets per ECMP next hop. This caps the granularity of adaptive load balancing (if in use) — fewer buckets mean coarser rebalancing adjustments compared to platforms supporting more buckets.
• This behavior has been the default since Junos 18.3R1 and is consistent across EVO-based PTX platforms using this chipset family.

First publication 2026-10-06