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

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

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.

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.

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. 

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

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.

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 or RSVP-TE colored tunnels.

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

BGP VPN routes today advertise a label by dynamically allocating it from a dynamic label range block without providing the user any control over the label value that is allocated per VRF’s address Family - VPNv4 or VPNv6. This feature allows the user to configure a unique label per VRF’s configured address-family, VPNv4 or VPNv6, thereby allowing the user granular control over the label value advertised with VPN routes exported from a VRF.

The “maximum-paths <m>” (default m=1) configuration that controls BGP’s multipath behavior, is available as a global knob, and not as a peer/peer-group knob today in EOS. When “maximum-paths” CLI is configured with m > 1, BGP starts forming ECMP groups for paths with similar attributes received from all configured neighbors.