EOS 4.36.1F TOI

EOS-4.23.1F added basic MLAG support for 7800R3, 7500R3 and 7280R3 platforms. The MLAG features that are currently supported are: Bridging, Routing, STP, VARP, L2 Multicast.

EOS-4.36.1F added basic MLAG support for 7800R4, 7280R4 and 7020R4 platforms.

This document describes how to integrate with Arista Media Control Service(MCS) supported APIs and the EOS releases that they are available in.

This document lists and describes the MCS supported features and the EOS releases that they are available in. Please refer here for information on how to configure and troubleshoot MCS and here for detailed API documentation.

The Media Control Service provides a deterministic high-performance service with an easy to use API interface to manage and monitor real-time broadcast workflows in IP networks. It allows fast programming of static multicast routes and IGMP snooping entries across L2/L3 interfaces with real-time tallies for feedback. This document describes how to provision, upgrade and troubleshoot Arista’s Media Control Service (both servers and clients).

BGP Monitoring Protocol (BMP) allows a monitoring station to collect information about a router’s BGP sessions, such as BGP announcements received from peers (Adj-RIB-In),  monitoring the Loc-Rib (as defined by RFC9096), and BGP announcements advertised from the router (Adj-RIB-Out). The announcements are sent to the station in the form of BMP Route Monitoring messages generated from the router’s BGP internal tables.

The Flexible Encapsulation (FlexEncap) feature is used in conjunction with pseudowire, L2, and L3 subinterfaces to match on incoming VLAN tags and retain and/or rewrite them on egress. In the case where VLAN tags are swapped or pushed, the class of service (CoS) field of any new VLAN tag is set based on the configured traffic-class to CoS mapping. That is, based on the traffic class the incoming packet traversed through, the CoS of all VLAN tags of the outgoing packet is determined by the result of the traffic-class to CoS map.

S supports L3 EVPN gateway with Type 5 nexthop-self mechanism. While the nexthop-self mechanism is simple to operate, the L3 gateway lacks the support to rewrite the EVPN route distinguisher as well as the BGP route target. This feature supports an alternative L3 EVPN gateway mechanism using multi-domain L3 VRF instead. A multi-domain IP VRF allows configuring not only the local domain route distinguisher (RD) and route targets (RT), but also the remote domain route distinguisher and route targets on a DCI gateway.

Until EOS release 4.32.0F, EOS allows users to statically configure link min-delay and max-delay used for IS-IS FlexAlgo. This feature adds support for dynamic measurement of link delay using the TWAMP Light protocol described in RFC 8186 and provides it to IS-IS FlexAlgo dynamically.

This document describes how to configure and monitor this feature.

eAPI over SSH provides programmatic access to Arista EOS Command API using SSH as the transport protocol, offering an alternative to HTTP/HTTPS-based eAPI. This feature enables network automation tools and scripts to execute CLI commands and retrieve structured output via JSON-RPC 2.0 over an SSH connection.

The feature uses the standard SSH subsystem mechanism, allowing clients to invoke the "eapi" subsystem after SSH authentication. Commands and responses use the same JSON-RPC 2.0 format as HTTP-based eAPI, ensuring compatibility with existing eAPI client libraries and scripts with minimal modifications.

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol which allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. ECN operates over an active queue management algorithm.

This feature adds control plane support for inter-subnet forwarding between EVPN networks. This support is achieved by advertising received EVPN IP Prefix routes (Type-5) with next-hop self. VXLAN and MPLS encapsulation are supported, and the encapsulation type used for advertised routes is dependent on the encapsulation type configured for EVPN peering. The following diagram shows an example topology where an EVPN VXLAN network exchanges Type-5 routes with an EVPN MPLS network.

Smart System Upgrade (SSU) provides the ability to upgrade the EOS image with minimal traffic disruption. SSU is supported on a standalone L2 only VTEP with EVPN-VXLAN configuration with the following scale is supported as of EOS 4.32.0F with the following scale numbers

Typical WiFi networks utilize a single, central Wireless LAN Controller (WLC) to act as a gateway between the wireless APs and the wired network. Arista differentiates itself by allowing the wireless network to utilize a distributed set of aggregation switches to connect APs to the wired network. This feature allows a decentralized and distributed set of aggregation switches to bridge wireless traffic on behalf of the set of APs configured to VXLAN tunnel all traffic to those aggregation switches, or their “local” APs.

Control Plane Policing (CoPP) classifies control plane traffic into different classes (e.g., IGMP, LLDP, PTP, OSPF) and applies rate limiting per class using queues shaping. However, when multiple flows within the same CoPP class share a single queue, a single high-rate flow can consume the entire allocated bandwidth for that class, starving other legitimate flows.

EOS-4.24.0 adds support for hardware-accelerated sFlow on R3 systems. Without hardware acceleration, all sFlow processing is done in software, which means performance is heavily dependent on the capabilities of the host CPU. Aggressive sampling rates also decrease the amount of processing time available for other EOS applications.

