Skip to content

[bgp] Use FRR route check instead of kernel ip route in test_bgp_router_id#23351

Open
rustiqly wants to merge 1 commit intosonic-net:masterfrom
rustiqly:fix/bgp-router-id-fullscale
Open

[bgp] Use FRR route check instead of kernel ip route in test_bgp_router_id#23351
rustiqly wants to merge 1 commit intosonic-net:masterfrom
rustiqly:fix/bgp-router-id-fullscale

Conversation

@rustiqly
Copy link
Copy Markdown
Contributor

Description

On full-scale topologies, the kernel ip route show command returns empty output due to a known issue (sonic-net/sonic-buildimage#24537). This causes check_default_route() (which uses get_ip_route_infoip route list) to fail with 'Default route not ready' in restart_bgp().

Fix

Add a local helper _check_default_route_via_frr() that uses vtysh -c 'show ip route 0.0.0.0/0' (FRR) instead of the kernel ip route command. This bypasses the kernel route table limitation on full-scale topologies while still validating that a default route with a valid nexthop exists.

Changes

  • tests/bgp/test_bgp_router_id.py: Add _check_default_route_via_frr() helper and use it in restart_bgp()

Fixes: #23168

…er_id

On full-scale topologies, the kernel 'ip route show' command returns
empty output due to a known issue (sonic-net/sonic-buildimage#24537).
This causes check_default_route() to fail with 'Default route not
ready' in restart_bgp().

Fix: Add a local helper _check_default_route_via_frr() that uses
'vtysh -c show ip route 0.0.0.0/0' (FRR) instead of kernel ip route,
and use it in restart_bgp(). This bypasses the kernel route table
limitation on full-scale topologies.

Fixes: sonic-net#23168

Signed-off-by: Rustiqly <rustiqly@users.noreply.github.com>
@mssonicbld
Copy link
Copy Markdown
Collaborator

/azp run

@rustiqly
Copy link
Copy Markdown
Contributor Author

@copilot review

@yijingyan2
Copy link
Copy Markdown

/azp run

@azure-pipelines
Copy link
Copy Markdown

Azure Pipelines successfully started running 1 pipeline(s).

@rustiqly
Copy link
Copy Markdown
Contributor Author

CI t1-lag failure is unrelated to this PR — the failing test is bgp/test_bgp_aggregate_address.py (2 failures), not test_bgp_router_id.py. t0 and t2 passed. Requesting re-run.

/azp run

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: test_bgp_router_id fails default route check on full-scale topologies

3 participants