Finally, I’ve managed to find the correct place for this change. I’ve submitted a patch series here: [1]
Thanks Dumitru, your help was very valuable! I’d be glad if you can find some time to review this series. :) 1: https://patchwork.ozlabs.org/project/ovn/cover/[email protected]/ > On 17 May 2023, at 19:05, Vladislav Odintsov <[email protected]> wrote: > > Thanks Dumitru for the response. > > I’ve looked through this code and even tried to implement similar logic for > vtep lport, but realized, that vtep mcast traffic is a bit different from > localnet port. > mcast traffic originated in normal vif port in localnet-attached lswitch has > two cases: > - if uplink bridge mapping is locally available, the mcast packet is sent to > this interface assuming classic network switch outside of ovn will flood it > in l2 domain > - if uplink bridge mapping is locally unawailable, such mcast packet is > flooded in overlay. (honestly I didn’t find code related to this logic, I’ve > found it just performing tests) > > With same logic implemented in consider_mc_group() the BUM traffic originated > in vif lport doesn’t reach remote chassis at all… > > With vtep lport mcast traffic must be replicated always on source node, but > it’s prohibited to re-send received from vtep lport mcast packets to other > remote chassis. > I guess I need to reject mcast l2 flood to remote ports if REGBIT_FROM_RAMP > == 1. > > Do you have an idea for the correct place to put such logic in? > >> On 16 May 2023, at 23:02, Dumitru Ceara <[email protected]> wrote: >> >> On 5/16/23 21:48, Vladislav Odintsov wrote: >>> Hi Numan, Dumitru, Ilya, Mark, >>> >> >> Hi Vladislav, >> >>> if someone can help, I’ll be very grateful. >>> >>> Thanks in advance. >>> >>>> On 15 May 2023, at 15:06, Vladislav Odintsov <[email protected]> wrote: >>>> >>>> Hi, I’m implementing neighbour learning on the chassis-redirect ports >>>> for traffic coming from lport of vtep type and have some >>>> misunderstanding of how MC_FLOOD action works with traffic coming from >>>> localnet lports. Imagine, we’ve got lswitch with 4 LSPs: - vtep lport >>>> (type vtep) - lrp (chassis-redirect configured router port on hv1) - >>>> lsp1 on hv1 - lsp2 on hv2 My problem is that mcast/bcast traffic >>>> coming from vtep lport got flooded to all logical ports of the >>>> lswitch, even for those which reside on another hypervisor (hv2 in >>>> this example), resulting in duplicated packets on lsp2 vif port. vtep >>>> switch performs source node replication of BUM traffic, so bcast >>>> packets reach normal vif lports + MC_FLOOD in ls_in_l2_lkup. I’m >>>> comparing behaviour with localnet port in same setup (lswitch with 2 >>>> LSPs on different hypervisors) and see there is no such behaviour: packets >>>> don’t get flooded to vif lports on other chassis. >>>> I see that eth.mcast traffic is matched in ls_in_l2_lkup lflow table with >>>> the action 'outport = "_MC_flood"; output;', then it got flooded to only >>>> LRPs of LS and *local* vif lports. The question is - where is the >>>> logic, which prevents flooding from localnet to vif located on other >>>> chassis? Am I missing something? Let me know if any additional >>>> information is needed. Thanks! >>>> >> >> For localnet ports the key is in how ovn-controllers expand (L2) >> multicast_groups. In consider_mc_group() [0]: >> >> /* Go through all of the ports in the multicast group: >> * >> * - For remote ports, add the chassis to 'remote_chassis' or >> * 'vtep_chassis'. >> * >> * - For local ports (other than logical patch ports), add actions >> * to 'ofpacts' to set the output port and resubmit. >> * >> * - For logical patch ports, add actions to 'remote_ofpacts' >> * instead. (If we put them in 'ofpacts', then the output >> * would happen on every hypervisor in the multicast group, >> * effectively duplicating the packet.) The only exception >> * is in case of transit switches (used by OVN-IC). We need >> * patch ports to be processed on the remote side, after >> * crossing the AZ boundary. >> * >> * - For chassisredirect ports, add actions to 'ofpacts' to >> * set the output port to be the router patch port for which >> * the redirect port was added. >> */ >> >> Later on, we have a special check for switches with localnet >> ports and we don't forward traffic to remote ports in that >> case because multicast traffic reaches remote ports through >> the localnet directly: >> >> } else if (!get_localnet_port(local_datapaths, >> mc->datapath->tunnel_key)) { >> /* Add remote chassis only when localnet port not exist, >> * otherwise multicast will reach remote ports through localnet >> * port. */ >> if (port->chassis) { >> if (chassis_is_vtep(port->chassis)) { >> sset_add(&vtep_chassis, port->chassis->name); >> } else { >> sset_add(&remote_chassis, port->chassis->name); >> } >> } >> for (size_t j = 0; j < port->n_additional_chassis; j++) { >> if (chassis_is_vtep(port->additional_chassis[j])) { >> sset_add(&vtep_chassis, >> port->additional_chassis[j]->name); >> } else { >> sset_add(&remote_chassis, >> port->additional_chassis[j]->name); >> } >> } >> } >> >> Should we have a similar behavior if the datapath has a "vtep" >> port? >> >> Hope this helps. >> >> Regards, >> Dumitru >> >> [0] >> https://github.com/ovn-org/ovn/blob/276e50c3f7782472ad7f57488c48c3bd4fdbe4b7/controller/physical.c#L1731-L1750 > > > Regards, > Vladislav Odintsov > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
