On Tue, Jul 23, 2019 at 4:57 PM Dumitru Ceara <[email protected]> wrote: > > On Tue, Jul 23, 2019 at 4:26 PM Han Zhou <[email protected]> wrote: > > > > > > > > On Tue, Jul 23, 2019 at 4:05 AM Dumitru Ceara <[email protected]> wrote: > > > > > > Add a restriction on the target protocol address to match the configured > > > subnet. All other ARP packets are invalid in this context. > > > > > > Reported-at: https://bugzilla.redhat.com/1729846 > > > Reported-by: Haidong Li <[email protected]> > > > CC: Han Zhou <[email protected]> > > > Fixes: b068454082f5 ("ovn-northd: Support learning neighbor from ARP > > > request.") > > > Signed-off-by: Dumitru Ceara <[email protected]> > > > --- > > > ovn/northd/ovn-northd.c | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c > > > index eb6c47c..29fc726 100644 > > > --- a/ovn/northd/ovn-northd.c > > > +++ b/ovn/northd/ovn-northd.c > > > @@ -6326,9 +6326,12 @@ build_lrouter_flows(struct hmap *datapaths, struct > > > hmap *ports, > > > for (int i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) { > > > ds_clear(&match); > > > ds_put_format(&match, > > > - "inport == %s && arp.spa == %s/%u && arp.op == > > > 1", > > > + "inport == %s && arp.spa == %s/%u && " > > > + "arp.tpa == %s/%u && arp.op == 1", > > > op->json_key, > > > op->lrp_networks.ipv4_addrs[i].network_s, > > > + op->lrp_networks.ipv4_addrs[i].plen, > > > + op->lrp_networks.ipv4_addrs[i].network_s, > > > op->lrp_networks.ipv4_addrs[i].plen); > > > if (op->od->l3dgw_port && op == op->od->l3dgw_port > > > && op->od->l3redirect_port) { > > > -- > > > 1.8.3.1 > > > > > > > Thanks for the fix. It looks good to me! Just to remind that for the CPU > > problem reported in the bug report, this patch may not completely fix it. > > For example, instead of using 0.0.0.0 as tpa, the test client can still > > flood ARP requests using IP in the subnet. It can also flood ARP response > > packets. ARP rate limiting would be needed to solve the problem. > > Hi Han, > > Thanks for reviewing! > > I guess there are two cases: > 1. valid ARP packets for IPs in the subnet which should reach the > controller and are currently not rate limited > 2. "invalid" ARP packets for IPs outside the subnet: this patch fixes > the ARP requests but I need to fix the ARP replies. I'll send a v2 to > address that part too.
I just posted v2 which now covers all types of ARP/ND packets (not only requests): https://patchwork.ozlabs.org/patch/1137258/ Thanks, Dumitru > > For point 1 above I think the problem is common for all control > packets that need to go to controller (e.g., IGMP too). We currently > don't rate limit anything and we should have a control plane > protection policy in place but i guess it's a bit outside the scope of > this fix. > > Regards, > Dumitru > > > > > Acked-by: Han Zhou <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
