[ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep

Darrell Ball dball at vmware.com
Thu Feb 11 00:35:09 UTC 2016

Hi Itamar

Thanks for looking into this code.
Your patch implements a source node replication approach for BUM traffic; using multiple OF flows.
Source node replication is not presently supported by the VTEP schema although admittedly the documentation is not clear
and will be updated soon. The text in red below is not agreed to be supported and should be removed pending any need to add
Source node replication support.

btw, have you run
make check
with your changes

The only VTEP schema model presently intended is service node replication, which involves sending to a special transport node in a list of such
transport nodes; the list being the physical locator set.
The service node is then responsible for replicating to other transport nodes.
The present code in ovs-vtep is simplified in that it assumes the physical locator list is a list of service nodes and simply sends to the first in the list.
Ideally, BFD, for example, should be used to select the healthy members of the physical locator list
and then some scheme applied to this list subset to select the service node used for replication – possibly the first healthy node
or load balancing might be applied as well.

If you would like to add enhanced service node selection support in ovs-vtep, then we would accept it, if it was cleanly written.

The VTEP schema can be found here:

and a relevant excerpt below

Mcast_Macs_Remote TABLE
       Mapping of multicast MAC addresses to tunnels (physical locators). This
       table is written by the NVC, so it contains the MAC addresses that  the
       NVC  has  learned. This table also specifies how to handle unknown uni‐
       cast and broadcast packets.

       Multicast packet replication may be handled by a service node, in which
       case  the  physical  locators will be IP addresses of service nodes. If
       the VTEP supports replication onto multiple tunnels, then this  may  be
       used to replicate directly onto VTEP-hypervisor tunnels.

Thanks Darrell

From: Itamar Ofek <itamar.ofek at huawei.com<mailto:itamar.ofek at huawei.com>>
Date: February 10, 2016 at 4:55:20 AM PST
To: "bugs at openvswitch.org<mailto:bugs at openvswitch.org>" <bugs at openvswitch.org<mailto:bugs at openvswitch.org>>
Subject: [ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep


I have observed that flood towards tunnels that are referenced via unknown-dst is done only to the first destination

       for tunnel in self.unknown_dsts:
            port_no = self.tunnels[tunnel][0]

        ovs_ofctl("add-flow %s table=1,priority=0,action=%s"
                  % (self.short_name, ",".join(flood_ports)))

Which prevents from other tunnel destination from receiving  BUM's

Attached below a patch which forwards flood to all unknown-dsts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160211/174cdd35/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_flood[8].patch
Type: application/octet-stream
Size: 1886 bytes
Desc: fix_flood[8].patch
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160211/174cdd35/attachment-0005.obj>

More information about the discuss mailing list