Tag :: EOS 4.24.1F

Accumulated IGP Metric (AIGP) is an optional non-transitive BGP attribute used to carry an IGP metric with BGP route advertisements. The AIGP attribute is useful for tie-breaking in BGP bestpath selection so that routing decisions can be made on the basis of shortest path/lowest IGP cost path amongst multiple BGP paths. This is particularly applicable in scenarios where a single administration is subdivided into multiple Autonomous Systems (AS) each with similar routing policies and the same IGP in use such that the IGP metric for a route can be propagated usefully between the ASes so as to let receiving BGP speakers make routing decisions based on the cumulative IGP cost of the route. This set of ASes in a common administrative domain in the context of advertising and receiving the AIGP attribute are referred to as an AIGP administrative domain.

The goal of IAR operation is to minimize the CPU processing and churn in hardware by identifying a set of nexthop adjacencies such that updating those adjacencies in-place is sufficient to correctly forward the traffic quickly for all the affected routes.

BGP Non Stop Forwarding (NSF) aims to minimize the traffic loss when the the following scenarios occur:

RPKI provides a mechanism to validate the originating AS of an advertised prefix. Using the result of the validation to apply inbound policy in a route map.

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.

This feature implements RFC 3478. It allows devices to preserve the MPLS LDP LFIB entries in the forwarding plane if the TCP connection is lost or LDP agent restarts.

On a MLAG chassis, MAC addresses learned on individual peers are synced and appropriate interfaces are mapped to these MAC addresses. In case of unexpected events like reloading of one of the peers in the MLAG chassis or flapping of one or more MLAG interfaces, some loss of traffic may be observed.

Bidirectional Forwarding Detection (BFD) is a protocol that provides low-overhead, short-duration detection of failures of arbitrary paths between two systems.

Static NAT rules may optionally include an access list to filter the packets to be translated.

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

In TAP Aggregation mode, configuration options are provided to handle special packet types. When receiving a packet whose Frame Check Sequence (FCS) is corrupted, the default behavior is to replace the bad FCS with the correct value and forward it. Configuration options are available to control the FCS behavior, such as to discard errors, pass through the bad FCS, or append a new FCS.

4.21.3F introduces support for the feature on the platforms listed below. The TOI describing the feature support on different versions/platforms is available here. 

This article describes a set of CLI commands to create TCAM profiles. The profile is composed of a set of TCAM features, with each feature having customized lookup key, actions and packet types to hit.