BGP recursion resulted in a limitation on the point-to-point interface

This article describes the issue of being unable to assign BGP recursion (the use of BGP to solve the BGp next-hop) labels to the link-local address under the forwarding plane.

As the kernel does not support the insertion of labels in the link-local address on the PFE engine , the KRT queue will be stuck with the Operation not supported error message.

For example:

Also, a lot of messages, such as the following, are generated:

Usually, to solve the BGP protocol next-hop, if the protocol next-hop was learnt from IGP in inet6.0 and MPLS inet6.3 (from LDP or setup a LSP), the LSP in inet6.3 will be selected and installed in the forwarding table.

For example:

The protocol next-hop should be solved to the 2001:e68:4005:8000::/49 prefix and lookup from both inet6.0 and inet6.3 in RIB as indirect next-hop; but the inet6.3 next-hop is installed in FIB.

Check the protocol next-hop, which is learnt from IS-IS and LDP; as the route was not from BGP, inet6.3 will not be looked up:

For the sake of comparison, the normal behavior was described above. Check for the issue as follows:

The issue occurs, when the protocol next-hop is resolved twice, which is due to BGP recursion and a day one software issue:

The following outputs can be examined to determine the cause of this message:

As the issue is due the kernel not supporting the assignment of the label to the IPv6 link-local address, assigning the label to the prefix will resolve this issue. Perform the following procedure:

  1. To enable FA or shortcuts in the next-hop of the forwarding path towards the P2P interface, such as sonet , frame relay, and MLPPP, and so on, run the following command:
  2. Replacing the P2P interface with the ethernet interface will work.
  3. Avoid the BGP recursion towards one prefix, as only BGP can lookup the label table.

About the author


Leave a Comment