Re: [LARTC] Multipath routing
On Tue, Jun 05, 2007 at 11:13:52AM +0200, Michał Margula wrote: Hello! Hi I have trouble with multipath routing. Those options are enabled in kernel: [*] IP: policy routing [*] IP: equal cost multipath [*] IP: equal cost multipath with caching support (EXPERIMENTAL) * MULTIPATH: round robin algorithm First of all equal cost multipathing is evil ;, It simply doesn't work for packets in forwarding path besides support in kernel is not maintained Realy if you want load balance both uplinks disable CONFIG_IP_ROUTE_MULTIPATH_CACHED and you will have random traffic distribiution between both links. More details : http://lists.openwall.net/netdev/2007/03/14/50 http://lists.openwall.net/netdev/2007/03/12/76 http://lists.quagga.net/pipermail/quagga-users/2007-May/008469.html Also I have trouble using multipath quagga, it simply doesn't put multipath route in routing table. For example: faramir# sh ip bgp 10.100.0.1 BGP routing table entry for 10.101.0.0/22 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer Local 80.245.176.13 (metric 1) from 80.245.176.13 (80.245.177.4) Origin IGP, metric 0, localpref 100, weight 150, valid, internal, best Last update: Tue Jun 5 01:59:29 2007 Local 80.245.176.10 (metric 1) from 80.245.176.10 (80.245.176.10) Origin IGP, metric 0, localpref 100, weight 100, valid, internal Last update: Tue Jun 5 01:28:02 2007 BGP always have alternative paths in BGP RIB and mostly don't insert them as multipath route to FIB. Of course there is path : http://lebon.org.ua/quagga.html that force route to be inserted to kernel with multiple gateways - but realy this is some kind of dirty-hack. Check thread 'Linux and BGP multipath' on quagga-dev, and especially this mail: http://lists.quagga.net/pipermail/quagga-dev/2007-April/004700.html # ip r s [...] 10.100.0.0/22 via 80.245.176.11 dev eth0 proto zebra But if I manually put something like that in quagga: faramir(config)# ip route 1.2.3.0/24 80.245.176.13 faramir(config)# ip route 1.2.3.0/24 80.245.176.11 yeah this is static route. /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] /proc/net/dev counters
Hi Maybe my problem is litle offtopic to this list , but maybe someone had something similar like this , and have some good solution . Ok, I've have router with four intel e1000 pci-x(2x100Mhz/2x133Mhz) nics that push about 200Mbit/s , and I'm using nload for realtime traffic monitoring. Everything was great until I've updated kernel to 2.6.17.13 . After update nload is showing some crazy values . I've tried to get counters from /proc/net/dev (like nload). [EMAIL PROTECTED]:~# while true; do cat /proc/net/dev|grep eth0; sleep 1; done eth0:1013729758 5729322500 18821020 0 0 0 1572910106 3860638290000 0 0 0 eth0:1055515817 5730043720 18821020 0 0 0 1601291109 3860694606000 0 0 0 eth0:1055515817 5730043720 18821020 0 0 0 1601291109 3860694606000 0 0 0 eth0:1097729573 5730764320 18821020 0 0 0 1629536436 3860751311000 0 0 0 eth0:1097729573 5730764320 18821020 0 0 0 1629536436 3860751311000 0 0 0 eth0:1139487258 5731484690 18821020 0 0 0 1658034498 3860807633000 0 0 0 eth0:1139487258 5731484690 18821020 0 0 0 1658034498 3860807633000 0 0 0 eth0:1181148113 5732200760 18821020 0 0 0 1685931047 3860863738000 0 0 0 Between second and third second counter increase of 0 bytes, 1055515817-1055515817=0 the same for fourth and fifth ( on mrtg graphs I've about 140Mbit/s incoming traffic - 17.5 MB/s ). On other router I've kernel 2.6.14.7 , e1000/2xe100 32bit nics , and interfece counters in /proc/net/dev are looking good: eth0:2101453114 3324697664 3604 3441 344192 0 1347064 867323793 3458783738000 0 0 0 eth0:2107451373 3324705778 3604 3441 344192 0 1347066 874688831 3458792480000 0 0 0 eth0:2113352907 3324713495 3604 3441 344192 0 1347066 881546913 3458800862000 0 0 0 eth0:2119707847 3324721929 3604 3441 344192 0 1347069 889060588 3458809975000 0 0 0 eth0:2125601276 3324729816 3604 3441 344192 0 1347070 896165072 3458818569000 0 0 0 2113352907-2107451373=5901534 (traffic on intefece about 40Mbit/s = 5MB/s) - seems good. Both routers have CONFIG_HZ=1000, two cpus, and bofh are using e1000/e100 driver with enabled NAPI. Besides I've similar thing on laptop, 2.6.14 , Broadcom BCM4401-B0 nic (b44) :) Why interface counters are increasing so slowy? this behavior can be changed? or in other way this is normal behavior or some bug , feature? /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] How to select Skype traffic??
On Thu, Aug 24, 2006 at 12:31:58AM +0200, Szymon Mroofka wrote: Hi, I have simple question about Skype. What are the methods of selecting packets which belongs to Skype?? I know about 7layer but I don't belive that is only way. Is 7layer realy good and stable solution for routers which must handle more than 1000 users ? Check also this : http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf Intresting paper about skype, there are some iptables rules to match skype udp traffic . /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] iptables u32 kernel 2.6.17
On Wed, Aug 02, 2006 at 03:52:39PM +0200, Torsten Luettgert wrote:
On Wed, 2006-08-02 at 10:55 +0200, gerald HUET wrote:
[ 5333.87] ip_tables: u32 match: invalid size 0 !=
2028
iptables: Unknown error -1
I tried to do some modifications on ipt_u32.c
following modifications which work for ipp2p
(http://www.sieglitzhof.net/~doc/ipp2p/) without any
succes.
Hm, that should have worked - it's the same problem for
all the little-maintained stuff in patch-o-matic.
Does anyone have an explication why the problem occurs
whith the new kernel and how to solve it ?
The parameters to checkentry() and match() changed
incompatibly between 2.6.16 and 2.6.17.
The u32 match in current SVN works with 2.6.17
(but not with 2.6.16 or earlier).
You need to
svn co http://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng
then patch your kernel and recompile.
apply also patch from attachment. 2.6.17 needs matchsize in ipt_match struct.
triss:~# iptables -I FORWARD -p udp -m length --length 39 -m u32 --u32
'270x8f=7' --u32 '31=0x527c4833' -j DROP
triss:~# iptables -L FORWARD -vn
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0
length 39 u32 0x1f=0x527c4833
seems working.
/pch
--
Dyslexia bug unpatched since 1977 ...
exploit has been leaked to the underground.
--- ipt_u32.c 2006-08-02 22:34:29.0 +0200
+++ /usr/src/linux-2.6.17.6/net/ipv4/netfilter/ipt_u32.c2006-08-02
22:45:43.0 +0200
@@ -217,6 +217,7 @@
static struct ipt_match u32_match = {
.name = u32,
.match = match,
+ .matchsize = sizeof(struct ipt_u32),
.checkentry = checkentry,
.me = THIS_MODULE
};
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] u32 and iptables do not work together
On Sat, Apr 08, 2006 at 08:21:40AM -0300, Nataniel Klug wrote: I think it worked fine... This is my new script (below the text). I just dont know how can I know if this traffic is relly going to the class I send it... hehehehe... I am marking Skype packages using L7-Filter like this: If you want to see packets in class you can use sch_log, quite good module, you must attach it to class and you will see every packet in this class in tcpdump. http://kernel.umbrella.ro/net/sch_log/v0.4/sch_log-0.4.tar.gz or Vincent Perrier's sch_spy (I don't have url). /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Screening packets within tc-classes
On Thu, Dec 01, 2005 at 06:45:42PM +0100, Andreas Unterkircher wrote: Good suggestion to use ulog for this. So I could dump the exactly traffic which would run through a class (CLASSIFY) to analyze and extract the necessary data to draw the graphs. So I do not have to parse my class (IP or MAC) out of a full tcpdump stream. Sadly not possible with tc-filter. But perhaps I could do this for tc with Vincent Perrier's sch_spy module. sch_log is also good for this: http://kernel.umbrella.ro/net/sch_log/v0.4/sch_log-0.4.tar.gz /pch -- Dyslexia bug unpatched since 1977 ... exploit has been leaked to the underground. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] passive FTP trafic control
On Fri, Nov 11, 2005 at 10:20:52PM +0100, Andreas Unterkircher wrote:
You could try to match on helper within iptables. Should be something like
iptables -A FORWARD --match conntrack --ctproto tcp --ctstate
RELATED,ESTABLISHED --match helper --helper ftp -j CLASSIFY
Perhaps this will match your data channel.
Something about 6 month ago I wrote iptables rules for DNATing incoming
connection to ftp server behind nat ,
${ipt} -t nat -A PREROUTING -i eth0 -p tcp -s ${src} -d ${fw_ip}/32 --dport
8181 -j DNAT
+--to-destination ${ftp_int}
${ipt} -t nat -A PREROUTING -i eth0 -p tcp -s ${src} -d ${fw_ip}/32 -m helper
--helper ftp-8181 -j DNAT --to-destination ${ftp_int}
${ipt} -A FORWARD -p tcp -i eth0 -s ${src} -d ${ftp_int} --dport 8181 -m state
--state NEW -j ACCEPT
${ipt} -A FORWARD -p tcp -i eth0 -s ${src} -d ${ftp_int} -m helper --helper
ftp-8181 -m state --state NEW,RELATED -j ACCEPT
8181 - ftp port
src - source address
fw_ip - firewall ip (external)
ftp_int - ftp server internal ip.
Everything was great but firewall sometimes hangs without kernel panic ,
maybe some deadlock in ftp conntrack code or in ftp helper. Kernel was
2.4.20 or 22 .
/pch
--
Dyslexia bug unpatched since 1977 ...
exploit has been leaked to the underground.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
