cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2757
Views
0
Helpful
11
Replies

output packets drop due to QoS configuration

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

1 Accepted Solution

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame

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?

View solution in original post

11 Replies 11

Joseph W. Doherty
Hall of Fame
Hall of Fame

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?

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 ??

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

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.

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??

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

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.

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

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

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

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

Getting Started

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: