Step by Step How To - basic qshape

[c.davis]

I grabbed a copy of the GPL'd bandwidth arbitrator software today.. just to see what it was all about. In a nutshell, they provide a patch for the 2.6.5 linux kernel bridge code (their entire system relies on bridging to deal with packets between interfaces).. the rest is a set of perl scripts.

The biggest differences from their commercial offering compared to the free version (aside from the hardware itself) is a couple of nice things like a web front end and some rrd graphs.. the configuration is very well documented and in reality should be actually fairly trivial to setup and get going.

If you'd really like to have your own netequalizer-like system then my advice would be to save yourself a bunch of cash and roll-your-own.. if you and/or your staff aren't up to the task then you can still save a big fistfull by setting up a very basic linux box with a build enviroment and grabbing a 'coder for hire', for a less than a thousand bucks the coder-for-hire guy(s) could do a 2.6.5 kernel build and make a web front-end tailored to your needs rather than you and your staff having to learn what's provided.

Just my 0.02

[ninedd]

OK, so if I read these two rules correctly - they mark only those customers with more than 100 connections, and then shape those customers through their own rule - but only while they are over 100 connections, right? I was hoping not to have to code 1,000 rules for 1,000 customers - but if we need to, then we need to. Ideally, a server could see the IP's in active use and dynamically creates 'rules' for each IP. Of course, that's pretty much what NetEqualizer or Arbitrator does - it sees the traffic to each IP and dynamically decides who needs to be slowed, and then slows those hogs by adding a small amount of latency into that IP's connection.

Netequalizer does more than this by a long shot. Netequalizer is a packaged solution using the free Bandwidth Abitrator software. So if you are up to building your own high powered machine, and can do the config your self you should be able to do the same thing as Netequalizer for a fair bit less money.

Hi. I was more whining for commedic effect. Yes, we looked at Arbitrator option as well. Our Linux skills are limited and for obvious (and understandable) reasons, all our requests from the Bandwidth Arbitrator Open Source guys are answered with "You know, we make a product called NetEqualizer that sounds perfect for your knowledge level..." Very understandable from their standpoint - they don't want to spend the time & money to make a comercial turn-key version, and then help people circumvent their business. We're going to have another stab at it in the new year here, but I was hoping that we might be able to have our StarOS edge router help smooth things out for us. As I mentioned, we already CBQ at the AP, and we CBQ at the CPE - but we also want to do something at the edge that can better shape the whole network when it get's busy, since the distributed CBQing has a drawback in that each AP/CPE doesn't really know what the whole rest of the network is up to at that instant.

[ninedd]

...a 2.6.5 kernel build and make a web front-end tailored to your needs rather than you and your staff having to learn what's provided. Just my 0.02

Well, that's about 4c worth of advice I think! I do have a couple coders that I subcontract some website stuff to - they are PHP/MySQL guys, so I'll check on their Perl skills. That's been the way we've been leaning anyway, although it runs the risk of spending the money and having a 'sort of' working solution. But, that's probably the way for us to continue moving. Thanx.

[c.davis]

Well, that's about 4c worth of advice I think! I do have a couple coders that I subcontract some website stuff to - they are PHP/MySQL guys, so I'll check on their Perl skills. That's been the way we've been leaning anyway, although it runs the risk of spending the money and having a 'sort of' working solution. But, that's probably the way for us to continue moving. Thanx.

Here's your 3rd and 4th cent...
I'd leave those perl scripts alone unless you really know what you're doing and have a desire to delve right in there, they are very purpose driven and really need no modification.. in fact there are static calls in some of the bridge patches to those perl scripts.. hand off is the best policy. Your best best is to get those coders-for-hire guys to evaluate the config file and have them rewrite it (the config) as changes are made.. for reporting.. have them parse the output from the perl scripts to your liking and when you're in that comfy spot.. the world is your oyster.... send the results to a sql database and go buck-wild with it.

As a side note, be aware of the cost of some coders-for-hire.. make sure that you own the code when the job is done as there are some that we reselll code that has already been paid for unless instructed otherwise.

Ok, I spent 2 more cents than planned and I'm out of coins