Accumulated IGP Metric (AIGP) is an optional non-transitive BGP attribute used to carry an IGP metric with BGP route advertisements. The AIGP attribute is useful for tie-breaking in BGP bestpath selection so that routing decisions can be made on the basis of shortest path/lowest IGP cost path amongst multiple BGP paths. This is particularly applicable in scenarios where a single administration is subdivided into multiple Autonomous Systems (AS) each with similar routing policies and the same IGP in use such that the IGP metric for a route can be propagated usefully between the ASes so as to let receiving BGP speakers make routing decisions based on the cumulative IGP cost of the route. This set of ASes in a common administrative domain in the context of advertising and receiving the AIGP attribute are referred to as an AIGP administrative domain.

The cEOS-lab and vEOS-lab platforms use a different “forwarding plane” than EOS and CloudEOS; it is a software forwarding agent called Etba. A more efficient Etba provides more flexibility and better scalability for virtual network simulation for cEOS-lab and vEOS-lab users.

cEOS-lab vEOS-lab EOS 4.30.1F

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.

BGP session based dynamic route injection provides the capability to control route injection into IS-IS based on BGP session status since EOS 4.30.1F. When the BGP session is down, the BGP peers addresses will be un-injected from IS-IS.

EOS 4.30.1F

This feature adds support for gNMI access to the last-configuration-timestamp YANG node in the OpenConfig/Octa agent. When a gNMI set is completed, the last-configuration-timestamp is updated. When the configuration is changed via CLI or some other mechanism, the change eventually propagates to the OpenConfig/Octa agent, which will update the last-configuration-timestamp.

OpenConfig Octa GNMI EOS 4.30.1F YANG

The above figure depicts a typical wireless network deployment.  In the above deployment, the traffic from wireless networks are encapsulated into VXLAN tunnels by the AP (Access Point) VTEPs and terminated at the aggregation switches.  When a host on the wireless network transmits a DHCP request broadcast packet, the AP encapsulates it in a VXLAN tunnel and sends it to the aggregation switch. 

Support for DHCPv4 (RFC 2131)  and DHCPv6 Server (RFC 8415) was added to EOS-4.22.1 and EOS-4.23.0 respectively. EOS DHCP server leverages ISC Kea as backend. The router with DHCP Server enabled acts as a server that allocates and delivers network addresses with desired configuration parameters to its hosts.

In vEos/CloudEos deployed as a WAN router, when DPS (Dynamic Path Selection) is configured, all the user traffic coming from the LAN side and going to the WAN side gets load balanced on the DPS paths. This feature enables the automatic discovery of end to end Path MTU for a DPS Path through an internal probing mechanism. 

EOS 4.28.1F EOS 4.30.0F EOS 4.30.1F

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.

sFlow is a sampling technique which monitors incoming traffic on all interfaces without affecting network performance. Egress sFlow is a feature which samples the packets in the egress pipeline for analytical purposes. Currently egress sFlow is only software based on Arista switches.

Egress Sflow EOS 4.30.1F

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 feature allows configuring an IPv4 static route with IPv6 nexthop, both the interface and associated IPv6 address as nexthop router; the associated IPv6 address could be a linklocal address.

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. 

EVPN Multihoming defines a mechanism for Multihoming PEs to quickly signal, to remote PEs, a failure in an Ethernet Segment (ES) connectivity with the use of Ethernet A-D per ES route

EVPN Multihoming EOS 4.30.1F

Forwarding destination prediction enables visibility into how a packet is forwarded through the switch, allowing you to determine which interfaces a packet would egress out of. Typical use cases include, but are not limited to, determining egress members for Port-Channels and ECMPs.

The Segment security feature provides the convenience of applying policies on segments rather than interfaces or subnets. Hosts/networks are classified into segments based on prefixes. Grouping prefixes into segments allows for definition of policies that govern flow of traffic between segments.

Prior to release EOS 4.29.1, a statically configured BGP neighbor, listen range or interface peer could reference a single peer group for inheriting configuration parameters. EOS 4.29.1 adds the ability for that peer group to inherit configuration from up to 8 additional “ancestor” peer groups. The term “leaf peer group” is given to the peer group which is directly referenced by the BGP neighbor, listen range or interface peer.

BGP EOS 4.29.1F Peer Group EOS 4.30.1F

sFlow is a sampling technique which monitors the incoming traffic on all the interfaces without affecting the network performance.

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.

The internet exit feature enables hosts attached to a VRF in an edge router to reach prefixes that may be reachable over the internet. Since the addresses assigned within a VRF may be non-routable private addresses which cannot be directly used when going to the Internet, the NAT feature is used as a part of the Internet exit solution to provide internet connectivity.

EOS 4.30.1F Internet Exit

IP Locking is an EOS feature configured on an Ethernet Layer 2 port.  When enabled, it ensures that a port will only permit IP and ARP packets with IP source addresses that have been authorized. As of EOS-4.25.0F release update, IP Locking can run in two modes - IPv4 Locking (which will be referred to as IP Locking) and IPv6 Locking, which can be configured using the commands mentioned in the below sections. IP Locking prevents another host on a different interface from claiming ownership of an IP address through either IP or ARP spoofing.

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.

Ipv6 Decap Groups Prefix EOS 4.30.1F

IS-IS Counters feature adds support to monitor per interface count of received, transmitted and dropped IS-IS PDUs at the Rib/ISIS agent level. The counters start getting incremented once IS-IS is enabled on an interface and persist until IS-IS is disabled on it or the Rib/Isis agent restart.

