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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
