QOS - Policing - Shaping question?

Unanswered Question
Mar 19th, 2009


I have a fault at the moment ongoing. Symptoms are low TCP throughput but UDP/Ping tests are okay. On the PE front, there is a traffic-shaping policy applied outbound and policing inbound. I have 2 questions though:-

1. The policy-map applied inbound which is configured to police is onlyl givening 8000bits to the default traffic but 776000 to the mgmt traffic(the customer is meant to be receiving 80meg) - surely these values are the wrong way around particularly as the mgmt class only matches traffic with dscp value of 63 so all other traffic will hit the default queue. 2nd question is that when I look at the policy-map on the PE , I can see traffic shaping is consistently active but at this is the odd thing, I am not seeing this reflected on the Physical interface.

Am I correct in my assumption that the values for the policing inbound policy-map pe_in_child_XXX_hub are incorrect ie. too small for the default and too big for the mgmt class?

I would post the configs but can't see an upload button...so here is the bits I am worried about...

policy-map BANKOFIRE-IN-F6/1/2

description PE_10000_Ethernet_PDSCP_60_152p4_FLANAGJ2_12:14_04/10/07_ivserveplus:231626_BANKOFIRE

class pe_mgmt_unb_input

police 760000 27500 55000 conform-action set-mpls-exp-transmit 6 exceed-action set-mpls-exp-transmit 2 violate-action set-mpls-exp-transmit 2

class class-default

police 8000 8000 8000 conform-action set-mpls-exp-transmit 5 exceed-action set-mpls-exp-transmit 5 violate-action set-mpls-exp-transmit 5

set ip dscp default

Service-policy output: pe_out_parent_xxx_hub

Class-map: class-default (match-any)

157816193 packets, 68996467859 bytes

5 minute offered rate 8962000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

81600000/81600000 510000 2040000 2040000 25 255000

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 1 0 0 0 0 yes



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joseph W. Doherty Thu, 03/19/2009 - 07:23

For #1, what's odd about both policer statements, if I understand them correctly, neither drops any packets, all packets are marked the same regardless of actual data rate.

I haven't worked with actual MPLS, maybe you can't directly set set-mpls-exp-transmit without using the policer.

Personally, I wouldn't be too happy with "set ip dscp default" if that is resetting my DSCP markings.

For #2, the shaper appears to be configured for about 80 Mbps, but the 5 minute (average) rate is only about 9 Mbps. It's possible, since shapers queue bursts, for the shaper to be active from time to time although the average data rate is so low.


A very common cause of poor TCP throughput is dropped packets which ping tests might not see (unless the drops are really bad). Try to investigate whether you're encountering TCP drops.



Another reason for poor TCP throughput, if your WAN has high bandwidth, e.g. 80 Mbps, but typical WAN latencies, many TCP stacks, default receive buffer, won't allow a single flow to ramp up. For instance, Windows XP clients connected to 100 Mbps, might not utilize more than 2 Mbps on a coast-to-coast jump.

If you run multiple TCP flows from the same host, and aggregate bandwidth jumps with each flow, you're likely seeing the issue just described.

Or, if you use a differnet host, e.g. Windows Vista (as receiver or better host to host), and again a bandwidth jump, same issue.

Also note, even when TCP can utilize full link bandwidth, high WAN latency will slow how fast TCP ramps up and how fast it recovers bandwidth if it sees a drop. Both of these can be very noticable on international links, even with much bandwidth.


This Discussion