[ovs-discuss] ovn not creating geneve tunnels

[Flavio Fernandes]

> On Jan 10, 2020, at 8:55 PM, Lars Kellogg-Stedman <lars at redhat.com> wrote:
> 
> Flavio,
> 
> I wanted to expand on our irc discussion earlier today.  Here's what
> I'm seeing:
> 
> If I run this command...
> 
>  ovs-vsctl set open_vswitch .  \
>    external_ids:ovn-remote=tcp:192.168.122.100:6642 \
>    external_ids:ovn-encap-ip=$(ip addr show eth0 | awk '$1 == "inet" {print $2}' | cut -f1 -d/) \
>    external_ids:ovn-encap-type=geneve \
>    external_ids:system-id=$(hostname)
> 
> Then OVN (reliably) does not immediately bring up the geneve tunnels:
> 
>  [root at ovn1 ~]# ovs-vsctl show
>  b55f79a1-686a-40c9-90c5-3cca33b02517
>      Bridge br-int
>          fail_mode: secure
>          Port br-int
>              Interface br-int
>                  type: internal
>      ovs_version: "2.12.0"
> 
> In this situation, the tunnels will come up if I restart
> ovn-controller, or if I bind some ports that require connectivity
> between hosts. Everything seems to *work*, but the behavior differs
> from what I was seeing earlier.
> 
> It turns out that if I set the same configuration using multiple
> commands (which is what I was originally doing), like this...
> 
>  ovs-vsctl set open_vswitch . external_ids:ovn-remote=tcp:192.168.122.100:6642
>  ovs-vsctl set open_vswitch . external_ids:ovn-encap-ip=$(ip addr show eth0 | awk '$1 == "inet" {print $2}' | cut -f1 -d/)
>  ovs-vsctl set open_vswitch . external_ids:ovn-encap-type=geneve
>  ovs-vsctl set open_vswitch . external_ids:system-id=$(hostname)
> 
> ...then the geneve tunnels come up without any additional changes:
> 
>  [root at ovn1 ~]# ovs-vsctl show
>  7ca1a9c6-f035-493a-94a9-31474dd6cf77
>      Bridge br-int
>          fail_mode: secure
>          Port "ovn-ovn2-0"
>              Interface "ovn-ovn2-0"
>                  type: geneve
>                  options: {csum="true", key=flow, remote_ip="192.168.122.102"}
>                  error: "could not add network device ovn-ovn2-0 to ofproto (File exists)"
>          Port br-int
>              Interface br-int
>                  type: internal
>          Port "ovn-ovn0-0"
>              Interface "ovn-ovn0-0"
>                  type: geneve
>                  options: {csum="true", key=flow, remote_ip="192.168.122.100"}
>      ovs_version: "2.12.0"
> 
> Although as you can see the tunnels don't always come up "cleanly". I
> get that "could not add network device ovn-ovn2-0 to ofproto (File
> exists)" fairly often, but not all the time.
> 
> And it's not always the same tunnel throwing the error; after a couple
> more tries, I see:
> 
>          Port "ovn-ovn0-0"
>              Interface "ovn-ovn0-0"
>                  type: geneve
>                  options: {csum="true", key=flow, remote_ip="192.168.122.100"}
>                  error: "could not add network device ovn-ovn0-0 to ofproto (File exists)"
> 
> Something here seems racy and/or non-deterministic.  I'm running
> openvswitch/ovn 2.12.0 on Fedora 31 (kernel 5.4.8-200.fc31.x86_64).


Indeed sounds like a timing thing, affected by when the attributes are done in a single ovsdb transaction or
separately. I will try to reproduce it on my setup using your findings as guide.

And thanks for cc'ing the ML. There are a lot of really smart people here who may have a good idea on
why this is happening.

Best,

-- flaviof




> 
> -- 
> Lars Kellogg-Stedman <lars at redhat.com> | larsks @ {irc,twitter,github}
> http://blog.oddbit.com/                | N1LKS
> 
> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss