[LARTC] IPP2P Problem
Hi Guys, 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. I can verify that the shared object is in /lib/iptables [EMAIL PROTECTED] ~]# ls /lib/iptables/ | grep pp2p libipt_ipp2p.so I have checked the permissions on the file [EMAIL PROTECTED] ~]# ls /lib/iptables/ -l | grep pp2p -rwxr-xr-x 1 root root 8448 Jan 11 02:00 libipt_ipp2p.so The system is a CentOS 4.4 system with all the latest updates applied Any help would be appreciated Regards, Rangi PS. The module was loading perfectly fine before upgrading to iptables 1.3.7 - and yes I recompiled the ipp2p module again after upgrading to iptables 1.3.7 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] dst cache overflow (bridged wan interfaces)
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
Re: [LARTC] Re: dst cache overflow
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
[LARTC] Wireless LAN
Hello, I am afraid if I post in an inaproprate forrum. I am novice in the traffic control TC with Linux. I have a R&D project and i should to apply a lot of QoS mecanisms in a wireless environement! I have an access point witch is rely to a PC and three laptops. The PC play a role of a controleur. All traffic must travers throw it. I have configure the AP to only play a role of a forwarder. The tables are configured also and all traffic passe throw the PC. My problem is how i can (begin) use TC in order to differentiate wireless users? have you examples? good tutorials? Thanks! ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: dst cache overflow
On Mi, 2007-01-10 at 14:20 +0100, ArcosCom Linux User wrote: > The configuration is: >1) linux box with 2.6.19.1 kernel with these patches/modules: > a) l7-filter > b) multipath patch (from nano-howto) > c) IMQ That's interesting - how did you get IMQ into 2.6.19.1? Afaik, the most recent patch is for 2.6.17, and there were some rejects if you try to patch it into 2.6.19. Regards, Torsten ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] RSVP source code
All: I'm trying to get RSVP running on a Linux machine. The machine is currently Fedora. I have read rfc 2205. Does anyone know where I can get the RSVP source code to install on the machine. Or does anyone know of some documentation that might help in doing this? Thanks, Jon Flechsenhaar Boeing WNW Team Network Services (714)-762-1231 202-E7 ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: dst cache overflow
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
[LARTC] Re: dst cache overflow
The configuration is: 1) linux box with 2.6.19.1 kernel with these patches/modules: a) l7-filter b) multipath patch (from nano-howto) c) IMQ d) ipp2p e) connlimit 2) 4 ethernet interfaces: a) 2 external (eth1 and eth3) interfaces with balanced links (as described in nato-howto). b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP enabled and configured. 3) For tests I load manually ALL conntrack/nat kernel modules. My first attempt (to allow UPnP daemon to handle only 1 external iface) where put eth1 and eth3 in a bridge without STP enabled and the NAT were done only with -j MASQUERADE and appeared to work fine, but when I run some amule clients along the network, the problem appear in one day (after some weeks working without peers to peers software). Then I broke the wan bridge and put each static external IP into their iface, and the problem appears too in two days instead 1 day. My next step were use SNAT instead MASQUERADE and the problem appears 3 days after the change. Always I had the multipath enableded along these described steps. A production linux box with 2.6.17.14 kernel and the same patches/modules and only 1 wan iface and 1 lan iface and with connlimit match enabled by host is working fine with 100 more p2p traffic than the test machine (the linux box that has de dst cache overflow problem). If you need more info about this to help me in solve this problem, please, say me, I'll get all you need and put here. Thanks 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 >> 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. > > > The MASQUERADE message is just an effect of the problem. Please describe > your setup in more detail (what kind of devices, how are they connected, > ebtables/iptables rules, routing, ...). > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: dst cache overflow
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
[LARTC] Re: dst cache overflow
The configuration is: 1) linux box with 2.6.19.1 kernel with these patches/modules: a) l7-filter b) multipath patch (from nano-howto) c) IMQ d) ipp2p e) connlimit 2) 4 ethernet interfaces: a) 2 external (eth1 and eth3) interfaces with balanced links (as described in nato-howto). b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP enabled and configured. 3) For tests I load manually ALL conntrack/nat kernel modules. My first attempt (to allow UPnP daemon to handle only 1 external iface) where put eth1 and eth3 in a bridge without STP enabled and the NAT were done only with -j MASQUERADE and appeared to work fine, but when I run some amule clients along the network, the problem appear in one day (after some weeks working without peers to peers software). Then I broke the wan bridge and put each static external IP into their iface, and the problem appears too in two days instead 1 day. My next step were use SNAT instead MASQUERADE and the problem appears 3 days after the change. Always I had the multipath enableded along these described steps. A production linux box with 2.6.17.14 kernel and the same patches/modules and only 1 wan iface and 1 lan iface and with connlimit match enabled by host is working fine with 100 more p2p traffic than the test machine (the linux box that has de dst cache overflow problem). If you need more info about this to help me in solve this problem, please, say me, I'll get all you need and put here. Thanks 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 >> 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. > The MASQUERADE message is just an effect of the problem. Please describe your setup in more detail (what kind of devices, how are they connected, ebtables/iptables rules, routing, ...). ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Opinions about pom/patches [was: iptables 1.3.7, kernel 2.6.19, ROUTE and Layer7 issues]
I think so, there are many old matches that are stables and I have to apply many times when I update the kernel. If they where into kernel and iptables (because they are now not as experimental than many months/years ago) these problem when new kernel releases and/or iptables releases disapears very quickly. I have a great headache now, I had to patch my kernel, patch iptables, update iproute to allow "mark-and" operations for routing. Yes, I can adapt many thinks and forgot many routing/filtering functionality, but then, my linux box will be useless for the purposes I deploy it. I have no problem in patch and upgrade thinks, my problem is that I have no time to do all these steps every any important bug, improvement is released. To allow compatibility with my installed distro (one in production and another in testing), I had to readapt the RPM's and modify specs to put there the patch. Usually is easy, but when netfilter changes its internals structs (that I have no knoledgement) I can't correct the patches and adapt them. When I readapt RPM's, I can use them into my systems, and I think many users should want them for their systems and the same purpose as me and I don't know where I can send them to allow people to use them (perhaps I make a simple webpage for that and a RPM repository, but I can't use my lines to allow comunity to massive download the rpm's). Too punctual work that comunity can't improve or maintain because they hasn't got access. Perhaps, when I finish the testing and all the problems I have got in testing environtment were solved, I can make a good repository to allow community to download and upload thinks, but now, I had time to make it. The real problems of all these, I think, are : 1) That the time from a fix/release goes out to that change appears into the distro repositories are enought. 2) Another problem is when there are bugs are fixed in versios and that fix is not backported to prior versions and distros mainteneers have to backport the fix to preserve stable state of the distro package (less features than actual stable sources, but stable system). 3) Another problem is that the patches for bugfixes are not public or easy accesible for normal users as me, and then I not only need to learn how to patch, make and upgrade (or rpm/deb build), I need to learn too how to extract the bugfix patch I need to solve one problem in my kernel/iptables/module/etc... version, what are the developer list, subscribe, where are the development sources that correct the problem, how I can download the patch, etc... I know that all these project are diferent communities, but if all comunities make more easy to the end user some tasks, the users learns more quickly how to contribute and work with the many projects and tecknologies. Don't know how projects could make the thinks easy, but, in case of netfilter, some tables explaining what matches are included in kernel (and from what version) allow users to know what kernel version can use for certain purposes. For example, I know h323 where added into kernel at 2.6.17 kernel version, but the community appears to be working into 2.6.16.x version to stabilize it and and backported many bugfixes from 2.6.19.x to 2.6.16.x. I think 2.6.16.x kernel is the more stable at these days, but if I want h323 conntrack modules I can't use pom-ńg because h323 is not in pom-ng today, and if I use old pom-ng, I know I will use a module with some bugs corrected in 2.6.18.x kernel. Do I explained a problem that have many users than me? Another example, some body say in the lists that using "mark" will allow me to change routes by "mark value" or by "and-mark mask", fine, that were to substitute ROUTE tarjet. I think that is a correct solution but ... What are the implications? 1) I can't see any documentation in netfilter or iproute. 2) My distro don't update the packages, I have to do it manually. 3) When I have an updated iproute package, kernel package, iptables package and I finish and test the configuration, I have the knowledte to write a little explanation/how-to to allow users to know how and don't waste their time looking for the steps ... some hours after I found a wiki, I need to register, etc When I finished all the needed steps to allow me to write a "more or less" public super-mini-howto I forgot the steps and I, finally, don't write the info, because my systems are working for my purposes, I have my paper with my hand annotations and I need to continue working in more tasks. Sorry for the big e-mail, but it is only my user opinion about these type o things. Sorry for my poor english. Regards El Mie, 10 de Enero de 2007, 12:53, Jan Engelhardt escribió: > On Jan 10 2007 06:58, Patrick McHardy wrote: >>Krzysztof Oledzki wrote: Its still down, but the ROUTE patch is unmaintained anyway. >>> How about attached (and inlined) patch. BTW - is it possible to add a Kconfig entry after a specific text, like with Makefile.ladd? >>>
[LARTC] Re: dst cache overflow
The configuration is: 1) linux box with 2.6.19.1 kernel with these patches/modules: a) l7-filter b) multipath patch (from nano-howto) c) IMQ d) ipp2p e) connlimit 2) 4 ethernet interfaces: a) 2 external (eth1 and eth3) interfaces with balanced links (as described in nato-howto). b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP enabled and configured. 3) For tests I load manually ALL conntrack/nat kernel modules. My first attempt (to allow UPnP daemon to handle only 1 external iface) where put eth1 and eth3 in a bridge without STP enabled and the NAT were done only with -j MASQUERADE and appeared to work fine, but when I run some amule clients along the network, the problem appear in one day (after some weeks working without peers to peers software). Then I broke the wan bridge and put each static external IP into their iface, and the problem appears too in two days instead 1 day. My next step were use SNAT instead MASQUERADE and the problem appears 3 days after the change. Always I had the multipath enableded along these described steps. A production linux box with 2.6.17.14 kernel and the same patches/modules and only 1 wan iface and 1 lan iface and with connlimit match enabled by host is working fine with 100 more p2p traffic than the test machine (the linux box that has de dst cache overflow problem). If you need more info about this to help me in solve this problem, please, say me, I'll get all you need and put here. Thanks 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 >> 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. > > > The MASQUERADE message is just an effect of the problem. Please describe > your setup in more detail (what kind of devices, how are they connected, > ebtables/iptables rules, routing, ...). > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: dst cache overflow
The configuration is: 1) linux box with 2.6.19.1 kernel with these patches/modules: a) l7-filter b) multipath patch (from nano-howto) c) IMQ d) ipp2p e) connlimit 2) 4 ethernet interfaces: a) 2 external (eth1 and eth3) interfaces with balanced links (as described in nato-howto). b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP enabled and configured. 3) For tests I load manually ALL conntrack/nat kernel modules. My first attempt (to allow UPnP daemon to handle only 1 external iface) where put eth1 and eth3 in a bridge without STP enabled and the NAT were done only with -j MASQUERADE and appeared to work fine, but when I run some amule clients along the network, the problem appear in one day (after some weeks working without peers to peers software). Then I broke the wan bridge and put each static external IP into their iface, and the problem appears too in two days instead 1 day. My next step were use SNAT instead MASQUERADE and the problem appears 3 days after the change. Always I had the multipath enableded along these described steps. A production linux box with 2.6.17.14 kernel and the same patches/modules and only 1 wan iface and 1 lan iface and with connlimit match enabled by host is working fine with 100 more p2p traffic than the test machine (the linux box that has de dst cache overflow problem). If you need more info about this to help me in solve this problem, please, say me, I'll get all you need and put here. Thanks 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 >> 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. > > > The MASQUERADE message is just an effect of the problem. Please describe > your setup in more detail (what kind of devices, how are they connected, > ebtables/iptables rules, routing, ...). > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Opinions about pom/patches [was: iptables 1.3.7, kernel 2.6.19, ROUTE and Layer7 issues]
I think so, there are many old matches that are stables and I have to apply many times when I update the kernel. If they where into kernel and iptables (because they are now not as experimental than many months/years ago) these problem when new kernel releases and/or iptables releases disapears very quickly. I have a great headache now, I had to patch my kernel, patch iptables, update iproute to allow "mark-and" operations for routing. Yes, I can adapt many thinks and forgot many routing/filtering functionality, but then, my linux box will be useless for the purposes I deploy it. I have no problem in patch and upgrade thinks, my problem is that I have no time to do all these steps every any important bug, improvement is released. To allow compatibility with my installed distro (one in production and another in testing), I had to readapt the RPM's and modify specs to put there the patch. Usually is easy, but when netfilter changes its internals structs (that I have no knoledgement) I can't correct the patches and adapt them. When I readapt RPM's, I can use them into my systems, and I think many users should want them for their systems and the same purpose as me and I don't know where I can send them to allow people to use them (perhaps I make a simple webpage for that and a RPM repository, but I can't use my lines to allow comunity to massive download the rpm's). Too punctual work that comunity can't improve or maintain because they hasn't got access. Perhaps, when I finish the testing and all the problems I have got in testing environtment were solved, I can make a good repository to allow community to download and upload thinks, but now, I had time to make it. The real problems of all these, I think, are : 1) That the time from a fix/release goes out to that change appears into the distro repositories are enought. 2) Another problem is when there are bugs are fixed in versios and that fix is not backported to prior versions and distros mainteneers have to backport the fix to preserve stable state of the distro package (less features than actual stable sources, but stable system). 3) Another problem is that the patches for bugfixes are not public or easy accesible for normal users as me, and then I not only need to learn how to patch, make and upgrade (or rpm/deb build), I need to learn too how to extract the bugfix patch I need to solve one problem in my kernel/iptables/module/etc... version, what are the developer list, subscribe, where are the development sources that correct the problem, how I can download the patch, etc... I know that all these project are diferent communities, but if all comunities make more easy to the end user some tasks, the users learns more quickly how to contribute and work with the many projects and tecknologies. Don't know how projects could make the thinks easy, but, in case of netfilter, some tables explaining what matches are included in kernel (and from what version) allow users to know what kernel version can use for certain purposes. For example, I know h323 where added into kernel at 2.6.17 kernel version, but the community appears to be working into 2.6.16.x version to stabilize it and and backported many bugfixes from 2.6.19.x to 2.6.16.x. I think 2.6.16.x kernel is the more stable at these days, but if I want h323 conntrack modules I can't use pom-ńg because h323 is not in pom-ng today, and if I use old pom-ng, I know I will use a module with some bugs corrected in 2.6.18.x kernel. Do I explained a problem that have many users than me? Another example, some body say in the lists that using "mark" will allow me to change routes by "mark value" or by "and-mark mask", fine, that were to substitute ROUTE tarjet. I think that is a correct solution but ... What are the implications? 1) I can't see any documentation in netfilter or iproute. 2) My distro don't update the packages, I have to do it manually. 3) When I have an updated iproute package, kernel package, iptables package and I finish and test the configuration, I have the knowledte to write a little explanation/how-to to allow users to know how and don't waste their time looking for the steps ... some hours after I found a wiki, I need to register, etc When I finished all the needed steps to allow me to write a "more or less" public super-mini-howto I forgot the steps and I, finally, don't write the info, because my systems are working for my purposes, I have my paper with my hand annotations and I need to continue working in more tasks. Sorry for the big e-mail, but it is only my user opinion about these type o things. Sorry for my poor english. Regards El Mie, 10 de Enero de 2007, 12:53, Jan Engelhardt escribió: > > On Jan 10 2007 06:58, Patrick McHardy wrote: >>Krzysztof Oledzki wrote: Its still down, but the ROUTE patch is unmaintained anyway. >>> >>> How about attached (and inlined) patch. BTW - is it possible to add a >>> Kconfig entry after a specific text, like with Makefile
[LARTC] Re: dst cache overflow
The configuration is: 1) linux box with 2.6.19.1 kernel with these patches/modules: a) l7-filter b) multipath patch (from nano-howto) c) IMQ d) ipp2p e) connlimit 2) 4 ethernet interfaces: a) 2 external (eth1 and eth3) interfaces with balanced links (as described in nato-howto). b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP enabled and configured. 3) For tests I load manually ALL conntrack/nat kernel modules. My first attempt (to allow UPnP daemon to handle only 1 external iface) where put eth1 and eth3 in a bridge without STP enabled and the NAT were done only with -j MASQUERADE and appeared to work fine, but when I run some amule clients along the network, the problem appear in one day (after some weeks working without peers to peers software). Then I broke the wan bridge and put each static external IP into their iface, and the problem appears too in two days instead 1 day. My next step were use SNAT instead MASQUERADE and the problem appears 3 days after the change. Always I had the multipath enableded along these described steps. A production linux box with 2.6.17.14 kernel and the same patches/modules and only 1 wan iface and 1 lan iface and with connlimit match enabled by host is working fine with 100 more p2p traffic than the test machine (the linux box that has de dst cache overflow problem). If you need more info about this to help me in solve this problem, please, say me, I'll get all you need and put here. Thanks 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 >> 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. > > > The MASQUERADE message is just an effect of the problem. Please describe > your setup in more detail (what kind of devices, how are they connected, > ebtables/iptables rules, routing, ...). > > ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Load Balancing Problems
Hi , Are U test it for same remote site and same client ?? - Original Message - From: "Alan Romaniuc" <[EMAIL PROTECTED]> To: Sent: Wednesday, January 10, 2007 6:42 AM Subject: Re: [LARTC] Load Balancing Problems Hi all, After setting the CONFIG_IP_ROUTE_MULTIPATH_CACHED to no and apply patches from http://www.ssi.bg/~ja/#routes , everything is working fine. No more problems with the two uplinks and one route only. Thanks for the help... I've been fighting with that for one week I will point this solution in another places too. Thanks again, Alan Luciano Ruete escreveu: On Friday 05 January 2007 08:33, Alan Romaniuc wrote: Hi, I have a router that got its second link. I was trying to do load balancing, but i can not get it to work properly. Just one link works at time, and is always the second in the command ip route add default table 222 proto static. Am I missing something? My script is below. I am using Debian, tried with kernel 2.6.19 (my compilation) or debian's one (2.6.18-3-486), same results Try "your compilation" without CONFIG_IP_ROUTE_MULTIPATH_CACHED there are several threads on this topic in the archive, one as reference: http://archives.free.net.ph/message/20060618.150532.8a6cc07f.en.html If it solves the problem, maybe is time to contact the author of Multipath Cached and send some report. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: dst cache overflow
ArcosCom Linux User wrote: > The configuration is: >1) linux box with 2.6.19.1 kernel with these patches/modules: > a) l7-filter > b) multipath patch (from nano-howto) > c) IMQ > d) ipp2p > e) connlimit >2) 4 ethernet interfaces: > a) 2 external (eth1 and eth3) interfaces with balanced links (as > described in nato-howto). > b) 2 internal ineterfaces (eth0 and eth2) in bridge zlan0 with STP > enabled and configured. >3) For tests I load manually ALL conntrack/nat kernel modules. Please try to reproduce this without all these whacky patches (or at least without multipath and IMQ). ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: iptables 1.3.7, kernel 2.6.19, ROUTE and Layer7 issues
Jan Engelhardt wrote: > On Jan 10 2007 06:58, Patrick McHardy wrote: > >>I would prefer to have someone maintain it externally though. Jan, are >>you still interested in doing that? If you need help or webspace for >>an external repository please let me know. > > > I would give it a try. Though I would really prefer to have it in the > kernel and iptables rather than pomng or pomng-external. In my > opinion that simplifies maintainability. Changes in the netfilter API > seem to be the most common reason for patching (someone changed the > xt_match->match and xt_target->target signatures in 2.6.20 again!), > and keeping out-of-tree modules compiling with kernel-du-jour can be > an #ifdef pita. Then it's really preferable to have 2.6.18 have a > xt_FOOBAR with netfilter-2.6.18 signatures, and 2.6.20 with > netfilter-2.6.20. Especially since many people run distributions with > RPM/DEBified iptables, so the POM `runme` will not be easy to > accomplish for the casual user. (I currently do have that issue - > after doing `svn up` on pomng, I have to manually move the changes to > (my) kernel rpm and (my) iptables rpm, because the days of `make > install` are GONE for me - at least I try.) > > I understand that POM does not require to compile with all > kernels-of-the-last-three-months, but this also simplifies > integration for end users. They do not need to backport/forward port > indated/outdated out-of-tree modules and, at best, do not even need > to recompile the kernel. > > Of course there are some modules that continue being out-of-tree > because they would not fit in (imagine a 500K geoip.c with a > compiled-in big string array). Not sure what to do about them. > Perhaps do it like chaostables [2.6.18-2.6.20], trying to keep it > working for a limited set of kernels. > > Oh well, that said, my ideal plan would be to get ROUTE TARPIT > connlimit and u32 into mainline in one go, and perhaps, after review > and discussion, chaostables and some of the others that live in > Krzystof's patchlet collection. ROUTE will not go in, its a bad hack and shouldn't be used (which is why I would prefer to get rid of it). Haven't looked at TARPIT and connlimit in a long time, we can think about it. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
