QoS for Cisco IP phones attached to layer 2 switch

Answered Question
Sep 14th, 2007

I am trying to implement LLQ across several switches. Our Cisco IP phones are attached to 3560 POE switches that are configured only at layer 2. They trunk to a 6509. I want to set up egress queues on that trunk so that voice traffic has priority and takes up a specified amount of the bandwidth. I tried to implement the following commands but when I get to the policy-map there are no commands available for "priority" or "bandwidth".

I'm new at this. For weeks I've been trying to learn QoS and VOIP by reading from various Cisco books (QOS 642-642 book, CCNP ONT 642-845 book, etc.) and online documents. I would be grateful for any help that anyone can give.

!Configure the class-maps for VOIP and VOIP signaling.

class-map llq-voip-traffic

match ip dscp ef

exit

class-map voip-signaling

match ip dscp af31

exit

!Configure the policy-map to reserve the bandwidth on 2GB PO egress queues

policy-map llq-voip-2gb

class llq-voip-traffic

priority percent 37 (740,000 Kbps)

class voip-signaling

bandwidth percent 13 (260,000 Kbps)

class class-default

fair-queue

end

!Set the bandwidth on the 2GB PO interface and apply the policy-map outbound.

conf t

int po2

bandwidth 2000000

service-policy output llq-voip-2gb

exit

Thank you very much!

Correct Answer by chris.mann about 9 years 4 months ago

I've found that echo is normally caused by the telco connection. Looking at the errors on your prime, I'd say get the fixed first, and see where you are at after that.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (4 ratings)
Loading.
jbarcena Fri, 09/14/2007 - 12:48

Those commands are only for some layer 3 switches, they won't work on layer 2 switches.

HTH

//Jorge

AJAZ NAWAZ Fri, 09/14/2007 - 21:11

Hello Teressa,

I think you may be in luck. I have recently deployed 3560's with PoE and have them set-up with auto-qos. I'll explain how to do that later.

Let's just for a momment however take a look at your scenario. First of all bandwidth availability on fast speed LAN's normally does not affect Voice traffic. FastSpeed meaning 100/1000mb or more. I would imagine that your inter-switch trunks are likely to be aggregated gigabit channels. So we have ample bandwidth for a fairly substantial deployment already in place.

Second. LLQ as you know is the acronym for Low Latency Queuing and is recommended queuing mechanism but used normally for slow speed WAN links such as leased-lines. LLQ is encouraged since it is one of the easiest QoS mechanisms to configure and implement. However, LLQ does have some restrictions:

The LLQ feature supports Voice over IP (VoIP) on serial links and ATM PVCs. It does not support VoIP over Frame Relay links.

For more information about LLQ - refer to the following document:

<http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html#wp8909>

QoS on the LAN for L2/L3 Catalyst Switches

------------------------------------------

Want to make sure that your Voice traffic is receiving priority over Data on the LAN?

look not much further than here, I've used this to implement Auto-Qos:

<http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuration_example09186a0080722cdb.shtml>

please rate post if it helps

Regards,

Ajaz : )

Teressa Corson Mon, 09/17/2007 - 04:23

Thanks for your help, Ajaz.

I neglected to mention that we had AutoQoS on the 3560s originally. We removed it after finding out from Cisco that it's only a macro and it doesn't take into account the environment. We were hoping to find something that was more appropriate to what we wanted in our environment (a single priority queue for voice over all other traffic).

What made us nervous about AutoQoS is that it appears to use traffic shaping commands (srr-queque...). I understood traffic shaping to be appropriate when you have lines with different speeds on either end or policing at one end, so you have to slow down the flow of traffic in order to avoid the far end dropping it. I also read that traffic shaping adds delay, which is exactly what I'm trying to eliminate/reduce.

You are correct that our interswitch links are all trunks, except the last one that goes from a core 6509 to the gateway router (2821). Some are 2GB port channels and the core has a 4GB port channel. There is plenty of bandwidth and we can tell that utilization is not even close to the maximum.

