VOIP in Cisco network
I'm trying to pin down the exact config to implement VOIP in a Cisco network. The core is a 4 switch 3750 stack and the closets 3560 (stacked with SFP interconnect cables).
ASKER
QOS settings. ..
I've researched many documents. On trunk ports is says to add "mls qos trust dscp" . Do I need this when I'm trusting cos on the switchports?
Just to give you an idea on the layout. The 4x3750 stacked are doing the intervlan routing. Then I've built etherchannels to every data closet. Each trunk has only the vlans needed per data closet. (I like to control what goes out the trunks. Been bitten a few times with a problem on a vlan which brought networks down. Easier to control this way).
This is what I've added on the switchports
mls qos (global)
-- standard data port
switchport access vlan XXX
switchport voice vlan XXX
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
The auto qos VOIp added a whole pile of mappings.
Now from what I've read you need to configure the trunk port this way?
-- standard trunk port
description trunk connection to data closet
switchport trunk encapsulation dot1q
switchport mode trunk
priority-queue out
mls qos trust dscp
auto qos voip trust
Why would I need "mls qos trust dscp" isn't this layer 3? not layer 2 where we use COS?
I've researched many documents. On trunk ports is says to add "mls qos trust dscp" . Do I need this when I'm trusting cos on the switchports?
Just to give you an idea on the layout. The 4x3750 stacked are doing the intervlan routing. Then I've built etherchannels to every data closet. Each trunk has only the vlans needed per data closet. (I like to control what goes out the trunks. Been bitten a few times with a problem on a vlan which brought networks down. Easier to control this way).
This is what I've added on the switchports
mls qos (global)
-- standard data port
switchport access vlan XXX
switchport voice vlan XXX
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone
spanning-tree portfast
The auto qos VOIp added a whole pile of mappings.
Now from what I've read you need to configure the trunk port this way?
-- standard trunk port
description trunk connection to data closet
switchport trunk encapsulation dot1q
switchport mode trunk
priority-queue out
mls qos trust dscp
auto qos voip trust
Why would I need "mls qos trust dscp" isn't this layer 3? not layer 2 where we use COS?
Layer 2 vs Layer 3... Yes and no. What you have to accomplish is two fold.
First you want to either mark all VoIP traffic that enters a port, or you must trust that your neighbor and all the upstream neighbors beyond have marked their traffic correctly. [if you do not explicitly trust the ingress port, by default the switch will strip the COS/DSCP values and set them back to 0 (best effort data) to ensure that no user/application is able to game the QoS system either on purpose or accidently.]
Second you want to ensure that the traffic that contains voice traffic is inserted into the Priority queue when it leave any switch port. It generally helps to use the same standards for marking/classifying traffic across the board (DSCP, or COS, or TOS, etc...). How you do this is mostly up to the platform (Cat 3750 in this case.) and then up to you to select which packet/frame tagging you wish to utilize.
When setting up a new switch configuration like this I prefer to try and keep everything to DSCP since I can use the same ACLs, rules, etc., across the organization as it is layer-3 and so the WAN can be included without changing so much or having to get all the mapping correct when switching between COS/TOS/DSCP/etc... If there are Layer 2 devices that need to see that and do not understand DSCP, you can mark the Layer 2 frame as well with CoS in case traffic crosses those links.
Whatever you pick, it helps me to run a packet analyzer trace on the traffic as it leaves the ports involved to make sure I am getting the markers I want and expect.
Auto QoS can be handy, but understanding all the settings it is installing will help you understand the potential issues and assist when you are having to solve problems.
First you want to either mark all VoIP traffic that enters a port, or you must trust that your neighbor and all the upstream neighbors beyond have marked their traffic correctly. [if you do not explicitly trust the ingress port, by default the switch will strip the COS/DSCP values and set them back to 0 (best effort data) to ensure that no user/application is able to game the QoS system either on purpose or accidently.]
Second you want to ensure that the traffic that contains voice traffic is inserted into the Priority queue when it leave any switch port. It generally helps to use the same standards for marking/classifying traffic across the board (DSCP, or COS, or TOS, etc...). How you do this is mostly up to the platform (Cat 3750 in this case.) and then up to you to select which packet/frame tagging you wish to utilize.
When setting up a new switch configuration like this I prefer to try and keep everything to DSCP since I can use the same ACLs, rules, etc., across the organization as it is layer-3 and so the WAN can be included without changing so much or having to get all the mapping correct when switching between COS/TOS/DSCP/etc... If there are Layer 2 devices that need to see that and do not understand DSCP, you can mark the Layer 2 frame as well with CoS in case traffic crosses those links.
Whatever you pick, it helps me to run a packet analyzer trace on the traffic as it leaves the ports involved to make sure I am getting the markers I want and expect.
Auto QoS can be handy, but understanding all the settings it is installing will help you understand the potential issues and assist when you are having to solve problems.
ASKER
Ok. I understand what you are saying but when I tried to apply "mls qos trust dscp" on the 3560 which are etherchanneled to the core 3750 stack, it accepts the command but when I do a show run, it automatically put it to " mls qos trust cos". Doesn't let me configure "mls qos trust dscp". Is this because of the "auto qos voip trust"? It's basically telling me that this is layer 2.
I'm just stumped on what I would do at the core? Do I configure "mls qos trust dscp" on the interface vlans seeing as these are layer 3? Is it going to trust the voip traffic the right way? To go between layer 2 and 3?
Also, do you know of any issues that auto qos would produce?
Do you know of a good packet analyser? Would wireshark do?
thx for your help!
I'm just stumped on what I would do at the core? Do I configure "mls qos trust dscp" on the interface vlans seeing as these are layer 3? Is it going to trust the voip traffic the right way? To go between layer 2 and 3?
Also, do you know of any issues that auto qos would produce?
Do you know of a good packet analyser? Would wireshark do?
thx for your help!
ASKER
I've noticed that IP routing was not enabled on the 3560 in the closets. After enabling it, I can put "mls qos trust dscp".
So now, you mentioned that you normally do this at a layer 3 level..should I be doing this? The 3560 can do layer 3 and seeing as the 3750 are already doing layer 3, I would think that it is the way?
If this is right, what is the right config for layer 3?
So now, you mentioned that you normally do this at a layer 3 level..should I be doing this? The 3560 can do layer 3 and seeing as the 3750 are already doing layer 3, I would think that it is the way?
If this is right, what is the right config for layer 3?
The best free analysers I have used are Wireshark and Microsoft NetMon v3.3. If you can find the free version of Wildpackets OmniPeek Personal that they used to give away, for a personal use program it is full of features.
The specific configuration matters to be sure, but you probably want to start at the top for the config by layong out the overall plan.
How many switches/routers?
How are they connected (3750-stack bus, GigE Etherchannel uplinks for 3560, etc.. WAN Routers using MPLS, IPsec, Frame Relay, etc...)? (a good start is what you mentioned in the previous post)
How are the VoIP packets tagged? DSCP, COS, TOS, etc...
Who is the VoIP call manager/VoIP software vendor and what platforms are you using? (Cisco CallManager, Asterisk, etc..)
Does every device that handles/touches VoIP traffic support the same QoS?
Some comments, and remmeber you should always see how it fits in your environment...
AutoQOS is certainly easier than trying to manage all the queues on each platform/ASIC/IOS release manually. There are a HUGE number of parameters that should be configured on some switches to map the DSCP/COS/TOS values to different hardware queues on each family of switches. Even if you tweak it later, it is a good place to start...
The primary goal is to decide what you have to tag/remark and what hosts (if any) you can trust... In this case trust just means that you will assume that the incoming packets are already marked correctly. Generally the basic rules are that you mark incoming traffic where it enters the network and trust the traffic on the uplinks and trunks.
Part of a this is to understand what it is you have to mark/tag/support QoS for...
The most important things to remember are that QoS only comes into the picture when there is traffic backed up in a buffer or queue somewhere. On GigE LAN links, QoS for voice is much less of an issue than on a 768K WAN link... Not that it should not be done, but until there is congestion enough to disrupts the LAN links by 50msec or > then the users will likely never see all of your hard work. Having said that...
QoS most important for time critical things and in a roughly decreasing order:
VoIP Payload packets, UDP and carrying the actual conversations...
VoIP Call Setup packets, both UDP and TCP are possible and these are important, but need about 10-20% of the bandwidth of the payload.
Video would be next and video conferencing is more time critical than streaming video.
Other applications and services that are extra important come next.
General apps can fight it out for the rest...
Sometimes you have low priority and/or abusive programs that need to be demoted to only get background bandwidth, but that is generally a WAN thing.
-------------
So in summary....
Decide what tags you need (DSCP if every device can handle it is probably a good start)
Figure out how you are going to classify it and tag it at each ingress port. (this will depend on what kind of traffic and where it originates, but basic 3 level VoIP_Payload, VoIP_Signalling, BestEffort is usually enough for VoIP on a LAN)
Trust those ports where the edges are doing the classification for you.
AutoQoS on each ingress port can work if all switching devices support it and the switches can see that the phones are Cisco. (they share that as part of the CDP traffic on the ports)
Try and keep the configs as similar as you can to make your life easier. Running QoS as L3 DSCP everywhere, even if say the 3560 switches are really only functioning as a Layer-2 switch, is just simpler to manage. If you have some non-DSCP switches like old Catalyst 29xx switches then things get a little more complicated, but if you just have what you have mentioned it should work fine like this.
Also, be sure you configure trust and QoS stuff on the trunk ports and the Poxx Etherchannel ports to make sure the packets are treated correctly. Again verify it with the packet analyzer to be sure... I have had it fail to manage the QoS tagging correctly many things... IOS bugs, ASIC limitations, application configuration issues and my own configuration mistakes. The analyzer shines the light on it just to be 100% sure.
The specific configuration matters to be sure, but you probably want to start at the top for the config by layong out the overall plan.
How many switches/routers?
How are they connected (3750-stack bus, GigE Etherchannel uplinks for 3560, etc.. WAN Routers using MPLS, IPsec, Frame Relay, etc...)? (a good start is what you mentioned in the previous post)
How are the VoIP packets tagged? DSCP, COS, TOS, etc...
Who is the VoIP call manager/VoIP software vendor and what platforms are you using? (Cisco CallManager, Asterisk, etc..)
Does every device that handles/touches VoIP traffic support the same QoS?
Some comments, and remmeber you should always see how it fits in your environment...
AutoQOS is certainly easier than trying to manage all the queues on each platform/ASIC/IOS release manually. There are a HUGE number of parameters that should be configured on some switches to map the DSCP/COS/TOS values to different hardware queues on each family of switches. Even if you tweak it later, it is a good place to start...
The primary goal is to decide what you have to tag/remark and what hosts (if any) you can trust... In this case trust just means that you will assume that the incoming packets are already marked correctly. Generally the basic rules are that you mark incoming traffic where it enters the network and trust the traffic on the uplinks and trunks.
Part of a this is to understand what it is you have to mark/tag/support QoS for...
The most important things to remember are that QoS only comes into the picture when there is traffic backed up in a buffer or queue somewhere. On GigE LAN links, QoS for voice is much less of an issue than on a 768K WAN link... Not that it should not be done, but until there is congestion enough to disrupts the LAN links by 50msec or > then the users will likely never see all of your hard work. Having said that...
QoS most important for time critical things and in a roughly decreasing order:
VoIP Payload packets, UDP and carrying the actual conversations...
VoIP Call Setup packets, both UDP and TCP are possible and these are important, but need about 10-20% of the bandwidth of the payload.
Video would be next and video conferencing is more time critical than streaming video.
Other applications and services that are extra important come next.
General apps can fight it out for the rest...
Sometimes you have low priority and/or abusive programs that need to be demoted to only get background bandwidth, but that is generally a WAN thing.
-------------
So in summary....
Decide what tags you need (DSCP if every device can handle it is probably a good start)
Figure out how you are going to classify it and tag it at each ingress port. (this will depend on what kind of traffic and where it originates, but basic 3 level VoIP_Payload, VoIP_Signalling, BestEffort is usually enough for VoIP on a LAN)
Trust those ports where the edges are doing the classification for you.
AutoQoS on each ingress port can work if all switching devices support it and the switches can see that the phones are Cisco. (they share that as part of the CDP traffic on the ports)
Try and keep the configs as similar as you can to make your life easier. Running QoS as L3 DSCP everywhere, even if say the 3560 switches are really only functioning as a Layer-2 switch, is just simpler to manage. If you have some non-DSCP switches like old Catalyst 29xx switches then things get a little more complicated, but if you just have what you have mentioned it should work fine like this.
Also, be sure you configure trust and QoS stuff on the trunk ports and the Poxx Etherchannel ports to make sure the packets are treated correctly. Again verify it with the packet analyzer to be sure... I have had it fail to manage the QoS tagging correctly many things... IOS bugs, ASIC limitations, application configuration issues and my own configuration mistakes. The analyzer shines the light on it just to be 100% sure.
ASKER
Great information! Thanks! so now another question ..Do I need to put the "mls qos trust" on the POxx etherchannel interfaces? or just on the trunk ports that they are applied to?
They way I configured the closets is with layer 2. The core stack is doing intervlan routing for all the different vlans going to every closet. There will be an ISR hanging off the core to connect all the different sites. For this link I will use "DSCP" to the ISR and for the closets I will use "COS" . Does this seem ok to you?
I will also get an analyser to see what is going on.
They way I configured the closets is with layer 2. The core stack is doing intervlan routing for all the different vlans going to every closet. There will be an ISR hanging off the core to connect all the different sites. For this link I will use "DSCP" to the ISR and for the closets I will use "COS" . Does this seem ok to you?
I will also get an analyser to see what is going on.
ASKER
Sorry forgot to mention everything is Cisco including the call manager..
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thx for the great info!
The QoS configuration on the ISR is the key to WAN VoIP call quality and reliability. The traffic on the ISR should be marked when it enters the router and CBWFQ when it heads out the WAN ports. That will be a small project in itself since you additionally need to ensure the WAN carriers honor and enforce your QoS policies.
Good luck and holler back if we can help.
CoreyMac
QOS - Switch settings ?
VLan recommendations + Subnets ?
Interconnect layout ?