From: Alex De Gruiter \(AU\) (Alex.deGruiter@didata.com.au)
Date: Thu Oct 05 2006 - 21:22:30 ART
Sorry, lack of sleep (the ammended options are below). So,
max-reserved-bandwidth actually has no bearing on actual service
restriction, but rather to prevent configuration errors. Interesting.
To hijack this thread (I'm allowed, its my own!), lets say you have 3
classes, calling for 30%, 20% and 40% of the total bandwidth; you would
need to adjust max-reserved-bandwidth to allow for the 90%. I think the
command is making a little more sense now. In reality,
max-reserved-bandwidth has no real effect on the actual QoS performance.
From the Doc CD: The police (percent) command uses the maximum rate of
bandwidth available as the reference point for calculating the bandwidth
percentage.
Therefore, if my understand is correct, a more appropriate solution
would be as follows (no need for max-reserved bandwidth). Can you
confirm?
i)
policy-map POLICE
class class-default
police percent 65
int serial 0/0
service-policy output POLICE
A)
int serial 0/0
max-reserved-bandwidth 65
B)
policy-map POLICE
class class-default
police percent 65
int serial 0/0
max-reserved-bandwidth 100
service-policy output POLICE
C)
policy-map POLICE
class class-default
police percent 65
int serial 0/0
! Default bandwidth
max-reserved-bandwidth 75
service-policy output POLICE
-----Original Message-----
From: Marvin Greenlee [mailto:marvingreenlee@yahoo.com]
Sent: Friday, 6 October 2006 9:57 AM
To: Alex De Gruiter (AU); ccielab@groupstudy.com
Subject: Re: Policing or max-reserved-bandwith?
Think of max-reserved as a "safety threshold". It is there primarily to
prevent a misconfigured policy from using up all the available
bandwidth, such that control traffic, etc., would not be able to get
through. All it does is prevent the application of a policy that is
asking for more than 75% of the interface's bandwidth.
[Note: some of the earlier 12.1T/12.2 codes calculated policies based
on the max-reserved, so be careful if you are using one of those codes.
In affected IOS versions, if you had a max reserved of 80% and specified
a bandwidth percent of 50%, it would allocate 40% (50% of 80%) for that
class.]
Verify on your router with show policy interface x/x
For the purposes of the lab, if the question does not give explicit
values for the interface bandwidth, I would assume that you are expected
to use the default for the interface.
Like everything else, if a section is unclear, ask the proctor for
clarification.
A doesn't do anything as far as restricting traffic.
B and C would act the same as each other, since neither policy is asking
for more than the max-reserved.
Is there a reason why you have 65% in A and 75% in B and C?
Thanks,
Marvin
--- "Alex De Gruiter (AU)"
<Alex.deGruiter@didata.com.au> wrote:
> Guys,
>
> I have a question about how Cisco considers the maximum bandwidth
> available on a line in terms of the CCIE lab.
>
> Lets say you have a router connected to a frame relay cloud, and the
> question states that you should never exceed 65% of the available
> bandwidth on the line. Assume that FRTS can not be used, and that you
> do not know the speed of the line.
>
> Which of the following solutions would be the most
> appropriate:
>
> A)
>
> int serial 0/0
> max-reserved-bandwidth 65
>
> B)
>
> policy-map POLICE
> class class-default
> police percent 75
>
> int serial 0/0
> max-reserved-bandwidth 100
> service-policy output POLICE
>
> C)
>
> policy-map POLICE
> class class-default
> police percent 75
>
> int serial 0/0
> ! Default bandwidth
> max-reserved-bandwidth 75
> service-policy output POLICE
>
> What do you think?
>
> Alex
>
>
************************************************************************
******
> - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential,
> and may contain proprietary or legally privileged information. If you
> have received this email in error, please notify the sender and delete
> it immediately.
>
> Internet communications are not secure. You should scan this message
> and any attachments for viruses.
> Under no circumstances do we accept liability for any loss or damage
> which may result from your receipt of this message or any attachments.
>
************************************************************************
******
>
>
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:04 ART