Inbound Qos on 6509 not working

[Nick Cutting]

6509 - Not working

1    6  Firewall Module                     

2    8  Intrusion Detection System          

3    1  Application Control Engine Module   

4   16  CEF720 16 port 10GE                 

5    2  Supervisor Engine 720 (Active)      

6   16  CEF720 16 port 10GE                 

7   48  CEF720 48 port 10/100/1000mb Ethernet

8   48  CEF720 48 port 10/100/1000mb Ethernet

9   48  CEF720 48 port 10/100/1000mb Ethernet

4.3   7.2(1)       4.1(3)       Ok

6.4   7.2(1)       6.1(1)E2     Ok

2.6   ace2t_main_d A2(3.4)      Ok

1.0   12.2(18r)S1  12.2(33)SXI  Ok

5.6   8.5(2)       12.2(33)SXI  Ok

1.0   12.2(18r)S1  12.2(33)SXI  Ok

2.7   12.2(14r)S5  12.2(33)SXI  Ok

2.7   12.2(14r)S5  12.2(33)SXI  Ok

2.7   12.2(14r)S5  12.2(33)SXI  Ok

2  IDS 2 accelerator board     WS-SVC-IDSUPG  

4  Distributed Forwarding Card WS-F6700-DFC3C 

5  Policy Feature Card 3       WS-F6K-PFC3B   

5  MSFC3 Daughterboard         WS-SUP720      

6  Distributed Forwarding Card WS-F6700-DFC3C 

7  Centralized Forwarding Card WS-F6700-CFC   

8  Centralized Forwarding Card WS-F6700-CFC   

9  Centralized Forwarding Card WS-F6700-CFC   

I cannot get Inbound Qos to work on a Vlan Interface that is connected logically to a FWSM context.

The same simple config works in GNS3 (albeit on 3400's + ASA) and it also works on a 6509 with slightly different software versions on one of the Sup Modules.  see below:

Module

4  Distributed Forwarding Card WS-F6700-DFC3C     SALxxxxxxxx  1.0    Ok

4  Distributed Forwarding Card WS-F6700-DFC3C     SALxxxxxxxx  1.1    Ok <- Other working 6509

The config is pretty standard

Policy Map Limit

    Class class_subnet1

     police cir 104857500 bc 3276796 be 3276796

       conform-action transmit

       exceed-action drop

       violate-action drop

Class Map match-any class_subnet1 (id 1)

   Match access-group name acl_subnet1

Extended IP access list acl_subnet1

    10 permit ip 10.0.0.0 0.0.0.3 any

applied to interface vlan671

interface Vlan671

ip address 10.141.21.194 255.255.255.240

service-policy input Limit_subnet1

end

sh policy-map int vlan671

Vlan671

  Service-policy input: Limit_subnet1

    class-map: class_subnet1 (match-any)

      Match: access-group name acl_subnet1

      police :

        104856000 bps 3276796 limit 3276796 extended limit

      Earl in slot 4 :

        0 bytes

        5 minute offered rate 0 bps

        aggregate-forwarded 0 bytes action: transmit

        exceeded 0 bytes action: drop

        aggregate-forward 0 bps exceed 0 bps

      Earl in slot 5 :

        0 bytes

        5 minute offered rate 0 bps

        aggregate-forwarded 0 bytes action: transmit

        exceeded 0 bytes action: drop

        aggregate-forward 0 bps exceed 0 bps

      Earl in slot 6 :

        0 bytes

        5 minute offered rate 0 bps

        aggregate-forwarded 0 bytes action: transmit

        exceeded 0 bytes action: drop

        aggregate-forward 0 bps exceed 0 bps

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

      0 packets, 0 bytes

      5 minute offered rate 0000 bps, drop rate 0000 bps

      Match: any

        0 packets, 0 bytes

        5 minute rate 0 bps

The Policy applied to the interface is just completely ignoring the configuration.

Any ideas?

I am sure it is related to the 6500 architecture in some way.

Same config is fine on the switch with the higher version on the sup card.

[acampbell]

Hi,

Are you sure about your access list

Extended IP access list acl_subnet1

10 permit ip 10.0.0.0 0.0.0.3 any

That will allow packets from

10.0.0.1 & 10.0.0.2 to any address

Every thing else is ignored on your class map

Regards,
Alex.
Please rate useful posts.

[Nick Cutting]

Thank you for your reply -

That access list is a subset/example of the 25 class maps and ACL's that are in the real policy map.  The class default should be seeing traffic anyway.  There is alot of traffic that is not covered by the acl's in the class maps that should hit the class-default and be passed.  As you can see there is zero bytes on both defined class maps and the default..  The 6500 is just ignoring the service-policy that has been applied.

but you are correct in that I have the mask wrong on some of my subnets as they are /29 and /28s  I need to change them to 0.0.0.7 and 0.0.0.15

Although this is not the problem, it is a step closer to the solution once the real problem is discovered

[Nick Cutting]

No one has faced this issue?

The different versions on the modules are for 10gig modules