Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bgpd: fix ipv4-mapped ipv6 use cases #17019

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

louis-6wind
Copy link
Contributor

@louis-6wind louis-6wind commented Oct 7, 2024

Re-apply what was reverted in #16615 because of the #16572 regression.

This new pull-requests fixes some ipv4-mapped ipv6 use cases but does not cause this time the #16572 regression.

The reverted pull-requests #16439, #15614 and #15368 are reapplied here with the following changes:

  • Fix from Donatas bgpd: Do not use mapped IPv4/IPv6 addresses for unnumbered peering #16582 has been applied and merged into commit "bgpd, tests: set ipv4-mapped ipv6 for ipv4 on ipv6". The fix was correct to fix issue.
  • The check for ipv4-mapped ipv6 global nexthop in f1b8364 has been removed. The
    ipv4-mapped ipv6 global nexthop was the cause of the regression with unnumbered peering.
  • Fixup commits that addressed previous commit issues have been merged into the initial commits for improved clarity.

@frrbot frrbot bot added bgp bugfix tests Topotests, make check, etc labels Oct 7, 2024
@louis-6wind louis-6wind marked this pull request as draft October 7, 2024 11:14
@riw777 riw777 self-requested a review October 8, 2024 15:25
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

louis-6wind and others added 13 commits October 11, 2024 10:28
Move common checks outside of the loop.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Reduce bgp_interface_address_add indentation

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Log new IPv6 global address in bgp_interface_address_add

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
bgpd keeps on advertising IPv6 prefixes with a IPv6 link-local nexthop
after a valid IPv6 global appears.

At bgpd startup, the IPv6 global is announced by zebra after the
link-local. Only the link-local is advertised. Clearing the BGP sessions
make the global to to be announced.

Update the nexthops with the global IPv6 when available.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This test uses the connected ipv4 mapped ipv6 prefix
to resolve the received BGP routes.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: François Dumontet <francois.dumontet@6wind.com>
Add bgp_nexthop_mp_ipv4_6 topotest to test to nexhop value with
MP-BGP IPv4 and IPv6 on IPv4 peering. The test has route-reflector,
route-server, iBGP and eBGP peers.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Move common checks outside of the loop.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When the IPv6 global is removed on an interface towards a peer, the
IPv6 nexthop global that is sent is a IPv4-mapped IPv6 address. It
should be the link-local.

At removal, replace the global by the next global address or the
link-local as last resort.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When a peer has no IPv6 global address to send as nexthop, it sends the
IPv6 link-local instead as global. "show bgp ipv6 json" displays the
same address in global and link-local scopes.

> "nexthops": [
>   {
>     "ip": "fe80::a495:38ff:fea6:6ea3",
>     "afi": "ipv6",
>     "scope": "global",
>     "used": true
>   },
>   {
>     "ip": "fe80::a495:38ff:fea6:6ea3",
>     "afi": "ipv6",
>     "scope": "link-local"
>   }
> ]

However, "used" key is set on the global nexthop but not in link-local.
It is correct but it makes difficult to test JSON to expect the usage of
a link-local. The contrary is also correct.

Set "used" key on the link-local nexhop instead to facilitate the tests.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The code was expected that no IPv6 global address was present but the
previous commit was replacing nexthop.v6global by the link-local address
instead of un-setting it in case of removal of the IPv6 global.

Set also ipv4-mapped ipv6 address as nexthop when a link-local is found
and it is an ipv4 prefix over ipv6 nexthop.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When a peer sends an IPv4-mapped IPv6 global and a IPv6 link-local
nexthop, prefer the link-local unless a route-map tells to use the
global.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Replace IPv4-mapped IPv6 at update forwarding because the peer may not
be able to create a route with the IPv4-mapped IPv6.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Test that a IPv4-mapped IPv6 is sent from a peer that has no global IPv6
address.

Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
@louis-6wind louis-6wind marked this pull request as ready for review October 11, 2024 12:27
@louis-6wind
Copy link
Contributor Author

@ton31337 please review this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants