Interface outDiscards.

[azibnaseem1]

Dear CISCO Members,

I am using cisco 3750-48TS at my core network. I experienced outDiscard problem on some interfaces. Output is given below. Kindly, view and update accordingly.

#show interfaces fastEthernet 1/0/1 counters errors

Port               Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Fa1/0/1                0            0            0             0           0              2201168

Port             Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa1/0/1            0                   0            0                0               0          0         0

Thanks,

[Mark Malone]

Hi

That doesn't mean anything without the other stats off the interface , it could well be under the 1% drop rate which is acceptable depending on volume of traffic going through

ca you post the show int f1/0/1 and are you running layer 2 qos

[azibnaseem1]

Dear Mark,

Thanks for your reply.

Interface f1/0/1 stats is given below and mls qos is configured on the switch.

FastEthernet1/0/1 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001a.6c2a.abc1 (bia 001a.6c2a.abc1)
Description: Local LAN (Connected to Fa 1/0/18)
Internet address is 210.56.19.1/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 72/255, rxload 29/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/2/0 (size/max/drops/flushes); Total output drops: 2826914
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 11673000 bits/sec, 3321 packets/sec
5 minute output rate 28405000 bits/sec, 3722 packets/sec
652993025 packets input, 247699422292 bytes, 0 no buffer
Received 3795099 broadcasts (466 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 214898 multicast, 0 pause input
0 input packets with dribble condition detected
758637408 packets output, 793777345536 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

Thanks,

[Joseph W. Doherty]

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 wha2tsoever (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

The good news, your overall drop percentage is only (about) .37% (2826914/758637408).

The not so good news, this is an overall drop percentage.  You might be having burst drops of more than 1%.

[azibnaseem1]

Dear Joseph,

Thanks for your reply.

You mean to say, it is ok no problem at all.

Thanks.

[Mark Malone]

Your alright for overall drops they are within guidelines but there could be burst traffic as Joseph is saying, some applications basically can cause burst traffic , burst traffic is what it says a burst of traffic which can for a second flood the buffer on a switch and overload the buffer so it drops some of the traffic, 3750s dont have good buffers compared to other switches

Burst traffic is not easy to capture ,you can drop the load interval to 30 seconds instead of default 5 minutes its easier to see then

http://www.cisco.com/c/en/us/support/docs/lan-switching/switched-port-analyzer-span/116260-technote-wireshark-00.html

Before that can we take a look at the layer 2 qos queue for the interface

can you post sh mls qos interface f1/0/1 statistics it might show more information relating to whats been dropped

Also post show buffers and show buffers failures

[azibnaseem1]

Dear Mark,

Thanks for your reply.

Given below is an information is requested.

show mls qos interface fastEthernet 1/0/1

FastEthernet1/0/1
trust state: not trusted
trust mode: not trusted
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based

===================

#show buffers

Interface buffer pools:
Syslog ED Pool buffers, 600 bytes (total 132, permanent 132):
100 in free list (132 min, 132 max allowed)
41894 hits, 0 misses
RxQFB buffers, 2040 bytes (total 904, permanent 904):
890 in free list (0 min, 904 max allowed)
4918428 hits, 0 misses
RxQ0 buffers, 2040 bytes (total 1200, permanent 1200):
700 in free list (0 min, 1200 max allowed)
500 hits, 0 misses
RxQ1 buffers, 2040 bytes (total 128, permanent 128):
2 in free list (0 min, 128 max allowed)
349771 hits, 4899 fallbacks
RxQ2 buffers, 2040 bytes (total 128, permanent 128):
0 in free list (0 min, 128 max allowed)
128 hits, 0 fallbacks, 0 trims, 0 created
0 failures (0 no memory)
RxQ3 buffers, 2040 bytes (total 128, permanent 128):
2 in free list (0 min, 128 max allowed)
36785868 hits, 4227925 fallbacks
RxQ4 buffers, 2040 bytes (total 128, permanent 128):
3 in free list (0 min, 128 max allowed)
78891 hits, 1397 fallbacks
RxQ5 buffers, 2040 bytes (total 128, permanent 128):
64 in free list (0 min, 128 max allowed)
64 hits, 0 misses
RxQ6 buffers, 2040 bytes (total 128, permanent 128):
0 in free list (0 min, 128 max allowed)
25794938 hits, 28316246 misses
RxQ7 buffers, 2040 bytes (total 192, permanent 192):
62 in free list (0 min, 192 max allowed)
6781986 hits, 14 misses
RxQ8 buffers, 2040 bytes (total 64, permanent 64):
0 in free list (0 min, 64 max allowed)
28739862 hits, 28393239 misses
RxQ9 buffers, 2040 bytes (total 1, permanent 1):
0 in free list (0 min, 1 max allowed)
1 hits, 0 misses
RxQ10 buffers, 2040 bytes (total 64, permanent 64):
1 in free list (0 min, 64 max allowed)
2836178 hits, 593746 fallbacks
RxQ11 buffers, 2040 bytes (total 16, permanent 16):
0 in free list (0 min, 16 max allowed)
4766492 hits, 7102113 misses
RxQ12 buffers, 2040 bytes (total 96, permanent 96):
0 in free list (0 min, 96 max allowed)
210805 hits, 371476 misses
RxQ13 buffers, 2040 bytes (total 16, permanent 16):
0 in free list (0 min, 16 max allowed)
16 hits, 0 misses
RxQ15 buffers, 2040 bytes (total 4, permanent 4):
0 in free list (0 min, 4 max allowed)
4629814 hits, 4629810 misses
IPC buffers, 2048 bytes (total 300, permanent 300):
296 in free list (150 min, 500 max allowed)
31516 hits, 0 fallbacks, 0 trims, 0 created
0 failures (0 no memory)

Header pools:

=========================

#show buffers failures
Caller Pool Size When

Thanks,

[Mark Malone]

as you can see some of the buffers have misses quite a few that can indicate over utilization at times  , you missed the statistics bit at the end of the mls command thats not the full output thanks please post with statistics

at least there are no full failures which is good

[azibnaseem1]

Dear Mark,

whole output of show mls qos with statistics is given below.

#show mls qos interface fastEthernet 1/0/1 statistics
FastEthernet1/0/1 (All statistics are in packets)

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

0 - 4 : 879137523 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 0
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 : 1020348372 0 0 0 9
5 - 9 : 0 0 0 0 0
10 - 14 : 104 0 0 0 0
15 - 19 : 0 0 0 4 0
20 - 24 : 0 0 0 0 0
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 38967 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 : 890184461 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------

0 - 4 : 1021583042 104 4 0 0
5 - 7 : 0 38984 9955566
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 2 0 0
queue 1: 1025054621 1531961 10024989
queue 2: 0 0 0
queue 3: 0 0 41116

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

Policer: Inprofile: 0 OutofProfile: 0

Thanks,

[Mark Malone]

Hi the qos is incorrect, it looks to be only applied globally, this tells the ports do not trust the markings which can cause packets to go to the wrong queue, when queues fill up packets get dropped in mls so you should make sure your port is set correctly

In access layer2 set it as mls cos trust cos and the uplinks set as mls qos trust dscp so the ports are trusted , when ports are not trusted properly the traffic can go to the wrong queue and fill it up , when its full it drops packets so its important to have the ports trusted or it will add to your issues of drops

GigabitEthernet0/3

trust state: trust cos

trust mode: trust cos

[azibnaseem1]

Dear Marks,

Thanks for the reply.

Could you refer to me any example related to this issue or study notes, so I can fix this problem.

Thanks,

[Mark Malone]

Hi

The fix would be to apply mls qos trust dscp to each interface that will cover you as long as mls qos map cos-dscp 0 8 16 26 32 46 48 56 is in place as well  in running config

or if switch only supports cos use that some older switches dont run dscp

mls qos trust cos

here is doc on it

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/91862-cat3750-qos-config.html

[azibnaseem1]

Dear Mark,

Thanks for the reply.

Sorry for late replying. I have studied your suggested material and also watched videos related to QoS. I am using policy base routing in my network. I need to know that can it possible to use PBR and QoS simultaneously? One thing more I have applied command mls qos trust dscp to interface but it didn't solved my problem.

Thanks,

[Mark Malone]

Hi no it wont fix the issue , its just so if your using mls qos you have it setup right because if you don't it will add to the issues of dropped packets , now that qos is marking correctly you need to see what queues are filling up and dropping the packets but first you need to clear the interface and monitor it and get stats that are actually correct , then from there you can make a decision on how to fix it

So the next steps would be clear counters f1/0/1 clear mls qos interface f1/0/1 Then monitor for a day or 2 until new drops are seen and ruin this command again show mls qos interface fastEthernet 1/0/1 statistics

pbr can work with qos fine are you planning on re-writing precendence values through pbr ?

[azibnaseem1]

Dear Mark,

I have applied all your suggested commands, then I have monitored the fa 1/0/1. It showing the same result as before. outDiscards are increased as before and also some packets are drooped in Queue 1.

No I am not planning to use pbr for re-writing precedence values, I am using pbr to police the bandwidth to customers.

Thanks,