Only the ovn-controller that runs a BFD session writes its status in the
Southbound BFD table, and only when the state of the session changes.
When that ovn-controller exits with cleanup, it releases the gateway
port binding and deletes its Chassis row, but the status stays as it
was, usually "up". If no other chassis can take the gateway over,
nobody writes the row again. ovn-northd then keeps the route's nexthop
in the ECMP set, and the traffic hashed to it is lost.

During a cleanup exit ("exit" without "--restart", with
ovn-cleanup-on-exit not set to false), ovn-controller now first sets
the status to "down" for each BFD session that it runs, whose status is
"up" or "init", and whose gateway has no other registered chassis: the
port is an l3gateway port, or the HA chassis group of its
chassisredirect binding has no other member whose Chassis row exists.
chassis_name is never written.

The update has its own transaction, committed before the cleanup loop
releases the bindings. New attempts start only in the first second,
and there are at most three: all rows, all rows again after a transient
failure, and after any other failure, such as an SB RBAC rejection,
only the rows whose chassis_name is this chassis. ovn-controller stops
waiting for the Southbound database after 1.5 seconds, so the release
is delayed by at most that much. An INFO message reports the sessions
marked down, and a WARN names those that could not be marked.

A stale "up" still stays when:
- ovn-controller is killed or stopped by a signal, including SIGTERM,
or the host fails;
- "exit --restart" or ovn-cleanup-on-exit=false keep the binding;
- another member of the HA chassis group is registered but dead, or
exits before it has taken the gateway over;
- the HA chassis group has another registered member that cannot
really take the gateway over, as in the per-router groups that
Neutron fills with every gateway chassis.

If a CMS moves a gateway router to another chassis when its chassis
exits, as Neutron does for a router pinned with options:chassis, the
router's routes are removed until the sessions on the new chassis come
up. With SB RBAC, the new chassis can write "up" only once the row's
chassis_name names it.

Reported-at: https://github.com/ovn-org/ovn/issues/320
<https://www.google.com/url?q=https://github.com/ovn-org/ovn/issues/320&source=gmail&ust=1791296560245000&sa=E>
Submitted-at: https://github.com/ovn-org/ovn/pull/332
<https://www.google.com/url?q=https://github.com/ovn-org/ovn/pull/332&source=gmail&ust=1791296560245000&sa=E>
Assisted-by: Claude Opus 5.5 (claude-opus-5-5), Cursor Grok Bot / Ultimum
harness assistants
Signed-off-by: Premysl Kouril <[email protected]>

---
NOTE: commit message only here. Before sending, attach
0002-controller-Mark-BFD-sessions-down-before-exit-cleanu.patch from
/home/ibmko/aiworkspaces/Ultimum/harness-runs/ovn-ml-series-20261005/
or use git send-email on that directory. A matching Gmail Draft was also
saved.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to