[ovs-dev] Question about ovs-vtep implementation

Lance Richardson lrichard at redhat.com
Tue Jul 19 13:45:15 UTC 2016


----- Original Message -----
> From: "Darrell Ball" <dlu998 at gmail.com>
> To: "Lance Richardson" <lrichard at redhat.com>
> Cc: "ovs dev" <dev at openvswitch.org>, "Daniele Di Proietto" <diproiettod at vmware.com>
> Sent: Friday, July 15, 2016 2:06:36 PM
> Subject: Re: [ovs-dev] Question about ovs-vtep implementation
> 
> On Fri, Jul 15, 2016 at 11:00 AM, Lance Richardson <lrichard at redhat.com>
> wrote:
> 
> > > From: "Darrell Ball" <dlu998 at gmail.com>
> > > To: "Lance Richardson" <lrichard at redhat.com>
> > > Cc: "ovs dev" <dev at openvswitch.org>
> > > Sent: Tuesday, July 12, 2016 5:34:04 PM
> > > Subject: Re: [ovs-dev] Question about ovs-vtep implementation
> > >
> > > On Fri, Jul 8, 2016 at 12:20 PM, Lance Richardson <lrichard at redhat.com>
> > > wrote:
> > >
> > > > The "ovn-controller-vtep - vtep-macs 1" test case fails occasionally,
> > > > with ovs-vswitchd logs similar to these:
> > > >
> > > >     bridge|INFO|bridge br-vtep_vtep_ls1: added interface vx1 on port 2
> > > >     tunnel|WARN|bfd1.2.3.5: attempting to add tunnel port with same
> > config
> > > > as port 'vx1' (::->1.2.3.5, key=0, dp port=4789, pkt mark=0)
> > > >     ofproto|WARN|vtep_bfd: could not add port bfd1.2.3.5 (File exists)
> > > >
> > > > In the passing case, ovs-vtep.log always seems to have:
> > > >
> > > >     ovs-vtep | INFO | using tunnel key 1 in lswitch0
> > > >
> > > > In the failing case, the tunnel key is zero:
> > > >
> > > >     ovs-vtep | INFO | using tunnel key 0 in lswitch0
> > > >
> > > >
> > > > ovs-vtep creates two VXLAN tunnels per logical switch, one for
> > > > ordinary data traffic and one for BFD.  These tunnels have the same
> > > > network configuration (IP addresses, UDP port, etc.), and in the
> > > > passing case the only difference in the configurations is the tunnel
> > key.
> > > >
> > > > In the failing case, the data tunnel key is 0 and the BFD tunnel
> > > > key is also 0 (it's not specified, I'm assuming it defaults
> > > > to zero), so the tunnel configurations are identical (which is why
> > > > ovs-vswitchd is rejecting the attempt to create the BFD tunnel).
> > > >
> > > > My questions are:
> > > >    - Does the above description make sense?
> > >
> > >    - What can be done to ensure that the tunnel pair uses
> > > >      two different keys (e.g. if the BFD tunnel always uses
> > > >      a key of zero, is there a way to make data tunnel keys
> > > >      start at one?)
> > > >
> > >
> > >
> > > We need to wait for the correct value of tunnel key to be programmed.
> > > OVN uses datapath tunnel keys >= 1
> > >
> > > 0 is reserved for BFD in the context of the VTEP emulator.
> > > 0 is also used as a non-BFD tunnel default in the VTEP emulator which is
> > > wrong in that
> > > it is internally inconsistent to fall back to a known conflicting value.
> > >
> > > I was thinking along the below lines in terms of fix.
> > > Can you check it out in your environment ?
> > >
> > > diff --git a/vtep/README.ovs-vtep.md b/vtep/README.ovs-vtep.md
> > > index 2913714..905c1a3 100644
> > > --- a/vtep/README.ovs-vtep.md
> > > +++ b/vtep/README.ovs-vtep.md
> > > @@ -161,6 +161,8 @@ vtep-ctl add-ls ls0
> > >
> > >  2. Bind the logical switch to a port:
> > >
> > > +   BFD reserves the use of tunnel_key 0 in ovs-vtep.
> > > +
> > >        ```
> > >  vtep-ctl bind-ls br0 p0 0 ls0
> > >  vtep-ctl set Logical_Switch ls0 tunnel_key=33
> > >
> > >
> > > diff --git a/vtep/ovs-vtep b/vtep/ovs-vtep
> > > old mode 100644
> > > new mode 100755
> > > index e52c66f..5ad900d
> > > --- a/vtep/ovs-vtep
> > > +++ b/vtep/ovs-vtep
> > > @@ -259,6 +259,21 @@ class Logical_Switch(object):
> > >          tunnels = set()
> > >          parse_ucast = True
> > >
> > > +        if not self.tunnel_key:
> > > +            vlog.info("Invalid tunnel key %s in %s; requery database"
> > > +                          % (self.tunnel_key, self.name))
> > > +            column = vtep_ctl("--columns=tunnel_key find logical_switch
> > "
> > > +                              "name=%s" % self.name)
> > > +            tunnel_key = column.partition(":")[2].strip()
> > > +            if tunnel_key and isinstance(eval(tunnel_key),
> > > six.integer_types):
> > > +                self.tunnel_key = tunnel_key
> > > +                vlog.info("update_remote_macs: using tunnel key %s in
> > %s"
> > > +                          % (self.tunnel_key, self.name))
> > > +            else:
> > > +                vlog.info("Invalid tunnel key %s in %s after DB
> > requery"
> > > +                          % (self.tunnel_key, self.name))
> > > +                return
> > > +
> > >          mac_list = vtep_ctl("list-remote-macs %s" % self.name
> > ).splitlines()
> > >          for line in mac_list:
> > >              if (line.find("mcast-mac-remote") != -1):
> > >
> > >
> >
> > Hi Darrell,
> >
> > After travelling most of the week, I'm now back to the testbed I originally
> > saw the failures on. I haven't seen any issues with your patch, but on
> > the other hand I'm having trouble recreating the failures without your
> > patch.
> > I'm going to continue to try to reproduce the original problem, will update
> > when I have more data.
> >
> > Thanks,
> >
> >    Lance
> >
> 
> 
> Thanks Lance
> 
> Daniele's testing with Travis used for OVS merge validation frequently
> fails without the patch using Ubuntu 16.04 environment timing.
> 

Sorry, I had not been paying attention to the thread in which you posted
this patch, and didn't realize it had already been pushed.

Thanks for fixing this!

   Lance



More information about the dev mailing list