[ovs-dev] OVN multicast enhancements

Mark Michelson mmichels at redhat.com
Wed Dec 5 19:19:06 UTC 2018


On 11/16/18 6:11 AM, Ankur Sharma wrote:
> Hi Mark,
> 
> Thanks for the write up.
> Initial proposal looks to be a good starting point.
> 
> Please find my feedback inline.
> 
> Regards,
> Ankur
> 

Sorry for the late response Ankur, but for some reason your response got 
completely lost and I did not see it until now.

> ------------------------------------------------------------------------
> *From:* ovs-dev-bounces at openvswitch.org 
> <ovs-dev-bounces at openvswitch.org> on behalf of Mark Michelson 
> <mmichels at redhat.com>
> *Sent:* Thursday, November 15, 2018 2:20 PM
> *To:* ovs-dev at openvswitch.org
> *Subject:* [ovs-dev] OVN multicast enhancements
> Hi everyone,
> 
> In today's IRC meeting I brought up the fact I was enhancing multicast
> support in OVN, and I was asked to expand on this a bit. So here are
> details about what all I am working on.
> 
> Right now, OVN logical switches treat all multicast destinations as if
> they were broadcast. That is, the packet gets sent to all ports on the
> switch. OVN logical routers block all traffic destined to a multicast
> address.
> 
> My goal is for there to be more intelligence. IP traffic sent to
> multicast addresses should be sent to members of that multicast group
> when possible.
> 
> My work consists of the following phases:
> 
> Phase 1: Northbound changes; multicast on a single logical switch port.
> 
> For this part, we create a new northbound table called Multicast_Group.
> It consists of:
> * A name
> * A multicast IP address
> * A list of logical switch ports
> The general idea is that traffic sent to the IP address should reach all
> logical switch ports listed.
> 
> [ANKUR]:
> a. I am assuming this table is per logical switch.

No, the table itself is not per logical switch. The logical switch ports 
may span across multiple logical switches.

> 
> b. How will you discover the port to multicast group mapping?
> I am of the opinion that instead of having an out of band mechanism, 
> OVN can leverage on igmp snopping in OVS and populate this multicast 
> group to port mapping.
> We can also enhance as ovn-controller to do local igmp snooping and 
> populate this table.

I agree that IGMP snooping should be a goal. For my initial work, I'm 
focusing more heavily on getting a basis in place so that IGMP snooping 
could be built on top of it.

> 
> c. Is it really multicast or multi unicast?
> i.e for intra chassis logical ports, will ovn-controller generate on 
> packet for each endpoint?
> Similarly, for endpoints in a remote chassis, how many packets will 
> source chassis generate?

Let's say that a multicast group has two ports on HV A and two ports on 
HV B. A multicast packet arrives on HV A.

We will send a packet on each port of HV A that is a member of the 
multicast group. In other words, we sill send two packets.

We will send one packet from HV A to HV B.

When HV B receives the multicast packet, it will send a packet to each 
of the ports on HV B that are members of the multicast group.

Hopefully that answers your question.

> 
> 
> In practice, each northbound multicast group will result in southbound
> multicast groups being added to the datapaths that the logical switch
> ports reside on. Logical flows are introduced on the logical switch
> ingress pipelines to output packets that are destined for the multicast
> IP address and the corresponding derived multicast ethernet address [1]
> to the constituent ports.
> [ANKUR]:
> To be honest, i am not clear with the use case of multicast_group table 
> in southbound DB.
> Can you elaborate on it please? It will help me with better 
> understanding of the proposal.

Sure. Multicast_Group in the southbound database is a pre-existing 
table. Each multicast group in the southbound database exists per-datapath.

ovn-northd can create logical flows that set the output port to be some 
multicast group

ovn-controller treats this in a couple of ways.
* For cases where we are setting an output port, ovn-controller uses the 
port key for the multicast group. This will be a value greater than 32767.
* ovn-controller evaluates each multicast group to expand it into rules 
to transmit to the ports in that multicast group.

If you want to see how this works, you can trace the MC_FLOOD multicast 
group from ovn-northd. This is a multicast group that is created for 
every logical switch datapath in the southbound database. The multicast 
group contains all logical switch ports on the datapath. It has a port 
key of 0xffff. This is the way that multicast behavior in OVN currently 
works. When a multicast packet arrives, we set the output port to 
0xffff. Openflow rules later make it so that if the output port is set 
to 0xffff, then the packet is sent to all of the ports on the datapath.

For my change, I'm installing more selective Multicast_Groups. I output 
the packet to this particular Multicast_Group based on the destination 
IP address that was configured in the northbound Multicast_Group.

> 
> 
> In practice, this set of changes only works if all ports in the
> multicast group are on the same logical switch.
> 
> I already have this implemented and have a test written for the
> testsuite that passes. You can see what I have at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_putnopvut_ovs_tree_multicast-2Dimprovements&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=kC2cxfPhTHmGGJ263RuiYNeBHuBVMBeBxjpjHCmrzlM&e= 
> 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_putnopvut_ovs_tree_multicast-2Dimprovements&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=kC2cxfPhTHmGGJ263RuiYNeBHuBVMBeBxjpjHCmrzlM&e=>
> 	
> putnopvut/ovs 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_putnopvut_ovs_tree_multicast-2Dimprovements&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=kC2cxfPhTHmGGJ263RuiYNeBHuBVMBeBxjpjHCmrzlM&e=>
> urldefense.proofpoint.com
> Open vSwitch. Contribute to putnopvut/ovs development by creating an 
> account on GitHub.
> 
> 
> 
> 
> Phase 2: Add multicast routing support
> 
> This expands on the work in phase 1 by creating southbound multicast
> groups on logical router datapaths for router ports connected to logical
> switches with multicast groups on them. This way, a multicast group
> distributed across multiple logical switches can have the traffic routed
> as desired.
> 
> This also requires adding new logical flows for the router pipeline to
> ensure that traffic bound to known multicast IPs is sent where we expect.
> 
> I'm currently working on this phase. I have a test written and it is not
> passing.
> 
> [ANKUR]:
> Looks like this proposal is only for E-W traffic. For N-S we will have 
> to advertise NATed IPs as multicast group member to uplink router.

Yes, that is correct.
> 
> 
> Phase 3: Expand to IPv6 support.
> 
> The previous phases are very IPv4-centric. This phase expands on what we
> have already by making it work with IPv6 as well. Mostly, this means
> removing IPv4-centric idioms and installing IPv6 flows in parallel with
> the IPv4 flows.
> 
> 
> With those three phases complete, I think I'll have a decent patchset to
> submit for approval. There are other enhancements that can be
> implemented as well later on:
> 
> * IGMP/MLD snooping in ovn-controller.
> * Installation of rules for well-known multicast addresses with semantic
> significance.
> 
> That's all for that. If you have questions/concerns, please let me know.
> 
> Mark!
> 
> [1] I initially had wanted to only use the multicast ethernet address
> for determining where to send the packets. However, the way that
> multicast IP translates into multicast ethernet addresses, there can be
> ambiguity. Therefore the logical switch needs to also examine the
> multicast IP address.
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwICAg&c=s883GpUCOChKOHiocYtGcg&r=mZwX9gFQgeJHzTg-68aCJgsODyUEVsHGFOfL90J6MJY&m=FzqJqkEOtSxSyDtTFtQYFLaAR8OPuTmCm85UStogNeI&s=52FWz085Rjvb5SniZ-Oe8I5bl3BAya6Q2-NOzFayn3o&e=



More information about the dev mailing list