On 1/27/22 11:59, Brendan Doyle wrote: > Hi Daniel , > > Thanks for the response, I'm not sure the patch in [1] would help in > this case. > The stale binding is of a VIP in the underlay learned through an OVN > physical > network port. The VIP is hosted by a number of "Management" nodes, the OVN > Gateway is hosted on some "Compute" nodes. If the VIP moves, GARPs are > generated > and we do want OVN to listen to these and update the MAC_binding table with > the MAC of the Management node that now hosts the VIP. > > The problem here was that there was a power cycle, after which the > Management > nodes powered up first. The VIP moved and GARPs are sent but as the > Compute Nodes/ > OVN configuration on the Compute nodes were not up, the GARPs were > missed. And as > the MAC_binding entries are not aged, it ended up with the wrong MAC for > the VIP. > The solution was to do: > |/ovn-sbctl/||||/--all destroy Mac_Binding/| > > > I've read the discussion in [0] and it seems to me that OVN should have > an aging > mechanism for entries in the MAC_binding table. >
Hi Brendan, I'm not sure it's still relevant but, just in case, OVN supports a basic form of MAC_binding aging (disabled by default, can be enabled per router) since 22.09.0: https://github.com/ovn-org/ovn/commit/1a947dd3073628d2f2655f46ee7d3db62ed15b55 Regards, Dumitru > Brendan > > > On 26/01/2022 13:28, Daniel Alvarez Sanchez wrote: >> Hey Brendan, >> >> On Wed, Jan 26, 2022 at 12:52 PM Brendan Doyle >> <brendan.do...@oracle.com> wrote: >> >> Hi, >> >> So I have an underlay VIP that is reachable via a Gateway. The VIP >> moved >> to a new >> hypervisor after a simulated power failure (all hypervisors >> rebooted). >> When things came >> back OVN was resolving it to the wrong MAC address. When I looked >> in the >> MAC_binding >> table I saw that all entries for that address were wrong. I >> flushed the >> table and everything >> was fine (entries got updated with the correct MAC). >> >> So It seems to me that these entries must not be aged out? How is >> this >> supposed to work? >> >> >> These entries do not age out. We discussed the topic a couple of other >> times (eg. [0]) without a clear conclusion. >> Also, we observed that in certain environments the size of this table >> can increase to a point where the SB database starts to be huge (>1GB) >> mostly due to the entries in this table. >> To avoid this, we landed a patch in OpenStack recently that could be >> useful for you [1]. >> >> [0] https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048936.html >> <https://urldefense.com/v3/__https://mail.openvswitch.org/pipermail/ovs-discuss/2019-June/048936.html__;!!ACWV5N9M2RV99hQ!epF_ARhUyGKDFElDfBHLpl8nwShlaihOzb8dblrzw1T29AVqmuNHf-a_eSJ2ZN6_CPI$> >> [1] https://review.opendev.org/c/openstack/neutron/+/813610 >> <https://urldefense.com/v3/__https://review.opendev.org/c/openstack/neutron/*/813610__;Kw!!ACWV5N9M2RV99hQ!epF_ARhUyGKDFElDfBHLpl8nwShlaihOzb8dblrzw1T29AVqmuNHf-a_eSJ2lv7NnXI$> >> >> >> Thanks >> >> Brendan. >> >> _______________________________________________ >> discuss mailing list >> disc...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> >> <https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!epF_ARhUyGKDFElDfBHLpl8nwShlaihOzb8dblrzw1T29AVqmuNHf-a_eSJ2MyZ1I8I$> >> > > > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
