yes I have concerns. I ahve entries in my policy

match protocol sql server

match access-group name test

and access list looks like this

ip access-list extended test
permit tcp any any eq 1433
permit tcp any eq 1433 any
!

when I make show policy-map on interface, I can see matches for both entries. How is it possible if nbar is catching all sqlserver traffic? IOS is 12.4.15.T7

It's an expected behavior, please note that this is not workin as an ACL or a route-map, that if one matches the rest ones are not considered.

For your setup, you only need to have one of those statements, you can remove the ACL.

or if you want to check how it works, you can leave both of them and use a match any, so it will work if traffics matches either the first match or the second match.

how the router evaluteas this, depends on the match any or match all command used.

but if traffic matches nbar, and matches the ACL at the same time, you will see matches in both statements.

the same will happen with other match commands.

If the traffic class contains more than one match command, you need to specify how to evaluate the match commands. You specify this by using either the match-any or match-all keywords of the class-map command. Note the following points about the match-any and match-all keywords:

•If you specify the match-any keyword, the traffic being evaluated by the traffic class must match one of the specified criteria.

•If you specify the match-all keyword, the traffic being evaluated by the traffic class must match all of the specified criteria.

•If you do not specify either keyword, the traffic being evaluated by the traffic class must match all of the specified criteria (that is, the behavior of the match-all keyword is used).

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/qos_mqc.html#wp1042857

well, if you say so. By having both of this statements I was just trying to see if match protocol statement catch sql or not. Real problem is that return sql traffic from server to client is not classified correctlly (netflow export show that this traffic is not marked). So mybe nbar does not catch return traffic, mybe netflow export does not show true, mybe it is som kind of bug in ios, but it is strange

Hello Dragan,

>> If I use match protocol sqlserver on my policy in out direction

but have you got SQL servers on both sides of the link or they are only on one side?

>> Real problem is that return sql traffic from server to client is not classified correctlly (netflow export show that this traffic is not marked)

you may need to configure QoS on the other side or you need two policy maps one oubound and one inbound, if you have a policy in outbound it can process only packets exiting that link/interface regardless that you are using NBAR or an extended ACLs.

However, if you are able to classify traffic using extended ACLs I would consider to use only them for efficiency reasons.

Hope to help

Giuseppe

I am using match-any, and another experiment (another access list with similar traffic, and this is last entry and not get hits) shows that it is not true that router goes through

all statements. Also I have sql server on one side and correctly configured policies

yes, match any as explained before, needs to match only one of the entries.

Match-all class-map, requires matching all the criteria defined in the class map, so in this case the order does not matter, since you need to match every match
statement in the class {AND operation on the individual match statements}. However, with match-any class-map, the expected behavior to
be different, because the packet is compared against each individual match statement in sequence, until the first match occurs and would not have to match everything specified for your classification criteria. So, in the case of match-any, the order would matter.