Tag :: EOS 4.36.1F

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.

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network. We support dot1x protocol standard 802.1X-2004 (version=2)

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).

Automatic certificate management provides support for retrieving signed x509v3 certificates from a server under the Enrollment over Secure Transport (EST) protocol, described in RFC 7030. The feature provides only EST client capabilities. This document describes automatic retrieval of CA certificates which is an update to the existing TOI which can be found here. All updates are highlighted.

This feature adds support for a dynamic configuration model to eliminate the need for the network administrator to

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.

This feature adds support for BGP UCMP in the multi agent routing protocol model. The TOI for BGP UCMP in the ribd

This feature allows failover to the backup path to occur in constant time per interface going down for features such as RSVP link protection, RSVP node protection, TI-LFA link protection, and BGP PIC. Without this feature enabled, it would take time proportional to the number of paths going over the interface experiencing the link down event to failover to the backup path. With this feature enabled, the failover time would be constant regardless of the number of paths.

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.

This feature allows the configuration of custom DSCP-to-DSCP maps on a per-Nexthop Group (NHG) basis. When applied it rewrites the DSCP of the outer IP header of IPvX-in-IPvX (X represents both v4 and v6) encapsulated packets using the inner IPvX header’s DSCP value while ensuring the DSCP of the inner IPvX overlay is preserved.

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.

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. SR-TE policies allow creating segment lists using segments along the shortest path or along a flex algo path. These policies can be traffic engineered to avoid the shortest or flex-algo paths.

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.

As Ethernet technologies made their way into the Metropolitan Area Networks (MAN) and the Wide Area Networks (WAN) from the conventional enterprise level usage, they are now widely being used by service providers to provide end-to-end connectivity to customers. Such service provider networks are typically spread across large geographical areas. Additionally, the service providers themselves may be relying on certain internet backbone providers, referred to as “operators”, to provide connectivity in case the geographical area to be covered is too huge.

Multihoming in EVPN allows a single customer edge (CE) to connect to multiple provider edges (PE or tunnel endpoint). In any multihoming EVPN instance (EVI), for each ethernet segment a designated forwarder is elected using EVPN type 4 Ethernet Segment (ES) routes sent through BGP. In single-active mode, the designated forwarder (DF) is responsible for sending and receiving all traffic. In all-active mode, the DF is only used to determine whether broadcast, unknown unicast or multicast packets should be egressed in order to avoid sending multiple copies of the same packet to a CE.

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.

EVPN gateway support for all-active (A-A) multihoming adds a new redundancy model to our multi-domain EVPN solution. This deployment model introduces the concept of a WAN Interconnect Ethernet Segment identifier (WAN I-ESI).

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.

Hardware-based GRE tunnel interface counters are supported on the DCS-7050X4 platform family starting from EOS-4.36.1 release. When GRE tunnels are configured and traffic is hardware-forwarded, per-tunnel packet and byte counters are available for both ingress (decapsulation) and egress (encapsulation) directions. The hardware tunnel counters are disabled by default and must be explicitly enabled using the `hardware counter feature` CLI command. The ingress and egress counters can be enabled independently.

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.

ICMP Probe allows querying of interface status and ARP or Neighbor Discovery table status remotely.  It is a request/response protocol, similar to ping, but instead of simply responding to the request, it responds with information about a local interface or a remote neighbor.  The node being queried is called the "proxy node".

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 optimizes the utilization of hardware resources by sharing the hardware resources between different VLAN interfaces when they have the same ACL attached in the ingress direction. This is particularly useful for larger deployments where the ACL is applied to multiple VLANs and with the RACL sharing capability, lesser hardware resources are used irrespective of the number of VLANs.

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.

At a high level, L1 profiles are a set of configurations which allow EOS users to change the numbering scheme and default L1 configurations of all front panel interfaces across their network switch. On Arista network switches, front panel transceiver cages are exposed as ports which are numbered sequentially: 1, 2, 3, 4, etc. These identifiers are usually marked on the front panel to allow for easier identification.

This feature is available when configuring BGP in the multi agent routing protocol model. Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family: L2VPN (address family number 25) / EVPN (subsequent address family number 70). It is used to exchange overlay MAC and IP address reachability information between BGP peers . EVPN supports the exchange of layer 3 IPv4 and IPv6 overlay routes through the extensions described in (type 5 EVPN routes).

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.