Hi All, I''ve been playing with QOS for a short while now and have worked out how to do what I want using HTB. Great queuing discipline btw. My problem is the tc filters I want to setup aren''t working because iptables is getting to the packets first and mangling the src address. The iptables script I am using is MonMotha''s Firewall 2.3.8 and it includes lots of nice goodies like syn flood rate limiting. The extra bits like this are why I''m using it rather than figuring the iptables configuration out myself. My network configuration is trivial, adsl router connected to linux box connected to two networks, LAN and WLAN. I like having these iptables features but MonMotha''s Firewall isn''t designed with QOS in mind. My question for this list, is there a recommended iptables router script that everyone here uses designed with QOS in mind or have you all written your own ? Thanks in Advance Lee
On Jeu 12 mai 2005 8:14, Lee Sanders a écrit :> Hi All, > > I''ve been playing with QOS for a short while now and have worked out how > to do > what I want using HTB. Great queuing discipline btw. > > My problem is the tc filters I want to setup aren''t working because > iptables is getting to the packets first and mangling the src address. > > The iptables script I am using is MonMotha''s Firewall 2.3.8 and it > includes > lots of nice goodies like syn flood rate limiting. The extra bits like > this > are why I''m using it rather than figuring the iptables configuration out > myself. > > My network configuration is trivial, adsl router connected to linux box > connected to two networks, LAN and WLAN. > > I like having these iptables features but MonMotha''s Firewall isn''t > designed > with QOS in mind. > > My question for this list, is there a recommended iptables router script > that > everyone here uses designed with QOS in mind or have you all written your > own ? > > Thanks in Advance > > Lee >Hi Lee, Below is my script. It''s inspired from LARTC, for the same configuration as you : home Linux routeur with DSL on eth1, masquerading trafic from LAN. The server is running a few services (http,mail,dns), and I want these services to have priority, and also the users must have priority for their mail & http over the default class. The trafic to/from the services not defined below goes to default class, which is fine (ftp, im, ...). Hope you can use it, though it''s certainly not perfect. Sylvain #!/bin/bash UPLINK_EXT=950 # outgoing DSL bandwidth, kbps DEV_EXT=eth1 # DSL link tc qdisc del dev ${DEV_EXT} root 2> /dev/null > /dev/null tc qdisc add dev ${DEV_EXT} root handle 1: htb default 20 # root class tc class add dev ${DEV_EXT} parent 1: classid 1:1 htb rate $[${UPLINK_EXT}]kbit prio 0 # fast ( 80% ) tc class add dev ${DEV_EXT} parent 1:1 classid 1:10 htb rate $[8*${UPLINK_EXT}/10]kbit ceil $[${UPLINK_EXT}]kbit burst 10k prio 1 # slow ( 20% ) tc class add dev ${DEV_EXT} parent 1:1 classid 1:20 htb rate $[2*${UPLINK_EXT}/10]kbit ceil $[8*${UPLINK_EXT}/10]kbit burst 2k prio 5 # stochastic fairness tc qdisc add dev ${DEV_EXT} parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev ${DEV_EXT} parent 1:20 handle 20: sfq perturb 10 # trafic with priority # CLIENT tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 22 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 25 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 53 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 80 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 110 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 143 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 443 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 993 0xffff flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 995 0xffff flowid 1:10 # SERVER tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip sport 22 0xfffd flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip sport 25 0xfffd flowid 1:10 tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip dport 53 0xffff flowid 1:10
On Thu, May 12, 2005 at 09:40:56AM +0200, Sylvain BERTRAND wrote:> On Jeu 12 mai 2005 8:14, Lee Sanders a ?crit : > > Hi All, > > > > I''ve been playing with QOS for a short while now and have worked out how > > to do > > what I want using HTB. Great queuing discipline btw. > > > > My problem is the tc filters I want to setup aren''t working because > > iptables is getting to the packets first and mangling the src address. > > > > The iptables script I am using is MonMotha''s Firewall 2.3.8 and it > > includes > > lots of nice goodies like syn flood rate limiting. The extra bits like > > this > > are why I''m using it rather than figuring the iptables configuration out > > myself. > > > > My network configuration is trivial, adsl router connected to linux box > > connected to two networks, LAN and WLAN. > > > > I like having these iptables features but MonMotha''s Firewall isn''t > > designed > > with QOS in mind. > > > > My question for this list, is there a recommended iptables router script > > that > > everyone here uses designed with QOS in mind or have you all written your > > own ? > > > > Thanks in Advance > > > > Lee > > > > Hi Lee, > > Below is my script. It''s inspired from LARTC, for the same configuration > as you : home Linux routeur with DSL on eth1, masquerading trafic from > LAN. The server is running a few services (http,mail,dns), and I want > these services to have priority, and also the users must have priority for > their mail & http over the default class. The trafic to/from the services > not defined below goes to default class, which is fine (ftp, im, ...). > Hope you can use it, though it''s certainly not perfect. > > Sylvain >Sylvain Q) why use do your matching in tc filter and not netfilter ? Is one way better than the other. I started out doing it via filter and then moved to netfilter instead using mark. Curious to hear what other people have/do do Alex> > #!/bin/bash > > UPLINK_EXT=950 # outgoing DSL bandwidth, kbps > DEV_EXT=eth1 # DSL link > > tc qdisc del dev ${DEV_EXT} root 2> /dev/null > /dev/null > > tc qdisc add dev ${DEV_EXT} root handle 1: htb default 20 > > # root class > tc class add dev ${DEV_EXT} parent 1: classid 1:1 htb rate > $[${UPLINK_EXT}]kbit prio 0 > # fast ( 80% ) > tc class add dev ${DEV_EXT} parent 1:1 classid 1:10 htb rate > $[8*${UPLINK_EXT}/10]kbit ceil $[${UPLINK_EXT}]kbit burst 10k prio 1 > # slow ( 20% ) > tc class add dev ${DEV_EXT} parent 1:1 classid 1:20 htb rate > $[2*${UPLINK_EXT}/10]kbit ceil $[8*${UPLINK_EXT}/10]kbit burst 2k prio 5 > > # stochastic fairness > tc qdisc add dev ${DEV_EXT} parent 1:10 handle 10: sfq perturb 10 > tc qdisc add dev ${DEV_EXT} parent 1:20 handle 20: sfq perturb 10 > > # trafic with priority > # CLIENT > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 22 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 25 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 53 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 80 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 110 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 143 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 443 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 993 0xffff flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 995 0xffff flowid 1:10 > # SERVER > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > sport 22 0xfffd flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > sport 25 0xfffd flowid 1:10 > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > dport 53 0xffff flowid 1:10 > > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >_______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
On Jeu 12 mai 2005 10:31, Alexander Samad a écrit :> Sylvain > > Q) why use do your matching in tc filter and not netfilter ? Is one way > better than the other. > > I started out doing it via filter and then moved to netfilter instead > using mark. > > Curious to hear what other people have/do do > > Alex >If I wanted to match via netfilter, I''d have to MARK the packets, and then use tc to classify packets according to this mark. It would be a "better thing" (tm), but this is a very simple configuration, so I chose to use tc directly. Sylvain
Hi Sylvain, Thanks for that, exactly what I''m doing :) Along my travels I ran into this: http://l7-filter.sourceforge.net/ Have you played with L7 and can you rate it good/bad ? The script you sent didn''t answer one question, how to match on IP so I can add a further level of htb to equally share bandwidth amongst computers. I think I know how to do this though, filter by MAC. I don''t know if iptables at this point has munted the mac so I''m going to try that in a sec and see if I can get a match. Alex: from what I read you can do more with netfilter than you can with tc filter. Depending on your needs you would use the simplest one as I believe tc filter to be easier to understand. L7 above also uses netfilter so there''s possibly another reason. :L> > #!/bin/bash > > > > UPLINK_EXT=950 # outgoing DSL bandwidth, kbps > > DEV_EXT=eth1 # DSL link > > > > tc qdisc del dev ${DEV_EXT} root 2> /dev/null > /dev/null > > > > tc qdisc add dev ${DEV_EXT} root handle 1: htb default 20 > > > > # root class > > tc class add dev ${DEV_EXT} parent 1: classid 1:1 htb rate > > $[${UPLINK_EXT}]kbit prio 0 > > # fast ( 80% ) > > tc class add dev ${DEV_EXT} parent 1:1 classid 1:10 htb rate > > $[8*${UPLINK_EXT}/10]kbit ceil $[${UPLINK_EXT}]kbit burst 10k prio 1 > > # slow ( 20% ) > > tc class add dev ${DEV_EXT} parent 1:1 classid 1:20 htb rate > > $[2*${UPLINK_EXT}/10]kbit ceil $[8*${UPLINK_EXT}/10]kbit burst 2k prio 5 > > > > # stochastic fairness > > tc qdisc add dev ${DEV_EXT} parent 1:10 handle 10: sfq perturb 10 > > tc qdisc add dev ${DEV_EXT} parent 1:20 handle 20: sfq perturb 10 > > > > # trafic with priority > > # CLIENT > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 22 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 25 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 53 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 80 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 110 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 143 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 443 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 993 0xffff flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 995 0xffff flowid 1:10 > > # SERVER > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > sport 22 0xfffd flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > sport 25 0xfffd flowid 1:10 > > tc filter add dev ${DEV_EXT} protocol ip parent 1: prio 4 u32 match ip > > dport 53 0xffff flowid 1:10 > > > > > > _______________________________________________ > > LARTC mailing list > > LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- _____________________________________________________ Lee Sanders Computer Systems Engineer Consultant Email: tagline@ccp.com.au Professionals Mobile: 0400481632 77 122 550 929
On Jeu 12 mai 2005 10:52, Lee Sanders a écrit :> Hi Sylvain, > > Thanks for that, exactly what I''m doing :) >Ok I thought you were trying to match src addresses, and that would be a problem because of masquerading ;)> Along my travels I ran into this: http://l7-filter.sourceforge.net/ > Have you played with L7 and can you rate it good/bad ?I''ve installed it and used it for 2 month, though I can''t say I''ve thoroughly tested the patterns. So far, it works out pretty good. The website has a page that lists supported protocols, and rates the quality of each pattern. I would not recommend it for production use, though. There can be side effects : if you visit a web page that describes the SMTP protocol, the packet will contain data that looks like SMTP, and who knows which pattern the packet is going to match...> The script you sent didn''t answer one question, how to match on IP so I > can > add a further level of htb to equally share bandwidth amongst computers.You can create a class for each client on the LAN link, and limit upload from your server to each client. If you want to limit upload from client to server, you can restrict bandwidth with ''ingress''.> I think I know how to do this though, filter by MAC. I don''t know if > iptables > at this point has munted the mac so I''m going to try that in a sec and see > if > I can get a match. >Iptables may give you more options to separate trafic to different classes by MARKing them. Then tc allocates bandwidth for each class. You''ll have much more flexibility this way. Sylvain
> Ok I thought you were trying to match src addresses, and that would be a > problem because of masquerading ;) >yep.> > Along my travels I ran into this: http://l7-filter.sourceforge.net/ > > Have you played with L7 and can you rate it good/bad ? > > I''ve installed it and used it for 2 month, though I can''t say I''ve > thoroughly tested the patterns. So far, it works out pretty good. The > website has a page that lists supported protocols, and rates the quality > of each pattern. I would not recommend it for production use, though. > There can be side effects : if you visit a web page that describes the > SMTP protocol, the packet will contain data that looks like SMTP, and who > knows which pattern the packet is going to match... >Interesting because in the L7 FAQ it says they take advantage of netfilters connection tracking capabilities to classify connections based on their first few packets and then classify packets based on what connection they are in. To my thinking this precludes what you say above, but I don''t know much about netfilters connection tracking. Have you seen the behaviour you describe ?> Iptables may give you more options to separate trafic to different classes > by MARKing them. > Then tc allocates bandwidth for each class. > You''ll have much more flexibility this way. >On this, can anyone help with: http://lartc.org/howto/lartc.adv-filter.html 12.1.3. Specific selectors The following table contains a list of all specific selectors the author of this section has found in the tc program source code. They simply make your life easier and increase readability of your filter''s configuration. FIXME: table placeholder - the table is in separate file ,,selector.html'''' FIXME: it''s also still in Polish :-( FIXME: must be sgml''ized I''m quite happy to read polish to get at the list they are offering.
On Jeu 12 mai 2005 12:42, Lee Sanders a écrit :> Interesting because in the L7 FAQ it says they take advantage of > netfilters > connection tracking capabilities to classify connections based on their > first > few packets and then classify packets based on what connection they are > in. > > To my thinking this precludes what you say above, but I don''t know much > about > netfilters connection tracking. Have you seen the behaviour you describe ? >I have not seem the problem occur. However, the webpage gives a warning and recommends not to use l7 matching to DROP packets. It should not be a problem if you only want to shape. Sylvain
Lee Sanders wrote:>>Ok I thought you were trying to match src addresses, and that would be a >>problem because of masquerading ;) >> > > yep. >So you need to use addresses before nat - just mark them in iptables postrouting like. iptables -t mangle -A POSTROUTING --src 192.168.0.2 -j MARK --set-mark 32 then filter them with tc something like - tc filter add dev $UPIF parent 1:0 prio 4 protocol ip handle 32 fw flowid 1:32> On this, can anyone help with: http://lartc.org/howto/lartc.adv-filter.html > > 12.1.3. Specific selectors > > The following table contains a list of all specific selectors the author of > this section has found in the tc program source code. They simply make your > life easier and increase readability of your filter''s configuration. > > FIXME: table placeholder - the table is in separate file ,,selector.html'''' > FIXME: it''s also still in Polish :-( > FIXME: must be sgml''ized > > I''m quite happy to read polish to get at the list they are offering.They may well be outdated now anyway - there is work going on currently with tc eg. ematches - just not many docs yet. Andy.
I worked out how to filter based on SRC IP, you can''t with tc. Using iptables PREROUTING you can but I wanted to avoid getting QOS into iptables. I also found you can filter on SRC/DST MAC address. Hmm same thing really so here is what you need to know: the u32 can be used to match any bit in the ip header. Before the ip header, there is a frame header. In that frame header you can find the src and dst mac address. You can trick the u32 filter in using the frame header if you use negative offsets. Decimal Offset Description -14: DST MAC, 6 bytes -8: SRC MAC, 6 bytes -2: Eth PROTO, 2 bytes, eg. ETH_P_IP 0: Protocol header (IP Header) Egress (match Dst MAC): ... match u16 0xPPPP 0xFFFF at -2 match u32 0xM2M3M4M5 0xFFFFFFFF at -12 match u16 0xM0M1 0xFFFF at -14 Ingress (match Src MAC): ... match u16 0xPPPP 0xFFFF at -2 match u16 0xM4M5 0xFFFF at -4 match u32 0xM0M1M2M3 0xFFFFFFFF at -8 Where PPPP is the Eth Proto Code (from linux/include/linux/if_ether.h): ETH_P_IP= IP = match u16 0x0800 So the below is what I came up with and it works. Simplistic I know. Now that I have the basics working I can build on it now with diferent QOS settings for different packet types (ie ack, ssh, bulk) though I may use L7 filtering using iptables for this. Hey using iptables after all this :\ tc qdisc add dev ppp0 root handle 1:0 htb default 20 tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 128kbit ceil 128kbit tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 64kbit ceil 128kbit tc qdisc add dev ppp0 parent 1:10 handle 100: sfq perturb 10 tc qdisc add dev ppp0 parent 1:20 handle 200: sfq perturb 10 # My Laptop tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0xFFFF at -2 match u16 0xM4M5 0xFFFF at -4 match u32 0xM0M1M2M3 0xFFFFFFFF at -8 flowid 1:10 # My Desktop tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 0xFFFF at -2 match u16 0xM4M5 0xFFFF at -4 match u32 0xM0M1M2M3 0xFFFFFFFF at -8 flowid 1:20 # change the MAC''s of course. tc -s -d class show dev ppp0 tc -s -d qdisc show dev ppp0 tc -s -d filter show dev ppp0 There you have it. :L ------------------------------------------------------------------------------> Hi All, > > I''ve been playing with QOS for a short while now and have worked out how to > do what I want using HTB. Great queuing discipline btw. > > My problem is the tc filters I want to setup aren''t working because > iptables is getting to the packets first and mangling the src address. > > The iptables script I am using is MonMotha''s Firewall 2.3.8 and it includes > lots of nice goodies like syn flood rate limiting. The extra bits like this > are why I''m using it rather than figuring the iptables configuration out > myself. > > My network configuration is trivial, adsl router connected to linux box > connected to two networks, LAN and WLAN. > > I like having these iptables features but MonMotha''s Firewall isn''t > designed with QOS in mind. > > My question for this list, is there a recommended iptables router script > that everyone here uses designed with QOS in mind or have you all written > your own ? > > Thanks in Advance > > Lee > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc-- _____________________________________________________ Lee Sanders Computer Systems Engineer Consultant Email: tagline@ccp.com.au Professionals Mobile: 0400481632 77 122 550 929