RE: NMC Lab# 18 QoS Configuration

From: chrlewis@cisco.com
Date: Sun Sep 25 2005 - 21:53:05 GMT-3


Hi Simon,

I think you have it right and make a good point about the bandwidth
statement.

For anyone that does not want to memorize this sort of stuff for the
exam, I'd strongly recommend familiarity with the show policy-map
interface command, it verifies what pecentage has been applied. Taking
the config supplied and applying it to an interface with multiple DLCIs
on it shows the policy applied to all DLCIs and the percentage
calculated, an example is at the end of this response.

Regards adaptive shaping, this is my understanding.

Adaptive shaping using the older BECN awareness means that should the
interface see BECNs, it will start to throttle the rate it transmits at
down from CIR to mincir, but no lower. I believe the congestion
awareness option does the same thing, but uses interface congestion
rahter than BECNs as the trigger for shaping and thorttling back of
output. The throttling algorithm for interface congestion awareness is
given in the documentation as following:

When the congestion level exceeds a configured value called queue depth,
the sending rate of all PVCs is reduced to the minimum committed
information rate (minCIR). As soon as interface congestion drops below
the queue depth, the traffic-shaping mechanism changes the sending rate
of the PVCs back to the committed information rate (CIR).

So, if there is no congestion, there will be no shaping. However set
statements are not conditional upon bandwidth or priority statements
being active in order for them to mark. The class-map identifies traffic
and the policy map applies the set commands, if there is no congestion,
the bandwidth commands will not be active but the plain set commands
will be, just as if no bandwidth command was configured.

Chris

Router2(config-if)#do sh policy-map int
 Serial1/0: DLCI 221 -

  Service-policy output: QOS

    Class-map: QOS-1 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 5
      Queueing
        Strict Priority
        Output Queue: Conversation 24
        Bandwidth 30 (%)
        Bandwidth 9 (kbps) Burst 225 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0
      QoS Set
        dscp ef
          Packets marked 0

    Class-map: QOS-3 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 1
      Queueing
        Output Queue: Conversation 25
        Bandwidth 20 (%)
        Bandwidth 6 (kbps) Max Threshold 64 (packets)
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
      QoS Set
        dscp af33
          Packets marked 0
        fr-de
          Packets marked 0

    Class-map: QOS-2 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 3
      Queueing
        Output Queue: Conversation 26
        Bandwidth 30 (%)
<------------------------------------------------------percent
calculation
        Bandwidth 9 (kbps) Max Threshold 64 (packets) <-------------
        (pkts matched/bytes matched) 0/0
        (depth/total drops/no-buffer drops) 0/0/0
      QoS Set
        dscp af31
          Packets marked 0

    Class-map: class-default (match-any)
      1 packets, 88 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Queueing
        Flow Based Fair Queueing
        Maximum Number of Hashed Queues 16
        (total queued/total drops/no-buffer drops) 0/0/0
      QoS Set
        dscp default
          Packets marked 1
 Serial1/0: DLCI 244 -

  Service-policy output: QOS

    Class-map: QOS-1 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip precedence 5
      Queueing
        Strict Priority
        Output Queue: Conversation 24
        Bandwidth 30 (%)
        Bandwidth 9 (kbps) Burst 225 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0
      QoS Set
        dscp ef
          Packets marked 0

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
simon hart
Sent: Saturday, September 24, 2005 2:39 AM
To: Dennis J. Hartmann; ccielab@groupstudy.com
Subject: RE: NMC Lab# 18 QoS Configuration

Hi Dennis,

MQC will pick up on the values assigned within Frame map class when
frame traffic shaping is enabled. In fact MQC will ignore the interface
bandwidth value assigned.

However MQC will use the value of mincir for assigning bandwidths.
Therefore in your example the bandwidth will be carved up as

30% of 32k for QOS-1
30% of 32k for QOS-2
20% of 32k for QOS-3
20% of 32k for Class-default

If no mincir figure was given within the map-class statement then MQC
would pick up on cir/2 = 125000 / 2 for the values.

Now what I am not sure on is the adaptive shaping, perhaps some others
could help.

If the interface is not congested then there will be no traffic shaping.
If there is no traffic shaping will the service policy within the Map
class be active?? If not then the CBWQ will not be working when the
interface is not congested, and thus your set statements will not work.
Would really like some clarity on this

Simon

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Dennis J. Hartmann
Sent: 24 September 2005 04:14
To: ccielab@groupstudy.com
Subject: NMC Lab# 18 QoS Configuration

    While I do NOT endorse adaptive traffic-shaping for VoIP networks of
any sort, I have come across this scenario in a CCIE practice test. The
question wants the admin to configure a Frame-Relay QoS policy that will
adapt rates based on interface congestion because the interface only
runs at 125kbps, but there are multiple PVCs terminating on the
interface. This calls for the frame-relay adaptive-shaping
interface-congestion command in the map-class.

    I don't think the answer key is correct though. In the following
policy, the mapclass has the cir and mincir configured and the CBWFQ
policy is being called to carve up the bandwidth on the interface. I
don't believe that the MQC has the ability to configure a policy based
on the cir in a frame map-class. This is why we normally use nested
policies to configure frame-relay traffic-shaping and congestion
management. The adaptive traffic-shaping interface-congestion feature
is not a part of the MQC however.

    Given the scenario, I believe the only logical choice would be to
put a bandwith 125 statement on the Serial 0/0 interface so the CBWFQ
congestion management policy is based on 125kbps, not the default of
1544kbps.

    Comments and suggestions welcome.

interface Serial0/0
 no ip address
 encapsulation frame-relay
 no fair-queue
 frame-relay class Frame-QOS
 frame-relay traffic-shaping

 policy-map QOS
  class QOS-1
   priority percent 30
   set dscp ef
  class QOS-3
   bandwidth percent 20
   set dscp af33
   set fr-de
  class QOS-2
   bandwidth percent 30
   set dscp af31
  class class-default
   fair-queue
   set dscp default

 class-map match-all QOS-1
  match ip precedence 5
 class-map match-all QOS-2
  match ip precedence 3
 class-map match-all QOS-3
  match ip precedence 1

map-class frame-relay Frame-QOS
 frame-relay cir 125000
 frame-relay mincir 32000

 frame-relay adaptive-shaping interface-congestion service-policy
output QOS

Sincerely,

Dennis J. Hartmann

White Pine Communications

dh8@pobox.com

CCSI#23402 / CCVP / CCIP / CCNP

Cisco Optical, VPN & IDS Specialist

MCSE



This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:16 GMT-3