IFA Latency Analyzer feature measures round trip time(RTT) and per-hop latency( residence time) between source and destination switches by sending IFA(Inband Flow Analyzer) probes.

This feature when configured enables users to rewrite the DSCP of the GUE encapsulated header on IP-over-UDP tunnels while preserving the TOS value of the inner IP ( IPv4 / IPv6 ) payload. Starting from software version 4.34.1F, the CLI configuration to enable or disable DSCP preserve globally on the egress interface introduces a clear distinction in the behavior of GUE encapsulation on the core facing interface of the IP-over-UDP tunnels. ( The user can configure DSCP to be rewritten using a set DSCP action via QoS Policy-Map or Traffic-Policy )

The document describes the support for dedicated and group ingress policing on interfaces without using QoS policy-maps to match on the traffic and apply policing.

This document describes the support for interface policing counters on interfaces where interface policing feature is configured. Counters for this feature provide information on how many packets are being allowed or dropped on a given interface via the policers configured. The counters are only supported on interfaces where dedicated policers are configured.

VLAN COS and IP DSCP values in a packet may be inconsistent. Without this feature, regardless of the interface's QoS trust mode, VLAN tagged packets always use the VLAN COS value as the input priority for PFC PG selection. This can lead to unpredictable PFC behavior. This feature allows tagged packets to use the QoS trust mode as the source for PG selection, instead of always using VLAN COS. This unifies the behavior for tagged and untagged packets, ensuring consistent PFC operation.

This document is an extension to the decap group feature, that allows IPv4 addresses to be configured and used as part of a group. Now we will be able to configure IPv4 prefixes as a decap group.

The document describes an extension of the decap group feature, that allows IPv6 addresses to be configured and used as part of a group. IP-in-IP packets with v6 destination matching a configured decap group IP will be decapsulated and forwarded based on the inner header. That will allow any IP-to-IP packet type to be decapsulated, i.e. IPv4 in IPv4, IPv4 in IPv6, IPv6 in IPv4 and IPv6 in IPv6.

This solution allows delivery of both IPv4 and IPv6 multicast traffic in an IP-VRF using an IPv6 multicast in the underlay network. The protocol used to build multicast trees in the underlay network is IPv6 PIM-SSM.

The document describes an extension of the decap group feature, that allows IPv6 addresses to be configured and used as part of a group. IP-in-IP packets with v6 destination matching a configured decap group IP will be decapsulated and forwarded based on the inner header. That will allow any IP-to-IP packet type to be decapsulated, i.e. IPv4 in IPv4, IPv4 in IPv6, IPv6 in IPv4 and IPv6 in IPv6.

This document is an extension to the Decap Group feature that allows IPv6 addresses to be configured and used as part of a decap group. Now we will be able to configure IPv6 prefixes as a decap group. Tunneled packets with IPv6 destination matching to a configured prefix decap group will be decapsulated and forwarded based on the inner header. IP-in-IP tunnel type will be supported for prefix based decap groups.

Some applications are highly sensitive to traffic loss lasting tens of milliseconds or more, yet typical router convergence after a link or node failure can take several hundred milliseconds. To minimize this loss, the router must rapidly activate a precomputed alternate repair path for all prefixes affected by the failure. IP FRR enables this by precomputing the repair path, allowing the router to switch to it immediately upon failure without waiting for full convergence.

Support for Multiple Router Capability TLVs (Type 242) in IS-IS LSPs. In modern segment-routed networks, a single router often needs to advertise a vast amount of capability data, including Segment Routing (SR) blocks, SRv6 capabilities, Node Maximum Stack Depth (MSD), Flexible Algorithm Definitions (FAD),  etc.

In modern networks, especially those handling real-time data, network performance metrics like bandwidth and latency are as crucial for data-path selection as traditional routing metrics. Incorporating this performance data into path selection offers an advantageous, scalable, and cost-effective method for network optimization.

Subinterfaces divide a single ethernet or port channel interface into multiple logical L3 interfaces based on the 802.1q tag (VLAN ID) of incoming traffic. Subinterfaces are commonly used in the L2/L3 boundary device, but they can also be used to isolate traffic with 802.1q tags between L3 peers by assigning each subinterface to a different VRF. L3 subinterface shaping + VRF is also supported.

Control Plane Policing (CoPP) classifies control plane traffic into protocol classes (e.g., IGMP, LLDP, BGP) and applies rate limiting per class using queue shaping. On supported platforms, all control plane traffic for a given protocol class is directed to a single queue regardless of the ingress port. As a result, a high-rate flow from a single port or host can consume the entire bandwidth allocated to that class, starving legitimate control plane traffic arriving on other ports.

Interface policing enforces traffic rate limits on ingress interfaces by configuring policer profiles with a lower rate (CIR) and/or higher rate (PIR) and a burst-size (CBS and/or EBS). The current implementation limits the maximum burst-size (CBS/EBS) to 4 MB. The large burst support feature extends the maximum configurable burst size for interface policers from 4 MB to 256 MB.

