Tag :: TOI

LACP on Loopback Interfaces allows for Active Port Channels on one or more interfaces whose link endpoints terminate

LACP State Transition Event Monitoring on Arista switches allows for quick and filterable viewing of LACP state

Introduced in EOS-4.20.1F, “selectable hashing fields” feature controls whether a certain header’s field is used in the hash calculation for LAG and ECMP.

Control Plane Policing (CoPP) classifies control plane traffic into protocol classes (e.g., IGMP, LLDP, BGP) and applies rate limiting per class using queue shaping. On supported platforms, all control plane traffic for a given protocol class is directed to a single queue regardless of the ingress port. As a result, a high-rate flow from a single port or host can consume the entire bandwidth allocated to that class, starving legitimate control plane traffic arriving on other ports.

LAGs are allocated hardware resources on transition from one member (software LAG) to two members (hardware LAG) and deallocated hardware resources on transition from two member to one member. This allocation/deallocation causes some traffic disruption. Starting with EOS4.15.4F, the option to configure all LAGs to use hardware resources is supported on the 7500E platform.

This document addresses LAG hashing improvements across different platforms. In DANZ Monitoring Fabric (DMF) 8.7, the Controller applies the default hash configuration if no hash fields are configured or the configuration contains an error. If the Controller detects any hash error, DMF reports it as a fabric error.

Switches can now use two LAG partitions (A and B) to support double the number of available Port Channels dictated by the chosen LAG mode. This is useful if the selected LAG mode does not allow the creation of the desired number of Port Channels on a single partition.

Arista switches use the hashing algorithm to load balance traffic among LAG (Link Aggregation Group) members

LANZ Mirroring feature allows users to automatically mirror traffic queued as a result of congestion to either CPU or a different interface.

This document describes the current status of LANZ on DCS 7500R, DCS 7280R and DCS 7020R, for both polling and

LANZ on 7160S 32CQ, 7160 48YC6 and 7160 48TC6 adds support for monitoring congestion on front panel ports with Start,

LANZ is the EOS Latency and congestion ANalyZer. On DCS-7280, DCS-7020, DCS-7500 and DCS-7800 series, it allows monitoring congestion and transmit latencies on both front panel and CPU ports.

Interface policing enforces traffic rate limits on ingress interfaces by configuring policer profiles with a lower rate (CIR) and/or higher rate (PIR) and a burst-size (CBS and/or EBS). The current implementation limits the maximum burst-size (CBS/EBS) to 4 MB. The large burst support feature extends the maximum configurable burst size for interface policers from 4 MB to 256 MB.

ECN (Explicit Congestion Notification) is a mechanism of notifying network congestion without dropping the packets. The ECN based network congestion notification can be done in two ways: queue-length based ECN, latency based ECN. The queue-length based ECN marks the ECN-Capable Transport (ECT) packets when the average VOQ length exceeds the configured ECN threshold value whereas latency based ECN notify the congestion by marking the ECT packets, if packets take longer than the configured threshold to get dequeued from the VOQ. Both result in the egress marking of the packet if the congestion experienced is beyond the threshold.

Configure latency thresholds for DHCP, DNS, AAA, WAN, and Gateway while creating a Client Connectivity Test (CCT) profile. When the latency exceeds the defined threshold, the CCT result is displayed as a partial failure.

NAT peer state synchronization feature provides redundancy and resiliency for dynamic NAT across a pair of devices in an attempt to mitigate the risk of single NAT device failure. The main motivation is that since the NAT state is shared between two switches, the failure of one switch can be tolerated since the other switch will retain the translations.

A layer 3 subinterface is a logical endpoint associated with traffic on an interface distinguished by 802.1Q tags, where each interface, 802.1Q tag tuple, is treated as a routing interface.

The Label Distribution Protocol (LDP) is a protocol in the Multiprotocol Label Switching (MPLS) context that allows label switch routers (LSRs) to exchange label mapping information. It is a distributed protocol without a central controller. Instead, each LSR generates local label mappings for Forward Equivalence Classes (FECs) and propagates this information to adjacent LSRs which it maintains LDP sessions with.

If a network device uses deep packet inspection for load balancing, RFC6790 recommends deployments to use entropy label in LDP to improve load balancing in MPLS networks by providing sufficient entropy in the label stack itself.

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.

LDP over RSVP (also known as LDP tunneling) allows LDP-signaled LSPs to use RSVP-TE tunnels as forwarding shortcuts instead of following hop-by-hop IGP paths. Prior to this feature, LDP over RSVP was supported only with IS-IS as the IGP. This feature extends LDP over RSVP support to OSPF, enabling both headend (ingress) and transit functionality when OSPF is the IGP.

The LDP pseudowire feature provides support for emulating Ethernet connections over a Multiprotocol Label

The LDP pseudowire feature provides support for emulating Ethernet connections over a Multiprotocol Label Switching (MPLS) network using the extension of the MPLS Label Distribution Protocol (LDP)

The alternate LDP pseudowire feature enables users to configure an alternate pseudowire to the existing (primary) pseudowire for a given patch. Preference is initially given to the primary pseudowire.

Leaf Smart System Upgrade (SSU) provides the ability to upgrade the EOS image with minimal traffic disruption.Note: It is possible that SSU shutdown and bootup are not supported in the same image. If a product has shutdown support in image A and bootup support in a later image B, then SSU upgrade cannot be performed from image A to any images earlier than image B, including image A itself. However, upgrading from image A to image B onwards is allowed.

Leaf Smart System Upgrade (SSU) provides the ability to upgrade the EOS image with minimal traffic disruption.