EOS 4.20.5F EOS 4.30.1F

L2 protocol packets - LLDP, LACP and STP are trapped to the CPU by default. This feature allows for disabling the per protocol trap on a given set of interfaces. Starting from 4.32.1F, forwarding of MACsec EAPoL frames is also supported on a per interface basis on certain platforms.

This feature adds the capability to filter Lfib routes based on source protocol and prefix. Additionally, source protocol “isis” can be filtered further based on a flexible algorithm name or segment type that can either be a prefix segment or an adjacency segment.

EOS 4.30.1F

This TOI describes the MAC limit per VLAN feature which can be used to limit the number of locally learned MAC addresses per VLAN.

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.

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

This feature adds support to configure the following QoS OpenConfig models via gNMI  QoS Classifiers for classification of incoming traffic. QoS Scheduler Policies for describing scheduling strategies on a port.

QoS OpenConfig EOS 4.30.1F

In a symmetric network topology, for the same ECMP (Equal Cost Multi Path) route programmed at different devices in a switch layer, the various devices can program ECMP next hops in the FEC (Forwarding Equivalence Class) for that route in varying orders.

EOS 4.25.0F EOS 4.30.1F Ordered FEC

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.

This document describes a new CLI command to help debug how and why policy permits and denies paths. The aim of this CLI command is for the user to debug a route map or RCF (Routing Control Functions) function by specifying as input a prefix for which BGP has reachability for, either via a BGP peer or a redistribute source.

This article provides a general introduction to Precision Time Protocol (PTP) supported within EOS. PTP is aimed at distributing time with sub-microsecond accuracy. PTP support is based on the IEEE-1588 specification for version 2 of the protocol. 

Enabling “Proxy ARP/ND for Single Aggregation (AG) VTEP Campus Deployments without EVPN” allows an aggregation VTEP to proxy reply to a VXLAN-encapsulated ARP request/NS when the ARP/NS target host is remote and the ARP/ND binding is already learned by the AG VTEP.

PTP 1-step Boundary Clock (or 1-step BC) is similar to 2-step BC in function but doesn’t send the PTP Follow_Up message. The timestamp present in the PTP Follow_Up message’s preciseOriginTimestamp field is sent in the PTP Sync message’s originTimestamp field along with a non-zero correctionField. This allows us to support more PTP master ports because the control plane does not need to generate PTP Follow_Up messages anymore. PTP 1-step BC supports all the existing features supported by 2-step BC like G8275.1 profile, G8275.2 profile, etc unless otherwise specified in the limitations.

Python3 is available from EOS 4.22.0 onward.. In all 4.22+ releases, the runtime enables customers to install 3rd party extensions utilizing python3 that do not require the EOS components. Python3 provides built-in virtual environment support, so customers may easily install any required third party modules from Python Package Index (PyPI).

Python EOS 4.30.1F Python2 Python3

This feature enables Qos policy-maps to match on IPv4/IPv6 fields for L3VPN & 6PE services on the LER device core facing interface, assuming all labels are popped and packets are sent to the customer as IP.

VRF Route leaking can be used when routes from one VRF are required in another VRF (e.g. in case of shared services). If VrfLeak Agent is being used to leak routes, the leaked routes (in destination VRF) can be redistributed into IGPs.

This feature provides the capability to specify the label stack of the return path from the S-BFD reflector to the S-BFD initiator on the S-BFD initiator, which can be a different path from the shortest/best IGP path from the S-BFD reflector back to the S-BFD initiator, in order that the forwarding of the S-BFD packets would not be impacted by IP routing convergence, i.e., the stability of S-BFD session is not impacted by the IP routing convergence time. 

BFD EOS 4.30.1F

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.

The send support bundle feature adds a new CLI command which creates a ZIP file containing a useful set of logs and

Arista has built the link qualification functionality utilizing the SAT engine. There will be 2 sides of the link, the generator port and the reflector port. The generator port will be put in generator mode and the reflector port will be put into reflector mode and then the test will be started on the generator port. Traffic will be transmitted on the generator port and reflected back to the generator port at the reflector port.

EOS 4.30.1F

The service insertion framework is intended to cover the gamut of features related to service insertion.

EOS 4.30.1F Service Insertion

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.

Storm control allows users to configure a traffic level above which incoming broadcast, unknown-unicast and multicast traffic on a port gets dropped, thus preventing flooded traffic from bringing the switch down.

EOS 4.30.1F EOS 4.30.2F

This feature is designed to be used in an L3 centric network where servers communicate using IPv4/IPv6 packets over VXLAN. The IP packets are all expected to be routed in this network. Since L2 information is not relevant in routing, some customers may prefer to send their packets with random destination MAC addresses over VXLAN to minimize L2 overhead. 

EOS 4.30.1F

sFlow is a multi-vendor sampling feature that helps to monitor application level traffic flow. For ingress sFlow, sampling can be configured on a set of interfaces and port-channels where the application data is flowing inbound.

Sflow Ingress sFlow EOS 4.30.1F

Generic UDP Encapsulation (GUE) is a general method for encapsulating packets of arbitrary IP protocols within a UDP tunnel. While GUE supports an extensible header format with optional data, currently we only support the variant 1 header format, which directly encapsulates the IPv4/IPv6 payload without a GUE header. 

Gue EOS 4.30.1F

Private VLAN is a feature that segregates a regular VLAN broadcast domain while maintaining all ports in the same IP subnet. There are three types of VLAN within a private VLAN