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 <dce...@redhat.com> 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 <odiv...@gmail.com> 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
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
