6500 QOS (again !!)

[Jon Marshall]

Couple of questions about 6500 aggregate policing I could do with some help with as QOS not my strongest suite - 

1)  I asked a while back about using the same policy map applied to multiple vlans with "mls qos vlan-based" applied and whether this meant the bandwidth in the policy map was shared between all vlans or each vlan got that bandwidth.  Joe kindly answered and said it was per vlan which is what I thought as well. 

However on investigating another issue I came across an excerpt from a document which contradicts that  - 

"As an example, if you configure a microflow policer to limit the TFTP traffic to 1 Mbps on VLAN 1 and VLAN 3, then 1 Mbps is allowed for each flow in VLAN 1 and 1 Mbps for each flow in VLAN 3. In other words, if there are three flows in VLAN 1 and four flows in VLAN 3, the microflow policer allows each of these flows 1 Mbps. If you configure an aggregate policer, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN 3 to 1 Mbps."

Full document - 

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/12493-102.html

So it seems to be saying that for aggregate policing if you want a per vlan based policer for the same bandwdith you need to use a different policy map name per SVI.

Could anyone confirm one way or the other ?

2) Hopefully an easier one. We have an aggregate policier applied to an SVI (mls qos vlan-based on physical ports) and the policy map is unique for this policer so not related to question 1.

The following output - 

xxxxxxxxxx#sh policy-map int vlan 480

Vlan480

Service-policy input: 300mbps

class-map: ALL.IPS.TCP.UDP (match-all)
Match: access-group name ALL.IPS.TCP.UDP
police :
300000000 bps 9375000 limit 9375000 extended limit
Earl in slot 5 :
15216340194688 bytes
5 minute offered rate 275938192 bps
aggregate-forwarded 15182445522858 bytes action: transmit
exceeded 33894671830 bytes action: drop
aggregate-forward 303086608 bps exceed 15847064 bps

Class-map: class-default (match-any)
163 packets, 12746 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
163 packets, 12746 bytes
5 minute rate 0 bps

Why am I getting drops when the 5 minute offered rate is less than the configured policed rate. 

Thanks 

Jon

[Joseph W. Doherty]

Hey Jon, it wouldn't be the first time I've been mistaken, but the statement you quote " If you configure an aggregate policer, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN 3 to 1 Mbps." might be meant to be read that both (the and) VLANs 1 and 3 are each limited to 1 Mbps, not that their combination of traffic, together, is limited to 1 Mbps. Unless someone knows for sure, perhaps the only way you can be sure is to test it.

As for your second question, the most likely reason is policing generally happens at the millisecond level, while your stats are often a multi-minute average. I.e. You can have a few milliseconds of a burst of traffic that will trigger a policer to drop traffic but a multi-minute traffic rate average won't show this.

[Jon Marshall]

Hi Joe 

Yes it could be read like that, that is the problem :) 

Would be nice to get a definitive answer from someone one way or the other or simply use a different policy map name per SVI which would solve the problem but doesn't help with an existing setup ! 

If I get time to test I will and get back to you. 

As to second question so from your experience is there a way to account for this in your policies to make your policies more accurate or do you just have to live with it on this specific SVI we have 300 Mbps in and out and our PRTG graphs never show the traffic rate exceeding the allowed police rate but we are still dropping packets. 

Jon

[Joseph W. Doherty]

It should be fairly simple to test, if you have a couple of hosts with a traffic generator. Set two new VLANs (each with just one port) with the same VLAN based policy with a low rate limit. Then see if you can drive both to the limit or only the aggregate. (I no longer have access to the equipment to try this myself.)

The stats are usually accurate, they are just on much different time scales. If you place both on the same time scale, they should then agree, but that's not practical. (I.e. the latter could have the too frequent polling and/or a too large policed [Tc] interval.) So, unfortunately, you need to live with both, as they are.

What you might look at, is whether your policer's parameters are optimal for your requirements. Sometimes they are set too restrictive (often by default) and a policer drops packets/frames before a like interface of the same bandwidth would. Also unfortunately, policers "count" bits while interfaces "count"packets/frames so it's can be difficult to get a policer to behave like an actual interface. (What you goal can be is to get your policer's Bc to pass the same amount of bits as a like interface would queue for the same time interval. Then it should start to drop, as would the like interface.)

[Jon Marshall]

Joe 

Just to clarify no criticism intended with initial question, as you can see I am fairly clueless about QOS :) 

Jon