Re: [LARTC] Explanation reqd. for few (more than few!) concepts in TC long
Hi, --- Stef Coene [EMAIL PROTECTED] wrote: http://lartc.org/lartc.html#AEN939 ; the part that lists parameters in CBQ ... was wondering how 'cell' can be defined. If you bound a class, the class can never send more then the configure rate. So that's the ceil. If you add a sub class (not bounded), that class has to respect the rate (in this case also the ceil) of it's parente. ! And htb is maintained, while the cbq code is not. in my xp, that sure is a reason to be using it :) Don't trust the help function :(. My tip : go to http://docum.org, go to the test pages and copy my cbq commands ,) okey! now I understand what you earlier meant by test pages. Was there, you syntax works ... which means the tc help isn't exhaustive, well that's a pity. Thank you. Do you have any pointers to where I can find a list of parameters configurable with a particular queue? Stef, I do really appreciate the time spent in trying to help me. Thank you. No problem. :) Thank you. Regards, suraj. __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] tc filter oddities
I shape my upstream cable link with HTB from a script. My voip traffic (from the 192.168.0.14 host) gets priority over everything else to the near-starvation of other classes; the rest of the traffic is split up based on some priority rules (qos, empty ack packets, etc). eth1 is the uplink I've been using HTB and fw marking for the job until recently, when I changed the queue structure around a bit, and moved to tc filters (no marking). None of my filters are working, in fact none are being applied, or respecting the 'parent' attribute that I give them. All of my filters end up with parent 1: All qdiscs are empty save for the root qdisc, and all packets from that one seem to be direct_packet_stat'd from it... when I added default values to the htb qdiscs, this just caused all packets to filter down to whatever default class I specified, and continue to get direct_packet_stat'd from those... so.. I'm trying to sort out why my filters aren't working and why they're not getting the parents I've intended. comments on the sanity of my queue structure are welcomed (as are all others), but really I should be able to deal with that after my filters agree to work, as the fw ones were beforehand. copy of script (commented): //root limited to 120kbits (on 128kbit link) tc qdisc add root dev eth1 handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 120kbit ceil 120kbit burst 2k //first one is voip, second one is everything else //this is a change from how i was doing it before and is untested tc class add dev eth1 parent 1:1 classid 1:10 htb rate 100kbit ceil 120kbit burst 2k prio 1 tc class add dev eth1 parent 1:1 classid 1:20 htb rate 20kbit ceil 120kbit burst 2k prio 2 //3 prio classes for the 'everything else' traffic tc class add dev eth1 parent 1:20 classid 1:21 htb rate 40kbit burst 2k prio 1 tc class add dev eth1 parent 1:20 classid 1:22 htb rate 40kbit burst 2k prio 2 tc class add dev eth1 parent 1:20 classid 1:23 htb rate 40kbit burst 2k prio 3 //sfq's for the prio classes tc qdisc add dev eth1 parent 1:21 handle 121: sfq tc qdisc add dev eth1 parent 1:22 handle 122: sfq tc qdisc add dev eth1 parent 1:23 handle 123: sfq //filters - first and second for voip and other tc filter add dev eth1 parent 1:0 prio 1 protocol ip u32 match ip src 192.168.0.14 flowid 110: tc filter add dev eth1 parent 1:0 prio 1 protocol ip u32 match ip dst 0/0 flowid 1:20 //and others are for qos min-delay, empty-ack, and everything else tc filter add dev eth1 parent 1:20 pref 2 protocol ip u32 match ip tos 0x10 0xff flowid 121: tc filter add dev eth1 parent 1:20 pref 3 protocol ip u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthd r+13 match u16 0x 0xffc0 at 2 flowid 122: tc filter add dev eth1 parent 1:20 pref 4 protocol ip route flowid 123: --- tc -s -d qdisc ls: qdisc sfq 123: dev eth1 quantum 1514b limit 128p flows 128/1024 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 122: dev eth1 quantum 1514b limit 128p flows 128/1024 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 121: dev eth1 quantum 1514b limit 128p flows 128/1024 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 166 ver 3.10 Sent 27491 bytes 166 pkts (dropped 0, overlimits 0) -- and perhaps more interesting is tc filter show dev eth1 (eth1=upstream) filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 802: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 122: match 0006/00ff at 8 match 0010/00ff at nexthdr+12 match /ffc0 at 0 filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 121: match 0010/00ff at 0 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 110: match c0a8000e/ at 12 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:20 match / at 16 (parents == 1: ??!) Thanks in advance all for your comments on this. --Justin Whitney ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Explanation reqd. for few (more than few!) concepts in TC long
On Friday 31 October 2003 08:23, Suraj Shankar wrote: Don't trust the help function :(. My tip : go to http://docum.org, go to the test pages and copy my cbq commands ,) okey! now I understand what you earlier meant by test pages. Was there, you syntax works ... which means the tc help isn't exhaustive, well that's a pity. Thank you. Do you have any pointers to where I can find a list of parameters configurable with a particular queue? Not really. The htb parameters are easy to understand. The cbq parameters are not. Some information can be found in the tc source, some in the kernel source. That's one of the reasons I suggest htb. 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/
[LARTC] (no subject)
I want to unsubscribe from this list can anybody tell how to do that... thanx... Liviu Liviu Obreja Network Administrator Romania Data Systems SA - Arad str. Spitalului Bl. 2B, Arad tel. +40-57-228.200 fax. +40-57-228.201 email: [EMAIL PROTECTED] - - Don't ever be afraid of shadows. They only show the presence of light around. ~ Gary Sinise Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such a case, you should destroy this message and kindly notify the sender by reply e-mail. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Question about iptables and maximum file size
Hi, I would like to know if there is any possibility to select from iptables the files with maximum size of 300 kbytes and send them to a proxy server. As I know until now you can only mark files with maximum size of 64 kbytes. thank you in advance, Codrin. ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] QoS / VoIP
Hello, Please excuse any of my errors, as I am new to this list (Just signed last night!) Here is my situation. I have four remote offices, one connected by a wireless link, one connected by a regular T1 and two connected by frame. We have just switched PBX's and are now using VoIP phones instead of landlines. My problem is (obviously) with VoIP, the voice is getting choppy whenever there is high data transfers. My question is, for the office with a T1, should I put a QoS box on both ends? (One here at HQ, and one there?) Same with the frame? And correct me if I'm wrong, but I will need one at both ends for the wireless link. If have read most of the LARTC HOW-TO, but it hasn't sank in totally (trying to take a drink from a fire hydrant) Thanks in advance, -- Brian M. Diehl Network Admin A-1 Limousine Inc. 609-919-2019 ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Question about iptables and maximum file size
On Friday, 31 October 2003, at 12:15:54 +0200, The Codrinus wrote: I would like to know if there is any possibility to select from iptables the files with maximum size of 300 kbytes and send them to a proxy server. As I know until now you can only mark files with maximum size of 64 kbytes. iptables only knows about layer 2, 3 and 4. Files and their sizes is a layer 7 thing, and depends entirely on the application protocol used to transfer them (SMB, CIFS, NFS, FTP, HTTP, SSH, etc.). So the short answer is no, you can't select packages based on file sizes, it doesn't make any sense. But you obviously can select IP packages based on their size (match length). However, remember that MTU in normal layer 2 networks, typically ethernet, have a value of 1500 bytes, so I think in normal conditions you will not see any packages larger than that (except if you use jumboframes, FR or the like). -- Jose Luis Domingo Lopez Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm1) ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Can't use fwmark filters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Sun, 26 Oct 2003, Alex wrote: tc filter add dev ppp0 parent 1: protocol ip prio 1 handle 1 fw classid 1:10 tc filter add dev ppp0 parent 1: protocol ip prio 1 handle 6 fw classid 1:60 Which works fine. Adding this single line triggers the error again : tc filter add dev ppp0 parent 1: protocol ip prio 1 u32 \ match ip tos 0x10 0xff flowid 1:10 --- RTNETLINK answers: Invalid argument Looks like the same problem what i reported ~2 months ago. A quick solution would be to use different prio's for fw filters and u32 filters. - -- Marton Sandor - [EMAIL PROTECTED] GPG id: 0x32825B5A , www.keyserver.net BOFH excuse #438: sticky bit has come loose -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/osMrKiUXNzKCW1oRAs/QAJ9CZzpifK6WEdBriFGsCUDN7gYHGACdGkdS VYdgeBMVFlq1pCLYfsFQvzo= =4lXy -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] tc filter oddities
Thanks, I ran with that and got things working. The filters that I saw as not respecting their parent attribute were in fact dupes from the u32 bug, and present in both 1:20 and 1: (according to filter show). I made some adjustments to the queues, and i'll post my results later so that anyone in a similar situation can have something to work from. --Justin Whitney On Fri, 2003-10-31 at 03:38, Catalin BOIE wrote: Hi! //root limited to 120kbits (on 128kbit link) tc qdisc add root dev eth1 handle 1: htb tc class add dev eth1 parent 1: classid 1:1 htb rate 120kbit ceil 120kbit burst 2k //first one is voip, second one is everything else //this is a change from how i was doing it before and is untested tc class add dev eth1 parent 1:1 classid 1:10 htb rate 100kbit ceil 120kbit burst 2k prio 1 tc class add dev eth1 parent 1:1 classid 1:20 htb rate 20kbit ceil 120kbit burst 2k prio 2 //3 prio classes for the 'everything else' traffic tc class add dev eth1 parent 1:20 classid 1:21 htb rate 40kbit burst 2k prio 1 tc class add dev eth1 parent 1:20 classid 1:22 htb rate 40kbit burst 2k prio 2 tc class add dev eth1 parent 1:20 classid 1:23 htb rate 40kbit burst 2k prio 3 //sfq's for the prio classes tc qdisc add dev eth1 parent 1:21 handle 121: sfq tc qdisc add dev eth1 parent 1:22 handle 122: sfq tc qdisc add dev eth1 parent 1:23 handle 123: sfq //filters - first and second for voip and other tc filter add dev eth1 parent 1:0 prio 1 protocol ip u32 match ip src 192.168.0.14 flowid 110: I think here is 1:10, right? tc filter add dev eth1 parent 1:0 prio 1 protocol ip u32 match ip dst 0/0 flowid 1:20 OK, till here. //and others are for qos min-delay, empty-ack, and everything else tc filter add dev eth1 parent 1:20 pref 2 protocol ip u32 match ip tos 0x10 0xff flowid 121: Here must be 1:21. tc filter add dev eth1 parent 1:20 pref 3 protocol ip u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthd r+13 match u16 0x 0xffc0 at 2 flowid 122: Here must be 1:22. tc filter add dev eth1 parent 1:20 pref 4 protocol ip route flowid 123: Here must be 1:23. Try this and come back. --- tc -s -d qdisc ls: qdisc sfq 123: dev eth1 quantum 1514b limit 128p flows 128/1024 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 122: dev eth1 quantum 1514b limit 128p flows 128/1024 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 121: dev eth1 quantum 1514b limit 128p flows 128/1024 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 166 ver 3.10 Sent 27491 bytes 166 pkts (dropped 0, overlimits 0) -- and perhaps more interesting is tc filter show dev eth1 (eth1=upstream) filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 802: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 802::800 order 2048 key ht 802 bkt 0 flowid 122: match 0006/00ff at 8 match 0010/00ff at nexthdr+12 match /ffc0 at 0 filter parent 1: protocol ip pref 1 u32 fh 801: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 801::800 order 2048 key ht 801 bkt 0 flowid 121: match 0010/00ff at 0 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 110: match c0a8000e/ at 12 filter parent 1: protocol ip pref 1 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:20 match / at 16 (parents == 1: ??!) Thanks in advance all for your comments on this. --Justin Whitney ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ --- Catalin(ux) BOIE [EMAIL PROTECTED] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
RE: [LARTC] beta-release of H-FSC port for Linux 2.6
Hello Patrick, I read the abstract and introduction to original H-FSC paper. I believe it was mostly about decoupling bw and delay. It seems to me HTB does this well. When and/or why would I would want to use H-FSC versus HTB or are they direct competitors? Curious, Torsten -Original Message- From: Patrick McHardy [mailto:[EMAIL PROTECTED] Sent: Sunday, October 26, 2003 10:05 AM To: [EMAIL PROTECTED] Subject: [LARTC] beta-release of H-FSC port for Linux 2.6 I've done a port of the altq H-FSC packet scheduler for linux 2.6. It's still in beta stage but it's running for about two weeks here without problems (and excellent shaping results). There is no documentation, so it's at best for the playful at the moment. The patches are available at http://trash.net/~kaber/hfsc If you are looking for 2.4 patches, there are none at the moment but it's a 5 minute effort so if you need them please ask. Please note due to a lack of time I will only answer basic usage questions at this point and for sure I won't review tc scripts without detailed bug reports. Have Fun, Patrick BTW: on a related issue, IMQ is looking for a new maintainer. If you are interested please contact me. ___ 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/
[LARTC] fwmark routing of locally generated packets
Hi Thomas, We have the same problem. ;) You're right, it doesn't make any sense. Can anyone elaborate?? My setup is virtually identical to what Thomas has. However, I'm using IPMASQ on my outgoing connection, so I am able to see that the problem exists even without using SNAT. Something is borked... Thomas Themel [EMAIL PROTECTED] Tue, 28 Oct 2003 01:32:09 +0100 Hi, I'm currently trying to get a Linux machine to route all traffic coming from a certain UID over a dedicated PPP interface. After going throught the available documentation and experimenting a bit, I settled for the following attempt: # 62.46.87.104 - local PPP address # 195.4.91.104 - PPP peer ip route add 195.3.91.104 dev ppp0 src 62.46.87.104 table special # local for DNS etc ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1 table special ip route add default via 195.3.91.104 src 62.46.87.104 table special ip rule add fwmark 3 lookup special iptables -t mangle -A OUTPUT -m owner --uid-owner freenet -j MARK --set-mar= k 3 ip route flush cache This seems to work in a way. It correctly sends the packets generated by that user out the ppp0 interface, but they don't get the correct source address: | sophokles:~# sh -x description.txt=20 | + ip route flush table aon | + ip route add 195.3.91.103 dev ppp0 src 62.46.86.137 table aonc | + ip route add 192.168.1.0/24 dev eth0 src 192.168.1.1 table aonc | + ip route add default via 195.3.91.103 src 62.46.86.137 table aonc | + ip rule add fwmark 3 lookup aonc | + iptables -t mangle -A OUTPUT -m owner --uid-owner freenet -j MARK | --set-mark 3 | + ip route flush cache | sophokles:~# tcpdump -ni ppp0 port 22 =20 | [1] 841 | sophokles:~# tcpdump: listening on ppp0 |=20 | sophokles:~# nc iwoars.net 22 | SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 |=20 | sophokles:~# su - freenet | [EMAIL PROTECTED]:~$ nc iwoars.net 22 | 01:25:17.044883 192.168.1.1.32848 217.160.110.113.22: SWE | 1344336467:1344336467(0) win 5840 mss 1460,sackOK,timestamp 2056533 | 0,nop,wscale 0 (DF) | 01:25:20.043828 192.168.1.1.32848 217.160.110.113.22: SWE | 1344336467:1344336467(0) win 5840 mss 1460,sackOK,timestamp 2059533 | 0,nop,wscale 0 (DF) | 01:25:26.042584 192.168.1.1.32848 217.160.110.113.22: SWE | 1344336467:1344336467(0) win 5840 mss 1460,sackOK,timestamp 2065533 | 0,nop,wscale 0 (DF) |=20 | [EMAIL PROTECTED]:~$=20 I've read on this list that owner-based policy routing is impossible because the routing decision is made before the packet traverses the OUTPUT chain. However, if this is true, then I don't understand how the packet can go out via the correct interface unless there are separate route lookups to determine the source address and outgoing interface. Could someone who knows please elaborate? I have also tried, unsuccessfully, to just mangle the source address using an iptables SNAT rule, but even though that produces correct network traffic, it seems to break something internally that keeps the TCP handshake from completing: | sophokles:~# iptables -t nat -A POSTROUTING -j SNAT -o ppp0 --to-source| 62.46.86.137 | sophokles:~# su - freenet | [EMAIL PROTECTED]:~$ nc iwoars.net 22 | 01:30:16.448930 62.46.86.137.32849 217.160.110.113.22: SWE | 1656968486:1656968486(0) win 5840 mss 1460,sackOK,timestamp 2356000 | 0,nop,wscale 0 (DF) | 01:30:16.516732 217.160.110.113.22 62.46.86.137.32849: S | 2293250552:2293250552(0) ack 1656968487 win 32120 mss | 1460,sackOK,timestamp 313375234 2356000,nop,wscale 0 (DF) | 01:30:19.448146 62.46.86.137.32849 217.160.110.113.22: SWE | 1656968486:1656968486(0) win 5840 mss 1460,sackOK,timestamp 2359000 | 0,nop,wscale 0 (DF) | 01:30:19.518099 217.160.110.113.22 62.46.86.137.32849: S | 2293250552:2293250552(0) ack 1656968487 win 32120 mss | 1460,sackOK,timestamp 313375535 2356000,nop,wscale 0 (DF) | 01:30:19.823023 217.160.110.113.22 62.46.86.137.32849: S | 2293250552:2293250552(0) ack 1656968487 win 32120 mss | 1460,sackOK,timestamp 313375566 2356000,nop,wscale 0 (DF) | [...] ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
