TOI Author :: Yaonan Liang

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

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