When I get a chance will try in my lab, but first I have to chase down
an ovs-switchd SEG
that we see very frequently.
On 18/10/2021 16:36, Numan Siddique wrote:
On Mon, Oct 18, 2021 at 9:01 AM Brendan Doyle <[email protected]> wrote:
Actually looking at the comments in those patches I'm a little worried.
The WARNs I see in the logs are for updates to the MAC for an underlay VIP.
So if the VIP has moved and OVN tries to update the MAC_Binding with the
new MAC are these warnings suggesting that the update is ignored because we
already have a binding entry for that logical port/IP? If so isn't that a bug?
Or we we relying on that MAC being eventually aged out?
It's a good observation. ovn-controller (pinctrl.c) updates the MAC
if the entry for the VIP
already exists.
I'm not sure how realistic it would be for the below to happen
(1) ovn-controller on Chassis - C1 creates a mac binding entry for
- (VIP, MAC1, LP)
(2) This VIP moves to another chassis - C2 with MAC2 and suppose
ovn-controller on C2 has not yet
received the update of (1) from ovsdb-server yet
(3) ovn-controller on C2 creates a new mac binding entry for -
(VIP, MAC2, LP). But since the mac binding
entry for (VIP, LP) already exists, ovsdb-server would return
constraint violation error and MAC2 is not
updated at all.
@Ammad Syed Is it possible for you to verify if this is the case ?
Enable jsonrpc:dbg (ovn-appctl -t ovn-controller vlog/set jsonrpc:dbg)
and see if the MAC entry set in
the transaction is the same as the MAC stored in the SB DB ?
(ovn-sbctl find mac_binding ip=<VIP>) ?
Otherwise the constraint violation warning can be ignored.
Thanks
Numan
On 18/10/2021 12:54, Daniel Alvarez Sanchez 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!btR--sreEQc_sxyeOUgF4K1qiVR8GhJ3LZORK-fXLq2zOB1vig71njVKuT1iABO2nRU$
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!btR--sreEQc_sxyeOUgF4K1qiVR8GhJ3LZORK-fXLq2zOB1vig71njVKuT1iTqfFvxg$
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.
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!btR--sreEQc_sxyeOUgF4K1qiVR8GhJ3LZORK-fXLq2zOB1vig71njVKuT1iFFS6X20$
--
Regards,
Syed Ammad Ali
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!btR--sreEQc_sxyeOUgF4K1qiVR8GhJ3LZORK-fXLq2zOB1vig71njVKuT1iFFS6X20$
_______________________________________________
discuss mailing list
[email protected]
https://urldefense.com/v3/__https://mail.openvswitch.org/mailman/listinfo/ovs-discuss__;!!ACWV5N9M2RV99hQ!btR--sreEQc_sxyeOUgF4K1qiVR8GhJ3LZORK-fXLq2zOB1vig71njVKuT1iFFS6X20$
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
