TOI Author

The feature adds cross-VRF support for dynamic prefix-list.

Dynamic prefix-list policy construct is similar to the traditional IP and IPv6 prefix-list, except that they have an additional state associated. This state associated with the dynamic prefix-lists, is determined on the basis of the route entries in FIB, and hence as and when the FIB changes, the state also changes dynamically. This state determines the dynamic prefix-list behavior, when used in route-map/RCF match clauses or route injection.

This feature provides support for advertising VPN-IPv4 Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC8950. Extended Next Hop Encoding capability can be supported for IPv4 unicast, IPv4 Labeled Unicast, and IPv4 VPN address and sub-address families (1/1, 1/4, 1/128 respectively) per RFC. The Extended Next Hop support for IPv4 unicast is described in RFC 5549 .

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 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.

Normally BGP allocates local labels and installs LFIB entries for all received IPv4/IPv6 Labeled Unicast (LU) routes in anticipation of readvertising them with nexthop-self. However, some deployments don’t require nexthop-self with LU routes, so LFIB hardware resources are needlessly allocated, which can present an issue in large scale LU deployments. 

This feature limits the maximum number of routes that BGP can advertise to a peer. When the maximum

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

The BGP Replace AS Path feature provides the capability to customize the AS PATH attribute for prefixes that are