Tag :: BGP

This feature allows a user to configure Autonomous System Number (ASN) in Asdot notation and get the ASN in output of

Adds the ability to revert to previous behavior where BGP and static routes could resolve over BGP aggregates (when

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

Prior to this feature, when the multi-agent routing protocol model was in use, the BGP agents (Bgp and, starting with 4.22.1F, BgpCliHelper) were always running, even if BGP was not configured. With this feature, these two BGP agents do not start up until BGP configuration is created with “router bgp <asn>”. 

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

It is often useful to know on a per AFI/SAFI basis, the number of paths that have been selected from a peer as best paths.

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.

This feature adds support for “Enhanced Route Refresh” capability (RFC7313). An enhanced route refresh is,

Stale routes are learned routes from adjacent BGP neighbors whose neighborship has been interrupted by session instability. This feature adds a mechanism to specify a stale policy route-map for which the stale routes from a gracefully restarting, or depending on the configuration of the feature, a non-gracefully restarting BGP peer will be processed.

This feature enables Flowspec rules to be leaked from one VRF to another. When combined with the ability to apply Flowspec rules from one VRF to interfaces in another VRF, this feature makes it possible to combine rules from different source VRFs into a target VRF, and apply the target VRF’s rules on the interfaces of the source VRFs.

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 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 sending and receiving BGP IPv6 labeled-unicast routes with IPv4-mapped IPv6 next hops. With this feature enabled, when a BGP speaker receives a next hop with IPv4-mapped IPv6 address,

This feature adds support for BGP peering over IPv6 link local addresses. This feature is available with the with the

The BGP-LS extension allows IGPs (OSPF/IS-IS) link state database information to be injected into BGP. This is typically used in deployments where some external component, (like a controller or Path Computation Engine) can do centralized path computations by learning the entire IGP topology through BGP-LS. The controller can then communicate the computed paths based on the BGP-LS updates to the head end device in the network. The mechanism used by the controller to communicate the computed TE paths is outside the scope of this document. Using BGP-LS instead of an IGP peering with the controller to distribute IGP link state information has the following advantages.

In the multi agent routing protocol model, the Bgp agent now supports matching community lists with a logical OR via

The BGP graceful restart mechanism has a limitation that the graceful restart time cannot exceed 4095 seconds per the

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 Adj-Rib-In tables.

BGP Monitoring Protocol (BMP) 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.

The route reflector, as described in RFC 4456, is a router allowed to advertise (reflect) iBGP learned routes to other

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:

Route reflectors are commonly used to distribute routes between BGP peers belonging to the same autonomous system. However, this can lead to non-optimal path selection. The reason for this is that the route reflector chooses the optimal route based on IGP cost from its perspective. This may not be optimal from the perspective of the client as its location may be different from the RR

The BGP graceful restart mechanism has a limitation that the graceful restart time cannot exceed 4095 seconds as per

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.

BGP update wait for convergence feature prevents BGP from programming routes into hardware and advertising routes

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

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.

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.

Remove Private AS Ingress is a feature used for removing and replacing private AS numbers from inbound AS paths, so

The replace remote AS feature allows a provider edge (PE) router to change the autonomous system (AS) number used by a

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

This feature adds support for BGP peering with multiple peers using the same IP address. The router id of those peers is

This change adds a global toggle to BGP communities that allow for community sharing to be enabled/disabled for all

This feature monitors the BGP session status. When a BGP session goes down, traffic originally forwarded to the next hops learned from the downed BGP peer is quickly diverted to a backup path if any, or in the case of ECMP, remaining ECMP members.

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.

This feature implements support for RFC8203/BIS so that users can attach the reason of BGP instance or peer session

EOS currently supports BGP message authentication via the TCP MD5 Signature (TCP MD5) option (RFC 2385) to protect the BGP sessions from spoofed TCP segments. However, research has shown many concerns that the TCP MD5 algorithm is cryptographically ineffective with a just simple keyed hash for authentication.

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. The TOI for BGP UCMP in the ribd

This feature extends the BGP Layer 3 VPN Import/Export and VRF Route Leaking functionality to “default” VRF.

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 Adj-Rib-In tables. A BMP speaker may choose to send either pre-policy routes, post-policy routes, or both.

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.

Class based forwarding (CBF) is a means for steering network traffic into colored tunnels based on one or more fields of the ingress traffic. Rephrased, CBF is forwarding of traffic based on “classes” which are derived from fields in the ingress packet headers and policies provisioned on the router.

Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an “SR Policy”. Class Based Forwarding (CBF) for SR-TE is a means for steering IP traffic into an SR Policy based on the ingress DSCP values. This mechanism is described in the section on Per-Flow Steering in the Segment Routing Policy Architecture Internet draft.

Class Based Forwarding (CBF) is a means for steering IP traffic into colored tunnels based on the ingress DSCP values. CBF may be used with SR-TE Policy, RSVP-TE or Flex-Algo colored tunnels.

This feature provides the ability to track the reason why a BGP path is excluded from the BGP best path selection