Qos policy not utilizing total bandwidth

Unanswered Question
Apr 12th, 2009

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Sun, 04/12/2009 - 11:39

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

tim1csolutions Sun, 04/12/2009 - 21:29

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

Edison Ortiz Mon, 04/13/2009 - 05:54

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.

Actions

This Discussion