[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re : RE: Router with bandwidth management
I haven't heard anyone mention the really simple, effective way of doing this imho:
FreeBSD + DUMMYNET + ipfw
really cheap. A box, configured as a bridge with two network cards and dummynet and voila you keep your costs as low as $500
----------
Noah
--------------------------------------------------------------------------
2003 May 18 - 12:00
Mark Tinka <mtinka at africaonline.co.ug>
--------------------------------------------------------------------------
>Brian, you can do full queueing, prioritisation and compression on Cisco
>routers. The only restriction and limitation I would have with this is =
>it's
>not the most effective way to manage bandwidth and traffic, and is =
>typically
>recommended for use on [WAN] interfaces that support less than 2Mbps, to
>solve TEMPORARY congestion problems.
>
>The best thing to do would be to simply upgrade your bandwidth to
>accommodate your growth, but just to give you some ways Cisco can shape
>traffic:
>
>The 4 main culprits are:
>
>1. FIFO - First In First Out
>2. WFQ - Weighted Fair Queueing
>3. Priority Queueing
>4. Custom Queueing
>
>1. FIFO - is the most basic and straight forward. Packets are sorted and
>processed based on the time they came in. The first packet that came in =
>will
>be the first to leave.
>
>2. WFQ - allows more interactive traffic such as Telnet and SSH to have
>higher priority over larger traffic such as FTP. Low volume traffic is =
>given
>higher priority. Traffic is sorted into high and low volume =
>conversations.
>Traffic in one session is kept within a single session/conversation and =
>the
>records handled FIFO-style within a particular conversation. The much =
>needed
>bandwidth is given to the more interactive, low volume traffic, and the =
>high
>volume sessions equally share what is left over. On Cisco, WFQ is on by
>default for WAN interfaces that support it.
>
>3. Priority Queueing - this gives absolute control over throughput, as =
>well
>as granular control that reduces delay for high priority traffic. =
>Cisco's
>implementation of this strategy uses 4 queues; high, medium, normal and =
>low.
>High priority traffic gets the benefit of all resources available on an
>output interface until its queue is empty. The medium queue is then =
>tackled,
>and so on and so forth. Meanwhile, low priority traffic in the normal =
>and
>low queues has no choice but to wait for the higher queues to complete =
>their
>processes; but during this waiting period, traffic can age and even get
>purged from memory if the queue overflows. If an overflow occurs, all =
>new
>packets meant for that queue are dropped until some space becomes =
>available
>in the queue.
>
>4. Custom Queueing - this allows the sharing of all available bandwidth
>evenly or unevenly across all traffic types. A percentage of the =
>bandwidth
>is allocated to each of the traffic types. The difference between it and
>priority queueing is that its queues are processed in a round-robin
>sequence, or multiplexed. So, high priority traffic won't have to be
>serviced first as no traffic is designated with a higher priority over =
>the
>rest of the traffic.
>
>But like I said, any of these methods should be used for temporary or
>emergency situations. It's not considered an end-solution to bandwidth
>problems. One should either upgrade, or employ a bandwidth manager +
>queueing.
>
>Regards,
>
>Mark Tinka - CCNA
>Network Engineer
>Africa Online Uganda
>5th Floor, Commercial Plaza
>7 Kampala Rd,
>Tel: +256-41-258143
>Fax: +256-41-258144
>E-mail: mtinka at africaonline.co.ug
>Web: www.africaonline.co.ug
>=20
>
>-----Original Message-----
>From: Brian Candler [mailto:B.Candler at pobox.com]=20
>Sent: Saturday, May 17, 2003 6:12 PM
>To: Mark Tinka
>Cc: 'Robert'; afnog at afnog.org
>Subject: Re: Router with bandwidth management
>
>
>On Sat, May 17, 2003 at 01:44:35PM +0300, Mark Tinka wrote:
>> As you can see above, the access list that matches your wireless
>> client's IP address is placed onto the Ethernet interface that is
>> connected to your wireless segment. In the rate-limit statement on =
>the
>> Ethernet interface, 32000 is the bits per second allowed, 8000 is =
>the
>> normal burst bytes and 16000 is the maximum burst bytes. As the =
>last
>> few lines say, if the user's IP address conforms to this setting,
>> transmit his packets through. If the assigned capacity is exceeded,
>> begin to apply congestion control - basically, drop packets =
>exceeding
>> allocated capacity.
>
>That's the problem with Cisco's solution: it doesn't shape your traffic, =
>it
>just polices it, which means throwing away packets which exceed the
>bandwidth limit. This does not give a graceful control, but relies on =
>TCP's
>backoff algorithm sensing the packet loss to ultimately reduce the
>throughput, but it will never settle properly at the level you want.
>
>For true traffic shaping, the incoming data would be stuffed straight =
>into a
>queue, and the output interface would pull packets out of this queue at =
>your
>predetermined rate (say 64kbps):
>
> Any +--------------+ 64kbps
>Incoming ---------> | Queue | ---------> Out
> +--------------+
>
>This is how the FreeBSD ipfw dummynet shaper works (see 'man 4 ipfw' and
>scan down to 'TRAFFIC SHAPER CONFIGURATION')
>
>This approach gives no packet loss, unless of course the queue fills up. =
>But
>each TCP session will only have at most one window's worth of data "in
>transit" (typically 32K bytes) waiting for an acknowledgement.
>
>The only way I know to do this with a Cisco is to use an ATM interface,
>where you can specify the output PCR/SCR as the speed you want packets =
>to
>exit.
>
>Regards,
>
>Brian.
>
>
>
>
>-----
>This is the afnog mailing list, managed by Majordomo 1.94.5
>
>To send a message to this list, e-mail afnog at afnog.org
>To send a request to majordomo, e-mail majordomo at afnog.org and put
>your request in the body of the message (i.e use "help" for help)
>
>This list is maintained by owner-afnog at afnog.org
>
>
>