EOS 4.33.1F TOI

EOS provides support for the use of IPsec to establish and maintain IPsec tunnels.  Currently EOS supports only route based IPsec tunnels - i.e traffic is routed through the tunnel only if there are routes in the FIB pointing to the IPsec tunnel as the next-hop.

This feature adds support for associating a WAN interface with multiple Dynamic Path Selection (DPS) path groups to allow paths originating from the same interface to have different priorities.

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.

DHCP Relay feature forwards DHCP packets between client and server when the DHCP Server is not in the same broadcast domain as the client. DHCP Relay should be configured on the gateway interface (SVI/ L3 interface ) for the clients.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, which is associated with a revision number to help the user identify changes to the event.

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.

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. 

Ethernet VPN (EVPN) networks normally require some measure of redundancy to reduce or eliminate the impact of outages and maintenance. RFC7432 describes four types of route to be exchanged through EVPN, with a built-in multihoming mechanism for redundancy. Prior to EOS 4.22.0F, MLAG was available as a redundancy option for EVPN with VXLAN, but not multihoming. EVPN multihoming is a multi-vendor standards-based redundancy solution that does not require a dedicated peer link and allows for more flexible configurations than MLAG, supporting peering on a per interface level rather than a per device level. It also supports a mass withdrawal mechanism to minimize traffic loss when a link goes down.

The FEC (Forward Error Correction) traffic analyzer is designed to estimate the performance of the FEC layer, identify error statistics, and the source of correlated errors on physical interfaces.

This feature provides a CLI to disable storm control policing on known multicast streams. By default, known multicast streams are policed by storm control policers and the behavior is consistent across all platforms supporting storm control feature. With the new CLI we can change the default policing behavior for known multicast streams.

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 introduces support for scaling both IPv4 and IPv6 hosts on our devices. Existing MDB profiles offer a maximum host scale of 128k with unique MAC rewrites. However, if hosts share the MAC rewrites, the scale can reach up to 204k. To address this issue, we are introducing a new MDB profile that will support a host scale of up to 192k when each host has a unique MAC rewrite. If hosts share the MAC rewrites, the scale can reach up to 256k.

With this feature, IPv4 and IPv6 packets matching a static nexthop-group route can be encapsulated within an IP-in-IP tunnel and forwarded

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.

Switches can now use two LAG partitions (A and B) to support double the number of available Port Channels dictated by the chosen LAG mode. This is useful if the selected LAG mode does not allow the creation of the desired number of Port Channels on a single partition.

Line system commands are used to apply configuration and query the status of line system modules in EOS. The supported line system modules are the OSFP-AMP-ZR and the QSFP-AMP-ZR.

Media Access Control Security (MACsec) is an industry standard encryption mechanism that protects all traffic flowing on the Ethernet links. MACsec is based on IEEE 802.1X and IEEE 802.1AE standards.

By default, the only visibility a user has into packets that are dropped due to errors with the MACsec/IPsec protocols is a set of counters, such as with show mac security counters detail. This feature enables redirecting such packets to the CPU for manual inspection; it is intended to assist with debugging unexpected packet drops.

Measured boot is an anti-tamper mechanism. It calculates the cryptographic signatures for software system components and extends the signatures into the Trusted Platform Module (TPM) security chip. Upon startup, with the feature turned on, the Aboot bootloader and EOS calculate the hash of various system components and extend the hashes into the Platform Configuration Registers (PCRs), which is one of the resources of the Trusted Platform Module (TPM) security chip. The calculation and extension event is called the measured boot event, and the event is associated with a revision number to help the user identify changes to the event.

This feature allows a user to configure a mirror session with subinterface sources from the CLI. This feature is only available with ingress mirroring (rx direction)

This feature allows users to configure L2 subinterfaces on MLAG interfaces. L2 subinterfaces are not supported on the MLAG peer-link.

This feature provides the ability to interconnect EVPN VXLAN domains. Domains may or may not be within the same data center network, and the decision to stretch/interconnect a subnet between domains is configurable. The following diagram shows a multi-domain deployment using symmetric IRB. Note that two domains are shown for simplicity, but this solution supports any number of domains.

OSPFv3 distribute-list is a policy construct to filter out routes received from OSPFv3 LSAs so that they will not be installed on the router even though the routes are resolved and are installable. The filtering is performed after SPF calculation and only on routes from received LSAs, not on self-originated LSAs. This feature does not affect the OSPFv3 protocol behavior of the router. LSAs are exchanged, e.g. flooded, even if the routes are not installed locally on the router.

This feature enables per port TC-To-COS mapping, where TC represents Traffic-Class and COS represents Vlan tag PCP bits. While at present there is a global TC-To-COS mapping, we can use the TC-To-COS feature to create custom profiles which can be applied to the required interfaces. 

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.

Subinterfaces are logical L3 interfaces that enable the division of a single Ethernet or Port-channel interface into multiple logical L3 interfaces based on the incoming 802.1q tag.  They are commonly used in the L2/L3 boundary.  They can also be used in the context of VRF-lite, by configuring each subinterface in a different VRF.

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

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

There are two types of reload on a switch running EOS, normal reload and Smart System Upgrade (SSU). Scheduled normal reload is supported via ‘reload in’ command, to perform a normal reload after a specified delay. It asks for saving unsaved configuration changes and confirmation in order to schedule the reload. Scheduled SSU is supported via ‘reload fast-boot in’ command. However, after scheduling an SSU reload, if there are unsaved configuration changes, or saved configuration changes which block an SSU reload, the scheduled reload will be aborted at scheduled time.

This feature introduces the support for Traffic Policy on VLANs. Traffic Policy allows the user to configure rules to match on certain packets through the packet processing pipeline. The user can also place actions to match packets.

This feature allows the export of IP FIB (Forwarding Information Base) through the OpenConfig AFT YANG models.

Topology Independent Fast Reroute, or TI-LFA, uses OSPF SR to build loop-free alternate paths along the post-convergence path. These loop-free alternates provide fast convergence.

EOS 4.15.0F added support for a CLI knob to determine whether the L3 forwarding agent (responsible for programming FECs and routes into hardware) would react to BFD status events for an interface to update next-hop programming for FECs programmed in hardware. This required two events, one for the BFD session to transition to an “Up” status and a subsequent transition to a “Down” status. This is identical to how various protocols in EOS (i.e. BGP, IS-IS) leverage BFD for faster down detection, and is useful to allow the L3 forwarding agent to preemptively remove next hops that would later be deprogrammed due to protocol session status state.