Evaluation order of class-maps under Policy map

[Dean Romanelli]

Hi All,

I have a QOS marking policy configured in my switch. I have not yet applied it, because it kept breaking traffic for my clients when attempting. I've determined that this is because I did not have a final "permit any" ACL called under a final class-map in the policy-map so while the phone was fine, the daisy-chained PC's traffic was getting denied. I am getting ready to configure that, but I just want to confirm that class-maps called under the policy-map are evaluated in a top down fashion, such that the following will do what I want:

ip access-list extended qos_voice_in_from_hosts
permit ip 192.168.154.0 0.0.0.255 8.xx.0.0 0.0.3.255

ip access-list extended qos_signaling_in_from_hosts
permit ip 192.168.154.0 0.0.0.255 8.xx.0.0 0.0.3.255

ip access-list extended rest_best_effort
permit ip any any

class-map QOS-VOICE-IN-FROM-HOSTS
match access-group qos_voice_in_from_hosts

class-map QOS-SIGNALING-IN-FROM-HOSTS
match access-group qos_signaling_in_from_hosts

class-map REST-BEST-EFFORT
match access-group rest_best_effort

policy-map QOS-POLICY-IN-FROM-HOSTS
class QOS-VOICE-IN-FROM-HOSTS
set dscp 46

class QOS-SIGNALING-IN-FROM-HOSTS
set dscp 24

class REST-BEST-EFFORT

int gi9
service-policy input QOS-POLICY-IN-FROM-HOSTS

[AllertGen · Accepted solution]

Hello.

The Policy works as ACL. If the traffic hits firs rule it don't look for a next one. And because your ACLs has the same networks, it allways hit a first rule to change dscp to 46.

Try make a change like this:

class-map match-all QOS-VOICE-IN-FROM-HOSTS
match access-group qos_voice_in_from_hosts

match protocol rtp audio

But it will work only if your switch has a nbar feature. And command "match protocol <type>" is very depends on the nbar version. If you don't have a "rtp audio" you can use a "?" to see all supported protocols.

If your switch don't has it you need to look what else you can use as mach mark for you policy (use a "match ?" at the class-map to see what else you can use as traffic mark).

Best Regards.

[Dean Romanelli]

Thanks very much.

So it sounds like I need to figure out a way to get both dscp 46 and dscp 24 applied under the same class-map if I don't have rtp audio.

[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

Maybe . . .

ip access-list extended qos_voice_in_from_hosts
permit udp 192.168.154.0 0.0.0.255 8.xx.0.0 0.0.3.255

ip access-list extended qos_signaling_in_from_hosts
permit tcp 192.168.154.0 0.0.0.255 8.xx.0.0 0.0.3.255

BTW, from what you've posted, you can:

ip access-list extended rest_best_effort
permit ip any any

class-map REST-BEST-EFFORT

match access-group rest_best_effort

class REST-BEST-EFFORT

[Dean Romanelli]

Hi Joseph,

I'm actually really glad you posted that config with the slashes through them because it gives me a chance to bring something up that no one could answer.  My original config did not include those lines, and when I rolled the config out without the permit any / best effort portion, it actually ended up crashing my entire branch, with the exception of the phones, which still worked, but all data was hosed.  The only thing I can deduce is that even though the ACL is applied as a service policy, it was still acting like an access-group. I actually haven't tested the permit any part yet, but I am assuming that is what I had needed to do.  By the way, this switch is an SG300-28P.

To your other point, I think that suggestion will work great.  Is all voice udp, while all signaling is tcp for sure?

[AllertGen]

Hello.

If you don't have a nbar at you switch, you can make a class with MAC ACL. To create a MAC ACL you can use a command like "mac access-list extended <name>". And use this ACL at the class-map. But if packets reaching your switch via a same router (that works as gateway) it will not help you. At this case it's better to change IP network for phone or PCs.

Best Regards.

[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

I'm not familiar with the SG series, but on ISRs there's always a class-default, whether you define it or not.  Also, by default, on those platforms it doesn't block any traffic.

Generally, VoIP bearer traffic uses UDP and VoIP signally uses TCP.  If the traffic is being generated by a VoIP phone, many can be configure to mark their packets.  If you cannot get them to mark as you desire, you're policy could look for how they are currently marked and remark them.

[Dean Romanelli]

Thanks guys.  Unfortunately the ASA's I've inherited (gateway device at each site) only have a base license, which only allows for two nameif's; inside & outside. So while I completely agree that I should be segmenting VOIP and data onto two separate subnets, I unfortunately don't have the capability to do so. As for the MAC ACL, the sites do use a common gateway device for both types of traffic, so I think I am out of luck with that option too.

Joseph, I believe my provider uses UDP for signaling as well. I will confirm.  Assuming they do use UDP for both, do you think a policy that only marks packets with dscp ef would be enough to prioritize it through the LAN? Or do I absolutely need to tag it with cs3 as well?

[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

VoIP signally usually consume low bandwidth, and you can often "get away" with treating it just like the VoIP bearer traffic.  So, if you cannot distinguish signally from bearer, treating both alike probably won't create any issues.

Regarding marking signally EF rather than CS3, again, see prior paragraph, but how EF or CS3 is actually treated within you LAN, depends on LAN QoS policies.

[Dean Romanelli]

Thanks Joseph.  As always, I appreciate your help.