[LARTC] Re: dst cache overflow

[Alexandru Dragoi]

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 at mailman.ds9a.nl
>> 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 at mailman.ds9a.nl
> 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).