Bird 2.0.8 + uClibc-ng, BGP RR + OSPF - OSPF falls to 'Alone' state at BGP routes recalculation
Hi all. I have Bird 2.0.8 on one of border routers, it runs with kernel 5.10.26 and uClibc-ng 1.0.38. It acts as RR and receives FV from uplink + FV from second border (also RR), and it has 2 routing tables (one which receives BGP routes, then routes sinks to main table. When second border's BGP link fails, Bird starts to rebuild routing table, and acts quite strange (too slow birdc response, etc) and after ~5 minutes OSPF looses neighbors and falls to state 'Alone'. It can be in that state for hours, and initiated only after bird restart (I didn't tried protocol restart - usually I don't wait for end of route table recalculation). When table recalculation is in progress, perf top shows that 40+% CPU time is used by malloc routine. Are there fixes in trunk for such behavior? If no - what extra info is needed for debugging?
Hello! Do you have any log? Are you able to replicate such a behavior consistently? If so, could you please share an exact configuration with us to put it into our testbed? You can also enable "debug protocols all;" in your conf file. This produces a s***load of logs, yet it should yield enough clues to isolate the problem and find a suitable solution. Thank you for your report! Maria On September 24, 2021 3:13:45 PM UTC, Andrew <nitr0@seti.kr.ua> wrote:
Hi all.
I have Bird 2.0.8 on one of border routers, it runs with kernel 5.10.26 and uClibc-ng 1.0.38. It acts as RR and receives FV from uplink + FV from second border (also RR), and it has 2 routing tables (one which receives BGP routes, then routes sinks to main table.
When second border's BGP link fails, Bird starts to rebuild routing table, and acts quite strange (too slow birdc response, etc) and after ~5 minutes OSPF looses neighbors and falls to state 'Alone'. It can be in that state for hours, and initiated only after bird restart (I didn't tried protocol restart - usually I don't wait for end of route table recalculation).
When table recalculation is in progress, perf top shows that 40+% CPU time is used by malloc routine.
Are there fixes in trunk for such behavior? If no - what extra info is needed for debugging?
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi. Yes, it's repeatable always. I'll try to enable debug and reproduce it in next days. Config file (with replaced networks and shrinked comments + legacy unused filters/functions) is attached. It seems like uclibc-ng has slow memory allocator, and it triggers hidden Bird bug. 24.09.2021 19:53, Maria Matějka пишет:
Hello!
Do you have any log? Are you able to replicate such a behavior consistently? If so, could you please share an exact configuration with us to put it into our testbed?
You can also enable "debug protocols all;" in your conf file. This produces a s***load of logs, yet it should yield enough clues to isolate the problem and find a suitable solution.
Thank you for your report!
Maria
On September 24, 2021 3:13:45 PM UTC, Andrew <nitr0@seti.kr.ua> wrote:
Hi all.
I have Bird 2.0.8 on one of border routers, it runs with kernel 5.10.26 and uClibc-ng 1.0.38. It acts as RR and receives FV from uplink + FV from second border (also RR), and it has 2 routing tables (one which receives BGP routes, then routes sinks to main table.
When second border's BGP link fails, Bird starts to rebuild routing table, and acts quite strange (too slow birdc response, etc) and after ~5 minutes OSPF looses neighbors and falls to state 'Alone'. It can be in that state for hours, and initiated only after bird restart (I didn't tried protocol restart - usually I don't wait for end of route table recalculation).
When table recalculation is in progress, perf top shows that 40+% CPU time is used by malloc routine.
Are there fixes in trunk for such behavior? If no - what extra info is needed for debugging?
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
participants (2)
-
Andrew -
Maria Matějka