EOS 4.32.0F TOI

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

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.

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

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.

EOS is now based on AlmaLinux 9. The document outlines the EOS image base operating system (OS) transition from CentOS 7 to AlmaLinux 9. With CentOS 7 reaching its end of life (EOL) in June 2024 and the impending cessation of active support for CentOS Stream 8 in May 2024, It was decided to migrate directly to a RHEL 9 compatible base for EOS skipping RHEL 8/CentOS 8. EOS 4.32.0 is based on AlmaLinux 9 which is binary compatible with RHEL 9.  

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. EosSdkRpc is built using C++ but supports clients written in any of the languages currently supported by the gRPC framework.

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. To support such scenarios, Ingress Replication (IR) or Head-End Replication (HER) can be used in the underlay to distribute overlay multicast traffic.

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.

gRIBI (gRPC Routing Information Base Interface) defines an interface through which OpenConfig AFT (Abstract Forwarding Table) entries can be injected from an external client to a network element.

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.

This feature enables the user to configure a list or range of BGP attributes to be ignored by the router on receipt of a BGP update message. The BGP attributes are discarded from the BGP update message, and unless the action of discarding an attribute causes the update message to trigger error handling, then the update message is parsed as normal.

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.

The Interface Reflector feature allows performing certain actions (such as source/destination MAC address swap) on bridged packets that are reflected back from the interface. It is useful to test properties and SLAs before deploying the service for a customer.

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

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.

This feature adds a point to the Supported Scale section of this existing TOI. MAC scale up to 230,000 entries on DCS-7260CX3 series and 100,000 entries on DCS-7060DX5 series running in standalone mode.

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.

Mirror on drop is a network visibility feature which allows monitoring of MPLS or IP flow drops occurring in the ingress pipeline. When such a drop is detected, it is sent to the control plane where it is processed and then sent to configured collectors. Additionally, CLI show commands provide general and detailed statistics and status.

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.

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.

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.

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.

When the MLAG peer link goes down, the secondary peer assumes the primary peer is down/dead, and takes over the primary

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.

Multicast VRF leak allows multicast traffic from a sender in one domain or VRF to be forwarded to a different domain or VRF, in which the receivers are connected. In the rest of this document, the VRF to which the multicast sender belongs to is referred to as the “source VRF” and the VRF that the multicast receiver belongs to is referred to as the “receiver VRF”.

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

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.

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.

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:

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.

The postcard telemetry (GreenT - GRE Encapsulated Telemetry) feature is used to gather per flow telemetry information like path and per hop latency. For network monitoring and troubleshooting flow related issues, it is desirable to know the path, latency and congestion information for flows at different times.