Comment 4 for bug 2029952

for context it would appear that the main culprit for triggering this is when neutron calls to [1] on hosts that have large numbers of devices.

In ussuri this is from the following places:

$ egrep -r "\.get_devices(|_info)\(" neutron/{agent,plugins}
neutron/agent/windows/ip_lib.py: for device in self.get_devices():
neutron/agent/linux/dhcp.py: for d in ns_ip.get_devices():
neutron/agent/linux/ip_lib.py: return not self.get_devices()
neutron/agent/l3/namespaces.py: for d in ns_ip.get_devices():
neutron/agent/l3/dvr_fip_ns.py: devices = ip_wrapper.get_devices()
neutron/agent/l3/dvr_fip_ns.py: for d in ip_wrapper.get_devices():
neutron/agent/l3/dvr_edge_router.py: for d in ns_ip.get_devices():
neutron/agent/l3/dvr_snat_ns.py: for d in ns_ip.get_devices():
neutron/agent/l3/router_info.py: ip_devs = ip_wrapper.get_devices()
neutron/plugins/ml2/drivers/macvtap/agent/macvtap_neutron_agent.py: devices = ip_lib.IPWrapper().get_devices(True)
neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py: devices = self.ip.get_devices(True)

I have personally found that in a l3ha+dvr environment with > 200 routers, neutron hitting this limit when scanning the fip ns devices.

[1] https://github.com/openstack/neutron/blob/97429dc916c09641f63d69edb3759875a5798e78/neutron/agent/linux/ip_lib.py#L1439