FW: QoS - MQC PARENT and Child - CORRECTED TYPOS - Sorry!!!

From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Sat Jun 18 2005 - 13:22:57 GMT-3


 Small correction to the syntax previously given, and I've added the
show policy-map interface output for illustration now I labbed it.

Cheers

Chris

I first posted it showing the output keyword applied to the
service-policy command in the PARENT policy-map, when you apply a
service policy nested within a poicy map, setting a direction is not an
option.

Just to recap, the following just shows overall shaping to 8Meg (I'm
using a regular, not fast ethernet port here). Although I've created a
CHILDREN policy-map, only the PARENT is applied at this stage

!
class-map match-all CORKSERVERS
  match protocol ip
class-map match-all CORKNONCRITICAL
  match protocol dlsw
!
!
policy-map CHILDREN
  class CORKSERVERS
   bandwidth 1500
  class CORKNONCRITICAL
   police 50000
policy-map PARENT
  class class-default
   shape average 8000000
!
interface Ethernet0/0
 ip address 172.16.136.1 255.255.255.192
 service-policy output PARENT

Router1(config-if)#do sho policy int
 Ethernet0/0

  Service-policy output: PARENT

    Class-map: class-default (match-any)
      1 packets, 60 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average Byte Sustain Excess Interval
Increment
             Rate Limit bits/int bits/int (ms) (bytes)

          8000000/8000000 50000 200000 200000 25 25000

        Adapt Queue Packets Bytes Packets Bytes Shaping
        Active Depth Delayed Delayed Active
        - 0 1 60 0 0 no

Now add in the service-policy for the CHILDREN as follows

policy-map PARENT
  class class-default
   shape average 8000000
   service-policy CHILDREN

And you get a different output from the show policy-map command to show
the hierarchical queuing configured.

Router1#sho policy int
 Ethernet0/0

  Service-policy output: PARENT

    Class-map: class-default (match-any)
      34 packets, 3702 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average Byte Sustain Excess Interval
