04-12-2009 08:17 AM - edited 03-04-2019 04:20 AM
I have a QoS policy configured on a fractional DS3 that is 15Mbps into our MPLS:
interface Serial5/1
no ip address
encapsulation frame-relay IETF
dsu bandwidth 44210
framing c-bit
cablelength 10
serial restart-delay 0
frame-relay traffic-shaping
Max-reserved-bandwidth 90
interface Serial5/1.400 point-to-point
bandwidth 15000
ip address 1.1.6.2 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 400 IETF
class P-class
map-class frame-relay P-class
frame-relay cir 15000000
service-policy output P-QoS
policy-map P-QoS
class VOICE
set ip dscp ef
priority percent 8
class VIDEO
bandwidth percent 25
set ip dscp ef
class class-default
set ip precedence 0
class DATA
set ip dscp af31
bandwidth percent 3
random-detect
Whenever I do a "sh policy-map int", I see the policy is applied, but only utilizing half of the interface bandwidth of 15M:
Class-map: VOICE (match-all)
3044633 packets, 219257241 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 190
QoS Set
dscp ef
Packets marked 3044633
Queueing
Strict Priority
Output Queue: Conversation 136
Bandwidth 8 (%)
Bandwidth 600 (kbps) Burst 15000 (Bytes)
(pkts matched/bytes matched) 10144/719191
(total drops/bytes drops) 0/0
Class-map: VIDEO (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 189
Queueing
Output Queue: Conversation 138
Bandwidth 25 (%)
Bandwidth 1875 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
QoS Set
dscp ef
Packets marked 0
Is this normal for frame-relay traffic shaping?
If so, will I be utilizing the percentages I have specified of the total bandwith, or do I need to adjust the policy?
04-12-2009 11:39 AM
Hello Richard,
I'm not sure if it is related to your issue.
I noticed that you have used this command within frame-relay class
frame-relay cir 15000000
looking at the WAN command reference, it says this is typically used to define CIR for setting up SVC.
http://www.cisco.com/en/US/docs/ios/wan/command/reference/wan_f1.html#wp1012383
I would expect you to use the following other command for a PVC like yours:
frame-relay traffic-rate
http://www.cisco.com/en/US/docs/ios/wan/command/reference/wan_f2.html#wp1015005
the frame-relay traffic-rate allows to define FRTS for the PVC instead of using multiple commands for Bc, Be, mincir and so on.
Hope to help
Giuseppe
04-12-2009 12:57 PM
thanks
04-12-2009 09:29 PM
Try configuring the frame-relay traffic shaping using Modular QoS. Remove the frame-relay traffic shaping command from the interface and configure something like:
policy-map TRAFFIC_SHAPE
class class-default
shape average 15000000
service-policy P-QoS
map-class frame-relay P-class
service-policy output TRAFFIC-SHAPE
04-13-2009 05:54 AM
Hi Richard,
Yes, this is normal on Frame-Relay Traffic Shaping as the calculations are based on the frame-relay mincir which by default is 1/2 of the CIR.
You can see your current mincir value by typing show frame-relay pvc 400.
The mincir is the value used when the circuit receives congestion notification. If you don't want your circuit to lower its speed when these packets are received, you can have your mincir value to be equal to your cir, so your map-class would be as followed:
map-class frame-relay P-class
frame-relay cir 15000000
frame-relay mincir 15000000
service-policy output P-QoS
HTH,
__
Edison.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: