Tag :: EOS 4.35.0F

This document provides information on how to configure static NAT with selective VXLAN encapsulation using policy-based routing (PBR) and debug related issues on Arista 7170 switches.

Newly supported Features, Ingress IPv4/IPv6 and MAC ACL on FPP ( routed/switched ), Port-Channel, L3 subInterfaces ,Ingress IPv4/IPv6 and MAC ACL counters , Ingress IPv4/IPv6 and MAC ACL deny logging

802.1X is an IEEE standard protocol that prevents unauthorized devices from gaining access to the network. We support dot1x protocol standard 802.1X-2004 (version=2)

802.1X supplicant feature supports different Extensible Authentication Protocol( EAP ) methods for 802.1X authentication. This document specifically talks about support for supplicants doing EAP Password ( EAP-PWD ) based authentication. Defined in RFC5931, EAP-PWD is an EAP method that uses a shared password for authentication. Furthermore, this feature allows EOS devices to interoperate with systems that rely on EAP-PWD for deriving MACsec CAK/CKN from the EAP Master Session Key (MSK) and EAP Session ID as per 802.1X-2020.

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. 

Data center switches and servers have traditionally been managed by separate teams using different tools creating complexity in setting up and maintaining the end to end network in the datacenter.

This document describes how to integrate with Arista Media Control Service(MCS) supported APIs and the EOS releases that they are available in

This document lists and describes the MCS supported features and the EOS releases that they are available in.

This document describes how to provision, upgrade and troubleshoot Arista’s Media Control Service (both servers and clients). The Media Control Service provides a deterministic high-performance service with an easy to use API interface to manage and monitor real-time broadcast workflows in IP networks. It allows fast programming of static multicast routes and IGMP snooping entries across L2/L3 interfaces with real-time tallies for feedback.

This feature adds support for BGP UCMP in the multi agent routing protocol model. The TOI for BGP UCMP in the ribd

Arista’s CCS-710XP series of ethernet switches consist of CCS-710XP-12TH-2S SKU. CCS-710XP-12TH-2S is a 12 port 1000BASE-T PoE & 2-port SFP+ fanless switch device rich with networking features suited for campus deployments.

This document describes the configuration and behavior of physical interfaces on the CCS-710XP series switch

This feature implements the ability to configure any tx serdes parameters via the CLI. This is useful to work around any L1 issues that customers may encounter due to suboptimal networks/links/transceivers.

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.

Cluster Load Balancing is a feature designed to ensure optimal load balancing of flows used as part of GPU based cluster communication. When this feature is enabled, a TOR router monitors RoCE traffic flowing between the GPU servers and spine uplinks and ensures optimal load balancing in the network.

EOS supports the DHCP Relay feature, which relays DHCP Requests/Responses between DHCP clients and DHCP servers in different subnets. However, the DHCP server does not have visibility of where the request originated from and can only make IP address allocation decisions based on the client MAC address alone (client MAC address is included in the DHCP packet as part of the payload). To remedy that, DHCP Option-82 was formalized to allow relay agents to include Remote ID and Circuit ID so that DHCP servers can apply a more intelligent allocation policy.

This feature supports counting ECN-marked packets (ECN = Explicit Congestion Notification) on a per egress port per tx-queue basis. The feature can be used to gather these packet counts via CLI or SNMP.

Explicit Congestion Notification (ECN) is an extension to the Internet Protocol and to the Transmission Control Protocol which allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints support it and are willing to use it. ECN operates over an active queue management algorithm.

Egress Priority Tagging is a feature that allows a switch to send out priority tagged ethernet frames in place of untagged frames. Priority tagged frames are sent with the VLAN ID set to zero allowing downstream devices to read the 802.1p priority bits set in the VLAN header.

Egress traffic-policing can be applied on L3 Ethernet subinterfaces for outbound traffic.

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.

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.

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.

This feature adds support for the front panel Ethernet (Et) interface counters on the platforms listed below and enables the Et interfaces to dynamically adopt the counter values (packet and error)1 of interfaces (Switch, App interfaces etc.) related to the currently running FPGA application, based on user or default configuration. All Arista FPGA applications are supported. Both the receive and transmit packet counters can be independently configured for each interface, as desired. Counters are supported for interfaces of any speed including agile ports.

This is an implementation of the gNOI Healthz RPCs (version 1.3.0). Note that RPC elements of the Healthz service are supported, and as of 4.33.1F, only the agent information is exposed in healthz yang component containers outlined as in the healthz service.

gNPSI is an OpenConfig protocol designed to act as a proxy between the sFlow agent and interested gRPC clients. The gNPSI server receives datagrams from sFlow, repackages the datagrams in the protobuf message format and forwards these messages onto any subscribed gRPC clients. The protobuf used for this feature is available at the link above.

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.

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. Policies define inter-segment or intra-segment communication rules, e.g. segment A can communicate with segment B but hosts in segment B can not communicate with each other.

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.

When the next hop of an IP route (hereafter referred to as the dependent route) resolves over another IP route (hereafter referred to as the resolving route), the adjacency information of the resolving route’s FEC is typically duplicated into the dependent route’s FEC. With this feature, we prevent the duplication of the adjacency information. Instead, the dependent route’s FEC points to the resolving route’s FEC, forming a hierarchical FEC for the dependent route.

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

