Policong appears not to work on 2950?

[wsanders1]

I am trying to limit traffic on a gigabit interface using policing. IOS version is 12.1(19)EA1c. The simplest configuration is:

policy-map Limit-Net
class class-default
police 12000000 65536 exceed-action drop
...
interface GigabitEthernet0/1
service-policy input Limit-Net

I see no reduction in traffic, either in the output of "show int Gi0/1" or in MRTG graphs for the interface.

Is this supposed to work? If policing limits the traffic, do the effects show up in the counters?

I have also tried this more complex configuration, to the same zero effect. What I am trying to do is limit traffic coming in on this Gi interface to about 1/2 the capacity of a T3 that is further "downstream", while still allowing traffic at full capacity to our local campus:

class-map match-all Internal-traffic
match access-group 102

policy-map Limit-Net
class Internal-traffic
police 1000000000 524288 exceed-action dscp 0
! exceed-action dscp 0 is default when no actions are specified.
! No traffic should exceed this limit anyway
class class-default
police 12000000 65536 exceed-action drop

interface GigabitEthernet0/1
...
service-policy input Limit-Net

! These are my internal IP addresses
access-list 102 permit ip 149.137.0.0 0.0.255.255 149.137.0.0 0.0.255.255

Thanks, any help is appreciated.

 

[wsanders1]

It appears to be impossible to do what I need to do. First - the class "class-default" never matches any packets according to the fine print in the documentation.

Next, you cannot use deny ACEs in class-maps.

Finally, you cannot combine two different ACL-based class entries in a policy-map unless the ACLs are the same, you receive either one of these errors:

%Error:Class-map has a different mask than the
Policymap

%Error:Class-maps have a mix of System Defined
and User Defined masks within the Policymap

You would think that a configuration like:

access-list 101 permit ip 149.137.0.0 0.0.255.255 0.0.0.0 255.255.255.255
access-list 102 permit ip 149.137.0.0 0.0.255.255 149.137.0.0 0.0.255.255
class-map match-all Internal-traffic
match access-group 102
class-map match-all External-traffic
match access-group 101
policy-map Limit-Net
class Internal-traffic
police 1000000000 524288 exceed-action dscp 0
class External-traffic
police 24000000 65536 exceed-action drop

Woudl work, but it is not allowed. So policing is really only useful for controlling *all* traffic on an interface, at least on a 2950, unless you are manipulating DSCP values.

 

[ADB100]

There are restrictions with QoS on the EMI 2950's...

- The range keyword cannot be used in the ACLs being referenced by the class-maps; server-ports should be explicitly defined with a separate access list entry (ACE) per TCP/UDP port.

- User-defined masks must be consistent for all ACLs being referenced by class maps (if filtering is being done against TCP/UDP ports, then all Access Control Entries (ACEs) should be set to filter by TCP/UDP ports, as opposed to some ACEs filtering by ports and others by subnet or host addresses).

- System-defined masks (such as permit ip any any) cannot be used in conjunction with user-defined masks (such as permit tcp any any eq 3200) within the same policy map; therefore, if some traffic is being matched against TCP/UDP ports, then a final ACL cannot be used to match all other traffic via a permit ip any any statement).

- The Catalyst 2950 IOS implementation of MQC’s class-default does not (at the time of writing) function compatibly with mainline IOS; class-default should apply a policy to all other traffic not explicitly defined, but testing has shown that this is not the case.

Taken from the QoS SRND version 3.3.

The ACL's you have listed therefore aren't compatible with the QoS implementation on the 2950. I think your best option would be to upgrade to a platform that offers what you need - 2960 for layer-2 or 3560/3750 for layer-2/3.

Andy