Tag :: TOI

ACL based traffic management often requires matching packets’ destination addresses against one or more sets of IP prefixes. This can become difficult to manage when the prefix sets need to be consistently maintained on several devices and either change too frequently or are very large. When the prefixes for the prefix sets are learned by BGP, this feature provides an alternative to maintaining unwieldy sets of statically configured IP prefixes. Instead the prefix sets are populated by BGP based on the BGP communities that are assigned to learned prefixes. BGP can manage IP prefix field sets for use with Traffic Policies.

To avoid hardware updates and route advertisement churn during switch reload or BGP instance start, BGP enters into

BGP Fallback AS offers the ability for BGP peering relationships be established with either the local as or the router

EOS 4.21.3F introduces support for BGP Flowspec, as defined in RFC5575 and RFC7674. The typical use case is to filter or redirect DDoS traffic on edge routers.

This feature introduces support for BGP route-target ranges specifically for route import. With this new capability, ranges of route targets can be configured for importing routes into VRFs.

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.

This feature adds support for a dynamic configuration model to eliminate the need for the network administrator to

This feature adds support for BGP peering over IPv6 link-local addresses. This feature is available with the ribd routing protocol model since EOS-4.20.5 and multi-agent routing protocol model since EOS-4.22.1. As defined in RFC 4007, IPv6 addresses have multiple possible scopes. The prefix range fe80::/10 is reserved for uniquely identifying interfaces on a single link, or of link-local scope. Previous EOS versions supported BGP sessions with IPv4 or IPv6 peer addresses

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

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.

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 adds support for BGP UCMP in the multi agent routing protocol model. The TOI for BGP UCMP in the ribd

RPKI serves as a security mechanism to mitigate specific instances of inadvertent route leaking and deliberate route hijacking.

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

Cable Length Measurement (CLM) is a feature that approximates path delays in cables and derives cable lengths from path delays. It is primarily used for features where knowing the path delay is important, such as hyperports. Upon full implementation of the protocol, EOS CLM would be capable of performing CLM message exchange with connected devices running EOS or other systems that support the CLM protocol.

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.