Interface outDiscards. - Page 2

azibnaseem1 · ‎04-13-2016

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 · ‎04-20-2016

Hi can you post the show int f1/0/1 again , the show mls qos interface fastEthernet 1/0/1 statistics and sh mls qos maps dscp-output-q Without these commands cant suggest anything further as I need to see what dscp values are exactly being dropped , there's a few things you can then try to alleviate the issue.

azibnaseem1 · ‎04-20-2016

Dear Mark,

Thanks for the reply.

yes sure, all commands output is given below.

#show interfaces fastEthernet 1/0/1
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 150/255, rxload 36/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 15:57:14
Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 629826
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 14279000 bits/sec, 5619 packets/sec
30 second output rate 59182000 bits/sec, 6813 packets/sec
190472950 packets input, 75788172069 bytes, 0 no buffer
Received 1032821 broadcasts (2899 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 79183 multicast, 0 pause input
0 input packets with dribble condition detected
214185651 packets output, 222161330255 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
======================================

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

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

0 - 4 : 189803321 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 : 213588853 0 0 0 3
5 - 9 : 0 0 0 0 0
10 - 14 : 25 0 0 0 0
15 - 19 : 0 0 0 3 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 6947 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 : 191981682 0 0 0 0
5 - 7 : 0 0 0
cos: outgoing
-------------------------------

0 - 4 : 213857719 25 3 0 0
5 - 7 : 0 6966 1944296
output queues enqueued:
queue: threshold1 threshold2 threshold3
-----------------------------------------------
queue 0: 0 0 0
queue 1: 214557313 324006 1958329
queue 2: 0 0 0
queue 3: 0 0 24138

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

Policer: Inprofile: 0 OutofProfile: 0

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

#show 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 02-01 02-01
1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01
2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01
3 : 03-01 03-01 04-01 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 04-01 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

Thanks,

Mark Malone · ‎04-20-2016

Your not dropping critical traffic only low end dscp value traffic so that's good , mls is working in terms of where the traffic is being pout in queues

There are a couple of options

1 MLS can cause issues sometimes and removing it can actually fix the issue you could try remove it clear the counters and see if the issue is still there and if its dropping packets

2 Manipulate the actual queues so queue1 above is slightly larger and can handle more traffic , you can tweak this until its not dropping packets anymore but be careful not to cause drops in your priority queues

can you post the show run interface f1/0/1 so we can see what the srr queues are split into ?

azibnaseem1 · ‎04-20-2016

Dear Mark,

I would mention that I am service provider and this is my core router. Is it possible to remove the mls qos and it didn't effect my network at all?

Running config of fa 1/0/1 is given below.

interface FastEthernet1/0/1
description Local LAN (Connected to Fa 1/0/18)
no switchport
ip address 203.124.61.1 255.255.255.0 secondary
ip address 192.168.1.253 255.255.255.0 secondary
ip address 10.19.10.1 255.255.255.0 secondary
ip address 210.56.19.1 255.255.255.0
load-interval 30
end

Thanks,

Mark Malone · ‎04-20-2016

Your core router is only a 100mb interface supplying customers ? that's a low end switch for a core device , its only a distribution switch really not built for huge amounts of traffic.

You can remove mls qos globally it will take a few seconds there may be a blip but usually not , your freeing the port from being in a queue so everything will go back to default 1 queue of the interface, the other option is increase the queue that's dropping

To alter the queues and increase queue 2 you use the command

srr-queue bandwidth shape x x x x change each x as a value

#sh mls qos queue-set
Queueset: 1
Queue     :       1       2       3       4
----------------------------------------------
buffers   :      15      25      40      20
threshold1:     100     125     100      60
threshold2:     100     125     100     150
reserved :      50     100     100      50
maximum   :     200     400     400     200

Just to say here as well this is an uplink with output drops less than 1% so its not doing badly for the load its taking , the more you shape the queues the more latency you can increase just to fix drops , its very unlikely even removing mls or shaping the queues are you going to get rid of all drops on a 100mb interface , the switch is dropping these legitimately by either being overloaded or burst traffic at times.

another fix for this would be have a bigger uplink gig pipe or bundle 2 or 3 interfaces together in a port-channel to provide more throughput , there will always be a bottle neck on uplinks as you have every other 100mb port sending traffic at same time to 1 100mb port

azibnaseem1 · ‎04-20-2016

Dear Mark,

It is right, my up-link is on gig port and I also have an ether-channel bundling two ports together with my distribution switch. One thing more, I have also observed outDiscards on physical ether-channel ports.

Moreover, this switch is in production from last 5 to 6 years. So, soon I am going to deploy a 2911 ISR router with 3560 gigabit switch.

Thanks,

Mark Malone · ‎04-20-2016

Hi sorry I don't get that the port were looking at is a FE port 1/0/1 I mean that as your uplink to the internet or are you saying the far end of it is a gig port

either way of your able to move to a gig interface switch it will definitely help with the drops as the buffers will be larger and able to handle more

azibnaseem1 · ‎04-20-2016

Dear Mark,

As earlier I said that I am working in an ISP. FE 1/0/1 is gateway for my local LAN and default gateway for two other subnets. My actual uplink which is connected to another ISP is on gigabit port.

Joseph W. Doherty · ‎04-14-2016

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

No, not saying there's not problem. Not saying there is a problem. Not enough information, and as Mark notes, it can be difficult to obtain. (I.e. you can obtain more information by using smaller intervals for analysis, but very frequent polling creates it's own issues. Mark suggesting reducing load interval to its minimum, of 30 seconds, helps, but burst drops happens at the subsecond level.)

Joseph W. Doherty · ‎04-13-2016

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

As Mark notes, without knowing the total number of egress packets, your drop count might be "normal".

That said, 3750's, default buffer settings, especially the defaults when QoS is enabled, often drop packets if traffic is bursty. If that's happening, sometimes buffer setting tuning can mitigate.