A typical multicast receiver expresses interest in a multicast stream by sending IGMP messages, the last hop router would then convert this IGMP to a PIM message and propagate upstream. As part of this feature when an IGMP message or PIM message is received in a VRF and there is a corresponding VRF leak configuration, the IGMP / PIM state is then leaked into the source VRF and processed only in the source VRF.

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network.

BFD Stateful Switchover (SSO) allows for a switchover from an active supervisor to a standby supervisor where BFD

TOI BFD EOS 4.18.2F SSO EOS 4.32.0F

EOS 4.21.3F introduces support for BGP Flowspec, as defined in RFC5575 and RFC7674. The typical use case is to filter or redirect DDoS traffic on edge routers.

The BGP-LS extension allows IGPs (OSPF/IS-IS) link state database information to be injected into BGP. This is typically used in deployments where some external component, (like a controller or Path Computation Engine) can do centralized path computations by learning the entire IGP topology through BGP-LS. The controller can then communicate the computed paths based on the BGP-LS updates to the head end device in the network. The mechanism used by the controller to communicate the computed TE paths is outside the scope of this document. Using BGP-LS instead of an IGP peering with the controller to distribute IGP link state information has the following advantages.

Bidirectional Protocol Independent Multicast (PIM) allows routers to build trees to deliver multicast traffic from sources to receivers. It is a variant of sparse-mode PIM that efficiently addresses the use case where receivers for a multicast group are also sources for that group.

PIM EOS 4.32.0F

Connectivity Monitor is an EOS feature that allows users to monitor their network resources from their Arista switches. The resources being monitored may or may not be Arista devices. Connectivity monitoring is unidirectional in nature.

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.

This TOI describes a feature allowing packets that do not match any VLAN translations to be dropped from a port. This can be useful to drop selective Q-in-Q packets that do not receive a VLAN. The Configuration section details CLI commands used to configure the feature.

Link Flap Damping is a feature designed to detect situations when an interface is continuously flapping. If enough flaps are done, the damping mechanism is triggered temporarily holding the interface link-down. This smoothes out link flap occurrences and reduces churn in the network caused by link flaps.

Link Flap EOS 4.32.0F Damping Damp

ECMP Hash visibility CLI determines the output interface for an ECMP set based on the flow parameters supplied by the user. Ingress interface, source IP address, destination IP address and IP protocol are the required parameters.

ECMP Hash visibility CLI determines the output interface for an ECMP set based on the flow parameters supplied by the user. Ingress interface, source IP address, destination IP address and IP protocol are the required parameters. L4 source and destination ports and VLAN identifier are optional, but should be specified if the packet has them.

EosSdkRpc is an agent built on top of the Arista EOS SDK. It uses gRPC as a mechanism to provide remote access to the EOS SDK. The gRPC interface that EosSdkRpc supports closely matches the interface provided by EOS SDK, and the intent is that the .proto interface can be publicly supported. EosSdkRpc allows for remote access and using protobuf to specify the interface isolates user code from the Linux ABI issues that come with building C++ applications on different compiler, libc, and kernel versions.

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. This mode of operation makes the task of Operations, Administration and Maintenance (OAM) of such networks to be far more challenging, and the ability of service providers to respond to such network faults swiftly directly impacts their competitiveness.

This new feature explains the use of the BGP Domain PATH (D-PATH) attribute that can be used to identify the EVPN domain(s) through which the EVPN MAC-IP routes have passed. EOS DCI Gateway provides new mechanisms for users to specify the EVPN Domain Identifier for its local and remote domains.   DCI Gateways sharing the same redundancy group should share the same local domain identifier and same remote domain identifier.


EOS currently supports EVPN Multicast by setting up PIM tunnels in the underlay with VXLAN as the transport. While this is an efficient delivery mechanism, it requires PIM to be deployed in the underlay. In certain cases, the overheads of provisioning/maintaining the multicast routers and the multicast routing state in the underlay may be significant.

