Tag :: EOS 4.32.2F

This feature adds support for configurable max sFlow datagram size. The current default max datagram size is 1400 bytes, which can cause some sFlow datagrams to be dropped when there is an MTU set. This feature enables the configuration of the max datagram payload size within the range of 200 to 1500 bytes to help avoid fragmentation. Note that this feature only configures software sFlow and is not supported on hardware-accelerated sFlow.

Prior to 4.32.2F, the “reset system storage secure” CLI command can be used to perform a best-effort storage device wipe of all sensitive data. However, this command has the limitation that it wipes EOS from the storage device, leaving the system “stuck” in Aboot. The “reset system storage secure rollback” command provides the same secure erase functionality, but additionally allows the user to preserve a subset of files on the main flash device by copying them into RAM during the secure erase procedure. The set of files that are preserved is configurable. After a successful wipe, the system will return to EOS after the erase is complete if the EOS SWI image and adequate configuration files are preserved (such as boot-config and startup-config).

gNSI (gRPC Network Security Interface) defines a set of gRPC-based microservices for executing security-related operations on network devices.

IS-IS SR Stateful Switchover (SSO) support allows for a switchover from an active supervisor to a standby supervisor where MPLS traffic remains undisrupted during switchover. This involves reconciliation of all Segment Routing related information in the network using IS-IS Graceful Restart procedures. And also installing the same in forwarding hardware in a manner that does not disrupt the ongoing traffic.

This feature provides a cli command showing the list of mac addresses which could not be learned due to hash collision in the hardware table. A hash collision occurs when two or more distinct pieces of data map to the same entry ( or slot ) in the hardware table. It can happen when the hash function used to calculate the index for a given mac address results in the already occupied index, resulting in failure of inserting the later mac address to the hardware table.

This document describes the OSPFv2 and OSPFv3 feature that allows enabling or disabling the inclusion of LSAs having “Down” (DN) bit set in SPF calculations. The DN Bit is a loop prevention mechanism implemented when OSPF is used as CE - PE IGP protocol.

In order to support PIM/IPv4 multicast routing on EOS switches with Broadcom Tomahawk4 ASICs, multicast support using ALPM is required. This works in both 3-level Algorithmic Longest Prefix Match (ALPM) capabilities and 2-level ALPM.

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

This supports checking that the value of a given x509 certificate OID matches a user-provided value during the TLS handshake in OpenConfig. If the value does not match, no connection will be established.

This document describes the availability of VLAN ingress and egress counters on R Series platforms. VLAN counters provide the ability to count packets and bytes ingressing or egressing a bridge domain (VLAN).

Overlay IPv6 routing over VXLAN tunnel using an anycast gateway (direct routing) has been previously supported using the “ipv6 virtual-router” configuration for both the data-plane and EVPN (or CVX) control-plane learning environments. 

SwitchApp is an FPGA-based feature available on Arista’s 7130LB-Series and 7132LB-Series platforms. It performs ultra low latency Ethernet packet switching. Its packet switching feature set, port count, and port to port latency are a function of the selected SwitchApp profile. Detailed latency measurements are available in the userguide on the Arista Support site.

The Unified Forwarding Table (UFT) is memory that is shared between Layer2 and Layer3 lookup tables with capabilities for variable partitions. Rather than separate Layer2 and Layer3 lookup tables of fixed size, the UFT may be partitioned to support user-requested combinations of Layer2 and Layer3 lookup table sizes.

This document describes the VRF selection policy and VRF fallback feature. A VRF selection policy contains match rules that specify certain criteria (e.g. DSCP, IP protocol) as well as a resulting action to select a VRF in which to do the FIB lookup. The VRF fallback feature is an extension of these policies which allows users to optionally specify a “fallback” VRF for each VRF. The behavior is such that if the FIB lookup fails in a match rule’s selected VRF, another lookup will be attempted in the configured fallback VRF. Additionally, the fallback VRF itself can have yet another fallback VRF, such that if the lookup in the VRF and fallback VRF fail, the fallback-of-the-fallback VRF will be looked up (see the Configuration section for an example of this).

VXLAN ARP and IPv6 Neighbor Discovery (NDP) packet headend replication capability via VxlanSwFwd matches the COPP rate limit for these packets for the supported platforms regardless of the size of the VXLAN flood VTEP list. However, there still remains a case where the handling capacity is limited by CPU: the handling of ARP broadcast and NS multicast that result from Glean traffic (post routing).

The document describes the support for policing on one or more VNIs configured on a Vxlan interface. This feature allows dedicated policing of flows on a VNI in both directions which corresponds to incoming traffic from a remote VTEP and outgoing traffic towards a remote VTEP. Policers in the hardware are created with policer profiles attached to VNIs. Policer profiles can be shared across multiple VNIs but policers are dedicated.

This document describes the support for VNI policing counters on VNIs where the VNI policing feature has been provisioned. Counters for this feature provide information on how many packets are being allowed or dropped for a VNI specific flow due to configured VNI policers. VNI policing counters are supported in both directions which correspond to incoming traffic from a remote VTEP and outgoing traffic towards a remote VTEP. Counters in each direction are configured separately. Both packet and bytes counts are supported.