The aspath value has no need to be controlled. Unset the bgp capability
to send aspath information to zebra.

Signed-off-by: Philippe Guibert <[email protected]>

Use experimental AS values to play the test.
Add BGP peering on CEs, and use the default-originate functionality on
each PE facing CPEs.

Signed-off-by: Philippe Guibert <[email protected]>

…3vpn

Add a BGP update in CE1 for redistribution. The expectation is that this
BGP update will be leaked to the L3VPN. Reversely, if the locator is
unset, the L3VPN prefix will be invalidated.

Signed-off-by: Philippe Guibert <[email protected]>

This test ensures route redistribution across an srv6 VPN network
is well taken into account.

Signed-off-by: Jonathan Voss <[email protected]>
Signed-off-by: Philippe Guibert <[email protected]>

The resulting VPN prefix of a BGP route from a L3VPN in an srv6 setup
is not advertised to remote devices.

> r1# show bgp ipv6 vpn
> BGP table version is 2, local router ID is 1.1.1.1, vrf id 0
> Default local pref 100, local AS 65500
> Status codes:  s suppressed, d damped, h history, u unsorted, * valid, > best, = multipath,
>                i internal, r RIB-failure, S Stale, R Removed
> Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
> Origin codes:  i - IGP, e - EGP, ? - incomplete
> RPKI validation codes: V valid, I invalid, N Not found
>
>      Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 1:10
>      2011:1::/64      2001:1::2@6<             0    100      0 i
>     UN=2001:1::2 EC{99:99} label=4096 sid=2001:db8:1:1:: sid_structure=[40,24,8,0] type=bgp, subtype=5

What happens is that the SID of this BGP update is used as nexthop.
Consequently, the prefix is not valid because of nexthop unreachable.
obviously the locator prefix is not reachable in that L3VRF, and the
real nexthop 2001:1::2 should be used.

> r1# show bgp vrf vrf10 nexthop  detail
> Current BGP nexthop cache:
>  2001:db8:1:1:100:: invalid, #paths 1
>   Last update: Fri Mar 14 21:18:59 2025
>   Paths:
>     2/3 2011:1::/64 RD 1:10 VRF default flags 0x4000

Fix this by considering the SID of a given BGP update, only if the SID
is not ours.

Signed-off-by: Philippe Guibert <[email protected]>

When detaching the locator from the main BGP instance, the used SIDs
and locators are removed from the srv6 per-afi or per-vrf contects.
Under those conditions, it is not possible to attempt to export new
VPN updates. Do invalidate the nexthop for leaking.

Restrict the control for exported VPN prefixes and not for unicast
imported prefixes.

Signed-off-by: Philippe Guibert <[email protected]>

When exporting a VPN SRv6 route, the path may not be considered valid if
the nexthop is not valid. This is the case when the 'nexthop vpn export'
command is used. The below example illustrates that the VPN path to
2001:1::/64 is not selected, as the expected nexthop to find in vrf10 is
the one configured:

> # show running-config
> router bgp 1 vrf vrf10
>  address-family ipv6 unicast
>   nexthop vpn export 2001::1

> # show bgp ipv6 vpn
> [..]
> Route Distinguisher: 1:10
>      2001:1::/64      2001::1@4                0             0 65001 i
>     UN=2001::1 EC{99:99} label=16 sid=2001:db8:1:1:: sid_structure=[40,24,16,0] type=bgp, subtype=5

The analysis indicates that the 2001::1 nexthop is considered.

> 2025/03/20 21:47:53.751853 BGP: [RD1WY-YE9EC] leak_update: entry: leak-to=VRF default, p=2001:1::/64, type=10, sub_type=0
> 2025/03/20 21:47:53.751855 BGP: [VWNP2-DNMFV] Found existing bnc 2001::1/128(0)(VRF vrf10) flags 0x82 ifindex 0 #paths 2 peer 0x0, resolved prefix UNK prefix
> 2025/03/20 21:47:53.751856 BGP: [VWC2R-4REXZ] leak_update_nexthop_valid: 2001:1::/64 nexthop is not valid (in VRF vrf10)
> 2025/03/20 21:47:53.751857 BGP: [HX87B-ZXWX9] leak_update: ->VRF default: 2001:1::/64: Found route, no change

Actually, to check the nexthop validity, only the source path in the VRF
has the correct nexthop. Fix this by reusing the source path information
instead of the current one.

> 2025/03/20 22:43:51.703521 BGP: [RD1WY-YE9EC] leak_update: entry: leak-to=VRF default, p=2001:1::/64, type=10, sub_type=0
> 2025/03/20 22:43:51.703523 BGP: [VWNP2-DNMFV] Found existing bnc fe80::b812:37ff:fe13:d441/128(0)(VRF vrf10) flags 0x87 ifindex 0 #paths 2 peer 0x0, resolved prefix fe80::/64
> 2025/03/20 22:43:51.703525 BGP: [VWC2R-4REXZ] leak_update_nexthop_valid: 2001:1::/64 nexthop is valid (in VRF vrf10)
> 2025/03/20 22:43:51.703526 BGP: [HX87B-ZXWX9] leak_update: ->VRF default: 2001:1::/64: Found route, no change

Signed-off-by: Philippe Guibert <[email protected]>

When srv6 is disabled due to misconfiguration, exported VPN prefixes
are invalidated, except for the ones that have their nexthop modified
with the 'nexthop vpn export' command. The previous commit also
invalidates those vpn prefixes.

Apply the changes to the test by not considering some prefixes as
selected. Enforce the expected route count.

Signed-off-by: Philippe Guibert <[email protected]>

Assuming attr is null, a dereference can happen in the function
make_prefix(). Add the protection over attr before accessing the
variable.

Signed-off-by: Philippe Guibert <[email protected]>