On 20/10/2021 21:29, Numan Siddique wrote:
On Mon, Oct 18, 2021 at 7:55 AM Daniel Alvarez Sanchez
<[email protected]> wrote:
On Mon, Oct 18, 2021 at 1:12 PM Ammad Syed <[email protected]> wrote:
Hi Brendan,
Not sure but this could be related to the patch below in neutron that was
recently released.
https://urldefense.com/v3/__https://opendev.org/openstack/neutron/commit/f6c35527698119ee6f73a6a3613c9beebb563840__;!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_dRqFH1OI$
Not really, as this commit that you refer to is to reduce the memory footprint
in the neutron-server process itself. Neutron never inserts anything into the
MAC_Binding table.
However, we landed another patch [0] that will likely minimize this issue as it
will reduce the MAC_Binding insertions, limiting them only to MAC addresses
that need to be reached out by the overlay.
Thanks!
daniel
[0]
https://urldefense.com/v3/__https://review.opendev.org/c/openstack/neutron/*/813610__;Kw!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_dIMoCVyw$
Ammad
On Mon, Oct 18, 2021 at 3:40 PM Brendan Doyle <[email protected]> wrote:
I too am seeing many entries in the ovn-controller log like these:
ovn/ovn-controller.log:2021-10-18T09:50:46.984Z|00164|ovsdb_idl|WARN|transaction error: {"details":"Transaction causes multiple rows in
\"MAC_Binding\" table to have identical values (lr_vcn6727324-ls_vcn6727324_external_ugw and \"253.255.80.18\") for index on columns
\"logical_port\" and \"ip\". First row, with UUID 614509d1-5dfc-4268-94b7-6190c1bd8c58, was inserted by this transaction. Second row,
with UUID 5b56044f-7e62-4e6b-b559-2bca31ad5ab0, existed in the database before this transaction and was not modified by the
transaction.","error":"constraint violation"}
So with my limited understanding of the MAC_Binding table I'm wondering are
these benign?
I think it's benign
In that is it that we for what ever reason have decided that we need to do an
ARP to discover
a MAC, then ovn-controller tries to add the discovered MAC to the MAC_Binding
only to find
that it is already there. In which case the question is why was an ARP request
sent when
we already had a MAC binding.
FYI, ovn-controller also learns from the ARP requests received from
external which can be
turned off if desired with the option - always_learn_from_arp_request
set in the logical router's options
column.
I don't think ovn-controller will generate an ARP request if its
already learnt. Looks to me
multiple ovn-controller try to learn from an ARP request originated
from external and ofcourse
only one will be able to write to the mac_binding entry and others would fail.
Yes that is possible, in which case the warnings are benign right?
Thanks
Numan
For me these are only ever seen on Distributed router Port Gateways.
On 12/10/2021 13:06, Ammad Syed wrote:
Hi,
I am using openstack with ml2/ovn. I have two gateway chassis whenever I
shutdown one chassis and bring it back online, I see below error in
ovn-controller logs.
Can you please advise the way to fix it ?
2021-10-12T11:49:22.124Z|00511|binding|INFO|cr-lrp-4c882760-15b1-4cf4-b680-53e88880e928:
Claiming fa:16:3e:55:12:5a 101.53.244.97/24
2021-10-12T11:49:22.126Z|00512|binding|INFO|Releasing lport
cr-lrp-4c882760-15b1-4cf4-b680-53e88880e928 from this chassis.
2021-10-12T11:50:32.032Z|00513|ovsdb_idl|WARN|transaction error: {"details":"Transaction causes multiple rows in \"MAC_Binding\" table
to have identical values (lrp-4c882760-15b1-4cf4-b680-53e88880e928 and \"fe80::6a4f:64ff:fef7:8c0\") for index on columns \"logical_port\"
and \"ip\". First row, with UUID cbc847e6-75e4-4d73-9906-4fef221cad38, was inserted by this transaction. Second row, with UUID
bcac2e3e-5f32-411a-afcf-3249b85700f4, existed in the database before this transaction and was not modified by the
transaction.","error":"constraint violation"}
Ammad
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!eo4L8XZbywCy0zb_p7-7LEVv9xl6g9V8JEf6oZTAO21scCtNAudRSGcK9mYnI7H-cyA$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_detQnyEU$
--
Regards,
Syed Ammad Ali
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_detQnyEU$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_detQnyEU$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!fKjD2ymIm0WKBrKvJ-6cjyKvYNJHCXYBXsL0nhWde_anAW_7exk9teq3h2_detQnyEU$
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss