Re: [LARTC] TC (HTB) doesn't work well when network is congested?
William Xu wrote: Thank you, Peter, After changing CONFIG_HZ to 1000, TC works much better. I still need to limit the total bandwidth to 110MB/s (about 90% of 125MB/s), but that's normal I guess. snip Yes, it's normal. Depending on the situation and tests you'll be allocating about 90% - 99% of the actual link capacity to tc. 100% will generally never work good as link queues start filling up and you don't want this. You (tc) should be the bottleneck of the link thus you can say what and how much goes where. -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] about default filter command
Vincent Dautremont wrote: Hi, here I have another newcomer question :-) in the section 9.6.1 of this how too http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.filters.html we can read commands about filters : -- # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip dport 22 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \ ip sport 80 0x flowid 10:1 # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 What does this say? It says: attach to eth0, node 10: a priority 1 u32 filter that matches on IP destination port 22 *exactly* and send it to band 10:1. And it then repeats the same for source port 80. The last command says that anything unmatched so far should go to band 10:2, the next-highest priority. -- i try to do this at home as i want my ssh traffic prioritary to other traffic but the problem is with the last command ! it simply don't work. The last command that says default trafic goes to prio 2 doesn't work # tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 just give me the error: Unknown filter flowid, hence option 1:2 is unparsable So I don't get what do I must do in order to say that the default trafic goes on priority 2 of the prio filter is this how too always valid with the current version of tc ? did i do something wrong ? Thank you for your help. snip You should have posted *all* your tc rules. -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping of pppoe clients
Kenneth Kalmer wrote: The keyword here is better, and that was my argument for using a bridge in the first place. It would appear to be easier to shape filter away from the messy scripts of pppd radius servers, but this raises the next issue. For the bridge, is the pppoe sessions identifiable using say source destination ips, as opposed to pppoe traffic... I know if I perform a tcpdump on the interface that I connect to my adsl modem I only see the traffic as pppoe... Logic tells me that the bridge would suffer the same consequenses... Yes, that was my concern too. Maybe someone else on the list that has already went trought this may share the experience. I will test it as soon as I get my hands on a spare machine ;-) -- regards, Georgi Alexandrov key server - http://pgp.mit.edu/ :: key id - 0x37B4B3EE key fingerprint - E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Shaping of pppoe clients
Kenneth Kalmer wrote: Guys After reading through the archives I found some insightful ways to be able to shape traffic to pppoe clients from the server. I have two questions on the topic of setting up a pppoe server however... 1. The clients will all be connected to each other using a normal ethernet network, the segments connected with managed switches. The capacity is roughly 500 nodes. Will these pppoe sessions interfere with each other or not? What do you mean by 'interfere' here? 2. I'd like to know if anyone has tried to shape pppoe client traffic by placing a transparent bridge between the servers and clients, and shaping on this bridge. I'm just testing the water here, after what I read in other threads it will be easier to just use a set of carefully crafted ip-up ip-down scripts with pppd rather than the bridge. But nonetheless, opinions are always needed. I use the ip-up and ip-down scripts, and a radius exec attribute so probably I can help with them. I'm planning on segmenting such a network with linux bridges for better filtering and QoS control. But that's yet to come ;-) Thanks guys -- regards, Georgi Alexandrov key server - http://pgp.mit.edu/ :: key id - 0x37B4B3EE key fingerprint - E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Conceptual question ;-)
Jody Shumaker wrote: I don't believe -j CLASSIFY targte can target sub-classes. Pretty sure you can only target classes whose parent is the root class of the qdisc. You would need to use tc filters to do this, or get rid of your redundant classes. For THB for some reason you have a root class and a child class with the same limit? This makes no sense, you'd be fine with just the 2:2 class and attaching the sfq to that, and setting the classify to that. Otherwise, yes I think this would work in setting a limit on those ppp devices as they come up to XXXkbit of bandwidth. - Jody Actually it looks like it can target sub-classes: pppoe users - eth1-gw/router-eth0 - WAN/Internet For shaping pppoe users upload i do the following: attached a root qdisc to eth0 then attached a htb class to it (1:10 for example) Then i attach dynamicaly classes to 1:10 with numbers (1:91 for ppp1 for example) with parent 1:10. There are also dynamic iptables rules (alot of dynamic stuff going on .. lol ;) saying traffic from that pppoe user going out trough eth0 CLASSIFY as 1:91 When a ppp43 is up, a class 1:943 with parent 1:10 will be attached to eth0 and iptables rule saying traffic from that pppoe user going out trough eth0 CLASSIFY as 1:943 and it seems to work fine, upload seems to be shaped at the desired rates. But that is in a one pppoe user test environment, i think it should work fine when deployed too, and each pppoe user will get their upload rates ;-) -- regards, Georgi Alexandrov Key Server = http://pgp.mit.edu/ :: KeyID = 37B4B3EE Key Fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Conceptual question ;-)
ehlo list, I'm willing to shape ppp users e.g. each pppX interface to get XXX kbits I classify traffic going to ppp+ interfaces like this: iptables -t mangle -A POSTROUTING -o ppp+ -j CLASSIFY --set-class 0002:0020 then i have a file which is executed when a ppp inteface is up and first argument parsed to that file ($1) is the ppp number (e.g. 35 for ppp35). it generally looks like this: tc qdisc del dev ppp$1 root tc qdisc add dev ppp$1 root handle 2: htb tc class add dev ppp$1 parent 2: classid 2:2 htb rate XXXkbit tc class add dev ppp$1 parent 2:2 classid 2:20 htb rate XXXkbit tc qdisc add dev ppp$1 parent 2:20 handle 20: sfq perturb 10 The question is, when for example 10 ppp interfaces are up will they each get XXX kbits. -- regards, Georgi Alexandrov Key Server = http://pgp.mit.edu/ :: KeyID = 37B4B3EE Key Fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE signature.asc Description: OpenPGP digital signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Some questions
Robb Bossley wrote: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter What does this do (it said something about spoofing, but I did not understand), and is it necessary? http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN634 Georgi Alexandrov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Some questions
Robb Bossley wrote: echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter What does this do (it said something about spoofing, but I did not understand), and is it necessary? http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html#AEN634 Georgi Alexandrov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] shareaza
ncrfgs wrote: Hi, A, B and C are three machines. A and C directly access to theInternet while B access to the Internet through A. +-+ | +-+ +-+ | | | A | | B | | | | | --- eth0 --- --- eth0 --- | | | | | 192.168.0.1 | | 192.168.0.2 | | | +-+ +-+ | +-+ | ppp0 | v Internet ^ | +---+ | C | +---+ A runs GNU/Linux and is configured to MASQUERADE B and in such a way that packets incoming on ppp0 are DROP'd unless their state is either ESTABLISHED or RELATED or unless their destination is port 6346 (both tcp and udp), in which case they are redirected to B. B runs Shareaza, a P2P that is able to access several kind of networks such as edonkey, gnutella and gnutella2 and it should only use port 6346. I'd like to shape outgoing traffic, that is, I'd like to limit the bandwidth B uses to upload files over the Internet. I'm sharing the connection with other individuals and I don't have much control over B... I only have very little informations about it, sorry, and most of them comes from tcpdump. If B uploads a file to C through gnutella everything works like a charm since packets look just like this: 192.168.0.2:6346 xxx.xxx.xxx.xxx:y With tc I filter packets whose source port is 6346 and everything is fine. Problems come when B uploads a file to C through edonkey. Packets don't always look like the former ones. Sometimes the source port is 6346 in this case as well, but more often they look like this: 192.168.0.2:z xxx.xxx.xxx.xxx:4662 Port 4662 is the most common one but it isn't always the same. How can I work around it? Thanks in advance. Best regards. You can classify the traffic from B going out trough ppp0 with netfilter/iptables like this: iptables -t mangle -A POSTROUTING -o ppp0 -s 192.168.0.2 -j CLASSIFY --set-class 0001:0010 And then shape it: tc qdisc del dev ppp0 root tc qdisc add dev ppp0 root handle 1: htb tc class add dev ppp0 parent 1: classid 1:1 htb rate 128kbit tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 128kbit tc qdisc add dev ppp0 parent 1:10 handle 10: sfq perturb 10 that's for 128kbits/sec upload from 192.168.0.2. I've attached a sfq to the htb class for smoothness. regards, Georgi Alexandrov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] shareaza
ncrfgs wrote: On Sun, Dec 11, 2005 at 05:30:55PM +0200, Georgi Alexandrov wrote: If B uploads a file to C through gnutella everything works like a charm since packets look just like this: 192.168.0.2:6346 xxx.xxx.xxx.xxx:y With tc I filter packets whose source port is 6346 and everything is fine. You can classify the traffic from B going out trough ppp0 with netfilter/iptables like this: What you wrote is indeed very similar to what I use right now except for the fact that I'm classifying according to the source port, too. The side effect of your configuration is that all of the traffic from B though ppp0 is shaped. The configuration you've suggested is interesting but I'd like to limit the shareaza traffic only. Is there any way to do that? How can I keep track of the traffic generated by shareaza only? Thanks in advance. Best regards. Perhaps you need something like l7-filter.sf.net ? Georgi Alexandrov ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
