Possible QoS Issue

support systemsGo · ‎01-28-2015

Hello.

We are experiencing drops in audio during calls.

We have a CME router connected to one switch in one location, and the phones connected to another switch in another location.

The two switches are connected via 100Mbps Metroethernet line (configured as trunk).

We have the following configured on each port:

mls qos trust device cisco-phone
mls qos trust cos

Below is the output of the ports for the connection of switches on both ends.

CME Router

sh mls qos interface GigabitEthernet 1/0/1 statistics
GigabitEthernet1/0/1 (All statistics are in packets)

dscp: incoming
-------------------------------

0 - 4 : 1904702 0 0 0 0
5 - 9 : 0 0 0 6982822 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 2415605
25 - 29 : 0 1 0 0 0
30 - 34 : 0 0 0 0 6036180
35 - 39 : 0 0 0 0 0
40 - 44 : 9240677 0 0 0 0
45 - 49 : 0 9472579 0 610471 0
50 - 54 : 26965 0 0 0 24188
55 - 59 : 0 10112 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------

0 - 4 : 305003126 0 0 0 45595
5 - 9 : 1 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 121678
25 - 29 : 0 1155772 0 0 0
30 - 34 : 0 0 1 0 3029255
35 - 39 : 0 0 0 0 0
40 - 44 : 1099597 0 0 0 0
45 - 49 : 0 193314819 0 531027 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 748131 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------

0 - 4 : 262240440 0 0 1878112 6036180
5 - 7 : 9418466 59864 23237935
cos: outgoing
-------------------------------

0 - 4 : 506101938 0 0 6 0
5 - 7 : 0 413774 13696794
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 504488499 1534961 14107556
queue 2: 6 0 0
queue 3: 3021 0 78489

output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 17157 1 0
queue 2: 0 0 0
queue 3: 0 0 0

Policer: Inprofile: 0 OutofProfile: 0

Phone Switch

sh mls qos interface GigabitEthernet 1/0/1 statistics
GigabitEthernet1/0/1 (All statistics are in packets)

dscp: incoming
-------------------------------

0 - 4 : 63302399 0 0 0 45757
5 - 9 : 1 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 119966
25 - 29 : 0 1156114 0 0 0
30 - 34 : 0 0 1 0 2852675
35 - 39 : 0 0 0 0 0
40 - 44 : 1100146 0 0 0 0
45 - 49 : 0 168545288 0 457041 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 748127 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------

0 - 4 : 238975390 0 0 0 0
5 - 9 : 0 0 0 6986889 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 2227944
25 - 29 : 0 1 0 0 0
30 - 34 : 0 0 0 0 5819365
35 - 39 : 0 0 0 0 0
40 - 44 : 9244185 0 0 0 0
45 - 49 : 0 9419259 0 608637 0
50 - 54 : 19662 0 0 0 24017
55 - 59 : 0 10124 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------

0 - 4 : 482733691 0 0 0 0
5 - 7 : 0 342219 3831448
cos: outgoing
-------------------------------

0 - 4 : 259560325 0 0 1887310 5819365
5 - 7 : 9365146 49539 25787950
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 9365148 0 0
queue 1: 419540487 6646 25793939
queue 2: 1887344 0 0
queue 3: 5863050 0 625137

output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 23965 0 0
queue 2: 0 0 0
queue 3: 0 0 0

Policer: Inprofile: 0 OutofProfile: 0

Richard Bradfield · ‎01-28-2015

A couple of questions.

what type of link is it between the switches on the metroethernet? is it a trunk? is it L3?

is the config on the switch port with phones something like

switchport access vlan 123
switchport mode access
switchport voice vlan 124
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
queue-set 2
mls qos trust device cisco-phone
mls qos trust cos
spanning-tree portfast
spanning-tree bpduguard enable

HTH

Richard

support systemsGo · ‎01-29-2015

It is a trunk on the metroethernet.

Yes, the switch port configuration is similar, but without this part:

srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
queue-set 2

Also pulled this from the router:

Framing is ESF, Line Code is B8ZS, Clock Source is Line.
CRC Threshold is 320. Reported from firmware is 320.
Data in current interval (759 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
72 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
72 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
8226 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
8226 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

Richard Bradfield · ‎01-30-2015

A few more questions,

What type of switches are you using,

can you put the following command on the trunk Interfaces " auto qos voip trust"

on ports with IP phones put " auto qos voip cisco-phone " command

to get rid of slip errors you need the onboard E1 to be the clock

commands something like depending on where the E1 card is

network-clock-participate wic 0
network-clock-select 1 E1 0/0/0

support systemsGo · ‎02-04-2015

Using 3750 switches.

network-clock-participate wic 0 is in the config already.

Could it be due to the cable length? The port on the wic card is connected to the PRI provider handoff by a 3meter RJ45, but config shows "Cablelength is long 0db".

Joseph W. Doherty · ‎03-10-2015

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

If you're experiencing call drops, that might be caused by signalling not being sufficiently protected.