Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

QoS

Status
Not open for further replies.

RobG2001

MIS
Oct 5, 2001
89
0
0
US
We're considering going to with a VoIP solution using our 6009 switch. How is the QoS set up in real life situations? I'm reading up on the Cisco papers but I'd like to know what's the norm when you have these IP phones where your pc plugs into the phone and then the phone to the switch? TIA
Robert
 
How it should be setup and how I have seen it setup are two different things. QoS should be configured End-toEnd, that is from IP phone to IP Phone (or gateway)and that includes all the equipment in between.

Most configurations I have seen skip the core. Not a good idea.

Use separate VLAN's for Voice and data.

QoS is a fairly involved issue despite what some people think and it will be difficult to explain everything here. Usually these are the people that think it is not required and wonder why their voice quality stinks.

If you want more detailed info just ask.
 
I agree with mtashiro, VoIP and QoS isnt a simple topic that can be explained here. Depending on your environment it may require a simple or complex configuration. For example a friend of mine recently demonstrated VoIP working using a 100mb Hub (no QoS or Vlans etc) and yes there was other traffic on it at the time (stress testing file transfers etc) and the voice quality was fine.

As Mtashiro says, Cisco recommends using separate VLAN's for voice traffic, even separate VLANS for voice control and management traffic. Eg, Phone plugs into switch and PC into phone. PC data traffic over Vlan A, Phone voice data over Vlan B and Phone management over Vlan C.

Using this approach allows the switch to prioritise voice taffic over phone traffic (even on L2 switches using 802.1Q & 802.1P). The big challenge with VoIP is to manage jitter. Voice conversations are sensitive to delay whereas email isnt. It makes sense then to priorities voice packets over email packets.

Also you have to think about your infrastructure setup, eg how much resiliency you have on your data switches/network. Inline power is another consideration.

Lots to read and digest, its all there on CCO if you look for it though ;-)

 
Thanks for the replies and yes I agree 100%. I just wondered if there was a "typical" setup. I understand about setting up aux. VLAN when the PC is plugged into the phone and to prioritize the frames. Do the Mitel phones tag the frame with a priority of 5? If not is some extra stuff on the phones to do? I know I can set the switch to "trust" the QoS coming on the port if I know stuff is being tagged. At the router level I will prioritize the voice at the Packet level. Any suggestions for the router? I can say we have very low data traffic on the LAN and WAN on our private T1s but I want to setup it up right in the beginning even if it's not easy or needed yet. Maybe what I'm looking for is some case studies of how others went about it. It's all new territory for me.
 
I am not sure how the Mitel tags packets. Most manufacturers use either IP Prec. or DSCP. Just make sure that you use end to end QoS and you should be fine.

The router will depend on a few things. Since you have a T1 you shouldn't use anything less than a 2600. The smaller routers are not capable of processing a full T1. I can send you router specs if you need them.

If money isn't an issue go with a 3725 and use IOS 12.2.15T. 12.2.15T has much improved echo cancelation features available.
 
What kind of new echo-cancellation features are there in the new code?


Thanks

BuckWeet
 
I'm bit confused on how a Layer 2 switch could prioritize based on IP Prec or DSCP. I thought they could only do it with CoS using the dot1q bits.

Yes I have a 2600 hundreds at my remoter site and a 3600 router at corp. What is echo cancellation?
 
Your right, L2 switches can only read/mark packets with 802.1Q/P headers. Since they don't read the IP header, they cannot do anything with IP Prec, ToS or DSCP.

Echo cancellation is a feature that minimises feedback on the voice conversation. It cancels out the sound of you own voice coming back over the conversation. Eg sometimes with bad cellphone calls you can hear your own voice repeated after you speak. Echo cancel attempts to supress this.
 
I'm trying to RTFM but it still have more questions:

The echo cancellation seems to be a feature used when the router is the gateway as in NM-HDV type equipment? In my case where I will have an actual IP PBX switch I don't think it would apply but please correct me.

So besides CoS and VLANs, what else should/could I do on the Cisco switches? DSCP is supposed to be the successor to IP Precedence so I'm assuming that is what I should use on the router. Would I then map the Cos Value to the DSCP value and then send over the T1?

Should I be looking at more mechanisms as well?
 
12.2.13T added new commands for echo cancellation. They also changed the way they do echo cancellation.

One of the new commands is: echo-cacel suppressor

Depending on how the IP Phone is marking the packet. Some use CoS some use DSCP. No matter how it is marked you can either re-mark it or just have the devices honor the marking. DSCP is backward compatible with IP Prec.

Echo cancelation would be useful with the HDV card or analog connections. Remember echo can't happen on a digital circuit, it is caused in the analog leg of the call. The echo cancelation settings can be adjusted depending on who is getting the echo.


 
>So besides CoS and VLANs, what else should/could I do on the Cisco switches? DSCP is supposed to be the successor to IP Precedence so I'm assuming that is what I should use on the router. Would I then map the Cos Value to the DSCP value and then send over the T1?

Yes, in theory, you should remark your traffic with IP DSCP tags. However when you start talking about transport across the WAN other factors present themselves. If you mark you voice traffic on the router, I doubt that the QoS values will be honored by your WAN service providers network, unless you've got a IP MPLS connection.

So marking can help prioritise the voice traffic's outbound serialisation on the router, but once the packets sent its then at the mercy of the SP's network.

If you've got plenty of bandwidth, then it should be no problem. However if, for example, you calling a branch office using a 256kb WAN link and someone in your office starts downloading a 60mb video file using the same WAN circuit, you might find it to be a problem.

Typically you can help manage these problems by using separate vc's for voice/data traffic (if your using frame-relay or atm). For example if you know your max bandwidth for voice ip is going to be 256kb and you need 512kb for data, then you can split your T1 into 2 vc's. Note that the actually configuration of this on the routers is much more complicated, especially if you've got a large WAN with more that 10 sites to service.

Of course if your using leased lines, then you wont have these issues since you've effectively got a point to point connection.
 
For point-to-point WAN connections use LLQ and you won't have voice quality issues unless you totally oversubscibe the link. LLQ creates a priority queue for voice (or whatever you define) and WFQ everything else.

You can get more granular but that is more complicated for the example here.

 
Thanks guys for the great info. I'm pasting all this in notepad. It's all good stuff. Although I have full P2P T1s I'm interested in the IP MPLS connection just for the info. I'll look nto the LLQ as well.

Now if AT&T would fix the errors on my T1...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top