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

Prasanna

Leave a Comment