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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev