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

Darrell Ball dball at vmware.com
Fri Feb 19 21:06:17 UTC 2016


Hi Itamar

From: Itamar Ofek <itamar.ofek at huawei.com<mailto:itamar.ofek at huawei.com>>
Date: Tuesday, February 16, 2016 at 8:38 AM
To: Darrel Ball <dball at vmware.com<mailto:dball at vmware.com>>, "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>
Subject: RE: [ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep

Hi Darrell,
Please view my comments inline.

From: Darrell Ball [mailto:dball at vmware.com]
Sent: Monday, 15 February, 2016 11:05 PM
To: Itamar Ofek; discuss at openvswitch.org<mailto:discuss at openvswitch.org>
Subject: Re: [ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep



From: Itamar Ofek <itamar.ofek at huawei.com<mailto:itamar.ofek at huawei.com>>
Date: Sunday, February 14, 2016 at 7:13 AM
To: Darrel Ball <dball at vmware.com<mailto:dball at vmware.com>>, "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>
Subject: RE: [ovs-discuss] unknown-dst BUM only forwarded to a single unknoun-dst tunnel in ovs-vtep

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.

> I’m not assuming that, just stating that the original intent includes that as one interpretation/option and that it was relayed to me
> that was the “favored mode” based on some hardware vendor input; nothing more than that.
> I can tell you that this is in a state of flux and I have spent cycles on this question over the last couple months

> here are some references regarding the service node replication option and other info., from googling

> https://lists.opendaylight.org/pipermail/ovsdb-dev/2015-November/002153.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opendaylight.org_pipermail_ovsdb-2Ddev_2015-2DNovember_002153.html&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=dGZmbKhBG9tJHY4odedsGA&m=2y2tpysZzDlmHBa5znkuy9TlYV5RIShNpQvMSC7KVQw&s=eEC6tGkpsBDZ3OMPVp_DPyMBmBupwZWpMH_puytgr_4&e=>

> http://blog.ipspace.net/2013/08/nicira-nvp-control-plane.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.ipspace.net_2013_08_nicira-2Dnvp-2Dcontrol-2Dplane.html&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=dGZmbKhBG9tJHY4odedsGA&m=2y2tpysZzDlmHBa5znkuy9TlYV5RIShNpQvMSC7KVQw&s=bpMunSmCACgM7WyjeXnCwNgDMJLoppFxy433PKkPLVM&e=>

> https://www.vmware.com/files/pdf/products/nsx/White_Paper_Design_VMware_Arista_3-15-2014.pdf


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.

> this is one of several valid options in general and there is no debate about this
> I referred to it earlier as source node replication although there is other terminology

> if you wanted to have the vtep schema support source node replication, then at least the following would be needed:
> 1) an option would need to be added to differentiate at least 2 approaches – service node replication and source node replication
Itamar: I suggest adding an enum  “locator_selection_mode” field  to the physical_locator_set, which  indicates the selection rule for the physical locators in the set,  which can be one of the values: “selective” (the default current behavior, impemented by the VTEP device as it fits ), “all” (indicates replication to all destinations in the set), or any other value, you may consider .

>> I would think the BUM replication mode would be associated per logical switch instance
>> see the Logical_Switch Table in the VTEP schema

> 2) existing tests or those soon to be enabled need to be supported for the service node replication type of approach

> 3) tests for the source node replication approach need to be added
Itamar:  Once agreed upon  the schema changes, I will send a patch with all the changes.
> Some infra is in the process of being added for this both types of support
Itamar: Sure


https://patchwork.ozlabs.org/patch/566244/<https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_566244_&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=dGZmbKhBG9tJHY4odedsGA&m=2y2tpysZzDlmHBa5znkuy9TlYV5RIShNpQvMSC7KVQw&s=KcvaDS33XjTrleGVD9dir0zAgfrcem1Da4wUpi9NLyg&e=>

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.

> not necessarily, although this is one option; the packet originating transport node can also decide which
> “service node” in the physical locator set to send to, based on BFD state, for example,
> although the present infrastructure needs augmenting as mentioned earlier

Currently, installing multiple unknown-dst addresses is meaningless and confusing (Despite the ability being well defined by the spec).

> unknown-dst addresses are per logical switch already; see the vtep schema
> what else did you want to do with multiple “unknown-dst” addresses ?

Thanks,
Itamar


From: Darrell Ball [mailto:dball at vmware.com]
Sent: Thursday, 11 February, 2016 2:35 AM
To: Itamar Ofek; bugs at openvswitch.org<mailto:bugs at openvswitch.org>; discuss at openvswitch.org<mailto:discuss at 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_support_dist-2Ddocs_vtep.5.html&d=BQMGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=dGZmbKhBG9tJHY4odedsGA&m=OeRTnyK7J-7TCYmlNuMdmqxP9eMwSIAzrXdK_Li9MZc&s=4GkN18476pvGvuAc2VEu_U6hzQuNrARlv65qOHCCbVk&e=>

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160219/24d6d5dd/attachment-0002.html>


More information about the discuss mailing list