At a transit router when multiple LSP are available for a given destination from different protocols EOS does stitching based on hard coded preferences. LFIB stitching preferences give a provision to stitch together different LSPs based on configurable preferences. For each protocol(destination) preference can be configured for a given source protocol.

Line system commands are used to apply configuration and query the status of line system modules in EOS. The supported line system modules are the OSFP-AMP-ZR and the QSFP-AMP-ZR.

Link Fault Signalling (LFS) is a mechanism by which remote link faults are asserted over a link experiencing

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.

This feature adds support for Layer1-only front panel Ethernet ports on 7130 devices (containing a layer1 crosspoint chip) to participate in LLDP. As of 4.33.1F only internal Switch interfaces on ASICs/FPGAs participate in the LLDP protocol. The neighbor also only sees these internal ports from the switch. Customers who really care about/rely on LLDP information of  the front panel Ethernet ports, especially for making cabling changes, would need to translate the internal interface to the appropriate Ethernet port using the show l1 path output.

Local Authentication (also known as authentication survivability) is the ability of access points (AP) to authenticate and onboard clients to the network using root CA certificates through the integrated EAP server of the AP. Use Local Authentication when the RADIUS servers are not reachable to authenticate the clients. It is typically a temporary authentication mechanism; avoid using it as a primary authentication. If there are certificate chains, you must upload the root CA certificate along with the certificate chain.

This capability allows for the logging of Access Control List (ACL) actions on CloudEOS and AWE-series platforms. Logging is supported for various ACL actions including permit, drop, and redirect.

Logical ports are hardware resources that are required to activate interfaces.

With the 14.0 release, CloudVision Cognitive Unified Edge (CV-CUE) removes the Wireless Manager(WM) UI dependency for login and for applying the service license. You will no longer be redirected to WM and can now directly login to CV-CUE from the UI. 

The low latency tx-queue scheduler profile feature aims to provide an alternative operating mode for the queue that is fine-tuned for reduced latency. This involves a tradeoff between achieving lower latency and being able to sustain full throughput over a large number of flows.

This TOI introduces a new global CLI configuration command to transition CMIS compliant transceivers to the low-power mode when all interfaces associated with the transceiver are shut down. Conversely, the transceivers will transition into high power mode when any interface associated with the transceiver is enabled.

For various peering applications, there is a need to support the assignment of a MAC address on routed interfaces.

Support for Media Access Control Security (MACsec) with static keys was added in EOS 4.15.4. This feature brings

Media Access Control Security (MACsec) is an industry standard encryption mechanism that protects all traffic

Media Access Control Security (MACSec) is an industry standard encryption mechanism that protects all traffic flowing on the Ethernet links. MACSec is based on IEEE 802.1X and IEEE 802.1AE standards. This document describes the details of MACSec on CCS-722XPM-48Y4 and CCS-722XPM-48ZY8 products. MACSec on these platforms is implemented by internally sending frames to be decrypted or encrypted to a block of the switch chip, referred to as the MACSec engine.

Media Access Control Security (MACSec) is an industry standard encryption mechanism to protect all traffic flowing on Ethernet links. Mac Security is described in IEEE 802.1X and IEEE 802.1AE standards.

Media Access Control Security (MACsec) is an industry standard encryption mechanism that protects all traffic flowing on the Ethernet links. MACsec is based on IEEE 802.1X and IEEE 802.1AE standards.

The MACsec SSU feature enables a switch to undergo an In-Service Software Upgrade to a newer EOS version without disrupting existing MACsec traffic. Previously, the MACsec control plane agent would restart during SSU without previous state information. This lengthy cold reboot caused sessions to drop because MKA (MACsec Key Agreement) protocol packets (MKPDUs) were not sent, leading to traffic loss based on configured security policies.

DMF 8.7.0 supports Media Access Control Security (MACsec) as an Early Field Trial (EFT) feature. MACsec is a global configuration option for the entire fabric, with the option to enable it on intracore traffic only. MACsec only encrypts traffic between core switches, ignoring all other ancillary traffic (e.g., tap to filter, delivery to tool). MACsec is a licensed feature. Verify a MACsec license is installed on all switches participating in MACsec before using this feature.

By default, the only visibility a user has into packets that are dropped due to errors with the MACsec/IPsec protocols is a set of counters, such as with show mac security counters detail. This feature enables redirecting such packets to the CPU for manual inspection; it is intended to assist with debugging unexpected packet drops.

Maintenance mode is a framework to allow for the easy removal of elements of a switch or the entire switch from

EVPN VXLAN all-active multihoming (AA-MH) provides redundancy to reduce or eliminate the impact of outages and maintenance. The objective of Maintenance Mode on AA-MH is to gracefully drain away the traffic from the EVPN core flowing through a switch that is part of multihoming while the switch is put into maintenance, and to gracefully add it back into the network and attract traffic again once the switch is out of maintenance. During the maintenance cycle any customer edge Ethernet or Port-Channel interfaces, whether they are participating as ethernet segments or not, can also be put into maintenance mode. Doing so eliminates the northbound traffic from the customer edge from flowing through the switch under maintenance. The traffic will instead take a path through other available multi-homing peers.

Maintenance mode is a framework that allows for the easy removal of switch elements or the entire switch from service with minimal configuration. This feature supports the maintenance mode in WAN Routing System Adaptive Virtual Topology, including high availability deployment. Traffic is drawn away from the node entering maintenance mode. Currently, the feature supports only maintenance mode for the built-in unit System.

Maintenance mode with sub interfaces is an extension to the maintenance mode feature released in EOS 4 15 2F. With this