Increment
             Rate Limit bits/int bits/int (ms) (bytes)

          8000000/8000000 50000 200000 200000 25 25000

        Adapt Queue Packets Bytes Packets Bytes Shaping
        Active Depth Delayed Delayed Active
        - 0 34 3702 0 0 no

      Service-policy : CHILDREN

        Class-map: CORKSERVERS (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol ip
          Queueing
            Output Queue: Conversation 137
            Bandwidth 1500 (kbps) Max Threshold 64 (packets)
            (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0

        Class-map: CORKNONCRITICAL (match-all)
          0 packets, 0 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: protocol dlsw
          police:
              cir 50000 bps, bc 1562 bytes
            conformed 0 packets, 0 bytes; actions:
              transmit
            exceeded 0 packets, 0 bytes; actions:
              drop
            conformed 0 bps, exceed 0 bps

        Class-map: class-default (match-any)
          7 packets, 749 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any

Chris

-----Original Message-----
From: Chris Lewis (chrlewis)
Sent: Saturday, June 18, 2005 7:49 AM
To: 'Keane, James'; lab
Subject: RE: QoS - MQC PARENT and Child - CORRECTED TYPOS - Sorry!!!

Hi James,

The second question is the simplest. The only issue is QoS policies like
this will increase CPU utilization.

Regarding the first, the desire to do per site QoS configurations within
an overall shaped rate, is fairly common I believe. I may be missing
something, or you may not have copied it in this config, but I don't see
where the overall rate is shaped to 45Meg.

If I was going to start from scratch to do this, I'd set a rate for the
class default on the interface, check that was working and add the
hierarchy from there.

A general thought process to consider here is that for qoS queuing
configurations to take effect, you need a queue to form so that the
queuing can re-order packets within the queue :) I know this sounds
simple, but unless you have a mechanism creating a queue, no QoS tales
place. In this case the interface is 100Meg, so it will send at that
rate, the committed rate from the provider is 45Meg, so you need to
create back pressure on your router in order for queuing policies to
work, otherwise your router just sends at 100 meg and the provider drops
above 45 meg. Once you create back pressure and you have a queue within
your router, the per site policies will take effect. From what you paste
in below, I don't see what creates the back presure, so I don't see what
would cause the queuing policies to take effect.

So I'd start this configuration with setting a shaped rate for the
interface as a whole like this.

Policy-map PARENT
 class class-default
  shape average 45000000

Interface fastethernet 0/0
 service-policy output PARENT

At this level in the hierarchy, no class-maps have been defined so all
traffic falls in to the class-default class.

Now you want to work in the hierarchical queuing part to give each
remote location the bandwidth you want, taking Cork as an example.

What we actually want to do is add a service-policy in the policy-map
PARENT config to control all the per site configurations, so creat the
following:

Policy-map CHILDREN
 class CORKSERVERS
  bandwidth 1500
 class CORKNONCRITICAL
  police 50000 etc.

Once you've added this, all you need to do is add the service-policy to
the PARENT policy-map and hierarchical queueing should now be in effect,
and viewable with the show policy-map interface command. The end config
should look like this and to add more sites, just add more class and
queuing/policiing definitions to the policy-map CHILDREN section:

Policy-map PARENT
 class class-default
  shape average 45000000
  serive-policy output CHILDREN
!
Policy-map CHILDREN
 class CORKSERVERS
  bandwidth 1500
 class CORKNONCRITICAL
  police 50000 etc.
!
Interface fastethernet 0/0
 service-policy output PARENT

This type of configuration is fairly simple to add another level of
hierarchy, for example, if for the CORKSERVERS you wanted to prioritize
one traffic type over another, add a service-policy to class
CORKSERVERS (under the policy-map CHILDREN section), which links to a
policy map to define traffic paramteres for HTTP versus oracle or
whatever and as long as the class-maps used identify the right traffic,
you can add traffic type prioritization too.

HTH

Chris

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Keane, James
Sent: Friday, June 17, 2005 4:53 AM
To: lab
Subject: RE: QoS - MQC PARENT and Child - CORRECTED TYPOS - Sorry!!!

I am having a good play with MQC and also setting up parent and child, I
am implementing it on a 100 mb fast int, In a nutshell I have many sites
and I would like to be able to implement different policies for each
site, its a connection into an MPLS cloud and the outbound traffic cant
exceed 45mb, the whole thing it isnt working very well and the processor
is running at about 20% the whole time, (normally 10%), it is a 2600XM

FIRST QUESTION
Do you think I have this parent child set up ok, is this how you would
do it ?

SECOND QUESTION
Is there any issues with implementing a QoS policy like this on a 100mb
int (when the AR is 45mb)

Here is the config

!
! bit for defining the classes for the CORK child policy ! there would
be another couple of these !
class-map match-all CORKNONCRITICAL
  match access-group name CORKNONCRITICAL class-map match-all
CORKCORESERVERS
  match access-group name CORKCORESERVERS

!
! bit for defining the individual child policies ! ok we would have 2 or
three more policies- i'll omit them for clarity !

policy-map CORKCHILDPOL
  class CORKCORESERVERS
   bandwidth 1500
  class CORKNONCRITICAL
     police 500000 15625 15625 conform-action transmit exceed-action
drop
  class class-default
   fair-queue

!
! bit for defining the children's classes (that sounds weird) ! for the
parent policy !
class-map CORKCITYCHILD
 match access-group name ALLCORKTRAFFIC
class-map CAVANCHILD
 match access-group name ALLCAVANTRAFFIC class-map KERRYCHILD match
access-group name ALLKERRYTRAFFIC !
! now the parent policy
!
policy-map QOSPOLICY

 class CORKCITYCHILD
  service-policy CORKCHILDPOL

 class CAVANCHILD
  service-policy CAVANCHILDPOL

 class KERRYCHILD
  service-policy KERRYCHILDPOL

 class class-default
  fair-queue

!
interface FastEthernet0/0
 bandwidth 100000
 service-policy output QOSPOLICY
 speed 100
!

**********************************************************************
*********** Department of Agriculture and Food ***************

The information contained in this email and in any attachments is
confidential and is designated solely for the attention and use of the
intended recipient(s).
This information may be subject to legal and professional privilege. If
you are not an intended recipient of this email, you must not use,
disclose, copy, distribute or retain this message or any part of it.
If you have received this email in error, please notify the sender
immediately and delete all copies of this email from your computer
system(s).
**********************************************************************



This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:41 GMT-3