Tag :: Profile

BGP triggered IP-in-GUE Encapsulation provides a mechanism for dynamically creating tunnels in a core network using an IP underlay.  IP-in-GUE (Generic UDP Encapsulation) encapsulates IP traffic in an IPv4/UDP header.  IP unicast routes to destinations reachable across the core network are learned via BGP at the ingress edge.

This is an ecosystem of CLI commands that allow the user to create and apply override profiles for the various CDB capabilities and related EOS software controls of CMIS-compliant transceivers. A profile consists of a set of parameters which, when configured, replace the default parameters provided by the transceiver or by EOS.

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.

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

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

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). The profile can contain configurations for ingress and egress. On the ingress, configuration is supported at both a port level as well as a priority-group level. 

Historically EOS transceiver-related configurations have been applied on a per-interface or per-slot basis, however this approach is inefficient in applying a configuration that is relevant to a group of transceiver modules determined by certain criteria.

To address such use cases, the concept of “transceiver matching rules” is being introduced.

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.