On 10/13/26 9:11 PM, Gavin McKee wrote: > Hi Dumitru, > Hi Gavin,
> 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 I'd say we would need defaults on Logical_Router records too. > 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 I guess so, right? In theory the backends reachable via different logical switches/routers might be different workloads that happen to have the same IP (in different logical networks). > 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. Ack, I see. > I'll keep those separate within the series. > If you want to prioritize getting these in, you could also just post the fixes as a separate series. > Regards, > Gavin Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
