[ovs-discuss] ovn not creating geneve tunnels

Flavio Fernandes flavio at flaviof.com
Tue Jan 14 23:55:35 UTC 2020





> On Jan 14, 2020, at 5:59 PM, Han Zhou <hzhou at ovn.org> wrote:
> 
> I am glad it works and thanks for the update :)
> 

I observed the same as Lars! The patch makes the southbound output work using the command as described!
I tested it on ovn+ovs 2.12


  (.env) [vagrant at ovn0 ~]$ sudo ovs-vsctl set open_vswitch .  \
  >     external_ids:ovn-remote=tcp:192.168.122.100:6642 \ 
  >     external_ids:ovn-encap-ip=$(ip addr show eth1 | awk '$1 == "inet" {print $2}' | cut -f1 -d/) \
  >     external_ids:ovn-encap-type=geneve
  (.env) [vagrant at ovn0 ~]$
  (.env) [vagrant at ovn0 ~]$ sudo ovn-sbctl show
  Chassis "1c3c6612-51ed-49b2-8c46-af210c4975be"
      hostname: ovn0
      Encap geneve
          ip: "192.168.122.100"
          options: {csum="true"}

THANKS Han!!!

-- flaviof



> On Tue, Jan 14, 2020 at 2:58 PM Lars Kellogg-Stedman <lars at redhat.com <mailto:lars at redhat.com>> wrote:
> Han,
> 
> It looks as if that patch may resolve the issue. I backported it to 2.12.0 and built some updated RPMS for Fedora 31; with those in place, the tunnels come up immediately.
> 
> On Tue, Jan 14, 2020 at 1:03 AM Han Zhou <hzhou at ovn.org <mailto:hzhou at ovn.org>> wrote:
> 
> 
> On Mon, Jan 13, 2020 at 6:52 PM Flavio Fernandes <flavio at flaviof.com <mailto:flavio at flaviof.com>> wrote:
> >
> >
> >
> > > On Jan 10, 2020, at 8:55 PM, Lars Kellogg-Stedman <lars at redhat.com <mailto: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 <http://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 <http://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
> >
> I am not 100% sure if it is the same problem, but could you try this patch and see if it helps?
> https://patchwork.ozlabs.org/patch/1222380/ <https://patchwork.ozlabs.org/patch/1222380/>
> 
> Thanks,
> Han
> 
> 
> -- 
> Lars Kellogg-Stedman <lars at redhat.com <mailto:lars at redhat.com>>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20200114/b9a01e5e/attachment.html>


More information about the discuss mailing list