<div dir="ltr"><div><br><br>On Mon, Jan 13, 2020 at 6:52 PM Flavio Fernandes <<a href="mailto:flavio@flaviof.com">flavio@flaviof.com</a>> wrote:<br>><br>><br>><br>> > On Jan 10, 2020, at 8:55 PM, Lars Kellogg-Stedman <<a href="mailto:lars@redhat.com">lars@redhat.com</a>> wrote:<br>> ><br>> > Flavio,<br>> ><br>> > I wanted to expand on our irc discussion earlier today.  Here's what<br>> > I'm seeing:<br>> ><br>> > If I run this command...<br>> ><br>> >  ovs-vsctl set open_vswitch .  \<br>> >    external_ids:ovn-remote=tcp:<a href="http://192.168.122.100:6642">192.168.122.100:6642</a> \<br>> >    external_ids:ovn-encap-ip=$(ip addr show eth0 | awk '$1 == "inet" {print $2}' | cut -f1 -d/) \<br>> >    external_ids:ovn-encap-type=geneve \<br>> >    external_ids:system-id=$(hostname)<br>> ><br>> > Then OVN (reliably) does not immediately bring up the geneve tunnels:<br>> ><br>> >  [root@ovn1 ~]# ovs-vsctl show<br>> >  b55f79a1-686a-40c9-90c5-3cca33b02517<br>> >      Bridge br-int<br>> >          fail_mode: secure<br>> >          Port br-int<br>> >              Interface br-int<br>> >                  type: internal<br>> >      ovs_version: "2.12.0"<br>> ><br>> > In this situation, the tunnels will come up if I restart<br>> > ovn-controller, or if I bind some ports that require connectivity<br>> > between hosts. Everything seems to *work*, but the behavior differs<br>> > from what I was seeing earlier.<br>> ><br>> > It turns out that if I set the same configuration using multiple<br>> > commands (which is what I was originally doing), like this...<br>> ><br>> >  ovs-vsctl set open_vswitch . external_ids:ovn-remote=tcp:<a href="http://192.168.122.100:6642">192.168.122.100:6642</a><br>> >  ovs-vsctl set open_vswitch . external_ids:ovn-encap-ip=$(ip addr show eth0 | awk '$1 == "inet" {print $2}' | cut -f1 -d/)<br>> >  ovs-vsctl set open_vswitch . external_ids:ovn-encap-type=geneve<br>> >  ovs-vsctl set open_vswitch . external_ids:system-id=$(hostname)<br>> ><br>> > ...then the geneve tunnels come up without any additional changes:<br>> ><br>> >  [root@ovn1 ~]# ovs-vsctl show<br>> >  7ca1a9c6-f035-493a-94a9-31474dd6cf77<br>> >      Bridge br-int<br>> >          fail_mode: secure<br>> >          Port "ovn-ovn2-0"<br>> >              Interface "ovn-ovn2-0"<br>> >                  type: geneve<br>> >                  options: {csum="true", key=flow, remote_ip="192.168.122.102"}<br>> >                  error: "could not add network device ovn-ovn2-0 to ofproto (File exists)"<br>> >          Port br-int<br>> >              Interface br-int<br>> >                  type: internal<br>> >          Port "ovn-ovn0-0"<br>> >              Interface "ovn-ovn0-0"<br>> >                  type: geneve<br>> >                  options: {csum="true", key=flow, remote_ip="192.168.122.100"}<br>> >      ovs_version: "2.12.0"<br>> ><br>> > Although as you can see the tunnels don't always come up "cleanly". I<br>> > get that "could not add network device ovn-ovn2-0 to ofproto (File<br>> > exists)" fairly often, but not all the time.<br>> ><br>> > And it's not always the same tunnel throwing the error; after a couple<br>> > more tries, I see:<br>> ><br>> >          Port "ovn-ovn0-0"<br>> >              Interface "ovn-ovn0-0"<br>> >                  type: geneve<br>> >                  options: {csum="true", key=flow, remote_ip="192.168.122.100"}<br>> >                  error: "could not add network device ovn-ovn0-0 to ofproto (File exists)"<br>> ><br>> > Something here seems racy and/or non-deterministic.  I'm running<br>> > openvswitch/ovn 2.12.0 on Fedora 31 (kernel 5.4.8-200.fc31.x86_64).<br>><br>><br>> Indeed sounds like a timing thing, affected by when the attributes are done in a single ovsdb transaction or<br>> separately. I will try to reproduce it on my setup using your findings as guide.<br>><br>> And thanks for cc'ing the ML. There are a lot of really smart people here who may have a good idea on<br>> why this is happening.<br>><br>> Best,<br>><br>> -- flaviof<br>><br></div><div>I am not 100% sure if it is the same problem, but could you try this patch and see if it helps?</div><div><a href="https://patchwork.ozlabs.org/patch/1222380/">https://patchwork.ozlabs.org/patch/1222380/</a></div><div><br></div><div>Thanks,</div><div>Han<br></div></div>