The problem I am about to describe emerged on several configurations. I had it on FreeBSD 8.3 as well as 9.1, though the output of the panic message in 8.3 was not that informative, as in 9.1
There are two NAS servers, running FreeBSD 9.1, using mpd5.6 as PPPoE server and Quagga 0.99.22 as OSFP router. Accasionaly, once in a month or so, one of the servers might fail with the following kernel panic message.
Though it shows the problem on ng interface, I believe, that Quagga causes the problem.
How it happens. When a number of ng interfaces are starting up, Quagga adds it to its configuration with ip ospf network option enabled by default, though there is a line passive-interface default in ospfd.conf.
Eventually, as Quagga does so, the OSPF database on both servers starts to update severly and on of them crashes.
The "solution" that I use now is to manually reconfigure new ng interfaces via Quagga OSPF console. That helps for a few weeks, but then one of the server for some reason fails again.
Is there a way to teach Quagga to read the configuration properly, or somehow "enforce" the server so it will withstand the load?
There are two NAS servers, running FreeBSD 9.1, using mpd5.6 as PPPoE server and Quagga 0.99.22 as OSFP router. Accasionaly, once in a month or so, one of the servers might fail with the following kernel panic message.
Code:
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 0 (eml que)
trap number = 18
panic: integer divide fault
cpuid = 4
KDB: stack backtrace:
#0 0xffffffff80943986 at kdb_backtrace+0x66
#1 0xfffffff f8090d99e at panic+0xlce
#2 0xffffffff80be5bl0 at trap_fata1+0x290
#3 0xffffffff80be61a5 at trap+0xl05
#4 0xffffffff80bd0a2f at calltrap+0x8
#5 0xffffffff8162f126 at ng_bpf_rcvdata+0x66
#6 0xffffffff80al47a8 at ng_apply_item+0x208
#7 0xffffffff80al390e at ng_snd_item+0x39e
#8 0xffffffff816207be at ng_iface_send+0xee
#9 0xffffffff81620bd3 at ng_iface_output+0xlb3
#10 0xffffffff80a33252 at ip_fastforward+0x752
#11 0xffffffff809c64el at ether_demux+0xl31
#12 0xffffffff809c67c4 at ether_nh_input*0xlf4
#13 0xffffffff809d057b at netisr_dispatch_src+0x20b
#14 0xf f f f f ff f804d216a at em_rxeof+0xlca
#15 0xffffffff804d25e8 at em_handle_que+0x48
#16 0xffffffff80950035 at taskqueue_run_locked+0x85
#17 0xffffffff80950fb6 at taskqueue_thread_loop+0x46Though it shows the problem on ng interface, I believe, that Quagga causes the problem.
How it happens. When a number of ng interfaces are starting up, Quagga adds it to its configuration with ip ospf network option enabled by default, though there is a line passive-interface default in ospfd.conf.
Eventually, as Quagga does so, the OSPF database on both servers starts to update severly and on of them crashes.
The "solution" that I use now is to manually reconfigure new ng interfaces via Quagga OSPF console. That helps for a few weeks, but then one of the server for some reason fails again.
Is there a way to teach Quagga to read the configuration properly, or somehow "enforce" the server so it will withstand the load?