[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[altq 1002] ALTQ performance, configuration and VLANs
Now that ALTQ has made it into the OpenBSD source tree - thanks to all those
woking so hard - I am looking to implement it in a late test phase of a project
I am working on.
The general topology is:
1. A full table BGP router with one 'upstream' interface through a switch fabric
and out to multiple upstream transit providers. Each upstream transit provider
supplies about the same bandwidth, but BGP decisions means that we cannot know
at the start what the ratios are going to be.
2. Downstream customers each connected to an Ethernet switch via an 802.1q VLAN
from the OpenBSD router. About 50 per router max.
(The actual topology is more complex, with some resilience features etc. but
they should be outside the scope of this message.)
These downstream customers are typical 'content providers' - i.e. web hosting,
e-commerce etc. so most of the traffic will be upstream bound. I want to be able
to impose some, as yet undefined, bandwidth prioritisation scheme on the
customers using committed rates and bursting. So far, so standard - I hope.
What I am not sure about is what the 'best current practise' is for this type of
thing.
Assuming each upstream is supplying 10Mb/sec of bandwidth and there are three of
them, I want to limit the overall amount going to each but providing some
minimum to each downstream.
Given that the only inbound discipline / conditioner is a sledge hammer - ok, I
generalise :) - what if any are the performance and configuration gotchas for
putting a whole load of filters on classes on the upstream interface ? Does that
make sense even ?
In this situation, what would be the best queueing discipline, from experience ?
rgds,
--
Peter Galbavy
Knowtion Ltd.