Tag :: EOS 4.33.0F

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.

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.

Class Based Forwarding (CBF) provides a means for forwarding traffic through selected tunnels based on the traffic class of the incoming packet. Starting 4.32.2F CBF supports forwarding MPLS labeled traffic based on the EXP value in the incoming packet or the internal traffic class (TC) resolved from the parameters of the packet (e.g TC derived from EXP bits combined with port trust mode). Here, EXP bits refer to the Experimental bits in the MPLS header.

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.

Common Management Interface Specification (CMIS) defines, starting with revision 4.0, a standard mechanism for managing the firmware of compliant transceivers. This mechanism allows for transceivers’ firmware to be updated without having to remove the transceiver from the switch. Firmware updates may be necessary in a testing or production environment to resolve potential firmware bugs. Some transceivers may also support firmware management operations in a hitless manner (without impacting traffic).

Transmit queues are logical partitions of an Ethernet port’s egress bandwidth. Data streams are assigned to queues based on their traffic class, then sent as scheduled by port and transmit settings. Sand platform switches have eight queues, 0 through 7, and all queues are exposed through the CLI. However, queue 7 is not user-configurable. Queue 7 is always mapped to traffic class 7, which is reserved for control plane traffic. This feature allows tx-queue 7 to be configurable. As of 4.33.0F, a limited set of features are configurable on tx-queue 7.

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.

This feature allows the user to define a custom DSCP-To-TC map and apply it to an interface. The custom DSCP-To-TC map would only be applicable when the interface is in DSCP trust mode. This feature allows the user to classify packets based on DSCP bits of the IP header. The exact mapping can be specified using a custom DSCP-To-TC map.

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.

Until EOS release 4.32.0F, EOS allows users to statically configure link min-delay and max-delay used for IS-IS FlexAlgo. This feature adds support for dynamic measurement of link delay using the TWAMP Light protocol described in RFC 8186 and provides it to IS-IS FlexAlgo dynamically.

This document describes how to configure and monitor this feature.

This feature allows generating the syslog message for the packets matching deny rules in egress ACLs. This can be enabled using the log keyword when configuring a deny ACL rule. A copy of the packet matching such deny ACL rule is sent to the control plane, where a syslog entry for the packet header is generated.

Normally, an ingress router has no control over an autonomous system border router’s (ASBR) selection of inter-AS links. In the example below, Peer 2 and Peer 3 both advertise reachability to some remote network to ASBR 1 (e.g. service route 172.16.1.0/24). ASBR 1 would then use normal bestpath selection rules to select a preferred egress path (for traffic flowing to that service route). However, this means that the ingress router has no control over which egress path is chosen.

RFC 5837 describes extensions to the Internet Control Message Protocol (ICMP) that enable network devices to identify incoming and outgoing interfaces and next-hop addresses via extensions to specific ICMP error messages. These extensions are particularly useful for network diagnostics and troubleshooting applications.

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. 

The EOS Event Manager feature provides the ability to specify a condition and an action to be carried out when that condition is detected. It is a flexible and configurable way to automate the reaction to conditions without the need for a system operator to observe and apply the desired actions manually.

E-Tree is an L2 EVPN service (defined in RFC8317) in which each attachment circuit (AC) is assigned the role of Root or Leaf. Once roles are assigned, the following forwarding rules are enforced:

Typical WiFi networks utilize a single, central Wireless LAN Controller (WLC) to act as a gateway between the wireless APs and the wired network. Arista differentiates itself by allowing the wireless network to utilize a distributed set of aggregation switches to connect APs to the wired network. This feature allows a decentralized and distributed set of aggregation switches to bridge wireless traffic on behalf of the set of APs configured to VXLAN tunnel all traffic to those aggregation switches, or their “local” APs.

Administrative Groups (AG) provide a way to associate certain attributes or policies with connections between nodes , enabling network administrators to control the routing decisions based on specific criteria. Extended Administrative Groups (EAG) are an extension of AG which allow a larger range of admin groups to be utilized for various Traffic Engineering (TE) purposes within a network. EAGs are defined in a new sub-TLV for IS-IS link attributes, separate to AGs, however they are considered as one within EOS. The EAG feature in EOS allows the range of administrative color to be increased from 0-31 to 0-127.

This is an extension to the IKE policy and SA policy configuration options available in EOS. The key lifetimes for IKE policies and SA policies are specifiable in hours. This feature allows specifying the key lifetimes in minutes as well.