If a network device uses deep packet inspection for load balancing, RFC6790 recommends deployments to use entropy label in LDP to improve load balancing in MPLS networks by providing sufficient entropy in the label stack itself.

LDP over RSVP (also known as LDP tunneling) allows LDP-signaled LSPs to use RSVP-TE tunnels as forwarding shortcuts instead of following hop-by-hop IGP paths. Prior to this feature, LDP over RSVP was supported only with IS-IS as the IGP. This feature extends LDP over RSVP support to OSPF, enabling both headend (ingress) and transit functionality when OSPF is the IGP.

Custom maintenance units with per-interface-type profiles (e.g., different shutdown behavior for L2 vs L3 ports) previously required manual tracking and updating of BGP VRF groups whenever VRFs were added or deleted. The System unit auto-includes all AllBgpNeighborVrf-* groups dynamically. However, it cannot be used when granular interface profiles are required, as a single profile is applied to all ports.

A new CLI command group auto bgp builtin enables a custom unit to behave like the System unit for BGP VRF group auto-inclusion: all builtin BGP VRF groups (AllBgpNeighborVrf-<vrf>) are automatically added to the unit and kept in sync as VRFs are created or deleted.

Container-based deployments make creating cloud portable applications extremely easy. An application can be written on normal build infrastructure, that in turn can be run on a EOS switch or any Linux device that runs docker run time engine. So the same applications that are run on a server for microservices can be run on a switch with Arista EOS. Since Arista extensible operating system is simply linux (AlmaLinux 9.7 at this time – 2026) we are able to integrate a container runtime engine into the operating system.

MetaWatch is an FPGA-based feature available for Arista 7130 Series platforms. It provides precise timestamping of packets, aggregation and deep buffering for Ethernet links. Timestamp information and other metadata such as device and port identifiers are appended to the end of the packet as a trailer.

Mirroring to a GRE tunnel allows mirrored packets to transit to a L3 network using GRE encapsulation.

EOS now exposes ASIC integrated-circuit memory health metrics via gNMI, under the vendor-augmented OpenConfig component tree. Two categories of memory are reported per chip instance: DRAM Bulk Data Block (BDB) free counts and SRAM buffer free counts. Each category provides three views: current value, minimum observed since last reset, and minimum observed in the latest polling interval.

EOS 4.22.1F added support for multiple OSPFv2 instances to be configured in the default VRF. This feature provides isolation and allows for segregating/dividing the link state database based on interface.

The Per-MAC ACL feature provides the functionality to apply an IPv4/IPv6 ACL to a 802.1x supplicant instead of applying them on the port that the supplicant is behind. This allows for more flexible and specific traffic policies to be defined for supplicants trying to access certain resources on the network.

Similar to reconfiguring the traffic-class to transmit-queue map, the traffic-class to priority-group mapping can also be changed using the CLI. This enables configuration capability to the user who can adjust the mapping based on the nature of the traffic. This configuration change doesn’t inhibit the flow of traffic.

Routes covered by a resilient equal-cost multi-path (RECMP) prefix are types of routes that make use of hardware tables dedicated for equal-cost multi-path (ECMP) routing. Resilient ECMP deduping is a new feature wherein the switch will reactively attempt to reduce the number of ECMP hardware table entries allocated by forcing routes that share the same set of next hops but point to different hardware table entries to point to the same hardware table entry when hardware resource utilization is high. Forcing RECMP routes to change the hardware table entry that they point to may potentially cause a traffic flow disruption for any existing flows going over that route. The deduping process will attempt to minimize the amount of potential traffic loss caused.

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for Routing protocol attributes

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for Bgp agent points of application:

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for IpRib agent points of application Configuration of RCF

RSVP-TE, the Resource Reservation Protocol (RSVP) for Traffic Engineering (TE), is used to distribute MPLS labels for steering traffic and reserving bandwidth. The Label Edge Router (LER) feature implements the headend functionality, i.e., RSVP-TE tunnels can originate at an LER which can steer traffic into the tunnel.

RSVP-TE applies the Resource Reservation Protocol (RSVP) for Traffic Engineering (TE), i.e., to distribute MPLS labels for steering traffic and reserving bandwidth.The EOS implementation supports:

VXLAN UDP-ESP support allows the customer to encrypt traffic between two VXLAN VTEPs. The frame format looks like: NOTE, Secure VXLAN is s~upported with both the sectag2 and UDP-ESP format in 4.27.1, where sectag2 is the default encapsulation format. However, the sectag2 format is deprecated and should not be used.

Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an “SR Policy”. EOS 4.21.0F adds support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments with BGP and locally configured policies as sources of SR Policies on Arista’s 7500, 7280 families of switches.

Subinterfaces divide a single ethernet or port channel interface into multiple logical L3 interfaces based on the 802.1q tag (VLAN ID) of incoming traffic. Subinterfaces are commonly used in the L2/L3 boundary device, but they can also be used to isolate traffic with 802.1q tags between L3 peers by assigning each subinterface to a different VRF