Hello,

On BIRD 3.3.2 a static route with an interface or neighbour next hop
stops reacting to interface state after the first `birdc configure`. It
is frozen at whatever state that reconfiguration evaluated and never
moves again -- it neither withdraws when the interface goes down nor
returns when it comes back -- until `birdc restart <proto>`.
`configure soft` and `configure undo` behave the same, and
`birdc reload` does not repair it. `check link` makes no difference
either way.

The attached reproducer, bird-repro-static-iface-tracking.sh, needs only
root, iproute2 and an installed bird3, cleans up after itself, and marks
any step whose result differs from expectation. On Debian's bird3
3.3.2-1~bpo13+1:

BIRD version 3.3.2
  fresh: iface up          route=yes want=yes
  fresh: iface down     route=no want=no
  -- birdc configure, configuration unchanged --
  after cfg: iface up       route=yes want=yes
  after cfg: iface down  route=yes want=no  <-- MISMATCH
  -- birdc restart s1 --
  -- birdc configure, taken while the iface is DOWN --
  still down                route=no want=no
  then: iface up         route=no want=yes  <-- MISMATCH
  then: iface down     route=no want=no

The same script on the same machine, with BIRD= and BIRDC= pointing at
Debian's bird2 2.17.5-0+deb13u1:

BIRD version 2.17.5
  fresh: iface up           route=yes want=yes
  fresh: iface down      route=no want=no
  fresh: iface up           route=yes want=yes

  -- birdc configure, configuration unchanged --
  after cfg: iface up       route=yes want=yes
  after cfg: iface down  route=no want=no
  after cfg: iface up      route=yes want=yes

  -- birdc restart s1 --
  after restart: down    route=no want=no

  -- birdc configure, taken while the iface is DOWN --
  still down                 route=no want=no
  then: iface up          route=yes want=yes
  then: iface down      route=no want=no

Where it seems to come from: the dependency is the route chain hanging
off the neighbour-cache entry. `static_reconfigure_rte()` calls
`static_add_rte()`, which links the new route into `n->data`, and then
`static_reset_rte()`, which sets `r2->neigh->data = NULL`.
`neigh_find()` returns the same cached neighbour for an unchanged next
hop, so the reset clears the chain the add has just built, and
`static_neigh_notify()` then walks an empty list.

That came in with commit eb6918e4db57b7e5fabc531963deb46313289d80
("Neighbor cache: fixed neighbor referencing"), which replaced a plain
`r2->neigh = NULL;` in `static_reset_rte` with a block that also clears
the shared `r2->neigh->data`, and added the matching `neigh_link()` in
`static_add_rte`. The commit is not reachable from master, no v2 tag
contains it, and the earliest release tag that does is v3.0.0 -- which
matches bird2 passing the run above.

Thanks,