Burst value for Policers in a 3750

Question

Hi,
I am trying to create a Policy-Map to use it at the ingress of a Fastethernet interface to be able to enforce bandwidth utilization and marking for incoming packets.
One of my queues is used for VOICE. My objective for this queue, is to be able to guarantee around 6Mbps. I started using the below configuration, but after using 3rd party testing software (WAN Killer and Qcheck) I realized that the enforcing wasn't working because I was reaching speeds of 90Mbs for that particular class.
The first thing I thought about, was queueing at the egress.
As you can see, at a queueing level, I am using shaping for the PQ with a 10% (10 0 0 0), so I assume all traffic should be dropped after using 10Mbps (assuming I use a 100Mbps port).
After not being able to explain why my shape wasn't working the way I thought, I focused on the policer.
Looking at the Burst value, I tried to modify it, but the results of my testing didn't make any sense *.
I started testing with pairs of Bandwidth/Burst and the average speed reached just didn't make any sense.
I would like to be able to predict the max. speed based on my Policers (Bandwidth/burst). Is there any way to do it?
Thanks in advance for the help.
mls qos
mls qos map policed-dscp 24 26 to 0
mls qos map cos-dscp 0 8 24 26 34 46 48 56
mls qos srr-queue output dscp-map queue 1 threshold 2 34
mls qos srr-queue output dscp-map queue 1 threshold 3 46
mls qos srr-queue output dscp-map queue 2 threshold 2 24
mls qos srr-queue output dscp-map queue 2 threshold 3 26
mls qos srr-queue output dscp-map queue 3 threshold 3 0
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos queue-set output 1 buffers 5 10 84 1
ip access-list extended MAPI
deny ip any any
ip access-list extended SCAVENGER
deny ip any any
ip access-list extended VOICE-SIGNALING
permit tcp any any range 2000 2002
permit tcp any range 2000 2002 any
ip access-list extended VIDEO
deny ip any any
ip access-list extended VOICE
permit udp any any range 16384 32767
class-map match-all MAPI
match access-group name MAPI
class-map match-all VOICE-SIGNALING
match access-group name VOICE-SIGNALING
class-map match-all VIDEO
match access-group name VIDEO
class-map match-all VOICE
match access-group name VOICE
class-map match-all SCAVENGER
match access-group name SCAVENGER
policy-map QOS
class VOICE
police 6000000 450000 exceed-action drop
set dscp 46
class VIDEO
police 4000000 300000 exceed-action drop
set dscp 34
class VOICE-SIGNALING
police 1000000 75000 exceed-action policed-dscp-transmit
set dscp 26
class MAPI
police 3000000 225000 exceed-action policed-dscp-transmit
set dscp 24
class SCAVENGER
police 1000000 75000 exceed-action drop
set dscp 8
class class-default
police 85000000 1000000 exceed-action drop
set dscp 0
! Access Interfaces:
interface range FastEthernet0/1 - 48
switchport trunk encapsulation dot1q
switchport mode trunk
switchport voice vlan 800
spanning-tree portfast
srr-queue bandwidth share 1 5 94 1
srr-queue bandwidth shape 10 0 0 0
priority-queue out
service-policy input QOS
exit
* I tried testing different sets of values and the Bandwidth I was able to reach wasn't congruent at least with the way I understand it.
Here are some sets of values I used and the average reached speed:
Bandwidth/Burst -> Reached-Bandwidth
10000/8000 -> About 1Mbps
20000/8000 -> About 2Mbps
20000/20000 -> About 2Mbps
30000/8000 -> About 0.5Mbps
30000/15000 -> About 0.5Mbps
30000/500000 -> About 0.5Mbps
320000/8000 -> About 320Kbps -> This is an actual example from the SRND.
4000000/8000 -> About 3Mbps
5000000/8000 -> About 5Mbps
6000000/8000 -> More than 15Mbps
5500000/8000 -> Around 6Mbps (I had a few instances where the max. speed reached 25Mbps)

Answer 1

None of this is making sense to me. Please provide more details after considering the following:
1. The priority-queue on the c3750 is output only, so setting a 'shape' to 10% would only effect outgoing traffic from the port, not inbound traffic. You can configure one ingress queue as the priority queue by using the 'mls qos srr-queue input priority-queue bandwidth ' global configuration command (see the docs).
2. The 'shaping' that you are describing for the priority queue is queue shaping, not a traffic shaper as if you had a policy map with a 'shape average ' command. This 'queue shaping' is outbound only and will not impact inbound traffic to the port. This is different if this is a metro c3750 on the ES ports.
3. Why are all 48 ports configured as trunks?
4. Why are you configuring portfast on each port instead of globally 'spanning-tree portfast default'?
5. What is the egress port for this switch? A Gig port or just other copper ports? Where does this traffic go from these copper ports? What is the config on the uplink or downlink ports? If this is the only switch involved in your test than you are definitely creating an interesting test environment in which your policer is policing inbound traffic and each port is 'queue shaping' outbound traffic. I would suggest one or the other and configure what is appropriate for what you need rather than configuring what looks like everything and trying to find out what works. I've been down this road, you will never get it exactly the way you want it.
6. Why on earth are the burst parameters so high on your config example? In most cases you should just configure the average and have the switch determine the appropriate burst values.
7. Why are you using access-lists for matching voice traffic? Your ACL matching udp ports from 16384 to 32767 have two huge problems: first, no guarantee that the udp packet is voice (many worms use ports in that range), second RTP traffic only uses even port numbers, not odd, odd port numbers are SRTP signalling packets. I want to be on your network, if I configure my laptop to trunk and send my edonkey traffic on udp port 16999 I will have high priority! At least include the destination ip of the call manager and voice gateways in the ACL to be more restrictive.
8. Why aren't you trusting the end device like an ip phone rather than trying to re-write the IP DSCP value using an ACL? The best practice is that the switch ports be configured (using auto qos or not) to use CDP to allow access to the voice vlan and NOT to use a trunk (the ip phone will tag the voice traffic using dot1q for the voice vlan and the port will never 'trunk'.
9. There are significant restrictions on how you can apply QoS policies to the switch ports on the ASIC based Catalyst platforms, including policing granularity, number of TCAM entries required, number of match statements per class, number of classes, etc.
10. Last, can you provide the IOS version and switch model that you are using?
I will provide some more advise once I understand the above information.
/Rick