Re: [LARTC] statistics and calc bandwidth traffic using tc -s qdisc show
[EMAIL PROTECTED] wrote on 16/05/2007 21:30:39: > Hello, > > Is there someone here who knows what does it means? > > The Sent part. > > [EMAIL PROTECTED] ~]# tc -s qdisc show |grep -A 2 "qdisc sfq 140: dev eth0" > qdisc sfq 140: dev eth0 parent 1:140 limit 128p quantum 1514b perturb 10sec > Sent 3155024 bytes 23249 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > > [EMAIL PROTECTED] ~]# tc -s qdisc show |grep -A 2 "qdisc sfq 140: dev eth1" > qdisc sfq 140: dev eth1 parent 1:140 limit 128p quantum 1514b perturb 10sec > Sent 41141183 bytes 32560 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > > > I also would like to know if there is a way to calc the bandwidth > traffic (in kbit for example)of this customer using this > informations. > > Thank you for any help in advance. > > Pablo Fernandes > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc Hi, the "Sent" parameter shows you the amount of data that fall into this qdisc. You can obtain the instant bandwith usage that falls into this qdisc parsing the "rate" parameter. In your example the rate is 0bit, that means 0 bits per second bandwith usage. I must admit that the output from tc -s is a big pain !! Best regards, Eric Janz -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] The "ip route get" returns wrong interface and gateway in an multipath routing environment
Hi, I think I found a problem in iproute or ubuntu kernel. I think that the "ip route get" returns wrong interface and gateway in an multipath routing environment on Ubuntu 6.06 LTS. I reported it also to launchpad as a bug: https://bugs.launchpad.net/ubuntu/+source/iproute/+bug/105521 The easiest way to reproduce it is to start an Ubuntu 6.06 LTS Live on a system with three IF's and setup the environment as follows: [EMAIL PROTECTED]:~# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255 up [EMAIL PROTECTED]:~# ifconfig eth1 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up [EMAIL PROTECTED]:~# ifconfig eth2 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 up [EMAIL PROTECTED]:~# ip route add default nexthop via 192.168.1.254 dev eth1 weight 1 nexthop via 192.168.2.254 dev eth2 weight 1 [EMAIL PROTECTED]:~# ip rule add prio 111 from 192.168.1.1 table 111 [EMAIL PROTECTED]:~# ip rule add prio 222 from 192.168.2.1 table 222 [EMAIL PROTECTED]:~# ip route add default table 111 via 192.168.1.254 [EMAIL PROTECTED]:~# ip route add default table 222 via 192.168.2.254 [EMAIL PROTECTED]:~# ip route ls 192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.1 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1 default nexthop via 192.168.1.254 dev eth1 weight 1 nexthop via 192.168.2.254 dev eth2 weight 1 [EMAIL PROTECTED]:~# ip rule ls 0: from all lookup local 111: from 192.168.1.1 lookup 111 222: from 192.168.2.1 lookup 222 32766: from all lookup main 32767: from all lookup default [EMAIL PROTECTED]:~# ip route ls table 111 default via 192.168.1.254 dev eth1 [EMAIL PROTECTED]:~# ip route ls table 222 default via 192.168.2.254 dev eth2 [EMAIL PROTECTED]:~# uname -a Linux ubuntu 2.6.15-23-386 #1 PREEMPT Tue May 23 13:49:40 UTC 2006 i686 GNU/Linux [EMAIL PROTECTED]:~# ip -V ip utility, iproute2-ss041019 [EMAIL PROTECTED]:~# ip route get 1.2.3.1 1.2.3.1 via 192.168.2.254 dev eth2 src 192.168.1.1 cache mtu 1500 advmss 1460 hoplimit 64 [EMAIL PROTECTED]:~# ip route get 1.2.3.2 1.2.3.2 via 192.168.2.254 dev eth2 src 192.168.2.1 cache mtu 1500 advmss 1460 hoplimit 64 As you can see, the "ip route get" always returns ".. via 192.168.2.254 dev eth2 ..." and only switches the source ip but not the corresponding interface and gateway. I saw this behaviour a long time ago on Debian, but by now, on Debian Woody this is working fine as least on kernel 2.6.14 and 2.6.16 with the same iproute package and the "ip route get" output also gives the right interface and gateway ( I did not test it on more environments ). On an installed Ubuntu 6.06 LTS the behaviour is also wrong ( I found this problem on a 2.6.15-28-server kernel with the same iproute package ). ¿ Any idea why this is happening ? ¿ Is this a regression ? ¿ Any suggestions ? Kind Regards, Eric Janz -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4
Andy Furniss <[EMAIL PROTECTED]> wrote on 10/04/2007 21:29:33: > [EMAIL PROTECTED] wrote: > > > thanks for the info. First of all, in order to use the nth match you need > > to patch your kernel using patch-o-matic. > > I think nth is in kernel now as part of the statistic match. > > Andy. I was searching this yesterday afternoon and could not verify it. Today I found it in the 2.6.18 kernel's changelog: [NETFILTER]: x_tables: add statistic match Add statistic match which is a combination of the nth and random matches. Signed-off-by: Patrick McHardy <...> Signed-off-by: David S. Miller <...> commit 62b7743483b402f8fb73545d5d487ca714e82766 Author: Patrick McHardy <...> Date: Mon May 29 18:20:32 2006 -0700 ¿ Does this match help you to solve the problem ? Regards, Eric -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4
Andrew Lyon <[EMAIL PROTECTED]> wrote on 10/04/2007 16:34:52: > > > > > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Sent: 10 April 2007 15:17 > >To: lartc@mailman.ds9a.nl > >Subject: Re: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4 > > > > > >Hi Andrew, > > > >I would use a combination with iptables. You should mark the packets, for > example using average or n-th, and then use ip rules to send half of the > packets vía one router and the rest to the other router according to the > marks you set with iptables. > >Just a question ¿ dont you have problems with your source IP and the > returning responses when you are sending packets from one connection over > multiple routers ? ¿ do you have something like an AS ? > > > > > >Best regards, > >Eric Janz > > > > > >Andrew Lyon <[EMAIL PROTECTED]> > >Enviado por: [EMAIL PROTECTED] > >10/04/2007 14:36 > >Para > >"'lartc@mailman.ds9a.nl'" > >cc > > > >Asunto > > [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4 > > > > Eric, > > Could you give me a example of how to do that? With nth if possible... > > It is not common for a ISP to support that sort of setup, but they do > http://aaisp.net.uk/aa/aaisp/multiline.html > > Each line has two ips, one for the router and another for the interface on a > linux box or other device, the isp routes a larger /28 down both lines, and > allows packets with source address in the /28 range to be sent through both > lines. > > On my linux server I have a routing table for each line with the necessary > routes to make each router ip reachable, and a default route that equalizes > over both router ips, it worked with 2.4 but with 2.6 it seems to be > per-flow instead of per packet. > > I can login to a control page app on the ISP website and configure which > lines a given block is routed down, and they also do really good traffic > monitoring etc http://www.aaisp.net.uk/cqm.html > > PS. Please reply below original posting, not above! > http://en.wikipedia.org/wiki/Top-posting > > Andy > > > JOSEDV001TAG Hi Andy, thanks for the info. First of all, in order to use the nth match you need to patch your kernel using patch-o-matic. After that, the nth match should be available. Try something like this: Supposing that the local traffic is entering into your linux server via eth0: 1. Mark the packets using iptables before the routing decision is done: iptables -t mangle -A PREROUTING -i eth0 -m nth --every 2 --packet 0 -j MARK --set-mark 111 iptables -t mangle -A PREROUTING -i eth0 -m nth --every 2 --packet 1 -j MARK --set-mark 222 2. Setup some rules to jump to the correct routing tables. In this case I will suppose that you are using the tables 111 and 222 ( obviously you can use the ones you like ) ip rule add prio 111 fwmark 111 table 111 ip rule add prio 222 fwmark 222 table 222 ( you can also set the priority of the rules at your convenience ) 3. Setup your routing tables ( in this example 111 and 222 ) to reach each router as you had with the 2.4 kernel. [ ... ] ip route add table 111 default via ROUTER1_IP_ADDRESS ip route add table 222 default via ROUTER2_IP_ADDRESS In this case we need no multipath route. Half of all the packets that come into eth0 are routed using the 111 table and the rest is routed using the 222 table thanks to the marks we set. The problems you are experiencing with the multipath routing are due to that the routing decision uses a cache and after a routing decision to a destination is done, it would always use the same gateway to reach that destination until the routing caché expires. I hope this helps, Regards, Eric Janz -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4
Hi Andrew, I would use a combination with iptables. You should mark the packets, for example using average or n-th, and then use ip rules to send half of the packets vía one router and the rest to the other router according to the marks you set with iptables. Just a question ¿ dont you have problems with your source IP and the returning responses when you are sending packets from one connection over multiple routers ? ¿ do you have something like an AS ? Best regards, Eric Janz Andrew Lyon <[EMAIL PROTECTED]> Enviado por: [EMAIL PROTECTED] 10/04/2007 14:36 Para "'lartc@mailman.ds9a.nl'" cc Asunto [LARTC] equalize / ecmp not working as expected in 2.6 vs 2.4 Hi, With kernel 2.4 I was able to use equalize to send our outgoing packets to two different routers (our isp supports this setup), like this: ip route add default src ip.a.dd.rr equalize nexthop via weight 1 nexthop via weight 1 The two routes were used equally on a per packet basis, not per flow or per cached route, but per packet, each line has 800k upload and with that route we could upload to a single remote host at 1.6mbit. We replaced the server with a newer one and changed to 2.6 (2.6.20) kernel, I found that equalize no longer works as expected, it does choose a router at random but once a single packet has been sent to a remote host the same route/router is used for all packets going to that remote host. Once the cached route expires a random route is chosen again, but that is not what we want. I had made no changes to the ip route commands, but then I realised that kernel 2.6.20 has options for multipath (IP: equal cost multipath with caching support), I enabled that and now our kernel options are: CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_MULTIPATH_CACHED=y CONFIG_IP_ROUTE_MULTIPATH_RR=m CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m CONFIG_IP_ROUTE_MULTIPATH_DRR=m But even with these options, and default route set as follows: ip route add default src ip.a.dd.rr mpath rr nexthop via weight 1 nexthop via weight 1 The result is the same, a single upload to a remote host only uses 800k bandwidth on one of the lines, it does not send packets to both lines, although two uploads to two different hosts will usually make use of both lines. It seems to me that the multipath with caching support is broken in 2.6.20? The exact kernel we use is 2.6.20.4, with that kernel how would you specify a remote route such that packets going to a remote host are sent 50/50 ratio to two different routers? Thanks Andy JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Re: htb traffic shaping problem
Hi,could you check the mtu set on eth0 with an ifconfig?I tried my own setup and it works fine...Regards,Eric Janz Departamento de SistemasGrupo Barceló ViajesC\ 16 de Julio, 7507009 Polígono Son CastellóPalma de Mallorca - BalearesTel.: +34 971 448030Fax.: +34 971 436986Bugzilla-Redirect <[EMAIL PROTECTED]>Enviado por: [EMAIL PROTECTED]13/09/2006 07:00Paralartc@mailman.ds9a.nlccAsunto[LARTC] Re: htb traffic shaping problemEric, here's the information you requested with the mtu set at 1500 (see further below):-[EMAIL PROTECTED]:~# tc -s -d qdisc show dev eth0qdisc htb 1: r2q 10 default 99 direct_packets_stat 335 ver 3.17 Sent 10388909 bytes 763 pkt (dropped 0, overlimits 372 requeues 0) rate 0bit 0pps backlog 0b 11p requeues 0qdisc sfq 10: parent 1:10 limit 128p quantum 1514b flows 128/1024 Sent 10328092 bytes 190 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 707234b 11p requeues 0qdisc sfq 99: parent 1:99 limit 128p quantum 1514b flows 128/1024 Sent 19927 bytes 188 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0[EMAIL PROTECTED]:~# tc filter show dev eth0filter parent 1: protocol ip pref 49151 u32filter parent 1: protocol ip pref 49151 u32 fh 801: ht divisor 1filter parent 1: protocol ip pref 49151 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:10 match 01bb/ at 20filter parent 1: protocol ip pref 49152 u32filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 match 0050/ at 20[EMAIL PROTECTED]:~#-Gypsy, I've been playing with the mtu settings. I had initially set it to 1500, which is what the card should be at as the switch I have does not support jumbo frames. If I set the mtu to 40,000 for the class the giants go away and everything seems to fall back into place. However, this seems way off what it should be, do you have any idea whats happening? I cannot seem to adjust the mpu setting.-updated classes:tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbit mtu 4tc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbit quantum 3000 mtu 4tc class add dev eth0 parent 1:1 classid 1:99 htb rate 900mbit ceil 1000mbit quantum 3000 mtu 4[EMAIL PROTECTED]:~# tc -s -d class show dev eth0class htb 1:99 parent 1:1 leaf 99: prio 0 quantum 3000 rate 90Kbit ceil 1000Mbit burst 489825b/256 mpu 0b overhead 0b cburst 539875b/256 mpu 0b overhead 0b level 0 Sent 31203 bytes 282 pkt (dropped 0, overlimits 0 requeues 0) rate 7264bit 8pps backlog 0b 0p requeues 0 lended: 282 borrowed: 0 giants: 0 tokens: 4695 ctokens: 4657class htb 1:1 root rate 1000Mbit ceil 1000Mbit burst 539875b/256 mpu 0b overhead 0b cburst 539875b/256 mpu 0b overhead 0b level 7 Sent 1126563 bytes 654 pkt (dropped 0, overlimits 0 requeues 0) rate 254848bit 15pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 4657 ctokens: 4657class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 3000 rate 512000bit ceil 512000bit burst 40255b/256 mpu 0b overhead 0b cburst 40255b/256 mpu 0b overhead 0b level 0 Sent 110 bytes 378 pkt (dropped 0, overlimits 0 requeues 0) rate 250464bit 10pps backlog 0b 6p requeues 0 lended: 372 borrowed: 0 giants: 0 tokens: -694028 ctokens: -694028[EMAIL PROTECTED]:~# tc -s -d qdisc show dev eth0qdisc htb 1: r2q 10 default 99 direct_packets_stat 338 ver 3.17 Sent 1609761 bytes 1180 pkt (dropped 0, overlimits 369 requeues 0) rate 0bit 0pps backlog 0b 3p requeues 0qdisc sfq 10: parent 1:10 limit 128p quantum 1514b flows 128/1024 Sent 1536378 bytes 509 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 29362b 3p requeues 0qdisc sfq 99: parent 1:99 limit 128p quantum 1514b flows 128/1024 Sent 32175 bytes 283 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0[EMAIL PROTECTED]:~# tc filter show dev eth0filter parent 1: protocol ip pref 49151 u32filter parent 1: protocol ip pref 49151 u32 fh 801: ht divisor 1filter parent 1: protocol ip pref 49151 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:10 match 01bb/ at 20filter parent 1: protocol ip pref 49152 u32filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:10 match 0050/ at 20[EMAIL PROTECTED]:~#-Thanks.-Ryan PowerAt 04:00 AM 9/12/2006, you wrote:>Message:
Re: [LARTC] Re: htb traffic shaping problem (Charlie Meyer)
Hi again,sorry for my late response. Could you give us also the output of tc -s -d qdisc show dev eth0tc filter show dev eth0It is very strange that the rate and ceil from class 1:10 are set to 512Kbit but the class's rate goes over 3,5Mbits!! ¿Maybe it is a bug?I'm preparing a similar setup (a linux wan router on a 100Mbit lan with 5Mbps upload/dowload to the Internet. We will see if I run into the same issues...Regards,Eric Janz Bugzilla-Redirect <[EMAIL PROTECTED]>Enviado por: [EMAIL PROTECTED]09/09/2006 21:56Paralartc@mailman.ds9a.nlccAsunto[LARTC] Re: htb traffic shaping problem (Charlie Meyer)Eric,I've attached the output from the command you requested below.I'm using kernel 2.6.17.12 and tc version ss060323. I'm have a nforce4 onboard giggabit controller using the forcedeth driver, if that makes a difference.Charlie,I'll take a look at the Apache model for throttling, thanks. I was going for tc because was going to try to add additional shaping to non-apache traffic once I got it working correctly.Thanks,-Ryan Powertc -s -d class show dev eth0class htb 1:99 parent 1:1 leaf 99: prio 0 quantum 3000 rate 90Kbit ceil 1000Mbit burst 451350b/8 mpu 0b overhead 0b cburst 501375b/8 mpu 0b overhead 0b level 0 Sent 48695 bytes 398 pkt (dropped 0, overlimits 0 requeues 0) rate 2704bit 2pps backlog 0b 0p requeues 0 lended: 398 borrowed: 0 giants: 0 tokens: 4326 ctokens: 4325class htb 1:1 root rate 1000Mbit ceil 1000Mbit burst 501375b/8 mpu 0b overhead 0b cburst 501375b/8 mpu 0b overhead 0b level 7 Sent 32821394 bytes 994 pkt (dropped 0, overlimits 0 requeues 0) rate 3556Kbit 10pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 1128 tokens: 4325 ctokens: 4325class htb 1:10 parent 1:1 leaf 10: prio 0 quantum 3000 rate 512000bit ceil 512000bit burst 1755b/8 mpu 0b overhead 0b cburst 1755b/8 mpu 0b overhead 0b level 0 Sent 34256069 bytes 701 pkt (dropped 0, overlimits 0 requeues 0) rate 3554Kbit 8pps backlog 0b 105p requeues 0 lended: 596 borrowed: 0 giants: 1128 tokens: -52724 ctokens: -52724___LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] htb traffic shaping problem
Good afternoon,your configuration seems correct to me. Could you send us the output of "tc -s -d class show dev eth0" during your probes?What kernel and tc versions are you using?Regards,Eric Janz Departamento de SistemasGrupo Barceló ViajesC\ 16 de Julio, 7507009 Polígono Son CastellóPalma de Mallorca - BalearesTel.: +34 971 448030Fax.: +34 971 436986Bugzilla-Redirect <[EMAIL PROTECTED]>Enviado por: [EMAIL PROTECTED]08/09/2006 10:02Paralartc@mailman.ds9a.nlccAsunto[LARTC] htb traffic shaping problemHello.I have a linux server connected to a gigabit lan, and though that lan to a 768kbps/768kbps DSL modem.I'm trying to shape my webserver running on port 80/443 down to 512kbps, while leaving all other ports alone. The current configuration script that I'm using is as follows:tc qdisc del dev eth0 roottc qdisc add dev eth0 root handle 1: htb default 99tc class add dev eth0 parent 1: classid 1:1 htb rate 1000mbit ceil 1000mbittc class add dev eth0 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbittc qdisc add dev eth0 parent 1:10 handle 10: sfqtc class add dev eth0 parent 1:1 classid 1:99 htb rate 900mbit ceil 1000mbittc qdisc add dev eth0 parent 1:99 handle 99: sfqtc filter add dev eth0 protocol ip parent 1: u32 match ip sport 80 0x flowid 1:10tc filter add dev eth0 protocol ip parent 1: u32 match ip sport 443 0x flowid 1:101:10 seems to be getting the correct traffic from port 80 and 443 while everything else is run to 1:99. The problem is that, while 1:10 is slowing the connection down to a degree, it's nowhere near the set limit. For example: the connection will start out around 50kBps, and then suddenly bounce to over 1MBps, far exceeding it's 64kBps setting.Setting the parent down to 512kbits seems to work correctly, but it cripples the local network.Can anyone point out what I've done incorrectly, or is this a bug?Thank you.-Ryan Power ___LARTC mailing listLARTC@mailman.ds9a.nlhttp://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] tc filter don't match packets
Hi,in this simple case you must attach the filter to the root:[...]> tc qdisc add dev eth0 root handle 1: htb default 10 [...]> tc filter add dev eth0 parent 1:11 protocol ip prio 1 u32 match ip > dport 80 0x flowid 1:11[...]Should be:tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 80 0x flowid 1:11The traffic gets enqueued traversing the filters attached to each node but starting at the root node. You must provide a way to arrive to a leaf.In man tc-htb it says: "When enqueueing a packet, HTB starts at the root and uses various meth- ods to determine which class should receive the data. In the absence of uncommon configuration options, the process is rather easy. At each node we look for an instruction, and then go to the class the instruction refers us to. If the class found is a barren leaf-node (without children), we enqueue the packet there. If it is not yet a leaf node, we do the whole thing over again starting from that node. The following actions are performed, in order at each node we visit, until one sends us to another node, or terminates the process. (i) Consult filters attached to the class. If sent to a leafnode, we are done. Otherwise, restart. (ii) If none of the above returned with an instruction, enqueue at this node. This algorithm makes sure that a packet always ends up somewhere, even while you are busy building your configuration."In your case, the packets arrive to the root node to get enqueed but due to that there is no filter attached it will get to the default 10.I hope this helps,Regards,Eric Janz -- ADVERTENCIA LEGAL El contenido de este correo es confidencial y dirigido unicamente a su destinatario. Para acceder a su clausula de privacidad consulte http://www.barceloviajes.com/privacy LEGAL ADVISORY This message is confidential and intended only for the person or entity to which it is addressed. In order to read its privacy policy consult it at http://www.barceloviajes.com/privacy ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
