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

Starting from 4.27.2F, IPFIX sampling introduced the capability to report BGP metadata for routes resolving over various tunnel types (ISIS-SR tunnels, NexthopGroups, etc).  For example BGP over ISIS-SR - BGP nexthop reported: 100.0.0.1

IPFIX EOS 4.30.2F EOS 4.31.0F

This feature allows the logging of packets matching deny rules in ingress ACLs applied on subinterfaces. This behavior can be enabled by using the log keyword when configuring an ACL deny rule. A copy of the packet matching those ACL rules is sent to the control plane, where a syslog entry of the packet header is being generated.

Logging ACL Subinterfaces EOS 4.30.2F

Agile ports allow users to connect 40G interfaces on 7130 products utilizing multiple SFP ports per 40G capable interface. This enables 40G capable applications, such as MetaConnect and MetaWatch, to operate at that speed.

L1 7130 EOS 4.30.2F Agile EOS 4.31.0F

Arista’s WAN routing solution comes with a suite of features. The network can spread across multiple geographical locations and make use of multiple types of service providers. One particular routing feature of this WAN network is called Adaptive virtual topology ( AVT ). Using AVT, the network operator can segment the physical topology into various virtual topologies based on certain constraints such as latency,  jitter or packet loss.

EOS 4.30.2F

This is achieved by using the next-hop of the static route as the peer IP address for the BFD session. The static route is either installed or removed based on the status of the underlying BFD session. A static route whose next-hop is configured to be tracked by BFD is referred to as a ‘BFD tracked static route’ in the context of this document. This feature is supported for both IPv4 and IPv6 static routes.

BFD VXLAN Static Route EOS 4.30.2F

This feature enables Flowspec rules to be leaked from one VRF to another. When combined with the ability to apply Flowspec rules from one VRF to interfaces in another VRF, this feature makes it possible to combine rules from different source VRFs into a target VRF, and apply the target VRF’s rules on the interfaces of the source VRFs. For example, in the diagram below, interface Ethernet1 is in VRF Red, Ethernet2 and 3 are in VRF Orange. Suppose Flowspec rules are received from BGP peers on interfaces Ethernet1, 2, and 3. Without this feature, the rules in VRF Red can only be applied on interface Ethernet1, and the rules in VRF Orange can only be applied on interfaces Ethernet2 and 3. Using this feature, the received rules can be leaked from VRFs Red and Orange to VRF Purple, and the leaked rules can be applied on interfaces Ethernet1, 2, and 3.

BGP VRF VRF Leaking Flowspec EOS 4.30.2F

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.

Class Based Forwarding (CBF) is a way of steering IP traffic into specific tunnels based on the ingress DSCP values.CBF is implemented in the hardware using an override model.

EOS 4.30.2F

CLI extension allows for custom CLIs commands/modes to be defined in EOS. It also integrates with EOS SDK to be able to control a daemon’s configuration and read a daemon’s status from the CLI command handlers. This feature is intended to have more customization compared to the “daemon cli” feature, which only allows for key/value pairs as cli commands, and doesn’t allow for custom CLI commands. It does this by using a statically defined YAML file that contains the daemon definition (EOS SDK or not), CLI mode, and CLI commands, very much akin to what is provided by the via configuration in the daemon cli mode.

Software Forwarding Engine (SFE) is a DPDK-based packet processing software and forwarding agent, which is being used in the CloudEOS and AWE 5000 series platforms. The SFE forwarding agent supports IPFIX hardware flow tracking.

EOS 4.30.2F

Coherent transceivers, compliant with Coherent Common Management Interface Specification (C-CMIS) maintain two sets of thresholds to detect and report two types of link degradation: FEC excessive degrade (FED) and FEC detected degrade (FDD).

CMIS EOS 4.30.2F

BGP VPN routes today advertise a label by dynamically allocating it from a dynamic label range block without providing the user any control over the label value that is allocated per VRF’s address Family - VPNv4 or VPNv6. This feature allows the user to configure a unique label per VRF’s configured address-family, VPNv4 or VPNv6, thereby allowing the user granular control over the label value advertised with VPN routes exported from a VRF.

Routing BGP MPLS VPN EOS 4.30.2F

Arista’s DCS-7130B series of switches are network devices designed for ultra low-latency applications along with a suite of networking features.

L1 SKU 7130 EOS 4.30.2F

By default, the DSCP and ECN bits of VXLAN bridged packets are not rewritten. Currently, for bridged packets undergoing VXLAN encapsulation, the DSCP in the outer IP header is derived from TC and the ECN bits are set to zero. The desired behavior is that the outer IP header should be remarked with ingress packet DSCP and ingress packet ECN. Also, local congestion should be handled correctly.

QoS VXLAN DSCP ECN EOS 4.30.2F

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.

NDR switch sensor aka “monitor security awake” feature provides deep network analysis by doing deep packet inspection of some or all packets of traffic that's forwarded by the switch.

This document describes the on_nexthop_group_programmed event within the context of both the EOS SDK and the EOS SDK RPC agent. This event is triggered when there is an update to the state of a watched nexthop group.   These state updates include both the hardware programming of the group itself, as well as the hardware status of any counters associated with the group.

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.

This feature allows exporting IP-in-IP tunnel counters through the OpenConfig AFT YANG models.This exporting IP-in-IP counters feature is supported on all platforms, however counting the IP-in-IP tunnel packets is supported only on DCS-7500R3, DCS-7280R3 and DCS-7800R3 series. 

In EVPN VXLAN context, binding a VRF to a VNI usually consumes a dynamic VLAN as shown in the following sample CLI configuration. The usable range of dynamic VLANs is from 1 to 4094, which is also shared by other features such as internal VLANs. The document describes the extended VLAN support for EVPN VXLAN, which increases the number of usable dynamic VLANs. The extended VLAN range is from 4101 to 8191.

