Hi Darrell, I think we are talking about 2 different scenarios here. You are assuming that my unknown-dst is a service node, however, I see no reason to mandate having service nodes at all. Since as you mentioned, the HW-VTEP switch is assumed to be controlled by an NVC, then we are running in a controlled network where the NVC has a global view of the network. In this case, the NVC installs learned MAC addresses in the HW-VTEP switch and in case it does not know what to do, the fallback action is classic learning (flooding all “unknown-dst” addresses). This is how I would expect any switch (including vtep devices) to treat BUM.
Even if we assume service nodes, if the required behavior is sending BUM’s to a specific service node then the NVC can configure a single unknown-dst address and get the exact same behavior you specified. Currently, installing multiple unknown-dst addresses is meaningless and confusing (Despite the ability being well defined by the spec). Thanks, Itamar From: Darrell Ball [mailto:db...@vmware.com] Sent: Thursday, 11 February, 2016 2:35 AM To: Itamar Ofek; b...@openvswitch.org<mailto:b...@openvswitch.org>; discuss@openvswitch.org<mailto:discuss@openvswitch.org> Subject: re: [ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep 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: http://openvswitch.org/support/dist-docs/vtep.5.html 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.o...@huawei.com<mailto:itamar.o...@huawei.com>> Date: February 10, 2016 at 4:55:20 AM PST To: "b...@openvswitch.org<mailto:b...@openvswitch.org>" <b...@openvswitch.org<mailto:b...@openvswitch.org>> Subject: [ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep Hi, 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] flood_ports.append(port_no) break 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 Regards
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
