WIP: fix(#3214): tablemanager use link-local nexthop if global is unspecified #3215
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work In Progress. Showcasing a quick fix for #3214.
When BIRD peers using only a link-local address it supplies this in a 32byte next-hop as
:: LL(i.e.:: fe80::ade0). FRR supports this format as well (see this issue).Though not entirely related, there's a draft RFC about this here.
This PR adds logic to the table manager that: if the nexthop is unspecified and the LinkLocalNexthop is valid and actually a local-link, then uses the LinkLocalNextHop for the path.
Some questions and statements floating in my mind while working on this:
A new RFC Draft for LinkLocal only capable peers state that a peer that advertises ONLY a LinkLocal Nexthop MUST encode this in 16 bytes nexthop.
This would mean that while decoding the nexthop in bgp.go the
BGP_ATTR_NHLEN_IPV6_GLOBALactually meansBGP_ATTR_NHLEN_IPV6_GLOBAL_OR_LINKLOCAL.This might also - at least for me - require a concrete definition for
PathAttributeMpReachNLRI.NextHopIn bgp.go. Is the field NextHop only Global or can it also be the LinkLocal? What is the LinkLocalNextHop field in that case.2025-10-31: path.go derives whether its local from the fact it uses a LocalAddress vs Address of a peer. This would argue in favor of NextHop being global address only.