Re: [LARTC] dst cache overflow (bridged wan interfaces)
The problem appears to be in the routes patch (after 1 day with 1 workstation with amule configured very agresively). I'm trying now the 2.6.19.2 kernel with the configuration exposed here, I'll tell you if the problem were (or not) the patch for dead-gw-detection/multipath-routes from nano-howto. Perhaps this patch is for specific configuration and need more accurate routes config (don't know). As I said: I'll say if I the problem persist in some days. Thank you very much. Regards El Mie, 10 de Enero de 2007, 21:14, ArcosCom Linux User escribió: > I recompiled yet 2.6.19.1 kernel (using iptables with the same patches > too). > > The configuration for this test is: >1) linux box with 2.6.19.1 kernel (SMP machine) with these > patches/modules: > a) l7-filter > b) ipp2p > c) connlimit > d) set >2) 4 ethernet interfaces: > a) 2 external (eth1 and eth3) interfaces with balanced links (as > described in nato-howto) bridged as wan0 with static IPs assigned to > wan0 and wan0:1 > b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP > enabled and configured. > > IPTABLES relevant configuration: > # iptables -t nat -vn -L POSTROUTING > Chain POSTROUTING (policy ACCEPT 185 packets, 16649 bytes) > pkts bytes target prot opt in out source > destination >26 1529 MASQUERADE 0-- * wan010.1.1.0/27 > 0.0.0.0/0 > 0 0 MASQUERADE 0-- * wan0:1 10.1.1.0/27 > 0.0.0.0/0 > > > ROUTES CONFIGURATION: > # service rt status > === REGLAS DE ENRUTAMIENTO === > 0: from all lookup local > 50: from all lookup main > 151:from NET_PUB1 lookup 151 > 152:from NET_PUB2 lookup 152 > 220:from all lookup 220 > 32766: from all lookup main > 32767: from all lookup default > === TABLAS DE RUTAS === > === MAIN === > NET_PUB1/26 dev wan0 proto kernel scope link src IP_PUB1 > NET_PUB2/24 dev wan0 proto kernel scope link src IP_PUB2 > 192.168.3.0/24 dev zlan0 proto kernel scope link src 192.168.3.247 > 192.168.2.0/24 dev zlan0 proto kernel scope link src 192.168.2.247 > 192.168.1.0/24 dev zlan0 proto kernel scope link src 192.168.1.247 > 10.1.1.0/24 dev zlan0 proto kernel scope link src 10.1.1.6 > 169.254.0.0/16 dev zlan0 scope link > 239.0.0.0/8 dev zlan0 scope link > === wan0 TABLA 151 === > default via GW_PUB1 dev wan0 proto static src IP_PUB1 > prohibit default proto static metric 1 > === wan0 TABLA 152 === > default via GW_PUB2 dev wan0 proto static src IP_PUB2 > prohibit default proto static metric 1 > === TABLA 220 (defecto) === > default proto static > nexthop via GW_PUB1 dev wan0 weight 1 > nexthop via GW_PUB2 dev wan0 weight 1 > > ROUTING parameters configuration: > # grep . /proc/sys/net/ipv4/route/* > /proc/sys/net/ipv4/route/error_burst:5000 > /proc/sys/net/ipv4/route/error_cost:1000 > grep: /proc/sys/net/ipv4/route/flush: Operación no permitida > /proc/sys/net/ipv4/route/gc_elasticity:8 > /proc/sys/net/ipv4/route/gc_interval:60 > /proc/sys/net/ipv4/route/gc_min_interval:0 > /proc/sys/net/ipv4/route/gc_min_interval_ms:500 > /proc/sys/net/ipv4/route/gc_thresh:32768 > /proc/sys/net/ipv4/route/gc_timeout:300 > /proc/sys/net/ipv4/route/max_delay:10 > /proc/sys/net/ipv4/route/max_size:524288 > /proc/sys/net/ipv4/route/min_adv_mss:256 > /proc/sys/net/ipv4/route/min_delay:2 > /proc/sys/net/ipv4/route/min_pmtu:552 > /proc/sys/net/ipv4/route/mtu_expires:600 > /proc/sys/net/ipv4/route/redirect_load:20 > /proc/sys/net/ipv4/route/redirect_number:9 > /proc/sys/net/ipv4/route/redirect_silence:20480 > /proc/sys/net/ipv4/route/secret_interval:600 > > When I test it along some weeks with intensive traffic I'll put here more > info about this test. > > If somebody has any idea on how to solve the problem, please, tell us. I'm > a bit desesperate with this issue. > > Regards > > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: dst cache overflow
Thanks, good tool: I'm using it to take a view into the routes table. El Mie, 10 de Enero de 2007, 20:40, Jesper Dangaard Brouer escribió: > > The values looks reasonable, garbage collection start (gc_thresh:32768) > fairly early, but I often see that the GC cannot keep up. > > The maximum size of the route cache max_size=524288 is okay, but it > depends on the usage pattern. On my production systems I has increased > max_size to 2 million, to keep up! > > Another interesting value is secret_interval:600, which is the interval > the route cache is flushed, in seconds, that is 10 minuts. > > 524288/600 = 873 packet/sec to new destinations. > > You should realize that filling the route cache in 10 minuts can happen, > as it only requires 873 packet/sec to new destinations. > > > What to do next: > > Monitor the route cache, to see whats actually happening. The route cache > counters are located in /proc/net/stat/rt_cache, but is not very human > readable. Use the tool "rtstat" to monitor the route cache. > > The rtstat tool can be downloaded from Roberts site: > ftp://robur.slu.se/pub/Linux/net-development/rt_cache_stat > > Cheers, >Jesper Brouer > > -- > --- > MSc. Master of Computer Science > Dept. of Computer Science, University of Copenhagen > Author of http://www.adsl-optimizer.dk > --- > > > > On Wed, 10 Jan 2007, ArcosCom Linux User wrote: > >> Here are: >> >> # grep . /proc/sys/net/ipv4/route/* >> /proc/sys/net/ipv4/route/error_burst:5000 >> /proc/sys/net/ipv4/route/error_cost:1000 >> grep: /proc/sys/net/ipv4/route/flush: Operación no permitida >> /proc/sys/net/ipv4/route/gc_elasticity:8 >> /proc/sys/net/ipv4/route/gc_interval:60 >> /proc/sys/net/ipv4/route/gc_min_interval:0 >> /proc/sys/net/ipv4/route/gc_min_interval_ms:500 >> /proc/sys/net/ipv4/route/gc_thresh:32768 >> /proc/sys/net/ipv4/route/gc_timeout:300 >> /proc/sys/net/ipv4/route/max_delay:10 >> /proc/sys/net/ipv4/route/max_size:524288 >> /proc/sys/net/ipv4/route/min_adv_mss:256 >> /proc/sys/net/ipv4/route/min_delay:2 >> /proc/sys/net/ipv4/route/min_pmtu:552 >> /proc/sys/net/ipv4/route/mtu_expires:600 >> /proc/sys/net/ipv4/route/redirect_load:20 >> /proc/sys/net/ipv4/route/redirect_number:9 >> /proc/sys/net/ipv4/route/redirect_silence:20480 >> /proc/sys/net/ipv4/route/secret_interval:600 >> >> >> El Mie, 10 de Enero de 2007, 16:01, Jesper Dangaard Brouer escribió: >>> >>> >>> On Wed, 10 Jan 2007, ArcosCom Linux User wrote: >>> El Mie, 10 de Enero de 2007, 8:15, Patrick McHardy escribió: > ArcosCom Linux User wrote: >> The log says: >> Dec 30 00:52:27 cura kernel: dst cache overflow >>> >>> The log message "dst cache overflow" is normally related to overflow of >>> the route cache. The max_size of the route cache can be adjusted >>> through >>> /proc/sys/net/ipv4/route/max_size. >>> >>> What is your settings in /proc/sys/net/ipv4/route/? >>> >>> Run command: >>> grep . /proc/sys/net/ipv4/route/* >>> >>> Hilsen >>>Jesper Brouer >>> >>> -- >>> --- >>> MSc. Master of Computer Science >>> Dept. of Computer Science, University of Copenhagen >>> Author of http://www.adsl-optimizer.dk >>> --- > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] IPP2P Problem
On Fri, 12 Jan 2007 08:33:17 +1300, Rangi Biddle wrote > Hi Tomasz, Hi Rangi. > Thank you for the reply. > > I have checked the Makefile and unfortunately it is using the respective > gcc. Output of Makefile below: > > libipt_ipp2p.so: libipt_ipp2p.c ipt_ipp2p.h > $(CC) $(CFLAGS) $(IPTABLES_OPTION) $(IPTABLES_INCLUDE) -fPIC > -c libipt_ipp2p.c What about line below?! ;-) * ld -shared -o libipt_ipp2p.so libipt_ipp2p.o * Replace ld by $(CC). > Any other suggestions? As above ;-) > Rangi Bests, Tomasz. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] filtering in layer 2 [but is not a bridge]
Isn't an AP just a bridge with a wireless interface? Luciano Ruete wrote: On Tuesday 09 January 2007 11:00, Zoilo Gomez wrote: ebtables from ebtables home page: "The ebtables utility enables basic Ethernet frame filtering on a Linux bridge" I have _not_ a bridge (that's why i put it in the subject), i have a Linux AP that forward traffic betwen clients at 802.11 level. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] filtering in layer 2 [but is not a bridge]
On Tuesday 09 January 2007 11:00, Zoilo Gomez wrote: > ebtables from ebtables home page: "The ebtables utility enables basic Ethernet frame filtering on a Linux bridge" I have _not_ a bridge (that's why i put it in the subject), i have a Linux AP that forward traffic betwen clients at 802.11 level. -- Luciano ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] help
Pagarbiai Darius Evseicikas == UAB "PROGMERA" Maironio g. 3, LT-60149, Raseiniai tel./faks. +370 428 70329 mob. +370 699 97390 ICQ 297832308 Informacija šiame pranešime gali būti konfidenciali. Ji skirta tik asmeniui, kuriam yra adresuota. Jei Jūs nesate tas asmuo (arba atsakingas už šio pranešimo pristatymą tam asmeniui), Jūs negalite skaityti, kopijuoti ar bet kaip platinti šio pranešimo viso ar iš dalies ir skleisti jame esančios informacijos. Jei šį pranešimą gavote per klaidą, prašome informuoti apie tai siuntėją ir iškart ištrinti visas šio pranešimo kopijas iš Jūsų sistemos.___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IPP2P Problem
On Thu, 11 Jan 2007 16:26:18 +1300, Rangi Biddle wrote > Hi Guys, Hi Rangi. > I am currently using linux kernel 2.6.18.6 + l7filter patch, > iptables 1.3.7 and have managed to compile the ipp2p shared object > which is now sitting in /lib/iptables. > > However when I run the following I get this following error > > [EMAIL PROTECTED] ~]# iptables -m ipp2p --help > > iptables v1.3.7: Couldn't load match `ipp2p' > > Try `iptables -h' or 'iptables --help' for more information. In ipp2p Makefile find libipt_ipp2p.so make definition and make sure you've got: $(CC) -shared -o libipt_ipp2p.so libipt_ipp2p.o Probably there's ld -shared -o libipt_ipp2p.so libipt_ipp2p.o over there and it's mistake. > Regards, > Rangi Bests, Tomasz. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
