Page MenuHomeVyOS Platform

static: a route with a blackhole and a next-hop at the same distance is accepted, then rejected by FRR
Open, NormalPublicBUG

Description

protocols static accepts a route that has both a blackhole (or reject) and a next-hop / interface at the same distance (the default distance is 1 for both). FRR's staticd rejects that route ("Route cannot have blackhole and non-blackhole nexthops simultaneously"), so the commit fails inside frr-reload instead of in verify(). What happens next depends on the train.

1.5.1 (FRR 10.5.2): the commit jams the FRR configuration manager.

  • staticd fails validation and drops its transaction; mgmtd keeps a lock on the running datastore for a transaction that never completes. The journal fills with mgmtd: Locking for DS 1 failed, Err: 'Lock already taken on datastore running ...' (about 10 per second).
  • Every commit, the commit-confirm revert and op-mode restart bgp are refused for 600 s, until mgmtd's txn_cfg_timeout: ERROR: Backend timeout validating txn-id ... aborting commit; then vyos-configd replies SUCCESS although the route was not applied.
  • A further commit that touches protocols static jams again, every 10 minutes, for hours (12 timeouts in 110 minutes in one run, still jammed when the run ended).
  • systemctl restart frr during the jam makes it worse: frr.conf holds both nexthops, FRR refuses to load it, and all static routes are lost. A reboot clears it.

rolling (FRR 10.6.1): the commit fails after five frr-reload retries with the staticd message ("Commit failed"). A second commit in the same session then reports nothing and vyos keeps the route as committed although FRR does not have it (frrender's change cache, T9442).

Reproduced on 1.5.1 and stock rolling:

set protocols static route 0.0.0.0/0 blackhole
commit
set protocols static route 0.0.0.0/0 next-hop 192.0.2.1
commit

Replacing the blackhole with the next-hop in one commit (delete + set) works on both; only a configuration that keeps both at the same distance fails. Different distances (for example blackhole distance 200 and next-hop ... distance 10) are valid and FRR accepts them.

Possible fix. A check in protocols_static.py verify(): a blackhole or reject route at the same distance as a next-hop or interface on the same prefix raises a ConfigError naming the prefix, the next-hop and the distance; for route, route6, VRF static routes and table <n> routes.

Details

Version
1.5.1, 1.5-rolling-20261011
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)