On Wed, 24 Jan 2001, Jack Coates wrote:
> I want to limit bandwidth available. Limiting bandwidth looks like it can
> be done pretty easily, after perusing the EigerSteinBETA2 scripts. But I'm
> not sure that establishing a single queue is effectively going to put all
> traffic into that queue. I'm also not sure if the queue is used on both
> traffic directions or only on one -- wouldn't want to accidentally double
> my restriction... Is there a way to make the queue unidirectional?
AFAIK, if there's only the one queue and that queue is applied to the
involved interfaces, any traffic going over that interface will live in
that queue first. Queueing on Ciscos is for any traffic destined for the
far side of the link that the interface lives on, so therefore queueing
the interface should have no effect on traffic coming in and destined for
another location.
If you're feeling adventurous, there's two options on the 2.4 side of the
kernel stuff; Under Networking Options there's Class-Based Queueing
(CONFIG_CBQ I believe) that's designed to restrict bandwidth usage, and
there's also - under Networking Devices - Traffic Shaper
(CONFIG_SHAPER; you need to turn on prompting for experimental code, since
it's listed under it.) I don't know if either of these are backported to
the 2.2.xx kernels, but they're a surefire way of getting the right
results. It also rules out LRP/LEAF, since nobody has a working and
configured 2.4.0 LRP Image yet.
> I want to introduce latency in a controlled manner. The link I'm going to
> simulate is ATM and currently provides about 200 ms latency (not bad for
> Santa Clara to London, huh?).
Not bad at all; UUNet has a hard time doing that over their backbone from
New York to LA on a weekday afternoon. =)
> I haven't got the slightest idea how to
> control latency. The queue buffering will certainly introduce a component,
> but I need that to be in addition to the latency of a real transoceanic
> cable because there will be buffering in the real application as well.
Again, you very well may be able to tweak some of the QoS options out to
create this controlled latency. Not my area of expertise, since we don't
use QoS on our network at the customer circuit level. Sorry.
> For the curious, this is a customer who wrote their app assuming global
> support could be done from a single datacenter and has since discovered
> that they need a regional presence for certain functions to work. However
> since all traffic passes through the database and needs to be near real
> time... when all roads lead to Rome you can't have two Romes.
Ah, another fine example of the innocence of design that visionaries tend
towards. Where would our jobs - and hobbies! - be without them? =)
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
