IPv4 ECMP Works on Arista cEOS Release 4.35.2F

Key Takeaways

• cEOS 4.35.2F enables IPv4 ECMP forwarding
• Forwarded traffic splits across multiple equal-cost paths
• Locally originated traffic still follows single path
• EOS traceroute uses UDP, obscuring anycast node selection
• Underlying Linux routing table shows single ECMP entry

Summary

Arista’s cEOS 4.35.2F release finally supports IPv4 ECMP, allowing forwarded traffic to be balanced across multiple equal‑cost paths in an anycast topology. The lab test shows packets alternating between two downstream nodes, confirming functional ECMP. However, locally originated traffic still follows a single path, revealing a discrepancy between control‑plane visibility and data‑plane behavior. EOS’s UDP‑based traceroute further masks which anycast node receives the traffic, complicating diagnostics.

Pulse Analysis

Equal-cost multipath (ECMP) routing is a cornerstone of modern data‑center fabrics, allowing traffic to be balanced across several paths with identical metrics. In anycast deployments, multiple nodes share a single IP address, relying on ECMP to distribute packets and improve redundancy. Historically, virtual network operating systems such as Arista’s cEOS struggled to install more than one equal‑cost route in the Linux forwarding table, limiting their usefulness for realistic lab simulations. The recent 4.35.2F release changes that narrative, delivering functional IPv4 ECMP for forwarded traffic.

The new cEOS version leverages the underlying Linux kernel to populate multiple next‑hops for a /32 anycast prefix, yet the kernel’s routing table still reports a single entry, indicating a hidden abstraction layer within EOS. Forwarded packets now traverse both L2 and L3 nodes, as demonstrated by traceroute output that shows alternating hops. However, locally generated probes continue to follow a single path, exposing a discrepancy between control‑plane visibility and data‑plane behavior. Additionally, EOS’s UDP‑based traceroute returns ICMP messages from the destination address, making it impossible to pinpoint which anycast node handled the packet.

For network engineers, this development expands the fidelity of virtual lab environments, enabling more accurate testing of load‑balancing algorithms, failure scenarios, and MPLS anycast designs without physical hardware. The partial ECMP support also signals Arista’s commitment to aligning cEOS with production‑grade EOS features, a trend that could accelerate adoption of container‑based network functions. Operators should still validate end‑to‑end path selection, especially for control‑plane traffic, and consider supplemental tools to reveal the true anycast endpoint. As cEOS matures, full parity with native ECMP for both inbound and outbound traffic is likely forthcoming.