[ovs-dev] Question about ovs-vtep implementation

Lance Richardson lrichard at redhat.com
Fri Jul 15 18:00:39 UTC 2016


> 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



More information about the dev mailing list