10-23-2011 01:03 AM - edited 03-07-2019 02:59 AM
there is packets drops in the access switch interfaces which connect to the IP phones which cousing call disconnet or unclear voice. below some show command from the switch and for example i choosed interface 1/0/8:
GigabitEthernet1/0/8 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 6416.8d9b.cb88 (bia 6416.8d9b.cb88)
Description: User and IP phones
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:06, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 73752
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 15000 bits/sec, 22 packets/sec
5 minute output rate 468000 bits/sec, 110 packets/sec
9603245 packets input, 1826517973 bytes, 0 no buffer
Received 353136 broadcasts (180161 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 180161 multicast, 0 pause input
0 input packets with dribble condition detected
258194603 packets output, 30909288303 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
interface GigabitEthernet1/0/8
description User and IP phones
switchport access vlan 111
switchport mode access
switchport voice vlan 511
switchport port-security maximum 3
switchport port-security
switchport port-security violation restrict
switchport port-security aging type inactivity
mls qos trust device cisco-phone
storm-control broadcast level 10.00
storm-control action trap
spanning-tree portfast
ip verify source
end
femstf-tc1-ad-acc#sh mls qos interface gigabitEthernet 1/0/8 statistics
GigabitEthernet1/0/8 (All statistics are in packets)
dscp: incoming
-------------------------------
0 - 4 : 6665679 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 907085
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 1834520 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 243978581 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 462547
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 616404 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 6861340 0 0 907095 0
5 - 7 : 1834619 0 0
cos: outgoing
-------------------------------
0 - 4 : 245332342 0 0 462547 0
5 - 7 : 616404 0 0
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------
queue 0: 616404 0 0
queue 1: 233599766 7988309 12252931
queue 2: 10470600 0 0
queue 3: 0 0 45851
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------
queue 0: 0 0 0
queue 1: 0 0 0
queue 2: 73752 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
femstf-tc1-ad-acc#sh mls qos queue-set
Queueset: 1
Queue : 1 2 3 4
----------------------------------------------
buffers : 25 25 25 25
threshold1: 100 80 100 60
threshold2: 100 91 100 100
reserved : 50 100 50 100
maximum : 400 100 400 100
Queueset: 2
Queue : 1 2 3 4
----------------------------------------------
buffers : 25 25 25 25
threshold1: 100 200 100 100
threshold2: 100 200 100 100
reserved : 50 50 50 50
maximum : 400 400 400 400
and here is the mls configurations:
mls qos map cos-dscp 0 8 16 24 32 46 48 56
mls qos srr-queue output dscp-map queue 2 threshold 1 18
mls qos srr-queue output dscp-map queue 2 threshold 2 32
mls qos srr-queue output dscp-map queue 2 threshold 3 16 24 48
mls qos srr-queue output dscp-map queue 3 threshold 1 0
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos queue-set output 1 threshold 2 80 91 100 100
mls qos queue-set output 1 threshold 4 60 100 100 100
mls qos
can someone help me please to solve this issue
Solved! Go to Solution.
10-23-2011 03:42 AM
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
It often helps to identify both the platform and actual IOS being used since there often subtle difference especially in features like QoS.
That noted, it appears all your drops are in queue 2, which is likely call signally packets. Packets drops of call signally packets likely explains your call drops.
Normally, if you're going to have drops, you would prefer to see them first, and perhaps only, on less critical traffic, such as the data traffic to the connected PC not to packets to the phone.
The fix is to stop these drops by increasing the ratio of scheduling for this queue and/or increasing queue resources for this queue. The latter accomplished by increasing buffer resources and/or increasing drop limits.
You can also consider mixing call signally and call bearer packets in the same queue. This is contrary to the "book", but signally is also critical and uses little bandwidth. Generally, I've found mixing it with bearer traffic is non-adverse to the bearer traffic and simplifies buffer/queue management for VoIP.
Lastly, does this platform support PQ? If so, is it enabled for VoIP bearer?
10-23-2011 03:42 AM
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
It often helps to identify both the platform and actual IOS being used since there often subtle difference especially in features like QoS.
That noted, it appears all your drops are in queue 2, which is likely call signally packets. Packets drops of call signally packets likely explains your call drops.
Normally, if you're going to have drops, you would prefer to see them first, and perhaps only, on less critical traffic, such as the data traffic to the connected PC not to packets to the phone.
The fix is to stop these drops by increasing the ratio of scheduling for this queue and/or increasing queue resources for this queue. The latter accomplished by increasing buffer resources and/or increasing drop limits.
You can also consider mixing call signally and call bearer packets in the same queue. This is contrary to the "book", but signally is also critical and uses little bandwidth. Generally, I've found mixing it with bearer traffic is non-adverse to the bearer traffic and simplifies buffer/queue management for VoIP.
Lastly, does this platform support PQ? If so, is it enabled for VoIP bearer?
10-23-2011 04:35 AM
hi joseph thanks for you answer,
Actually PQ not enabled and the IOS version is " flash:c3750-ipbasek9-mz.122-50.SE3.bin"
which soulution you think will be the best to solve this issure with modifing the existing configuration ??
10-23-2011 05:58 AM
Hi,
Why are you using this mapping "mls qos srr-queue output dscp-map queue 3 threshold 1 0"?
Actually I see the drop in queue 3 (because in the drop output queues are numbered 0-3, not 1-4, maybe I am wrong) there is the mapping for voip signaling too.
Best regards,
Alex
10-23-2011 04:49 PM
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
Hard to suggest "best" solution since you've haven't described QoS needs beyond VoIP. For that, would enable PQ and place VoIP bearer into PQ. As noted earlier, you might also map VoIP signally into that queue too. If you desire to keep signally traffic in non-PQ, you'll need to tune other QoS settings for that traffic.
Everything else might be initially left as is.
10-24-2011 02:35 AM
Actually this configuration done by someone alse and I am trying to stop the packet drops, what is I try to remove the
mls qos srr-queue output dscp-map queue 3 threshold 1 0 command from the switch and do the test again??
10-24-2011 07:06 AM
Yes, also share output of "show mls qos maps dscp-output-q" and for the "sh mls qos interface gigabitEthernet 1/0/8 statistics".
Best regards,
Alex
10-24-2011 01:07 PM
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
Well you can try lots of things, and I understand and appreciate you want to stop the drops, but also please realize unless you have a good understanding of what you want QoS to do for you, you can easily make matters worse. QoS is often about making trade-offs, so when you change any value it can have a ripple effect that's not desired.
If you want to experiment, if queue-set 2 isn't being used, you might try it on this interface. You could also intially try it with default QoS settings.
10-24-2011 11:06 PM
femstf-tc1-ad-acc#sh mls qos maps dscp-output-q
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 03-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 04-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 02-03 03-01 02-01 03-01
2 : 03-01 03-01 03-01 03-01 02-03 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 02-02 04-01 04-01 04-01 04-01 04-01 04-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 02-03 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01
10-25-2011 02:31 AM
Enter "mls qos srr-queue output dscp-map queue 2 threshold 1 0" as queue 2 threshold 1 is the default for the dscp 0 traffic. It is not yet implemented as I can see from the output. Then maybe it will be dropped but with the traffic which belong to this queue which is neither voip signaling nor carrier. So the problems with the voice could be resolved.
You should see the d1 0 - d2 0 value 02-01(02 is the queue number 01 is the threshold number) not 03-01 as it is now.
Best regards,
Alex
10-25-2011 11:28 PM
Hi Alexander
queuee 2 threshold 1 is the default for dscp 0 traffic now
femstf-tc1-ad-acc#sh mls qos maps dscp-output-q
Dscp-outputq-threshold map:
d1 :d2 0 1 2 3 4 5 6 7 8 9
------------------------------------------------------------
0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 04-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 02-03 03-01 02-01 03-01
2 : 03-01 03-01 03-01 03-01 02-03 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 02-02 04-01 04-01 04-01 04-01 04-01 04-01 04-01
4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 02-03 04-01
5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01
6 : 04-01 04-01 04-01 04-01
but still I can see some drops for the packets as shown below:
femstf-tc1-ad-acc#sh mls qos interface gigabitEthernet 1/0/39 statistics
GigabitEthernet1/0/39 (All statistics are in packets)
dscp: incoming
-------------------------------
0 - 4 : 2386 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 104
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------
0 - 4 : 13424 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 85
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 0 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------
0 - 4 : 2416 0 0 104 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------
0 - 4 : 13460 0 0 85 0
5 - 7 : 0 0 0
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------
queue 0: 0 0 0
queue 1: 13464 488 620
queue 2: 0 0 0
queue 3: 0 0 26
output queues dropped:
queue: threshold1 threshold2 threshold3
-----------------------------------------
queue 0: 0 0 0
queue 1: 29 0 0
queue 2: 0 0 0
queue 3: 0 0 0
Policer: Inprofile: 0 OutofProfile: 0
femstf-tc1-ad-acc#sh interfaces gigabitEthernet 1/0/39
GigabitEthernet1/0/39 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is
Description: User and IP phones
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:44, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:07:53
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 29
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 7000 bits/sec, 5 packets/sec
5 minute output rate 26000 bits/sec, 26 packets/sec
2840 packets input, 648805 bytes, 0 no buffer
Received 124 broadcasts (15 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 15 multicast, 0 pause input
0 input packets with dribble condition detected
14087 packets output, 2160879 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
10-27-2011 03:06 AM
Hi,
You have drops because this queue is limited even more then the previous one but this traffic will not cause the signalling for the voip to be dropped now and you should be fine with the voip, isn't that your goal?
Best regards,
Alex
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: