I''m successfully using HTB + GRED to shape traffic based on the DSCP field. I would like to strip the DSCP and possibly replace it with normal ToS bits on egress traffic leaving my network. Leaving DSCP set is pointless, and could potentially cause problems with some ISPs that use DSCP internally I suppose. Setting ToS bits would seem ideal as most networks still honor it to varying degrees. The problem is I can see no way of doing this. Since DSCP is needed in the qdiscs for shaping, it can''t be mangled with iptables. According to the packet flow diagram, there doesn''t appear to be any other opportunity to mangle the packets in this manor. Will I need to insert another router in the chain just to do this? :( -- Dan- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tue, 15 Feb 2005, Dan Cox wrote:> I''m successfully using HTB + GRED to shape traffic based on the DSCP field. I > would like to strip the DSCP and possibly replace it with normal ToS bits on > egress traffic leaving my network. Leaving DSCP set is pointless, and could > potentially cause problems with some ISPs that use DSCP internally I suppose. > Setting ToS bits would seem ideal as most networks still honor it to varying > degrees. > > The problem is I can see no way of doing this. Since DSCP is needed in the > qdiscs for shaping, it can''t be mangled with iptables. According to the packet > flow diagram, there doesn''t appear to be any other opportunity to mangle the > packets in this manor. Will I need to insert another router in the chain just > to do this? :(You can clone the GRED qdisc code and modify it to overwrite the DSCP bits.> > -- > Dan- > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >--- Catalin(ux aka Dino) BOIE catab at deuroconsult.ro http://kernel.umbrella.ro/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
You can try with IMQ, which probably is not wanted for a production server. You can also mark the pachets which have some DSCP bits, then use u32 with the mark match (Probably Catalin''s implementation), i think it is even in some latest 2.6 kernels, also don''t forget to use a new iproute2 :) On Wed, 16 Feb 2005 11:12:46 +0200 (EET), Catalin(ux aka Dino) BOIE <util@deuroconsult.ro> wrote:> On Tue, 15 Feb 2005, Dan Cox wrote: > > > I''m successfully using HTB + GRED to shape traffic based on the DSCP field. I > > would like to strip the DSCP and possibly replace it with normal ToS bits on > > egress traffic leaving my network. Leaving DSCP set is pointless, and could > > potentially cause problems with some ISPs that use DSCP internally I suppose. > > Setting ToS bits would seem ideal as most networks still honor it to varying > > degrees. > > > > The problem is I can see no way of doing this. Since DSCP is needed in the > > qdiscs for shaping, it can''t be mangled with iptables. According to the packet > > flow diagram, there doesn''t appear to be any other opportunity to mangle the > > packets in this manor. Will I need to insert another router in the chain just > > to do this? :( > > You can clone the GRED qdisc code and modify it to overwrite the DSCP > bits. > > > > > -- > > Dan- > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > > > --- > Catalin(ux aka Dino) BOIE > catab at deuroconsult.ro > http://kernel.umbrella.ro/ > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >-- Bla bla _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I thought I could use IMQ, but it appears the packets entering the IMQ device happen last, just like normal device qdiscs. Meaning, you can''t send packets to IMQ, then return to iptables for more mangling :/ Also, can''t use MARK because I''m already using it for traffic prioritization across 32 levels, and CLASSIFY is no good for this since it only works on a leaf class. I know I can sort traffic with filters, but I don''t think it''s possible to do any packet matching and mangling with them? I may have to just modify the source code :/ Dan- Quoting George Alexandru Dragoi <waruiinu@gmail.com>:> You can try with IMQ, which probably is not wanted for a production > server. You can also mark the pachets which have some DSCP bits, then > use u32 with the mark match (Probably Catalin''s implementation), i > think it is even in some latest 2.6 kernels, also don''t forget to use > a new iproute2 :) > > > On Wed, 16 Feb 2005 11:12:46 +0200 (EET), Catalin(ux aka Dino) BOIE > <util@deuroconsult.ro> wrote: >> On Tue, 15 Feb 2005, Dan Cox wrote: >> >> > I''m successfully using HTB + GRED to shape traffic based on the >> DSCP field. I >> > would like to strip the DSCP and possibly replace it with normal >> ToS bits on >> > egress traffic leaving my network. Leaving DSCP set is pointless, >> and could >> > potentially cause problems with some ISPs that use DSCP internally >> I suppose. >> > Setting ToS bits would seem ideal as most networks still honor it >> to varying >> > degrees. >> > >> > The problem is I can see no way of doing this. Since DSCP is needed in the >> > qdiscs for shaping, it can''t be mangled with iptables. According >> to the packet >> > flow diagram, there doesn''t appear to be any other opportunity to >> mangle the >> > packets in this manor. Will I need to insert another router in the >> chain just >> > to do this? :( >> >> You can clone the GRED qdisc code and modify it to overwrite the DSCP >> bits. >> >> > >> > -- >> > Dan- >> > _______________________________________________ >> > LARTC mailing list / LARTC@mailman.ds9a.nl >> > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> > >> >> --- >> Catalin(ux aka Dino) BOIE >> catab at deuroconsult.ro >> http://kernel.umbrella.ro/ >> _______________________________________________ >> LARTC mailing list / LARTC@mailman.ds9a.nl >> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >> > > > -- > Bla bla >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tue, 15 Feb 2005, Dan Cox wrote:>> I''m successfully using HTB + GRED to shape traffic based on the DSCP field. >I am investigationg WHY HTB + GRED does not work on my test beds. In SuSe 9.1 , 9.2 and Debian testing with 2.6.8 and 2.4.27 i face LOTS of problems (actually GRED works partially). Can you sent me your scripts and mention the version''s of the kernel and iproute2 you are currently using? Thanks in advance for your time, Antonios Chalkiopoylos My only working configuration is vanilla kernel 2.4.20 (patched with HTB) _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I would post my scripts but they''re around several thousand lines,
intertwined
with lots of variable substitution and generate about 300 qdiscs and
classes so
I don''t think it would be easy to follow :)
I''m using stock Fedora Core 3 packages for kernel (2.6.10), iptables
and
iproute2 (2.6.9) with the QNET patchset applied
(http://kem.p.lodz.pl/~peter/qnet/). I''ve also done this under Gentoo
with the
same stock kernels, packages and patches.
Basically, I sort traffic into several different HTB classes based on
protocol,
then I have 4 levels of priority subclasses under each protocol, with yet
another 4 levels of subpriorities under those. IPTables helps here by MARKing
the packets so I know which priority subclass to sort them into. Then I use an
HTB + diffserv combo on these leaf priority subclasses to apply GRED for
AF1-AF4 and apply RED for BE (not using EF yet).
Here is an organizational snippet with 1 protocol priority level:
|root DSMARK qdisc
|root DSMARK bit mask filters
|HTB main qdisc
|HTB main class
|HTB main filters (sort based on protocol into subs)
|HTB UDP Protocol Subclass
|HTB UDP Protocol Subclass filters (sort based on MARK value into subs)
|HTB UDP Priority 1 Subclass
|HTB UDP Priority 1 filters (apply DSMARK bit mask for sorting into subs)
|HTB AF1 Class
|GRED qdisc
|HTB AF2 Class
|GRED qdisc
|HTB AF3 Class
|GRED qdisc
|HTB AF4 Class
|GRED qdisc
|HTB BE Class
|RED qdisc
There''s a great site with lots of examples and info:
http://www.opalsoft.net/qos/DS.htm
Hope that helps-
Dan-
Quoting Antonios Halkiopoulos <alg0@iit.demokritos.gr>:
> On Tue, 15 Feb 2005, Dan Cox wrote:
>
>
>>> I''m successfully using HTB + GRED to shape traffic based
on the DSCP field.
>>
>
> I am investigationg WHY HTB + GRED does not work on my test beds. In
> SuSe 9.1 , 9.2 and Debian testing with 2.6.8 and 2.4.27 i face LOTS
> of problems (actually GRED works partially).
>
> Can you sent me your scripts and mention the version''s of the
kernel
> and iproute2 you are currently using?
>
> Thanks in advance for your time,
> Antonios Chalkiopoylos
>
> My only working configuration is vanilla kernel 2.4.20 (patched with HTB)
>
-- Dan-
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Dan Cox wrote:> I would post my scripts but they''re around several thousand lines, > intertwined > with lots of variable substitution and generate about 300 qdiscs and > classes so > I don''t think it would be easy to follow :)I am still interested, just post them to my personal email only so that you won''t flood lartc list.> I''m using stock Fedora Core 3 packages for kernel (2.6.10), iptables and > iproute2 (2.6.9) with the QNET patchset applied > (http://kem.p.lodz.pl/~peter/qnet/). I''ve also done this under Gentoo > with the same stock kernels, packages and patches.I will check as soon as possible> |HTB AF1 Class > |GRED qdisc > |HTB AF2 Class > |GRED qdisc > |HTB AF3 Class > |GRED qdisc > |HTB AF4 Class > |GRED qdisc > |HTB BE Class > |RED qdiscThis is the part i am most interested in. I guess GRED for AF1 (for example) takes care of AF11 , AF12, AF13 and AF14. If so please sent me your scripts. I will generate UDP traffic with mgen to test the kernels i am currently using. Thanks for your time, Antonios Chalkiopoulos _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
I''ve attached my diffserv automagic generator script because I think it''s pretty useful. Any feedback appreciated. After sourcing this into your scripts you basically feed it the following information to have it auto generate the needed classes and qdiscs based on formulas I''ve found on the net. This should be called to attach itself to a leaf class when you are already done sorting traffic into generic priority queues, etc. Note that I''ve ripped this out of a much larger script, but it should work as is. Here''s an example of the arguments the ''diffserv'' function takes: # ----------------------------------------------- # PARENT: Parent Class ID # DEV: Target Device # RATE: Parent Rate (kbit) # CEIL: Parent Ceiling (kbit) # AVPKT: Average Packet Size (bytes) # LATENCY: Target Latency (milliseconds) # QUANTUM: Device MTU (normally) (bytes) # MTU: Maximum Transmission Unit (bytes) # MPU: Minimum Packet Unit (bytes) # OVERHEAD: Packet Overhead (bytes) # ----------------------------------------------- The most common problem someone will run into with this script is not being able to guarantee a low enough latency. It takes a certain amount of bandwidth (rate) to guarantee a target latency based on the average packet size (of course!). Dan - Quoting Antonios Halkiopoulos <alg0@iit.demokritos.gr>:> Dan Cox wrote: > >> I would post my scripts but they''re around several thousand lines, >> intertwined >> with lots of variable substitution and generate about 300 qdiscs and >> classes so >> I don''t think it would be easy to follow :) > > I am still interested, just post them to my personal email only so > that you won''t flood lartc list. > >> I''m using stock Fedora Core 3 packages for kernel (2.6.10), iptables and >> iproute2 (2.6.9) with the QNET patchset applied >> (http://kem.p.lodz.pl/~peter/qnet/). I''ve also done this under >> Gentoo with the same stock kernels, packages and patches. > > I will check as soon as possible > > >> |HTB AF1 Class >> |GRED qdisc >> |HTB AF2 Class >> |GRED qdisc >> |HTB AF3 Class >> |GRED qdisc >> |HTB AF4 Class >> |GRED qdisc >> |HTB BE Class >> |RED qdisc > > > This is the part i am most interested in. I guess GRED for AF1 (for > example) takes care of AF11 , AF12, AF13 and AF14. If so please sent > me your scripts. > > I will generate UDP traffic with mgen to test the kernels i am > currently using. > > Thanks for your time, > Antonios Chalkiopoulos >-- Dan-
I''ve added a few more helper functions for a more complete demonstration. I''ve also added some suggested default values (see script). Here''s an example usage for a 100mbit LAN: # Load the functions into the environment # source diffserv.sh # # Set device queue length and MTU # init_device eth1 10 1500 # # Clear the device qdiscs # reset_qdisc eth1 # # Create the root DSMARK qdisc & filters. # init_classifier eth1 10: # # Now create our main HTB qdisc # We attach to the parent DSMARK qdisc (10:) and give ourselves a handle of 1: # qdisc eth1 "parent 10: handle 1: htb default 1 r2q 1" # # Now we create our leaf HTB + GRED classes and qdiscs to perform diffserv # Note that this will create HTB classes underneath the HTB qdisc (1:) # diffserv 1: eth1 100000 100000 1000 10 1500 1500 64 0 In a more complex setup, you can insert additional levels of HTB classes under the HTB qdisc and then call ''diffserv'' on those leaf classes, but remember to add additional filters (can NOT use iptables CLASSIFY target) or traffic will never reach those classes. ''diffserv'' assumes traffic has already made it as far as its parent qdisc (or class) and attaches it''s filters there. Dan-
I was just looking at your QoS Script. Did you ever notice that no packets will be put into gred dp3 ? I was using a similar script based on AF examples on the web and apparently in the gred qdisc now when you declare 3 dps they are numbered 0,1,2 and not 1,2,3. This line in gred_enqueue in sch_gred.c will prevent packets that you have given a tcindex of 113,123,133,143 of being put in the right dp. They will get put into the default dp. if ( ((skb->tc_index&0xf) > (t->DPs -1)) || !(q=t->tab[skb->tc_index&0xf])) {This isnt a bug in the code either as I found out. You could take the -1 out of this line or else use gred DP0 , DP1, DP2 and change your tcindex classifiers to 110,111,112 Jonathan On Fri, 2005-02-18 at 11:25 -0600, Dan Cox wrote:> I''ve added a few more helper functions for a more complete demonstration. I''ve > also added some suggested default values (see script). > Here''s an example usage for a 100mbit LAN: > > # Load the functions into the environment > # > source diffserv.sh > # > # Set device queue length and MTU > # > init_device eth1 10 1500 > # > # Clear the device qdiscs > # > reset_qdisc eth1 > # > # Create the root DSMARK qdisc & filters. > # > init_classifier eth1 10: > # > # Now create our main HTB qdisc > # We attach to the parent DSMARK qdisc (10:) and give ourselves a handle of 1: > # > qdisc eth1 "parent 10: handle 1: htb default 1 r2q 1" > # > # Now we create our leaf HTB + GRED classes and qdiscs to perform diffserv > # Note that this will create HTB classes underneath the HTB qdisc (1:) > # > diffserv 1: eth1 100000 100000 1000 10 1500 1500 64 0 > > In a more complex setup, you can insert additional levels of HTB classes under > the HTB qdisc and then call ''diffserv'' on those leaf classes, but remember to > add additional filters (can NOT use iptables CLASSIFY target) or traffic will > never reach those classes. ''diffserv'' assumes traffic has already made > it as far > as its parent qdisc (or class) and attaches it''s filters there. > > Dan- >