Hi Andy, The situation is this: there are a total of four companies represented in our building. We've all been looking at upgrading our Internet connections from ADSL, and as we're all owned by the same parent company it made sense to buy our bandwidth "in bulk". As such we're hoping to get a 4Mb/4Mb pipe of some description. One of the drivers for going ahead with this is the fact that one of the companies wants to start using some reasonably funky video conferencing equipment. The four companies are not paying the same amount each for the connection. Each company has agreed to pay an amount that represents their expected usage of the system. To keep things fair, we would like to shape the traffic on the link to reflect the amounts people are paying. Also, the video conferencing equipment (as it will be available to all the companies in the building) will need a guaranteed chunk of bandwidth itself. We've looked at getting our ISP to provide the traffic shaping, but they want to charge a large setup fee and quite a bit of money per quarter to 'maintain' it (to leave the settings alone, in other words). I'm looking at using a spare box we have here as a means of shaping our outgoing traffic as an alternative. The idea is that downstream traffic will still be better off than with a 20:1 contended ADSL. The traffic will be split by IP, so the latest incarnation of the rules I have are: SQ="tc qdisc add dev eth0" SC="tc class add dev eth0" SF="tc filter add dev eth0" tc qdisc del dev eth0 root $SQ root handle 1:0 htb $SC parent 1:0 classid 1:1 htb rate 4mbit $SC parent 1:1 classid 1:2 htb rate <rate>kbit ceil 4mbit $SC parent 1:1 classid 1:3 htb rate <rate>kbit ceil 4mbit $SC parent 1:1 classid 1:4 htb rate <rate>kbit ceil 4mbit $SC parent 1:1 classid 1:5 htb rate <rate>kbit ceil 4mbit $SC parent 1:1 classid 1:6 htb rate <rate>kbit ceil 4mbit $SQ parent 1:2 handle 120: pfifo limit 50 $SQ parent 1:3 handle 130: pfifo limit 50 $SQ parent 1:4 handle 140: pfifo limit 50 $SQ parent 1:5 handle 150: pfifo limit 50 $SQ parent 1:6 handle 160: pfifo limit 50 $SF parent 1:0 protocol ip prio 1 u32 match ip src 1.1.1.5/32 flowid 1:6 $SF parent 1:0 protocol ip prio 2 u32 match ip src 1.1.1.1/32 flowid 1:2 $SF parent 1:0 protocol ip prio 3 u32 match ip src 1.1.1.2/32 flowid 1:3 $SF parent 1:0 protocol ip prio 4 u32 match ip src 1.1.1.3/32 flowid 1:4 $SF parent 1:0 protocol ip prio 5 u32 match ip src 1.1.1.4/32 flowid 1:5 It's just a very simple 5-child HTB with pfifo queues. I might split things down more later, but this should get things going. It's just a pity that the ISP want to charge stupid amounts of money for the shaping. Many thanks, Mark Lidstone IT and Network Support Administrator BMT SeaTech Ltd Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton. SO14 3TJ. UK Tel: +44 (0)23 8063 5122 Fax: +44 (0)23 8063 5144 E-Mail: mailto:mark.lidstone@xxxxxxxxxxxxxxxx Website: www.bmtseatech.co.uk ======================================================================== == Confidentiality Notice and Disclaimer: The contents of this e-mail and any attachments are intended only for the use of the e-mail addressee(s) shown. If you are not that person, or one of those persons, you are not allowed to take any action based upon it or to copy it, forward, distribute or disclose the contents of it and you should please delete it from your system. BMT SeaTech Limited does not accept liability for any errors or omissions in the context of this e-mail or its attachments which arise as a result of Internet transmission, nor accept liability for statements which are those of the author and not clearly made on behalf of BMT SeaTech Limited. ======================================================================== == -----Original Message----- From: Andy Furniss [mailto:andy.furniss@xxxxxxxxxxxxx] Sent: 14 November 2005 22:36 To: Mark Lidstone Cc: lartc@xxxxxxxxxxxxxxx Subject: Re: Pfifo_fast "Unknown qdisc" and asking for basic design advice Mark Lidstone wrote: > Hi Andy, > > Many thanks for the reply. > > Is there a reason why the user is not supposed to use pfifo_fast? I > don't think I need a full-on PRIO (surely pfifo_fast is more efficient > if it is classless?). Sorry for asking, but I didn't come across this > limitation in the documentation. Not sure really. > > Following your suggestions, I've come up with the following: > > #!/bin/sh > SQ="tc qdisc add dev eth0" > SC="tc class add dev eth0" > SF="tc filter add dev eth0" > > tc qdisc del dev eth0 root > $SQ root handle 1:0 htb > $SC parent 1:0 classid 1:1 htb rate 4096kbit > $SC parent 1:1 classid 1:2 htb prio 0 rate 768kbit #Video > Conferencing > $SC parent 1:1 classid 1:3 htb prio 1 rate 1545kbit #Company 1 > $SC parent 1:1 classid 1:4 htb prio 1 rate 832kbit #Company 2 > $SC parent 1:1 classid 1:5 htb prio 1 rate 713kbit #Company 3 > $SC parent 1:1 classid 1:6 htb prio 1 rate 238kbit #Company 4 > $SQ parent 1:2 handle 5:0 prio #Video Conferencing > $SQ parent 1:3 handle 6:0 prio #Company 1 > $SQ parent 1:4 handle 7:0 prio #Company 2 > $SQ parent 1:5 handle 8:0 prio #Company 3 > $SQ parent 1:6 handle 9:0 prio #Company 4 > > $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.4/32 flowid > 5:0 > $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.5/32 flowid > 6:0 > $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.6/32 flowid > 7:0 > $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.7/32 flowid > 8:0 > $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.8/32 flowid > 9:0 > > (I've a horrible feeling there's something obviously and fundamentally > wrong with this) > > What happens with any traffic not from these IPs? You can use a catch all filter after the others ... u32 match u32 0 0 .. Unlike htb prio 1 is the top prio for filters. Without knowing what your setup is it's hard to say what's the best way in detail eg. where and what bandwidth are the bottleneck links and which end of them you are shaping. Andy. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
