On Fri, Mar 28, 2025 at 6:11 AM Aleksandr Smirnov (K2 Cloud) <[email protected]> wrote: > > Hello, > > We experienced one issue with ARP cache propagation to the mac_binding > table. > Roughly, we have the following structure: > A logical router having a port that is detected as a gateway port. > It is attached to the logical switch that has one vtep port and several > logcial > ports. Also, the same router's port has a HA group assigned to it. > > Finally, we have a logical router port, recognized as a gateway port and > it has > the cr-* counterpart that is the chassisredirect. > > Then we try to announce ARP pair to cache starting from one of the logical > switch ports residing on the same switch as vtep port is. > > We see the following behavior: > 1. If we announce ARP with Reply command all is ok. > 2. If we use ARP Request command it depends on the fact an issuing port > resides > on active HA group member. If it is not, mac_binding table is not updated. > > Investigation shows that the reason of such behavior is in following lflows > generated for conditions described abouve: > > table=1 (lr_in_lookup_neighbor), priority=100, match=(arp.op == 2), > action=(reg9[2] = lookup_arp(inport, arp.spa, arp.sha); next;) > table=1 (lr_in_lookup_neighbor), priority=100, match=(inport == "down1" > && arp.spa == 192.168.0.0/24 && arp.op == 1 > && is_chassis_resident("cr-down1")), > action=(reg9[2] = lookup_arp(inport, arp.spa, arp.sha); next;) > > You can see that ARP replies are always allowed while arp requesta only > pass thru (and later comes to the mac_binding table update) only if a > request > comes from a valid port/network AND controller is resident on the active HA > group member. > > So, we have two questions arised: > > 1. What is a reason lflow restricts ARP requests by resident chassis only? > Is this a bug or desired behavior? If this is a bug how can I fix it > properly? >
It is the desired behavior. Please take a look at this commit which added this behavior - https://github.com/ovn-org/ovn/commit/783337b24c3f68798752b1dcbbe48adc75cdfa59 > 2. Why are all ARP replies allowed? In terms of ARP cache annonce > both ways (use request / reply) are equivalent. When OVN doesn't know the mac address of the next hop ip in a router pipeline, the packet is sent to ovn-controller and it generates an ARP request for it. When the ARP reply is received we want to learn it and create a mac binding for it. Hence we allow ARP replies. We do learn mac bindings from arp requests, but only if required. The commit message has more details. The ARP requests are learnt only on the resident chassis only because that is the gateway node for the North-South traffic and hence it makes sense for this gateway chassis to learn mac bindings. Thanks Numan > > Thank you, > > Alexander > > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
