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

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.

Arista switches mentioned in below platform compatibility section have two chip profiles. ADNA is the default chip profile in which the system boots up starting from 4.31.2F release.

Multiple dynamic counter features may be enabled simultaneously, primarily configured using the [no] hardware counter feature [feature] CLI commands. Compatibility of these features has been enhanced to allow for greater flexibility in simultaneously enabled counter features. Changes in counter feature compatibility across EOS releases is detailed below.

EOS SDK and its RPC counterpart traditionally offer two separate calls for configuring static routes. These calls are ip_route_set/ip_route_via_set and mpls_route_set/mpls_route_via_set. When calling the SDK API directly the calling latency is negligible, since it is a simple function call. However, the time of each of those calls can become a considerable factor with the adoption of RPC. To reduce the overall latency associated with creating and updating numerous routes, EOS SDK RPC now supports bulk calls.

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.

The EOS implementation of OSPF uses an alternate Area Border Router (ABR) behavior as specified in the IETF draft document. This is implemented as an optimization over the standard OSPF so that the packets would not be dropped when a router loses Active backbone connection which could otherwise be successfully forwarded.

Several customers have expressed interest in using IPv6 addresses for VXLAN underlay in their Data Centers (DC). Prior to 4.24.1F, EOS only supported IPv4 addresses for VXLAN underlay, i.e., VTEPs were reachable via IPv4 addresses only.

Introduced in EOS-4.20.1F, “selectable hashing fields” feature controls whether a certain header’s field is used in the hash calculation for LAG and ECMP.

Loop protection is a loop detection and prevention method which is independent of Spanning Tree Protocol (STP) and is not disabled when the switch is in switchport backup mode or port is in discarding state. The LoopProtect agent has a method to detect loops and take action based on the configuration by the user. In order to find loops in the system, a loop detection frame is sent out periodically on each interface that loop protection is enabled on. The frame carries broadcast destination MAC address, bridge MAC source address, OUI Extended EtherType 0x88b7 as well as information to specify the origins of the packet.

The macsec scheduler compensation feature is used to automatically make adjustments to the packet size seen by the scheduler for macsec encrypted traffic, based on mac security configuration. This feature is useful when macsec is configured on an interface. When a packet egresses out of the macsec enabled interface, the packet gets encrypted by adding additional macsec headers.

The main motivation for the feature is to provide high availability to the ManagementActive interface (Management0) via multiple redundant paths in the modular system. The ManagementActive interface(Management0) is a virtual interface pointing to the active supervisor.

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.

This feature serves as a valuable tool for pinpointing the nature of network traffic at a device under congestion. By mirroring packets from congested queues to a designated mirror destination or CPU for analysis and monitoring, it provides network administrators and operators with the capability to gain an understanding of the traffic contributing to the congestion.

This feature adds configuration support for the OSPFv2 OpenConfig model via gNMI. Currently, only a limited set of config paths are supported and no state paths are supported. Supported paths can be found at OpenConfig Path Support

If two or more streams of packets are subjected to the same policer, the policing may not be fair, that is, the policer might exhibit bias towards one of the streams. Fair policing across all the streams is not guaranteed. Policer fairness provides a way to reduce this bias and maintain fair distribution of policer bandwidth among the input streams proportional to the ingress rate.

This TOI describes a set of enhancements made to the existing Port Security: Protect Mode (PortSec-Protect) feature. Please see the existing TOI for this feature here:Port Security: Protect Mode

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.

RADIUS proxy feature enables proxying RADIUS requests from a RADIUS client and forwarding it to a remote RADIUS server. Similarly, RADIUS proxy receives the reply from remote RADIUS server and forwards it to the client.

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.

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.

Smart System Upgrade (SSU) provides the ability to upgrade the EOS image with minimal traffic disruption. This is an existing feature on many fixed system products. This resource will outline the SSU feature in reference to CCS-720DP, CCS-722XPM, CCS-720XP-96ZC2 and DCS-7010TX.

This TOI describes details and limitations of Stateful Switchover on Modular chassis with 7500R3, 7800R3, 7800R3A based line cards.

NAT has been supported in DCS-7150 for many years. Starting at EOS 4.21.6F, NAT functionality is supported on certain 7050X3 platforms.

