From: simon hart (simon@harttel.com)
Date: Sat Sep 24 2005 - 04:39:07 GMT-3
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
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