Hi all, I''m new to using iproute2 for traffic shaping but not new to Linux. Essentially I have a WAN between two cities that I stream audio over for rebroadcast. Since it''s all done live stability and prioritization is critical in staying on air for our radio broadcasts. My WAN is 1.5Mbit PVC within my provider''s infrastructure so I have an unencrypted direct line via DSL to my remote site. My streaming devices use between 300 and 600kilobits/sec. with plenty of room for the workstations/servers at the remote site. Unfortunately as we all know, typical applications like web, mail, windows file sharing, etc are bursty and pigs for the bandwidth. This results in audio that''s choppy and drops off for seconds to minutes. I know there''s enough bandwidth to go around but I need limits set. I''ve created a bridge called edmbr on a Mandrake 10.1 server with 2 nics. The bridge works just great thanks to Don''s script from burnpc.com. The problem I''ve run into is in testing my filtering. After fixing the bugs in my first script I went to tweaking its settings. I''m using htb as it seems simpler for me to use at the moment. For some unknown reason to me all traffic is being sent to my default classid 1:11. In the script below my test workstation is the 10.2.1.251 address but all of my traffic goes to 1:11. I''m using "tc -s -d class show dev eth0" to monitor the traffic. Any ideas? Should I move to CBQ? I''m currently tweaking but this is what I have for now: ----------------------- #!/bin/sh DEV=eth0 #setup the root #tc qdisc add dev $DEV root handle 1: htb default 11 tc class add dev $DEV parent 1: classid 1:1 htb rate 100kbps ceil 100kbps #Tokyo class tc class add dev $DEV parent 1:1 classid 1:10 htb rate 50kbps ceil 100kbps #Everything else tc class add dev $DEV parent 1:1 classid 1:11 htb rate 50kbps ceil 100kbps #filter for streaming tc filter add dev $DEV parent 1:1 protocol ip prio 0 u32 match ip src 10.2.1.7 match ip dport 2001 0xffff flowid 1:10 tc filter add dev $DEV protocol ip parent 1:1 prio 0 u32 match ip src 10.2.1.5 match ip dport 2001 0xffff flowid 1:10 #filter for my workstation tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src 10.2.1.251 flowid 1:10 #all other traffic sent to the other queue tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src 0.0.0.0/0 flowid 1:11 tc qdisc add dev $DEV parent 1:10 handle 10: pfifo limit 2 tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 2 ------------------- -- Jason Bath Network Administrator CKUA Radio Network
Just a follow-up at this point. No matter what I do to tweak all traffic goes to the default queue even though I have tc filters in place. Any suggestions? Jason Bath Network Administrator CKUA Radio Network 780.428.2017 Jason Bath wrote:> Hi all, > > I''m new to using iproute2 for traffic shaping but not new to Linux. > Essentially I have a WAN between two cities that I stream audio over for > rebroadcast. Since it''s all done live stability and prioritization is > critical in staying on air for our radio broadcasts. > > My WAN is 1.5Mbit PVC within my provider''s infrastructure so I have an > unencrypted direct line via DSL to my remote site. My streaming devices > use between 300 and 600kilobits/sec. with plenty of room for the > workstations/servers at the remote site. Unfortunately as we all know, > typical applications like web, mail, windows file sharing, etc are > bursty and pigs for the bandwidth. This results in audio that''s choppy > and drops off for seconds to minutes. I know there''s enough bandwidth > to go around but I need limits set. > > I''ve created a bridge called edmbr on a Mandrake 10.1 server with 2 > nics. The bridge works just great thanks to Don''s script from > burnpc.com. The problem I''ve run into is in testing my filtering. After > fixing the bugs in my first script I went to tweaking its settings. > > I''m using htb as it seems simpler for me to use at the moment. For some > unknown reason to me all traffic is being sent to my default classid > 1:11. In the script below my test workstation is the 10.2.1.251 address > but all of my traffic goes to 1:11. I''m using "tc -s -d class show dev > eth0" to monitor the traffic. > > Any ideas? Should I move to CBQ? > > I''m currently tweaking but this is what I have for now: > ----------------------- > #!/bin/sh > > DEV=eth0 > #setup the root > > #tc qdisc add dev $DEV root handle 1: htb default 11 > tc class add dev $DEV parent 1: classid 1:1 htb rate 100kbps ceil 100kbps > #Tokyo class > tc class add dev $DEV parent 1:1 classid 1:10 htb rate 50kbps ceil 100kbps > #Everything else > tc class add dev $DEV parent 1:1 classid 1:11 htb rate 50kbps ceil 100kbps > > #filter for streaming > tc filter add dev $DEV parent 1:1 protocol ip prio 0 u32 match ip src > 10.2.1.7 match ip dport 2001 0xffff flowid 1:10 > tc filter add dev $DEV protocol ip parent 1:1 prio 0 u32 match ip src > 10.2.1.5 match ip dport 2001 0xffff flowid 1:10 > > #filter for my workstation > tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src > 10.2.1.251 flowid 1:10 > > #all other traffic sent to the other queue > tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src > 0.0.0.0/0 flowid 1:11 > > > tc qdisc add dev $DEV parent 1:10 handle 10: pfifo limit 2 > tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 2 > ------------------- > > > >
On Thursday 05 May 2005 18:26, Jason Bath wrote:> tc filter add dev $DEV parent 1:1 protocol ip prio 0 u32 match ip src > 10.2.1.7 match ip dport 2001 0xffff flowid 1:10You have to attach the filters to the QDisc (parent 1:). HTH Andreas
Jason Bath wrote:> I''m currently tweaking but this is what I have for now: > ----------------------- > #!/bin/sh > > DEV=eth0 > #setup the root > > #tc qdisc add dev $DEV root handle 1: htb default 11Remember arp traffic will go to default unless you filter elsewhere.> tc class add dev $DEV parent 1: classid 1:1 htb rate 100kbps ceil 100kbps > #Tokyo class > tc class add dev $DEV parent 1:1 classid 1:10 htb rate 50kbps ceil 100kbpsI would use rate 90 ceil 100 prio 0> #Everything else > tc class add dev $DEV parent 1:1 classid 1:11 htb rate 50kbps ceil 100kbpsrate 10 ceil 100 prio 1 quantum 1500 (or your mtu) burst 10b cburst 10b> > #filter for streaming > tc filter add dev $DEV parent 1:1 protocol ip prio 0 u32 match ip src > 10.2.1.7 match ip dport 2001 0xffff flowid 1:10Filters don''t work as you need to add them to 1:0 also prio 0 is not highest for a filter - use 1> tc filter add dev $DEV protocol ip parent 1:1 prio 0 u32 match ip src > 10.2.1.5 match ip dport 2001 0xffff flowid 1:10 > > #filter for my workstation > tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src > 10.2.1.251 flowid 1:10If your workstation generates bulk traffic don''t put it with stream - make another class.> > #all other traffic sent to the other queue > tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src > 0.0.0.0/0 flowid 1:11Not really needed if you use default 11 but remember arp - if you omit default 11 then leave this and arp will pass unshaped.> tc qdisc add dev $DEV parent 1:10 handle 10: pfifo limit 2two packets seems a bit low - maybe use a short bfifo to limit to a couple big packets (3k) but still allow more small.> tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 2perturb causes packet reordering 2 is too low use min 10 or higher. Andy.
Thanks! Adding the filter to the root was the trick. From the various documentation I was reading I had the impression that the filter needed to be added to the sub-classes - 1:1 and so forth. I presume that''s only appropriate when you have leaves below 1:1. Anyhow, the trick now is figuring out how I want to configure things with two of these bridges in mind. The topology would look like this: Switch-bridge/filter-WAN router--Remote WAN router-bridge-remote switch Now with 1.5Mbit/s with the potential for 2mbit/s I was thinking of limiting each bridge at 1Mbit/s. I didn''t want to limit at 750kbit/s because if you''re doing a big file transfer, you''re going to suffer and besides, the ratio of download to upload is in favour of the download The streaming audio devices are set up for 128kbit/s MPEG-layer3. So we''re looking at dedicating a minimum of 150kbit/s which can double or more if I''m having congestion problems. Now here''s an interesting idea. Let me know if it''s possible or not. Is it possible for me to create a bridge between the two linux boxes so it physically looks like eth0 eth1 --WAN-- eth1 eth0 but virtually you are going eth0 ------- eth0 The reason I ask this is so I can create an awareness between the two bridges as to how much traffic is actually going through the pipe so I may optimize it to its fullest. I suppose that it could be done via snmp or spanning-tree? Thanks again. Jason Bath Network Administrator CKUA Radio Network 780.428.2017 Andy Furniss wrote:> Jason Bath wrote: > >> I''m currently tweaking but this is what I have for now: >> ----------------------- >> #!/bin/sh >> >> DEV=eth0 >> #setup the root >> >> #tc qdisc add dev $DEV root handle 1: htb default 11 > > > Remember arp traffic will go to default unless you filter elsewhere. > >> tc class add dev $DEV parent 1: classid 1:1 htb rate 100kbps ceil 100kbps >> #Tokyo class >> tc class add dev $DEV parent 1:1 classid 1:10 htb rate 50kbps ceil >> 100kbps > > > I would use rate 90 ceil 100 prio 0 > >> #Everything else >> tc class add dev $DEV parent 1:1 classid 1:11 htb rate 50kbps ceil >> 100kbps > > > rate 10 ceil 100 prio 1 quantum 1500 (or your mtu) burst 10b cburst 10b > >> >> #filter for streaming >> tc filter add dev $DEV parent 1:1 protocol ip prio 0 u32 match ip src >> 10.2.1.7 match ip dport 2001 0xffff flowid 1:10 > > > Filters don''t work as you need to add them to 1:0 also prio 0 is not > highest for a filter - use 1 > >> tc filter add dev $DEV protocol ip parent 1:1 prio 0 u32 match ip src >> 10.2.1.5 match ip dport 2001 0xffff flowid 1:10 >> >> #filter for my workstation >> tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src >> 10.2.1.251 flowid 1:10 > > > If your workstation generates bulk traffic don''t put it with stream - > make another class. > >> >> #all other traffic sent to the other queue >> tc filter add dev $DEV protocol ip parent 1:1 prio 3 u32 match ip src >> 0.0.0.0/0 flowid 1:11 > > > Not really needed if you use default 11 but remember arp - if you omit > default 11 then leave this and arp will pass unshaped. > > >> tc qdisc add dev $DEV parent 1:10 handle 10: pfifo limit 2 > > > two packets seems a bit low - maybe use a short bfifo to limit to a > couple big packets (3k) but still allow more small. > >> tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 2 > > > perturb causes packet reordering 2 is too low use min 10 or higher. > > Andy.
Jason Bath wrote:> Thanks! Adding the filter to the root was the trick. From the various > documentation I was reading I had the impression that the filter needed > to be added to the sub-classes - 1:1 and so forth. I presume that''s > only appropriate when you have leaves below 1:1. > > Anyhow, the trick now is figuring out how I want to configure things > with two of these bridges in mind. The topology would look like this: > > Switch-bridge/filter-WAN router--Remote WAN router-bridge-remote switch > > Now with 1.5Mbit/s with the potential for 2mbit/s I was thinking of > limiting each bridge at 1Mbit/s. I didn''t want to limit at 750kbit/s > because if you''re doing a big file transfer, you''re going to suffer and > besides, the ratio of download to upload is in favour of the download > The streaming audio devices are set up for 128kbit/s MPEG-layer3. So > we''re looking at dedicating a minimum of 150kbit/s which can double or > more if I''m having congestion problems. > > Now here''s an interesting idea. Let me know if it''s possible or not. Is > it possible for me to create a bridge between the two linux boxes so it > physically looks like > > eth0 eth1 --WAN-- eth1 eth0 > > but virtually you are going > > eth0 ------- eth0 > > The reason I ask this is so I can create an awareness between the two > bridges as to how much traffic is actually going through the pipe so I > may optimize it to its fullest. > > I suppose that it could be done via snmp or spanning-tree?I don''t know if that will work - if you can shape on both ends just do egress shaping on the WAN facing interfaces. You''ll need to back off a bit to allow for link overheads, but it will be alot nicer than doing it all from one end. Andy.