On 4/7/25 3:15 PM, Dumitru Ceara wrote:
> On 4/5/25 6:38 AM, num...@ovn.org wrote:
>> From: Numan Siddique <num...@ovn.org>
>>
>
> Hi Numan,
>
> Thanks for the patch!
>
>> After the commit [1], OVN doesn't reply to the unicast ARP
>> requests for the known IPs. This patch adds a global option
>> "unicast_arp_responder" and if set to true, OVN will also
>> respond to the unicast ARP requests. This gives the option
>> for deployments which were relying on the older behavior.
>>
>
> I wonder if the new unicast_arp_responder option should be a router (or
> switch) option instead. Or maybe keep the global option but also add
> per router or switch ways of tuning this. Some deployments might not
> want this behavior globally.
>
>> However the main reason to add this option is to address
>> another issue. Consider the below topology where logical switches
>> sw0 and sw1 are connected lr0. lr0 is also connected to a
>> public switch which is not shown here.
>>
>> switch 8144b9c4-b38f-47db-a403-62283c8a5756 (sw0)
>> port sw0-port2
>> addresses: ["50:54:00:00:00:04 10.0.0.4"]
>> port sw0-port1
>> addresses: ["50:54:00:00:00:03 10.0.0.3"]
>> port sw0-lr0
>> type: router
>> addresses: ["00:00:00:00:ff:01"]
>> router-port: lr0-sw0
>>
>> switch 8f53c293-9486-49ff-9e62-98ea3408ee2e (sw1)
>> port sw1-port2
>> addresses: ["40:54:00:00:00:04 20.0.0.4"]
>> port sw1-lr0
>> type: router
>> addresses: ["00:00:00:00:ff:02"]
>> router-port: lr0-sw1
>> port sw1-port1
>> addresses: ["40:54:00:00:00:03 20.0.0.3"]
>>
>> ovn-nbctl lr-nat-list lr0
>> TYPE EXTERNAL_IP LOGICAL_IP EXTERNAL_MAC
>> LOGICAL_PORT
>> dnat_and_snat 172.168.0.110 10.0.0.3 50:54:00:00:00:03
>> sw0-port1
>> dnat_and_snat 172.168.0.120 20.0.0.3 40:54:00:00:00:04
>> sw1-port1
>>
>> Here the logical port's mac is also used as external mac in the NATs.
>>
>> ovn-northd adds the below logical flow in both the sw0 and sw1 pipeline
>>
>> table=28(ls_in_l2_lkup ), priority=75 ,
>> match=(eth.src == {.., 50:54:00:00:00:03, 40:54:00:00:00:04, ..}
>> && (arp.op == 1 || rarp.op == 3 || nd_ns)),
>> action=(outport = "_MC_flood_l2"; output;)
>>
>> This lflow is added to broadcast the self originated GARP packets.
>> Most likely to broadcast the GARPs generated by ovn-controller
>> and where the router MAC is used as source address [2].
>> Seems like this flow should have been added only on the logical switches
>> connected to the router if the IPs are reachable from it.
>>
>
> Just a note, the behavior before [2] was to always flood so I think this
> is not necessarily a problem introduced by [2] (32f5ebb06226
> ("ovn-northd: Limit ARP/ND broadcast domain whenever possible.")).
>
> The problem [2] was trying to avoid was determining whether a packet is
> GARP. There's no easy way to do that today without adding a per-OVN-IP
> flow which might be prohibitive from performance perspective.
>
> Adding Ilya in CC because we had an offline discussion regarding the
> possibility of adding an OVS extension to allow OVN to match on "packet
> is GARP". That would definitely simplify OVN's life in this case.
Yeah, the idea would be to create a new action like is_garp() or maybe a more
generic cmp(regA, regB), since "is it GARP?" is not a straightforward question
to answer and so it may be better to offload that decision to OVN. In OpenFlow
we would store the result of that action in the register and use as a match on
resubmit, e.g.
table:0, arp, actions:reg9[5]=cmp(arp_spa, arp_tpa),resubmit(1,)
table:1, arp,reg9[5]=1, actions:drop
This would solve the problem of creating too many OpenFlow rules, but it would
still result in creating a separate datapath flow per packet, since both values
will have to be exact matched if they are equal (we may only match on one bit
that is different, if there is one, but if they are equal we'll have to match on
all the bits). This may be avoided by creating a corresponding datapath action
as well in a form of call+recirc or in a style of check_pkt_len with different
action lists per result. But note that these will likely not be offloadable,
though ARP traffic is generally handed in userspace for the most part, so that
may not be a problem.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
