Tag :: EOS 4.29.1F

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. 

This feature enables Tap Aggregation generic header removal on a tap port.

Prior to this feature we supported a maximum of two levels of Forward Equivalence Class hierarchies in hardware.

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 feature introduces hardware forwarding support of IPv4 multicast traffic over IPv4 GRE tunnel interfaces in Arista Switches. Multicast source traffic can reach the receivers which are separated by an IP cloud which is not configured for IP multicast routing by utilizing a GRE tunnel.

SWIM (SWI Modularized) is a change to the format of EOS.swi. It is a feature that is mostly internal, but has a few customer visible side-effects one should be mindful of.

SwitchApp is an FPGA-based feature available on compatible Arista 7130 devices. 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 user guide on the Arista Support site.

The new show command show configuration consistency adds the ability to check for “dangling” references in the configuration. For example, it is possible to configure an access-list, TEST-ACL, to an interface (ip access-group TEST-ACL in), without actually defining TEST-ACL (ip access-list TEST-ACL). This show command will list such “undefined” references.

This article describes how to customize TCAM ( Ternary Content Addressable Memory ) lookup for each feature which uses TCAM. The lookup is composed of fields, in the packet header / forwarding chip pipeline decisions, that are of interest to a feature. Size of the lookup determines the number of banks to be used by a feature. Traditionally, any feature uses a predefined TCAM lookup.

Virtual Private LAN Service (VPLS) appears in (almost) all respects as an Ethernet type service to customers of a Service Provider (SP). A VPLS glues together several individual LANs across a packet switched network to appear and function as a single bridged LAN. This is accomplished by incorporating MAC address learning, flooding, and forwarding functions in the context of pseudowires that connect these individual LANs across the packet switched network. LDP signaling is used for the setup and teardown of the mesh of pseudowires that constitute a given VPLS instance.

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