EOS 4.30.2F EVPN VXLAN

EOS supports the ability to match on a single VLAN tag (example: encapsulation dot1q vlan 10)  or a VLAN tag pair (example: encapsulation dot1q vlan 10 inner 20) to map matching packets to an interface. In this case, the encapsulation string is considered consumed by the mapped interface before forwarding, which means that the tags are effectively removed from the incoming packet for the purposes of any downstream forwarding.

This feature is used to send gratuitous ARPs and NDs to update the mac address in neighbors’ mac address table when the users configure to change the mac address in the routed interface.

This feature introduces the hardware forwarding support for IPv4 over IPv4, GRE-Tunnel interfaces on Arista Switches. A GRE-Tunnel interface acts as a logical interface which performs the GRE encapsulation or decapsulation.

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.

 

Current behavior for IPv4 Options packets is to let Kernel do the forwarding. Strata Platforms do this by setting the action of drop=1 and CPU=1 in the IP_OPTION_CONTROL_PROFILE_TABLE Hardware table so that all IPv4 options packets reach the CPU for forwarding in the Kernel.

EOS 4.30.2F IPv4 Options

IPSec tunnel mode support allows the customer to encrypt traffic transiting between two tunnel endpoints.

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

IS-IS flexible algorithm (FlexAlgo) provides a lightweight, simplified mechanism for performing basic traffic engineering functions within a single IS-IS area. FlexAlgo requires the cooperation of all nodes within the IS-IS area but does not require an external controller. Paths are computed by each node within the area, resulting in an MPLS switched forwarding path to nodes that are advertising a node Segment Identifier (SID) for the algorithm. The results of the path computation are placed in the colored tunnel RIB or system tunnel RIB, which simplifies route resolution.

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.

Configuring loopback is a vital tool in troubleshooting physical layer issues in computer networks. It enables the creation of a closed environment for self-verification and testing. It is essential for isolating problems related to cabling, hardware, and network interfaces. Loopback tests confirm the integrity of physical interconnections by sending traffic back to the source device. [This traffic can be injected, or a generated test pattern]. This can help to locate the source of issues in the physical layer.

EOS 4.30.2F

MetaMux is an FPGA-based feature available on Arista’s 7130 platforms. It performs ultra-low latency Ethernet packet multiplexing with or without packet contention queuing. The port to port latency is a function of the selected MetaMux profile, front panel ingress port, front panel egress port, FPGA connector ingress port, and platform being used.

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.

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

EOS 4.29.1F EOS 4.29.2F EOS 4.30.2F

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.

Mirroring VXLAN EOS 4.30.2F

In networks where source and destination of multicast traffic all reside in the same VLAN, IPv6 multicast traffic is flooded to all ports in the VLAN by default. MLD snooping can be enabled to optimize the inefficient transmission, pruning out ports with no receivers.

Multicast Ipv6 EOS 4.30.2F MLD RFC3810

This solution optimizes the delivery of multicast to a VLAN over an Ethernet VPN (EVPN) network. Without this solution IPv6 multicast traffic in a VLAN is flooded to all Provider Edge(PE) devices which contain the VLAN.

This feature adds the support for OSPF multi-site domains described in RFC 4577(OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) ) and enables routes BGP VPN routes to retain their original route type if they are in the same OSPF domain. Two sites are considered to be in the same OSPF domain if it is intended that routes from one site to the other be considered intra-network routes.

OSPF EOS 4.30.2F RFC4577

This solution allows delivery of multicast traffic in an IP VRF using multicast in the underlay network. It builds on

Multicast EVPN VXLAN 4.25.1 EOS 4.30.2F

The Arista OSFP-400G-SRBD and QDD-400G-SRBD modules (Sometimes referred to as “400G-BIDI” or “400G-SR4.2”) may be used with other 400G-BIDI / 400G-SR4.2 modules, or connected to four 100G-BiDi modules indicated below.

Configuring OSPF as PE-CE protocol enables us to distinguish between the “real external routes” and intra network routes between the sites that are stretched across VPN.  But the problem arises when VPN sites are in the same area and have a backdoor connection. With OSPF as PE-CE protocol redistribution, CE routers end up getting inter-area routes(assuming the VRFs on the PE devices that connect the CE sites, are configured with the same OSPF domain id) that actually belong to the same area and just happen to be multihomed to the backbone. 

OSPF EOS 4.30.2F PE-CE RFC 4577

This document describes the PFC (priority-based flow control) history counters that are available to debug network oversubscription issues. These counters track statistics on the switch that is sending network traffic at a rate that is more than what its peer can handle.

In a modular system there are two supervisors which ensures redundancy in event of Hardware and software failures. At any given time, only one supervisor is in control (managing most hardware, including all the linecards). We call it the active supervisor. The other supervisor is called standby supervisor, which serves as a backup in case the active supervisor fails. Stateful switchover is the transition when the standby supervisor takes over control of the entire system from the active supervisor (and therefore becomes the new active). This document describes PIM SSO works and its limitations.

PIM EOS 4.30.2F PIM NSF PIM SSO PIM SSU

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.

TStarting from EOS-4.17.0F, the capability of advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions, as described in the Extended Next Hop Encoding capability in RFC5549, is supported. This document describes the feature that allows the redistribution of such routes into OSPF.

OSPF Redistribute EOS 4.30.2F

PIM Reverse Path Forwarding (RPF) is a mechanism that allows the multicast routers to send the PIM control packets to the upstream routers via the shortest path to form the RP/Source Tree.

PIM Tunnel EOS 4.30.2F Rpf

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.

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.