class-map match conditions?

[andrew.butterworth]

I am trying to understand what the differences are (or if there are?) between the following class-maps on a Catalyst 2960X:

class-map match-any multimedia-class

 match ip dscp af31 af32 af33

class-map match-any multimedia-class

 match ip dscp af31

 match ip dscp af32

 match ip dscp af33

The CLI lets you enter both and I get the impression from the command syntax that both achieve the same thing?

Andy

[Mark Malone]

Hi Andy

no difference as there both set as match-any and have the same dscp sets , your correct either method will produce the same results

[andrew.butterworth]

Cheers Mark.

OK, so is the processing different in anyway or are there any performance improvements with either class-map?

i.e. with the 1st class-map does the parser look in the packet for af31, af32 or af33 and then if not seen moves on to the next line?  With the 2nd class-map does the parser look for af31 and if not seen moves on to the next line and looks for af32 and if not seen moves onto the next line and looks for af33?

Andy

[acampbell]

Hi Andy, Mark,

I thought the same as you that they were equal.

So I labbed it on my own switch.

When you apply the 2nd method to a policy-map - OK

But when you apply the policy as a service-policy in on an interface it gets blown away

E.g.

class-map match-any multimedia-class
match ip dscp af31
match ip dscp af32
match ip dscp af33
!
policy-map BOB
class multimedia-class
set ip dscp CS3
!
interface fas0/1
service-policy in BOB

Switch(config-if)#
*Mar  1 00:21:27.819: %QOSMGR-4-CLASS_NOT_SUPPORTED: Classification is not supported in classmap BOB
*Mar  1 00:21:27.819: %QOSMGR-4-CLASS_NOT_SUPPORTED: Classification is not supported in classmap BOB
*Mar  1 00:21:27.819: %QOSMGR-4-CLASS_NOT_SUPPORTED: Classification is not supported in classmap BOB
*Mar  1 00:21:27.819: %QOSMGR-4-CLASS_NOT_SUPPORTED: Classification is not supported in classmap BOB
*Mar  1 00:21:27.819: %QOSMGR-4-CLASS_NOT_SUPPORTED: Classification is not supported in classmap BOB
*Mar  1 00:21:27.819: %QOSMGR-4-CLASS_NOT_SUPPORTED: Classification is not supported in classmap BOB

Rewriting as method 1

class-map match-any multimedia-class
match ip dscp af31 af32 af33

No issues

See the notes against the config guide lines

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_2_e/consolidated_guide/configuration_guide/b_1522e_consolidated_2960x_cg/b_consolidated_152ex_2960-X_cg_chapter_011011.html#ID2130

Step 4

match {access-group acl-index-or-name | ip dscp dscp-list | ip precedence ip-precedence-list} Example: Switch(config-cmap)# match ip dscp 10 11 12

Defines the match criterion to classify traffic. By default, no match criterion is defined. Only one match criterion per class map is supported, and only one ACL per class map is supported.

Regards

Alex

[andrew.butterworth]

Cheers everybody.  I think I may be merging some Catalyst 4500-X and 2960X examples here...

Just tested this out on an older 2960-24TT switch and it does exactly what Alex describes.  I must admit I missed the 'Only one match criteria per class map' statement on CCO though.

Thanks

Andy

[Mark Malone]

Hi Alex/Andy and Joseph

that's interesting , I just labbed exactly above on another WS-C2960G-48TC-L didnt have an x series in LAB to test on and I got different limitation , would not even attach the policy to tghhe interface  

QoS: class(multimedia-class) match ip can be used only with match protocol in a match-all class [GigabitEthernet0/1]

so I changed it to match-all and still got the same alert :)

Then I changed it to the other way , it took it as match-all and match-any , so it looks like there's definite limitations there , It would not even apply the service policy in 1st method either way on that particular IOS/platform  

Never seen an issue like this on routers maybe its due to these being switch platforms

good spot Alex

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Not withstanding what Alex found (apparently a limitation on the 2960x), in principal both forms of the class-map should function alike.  Whether they would in practice might depend on the platform and/or IOS version.  With the first variant, it's possible, the matches wouldn't be done in the sequence of the terms on the line (I think this unlikely, though).  With the second variant, statements should be tested in sequence.

A possible example of the subtle difference between the two format variants, if we had:

class-map match-all multimedia-class

 match ip dscp af31 af32 af33

class-map match-all multimedia-class

 match ip dscp af31

 match ip dscp af32

 match ip dscp af33

I think the first variant would still work, but the second variant would always be false.

BTW, for performance, assuming matching CS3 would be valid for this class too (or it's matched earlier), I'll match IP Precedence 3.  (NB: Of course, IPPrec 3 matches non-DSCP values, but as they generally aren't used, it matches what I want.)