Tag :: TOI

BGP inbound update processing delay is a feature in EOS where an optional delay is applied prior to processing inbound UPDATE messages from a peer(s). The duration of the delay is configurable per peer. The delay is applied to UPDATE messages for all the address families that are negotiated with the peer. The delay timer starts when the peer becomes established. The routes from such peers are processed only after the timer expires. Any routes received after the timer expired are processed as usual without the delay. Both the default VRF and non-default VRFs are supported.

IPv6 BGP peers and IPv6 prefixes for non default VRFs are supported starting EOS 4.15.0F. All CLI commands available

The default policy behavior is to permit/accept all routes when a BGP neighbor or peer group is configured with a route

BGP Monitoring Protocol (BMP) [1] allows a monitoring station to connect to a router and collect all of the BGP

BGP Monitoring Protocol (BMP) allows a monitoring station to collect information about a router’s BGP sessions, such as BGP announcements received from peers (Adj-RIB-In),  monitoring the Loc-Rib (as defined by RFC9096), and BGP announcements advertised from the router (Adj-RIB-Out). The announcements are sent to the station in the form of BMP Route Monitoring messages generated from the router’s BGP internal tables.

EOS by default selects the prefix for ECMP if the two paths have the same AS PATH length regardless of the ASN values in

When a BGP session cannot be established between two peers due to configuration inconsistencies, the peer is moved to the “idle state” and the session establishment is not retried. The session remains down until an operator issues a manual clear ip bgp command to bring it back up. This prevents continuous immediate reconnection attempts to the peer.

The BGP idle restart interval feature allows an idle BGP peer session to automatically restart after a configurable

When a core router has competing advertisements for the same prefix from various PEs, the local edge route should be selected as the best path based on the IGP metric of the resolving routes of those competing advertisements. Without the support mentioned in this TOI, when a BGP route has two or more levels of recursion, the BGP process does not utilize the IGP distance in the route selection process. 

This feature adds support for user-configured BGP Nexthop Resolution RIB profiles for various BGP-based services e.g. IP unicast, L3 VPN, EVPN, etc. The feature allows an administrator to customize the next hop resolution semantics of BGP routes with an ordered list, or profile, of resolution RIB domains (i.e., either tunnel or IP domain). This allows EOS to direct specific services over the specified RIB domains, overriding the default behavior.

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

Creating Traffic Policies that regulate control plane traffic from BGP peers by writing the list of BGP peer addresses statically in a field-set is error prone and difficult to update. Selecting only internal or external peers requires additional care. This feature automatically populates a field-set with IPv4 or IPv6 prefixes corresponding to iBGP or eBGP peers. This can be used instead of “protocol neighbors bgp” (see "Support for CPU traffic policy" ) where only a particular peer type is needed, or to replace complicated manual field-set updates.

Peer Tagging Route Filtering feature discards BGP route advertisements by the peers which the routes are received from. The feature lets users assign a peer-tag to a peer or a group of peers in inbound direction and discard routes advertisements by the peer-tag in outbound direction. One use case of the feature is to discard AS loop routes in outbound direction in data center deployments.

The sub route map configuration simplifies routing policies by sharing common policy across route maps. Common

BGP Prefix Independent Convergence (PIC Edge) refers to fast re-convergence of traffic destined for BGP prefixes on a network event affecting the best path(s) such that the time taken to switch traffic from the active best path(s) to the next best path (i.e. backup path) is independent of the number of prefixes. The above behavior is achieved by pre-programming the best path and alternate backup path in the forwarding agent in steady state. 

The BGP Prefix Independent Convergence (PIC) Edge feature refers to fast re-convergence of traffic destined for BGP prefixes on a network event affecting the best path(s) such that the time taken to switch traffic from the active best path(s) to the next best path (i.e. backup path) is independent of the number of prefixes. The above behavior is achieved by pre-programming the best path and alternate backup path in the forwarding agent in steady state.

The BGP Prefix Independent Convergence (PIC Edge) is an existing feature that was first introduced in EOS 4.15.0F.

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.

Nexthop Groups is a feature that allows users to manually configure a set of nexthops by specifying their nexthop

Nexthop Groups allow users to manually configure a set of nexthops by specifying their nexthop addresses and

This feature adds support for a 'match route type' route map match clause in release 4.20.1F. This clause allows

The BGP selective route download feature allows learning and advertising BGP prefixes without installing them in

When a Provider Edge (PE) device loses BGP connectivity to the core (uplink) devices, it may be unable to forward any traffic from its downlink devices, typically CE (Customer Edge) devices. It is beneficial to indicate this connectivity loss to these CE devices so that they may find alternative paths to forward traffic.

BGP sFlow export is to add BGP route information including source and destination AS path information, local

BGP sFlow export is to add BGP route information in sFlow sample packet is the destination IP matches a BGP route. Prior

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 feature adds support for BGP UCMP in the multi-agent routing protocol model. Unequal Cost Multi Path (UCMP) for BGP is a mechanism for forwarding traffic from a device for an ECMP route in the ratio of the weights with which the next hops of that route are programmed in the FIB. This is done for BGP by disseminating BGP link bandwidth extended community attribute information with BGP paths such that the receiver device of all such paths for a route programs next hops for that route in the FIB in the ratio of the received link bandwidth values.

