Solved: QOS at Distribution Layer

babatunde_sanda · ‎01-29-2009

At the head office, I have four 6500 switches separated by a firewall. Two 6500 for each VTP domain providing redundancy with HSRP for all VLAN's. On one of the domains I have Cisco Call Manager providing voice services for all the segments. On one of the domains all remote sites terminate into one of the 6500 via a DS3 --- Flex module each using a T1 connection (Total number of 25 remote sites that I have discovered for now). I reclassified voice traffic using the below commands for all the remote sites (everything was best effort before I got in 3 months ago).

class-map match-all rtp-voice

match access-group 100

policy-map VoIP-QoS

class rtp-voice

priority percent 40

class class-default

fair-queue

access-list 100 permit ip any any dscp ef

access-list 100 permit udp any any range 16384 32767

access-list 100 permit ip any any precedence critical

I was thinking about using NBAR for the head office with the below commands.

class-map match-any C-VOICE

description VoIP TRAFFIC

match protocol rtp audio

policy-map P-VOICE

class C-VOICE

priority percent 40

Class class-default

fair-queue

service-policy output P-VOICE

and applying it on all my serials and Multilinks interfaces.

Here is my question/concern. With the amount of traffic that passes through those 6500, does anyone think I might end up creating a bottleneck at this distribution layer? Let me put it this way. Would you classify traffic on the 6500's using NBAR? I uderstand NBAR can be processor intensive.

Joseph W. Doherty · ‎01-29-2009

I like to use NBAR, where possible. Besides it being able to look just beyond port numbers, in some cases, I think it makes the config easier to understand.

However, I also like to assure special treatment for just the intended traffic. Nothing says you can not use NBAR and an ACL or multiple NBAR conditions. A class map using match-ALL vs. match-ANY can sometimes help here.

e.g. (NB: syntax might be incorrect)

class-map match-all CiscoVoIP

match ip dscpEF

match protocol rtp audio

The prior examples looks for audio with an EF marking, like from a Cisco phone, so only it should get special treatment. This doesn't preclude other hosts from sending similar looking traffic, but might avoid some. The book approach would be for the edge to validate and allow EF only from Cisco phones.

However, if you're pretty certain other traffic wouldn't be a concern, I might just go ahead and do what you're thinking too.

PS:

BTW: don't forget the signally component.

View solution in original post

Joseph W. Doherty · ‎01-29-2009

NBAR on a 6500, I believe, isn't possible without special hardware such as the FlexWAN I understand you're using. Since, I also believe, NBAR's impact would be limited to just the card, and it supports it, I wouldn't be too concerned about using it with regard to its performance impact. More of a concern would be that NBAR is matching just the traffic you want it to match. Class maps to test that might be:

class-map match-any VoIPtest1

match protocol rtp audio

match access-group 100

class-map match-any VoIPtest2

match access-group 100

match protocol rtp audio

Try each. Check stats to see if there are any matches against the 2nd match statement.

babatunde_sanda · ‎01-29-2009

Thanks for the input. I actually just want to match it to the rtp audio.

You know NBAR inspects at Application layer so using "match-any protocol rtp audio" should take care of just voice traffic. I don't think I will need to specify port range nor dscp or ip precedence in an ACL again. I know i will get hits I was just trying to weight the impact during production. After the posting I concluded I will enable it very early in the morning so I can deal with the impact immediately if any.

Thank for the imput though I appreciate it.

class-map match-any C-VOICE

description VoIP TRAFFIC

match protocol rtp audio

policy-map P-VOICE

class C-VOICE

priority percent 40

Class class-default

fair-queue

service-policy output P-VOICE

Joseph W. Doherty · ‎01-29-2009

"I actually just want to match it to the rtp audio."

That's one of my points. I.e. are you sure you do?

My two test class maps weren't to test performance, or for permanent usage, but for watching for "leakers", to determine whether you're matching the traffic you really want.

I've used NBAR rtp audio, and I think I recalled it matched more audio then we wanted to prioritze. I.e. user installed applications passing audio contending with VoIP phones.

As to impact on a 6500, I've only lab'ed it on a 6500 FlexWAN and SIP200, but in general NBAR performance hit on other equipment doesn't seem excessive. Much of the performance hit would likely also depend, I would expect, on how deep the analysis must be for a certain NBAR protocol. Some is just a pretty face on a port ACL, some is stateful, some digs into the application (like HTTP URL stuff), etc.

babatunde_sanda · ‎01-29-2009

I totally agree with you. I thought of that, that was why I thought using NBAR might help more than using port ranges. Becuase those well known port ranges can be masked by another application as well. Well I guess the aguement goes both ways. Currentlly on my network I would say the cisco IP phones rtp packets is the buck of voice traffic I have. Not to say websites with audio streaming too are not there but we have a web filtering device denying access to certain site well known for audio / video streaming.

Ok. From your professional stand point what will you use to classify cisco voice traffic. Forget all my previous configs. Just something for voice only on a network where you have CCM like my previous.

Thanks.

Joseph W. Doherty · ‎01-29-2009

I like to use NBAR, where possible. Besides it being able to look just beyond port numbers, in some cases, I think it makes the config easier to understand.

However, I also like to assure special treatment for just the intended traffic. Nothing says you can not use NBAR and an ACL or multiple NBAR conditions. A class map using match-ALL vs. match-ANY can sometimes help here.

e.g. (NB: syntax might be incorrect)

class-map match-all CiscoVoIP

match ip dscpEF

match protocol rtp audio

The prior examples looks for audio with an EF marking, like from a Cisco phone, so only it should get special treatment. This doesn't preclude other hosts from sending similar looking traffic, but might avoid some. The book approach would be for the edge to validate and allow EF only from Cisco phones.

However, if you're pretty certain other traffic wouldn't be a concern, I might just go ahead and do what you're thinking too.

PS:

BTW: don't forget the signally component.