The routing table is not available on the standby supervisor in EOS, hence running any diagnostics or scripts that talk to the standby supervisor through the forwarding plane is not possible. This feature adds a new Cli command that configures a default route on a standby supervisor. This default route will offload routing to the forwarding plane. Therefore it behaves the same way as the routing table on the active supervisor. The default route is installed on all VRFs.

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.

Normally, a switch traps L2 protocol frames to the CPU. However, certain use-cases may require these frames to be forwarded or dropped. In cases where the L2 protocol frames are forwarded (eg: Pseudowire), we may require the frames to be trapped to the CPU or dropped. The L2 Protocol Forwarding feature provides a mechanism to control the behavior of L2 protocol frames received on a port or subinterface.

A L2 sub-interface is a logical bridging endpoint associated with traffic on an interface distinguished by 802.1Q tags, where each <interface, 802.1q tag> tuple is treated as a first class bridging interface.

Subinterfaces divide a single ethernet or port channel interface into multiple logical L3 interfaces based on the 802.1q tag (VLAN ID) of incoming traffic. Subinterfaces are commonly used in the L2/L3 boundary device, but they can also be used to isolate traffic with 802.1q tags between L3 peers by assigning each subinterface to a different VRF. L3 subinterface shaping + VRF is also supported.

LANZ Mirroring feature allows users to automatically mirror traffic queued as a result of congestion to either CPU or a different interface.

LANZ is the EOS Latency and congestion ANalyZer. On DCS-7280, DCS-7020, DCS-7500 and DCS-7800 series, it allows monitoring congestion and transmit latencies on both front panel and CPU ports.

ECN (Explicit Congestion Notification) is a mechanism of notifying network congestion without dropping the packets. The ECN based network congestion notification can be done in two ways: queue-length based ECN, latency based ECN. The queue-length based ECN marks the ECN-Capable Transport (ECT) packets when the average VOQ length exceeds the configured ECN threshold value whereas latency based ECN notify the congestion by marking the ECT packets, if packets take longer than the configured threshold to get dequeued from the VOQ. Both result in the egress marking of the packet if the congestion experienced is beyond the threshold.

The low latency tx-queue scheduler profile feature aims to provide an alternative operating mode for the queue that is fine-tuned for reduced latency. This involves a tradeoff between achieving lower latency and being able to sustain full throughput over a large number of flows.

In general, EOS always configures the PHYs to have the correct polarity to match that of the standard, such that if a standard compliant transceiver is plugged in and the peer is standard compliant everything will work.

Measured boot is a tamper-detection mechanism that records a system's boot process. It calculates cryptographic hashes of system components and configurations, which are then securely stored in the Platform Configuration Registers (PCRs) of a Trusted Platform Module (TPM) chip. This process creates a secure "hash chain" of the boot sequence. After the system starts, the TPM Quote operation, along with the PCR extension records, can be used to verify the PCR values, confirming that the system components are unchanged and the software is trusted.

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

For packets sent and received on the front-panel interfaces, this feature allows creation of a profile to configure buffer reservations in the MMU (MMU = Memory Management Unit which manages how the on-chip packet buffers are organized).

In EVPN, an overlay index is a field in type-5 IP Prefix routes that indicates that they should resolve indirectly rather than using resolution information contained in the type-5 route itself. Depending on the type of overlay index, this resolution information may come from type-1 auto discovery or type-2 MAC+IP routes. For this feature the gateway IP address field of the type-5 NLRI is used as the overlay index, which matches the target IPv4 / IPv6 address in the type-2 NLRI. Other types of overlay index are described in RFC9136, but these are currently unsupported.

EOS 4.35.0F introduces support for Network Time Security (NTS), as defined in RFC8915. NTS provides modern cryptographic security for the client-server mode of the Network Time Protocol (NTP). It separates key establishment from time synchronization by using a TLS-based NTS Key Establishment (NTS-KE) protocol to negotiate symmetric keys and encrypted cookies. These cookies are included in subsequent NTP packets to enable stateless authentication by the server. NTS ensures that time synchronization data is received from a legitimate source and has not been modified in transit.

If a gNMI.Set union_replace operation or gNOI.BootConfig RPC is issued without this configuration, an error is returned to the client.This feature adds support for the following to OpenConfig: gNMI.Set union_replace operation

Packet trimming is a novel method for end-to-end congestion notification. When a packet is dropped in the MMU due to congestion, the dropped packet is trimmed and forwarded to the intended receiver with a new configured DSCP value. Upon receiving a trimmed packet, the receiver can perform appropriate handling to reduce transmission rate or retransmit any lost packets. The feature supports matching criteria via ingress traffic policy for selecting which packets should be trimmed when they get dropped in the MMU. Similarly, the rewritten DSCP is specified on a per egress port basis for trimmed packets egressing out of the switch to the intended destination.This feature is supported for protocols IPv4, IPv6 and SRv6. 

Priority-Flow-Control (PFC) Fair Adaptive Dynamic Threshold (FADT) configuration facilitates efficient utilization of packet buffer resources for both lossy and lossless traffic. Reserve headroom buffer resources to absorb in-flight packets for congested, lossless flows. Assign default or user-defined PFC profiles to interface/PFC priority pairs, called Priority Groups (PG), to dynamically manage packet buffer usage and assertion of PFC pause.

Policy-based routing (PBR) is a feature that is applied on routable ports, to preferentially route packets. Forwarding is based on a policy that is enforced at the ingress of the applied interface and overrides normal routing decisions. In addition to matches on regular ACLs, PBR policy-maps can also include “raw match” statements that look like a single entry of an ACL as a convenience for users.