EVPN gateway support for all-active (A-A) multihoming adds a new redundancy model to our multi-domain EVPN solution introduced in [1]. This deployment model introduces the concept of a WAN Interconnect Ethernet Segment identifier (WAN I-ESI). The WAN I-ESI allows the gateway’s EVPN neighbors to form L2 and L3 overlay ECMP on routes re-exported by the gateways. The identifier is shared by gateway nodes within the same domain (site) and set in MAC-IP routes that cross domain boundaries.

Filtered mirroring allows certain packets to be selected for mirroring, rather than all packets ingressing or egressing a mirror source port.

A forwarding equivalence class (FEC) entry is the data structure that holds all reachable vias where the packets should be sent to, for certain routes. Before this feature, a FEC could not contain both IPv4 next hop vias and IPv6 next hop vias. This feature starts supporting FECs that have both IPv4 next hop vias and IPv6 next hop vias. In an Equal Cost Multi-Path (ECMP) FEC, some of the vias may have IPv4 next hop and others may have IPv6 next hop. 


Generic UDP Encapsulation (GUE) is a general method for encapsulating packets of arbitrary IP protocols within a UDP tunnel. GUE provides an extensible header format with optional data. In this release, decap capability of GUE packets of variant 1 header format has been added. This variant allows direct encapsulation using the UDP header without the GUE header. The inner payload could be one of IPv4, IPv6, or MPLS.

This document describes the introduction and use of the global knob which facilitates the txQueue percentage-based allocations based on the available bandwidth of the parent interface.

Shaping EOS 4.32.0F txQueue

This feature adds support for offloading BFD Transmit path to hardware (ASIC) for specific types of BFD sessions. This will improve accuracy of transmit timer implementations for BFD (especially with fast timers like 50 ms) and relieve pressure on the main CPU in scenarios of scale.

Support for ingress Port ACLs on GUE Packets. The matching of ACLs can be done on  outer IP header as well as UDP header fields for gue routed/bridged, decap/transit packets, and the ACL can be applied to Front Panel Ports.

ACL Gue EOS 4.32.0F Ingress ACL

Segment Routing provides mechanism to define end-to-end paths within a topology by encoding paths as sequences of sub-paths or instructions. These sub-paths or instructions are referred to as “segments”. IS-IS Segment Routing (henceforth referred to as IS-IS SR) provides means to advertise such segments through IS-IS protocol.

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.

Arista’s 7135 Connect Series of Layer 1+ switches are powerful network devices that allow for dynamic connections between various layer 1 components on the system, such as the front panel and FPGA. These connections are driven by an underlying CLOS network of crossbar switches. The following commands provide the ability to configure middle stage crossbar switches within the system to create dynamic layer 1 connections.

L1 Source EOS 4.32.0F 7135

On supported devices, a port-channel can be configured as a mirroring destination for both ingress and egress source directions. Traffic mirrored to a port-channel is load-balanced based on the global port-channel load-balance configuration, which is the same for other port-channels.

Mirroring Port Channel LAG EOS 4.32.0F

An interface may be a source for both a mirroring session and sFlow at the same time. For more information about mirroring and ingress and egress sFlow look in the Resources section below.

Mirroring Sflow EOS 4.32.0F

Arista switches provide several mirroring features. Filtered mirroring to CPU adds a special destination to the mirroring features that allows the mirrored traffic to be sent to the switch supervisor. The traffic can then be monitored and analyzed locally without the need of a remote port analyzer. Use case of this feature is for debugging and troubleshooting purposes.

Time stamping is an important tool for network engineering and performance analysis. EOS-4.21.3F adds support for payload timestamping of all GRE encapsulated mirrored packets at line rate (initially only supported on the 7500R/7280R/7500R2/7280R2 series). A timestamp is taken on ingress and inserted into the GRE encapsulated mirrored packet payload at egress.

EOS 4.21.3F EOS 4.30.1F EOS 4.32.0F

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

This feature adds support for allowing multiple destinations in a single monitor session.

For traffic mirroring, Arista switches support several types of mirroring destinations. This document describes a new type of mirroring destination in which mirrored traffic is tunneled over VXLAN as the inner packet to a remote VTEP. This feature is useful for when the traffic analyzer is a VTEP reachable over a VXLAN tunnel.

Mirrored packets may be configured to be truncated per mirroring session.

Mirroring Truncation EOS 4.32.0F

