Re: [LARTC] Again,Bandwidthhtb
OK but how do I specify a range of ports,for examples 15000-15010 15000:15010?? On Wed, 2004-01-07 at 19:09, Stef Coene wrote: *This message was transferred with a trial version of CommuniGate(tm) Pro* On Wednesday 07 January 2004 07:20, Eddie wrote: Good Day All Just 2 questions on htb 1,My Wan link is on eth1 and my Lan on eth0,where do I put my htb on?I want to limit web serving and ftp ens. eth1 for downloads from your web/ftp server eth0 for uploads to your web/ftp server 2.Im going to use the u32 filter.Can I use sub-netting for IP,i.o.w where src is can I do 192.168.1.0/24? Yes you can. See http://docum.org/stef.coene/qos/docs/u32-filter.html Stef ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multihome- routes patch problem
Hello, On Thu, 8 Jan 2004, hare ram wrote: [EMAIL PROTECTED] patch -p1 /root/update/update/routes-2.4.20-9.diff What happens with routes-2.4.22-9.diff ? Regards -- Julian Anastasov [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multihome- routes patch problem
See the the error, its not patched perfectly its giving some problems, while iam patching patching file net/ipv4/fib_rules.c patching file net/ipv4/fib_semantics.c Hunk #4 succeeded at 366 with fuzz 2. Hunk #5 FAILED at 384. --- Hunk #6 succeeded at 436 with fuzz 1. 1 out of 12 hunks FAILED -- saving rejects to file net/ipv4/fib_semantics.c.rej - patching file net/ipv4/ip_nat_dumb.c patching file net/ipv4/netfilter/ip_fw_compat_masq.c patching file net/ipv4/netfilter/ip_nat_core.c Hunk #1 succeeded at 962 (offset 9 lines). patching file net/ipv4/netfilter/ip_nat_standalone.c Hunk #1 succeeded at 221 (offset -5 lines). Hunk #2 succeeded at 300 with fuzz 2 (offset 1 line). Hunk #3 succeeded at 330 with fuzz 2 (offset -5 lines). patching file net/ipv4/netfilter/ipt_MASQUERADE.c Hunk #1 FAILED at 88. 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/netfilter/ipt_MASQUERADE.c.rej hare - Original Message - From: Julian Anastasov [EMAIL PROTECTED] To: hare ram [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 08, 2004 4:27 PM Subject: Re: [LARTC] Multihome- routes patch problem Hello, On Thu, 8 Jan 2004, hare ram wrote: [EMAIL PROTECTED] patch -p1 /root/update/update/routes-2.4.20-9.diff What happens with routes-2.4.22-9.diff ? Regards -- Julian Anastasov [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Random ping jumps
Roy wrote: I think it is your privider fault, Isnt your provider litnet? and you connected with some wlan card no. my provider is Lithuania telecom. And i'm on DSL 320/128. to debug it trace the patch (with traceroute or tracert) and try to ping the most near routers, this way you will easy find the problem i'll try using mrt. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Multihomed router problems
Ral Alexis Betancort Santana wrote: Hi all, i'm new at LARTC, and after reading the docs I found no solution to my problem ... On one side I have eth0 conected to the LAN, on the other side I have eth1 conected to a switch and to 3 DSL routers with 3 diferent providers, and also eth2 conected to a cisco 2600 conected to a LDMS line. I have readed the larct docs about multihomed conections to internet, but I'm been unable to setup the routes with iproute2. I have setup a default multihop route, but if I receive a ssh conection throught one of the DSL lines it get not answered by the same line, it's answered throught the default route, How could I change this? I want to begin by answering the traffic by the line it is coming in. Well. this should be done automatically otherwise it would break TCP/ip. I think you messed up your config. Mine setup with 2 ip's: rasnet:/etc/blootbot# ip rule 0: from all lookup local 32760: from all to 213.226.172.0/24 lookup parabole 32761: from all to 213.252.224.0/24 lookup parabole 32763: from all to 213.226.161.0/24 lookup parabole 32764: from all to 213.226.147.0/24 lookup parabole 32765: from all to 213.226.146.0/24 lookup parabole 32766: from all lookup main 32767: from all lookup default rasnet:/etc/blootbot# ip route 192.168.20.0/24 dev eth1 proto kernel scope link src 192.168.20.59 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 81.0.0.0/8 dev eth0 proto kernel scope link src 81.7.84.36 default via 81.7.84.1 dev eth0 src 81.7.84.36 rasnet:/etc/blootbot# ip route ls table parabole default via 192.168.20.1 dev eth1 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Strange behavior deleting filters
Hi list, I'm playing with tc and found a strange behavior when I try to delete filters. For example, this simple scenario: tc qdisc add dev eth1 root handle 1: htb default 100 tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 works just fine, but when I try to delete oen of the filters with something like this: tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 both filters are deleted. I've found a post from Dimitry V. Ketov in the kernel list on may/2003 with a situation like this one, but there are no answers. I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? I'm suposed to be able to delete filters separately right? May it be a bug? Deleting the whole qdisc is not an opition in my setup and trying to delete the parent class gives me a device or resource busy error because of the filters. tc class del doesn't seen to delete its child filter. tks for any information... Andre ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Random ping jumps
Can you provide some more detail on your network configuration? I'm unclear if the linux server is your internet router or just another client computer on your local LAN, where the test pings to the internet are going (i.e. nexthop router, etc.), and if/where CIPE tunnels are involved in the equation. Perhaps a small network map would be helpful. I'm also unclear about the pings that you've tried. After you've shown the network map, perhaps you can identify the two machines (and interfaces) involved in each of the different ping tests you've performed. I had a similar problem recently. A linux-based router with four interfaces serving three local LANs and a T-1 (via the provider's router) to the internet. The router was forwarding traffic between all combinations of networks (that were allowed by rule) correctly, except between LANs 1 and 2. In this case, pings would vary much as in your case. Interestingly, it turned out to be bad hardware. Moved the boot media to an identically configured machine and the problem went away. Returned the boot media to the original machine and the problem returned. On Wednesday 07 January 2004 02:26 pm, Artras lajus wrote: Hello, I've got this problem. There is an linux server with 2.4.24 kernel and pinging from him to internet (or from lan) ping randomly jumps up: 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=387 ttl=59 time=30.0 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=388 ttl=59 time=32.6 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=389 ttl=59 time=34.9 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=390 ttl=59 time=198 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=391 ttl=59 time=407 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=392 ttl=59 time=407 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=393 ttl=59 time=430 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=394 ttl=59 time=30.9 ms 64 bytes from fortas.ktu.lt (193.219.160.131): icmp_seq=395 ttl=59 time=31.6 ms Internet line isn't loaded up, server load fine. QOS isn't used, qdiscs default. I don't realize what the problem is and even how to debug it. Sysctl config: net/ipv4/ip_forward = 1 net/ipv4/icmp_ignore_bogus_error_responses = 1 net/ipv4/icmp_echo_ignore_broadcasts = 1 net/ipv4/tcp_syncookies = 1 net/ipv4/tcp_timestamps = 0 net/ipv4/tcp_window_scaling = 0 net/ipv4/tcp_sack = 0 net/ipv4/tcp_fin_timeout = 30 net/ipv4/tcp_keepalive_time = 1800 net/ipv4/tcp_low_latency = 1 Thanks for any thoughts. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Again,Bandwidthhtb
On Thursday 08 January 2004 10:50, Eddie wrote: OK but how do I specify a range of ports,for examples 15000-15010 15000:15010?? You can't with u32. But you can use iptables to mark packets and filter the packets with the fw filter. Stef -- [EMAIL PROTECTED] Using Linux as bandwidth manager http://www.docum.org/ #lartc @ irc.openprojects.net ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Strange behavior deleting filters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, In my last e-mail about deleting filters (I'm sorry): s/Anything else ?/Anyone has idea about that strange problem ?/ Stef ? Telles Rodrigo P. Telles wrote: | Andre, | | I've had the same problem when I try to remove one filter rule. | This is ocurred when you have the same prio for all filter rules. I've | solved | my problem using diferent prio values in filter rules. | I don't now if this is a BUG ! | | Anything else ? | | Telles | | Andre Correa wrote: | | | | Hi list, I'm playing with tc and found a strange behavior when I try to | | delete filters. For example, this simple scenario: | | | | tc qdisc add dev eth1 root handle 1: htb default 100 | | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit | | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit | | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit | | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 | | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 flowid 1:2 | | | | works just fine, but when I try to delete oen of the filters with | | something like this: | | | | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 flowid 1:2 | | | | both filters are deleted. | | | | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 | | with a situation like this one, but there are no answers. | | | | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? | | I'm suposed to be able to delete filters separately right? May it be a | bug? | | | | Deleting the whole qdisc is not an opition in my setup and trying to | | delete the parent class gives me a device or resource busy error | | because of the filters. tc class del doesn't seen to delete its child | | filter. | | | | tks for any information... | | | | Andre | | | | ___ | | LARTC mailing list / [EMAIL PROTECTED] | | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | | | | | -- | -- | Rodrigo P. Telles [EMAIL PROTECTED] | Gerente de Projetos - http://www.devel-it.com.br | Devel-IT - Uma empresa do Grupo TDKOM | -- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ - -- - -- Rodrigo P. Telles [EMAIL PROTECTED] Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//a88iLK8unYgEMQRAkJ1AJ498bVg/9cOGlmlnkpNVsb0WudUlACfUny6 Wz0hejIwM5z3cz417//1LCg= =f/u2 -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Random ping jumps
R. Steve McKown wrote: Can you provide some more detail on your network configuration? I'm unclear if the linux server is your internet router or just another client computer on your local LAN It's network router. , where the test pings to the internet are going (i.e. nexthop router, etc.), and if/where CIPE tunnels are involved in the equation. Perhaps a small network map would be helpful. No CIPE (whatever is that ;-). Nexthop? You mean gateway? eth0:1Link encap:Ethernet HWaddr 00:50:22:B1:67:6D inet addr:81.7.84.36 Bcast:81.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1 Interrupt:10 Base address:0xd000 gateway: 81.7.84.1 Map is at http://h2o.pieva.net/net.png I'm also unclear about the pings that you've tried. After you've shown the network map, perhaps you can identify the two machines (and interfaces) involved in each of the different ping tests you've performed. The machine is totaly random. [EMAIL PROTECTED]:~$ traceroute fortas.ktu.lt traceroute to fortas.ktu.lt (193.219.160.131), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 26.269 ms 23.333 ms 25.156 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 63.079 ms 33.146 ms 26.117 ms 3 telecom-gw.is.lt (193.219.13.99) 35.978 ms 26.476 ms 103.138 ms 4 litnet-gw.is.lt (193.219.13.98) 22.715 ms 24.531 ms 209.984 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 52.826 ms 98.040 ms 81.609 ms 6 ktu-lan.litnet.lt (193.219.61.252) 38.696 ms 182.582 ms 241.836 ms 7 fortas.ktu.lt (193.219.160.131) 215.523 ms 126.815 ms 29.217 ms [EMAIL PROTECTED]:~$ traceroute cs.mes.lt traceroute to cs.mes.lt (193.219.67.253), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 748.174 ms 66.331 ms 135.586 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 21.645 ms 21.588 ms 24.597 ms 3 telecom-gw.is.lt (193.219.13.99) 30.584 ms 31.065 ms 29.612 ms 4 litnet-gw.is.lt (193.219.13.98) 24.602 ms 143.212 ms 143.096 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 292.196 ms 163.870 ms 84.549 ms 6 ktu-lan.litnet.lt (193.219.61.252) 84.982 ms 54.801 ms 69.143 ms 7 diz.ktu.lt (193.219.67.253) 33.831 ms 29.877 ms 30.005 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=5 ttl=59 time=34.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=6 ttl=59 time=32.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=7 ttl=59 time=33.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=8 ttl=59 time=324 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=9 ttl=59 time=836 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=10 ttl=59 time=850 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=11 ttl=59 time=321 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=12 ttl=59 time=147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=13 ttl=59 time=115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=14 ttl=59 time=118 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=15 ttl=59 time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=16 ttl=59 time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=17 ttl=59 time=272 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=18 ttl=59 time=312 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=19 ttl=59 time=102 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=20 ttl=59 time=107 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=21 ttl=59 time=114 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=22 ttl=59 time=89.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=23 ttl=59 time=91.2 ms [EMAIL PROTECTED]:~$ traceroute cs.bbd.lt traceroute to cs.bbd.lt (193.219.184.7), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 23.803 ms 24.813 ms 56.163 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 171.425 ms 21.174 ms 24.321 ms 3 telecom-gw.is.lt (193.219.13.99) 27.882 ms 30.782 ms 26.219 ms 4 litnet-gw.is.lt (193.219.13.98) 22.842 ms 23.025 ms 24.079 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 24.201 ms 25.130 ms 27.256 ms 6 ktu-lan.litnet.lt (193.219.61.252) 26.811 ms 27.362 ms 27.785 ms 7 193.219.184.7 (193.219.184.7) 27.928 ms 29.185 ms 28.067 ms [EMAIL PROTECTED]:~$ ping cs.bbd.lt PING cs.bbd.lt (193.219.184.7) 56(84) bytes of data. 64 bytes from 193.219.184.7: icmp_seq=1 ttl=123 time=133 ms 64 bytes from 193.219.184.7: icmp_seq=2 ttl=123 time=122 ms 64 bytes from 193.219.184.7: icmp_seq=3 ttl=123 time=118 ms 64 bytes from 193.219.184.7: icmp_seq=4 ttl=123 time=109 ms 64 bytes from 193.219.184.7: icmp_seq=5 ttl=123 time=725 ms 64 bytes from 193.219.184.7: icmp_seq=6 ttl=123 time=668 ms 64 bytes from 193.219.184.7: icmp_seq=7 ttl=123 time=120 ms 64 bytes from 193.219.184.7: icmp_seq=8 ttl=123 time=102 ms 64 bytes from 193.219.184.7: icmp_seq=9 ttl=123 time=91.5 ms 64 bytes from
Re: [LARTC] Strange behavior deleting filters
Hi Rodrigo, tks for the answer. It sounds like a starting point but this is not that good if there are several filters pointing to classes with high load. In this case lower prio classes will really have higher priority. Isn't it supposed to work as expected: delete only the right filter? May it be reported as a bug? Is it a known behavior? tks... Andre Rodrigo P. Telles wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, I've had the same problem when I try to remove one filter rule. This is ocurred when you have the same prio for all filter rules. I've solved my problem using diferent prio values in filter rules. I don't now if this is a BUG ! Anything else ? Telles Andre Correa wrote: | | Hi list, I'm playing with tc and found a strange behavior when I try to | delete filters. For example, this simple scenario: | | tc qdisc add dev eth1 root handle 1: htb default 100 | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | 10.10.10.20 flowid 1:2 | | works just fine, but when I try to delete oen of the filters with | something like this: | | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src | 10.10.10.20 flowid 1:2 | | both filters are deleted. | | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 | with a situation like this one, but there are no answers. | | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? | I'm suposed to be able to delete filters separately right? May it be a bug? | | Deleting the whole qdisc is not an opition in my setup and trying to | delete the parent class gives me a device or resource busy error | because of the filters. tc class del doesn't seen to delete its child | filter. | | tks for any information... | | Andre | | ___ | LARTC mailing list / [EMAIL PROTECTED] | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | - -- - -- Rodrigo P. Telles [EMAIL PROTECTED] Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//aWeiLK8unYgEMQRAgPcAJ9iqsF9V5m4QqKrLgI3iUF6rLW8hACeJ0GP 6DYjQf0/5NVNRrojAXvgcw8= =d0PR -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Strange behavior deleting filters
Patrick, tks for the info but I'm sure I got your idea. A filter handle is something like: 804::800 right? I've tried this (supose classes 1:1 and 1:2 exist): tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 match ip src 10.10.10.10 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.11 flowid 1:2 and then: tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 but both filter are deleted... Am I missing something? tks a lot... Andre Patrick McHardy wrote: Andre Correa wrote: Hi list, I'm playing with tc and found a strange behavior when I try to delete filters. For example, this simple scenario: tc qdisc add dev eth1 root handle 1: htb default 100 tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 works just fine, but when I try to delete oen of the filters with something like this: tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 both filters are deleted. The kernel only regards priorities when deleting a filter without giving a handle. Use the handle if you want to delete a specific filter. Regards, Patricky ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Strange behavior deleting filters
Andre Correa wrote: Patrick, tks for the info but I'm sure I got your idea. A filter handle is something like: 804::800 right? Not exactly. How handles are handled depends on the classifier, fw classifier for example uses its own handle to match the nfmark, route creates handles of its own and errors if the handle supplied from userspace differs. Maybe a example clears things up: add filters tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 show filters filter protocol ip pref 1 route filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 As you can see the route classifier uses realm | 0x8000. delete filters tc filter del dev lo pref 1 handle 0x00048000 route tc filter del dev lo pref 1 handle 0x00058000 route tc filter del dev lo pref 1 handle 0x00068000 route tc filter del dev lo pref 1 handle 0x00078000 route tc filter del dev lo pref 1 handle 0x00088000 route show filters again filter protocol ip pref 1 route Only the container of the single filters is left. To destroy it, delete by priority: tc filter del dev lo pref 1. Hope that helps. Patrick I've tried this (supose classes 1:1 and 1:2 exist): tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 match ip src 10.10.10.10 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.11 flowid 1:2 and then: tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 but both filter are deleted... Am I missing something? tks a lot... Andre ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Strange behavior deleting filters
Andre Correa wrote: Hi list, I'm playing with tc and found a strange behavior when I try to delete filters. For example, this simple scenario: tc qdisc add dev eth1 root handle 1: htb default 100 tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 works just fine, but when I try to delete oen of the filters with something like this: tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src 10.10.10.20 flowid 1:2 both filters are deleted. The kernel only regards priorities when deleting a filter without giving a handle. Use the handle if you want to delete a specific filter. Regards, Patricky ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Strange behavior deleting filters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andre, I don't now, when I've had that problem, I didn't find anything about that ! I've tried to report this problem, but all mails that I sent to the list, they had simply desappeared, and I've found this solution (for my case this solution is good). Later, my mail was started to work and I forgot to notify the list about that. I remembered that when I saw your mail about filter rules :-) I expect that someone have an idea about that, because is impossible that only you and me are having this behavior. Telles Andre Correa wrote: | | Hi Rodrigo, tks for the answer. It sounds like a starting point but this | is not that good if there are several filters pointing to classes with | high load. In this case lower prio classes will really have higher | priority. | | Isn't it supposed to work as expected: delete only the right filter? May | it be reported as a bug? Is it a known behavior? | | tks... | | Andre | | | Rodrigo P. Telles wrote: | | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | Andre, | | I've had the same problem when I try to remove one filter rule. | This is ocurred when you have the same prio for all filter rules. I've | solved | my problem using diferent prio values in filter rules. | I don't now if this is a BUG ! | | Anything else ? | | Telles | | Andre Correa wrote: | | | | Hi list, I'm playing with tc and found a strange behavior when I try to | | delete filters. For example, this simple scenario: | | | | tc qdisc add dev eth1 root handle 1: htb default 100 | | tc class add dev eth1 parent 1: classid 1:1 htb rate 128Kbit | | tc class add dev eth1 parent 1: classid 1:2 htb rate 258Kbit | | tc class add dev eth1 parent 1: classid 1:100 htb rate 32Kbit | | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 match ip dst 63.63.63.63 flowid 1:1 | | tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 flowid 1:2 | | | | works just fine, but when I try to delete oen of the filters with | | something like this: | | | | tc filter del dev eth1 parent 1: protocol ip prio 1 u32 match ip src | | 10.10.10.20 flowid 1:2 | | | | both filters are deleted. | | | | I've found a post from Dimitry V. Ketov in the kernel list on may/2003 | | with a situation like this one, but there are no answers. | | | | I'm using 2.4.23 and iptables 1.2.7a. Any clues what can be the cause? | | I'm suposed to be able to delete filters separately right? May it be | a bug? | | | | Deleting the whole qdisc is not an opition in my setup and trying to | | delete the parent class gives me a device or resource busy error | | because of the filters. tc class del doesn't seen to delete its child | | filter. | | | | tks for any information... | | | | Andre | | | | ___ | | LARTC mailing list / [EMAIL PROTECTED] | | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | | | | | - -- | - -- | Rodrigo P. Telles [EMAIL PROTECTED] | Gerente de Projetos - http://www.devel-it.com.br | Devel-IT - Uma empresa do Grupo TDKOM | - -- | -BEGIN PGP SIGNATURE- | Version: GnuPG v1.0.7 (GNU/Linux) | Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org | | iD8DBQE//aWeiLK8unYgEMQRAgPcAJ9iqsF9V5m4QqKrLgI3iUF6rLW8hACeJ0GP | 6DYjQf0/5NVNRrojAXvgcw8= | =d0PR | -END PGP SIGNATURE- | | ___ | LARTC mailing list / [EMAIL PROTECTED] | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | | | ___ | LARTC mailing list / [EMAIL PROTECTED] | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | | - -- - -- Rodrigo P. Telles [EMAIL PROTECTED] Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//d/KiLK8unYgEMQRAlgLAJ4torQ3qVFfOLujnSMiFUkKG+CiIgCfZ2q9 jTggAS7kT2eIyiMnNqeEvEk= =bzBz -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Strange behavior deleting filters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick, Based in your explanation, I tried that: # adding root qdisc, class and filters tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:10 htb rate 768Kbit tc class add dev eth0 parent 1:1 classid 1:11 htb rate 512Kbit tc class add dev eth0 parent 1:1 classid 1:12 htb rate 256Kbit tc qdisc add dev eth0 parent 1:11 handle 11: sfq tc qdisc add dev eth0 parent 1:12 handle 12: sfq tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::11 u32 match ip src 10.10.10.10 flowid 1:11 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle ::12 u32 match ip src 10.10.10.11 flowid 1:12 # tc filter show dev eth0 filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::11 order 17 key ht 800 bkt 0 flowid 1:11 ~ match 0a0a0a0a/ at 12 filter parent 1: protocol ip pref 1 u32 fh 800::12 order 18 key ht 800 bkt 0 flowid 1:12 ~ match 0a0a0a0b/ at 12 # deleting a rule tc filter del dev eth0 parent 1:0 protocol ip prio 1 handle ::12 Must specify filter type when using handle Humm, I got back to LARTC Howto, but I can't found anything about filter type ! What's wrong ? Telles Patrick McHardy wrote: | Andre Correa wrote: | | | Patrick, tks for the info but I'm sure I got your idea. | | A filter handle is something like: 804::800 right? | | | Not exactly. How handles are handled depends on the classifier, | fw classifier for example uses its own handle to match the nfmark, | route creates handles of its own and errors if the handle supplied | from userspace differs. | | Maybe a example clears things up: | add filters | tc filter add dev lo protocol ip parent 1: pref 1 route from 4 flowid 1:100 | tc filter add dev lo protocol ip parent 1: pref 1 route from 5 flowid 1:200 | tc filter add dev lo protocol ip parent 1: pref 1 route from 6 flowid 1:300 | tc filter add dev lo protocol ip parent 1: pref 1 route from 7 flowid 1:400 | tc filter add dev lo protocol ip parent 1: pref 1 route from 8 flowid 1:500 | | show filters | filter protocol ip pref 1 route | filter protocol ip pref 1 route fh 0x00048000 flowid 1:100 from 4 | filter protocol ip pref 1 route fh 0x00058000 flowid 1:200 from 5 | filter protocol ip pref 1 route fh 0x00068000 flowid 1:300 from 6 | filter protocol ip pref 1 route fh 0x00078000 flowid 1:400 from 7 | filter protocol ip pref 1 route fh 0x00088000 flowid 1:500 from 8 | | As you can see the route classifier uses realm | 0x8000. | | delete filters | tc filter del dev lo pref 1 handle 0x00048000 route | tc filter del dev lo pref 1 handle 0x00058000 route | tc filter del dev lo pref 1 handle 0x00068000 route | tc filter del dev lo pref 1 handle 0x00078000 route | tc filter del dev lo pref 1 handle 0x00088000 route | | show filters again | filter protocol ip pref 1 route | | Only the container of the single filters is left. To destroy it, delete by | priority: tc filter del dev lo pref 1. | | Hope that helps. | | Patrick | | | I've tried this (supose classes 1:1 and 1:2 exist): | | tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::10 u32 | match ip src 10.10.10.10 flowid 1:1 | tc filter add dev eth1 parent 1: protocol ip prio 1 handle ::11 u32 | match ip src 10.10.10.11 flowid 1:2 | | and then: | | tc filter del dev eth1 parent 1: protocol ip prio 1 handle ::11 | | but both filter are deleted... | | Am I missing something? | | tks a lot... | | Andre | | | | ___ | LARTC mailing list / [EMAIL PROTECTED] | http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ | | - -- - -- Rodrigo P. Telles [EMAIL PROTECTED] Gerente de Projetos - http://www.devel-it.com.br Devel-IT - Uma empresa do Grupo TDKOM - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//eiViLK8unYgEMQRAv1PAJ96witXRlYUwPW5fqDySWURu3VLcQCdGrx3 Ly6eZtiaSTtrWMrpPm9MxnQ= =rhE2 -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re:[LARTC] Again,Bandwidthhtb
Hi all, 1.) You can put in your internal interface to slow down the traffic. 2.) You set the filter by single ip or network. []´s Anderson Good Day All Just 2 questions on htb 1,My Wan link is on eth1 and my Lan on eth0,where do I put my htb on?I want to limit web serving and ftp ens. 2.Im going to use the u32 filter.Can I use sub- netting for IP,i.o.w where src is can I do 192.168.1.0/24? Thanks and Please Help Eddie ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: ht tp://lartc.org/ __ Acabe com aquelas janelinhas que pulam na sua tela. AntiPop-up UOL - É grátis! http://antipopup.uol.com.br/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Random ping jumps
On Thursday 08 January 2004 01:01 pm, Artras lajus wrote: Map is at http://h2o.pieva.net/net.png Ah, nice. I'm also unclear about the pings that you've tried. After you've shown the network map, perhaps you can identify the two machines (and interfaces) involved in each of the different ping tests you've performed. The machine is totaly random. What happens if you ping from the linux box to the linux box's default gateway? If the problem doesn't exhibit in this test nor in any test between machines in your LAN, the problem is probably your providers: the DSL modem or something 'downstream' from it. You should consider doing tests #2 and #3 anyway as support for your position when you call your ISP to open a trouble ticket. If the latency problem does exhibit pinging from the linux box to the default gateway, you haven't learned much yet. Continue testing by removing variables, attempting to isolate the smallest 'configuration' that exhibits the problem. The variables are: computers, hubs/switches, cables, and the like. Here's some suggestions for testing: 1. plug the linux router directly into the DSL modem and ping from the router to the default gateway. If the problem goes away, it's something in the hardware and cables that were 'bypassed' in this test. You can continue this strategy to test into your network. Read my security note below. 2. plug a PC, configured as the linux router's eth0:1 interface (with proper default gateway) and ping from the pc to the default gateway. If the problem goes away, its probably the linux router (hardware or software). 3. If #1 and #2 don't cause it to go away, be sure you used a different cable in tests #1 and #2. If the problem still doesn't go away, it's an issue for your network provider. * security note * Running both your LAN and the internet provider subnets on the same ethernet network puts you at a much greater security risk. You should seriously consider installing a third network interface into your linux box and moving eth0:1's ip info to eth2. Then plug the DSL modem into eth2 with a cross-over cable with no computers attached. I'm guessing your thirty users using Windows. If they have windows network enabled, they are all generating broadcast traffic. That traffic will most likely be crossing the DSL modem (since it is bridging). Aside from security implications, the local traffic that does get bridged is tying up your DSL bandwidth. It seems unlikely that 30 PC's could saturate your 128kbps uplink, but I'm no expert on windows networking. 128kbps is not a huge pipe, so perhaps it's possible. If so, the solution to your security problem is also the solution to the latency variability issue. If this is the case, both tests #2 and #3 will not show the variability, since your local LAN is effectively removed from the test. Hope this helps, Steve [EMAIL PROTECTED]:~$ traceroute fortas.ktu.lt traceroute to fortas.ktu.lt (193.219.160.131), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 26.269 ms 23.333 ms 25.156 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 63.079 ms 33.146 ms 26.117 ms 3 telecom-gw.is.lt (193.219.13.99) 35.978 ms 26.476 ms 103.138 ms 4 litnet-gw.is.lt (193.219.13.98) 22.715 ms 24.531 ms 209.984 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 52.826 ms 98.040 ms 81.609 ms 6 ktu-lan.litnet.lt (193.219.61.252) 38.696 ms 182.582 ms 241.836 ms 7 fortas.ktu.lt (193.219.160.131) 215.523 ms 126.815 ms 29.217 ms [EMAIL PROTECTED]:~$ traceroute cs.mes.lt traceroute to cs.mes.lt (193.219.67.253), 30 hops max, 38 byte packets 1 adsl-213-190-40-129.takas.lt (213.190.40.129) 748.174 ms 66.331 ms 135.586 ms 2 fe22-acc0-tai.kns.telecom.lt (212.59.7.233) 21.645 ms 21.588 ms 24.597 ms 3 telecom-gw.is.lt (193.219.13.99) 30.584 ms 31.065 ms 29.612 ms 4 litnet-gw.is.lt (193.219.13.98) 24.602 ms 143.212 ms 143.096 ms 5 cat6506-p2-1.kttc.litnet.lt (193.219.62.125) 292.196 ms 163.870 ms 84.549 ms 6 ktu-lan.litnet.lt (193.219.61.252) 84.982 ms 54.801 ms 69.143 ms 7 diz.ktu.lt (193.219.67.253) 33.831 ms 29.877 ms 30.005 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=5 ttl=59 time=34.8 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=6 ttl=59 time=32.6 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=7 ttl=59 time=33.1 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=8 ttl=59 time=324 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=9 ttl=59 time=836 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=10 ttl=59 time=850 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=11 ttl=59 time=321 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=12 ttl=59 time=147 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=13 ttl=59 time=115 ms 64 bytes from diz.ktu.lt (193.219.67.253): icmp_seq=14 ttl=59 time=118 ms 64 bytes from diz.ktu.lt
[LARTC] [ot]Bridging and Cisco switch
Hi, I was trying to setup QoS for my network in my machine. It had a Ethernet interface connected to a cisco switch. I connected one more interface on to the same switch and setup and bridge, zeroed out both the interfaces and assigned my old ip to the bridge interface. After this when I pinged outside, all the lights in my switch started blinking fast. I immediately pulled the network cable from my box. Is the configuration I attempted legal? Is their any problem with bridges and Switchs? When a packet comes to bridge ip, which interface does it go? I am bit confused! Thanks for your help raj ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
