ArcosCom Linux User wrote: > The log says: > > Dec 30 00:52:27 cura kernel: dst cache overflow > Dec 30 00:52:27 cura kernel: MASQUERADE: No route: Rusty's brain broke! > Dec 30 00:52:27 cura kernel: dst cache overflow > Dec 30 00:52:28 cura kernel: zlan0: received tcn bpdu on port 1(eth0) > Dec 30 00:52:28 cura kernel: zlan0: topology change detected, propagating > Dec 30 00:52:28 cura kernel: dst cache overflow > Dec 30 00:52:30 cura kernel: zlan0: received tcn bpdu on port 1(eth0) > Dec 30 00:52:30 cura kernel: zlan0: topology change detected, propagating > Dec 30 00:52:32 cura kernel: zlan0: received tcn bpdu on port 1(eth0) > Dec 30 00:52:32 cura kernel: zlan0: topology change detected, propagating > Dec 30 00:52:32 cura kernel: printk: 15 messages suppressed. > Dec 30 00:52:32 cura kernel: dst cache overflow > Dec 30 00:52:34 cura kernel: zlan0: received tcn bpdu on port 1(eth0) > Dec 30 00:52:34 cura kernel: zlan0: topology change detected, propagating > Dec 30 00:52:36 cura kernel: zlan0: received tcn bpdu on port 1(eth0) > Dec 30 00:52:36 cura kernel: zlan0: topology change detected, propagating > Dec 30 00:52:37 cura kernel: printk: 40 messages suppressed. > Dec 30 00:52:37 cura kernel: dst cache overflow > > zlan0 is a bridge (with STP configured) between some LANs. > > Thanks > > P.D.: I'm a bit desesperated with this error, I changed "MASQUERADE" with > "SNAT" with no sense. Some hours after router is booted up, the network > appears to be UP but all ifaces haven't responses. > > El Mar, 2 de Enero de 2007, 23:24, ArcosCom Linux User escribió: > >> Hi all, I'm having this problem with this system configuration: >> 1) iptables 1.3.7 >> 2) kernel 2.6.19.1 >> 3) SMP computer >> 4) 2 external links + 2 internal (bridged). >> >> Some hours after the system is working without any troubles, all network >> devices stop respond. >> >> Anyone could help me to fix this problem? >> >> Googling some ours I detect that this was a problem with old kernels and >> were solved with 2.6.11 kernel version. >> >> Any help will be appretiated. >> >> Regards. >> >> P.D.: With MASQUERADE the problem begans more quickly than with SNAT >> target. >> > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > The generic solution is to make less/better use of the CPU resources. In particular, it is good to tune a lot of parrametters, like /proc/sys/net/ipv4/neigh/default/gc_threshx, where x is 1,2 or 3. echo 2048 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 Then, check/tune whatever consume CPU, iptables firewall, tc filters, lots of routes and heavy pachekts/second traffic, and so on. You can check with top how resources are used, for start. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
