11-29-2010 07:52 AM - edited 03-04-2019 10:36 AM
I have a customer who's outbound interface is a FE interface configured for 100MBs. The actual circuit is only about 11MB download and just barely 1MB upload. The policy map they had configured on their interface wasn't being triggered before the link was saturated due to the big difference in interface line speed and the actual circuit bandwidth. This was causing a problem with their voice services. I since configure a hiearchal policy-map that is shown below. I'm just now trying to verify that its working properly or if I have configure it wrong.
Policy Map Wan-Shaping-1MB-Upload
Class class-default
Traffic Shaping
Average Rate Traffic Shaping
CIR 800000 (bps) Max. Buffers Limit 1000 (Packets)
Bc 8000 Be 0
service-policy WAN-OUTBOUND-PMAP
Policy Map WAN-OUTBOUND-PMAP
Class MATCH-EF-CMAP
Strict Priority
Bandwidth 70 (%)
Class MATCH-CS3-AF31-CMAP
Bandwidth 5 (%) Max Threshold 64 (packets)
Class class-default
Flow based Fair Queueing
Bandwidth 0 (kbps)
exponential weight 9
explicit congestion notification
class min-threshold max-threshold mark-probablity
----------------------------------------------------------
0 - - 1/10
1 - - 1/10
2 - - 1/10
3 - - 1/10
4 - - 1/10
5 - - 1/10
6 - - 1/10
7 - - 1/10
rsvp - - 1/10
The above policy map was added to their WAN port fa4. When I do a sho policy interface fa4, it has consistently shown that shaping is not active (which could just mean that the bandwidth hasn't gotten that high yet) I was just hoping someone could maybe help me confirm prior to them having problems that this would solve what issue they had. I've posted the output of the show policy-map interface fa4 for you to look over. Thanks!
FastEthernet4
Service-policy output: Wan-Shaping-1MB-Upload
Class-map: class-default (match-any)
7961 packets, 925920 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
800000/800000 1000 8000 0 10 1000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 7961 925920 11 4091 no
Service-policy : WAN-OUTBOUND-PMAP
Class-map: MATCH-EF-CMAP (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 70 (%)
Bandwidth 560 (kbps) Burst 14000 (Bytes)
(pkts matched/bytes matched) 0/0
(total drops/bytes drops) 0/0
Class-map: MATCH-CS3-AF31-CMAP (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip dscp af31 (26)
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 73
Bandwidth 5 (%)
Bandwidth 40 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
7961 packets, 925920 bytes
5 minute offered rate 1000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 64
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9
explicit congestion notification
class Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
0 7155/848278 0/0 0/0 20 40 1/10
1 1/60 0/0 0/0 22 40 1/10
2 0/0 0/0 0/0 24 40 1/10
3 0/0 0/0 0/0 26 40 1/10
4 0/0 0/0 0/0 28 40 1/10
5 0/0 0/0 0/0 30 40 1/10
6 394/34960 0/0 0/0 32 40 1/10
7 0/0 0/0 0/0 34 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
class ECN Mark
pkts/bytes
0 0/0
1 0/0
2 0/0
3 0/0
4 0/0
5 0/0
6 0/0
7 0/0
rsvp 0/0
11-29-2010 08:38 AM
You have queued 11 packets which means that the shaper was active but only for a short duration.
The configs looks good and should shape to 800k with no burst capabilites. having shaped to 80% bandwidth is good as well so shaper will get active just before it hits the roof on the upload limits. If the service provider allows an occasional burst you might want to give a Be value based on that.
Shelley.
11-30-2010 01:26 AM
Hi
As mentioned above, it looks good. You can see in the output that at some point there has been traffic that has been shaped.
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 7961 925920 11 4091 no
this show's that 11 packets have been delayed due to traffic exceeds 800000.
It,s a good idea to have the shaper configured slitly below the providers bandwidth to make room for the layer2 overhead, because the shaper doesn't account for the layer2 overhead,
/Mikael
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide