Solved: using egress policing on SUP720 for sub-rate Metro-E WAN

Eric.Wang · ‎03-25-2009

we have a 500M Metro-E link terminated on the fiber 1G port on SUP720 itself (C6500). The switch sees the link as 1G instead of 500M.

The challenge is how to achieve QoS for VoIP traffic (dscp EF) without feature support of "shaping" on LAN ports. We don't have FlexWAN/SIP/SPA cards.

so I can't do:

1. shaping down to 500M

2. WRR since the port will never see egree queue filled up

Since DSCP marking is configured and we basically have two classes of traffics:

1. dscp 0 for data

2. dscp 46 for voice

I want your views on this "creative" QoS design in place of WRR queuing because the LAN port will never see the congestion at 500M.

Here is my plan:

1. implement egress policing on the LAN port connected to this 500M WAN link

2. police dscp 0 at 450M

3. implicitly IPT dscp 46/EF traffic can have 50M bandwidth when there is congestion on 500M WAN link

is it a valid design?

class-map match-all data

match ip dscp default

policy-map dropdata

class data

police 450000000 800000 800000 conform-action transmit exceed-action drop

int g5/1

desc 500M WAN link

switchport

service-policy output dropdata

Joseph W. Doherty · ‎04-01-2009

If I recall correctly, the general recommendation is to keep within 150 ms, so you might start with a Tc of 50 ms or less.

That should be 280,000,000 b/s * .05 /8 = 1,750,000 bytes.

Also keep in mind, recall shaper/policer doesn't account for Ethernet overhead, so probably should reduce that by about 10 to 15%.

PS:

BTW, the default often may have been 25 ms, not 250 ms (.25 s). 12.4(20)T now uses, I think, a 4 ms default.

View solution in original post

Joseph W. Doherty · ‎03-25-2009

Your basic idea is sound. However, some things you might do to improve upon it.

Match all other traffic, except the traffic you're trying to reserve bandwidth for. This to avoid other non-BE traffic from taking bandwidth intended for your "reserved" marking(s). (I note you say you only have DSCP 0 and 46, but "be prepared".)

I've seen dropping some voice signally packets as bad or worst than the payload packets. I.e., you might want to insure they are not policed.

You may want to only use non-peak policing and decrease the Tc. Otherwise, real-time traffic could be hit by a short term BE burst.

PS:

Another option, instead of a FlexWAN/SIP/SPA card, consider dropping another device between the 6500 and WAN handoff. E.g., 2960G-8TC-L or 3750 Metro Series Switch (base image).

If you're wondering about the 2960G-8TC-L, "srr-queue bandwidth limit 50" would "shape" at about 500 Mbps and "priority-queue out" could be used for your real-time traffic.

Eric.Wang · ‎03-25-2009

Jose:

thanks for the info

how to "use non-peak policing and decrease the Tc"?

what does mean for normal and max burst numbers in term of bytes?

Joseph W. Doherty · ‎03-25-2009

If the police statement doesn't support a "peak" vs. "average" parameter, making the Be value (3rd parm) zero should avoid "peak" policing.

To decrease Tc, just decrease Bc (2nd parm). (Recall reading somewhere[?], you don't want to decrease Bc, in bytes, less than one packet's maximum size.)

adamclarkuk_2 · ‎03-25-2009

Hi

I think it would make more sense to match the VoIP traffic and catch the rest in the class-default.

class-map VoIP

match ip dscp ef

policy-map dropdata

class Voip

police 50000000 conform-action transmit exceed-action drop

class class-default

police 450000000 conform-action transmit exceed-action drop

As this is Voip you my want to adjust the Time inteval by allocating a Bc value as you have done above, the 250ms default my affect your VoIP traffic during heavy usage (4ms being the smallest).

Just in case you didn't know the formula :-

CIR * / 8

So in your case for 0.004ms

50000000 * 0.004 / 8 = 25000 bytes

If you try to go down to 3ms for instance (18750), then it will adjust the value to the closest match which is 4ms.

Eric.Wang · ‎03-26-2009

some people say use MTUx10 as Bc

is it a good estimate?

thanks

Joseph W. Doherty · ‎03-26-2009

Perhaps if you wanted to emulate an interface with a FIFO queue depth of about 10, but in your case, I think trying to keep within the "time budget" for voice would be more critical.

For you, your might first try the default, and if you have VoIP quality problems, then try tuning the Bc (and Tc) down.

Eric.Wang · ‎04-01-2009

last question:

if I decide only to police data dscp 0 at 280MB out of 300MB bandwidth, NOT police voice, IPT sigaling, etc...

for class-map data, what is the ideal Tc?

default is 0.25 second. should I make it 0.01 sec then Bc=350,000 bytes?

thanks a lot!

Joseph W. Doherty · ‎04-01-2009

If I recall correctly, the general recommendation is to keep within 150 ms, so you might start with a Tc of 50 ms or less.

That should be 280,000,000 b/s * .05 /8 = 1,750,000 bytes.

Also keep in mind, recall shaper/policer doesn't account for Ethernet overhead, so probably should reduce that by about 10 to 15%.

PS:

BTW, the default often may have been 25 ms, not 250 ms (.25 s). 12.4(20)T now uses, I think, a 4 ms default.