Solved: QoS question about shaping everything

John Blakley · ‎04-09-2009

This is a branch off of another post I was trying to help someone with this morning, but I was curious about what I posted:

If I have to shape traffic to 128k only during times of congestion, would creating a class-map to match any traffic and applying it to a policy be sufficient? You can't apply shaping to that rate on the class-default, or it would be shaped all of the time. If this isn't correct, how would someone be able to shape all traffic based when congestion occurs only? (This is all theoretical because I know that you would want to shape only certain types of traffic.)

Thanks,

John

HTH, John *** Please rate all useful posts ***

Edison Ortiz · ‎04-09-2009

If I have to shape traffic to 128k only during times of congestion, would creating a class-map to match any traffic and applying it to a policy be sufficient?

The 'only during congestion' defines a whole new criteria. The default shaping is to limit the traffic up to the amount specified. With that said, you can use shape peak to have a guaranteed throughput during congestion while having a higher throughput during non-congested times.

For instance:

Rack1R1#sh policy-map NETPRO

Policy Map NETPRO

Class class-default

Traffic Shaping

Peak Rate Traffic Shaping

CIR 128000 (bps) Max. Buffers Limit 1000 (Packets)

Rack1R1#sh policy-map int s0/1

Serial0/1

Service-policy output: NETPRO

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

71 packets, 16511 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

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

256000/128000 1984 7936 7936 62 1984

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 49 15983 0 0 no

Rack1R1#

I can shape down to 128kbps during congestion for all traffic while allow to send up to 256kbps during non-congested times.

__

Edison.

View solution in original post

paolo bevilacqua · ‎04-09-2009

Hi, if you think about, isn't really conceivable to shape all traffic based when congestion occurs only

Suppose you have a 256 Kbps circuit. At some point, congestion occurs, queue drops, and in a sort of punitive constraining, you begin shaping all traffic to 128 Kbps.

At that time, the circuit is not congested anymore, because you're using it for half the capacity.

And, you've moved the congestion to the shaping queue, and dropping a lot more packets than if you had not.

Worst, how would you now detect when congestion ends ? Just waiting that sources desist from sending, having noticed how poor the circuit is ?

So, nothing good here.

But, if you meant something else, feel free to explain again.

Edison Ortiz · ‎04-09-2009

If I have to shape traffic to 128k only during times of congestion, would creating a class-map to match any traffic and applying it to a policy be sufficient?

The 'only during congestion' defines a whole new criteria. The default shaping is to limit the traffic up to the amount specified. With that said, you can use shape peak to have a guaranteed throughput during congestion while having a higher throughput during non-congested times.

For instance:

Rack1R1#sh policy-map NETPRO

Policy Map NETPRO

Class class-default

Traffic Shaping

Peak Rate Traffic Shaping

CIR 128000 (bps) Max. Buffers Limit 1000 (Packets)

Rack1R1#sh policy-map int s0/1

Serial0/1

Service-policy output: NETPRO

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

71 packets, 16511 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

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

256000/128000 1984 7936 7936 62 1984

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 49 15983 0 0 no

Rack1R1#

I can shape down to 128kbps during congestion for all traffic while allow to send up to 256kbps during non-congested times.

__

Edison.

Joseph W. Doherty · ‎04-09-2009

The only QoS that comes to mind that provides something close to what you're describing would be a form of adaptive shaping based on a congestion indication within frame-relay. For instance, frame-relay BECNs can cause a generic traffic shaper to adjust its shaped bandwidth allocation.

e.g.

traffic-shape rate ### !(link speed)

traffic-shape adaptive 128000

traffic-shape fecn-adapt