bgpd: fix ipv4-mapped ipv6 use cases #17019
Draft
+3,150
−101
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
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>
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>
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>
Test ipv6 global removal in bgp_nexthop_mp_ipv4_6 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>
Before the patch-set, ce1 was sending an IPv6 Link-local as global and link-local nexthop to pe1. Set bgp_vrf_leaking_5549_routes in accordance with the previous fixes. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When IPv6 prefixes are sent over an IPv4 session, the UPDATE is sent
with a link-local nexthop as global nexthop instead of a IPv4-mapped
IPv6 address. If the peer interface has no IPv6 address, routes are
not installed.
Seen with bgp_nexthop_mp_ipv4_6 topotests on step2:
> root@r2:/# vtysh -c 'show bgp ipv6 fd00:100::/64 json' | jq .
> {
> "prefix": "fd00:100::/64",
> "paths": [
> {
> "nexthops": [
> {
> "ip": "fe80::449a:f8ff:fe67:1f93",
> "hostname": "r1",
> "afi": "ipv6",
> "scope": "global",
> "metric": 0,
> "accessible": true
> },
> {
> "ip": "fe80::449a:f8ff:fe67:1f93",
> "hostname": "r1",
> "afi": "ipv6",
> "scope": "link-local",
> "accessible": true,
> "used": true
> }
> ],
> }
> ]
> }
Now:
> root@r2:/# vtysh -c 'show bgp ipv6 fd00:100::/64 json' | jq .
> {
> "prefix": "fd00:100::/64",
> "paths": [
> "nexthops": [
> {
> "ip": "::ffff:172.16.0.1",
> "hostname": "r1",
> "afi": "ipv6",
> "scope": "global",
> "metric": 0,
> "accessible": true
> },
> {
> "ip": "fe80::3842:28ff:fe90:f815",
> "hostname": "r1",
> "afi": "ipv6",
> "scope": "link-local",
> "accessible": true,
> "used": true
> }
> ],
> }
> ]
> }
Note that the link-local is still preferred over the global address.
Fixes: 25995695f5 ("bgpd: set ipv4-mapped ipv6 for ipv4 with ipv6 nexthop")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix nexthop resolution of ipv4-mapped ipv6 nexthop addresses. Fixes: 5dd731a ("bgpd: prefer link-local to a ipv4-mapped ipv6 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>
Before:
```
router bgp 4283023031
bgp router-id 100.83.23.31
neighbor leafs peer-group
neighbor leafs remote-as external
neighbor eth1 interface peer-group leafs
!
address-family ipv4 unicast
network 100.83.23.31/32
exit-address-family
!
exit
```
```
leaf2# show ip bgp 100.83.23.31/32
…
4283023031
::ffff:6453:171f (inaccessible) from node31-h23-osl3(swp32) (100.83.23.31)
(fe80::a6bf:1ff:fe2d:689a) (used)
Origin IGP, metric 0, invalid, external
Last update: Tue Aug 13 08:36:46 2024
```
Fixes: fc5a738 ("bgpd: set ipv4-mapped ipv6 for ipv4 with ipv6 nexthop")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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.
Re-apply what was reverted in #16587
Issue #16572 will be fixed