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 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>
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 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>
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>
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>
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 reverts commit 0325116a27.
It was causing an issue where a nexthop for IPv6 over an IPv4 session
was always rewritten to an IPv4-mapped IPv6 address even when a valid
IPv6 global address was existing.
Link: https://github.com/FRRouting/frr/issues/15610
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Link-bandwidth is encoded into extended community, not ipv6 extended community.
Thus it's not needed here at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is needed to implement and use larger bandwidths rather than limiting only
to theoretical 34Gbps max bandwidth.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In zebra_interface_nhg_reinstall zebra is checking that the
nhg is a singleton and not a blackhole nhg. This was originally
done with checking that the nexthop is a NEXTHOP_TYPE_IFINDEX,
NEXTHOP_TYPE_IPV4_IFINDEX and NEXTHOP_TYPE_IPV6_IFINDEX. This
was excluding NEXTHOP_TYPE_IPV4 and NEXTHOP_TYPE_IPV6. These
were both possible to be received and maintained from the upper
level protocol for when a route is being recursively resolved.
If we have gotten to this point in zebra_interface_nhg_reinstall
the nexthop group has already been installed at least once
and we *know* that it is actually a valid nexthop. What the
test is really trying to do is ensure that we are not reinstalling
a blackhole nexthop group( Which is not possible to even be
here by the way, but safety first! ). So let's change
to test for that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Change input/output arguments of the RPC callback from lists of
(xpath/value) tuples to YANG data trees.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The define has inheritated from a wrong naming in sr-mpls.
Fix this by renaming ISIS_SRV6_LAN_BACKUP to ISIS_SRV6_ADJ_BACKUP.
Fixes: 2566656a6f ("isisd: Add data structure for SRv6 Adjacency SIDs")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
