Re: [neutron][ovn] Logical flow scaling (flow explosion in lr_in_arp_resolve)

Krzysztof Klimonda kklimonda at syntaxhighlighted.com
Thu Sep 17 19:14:51 UTC 2020


Hi Tony,

Indeed I forgot to mention that all routers are using the same external network (and subnet) for the external gateway.

Creating separate external networks per router wouldn't really work for us, and I'm not even quite sure what the setup would look like in that case. 

-- 
  Krzysztof Klimonda
  kklimonda at syntaxhighlighted.com

On Thu, Sep 17, 2020, at 20:31, Tony Liu wrote:
> I am trying to reach 5000. The problem I hit is that northd is
> stuck in translating from NB to SB when connect router to external
> network.
> 
> I assume all your 400 routers connect to the same subnet in that
> external network. I am trying another approach where one subnet
> is created for each router in external network. That may help to
> reduce the ARP flow?
> 
> Thanks!
> Tony
> > -----Original Message-----
> > From: Krzysztof Klimonda <kklimonda at syntaxhighlighted.com>
> > Sent: Thursday, September 17, 2020 8:57 AM
> > To: openstack-discuss at lists.openstack.org
> > Subject: [neutron][ovn] Logical flow scaling (flow explosion in
> > lr_in_arp_resolve)
> > 
> > Hi,
> > 
> > We're running some tests of ussuri deployment with ovn ML2 driver and
> > seeing some worrying numbers of logical flows generated for our test
> > deployment.
> > 
> > As a test, we create 400 routes, 400 private networks and connect each
> > network to its own routers. We also connect each router to an external
> > network. After doing that a dump of logical flows shows almost 800k
> > logical flows, most of them in lr_in_arp_resolve table:
> > 
> > --8<--8<--8<--
> > # cat lflows.txt |grep -v Datapath |cut -d'(' -f 2 | cut -d ')' -f1
> > |sort | uniq -c |sort -n | tail -10
> >    3264 lr_in_learn_neighbor
> >    3386 ls_out_port_sec_l2
> >    4112 lr_in_admission
> >    4202 ls_in_port_sec_l2
> >    4898 lr_in_lookup_neighbor
> >    4900 lr_in_ip_routing
> >    9144 ls_in_l2_lkup
> >    9160 ls_in_arp_rsp
> >   22136 lr_in_ip_input
> >  671656 lr_in_arp_resolve
> > #
> > --8<--8<--8<--
> > 
> > ovn: 20.06.2 + patch for SNAT IP ARP reply issue
> > openvswitch: 2.13.0
> > neutron: 16.1.0
> > 
> > I've seen some discussion about similar issue at OVS mailing lists:
> > https://www.mail-archive.com/ovs-discuss@openvswitch.org/msg07014.html -
> > is this relevant to neutron, and not just kubernetes?
> > 
> > --
> >   Krzysztof Klimonda
> >   kklimonda at syntaxhighlighted.com
> 
>



More information about the openstack-discuss mailing list