On 5/19/23 20:24, Vladislav Odintsov wrote: > 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. :) >
Hi Vladislav, I'll try to give it a review as soon as possible. Regards, Dumitru > 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
