Tag :: TOI

This feature is provided on all platforms. The BGP listen range command has been modified to optionally allow

Support for asset tagging aids hardware identification by the use of user supplied strings. Fixed

This feature adds support for associating a WAN interface with multiple Dynamic Path Selection (DPS) path groups to allow paths originating from the same interface to have different priorities.

AVB technology allows transporting time sensitive professional grade audio and video streams over a switched ethernet network while providing deterministic latency and bandwidth guarantees. Supporting protocols include:

The audit report includes the start and end timestamps of the communication key timers for the past six months, the event type, MAC address, type of the key used between AP and the server, and the login ID. It also lists the non-TPM Access Points connected to the server during the onboarding window.

With the 13.0.1 release, you can authenticate wired hosts connected to the LAN ports of access points (W-118 and W-318) using 802.1X or MAC-based authentication. You can configure the authentication parameters for each downlink port on the access point (AP) using a LAN Port profile in CV-CUE. The communication happens either through a bridged network or transferred using L2 Tunnels.

Use the Authentication Studio to configure RADIUS servers for user authentication and 802.1X authentication and accounting. The 802.1X authentication protocol is a port-based network access control that provides an extra layer of security for both wired and wireless networks.  

The Federal Communications Commission (FCC) mandates that operations in the 6 GHz band require all Access Points (APs) operating at standard power to communicate their geolocation to an Automated Frequency Coordination (AFC) system. The AFC system evaluates this geolocation data to ensure compliance with regulatory requirements by providing the APs with the permissible frequencies and the maximum allowable transmission power for each frequency range at their specific locations. 

Automatic certificate management provides support for retrieving signed x509v3 certificates from a server under the Enrollment over Secure Transport (EST) protocol, described in RFC 7030. The feature provides only EST client capabilities.

This feature detects whether a given EOS image is MLAG ISSU compatible with the currently running version on a switch.

CloudVision Cognitive Unified Edge (CV-CUE) dynamically computes and updates a baseline for normal performance and connectivity of the network. The baseline adjusts as the network behavior changes, eliminating the false positive and false negative alerts associated with thresholds.

Use bearer tokens to provide custom applications or third-party applications, like Ansible, login access to CloudVision. Doing so will allow the application to make configuration changes to EOS devices. Bearer token login can be used with identity providers that issue bearer tokens and have an introspection endpoint. Okta and PingIdentity have been tested for use with CloudVision.

As of EOS 4.17.0F, BFD support has been enhanced with support for configuring BFD within VRFs, improved scalability

BFD for static routes enables monitoring of directly connected next hop reachability using a BFD session. This is

This document describes BFD RFC7130 mode on EOS. RFC7130 defines a mechanism to run BFD protocol over port channels with an independent asynchronous BFD session on every port channel member link. With RFC7130 support, the port channel member link will be removed from forwarding if the BFD session state transitions from UP to DOWN on the member link. This is useful for quickly detecting failures where L1 stays connected but the interface is unable to forward traffic.

BFD Stateful Switchover (SSO) allows for a switchover from an active supervisor to a standby supervisor where BFD

IPv6 support for BFD in ISIS. BFD provides a faster convergence in scaled deployments where using aggressive times

BFD telemetry streaming via OpenConfig implements the gNMI path /bfd/interfaces/interface/peers such that users can get real time telemetry data on BFD sessions configured on the device.

At the beginning of 2014 the the Number Resource Organization announced that the pool of 2 byte BGP AS numbers had

BGP additional paths is an enhancement that allows a BGP router to advertise and receive multiple distinct paths for

BGP Add Path TX allows for a BGP speaker to advertise multiple paths (instead of a single best path) for a prefix towards

EOS BGP implementation normally considers only active routes in RIB for advertisement to its peers. In certain

The aggregate address advertise only feature adds the capability of NOT installing the Null0 route in the FIB/kernel

The "set as path prepend" clause in route map configuration mode has been enhanced with the addition of the “last

The automatic Route Distinguisher (auto RD) feature is designed to simplify customer configuration by automating RD assignment. This feature is supported for the following address families.

ACL based traffic management often requires matching packets’ destination addresses against one or more sets of

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.

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 connect to a router and collect all of the BGP announcements received from the router’s BGP peers. The announcements are sent to the station in the form of BMP Route Monitoring messages generated from path information in the router’s BGP internal tables. A BMP speaker may choose to send either Adj-Rib-In routes, or Loc-Rib routes (as defined by RFC9069 ), or both.

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

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:

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.