From: David Duncon (david_ccie@hotmail.com)
Date: Wed Dec 29 2004 - 06:03:05 GMT-3
Ohh, I got it now, Chuck :-) Thanks for the insight.
Cheers
- David.
-----Original Message-----
From: Church, Chuck [mailto:cchurch@netcogov.com]
Sent: Tuesday, 28 December 2004 3:50 PM
To: David Duncon; ccielab@groupstudy.com
Subject: RE: Class class-default
David,
Say after you've dedicated your bandwidth to your priority
(voice) and important (citrix&email) traffic; that you've got 256kb left.
It makes no sense to have your normal business (http, ftp, etc) traffic
battle it out with P2P or streaming radio apps; with each suffering WRED
drops. If you police your 'fun' traffic to say 16kb, you're guaranteeing
240kb for everything else. Sort of like this:
class fileshare
police cir 16000 bc 1000 be 2000
conform-action transmit
exceed-action drop
Where the fileshare class is defined by NBAR or something like that.
It's just a case of robbing Peter (non-business-related apps) to pay Paul
(business-related apps). HTH.
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team 1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
cchurch@netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
-----Original Message-----
From: David Duncon [mailto:david_ccie@hotmail.com]
Sent: Monday, December 27, 2004 8:55 PM
To: Church, Chuck; ccielab@groupstudy.com
Subject: RE: Class class-default
Thanks for your time, Chuck.
Can you please elaborate or give an example of your previous statement.
<clip> Other things you can consider is policing or shaping your
less-than-normal-importance traffic, such as file-sharing apps, etc.
That'll
lessen your WRED drops for your class-default traffic. <clip>
Cheers
- David.
>From: "Church, Chuck" <cchurch@netcogov.com>
>To: "David Duncon" <david_ccie@hotmail.com>,<ccielab@groupstudy.com>
>Subject: RE: Class class-default
>Date: Mon, 27 Dec 2004 07:49:45 -0600
>
>I think I'd go with solution 1. Like Bob said, I don't think assigning
>a bandwidth to the class-default makes any sense. You don't want random
>detect being applied to the email traffic either, which makes a better
>case for solution 1 as well. Of course with any complicated QOS
>configuration, it's going to take some fine tuning to get the settings
>you want. Other things you can consider is policing or shaping your
>less-than-normal-importance traffic, such as file-sharing apps, etc.
>That'll lessen your WRED drops for your class-default traffic.
>
>
>Chuck Church
>Lead Design Engineer
>CCIE #8776, MCNE, MCSE
>Netco Government Services - Design & Implementation Team
>1210 N. Parker Rd.
>Greenville, SC 29609
>Home office: 864-335-9473
>Cell: 703-819-3495
>cchurch@netcogov.com
>PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>David Duncon
>Sent: Monday, December 27, 2004 2:54 AM
>To: ccielab@groupstudy.com
>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
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:31 GMT-3