From: Michael Snyder (msnyder@revolutioncomputer.com)
Date: Wed Apr 23 2003 - 14:35:55 GMT-3
I got a problem that Im not sure how to solve.
Im working with a small Broadband WISP. We have two T1s coming in,
going to a /24 network. Each user of the ISP gets one public ip of the
/24. Most have private networks behind their public ip.
My problem is that any one of the host ips can tie up the full
bandwidth of our outgoing pipes. I truly understand how this is a very
common problem with ISPs. Of our 60 present users, only 4 or 5 of them
are the bandwidth hogging trouble makers at any one time.
I do have CIR limiting options at the radio modems for the client sites,
but because of design limitations I rather not use them. The reason is
that one of the services we offer is site to site vpn and ip transit
between local sites. If I enable the cir limiting at the access point
level, it applies to all radio modem users that connect to that main
radio access point; which could be 20 or 30 people.
In a nut shell, I rather not limit local traffic, just remote traffic.
I have looked at some of unix based bandwidth limiting solutions, and
believe I could get one running if I needed.
Ok, so the goal is to bandwidth limit remote traffic and to leave local
traffic at full speed.
My tool of choice is an 3550. I have one on order to replace one of
3524s were using now.
The issues I see is per host vs aggregate subnet limiting.
In other words just how granular can I get and still have a stable
configuration?
In the best of all worlds, I wish could set each host to have 768K down
and 384K up using something like car.
My second thought is to divide the /24 into 16 /28 sections for car
purposes and use 16 car statements.
Of course if I want to go with the application limiting path, I could
use cbwfq or nbar based solutions.
Im asking for advice how you would handle bandwidth limiting using an
3550 on a per user or group of users basis.
Thanks in advance,
Michael Snyder
This archive was generated by hypermail 2.1.4 : Thu May 01 2003 - 13:36:03 GMT-3