tests: Check PIM Register/-Stop handling in pim_igmp_vrf topotest

[gromit1811]

Check whether PIM Register messages are generated towards the RP and answered by Register-Stop from the RP. To force generation of PIM Register, move the DR role from the RP on R11/12 to R1 (otherwise, with DR and RP being the same routers, no Register messages would be needed). The RPs need to generate Register-Stop because there are no other group members besides the ones on the path whether the traffic is received from on the RPs.

Useful as a regression test for #18216 even though the situation there was slightly different: In that case, the RP was the VRF router and its Register-Stop messages ended up the in the wrong VRF. In our case, the DRs are the VRF routers and the Register messages would end up in the wrong VRF. But our check works for both cases: If we don't receive Register-Stop messages, either the Register or the Register-Stop messages got lost and will trigger an assertion failure.

Note: The last commit is the actual change to check PIM Register. The other commits are just minor cleanup/bugfix changes to the original topotest.

[Jafaral]

style suggestions:
https://github.com/FRRouting/frr/pull/18329/checks?check_run_id=38321233157

[gromit1811]

Converted to draft while working on IPv6 support

[gromit1811]

Added IPv6 support. Open issues, to be fixed before removing "draft" status:

• Lots of duplicated code, refactor
• Rebase to current master
• Register/Register-Stop check sometimes fails with IPv6. Looks like a pim6d issue rather than a test case bug. Analyze
• We need explicit vrf red and vrf blue statements in r1/pim*d.conf to avoid the following assertion failure: 2025/03/10 17:02:12 PIM: lib/routing_nb_config.c:51: routing_control_plane_protocols_control_plane_protocol_create(): assertion (vrf) failed. An assertion failure is never the correct way to handle config errors, check what the actual problem is.

[Jafaral]

Thank you @gromit1811

[Jafaral]

While I agree that we should fix this. A more permanent fix for this test is to actually reflect the interface vrf assignment below. I never liked relying on side effects from the kernel to map interfaces to vrfs because the configs don't really tell us much about that. Here is the the vrf info from the test file.

        "ip link set dev r1-eth0 vrf blue up",
        "ip link set dev r1-eth1 vrf blue up",
        "ip link set dev r1-eth2 vrf red up",
        "ip link set dev r1-eth3 vrf red up",

So for interfaces below you would have

interface r1-eth0 vrf blue

That is the correct config that will behave exactly as intended and also reflects the mapping for interfaces to vrfs.

[gromit1811]

That's also how I'd write it if I had to write it from scratch.
But the vrf ... / exit-vrf are still required to avoid the assertion failure.
BTW, IIRC, I've seen cases where I had the "interface XXX vrf YYY" in the config and then at runtime, "show run" listed the interfaces but stripped the vrf options again. Don't remember the exact circumstances, but it that's still the case, that probably should get fixed as well...

[Jafaral]

That is probably a race condition. The kernel sends us an new interface message say new eth0. If there is no vrf binding in the kernel for that interface, then it will show without a vrf in the configs, or if the message arrived late.

[gromit1811]

Just checked this again. It even happens when I interactively configure this using vtysh, so it's unlikely to be a race condition (I don't type that fast 😉)

For instance with FRR from git master 361f80a plus this PR, i.e. post-vrf-fix. System VRF config:

504: ovl2336: <NOARP,MASTER,UP,LOWER_UP> mtu 65575 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:49:4a:dd:27:aa brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 1280 maxmtu 65575 
    vrf table 2336 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
root@debian:~/frr# ip -d l sh dev veth0a
512: veth0a@veth0b: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master ovl2336 state UP mode DEFAULT group default qlen 1000
    link/ether 12:36:87:5a:e2:f2 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535 
    veth 
    vrf_slave table 2336 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 

-> VRF ovl2336 plus interface veth0a in this VRF.

Trying to configure these interactively in FRR with initial config empty:

debian# show run
Building configuration...

Current configuration:
!
frr version 10.4-dev-my-manual-build
frr defaults traditional
hostname debian
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
end
debian# conf
debian(config)# vrf ovl2336 
debian(config-vrf)# exit-vrf 
debian(config)# interface veth0a vrf ovl2336 
debian(config-if)# ip pim
debian(config-if)# exit
debian(config)# router pim vrf ovl2336 
debian(config-pim)# join-prune-interval 5
debian(config-pim)# end
debian# show run
Building configuration...

Current configuration:
!
frr version 10.4-dev-my-manual-build
frr defaults traditional
hostname debian
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
vrf ovl2336
exit-vrf
!
interface veth0a
 ip pim
exit
!
router pim
 join-prune-interval 5
exit
!
end

-> All my config commands are there, but all vrf ovl2336 arguments have been stripped. Am I doing something wrong? Am I expecting too much?

[gromit1811]

Should I open yet another issue for that? And/or add a check to this topotest?

[Jafaral]

Some minor comments. Sorry, for the incremental review, finding time here and there!

[Jafaral]

FYI, fields that you don't care about can be omitted completely, and that would simplify the test and make it a tiny bit faster :)

[gromit1811]

Without fully understanding what this test is trying to test, I didn't want to deviate too much from the original and just did things the same way as in IPv4.

[Jafaral]

new format suggestion as well.

[Jafaral]

@gromit1811 if you rebase , you no longer need to do the funny vrf business. Fixed on master.

[gromit1811]

Rebased to get the vrf fix.

Added yet another test case to check interface/router removal. PIM interface removal seems to work properly, but completely disabling PIM (e.g. causing the pimreg interface to disappear) doesn't. Also, "no router pim vrf XXX" doesn't actually remove the PIM section from config, "show run" afterwards still shows it.

I guess that's not expected behavior, right? I'll open an issue for that unless somebody tells me it's OK like this.

[Jafaral]

Rebased to get the vrf fix.

Added yet another test case to check interface/router removal. PIM interface removal seems to work properly, but completely disabling PIM (e.g. causing the pimreg interface to disappear) doesn't. Also, "no router pim vrf XXX" doesn't actually remove the PIM section from config, "show run" afterwards still shows it.

I guess that's not expected behavior, right? I'll open an issue for that unless somebody tells me it's OK like this.

Yeah, that should probably be fixed.

[gromit1811]

Yeah, that should probably be fixed.

Not fixed, but at least reported: #18537

[gromit1811]

Pushed an update with some pytest mark fixes and a modified join/MC stream start order: Join first, then start MC stream 1 second later (before: start MC stream and then immediately join). With this, #18445 now also occurs for IPv4 ☹️