Alexandru Dragoi wrote: > 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 > Now i see the bpdu packets received by your bridge. Seem you may have some network loop, wich generated lots of broadcast traffic (wich includes arp). _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc