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

Reply via email to