The whole reason we're implementing QoS in the first place is because we have echo on our VOIP phone calls and we want to eliminate delay within our network as a possible cause. We've tried adjusting input gain and output attenuation; that didn't seem to help. We also upgraded the IOS on the 2821 gateway which did seem to help but not enough; the echo is still too noticeable.

From my research, I see lots of articles stating that echo is mainly from the other end, the analog end of the call. I need to make sure everything possible is done on my end of the call before I can convince the telecom staff that they may need to take a look at their equipment too.

Thanks again for your help. I really appreciate it. :-)

Paolo Bevilacqua Mon, 09/17/2007 - 04:27

Which IOS are you running on the 2821? As you've seen, QoS has nothing to do with that. If you search the forum, there are some discussions about "advanced" echo problems. But I would start with latest dspware first.

Paolo Bevilacqua Mon, 09/17/2007 - 04:39

Would you please try 12.4(11)XJ that contains dspware 9.2.2.

Before you worry about, it is a perfectly stable release, widely used by myself and many others in customer production.

Teressa Corson Mon, 09/17/2007 - 06:57

Thank you. We have been looking into that. I have a couple questions, if you don't mind. I hope they don't sound too dumb.

The IOS we are running [12.4(16)] is dated June 2007. The one you are recommending is dated Dec 2006. That seems like a step backwards, although if you compare DSPWare versions the 9.2.2 version in your IOS recommendation seems to be higher than the 4.4.24 in our current IOS. I don't understand the link between IOS and DSPWare versions. Can you explain?

Also, how can I tell what DSPware version an IOS contains, without actually installing it. I don't have any test equipment so anything I do is going to be immediately in production. Thanks so much for your help.

Paolo Bevilacqua Mon, 09/17/2007 - 08:22

Hi,

check that 12.4(11)XJ4, came out like july 2007.

beside, you are using mainlines, while XJ4 is platform-specific and contains latest enhancements together with many many bug fixes.

I haven't seen a tool to map DSPware to IOS, but this info is generally 'circulated'.

Teressa Corson Wed, 09/26/2007 - 06:01

Thanks. We completed an IOS upgrade to 12.4(11)XJ4 on 9/24. Haven't had enough time to see if it has made a difference.

This morning I found information on another site about slip secs and the network-clock-select and network-clock-participate commands. Does anyone have further information about these related to possibly resolving echo problems?

We showed those errors on our T1 PRI interface:

Total Data (last 24 hours)

0 Line Code Violations, 0 Path Code Violations,

1394 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,

1394 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

We added these commands:

network-clock-participate wic 0

network-clock-select 1 t1 0/0/0

To our existing time commands:

ntp clock-period 17180247

ntp update-calendar

ntp server 10.128.10.2 source GigabitEthernet0/0

Thanks for your help.

Correct Answer
chris.mann Wed, 09/26/2007 - 11:47

I've found that echo is normally caused by the telco connection. Looking at the errors on your prime, I'd say get the fixed first, and see where you are at after that.

a.cruea1980 Wed, 09/26/2007 - 12:57

I gotta agree with the above.

Look up information on Hybrid Echo. You might be able to play with attenuation to get it fixed, but rarely does QoS cause it. You can also ask the telco to check the impedance on the line to make sure it's matched properly.

If it were a QoS, you'd see it much in the form of drops, cut-outs, and other such nasty things. Try turning on the QRT key on some of your phones, and when people notice issues, have them press that button. It'll kick back all sorts of fun statistics like jitter, delay, stuff like that.

Teressa Corson Mon, 10/08/2007 - 11:19

Adding the commands below to fix the timing errors seems to have done the trick.

network-clock-participate wic 0

network-clock-select 1 t1 0/0/0

Once our errors on the T1 interface went away, so did our echo. Thanks to everyone for your help.

Actions

This Discussion