IP traceroute and path MTU (PMTU) discovery both require that routers send ICMP reply messages to the host that invokes each network function. When the route to the destination host traverses an MPLS label-switched path (LSP), the label switching routers (LSRs) will also need to send ICMP reply messages to the originating host.

EOS supported two routing protocol implementations: multi-agent and ribd. The ribd routing protocol model is removed starting from the EOS-4.32.0F release. Multi-agent will be the only routing protocol model. Both models largely work the same way though there are subtle differences.

Routing BGP RIB EOS 4.32.0F ribd iprib Gated

This feature adds all-active (A-A) multihoming support on the multi-domain EVPN VXLAN-MPLS gateway. It allows L2 and L3 ECMP to form between the multihoming gateways on the TOR devices inside the site and on the gateways in the remote sites. Therefore, traffic can be load-balanced to the multi-homing gateway and redundancy and fast convergence can be achieved.


EOS supports reading and streaming various OpenConfig configuration and state models over gNMI (gRPC Network Management Interface), RESTCONF, and NETCONF transports. A subset of the configuration models may also be modified over these transports

EOS 4.32.0F

By default, the scheduling between parent interfaces and the attached shaped subinterfaces is done in strict priority mode where the parent interface has the highest priority. Subinterfaces that are not shaped use the same queues as the parent so the traffic on these subinterfaces will also have strict priority over shaped subinterfaces.

Subinterfaces EOS 4.32.0F

PIM Static Source Discovery (SSD) is a feature implemented as part of PIM-SM. Familiarity with setting up and configuring PIM-SM (Sparse Mode) and PIM-SSM (Source-Specific Multicast) is assumed.

PIM TOI EOS 4.20.1F EOS 4.32.0F PIM-SM

This feature provides a continuous, live, stream of ingress counters for Policy-Based Routing (PBR) rules in terms of bytes and packets. It is implemented as a special call in EosSdkRpc and follows this definition:

Counters PBR EosSdkRpc RPC EOS 4.32.0F

Port mirroring is used to send a copy of packets seen on one port to a network monitoring connection on another switch port. Port mirroring is commonly used with network probes or other monitoring devices; examples include intrusion detection devices, latency analyzers, or packet capture and protocol analysis tools.

Mirroring EOS 4.32.0F

The goal of route prioritization is to improve overall network behavior by ensuring that routes classified as having a higher priority are processed and installed in a timely fashion. Activity for lower priority routes must not significantly delay high priority route processing. For example, when a network event affects a large number of BGP routes causing them to be reprogrammed, the programming of an important IGP route that provides underlay connectivity and is affected by a subsequent event should not have to be queued behind the BGP routes. Prioritizing the IGP route programming will improve network convergence. It may also eliminate duplicate work for other routes depending on it.

EOS 4.32.0F Route Prioritization

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 article describes the support for Filtered Mirroring using security ACL. The user can selectively mirror packets based on the statement in the configured IPv4, IPv6 or MAC ACL.

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.

The sFlow VPLS extension adds support for providing VPLS-related information to sFlow packet samples, for VPLS forwarded traffic. Specifically, for customer traffic ingressing on a CE-facing PE interface in a VPLS deployment that uses statically configured LDP pseudowires, information such as the name of the VPLS instance and the ID of the pseudowire that the packet will egress over will be included in the sFlow datagram. 

Sflow VPLS EOS 4.32.0F

This is an infrastructure that provides management of SSL certificates, keys and profiles. SSL/TLS is an application-layer protocol that provides secure transport between client and server through a combination of authentication, encryption and data integrity. SSL/TLS uses certificates and private-public key pairs to provide this security.

This feature adds support for CPU traffic policy capable of matching and acting on IP traffic which would otherwise

This feature adds support for “Dynamic Load Balancing (DLB)” on Equal Cost Multi Path (ECMP) groups.
It is intended to help overcome the potential shortcomings of traditional hash-based load balancing by considering the traffic load of members of ECMP groups. DLB considers the state of the port while assigning egress ports to packets, resulting in a more even flow. The state of each port member is determined by measuring the amount of data transmitted from a given port and total number of packets enqueued to a given port.