This feature introduces the support for IPv4 ACL configuration under GRE and IPsec tunnel interfaces and IPv6 ACL configuration under GRE tunnel interfaces. The configured ACL rules are applied to a tunnel terminated GRE packet i.e. any IPv4/v6-over-GRE-over-IPv4 that is decapsulated by the GRE tunnel-interface on which the ACL is applied, or a packet terminated on IPsec tunnel i.e, IPv4-over-ESP-over-encrypted-IPv4 packet that is decapsulated and decrypted by the IPsec tunnel interface on which the ACL is applied.

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 allows capturing packets and byte counts at high resolution on physical interfaces, down to 1 ms granularity. Allows for detecting anomalous packet flows, or confirming the expected bandwidth usage. Requires selecting a set of interfaces to sample, a time resolution, and sampling duration.

This is an extension to BGP EVPN VPNs that allow us to use iBGP as the PE-CE protocol. This feature also provides a way to isolate the customer’s network BGP attributes from the SP backbone’s attributes, by saving them into a special attribute called ATTR_SET, code 128. This separation introduces a “route server” model that allows the customer’s BGP path attributes to be stored in the SP backbone along with the VPN-IPv4/v6 paths.

ICMP Probe allows querying of interface status and ARP or Neighbor Discovery table status remotely.  It is a request/response protocol, similar to ping, but instead of simply responding to the request, it responds with information about a local interface or a remote neighbor.  The node being queried is called the "proxy node"

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

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

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.

Segment Routing provides mechanism to define end-to-end paths within a topology by encoding paths as sequences of sub-paths or instructions. These sub-paths or instructions are referred to as “segments”. IS-IS Segment Routing (henceforth referred to as IS-IS SR) provides means to advertise such segments through IS-IS protocol.

Traffic Engineering (TE) provides a mechanism to network administrators to control the path that a data packet takes, bypassing the standard routing model which uses routes along the shortest path. Traffic engineered paths are generally computed on the head-end routers of the topology based on various constraints (e.g. minimum bandwidth, affinity) configured for those paths and attributes (e.g available bandwidth, color) received from devices in the network topology. IS-IS Traffic Engineering (IS-IS TE) feature extends IS-IS protocol in EOS to carry TE attributes as part of its Link State Protocol Data Units (LSPs).  Note that IS-IS in EOS only acts as a carrier for TE attributes and it is not used by any processing (e.g. SPF).

Normally, a switch traps L2 protocol frames to the CPU. However, certain use-cases may require these frames to be forwarded or dropped. And 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.

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.

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.

This feature allows setting the desired maximum VOQ latency. Drop probabilities are adjusted in hardware to meet this limit.

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.

MultiAccess is an FPGA-based feature available on certain Arista 7130 platforms. It performs low-latency Ethernet multiplexing with optional packet contention queuing, storm control, VLAN tunneling, and packet access control. The interface to interface latency is a function of the selected MultiAccess profile, front panel interfaces, MultiAccess interfaces, configuration settings, and platform being used.

Today in any WAN deployment, customers are required to configure path metrics in load balance policy to program a set of best paths in dataplane. Path metrics are multi-dimensional, it include loss, latency, jitter, and load of path. It is not very intuitive to come up with exact values for these metrics as they are highly dependent on the type of application and geographical locations of routers. Also these path metrics keep changing and except for a few apps that require strict max characteristics on latency, jitter or loss, the other apps are able to tolerate variances in metrics.

Proxy node segment helps in advertising segments in a segment-routing domain for prefixes that are originated outside the segment-routing domain.  Node B in the SR domain can advertise proxy-segments to node A for the loopacks of C and D which are not present in the SR domain. This feature will help in creating mpls routes for those loopbacks on node B. Note that if C and D loopbacks have LDP enabled and if they have exchanged the LDP labels with B then B can by default create a SR to LDP stitched mpls route even without enabling this feature. This feature is specific to the case where such stitched routes cannot be created.

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 the 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.

Routing Control Functions (RCF) is a language that can express route filtering and attribute modification logic in a powerful and programmatic fashion.The document covers: Configurations of a RCF function for BGP points of application

The sFlow VXLAN extension adds support for providing VXLAN-related information to sFlow packet samples, for VXLAN forwarded traffic. Specifically, for customer traffic ingressing on a CE-facing PE interface and forwarded into a VXLAN tunnel, the IP address of the source VTEP, the IP address of the destination VTEP and the VNI will be included in the sFlow datagram.

Currently, EOS supports the receiving and transmitting of BGP Flowspec rules. Rules received can be installed locally as ACLs and/or transmitted to other BGP peers/route reflectors. EOS relies on external controllers to inject these flowspec rules. The feature will allow flowspec rules to be defined via CLI in a similar fashion as traffic-policies is currently done. These policies would then be redistributed into BGP. Once redistributed, the rules can be advertised to other BGP peers and optionally installed locally on the configured system.

Storm control enables traffic policing on floods of packets on L2 switching networks. Support for counting dropped packets and bytes on interfaces where storm control metering is provisioned. Both packet and bytes count are supported and will be displayed. Drop logging on storm-control discards is also supported.

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