EOS 4.36.0F TOI

Beginning with EOS version 4.36.0F, the CCS-710XP series offers the ability to increase ingress Access Control List (ACL) scale if counters are declared unnecessary. This will be the default behavior on CCS-710XP platforms running releases from 4.36.0F onwards. This document details steps to enable or disable counters as required, along with resources for related issues.

Groups of front panel ports can be controlled by one power controller module. Power faults can often be detected by the power controller, which causes loss of power for all ports controlled by the power controller. The fault can be triggered by inrush current during insertion or removal of transceivers. A broken transceiver can cause a fault too.

This feature enables efficient cross-domain communication in a multi-domain deployment where the Layer 2 leaf VTEPs don't have arp learning bridged configured. Without this feature, cross-domain ARP requests must be flooded across all domains, creating significant overhead in large multi-domain deployments.

This feature allows the configuration of custom DSCP-to-DSCP maps on a per-Nexthop Group (NHG) basis. When applied it rewrites the DSCP of the outer IPv4 header of IPvX-in-IPv4 (X represents both v4 and v6) encapsulated packets using the inner IPvX header’s DSCP value while ensuring the DSCP of the inner IPvX overlay is preserved.

Forwarding destination prediction allows users to determine which interface a given packet will egress out. This feature is enhanced to identify the TCAM bank and rule offset for the matched ACL rule responsible for the forwarding decision. This allows network operators to trace the egress result back to the exact rule that triggered the action.

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

IPv6 static routes can be configured with link-local next-hop addresses on point-to-point interfaces. However, in deployments that rely on Zero Touch Provisioning (ZTP) to bring up devices with static routes, specifying link-local addresses in configuration templates is cumbersome because link-local addresses vary per device and per interface. This makes it impossible to use a single configuration template across multiple devices.

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.

In certain IPsec VPN scenarios, the responder needs to assign a virtual IP address (peer address) to an initiator. During the IKE negotiation, the initiator requests a virtual IP to be assigned with an IPsec configuration payload parameter. The responder establishes the connection after assigning an IP to the initiator.

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. 

Forwarding destination prediction allows users to determine which interface a given packet will egress out. This feature is enhanced to identify the TCAM bank and rule offset for the matched ACL rule responsible for the forwarding decision. This allows network operators to trace the egress result back to the exact rule that triggered the action.

This feature provides protocol independent UCMP support for all the routes which follow the IGP path provided there is no UCMP computation done at the protocol level itself. This feature optimizes bandwidth utilization by weighting next-hop members according to their link capacity.

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.

The identity of a remote peer (used to authenticate the remote peer in IKE phase 1) can be specified in the form of an IP address or a Fully Qualified Domain Name (FQDN) / User Fully Qualified Domain Name (UFQDN). This feature allows specifying an X.500 distinguished name (RFC 4514) as the remote peer identity.

Access Control Lists (ACL) use packet classification to mark certain packets going through the packet processor pipeline and then take configured action against them. Rules are defined based on various fields of packets and usually TCAM is used to match packets to rules. For example, there can be a rule to match the packet source IP address against a list of IP addresses, and drop the packet if there is a match. This will be expressed in TCAM with multiple entries matching the list of IP addresses. The number of entries is reduced by masking off bits, if possible. TCAM is a limited resource, so with classifiers having a large number of rules and a big field list, TCAM runs out of resources.

This TOI supplements the Ingress Traffic Policy applied on ingress port interfaces. Please refer to that document for a description of Traffic Policies and field-sets. This TOI explains the Traffic Policies as applied in the ingress direction on VLAN interfaces. For Traffic Policies on the egress direction of VLAN interfaces, see the Egress Traffic Policy TOI.

As of EOS-4.36.0F, a configurable user session timeout is supported for console, SSH, and telnet management sessions. This feature closes the user session (interactive) once the specified duration has been reached, regardless of user activity and independent of any configured idle-timeout. Upon session termination, a system message is generated to indicate the session’s closure. This feature is disabled by default.