QoS - is ACL allowed to be matched in MQC?

huangedmc · ‎04-10-2010

I'm trying to match LWAPP/CAPWAP traffic, so that it's classified as critical traffic for our outbound QoS policy that's applied on the CE WAN router.

There are hits on ACL, but when I look at "show policy-map interface", stats is zero.

So my question is if matching ACL along w/ DSCP is a valid configuration within MQC?

ip access-list extended LWAPP
permit udp any any eq 12223
permit udp any any eq 5246
permit udp any eq 12223 any
permit udp any eq 5246 any

class-map match-any missioncritical
match ip dscp cs3 af31 af32 af33 cs6 cs7
match access-group name LWAPP

policy-map CHILD-POLICY
class realtime
    priority 2048
    police 2048000 conform-action transmit exceed-action drop
class priority
    bandwidth remaining percent 30
     random-detect dscp-based
class missioncritical
    bandwidth remaining percent 20
     random-detect dscp-based
class transactional
    bandwidth remaining percent 20
     random-detect dscp-based
class general
    bandwidth remaining percent 10
     random-detect dscp-based
class class-default
    bandwidth remaining percent 20
     random-detect dscp-based
policy-map PARENT-POLICY
class class-default
    shape average 8500000
service-policy CHILD-POLICY

interface FastEthernet0/0/0.2

service-policy output PARENT-POLICY

Router#sh access-list LWAPP
Extended IP access list LWAPP
    10 permit udp any any eq 12223 (3837 matches)
    20 permit udp any any eq 5246
    30 permit udp any eq 12223 any (466137 matches)
    40 permit udp any eq 5246 any (14184 matches)

Router#show policy-map int fa0/0/0.2
FastEthernet0/0/0.2

...

    Class-map: missioncritical (match-any)
          2610146 packets, 811329309 bytes
          30 second offered rate 11000 bps, drop rate 0 bps
          Match: ip dscp cs3 (24) af31 (26) af32 (28) af33 (30) cs6 (48) cs7 (56)
            2124221 packets, 330567230 bytes
            30 second rate 0 bps
          Match: access-group name LWAPP
           0 packets, 0 bytes
            30 second rate 0 bps

...

Giuseppe Larosa · ‎04-11-2010

Hello Huangedmc,

>> So my question is if matching ACL along w/ DSCP is a valid configuration within MQC?

your configuration is correct because you have used match-any in defining the class-map.

The question can be: are you using any form of tunneling and/or encryption on the WAN interface that could hide the traffic flows?

DSCP settings are propagated to external headers both for GRE and IPSec so it is possible to match on them even if you are using tunnels and/or IPSec.

Another possible hint is: if the LWAPP packets are marked with a DSCP value matched by first match for the match-any directive there is no need to have them processed by second match statement to be classified in this traffic class.

Hope to help

Giuseppe

huangedmc · ‎04-12-2010

Thanks for the response.

No, we are not doing encryption / IPSec, or GRE on the CE, but you had a good point about matching DSCP before ACL.

I changed the order, so that the ACL comes first:

class-map match-any missioncritical
match access-group name LWAPP
match ip dscp cs3 af31 af32 af33 cs6 cs7

Now both class-maps have zero packets:

        Class-map: missioncritical (match-any)
          3507010 packets, 942960979 bytes
          30 second offered rate 14000 bps, drop rate 0 bps
          Match: access-group name LWAPP
            0 packets, 0 bytes
            30 second rate 0 bps
          Match: ip dscp cs3 (24) af31 (26) af32 (28) af33 (30) cs6 (48) cs7 (56)
            0 packets, 0 bytes
            30 second rate 0 bps

Do you know if there would be matches only if congestion is experienced on the interface?

Wouldn't QoS only kick in when there's congestion, like when the interface hardware queue is full?

Giuseppe Larosa · ‎04-12-2010

Hello Huangedmc,

>> Do you know if there would be matches only if congestion is experienced on the interface?

counters should be updated even when congestion is not present, I've seen this behaviour on several platforms including C7200, C7500, and other ones.

Actually this is a way to know traffic per traffic class over time.

What you see is strange, what device is this and what IOS image is running on it?

Hope to help

Giuseppe

huangedmc · ‎04-12-2010

This is a 2821 running 12.4(24)T1, ADVIPSERVICESK9.

The circuit is terminated on a fast ethernet HWIC card (fa0/0/0).

It's physically provisioned as 100M/full, but the actual circuit rate is 10M.

Even though the stats are zero under each class, the class-map itself shows some matching traffic however:

Class-map: missioncritical (match-any)
3507010 packets, 942960979 bytes
30 second offered rate 14000 bps, drop rate 0 bps

          Match: access-group name LWAPP
            0 packets, 0 bytes
            30 second rate 0 bps
          Match: ip dscp cs3 (24) af31 (26) af32 (28) af33 (30) cs6 (48) cs7 (56)
            0 packets, 0 bytes
            30 second rate 0 bps

==

I checked on the 7206VXR, also running 12.4(24)T1, ADVIPSERVICESK9 at our head-end.

Stats are non-zero under this class.

However, we have not configured the second matching statement (against ACL) on this router yet, so it's not exactly apples to apples.

        Class-map: missioncritical (match-any)
          124339798 packets, 55580257642 bytes
          5 minute offered rate 24000 bps, drop rate 0 bps
          Match: ip dscp cs3 (24) af31 (26) af32 (28) af33 (30) cs6 (48) cs7 (56)
            124339799 packets, 55580257642 bytes
            5 minute rate 24000 bps

==

Edit:

Before we added the second matching statement against the ACL, I'm pretty sure there were matches against the ip dscp match under the class-map.

I just checked on another 2821 running the same IOS code at a different location, and confirmed that's the case:

        Class-map: missioncritical (match-any)
          30838116 packets, 4765524600 bytes
          5 minute offered rate 19000 bps, drop rate 0 bps
          Match: ip dscp cs3 (24) af31 (26) af32 (28) af33 (30) cs6 (48) cs7 (56)
            30838116 packets, 4765524600 bytes
            5 minute rate 19000 bps

Does this mean when there's more than one matching statement, IOS can't tell how many packets are matched under the same class?

Message was edited by: huangedmc