RIP+ 5K routes: high access time via vtysh

[ak503]

Hello!
In frr-7.3.1 i have next test-config:

-----5k_nets----(enp0s9)[R1]---enp0s8---[R2](enp0s9)----
R1:

interface enp0s8
 ip address 192.168.1.1/24
!
interface enp0s9
 ip address 10.11.0.1/24
 ip address 10.11.1.1/24
 ip address 10.11.2.1/24
 ...
   5K adresses.
 ...
router rip
 network enp0s9
 neighbor 192.168.1.2
 timers basic 600 3600 2400

R2:

interface enp0s8
 ip address 192.168.1.2/24
!
interface enp0s9
 ip address 172.16.1.1/24
!
router rip
 neighbor 192.168.1.1
 network enp0s9
 timers basic 600 3600 2400
 version 2
!

On R1 i have very high access time via vtysh. (vtysh is blocked, when rip send many routes)

[donaldsharp]

Can you grab a perf flamegraph of rip when it is experiencing issues? https://github.com/FRRouting/frr/wiki/Perf-Recording

[donaldsharp]

Secondly what are you actuallytrying to do. Having 5k addresses on an interface seems like a bad idea imo( I can't imagine that there are not lots of places where code is not optimized for this size )

[ak503]

5k addresses on an interface - it for example. I have 5k tunnels

[donaldsharp]

if you have 5k tunnels you would have 5k interfaces on linux with each interface having a ip address, not 1 interface w/ 5k addresses. Hence my question. What are you really trying to do?

[ak503]

i want send via rip many networks (routes). Many tunnels or many ip on one interface - its does not matter. Many networks.
When ripd sends all routes (networks), vtysh is not available

[rwestphal]

I could reproduce this problem and record a flamegraph. Here's it: ripd.svg.zip (edit: this is an SVG file with a .zip extension, not a real zip file)

The problem only happens when you have a large amount of IP addresses in a single interface. So, for example, 5k interfaces with one IP address each scales well.

The slowness comes from how ripd performs split-horizon suppression for connected routes. For details please see https://github.com/FRRouting/frr/blob/base_7.4/ripd/ripd.c#L2201-L2243 and commit 9920df0.

One way to fix this would be to turn the interface list of connected addresses (ifp->connected) into a routing table, so that rip_output_process() would be able to do a single prefix_match() which would encompass all of the interface addresses. That data structure change would also allow us to optimize important functions like if_lookup_prefix(), if_lookup_exact_address(), if_lookup_by_ipv4() and others.

@ak503 if you really need that much addresses in a single interface, the only workaround for now would be to disable split-horizon using "no ip rip split-horizon" (which can cause routing loops depending on your network topology) or use a different routing daemon.