tests: Add topotest to validate the sharing of an SRv6 locator among multiple protocols

[cscarpitta]

PR #15604 introduces the SRv6 SID Manager, a zebra component responsible for SID allocation/management. The SRv6 SID Manager exposes a SID allocation/release APIs, allowing clients to request and release an SRv6 SID. The SID manager allows the SRv6 Locator to be shared among many clients such as IS-IS, BGP and others.

This PR adds a new topotest to validate the sharing of an SRv6 locator among multiple clients

It sets up a mixed BGP and IS-IS topology and verifies that the locator can be shared by BGP and IS-IS, and that both daemons are able to request and obtain SIDs from the same locator.

[riw777]

looks good

[riw777]

looks like the docker build is failing ...

[dmytroshytyi]

Hello,

Generally SRv6 uSID test looks ok. 1 minor comment.

Resume: This PR demonstrates the advantage to use same SRv6 locator for BGP SRv6 and ISIS SRv6 on the same node.

I retain the next from this PR:

1. BGP SRv6 session is established between rt1 and rt6. 
2. ISIS SRv6 on rt1,rt2,rt3,rt4,rt5,rt6.
3. Same locator shared between BGP SRv6 and ISIS SRv6 

I assume that the failed status of PR is related to the fact this PR waits before BGP + ISIS extension are going to be merged? Please confirm if the case or provide a fix if there is an issue.

[dmytroshytyi]

Minor comment: Why this func value? Is there is anything blocking us to use 65324? The value 65024 might be "out-of-range" for default value range of func (starting from "0xff00" if I remember correctly) particular format uncompressed-f4024? It might be a good thing to avoid confusion in case when user switches the uncompressed-f4024 and consequently there is a risk that related func are failed to allocate?

[dmytroshytyi]

Tu further evolve this point: user should be notified directly if (s)he types the value of out-of-range func.

[riw777]

ci:rerun

[riw777]

still failing just on docker ... ci:rerun

[riw777]

ci:rerun

[riw777]

I don't know if this is a real problem or not:

self = <lib.topotest.Router object at 0x7f3579180e20>
p = <Popen: returncode: 2 args: ['/usr/bin/nsenter', '--mount=/proc/116/ns/mnt',...>
c = ['/usr/sbin/ip', 'link', 'add', 'vrf1', 'type', 'vrf', ...]
ac = ['/usr/bin/nsenter', '--mount=/proc/116/ns/mnt', '--net=/proc/116/ns/net', '--uts=/proc/116/ns/uts', '-F', '/usr/sbin/ip', ...]
o = '', e = 'Error: Unknown device type.\n', raises = True, warn = True

Can y'all look at this to see what's going on?

[dmytroshytyi]

Hi @riw777,

I don't know if this is a real problem or not:

self = <lib.topotest.Router object at 0x7f3579180e20>
p = <Popen: returncode: 2 args: ['/usr/bin/nsenter', '--mount=/proc/116/ns/mnt',...>
c = ['/usr/sbin/ip', 'link', 'add', 'vrf1', 'type', 'vrf', ...]
ac = ['/usr/bin/nsenter', '--mount=/proc/116/ns/mnt', '--net=/proc/116/ns/net', '--uts=/proc/116/ns/uts', '-F', '/usr/sbin/ip', ...]
o = '', e = 'Error: Unknown device type.\n', raises = True, warn = True

Can y'all look at this to see what's going on?

After brief check, it looks like this error starts in the bfd_vrflite_topo1 context.

The command itself looks ok ('/usr/sbin/ip', 'link', 'add', 'vrf1', 'type', 'vrf', 'table', '10')

The error might be seen in case, when vrf module is not inserted into the kernel.

[riw777]

ci:rerun
current failure isn't related

[riw777]

ci:rerun

[cscarpitta]

ci:rerun