----- Original Message -----
> From: "Darrell Ball" <dlu...@gmail.com>
> To: "Lance Richardson" <lrich...@redhat.com>
> Cc: "ovs dev" <dev@openvswitch.org>, "Daniele Di Proietto"
> <diproiet...@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 <lrich...@redhat.com>
> wrote:
>
> > > From: "Darrell Ball" <dlu...@gmail.com>
> > > To: "Lance Richardson" <lrich...@redhat.com>
> > > Cc: "ovs dev" <dev@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 <lrich...@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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
