Need some help with QoS on 3750x for VOIP implementation

[lcipriani]

I'm hoping someone can point me in the right direction. 

We are going to be expanding our Shoretel phone system in our HQ and I need to get QoS configured correctly.  All of our offices are connected via MPLS and I need to make sure that we are sending QoS tagged traffic to our provider.  The phones are tagged by the director, but there is other traffic for call control that needs to be tagged.  I don't have access to our CPE router as it is managed by Sprint.  The Sprint router is connected to our internal network.  We have our data network running on (4) 3750x switches running 12.2(55) with IP feature set.

All of the documentation I've found contains information similar to what's below.  The problem is that many of these commands don't work on the 3750 (priority, bandwidth, match protocol, etc...) and the configuration assumes you are applying this to an outbound queue which is not supported on the 3750.  I think I have to do this with policing, but I'm not sure what interfaces need to have this applied.  

I have very little experience with QoS and appreciate any help you guys can give me. 

Thanks.

[paul driver]

Hello

can you post what the traffic you wish to mark and then we can supply a qos config - do you wish to rate limit?


res
paul


Sent from Cisco Technical Support Android App

[Kevin-John Beasley · Accepted solution]

Yeah a lot of that config is based on cisco routers that support more advanced features like NBAR (which is why you can't use the "match protocol" commands). However from what is described you don't need anything too fancy, you should be able to match and mark traffic on your 3750X switches.

I'd take a look at and apply the Cisco Validated Design config that is in here:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/qoscampuscat3xxxaag.html

Basically if you trust dscp towards your CPE and have priority-queue out on all ports you should be fine. Since you are not using Cisco IP Phones but I assume they do mark some of their traffic anyway, you may have to trust DSCP or COS towards the phone ports as well.

That solves half your problem. The other half is matching traffic. There is some good basic config for doing this here:

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSCampus_40.html#wp1098671

Under Per-Port marking model.Youd should be able to adjust or add to the SIGNALING ACL to mark the TCP/UDP ports mentioned above. Just be careful if you want those other ACL's in there or not, sometimes the cisco guys go a bit crazy when they get told to write QOS and come up with markings that some people disagree with. If you don't want to get too fancy mark the stuff you need (signalling) and let everything else drop into the default best-effort class by deleating all the other ACL's and class-maps that you don't need, just leaving the default.

Once you do all that as long as your CPE router is set to trust the DSCP markings your 3750's are sending to it there should be no problem. Your signalling traffic should get sent after the Voice packets but before other traffic that is buffered, with some 30% of your bandwidth allocated during congestion to protect it from delay and your ISP will accept the marked traffic and deal with it according to their own QoS policy which should do the same sort of thing, except what % of bandwidth they reserve will be their decision, we let them do their thing, many ISP's have a habit of ignoring customer requests anyway.

[lcipriani]

Kevin,

Thanks.  That helped a lot.  I setup an ACL to mark call setup traffic and Shortel Communicator traffic on certain ports for tcp and udp (as per ShoreTel's documentation) and applied them to the appropriate interface ingress queues.  I am trusting all other dscp values coming from the voice vlan. 

I'm going to hold off on doing any policing or bandwidth allocation in the switch right now.  I want to see if there are any issues first. Sprint is doing a 30% BW allocation for voice on the MPLS WAN (or so they say).

We have a call setup with Sprint in a few days so we can check to see if it's working or not.  Their client portal is pretty neat. We can actually view QoS stats and see if the number of packets tagged is increasing or not.