Re: QoS interpretation

From: Dale Shaw <dale.shaw_at_gmail.com>
Date: Wed, 15 Apr 2009 11:15:59 +1000

Hi,

It's suggesting that BB2 and BB3 -- devices which you don't have any
administrative control over -- are policing at the specified rates. I
believe the task is asking you to configure shaping (outbound, of
course) to the same rate.

Think of R5 as a customer router, and BB2 and BB3 as service provider
routers. BB2 and BB3 are going to drop any traffic in excess of the
specified rates, so it makes sense to avoid that situation completely
by implementing a queueing strategy on routers you control, on egress
to the provider.

Shaping is typically the best solution. You could achieve a similar
thing by using policing (usually on ingress to the CPE but it really
depends on the CPE configuration), but all that really does is move
the effect of the configuration (drops) to devices that you control.
Shaping allows traffic to be delayed without being dropped - to a
point. In the real world, depending on your applications and how they
respond to packet delay vs packet loss, policing may be a better
choice.

But that's in the real world ;-)

cheers,
Dale

On Wed, Apr 15, 2009 at 8:24 AM, Nick <ccieaz_at_googlemail.com> wrote:
> Hi all,
>
> I still have trouble sometimes with QoS question interpretation.
>
> Take this example from IE lab 18
>
> ".... BB2 will only allow R5 to send traffic across this link at a maximum
> of 2.5mpbs. BB3 will only allow R5 to send traffic into its network at a
> maximum rate of 3mpbs"
>
> How should I interpret this?
>
> I think that you could do this with shaping, policing or bandwidth
> statement. But which is best and why?
>
> Any tips would be great.
>
> (SG uses shaping)
>
> Thanks
>
> Nick
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed Apr 15 2009 - 11:15:59 ART

This archive was generated by hypermail 2.2.0 : Mon May 04 2009 - 07:39:12 ART