Hi Dumitru, Thanks, that helps clarify the API direction. Defaults on the logical switch look like a better fit for identifying the source context of each attachment.
I have a local, unsent v2 draft using source_port/source_ip on Load_Balancer_Health_Check. It requires the LB attachments to resolve to one source context and rejects unrelated attachments. I'll revisit that around your per-switch suggestion before posting the next version. For router-attached load balancers, would you expect defaults on Logical_Router as well, or selection of a source switch? Also, if the same LB is attached to two switches and a backend is reachable from only one source context, should backend eligibility differ between those attachments? That affects how we associate Service_Monitor results with backend selection. The defaults would also need to preserve explicit ip_port_mappings and support source-address selection for both IPv4 and IPv6. On neighbor withdrawal, you're right that the existing synchronization path already retries failures while an interface remains monitored. The gap I reproduced is removal of the monitor itself: its previous desired state is discarded, and that interface is no longer visited by synchronization. The regression removes dynamic-routing-vni while leaving the Linux devices present. The old controller leaves the FDB announcement behind. With the fix, the tests verify withdrawal of the owned FDB, IPv4 and IPv6 entries in both Southbound monitoring modes. They also exercise failed-withdrawal retry and cancellation when an entry becomes desired again. I have separated the removed-monitor cleanup and neighbor-dump error handling into independent commits with focused regression tests. I'll keep those separate within the series. Regards, Gavin _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
