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.
Brendan
On 26/01/2022 13:28, Daniel Alvarez Sanchez wrote:
Hey Brendan,
On Wed, Jan 26, 2022 at 12:52 PM Brendan Doyle
<[email protected]> 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
[email protected]
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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
