tests: Fix zebra_vrf_netns topotest

[donaldsharp]

This test is installing configuration in a netns based system and immediately sending mac address additions to the system. Under heavy load interfaces are not fully read in when the neighbor table entry is added causing issues. Modify the test to ensure that the moved interfaces are actually in the appropriate vrf and actually up.

[greptile-apps]

Greptile Summary

This PR adds a run_and_expect polling barrier in setup_module to eliminate a race condition where ip neigh add could fire before zebra had fully registered the netns-moved interfaces, causing RTM_NEWNEIGH to be silently dropped.

• The barrier's ipAddresses check uses the dict form [{"address": OVERLAP_PREFIX}], but test_same_ip_per_vrf() already guards against both dict and string address formats — suggesting the actual FRR JSON format may not be the dict form. If FRR returns string addresses, the 30-second poll will always exhaust itself and setup_module will unconditionally fail, breaking every test in the file.

Confidence Score: 3/5

The race-condition fix is sound in intent, but the ipAddresses format assumption in the wait barrier could cause setup_module to unconditionally fail, making the PR worse than the status quo under any load.

The logic and framing of the fix are correct (poll until interfaces are up, then add neighbours). However, the format used for the ipAddresses field in expected_ifaces may not match what FRR actually emits, and the existing test code already defensively handles two incompatible formats — a signal that this assumption needs explicit verification before the barrier can be trusted.

tests/topotests/zebra_vrf_netns/test_zebra_vrf_netns.py — specifically the expected_ifaces ipAddresses check at line 97

Important Files Changed

Filename	Overview
tests/topotests/zebra_vrf_netns/test_zebra_vrf_netns.py	Adds a run_and_expect barrier in setup_module to fix a race condition between zebra interface registration and ip neigh add; the ipAddresses format assumption in the barrier may not match FRR's actual JSON output, risking unconditional failure.

Sequence Diagram

sequenceDiagram
    participant M as setup_module
    participant FRR as FRR/zebra
    participant K as Kernel (netns)

    M->>K: add_netns(vrf), set_intf_netns(ifname, vrf, up=True)
    M->>FRR: load_frr_config + start_router()
    Note over FRR: zebra registers interfaces<br/>per netns (async)

    loop run_and_expect (count=30, wait=1s) [NEW]
        M->>FRR: show interface vrf all json
        FRR-->>M: interface state
        M->>M: check adminUp, operUp, vrfName, ipAddresses
    end

    alt all interfaces ready
        M->>K: ip netns exec vrf ip neigh add
    else timeout (30 s)
        M->>M: assert fails → setup_module aborts
    end

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: tests/topotests/zebra_vrf_netns/test_zebra_vrf_netns.py
Line: 97

Comment:
**`ipAddresses` format may not match FRR output**

The wait barrier checks `"ipAddresses": [{"address": OVERLAP_PREFIX}]`, which assumes addresses are returned as a list of dicts. However, the already-existing `test_same_ip_per_vrf()` defensively handles *both* dict (`{"address": ...}`) and string (`"10.0.0.1/24"`) forms in its loop — strongly suggesting the actual FRR JSON format is not guaranteed. If `show interface vrf all json` returns addresses as plain strings, `router_json_cmp` will never find a match, the 30-second polling loop will always exhaust itself, and `setup_module` will fail unconditionally (not just under heavy load), breaking every test in this file.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "tests: Fix zebra_vrf_netns topotest" | Re-trigger Greptile}

[donaldsharp]

ci:rerun

[riw777]

looks good