Unequal Cost Multi Path (UCMP) for BGP is a mechanism for forwarding traffic from a device for an ECMP route in the ratio

This feature introduces support for BGP wildcard-AS route targets specifically for route import into VRFs.

Bidirectional Protocol Independent Multicast (PIM) allows routers to build trees to deliver multicast traffic from sources to receivers. It is a variant of sparse-mode PIM that efficiently addresses the use case where receivers for a multicast group are also sources for that group. While sparse-mode PIM builds shared trees and source-specific trees, bidirectional PIM only builds shared trees. A shared tree for a multicast group is rooted at the Rendezvous Point (RP) for that group. The RP for a bidirectional group is an IP address, which may or may not be real, but is reachable via all routers in the multicast domain. There may be multiple RPs in a multicast domain.

"Block Untagged Frames on Dot1Q Tunnel port" is a new feature that has been added in this release. When this feature is

With the 12.0 release, CV-CUE supports Bluetooth scanning to detect nearby Bluetooth devices.  

A device's classification as a phone or non-phone is determined by the switch through three mechanisms: advertisement via LLDP packets, explicit MAC address classification via CLI commands, or classification as a phone through the DeviceType VSA from a AAA server during authentication. This feature enables the port to be flapped (portflap) when the device's classification transitions from phone to non-phone or vice versa. This functionality applies to classification changes for both MBA and EAPOL supplicants. 

Bug Alerts is a service that runs on Arista CloudVisionTM eXchange (CVX) that provides customers with information on

The Campus Dashboard provides an overview of your network state. Devices stream telemetry data to CloudVision in real time, giving you immediate and up-to-date insights into your network’s health. The timepicker can be used to view historic data of the network state.

The Campus Fabric studio allows you to set up and configure a complete campus network using Arista’s validated designs. By leveraging zero touch provisioning (ZTP), you can seamlessly onboard EOS devices, define their roles and connections within the fabric, and configure L2 and L3 services across the fabric. 

Deployments utilizing VXLAN, a routing underlay (OSPF or eBGP), and a routing overlay (eBGP) are supported, and you can also define connections to non-EOS devices in the fabric. Additionally, PTP, 802.1X, IP locking, and other network features are supported by the studio.

The Campus Health Dashboard provides an overview of your network state. Devices stream telemetry data to CloudVision in real-time, giving you immediate and up-to-date insights into your network’s health. The timepicker can be used to view historic data of the network state.

Class Based Forwarding (CBF) is a means for steering IP traffic into specific tunnels based on either the ingress DSCP values or based on “classes”, which are derived from fields in the ingress packet headers and policies provisioned on the router. CBF may be used with SR-TE Policy or RSVP-TE colored tunnels. 4.35.1F adds support for CBF with flex-algo colored tunnels.

Arista’s CCS-710XP series of ethernet switches consist of CCS-710XP-12TH-2S SKU. CCS-710XP-12TH-2S is a 12 port 1000BASE-T PoE & 2-port SFP+ fanless switch device rich with networking features suited for campus deployments.

This document describes the configuration and behavior of physical interfaces on the CCS-710XP series switch

This feature enables efficient cross-domain communication in a multi-domain deployment where the Layer 2 leaf VTEPs don't have arp learning bridged configured. Without this feature, cross-domain ARP requests must be flooded across all domains, creating significant overhead in large multi-domain deployments.

This is an addition to the SSL certificate and key management feature added in EOS 4.15.0F.

Network Administrators can configure the Certificate Revocation List (CRL) in CV-CUE to facilitate secure communication between the Access Points (AP) and the RadSec or Rsyslog server. A Certificate Revocation List (CRL) contains a list of digital certificates, typically provided as URLs, that the issuing authority has revoked before their scheduled expiration date. You can provide a maximum of 10 URLs for CRL

Connectivity Fault Management (CFM) is used in Virtual Bridged Local Area Networks for detecting, isolating, and

 With the 12.0 release, CloudVision Cognitive Unified Edge (CV-CUE) introduces Channel Maps. This chart displays the number of clients and access points (APs) visible to the managed device at a time on a given channel.

With the 12.0 release, you can view the criteria and parameters that influenced a channel change event. The data provides you insights on why the access point (AP) selected a particular channel over another.

With the DANZ Monitoring Fabric (DMF) 8.7 release, DMF Controller support for modular chassis switches has been improved by adding platform compatibility for DCS-7289-CH switches. DMF Controller and switch sync-up have also been improved to maintain state consistency.

With the 14.0 release, CV-CUE brings the ability to create checkpoints to save your current configurations, profiles, and settings. Creating and restoring a checkpoint is possible for all configuration settings available in CV-CUE. You can create a checkpoint for location based configurations, group configurations, or global configurations. For all the configurable settings that are available for a network, you can create a checkpoint to save it. 

With the 20.0 release, the checkpoint feature in CV-CUE also captures custom attributes created on the child or parent location. When you create a checkpoint for a location that has custom attributes, the custom value is also captured in the saved checkpoint.

This feature allows failover to the backup path to occur in constant time per interface going down for features such as RSVP link protection, RSVP node protection, TI-LFA link protection, and BGP PIC. Without this feature enabled, it would take time proportional to the number of paths going over the interface experiencing the link down event to failover to the backup path. With this feature enabled, the failover time would be constant regardless of the number of paths.