zebra: be consistent about v6 nexthops for v4 routes #16103
Merged
Conversation
This file contains 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
|
when does zebra receive a NEXTHOP_TYPE_IPV6 for usage in 5549? |
when ... bgp has regular v6 nexthops to use? I don't think there's any requirement that the v6 addresses be link-locals, is there? we saw this problem with a sonic topology, so using sonic's frr at 8.5.x. |
|
I was mainly asking to gauge whether or not I wanted to ask for a topotest. I don't mind treating both the same, I am trying to figure out what kind of code coverage we want. |
|
CI:rerun |
|
would it be possible to add a small topotest to show that this is working the way we want? |
|
new rfc 8950 |
|
waiting on topo test |
Treat TYPE_IPV6 and TYPE_IPV6_IFINDEX nexthops the same way when processing v4 (RFC 5549) routes. Signed-off-by: Mark Stapp <[email protected]>
mjstapp
force-pushed
the
fix_5549_nhg_type
branch
from
9430c75 to
0221ed2
Compare
|
rebased to current master... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Treat TYPE_IPV6 and TYPE_IPV6_IFINDEX nexthops the same way when processing v4 (RFC 5549) routes. TYPE_IPV6 nexthops were being treated as if the prefix was v6: that causes the zebra 'ip protocol' routemap to fail to match and prevents use of the routemap to set a v4 source address when installing the route. That in turn prevents locally-sourced traffic to the v4 prefix from working correctly.