On Wed, Oct 23, 2019 at 12:11 AM Dumitru Ceara <[email protected]> wrote: > > ARP request and ND NS packets for router owned IPs were being > flooded in the complete L2 domain (using the MC_FLOOD multicast group). > However this creates a scaling issue in scenarios where aggregation > logical switches are connected to more logical routers (~350). The > logical pipelines of all routers would have to be executed before the > packet is finally replied to by a single router, the owner of the IP > address. > > This commit limits the broadcast domain by bypassing the L2 Lookup stage > for ARP requests that will be replied by a single router. The packets > are still flooded in the L2 domain but not on any of the other patch > ports towards other routers connected to the switch. This restricted > flooding is done by using a new multicast group (MC_ARP_ND_FLOOD). > > IPs that are owned by the routers and for which this fix applies are: > - IP addresses configured on the router ports. > - VIPs. > - NAT IPs. > > Reported-at: https://bugzilla.redhat.com/1756945 > Reported-by: Anil Venkata <[email protected]> > Signed-off-by: Dumitru Ceara <[email protected]> >
Thanks Dumitru for addressing the issue. I have only one concern, but I am not sure if it would cause real issue. The concern is, this patch changes the behavior that originally if there is any ARP request broadcasted by an external routers, all OVN routers will learn the MAC-IP bindings from the ARP request, but with this change only the one with the requested IP would learn it. At the same time, what if an ARP response (or GARP) is coming? Would it still trigger the same problem since it has to go through all router pipelines? Thanks, Han _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