The CCS-750X-48ZXP is a 48 port 10GBASE-T linecard, capable of several full-duplex link speeds to support connecting to a variety of compatible devices of varying capabilities. All supported linkup speeds on this card can be automatically selected during the linkup process using IEEE 802.3 Clause 28 auto-negotiation. Note that IEEE 802.3 also allows for speeds lower than 1Gbps to link up without clause 28 auto-negotiation.

In EOS-4.31.2F ipv6 link-local next-hops can now be configured in BGP through RCF (Routing Control Functions). On the advertising BGP agent an ipv6 link-local next-hop is configured on the outbound policy function. The receiving BGP agent reads this link-local next-hop and automatically assigns the interface from which the BGP path was sent.

Dot1q (802.1Q) is a tunneling protocol that encapsulates traffic from multiple customer (c-tag) VLANs in an additional single outer service provider (s-tag) VLAN for transit across a larger network structure that includes traffic from all customers. Tunneling eliminates the service provider requirement that every VLAN be configured from multiple customers, avoiding overlapping address space issues.

This feature allows exporting the route count by protocol, i.e., a summary of routes, in the FIB (Forwarding Information Base) through the OpenConfig AFT YANG model.

BGP Monitoring Protocol (BMP) allows a monitoring station to connect to a router and collect all of the BGP announcements received from the router’s BGP peers. The announcements are sent to the station in the form of BMP Route Monitoring messages generated from path information in the router’s BGP internal tables. A BMP speaker may choose to send either Adj-Rib-In routes, or Loc-Rib routes (as defined by RFC9069), or both.

The feature adds support for redirecting traffic matching on traffic policy rules applied to an egress interface to a specified next-hop or next-hop group. This feature requires the packet to be recirculated a second time through the packet forwarding pipeline to get its configured single or multiple next-hops to be resolved. This is achieved by configuring traffic-policy with redirect interface action applied on egress interface in conjunction with ingress redirect next-hop action applied on the recirculation interface. Redirect interface action is used to forward the egressing packet through an interface on which traffic loop-back ( a.k.a recirculation ) is enabled.

This feature adds support for a selected set of configured interfaces to collect egress flow samples. Egress sFlow can be configured on ethernet and port-channel interfaces.

This TOI supplements the Ingress Traffic Policy applied on ingress interfaces. Please refer to that document for a description of Traffic Policies and field-sets. This TOI explains the Traffic Policies as applied in the egress direction on interfaces

Access Control Lists (ACL) use packet classification to mark certain packets going through the packet processor pipeline and then take configured action against them. Rules are defined based on various fields of packets and usually TCAM is used to match packets to rules. For example, there can be a rule to match the packet source IP address against a list of IP addresses, and drop the packet if there is a match. This will be expressed in TCAM with multiple entries matching the list of IP addresses. Number of entries is reduced by masking off bits, if possible. TCAM is a limited resource, so with classifiers having a large number of rules and a big field list, TCAM runs out of resources.

EOS generates a single system-defined colored tunnel RIB for colored next hop resolution. When colored tunnels to the same destination address are learned from multiple protocols, a fixed preference that is associated with each protocol is used to determine the winning tunnel. This feature provides the ability to override the preference for all colored tunnels from a protocol in order to achieve non-default ordering of tunnels.

The Unified Forwarding Table (UFT) is memory that is shared between Layer2 and Layer3 lookup tables with capabilities for variable partitions. Rather than separate Layer2 and Layer3 lookup tables of fixed size, the UFT may be partitioned to support user-requested combinations of Layer2 and Layer3 lookup table sizes. The new UFT partitioning CLI has capabilities to reconfigure individual forwarding table scales (Layer2, Layer3 Unicast, Layer3 Multicast) according to the user’s input. The CLI provides an interface for granular control of the underlying UFT resources.

This feature allows selecting Differentiated Services Code Point (DSCP) and Traffic Class (TC) values for packets at VTEPs along VXLAN encapsulation and decapsulation directions respectively. DSCP is a field in IP Header and TC is a tag associated with a packet within the switch, both influence the Quality of Service the packet receives. This feature can be enabled via configuration as explained later in this document.