From: Bob Sinclair (bsin@cox.net)
Date: Wed Dec 29 2004 - 12:55:16 GMT-3
Hi David,
These are all good questions you ask, and I hope some other folks will give
us the benefit of their experience. Here are some conclusions I have
reached that may be relevant:
When frame-relay traffic-shaping is configured on a physical interface, the
concept of interface Available Bandwidth disappears, and max-reservable
bandwidth is equal to mincir of the dlcis.
Notes below regard applying cbwfq policy-maps at different levels.
On Physical Interfaces:
Any policy-map can be applied to a physical interface using the
service-policy input/output command.
On Subinterfaces:
Policies that use only the "shape," "set" or "police" options can be applied
directly to a subinterface.
Policy-maps that use the "bandwidth" or "priority" commands must be applied
in a child policy to a shaped parent policy (a "nested" or "hierarchical"
policy). Any "percent" value in the child policy is of the shaped rate.
On DLCIs:
Policy-maps cannot be applied directly to DLCIs. They must be applied in a
Frame-Relay map-class.
If Frame-Relay traffic shaping is configured on the physical interface, then
any policy can be applied directly to a map-class.
If Frame-Relay traffic shaping is not configured on the physical interface,
then policies that use only the "shape," "set" or "police" options can be
applied directly to a map-class.
Policy-maps that use the "bandwidth" or "priority" commands must be applied
in a child policy to a shaped class-default in the parent policy (a "nested"
or "hierarchical" policy). Any "percent" value in the child policy is of the
shaped rate.
Above comments are not directly on point. But hope they help.
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: "David Duncon" <david_ccie@hotmail.com>
To: <bsin@cox.net>; <ccielab@groupstudy.com>
Sent: Wednesday, December 29, 2004 6:25 AM
Subject: Re: Class class-default
> Ok, now I know where you are coming from , Bob :-) Thanks.
>
> Can I ask you one last Q before we exit this topic ?
>
> I am not 100% on this max-reference bandwidth command's functionality.
> From my understanding MQC is by default is only uses 75% of the target CIR
> of the circuit. And if you want to use MQC engine to use more than 75% of
> the available CIR , then you use this max-reference bandwidth command to
> tweak this behavior.
>
> Now let me take help of an example to push my doubts across.
>
> So let us say we have a P2P VC an Access & CIR of 1024k and 256k
> respectively. And I have configured " Access of 1024k " on the serial
> interface with a "bandwidth command. But at L2 I have , I have adaptive
> shaping becn (with mincir of 257000) and throttle down to the real CIR of
> 256k in the event of congestion.
>
> Now these are my doubts,
>
> 1) I was in impression that Frame relay predominantly takes the mincir
> value as the primary reference value , so unlike any other WAN protocols ,
> we do not necessarily need to configure the max-reference bandwidth
> command on the serial interfaces. Am I on right school of thought ?
>
> As a mater of fact , that is what I am running on my production network.
> While running LLQ & CBWFQ at L3 and A/shaping at L2 , I am not using
> this command at all on our frame circuits . And every things works as per
> specs or user requirements. So I was wondering when do I need to use this
> command on the ground.
>
> 2) Secondly as I mentioned above , I normally configure the Access value
> on each VC as my bandwidth command under serial int or sub interfaces at
> both the ends. So I assume that Queuing engine will look at the Access
> value of 1024k as the reference point (to take 75% of that ###) at L3 and
> then A/Shaping engine will look at MINCIR value of 256k , then how does it
> work. Do you see my confusion ?
>
> May be I am thinking too many unnecessary aspects or I am bit confused on
> how L2 shaping config interacts with L3's Queuing before the actual 0s and
> 1s are clocked on to the wire.
>
> I appreciate your guidance on this long running & confused issue :(
>
> Cheers
>
> - David.
>
>>From: "Bob Sinclair" <bsin@cox.net>
>>To: "David Duncon" <david_ccie@hotmail.com>,<ccielab@groupstudy.com>
>>Subject: Re: Class class-default
>>Date: Mon, 27 Dec 2004 22:32:55 -0500
>>
>>Hi David,
>>
>>When I reserve bandwidth for a class and apply that policy to an
>>interface, I should see the Available Bandwidth parameter decrease from
>>75% (default max-reservable). Each time I reserve more bandwidth in an
>>applied policy I should see Available bandwidth (show interface)
>>correspondingly decrease. This did not happen when I entered the command
>>to reserve bandwidth for class class-default, further suggesting that the
>>command is not effective.
>>
>>HTH,
>>
>>Bob Sinclair
>>CCIE #10427, CCSI 30427, CISSP
>>www.netmasterclass.net
>>
>>----- Original Message ----- From: "David Duncon" <david_ccie@hotmail.com>
>>To: <bsin@cox.net>; <ccielab@groupstudy.com>
>>Sent: Monday, December 27, 2004 8:58 PM
>>Subject: Re: Class class-default
>>
>>
>>>Appreciate your feedback, Bob.
>>>
>>>As I did not quite get your point (attached clip bellow) , can you please
>>>elaborate ?
>>>
>>><clip> it does not decrease available bandwidth on the interface. <clip>
>>>
>>>Cheers
>>>
>>>- David
>>>
>>>>From: "Bob Sinclair" <bsin@cox.net>
>>>>To: "David Duncon" <david_ccie@hotmail.com>,<ccielab@groupstudy.com>
>>>>Subject: Re: Class class-default
>>>>Date: Mon, 27 Dec 2004 08:17:17 -0500
>>>>
>>>>David,
>>>>
>>>>I would say definitely option 1. Is the bandwidth command really
>>>>effective in class class-default? On my box it takes the command, but
>>>>it does not show up in the output of "show policy-map interface," and
>>>>it does not decrease available bandwidth on the interface.
>>>>
>>>>HTH,
>>>>
>>>>Bob Sinclair
>>>>CCIE #10427, CCSI 30427, CISSP
>>>>www.netmasterclass.net
>>>>
>>>>----- Original Message ----- From: "David Duncon"
>>>><david_ccie@hotmail.com>
>>>>To: <ccielab@groupstudy.com>
>>>>Sent: Monday, December 27, 2004 2:54 AM
>>>>Subject: Class class-default
>>>>
>>>>
>>>>>Hi Group,
>>>>>
>>>>>I got a Q on MQC 'c class class-default behavior. And appreciate your
>>>>>guidance on this.
>>>>>
>>>>>On production network, let us consider that we have end to end L3 MQC
>>>>>policy which primarily aimed to protect Business critical apps such as
>>>>>Voice and Citrix and bundled every other traffic type such as File
>>>>>transfers , HTTP and Emails ..etc in to a common default class with
>>>>>random detect feature enabled. Since there is a bit of concern on the
>>>>>email (MS Exchange & Lotus Notes Domino) traffic with in a default
>>>>>class as we are seeing some drops there. So If we were to segregate &
>>>>>prioritize email traffic from the rest of default class traffic , then
>>>>>which of the following options is the better way to go. Either to leave
>>>>>the email traffic with in class class-default and assign a guaranteed
>>>>>bandwidth or to segregate email traffic in to separate class-map with
>>>>>in policy-map. The reason I am asking this Q is to understand any
>>>>>negative impacts the NON time sensitive email traffic can bring in to
>>>>>policy maps processing where already time sensitive traffic types
>>>>>(Voice & citrix) are being serviced.
>>>>>
>>>>>
>>>>>Option 1:
>>>>>=================
>>>>>
>>>>>Policy-map data
>>>>>
>>>>>Class voice
>>>>>Match access-group xxx
>>>>>Priority xxx
>>>>>
>>>>>Class citrix
>>>>>Match access-group xxx
>>>>>Bandwidth xxx
>>>>>
>>>>>Class email
>>>>>Match access-group xxx
>>>>>Bandwidth xxx
>>>>>
>>>>>Class class-default
>>>>>Random detect
>>>>>
>>>>>Option 2:
>>>>>==================
>>>>>
>>>>>Policy-map data
>>>>>
>>>>>Class voice
>>>>>Match access-group xxx
>>>>>Priority xxx
>>>>>
>>>>>Class citrix
>>>>>Match access-group xxx
>>>>>Bandwidth xxx
>>>>>
>>>>>Class class-default
>>>>>Random detect
>>>>>Bandwidth xxx ---------------------------------------> emails are
>>>>>bundled together along with file transfers & HTTP traffic with in class
>>>>>default.
>>>>>
>>>>>
>>>>>And my Qs are :
>>>>>
>>>>>1) is there any way where we can create 2 class-maps with in class
>>>>>class-default , one for email and the rest for all default traffic ? If
>>>>>yes is there any benefit in doing that ?
>>>>>
>>>>>2) or is it safe for me to create another class-map for email and slot
>>>>>that in with policy-map itself along with voice & citrix and dedicate
>>>>>certain amount of bandwidth to it.
>>>>>
>>>>>3) Thirdly , what is the between a class class-default with a bandwidth
>>>>>command and one with out a bandwidth command. And also what is the
>>>>>difference between a class class-default with a random detect command
>>>>>and one with out it. Though I do aware the functionality of congestion
>>>>>avoidance techniques such as WRED and RED , I was in the impression
>>>>>that besides configuring random detect , you need to map it to a
>>>>>relevant DSCP code which underlines a certain level of drop
>>>>>probability. In other words, you are telling the policy engine on what
>>>>>type of traffic you want her to drop should she pick up any early
>>>>>congestion warnings.
>>>>>
>>>>>
>>>>>Any feed back is much appreciated.
>>>>>
>>>>>- David.
>>>>>
>>>>>_________________________________________________________________
>>>>>SEEK: Now with over 60,000 dream jobs! Click here:
>>>>>http://ninemsn.seek.com.au?hotmail
>>>>>
>>>>>_______________________________________________________________________
>>>>>Subscription information may be found at:
>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>
>>>>
>>>
>>>_________________________________________________________________
>>>Find love today with ninemsn personals. Click here:
>>>http://ninemsn.match.com?referrer=hotmailtagline
>>>
>>>_______________________________________________________________________
>>>Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>
>>
>
> _________________________________________________________________
> SEEK: Now with over 60,000 dream jobs! Click here:
> http://ninemsn.seek.com.au?hotmail
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:31 GMT-3