Bird performance issue with many PPPOE interfaces and a large routing table.

[Maria Matejka]

Hello!

On 7/5/22 8:48 PM, LU wrote:
> I wanted to optimize this by feeding routes from BGP1/BGP2 to PPPOE 
> SERV1/ SERV2. Now such unnecessary jumping back and forth between 
> BGP1/BGP2 of packets from PPPOE SERVERS would be kept to a minimum.
> 
> However with the following setup, where I now feed /24 and lower routes 
> from a combination of the upstream providers to PPPOE Servers (about 
> 800k routes) I face performance issues that causes a mild packet loss on 
> the PPPOE Servers (which is not present if only default routes are used).

Well, my first thought would be to separate the routing tables, to have 
one for PPPOE daemons and another for full BGP, as the PPPOE daemon 
quite obviously scans the whole table or processes the routes added by 
BIRD in some way.

If it is possible to harmlessly make the PPPOE daemon think that there 
is just a single default route and do the routing on the (virtual) next hop.

We're thinking about creating a route aggregator inside BIRD, capable of 
condensing the full BGP into a minimal route set suitable for local use. 
That feature may help these use cases where the full BGP set is 
annoyingly big for no good reason.

Maria