ClearFoundation

This webconfig app will let you get under the skin of the bandwidth rules created by ClearOS. Ever wanted to check whether the rules you have in place are effective? matching the intended traffic, and are prioritising / capping traffic? well now you can. This app was inspired by the TCCS (tc class statistics parser)

Info
The bandwidth system consists of two intermediate queueing devices (imq) that sit between the ClearOS box and the internet. These devices filter upload and download traffic and prioritise according to the defined rules. The app will display each of the rules on each interface, whether packets are being dropped, over the limits, or creating a backlog. It will also show which classes are consistently borrowing traffic from others.

Bandwidth is distributed between all the classes according to their rate, and their priority. When a class needs more traffic than it's rate it will attempt to borrow more from the parent class. The priority in which traffic is borrowed and shared is based on the priority of the class. Each class can borrow more traffic up to the ceiling limit. You can artificially limit traffic by setting the ceiling limit lower than your upload.

The top table will list all rules which have seen traffic since the firewall was restarted. It's essentially a static snapshot - refresh the page to see updates....(todo: use AJAX to update the table)

Install
To install simply setup the community repo with instructions here HERE

Navigate to Gateway > Bandwidth and QOS > Bandwidth Monitor

What this app doesn't do....record bandwidth usage or log bandwidth totals, sorry!

Lessons learnt- all other traffic not specified by your bandwidth rules end up in the standard 1:2 class. This is hard coded to have a low priority and 1/8th of your upload. It maybe obvious but to maintain maximum throughput and interactivity you should create rules for all traffic that rely on packets being passed in a timely manner. Namely SSH (port 22), DNS (port 53), VOIP, Gaming UDP ports. Everything else can be left as bulk traffic. Or if you wish to limit P2P create a rule for that but limit the Ceiling slightly lower than your upload.

For all things bandwidth related see this excellent guide
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

Tricks!
since i've been learning a lot about how the bandwidth system goes together, there are a couple of tweaks which originate from the wondershaper scripts that you can apply to the bandwidth system here:-

Prioritise small ACK and ICMP packets. Run the following from the console:-


Note both rules only apply to packets <64bytes, as ACK and ICMP can have some payload which we don't want to prioritise. To show off to your friends once these are in place you should try and max out your upload whilst demonstrating a very low ping!

This application doesn't do anything amazingly special, but if you want to understand a bit more about how your bandwidth rules are implemented I find it useful

p.s. add the commands above to /etc/rc.d/rc.firewall.local if you want to make them permanent

If you mess it up simply run 'service firewall restart' to wipe your changes

How do i go about uninstalling this tim. I think it maybe making a minor issue for me with changing my mac. Posted in another thread here located at www.clearfoundation.com/component/option.../func,view/id,15127/

Hi Alton - thanks for trying it out! you can remove it by running


I should note that this app doesn't actually modify any configuration files, it merely displays the existing config, and the associated traffic as represented by the 'tc -s' command, so it'a unlikely to have caused your MAC address issues

UPDATE: Uploaded 5.1-2 which now includes an automatic refresh page refresh option

UPDATE: Uploaded 5.1-3 which includes a small bug fix. For fast traffic the download (IMQ1) speeds were incorrectly displayed as KBits/1000 instead of KBits

Just quick Thanks Tim - this installed perfectly. Still getting my head around the output but looks good. I used to mess around with wondershaper scripts to prioritise my voip so its not totally foreign.

Hi grubs, thanks for trying it out

I guess I should post some more info on what each of the fields represent for those that are not familiar with bandwidth shaping

ClearOS uses virtual intermediate queing devices to apply traffic shaping rules too. All incoming (or 'download') traffic from the WAN is passed through IMQ1, all outgoing (or 'upload') traffic from the WAN is passed through IMQ0. These rules are created in the mangle table of iptables.

On each of these 'virtual devices' bandwith rules are applied to prioritise or shape traffic as it passes through. It is important that your upload or download speeds defined in the webconfig are kept *below* your actual throughput to ensure that queues of traffic do not get stuck in your modem and are controlled by the queuing devices. (approx 90% of your actual bandwdith works well for me and I have relatively stable up/down speeds). I should emphasise here that bandwidth management is not about getting faster uploads out of your connection, it's about ensuring that traffic is shared among all services so that none can use it at the expense of the others, with a preference to some of those services.

So on each IMQ device, there are several classes of 'qdiscs' which are used to lump traffic into based on your webconfig rules. The clearos bandwdith rules create filters - one for each class so that traffic is matched and placed into one of these classes. These are arranged in a tree like heirachy, so you can have more than one 'tier' of bandwidth classes - however ClearOS uses one.

Class 1:1 is the root or parent class, i.e. the top of the tree - and has your ceiling limits applied to it. Class 1:2 is a special class for all other traffic that doesn't match your other rules. User defined bandwdith rules start at 1:10, 1:11, 1:12 etc. All of these classes are children of the parent 1:1 class.

This heirachical behaviour is important as when a class needs more traffic than it's specified rate, it will ask the parent to borrow more. The parent class will then lend some traffic from the other classes which are not in use. A class can borrow more traffic up to it's specified limit - which is the ceiling rate. The ceiling rate maybe the same as the parent or at some lower value if you have chosen to cap this class to a slower value. When several classes need to borrow more traffic - the parent class will apportion it between them based on their priorities as set in the webconfig. higher priorities getting traffic before other classes.

So a class which consistently borrows more packets (as shown in the list) is consistently requiring more traffic than it's specified rate.
A class which is consistently lending packets is not using as much as it's specified rate.

Overlimits, shows how many times a class was asked to send a packet but he can't due to rate/ceil constraints (currently counted for leaves only).
Rate, tells you actual (10 sec averaged) rate going through the class.
Lended, is # of packets donated by this class (from its rate) and Borrowed are packets borrowed from parent class.

Backlog of packets can occur when your connection is saturated by other classes or your upload (actual) speed has lowered below your ceiling rate. Backlogs of packets are not good and should be investigated

There are several other parts to it which are hard coded into the webconfig - such as burst levels. These control how much data a class can temporarily send quickly or in a 'burst' over and above the rate or it's ceiling rate. HTTP is an example of very bursty type of traffic

Some practical guidlines on creating rules then:-

Define bandwidth rules for all traffic that you consider to be essential to your server. For example on my cable line with a limited upload I have DNS, SSH, SMTP, Web uploads, FTP and my PS3 all set to high priority with a small rate so that they can always pass traffic and more importantly keep the latency down. I then have torrents set to a lower ceiling value (i.e. rate capped) and use transmission which only uses one port for it's transfers. All remaining traffic is then left in class 1:2 and dealt with on a round robin scnario based on it's QOS fields.

So on a well configured connection - when your upload is 'maxed out' you should still be able to run all these services, and still be able to browse the web, use SSH connections, have quick and responsive DNS and host other bulk transfer traffic. The same principles apply to VOIP which also requires low latency conenctions.

Hope that helps

For more details see many of the guides on the web....
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm

Update 5.1-4 now available, which removes the bottom table and now shows the source / IP with the rules above. From a technical point of view this is a much better solution as it now reads the exact filter rules from the IMQ rather than trying to second guess them from the /etc/firewall rules.