Increasing Total output drops in the Cisco switch

dhinesh_83 · ‎07-29-2014

Hi Team,

I am seeing a total output drops are increasing in the switch side interface where the interface connected between router and switch. I cleared the counters but still it increasing high.

Router Model: Cisco 3845

Switch Model : Cisco C3750

What could be the problem.?

What i need do further?

It will affect the network performance?

Please anyone provide the permanent solution to avoid this issue.

Joseph W. Doherty · ‎07-29-2014

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

First question: Generally, the problem is sending packets faster to the interface than it can transmit them.

Third question: It might.

Second question: Well, first you want to determine if it's adverse to your traffic needs. If it is, you work to mitigate it. How that would be done, depends on many factors. For example, on your 3750, egress buffer tuning might mitigate.

dhinesh_83 · ‎07-29-2014

Hi Joesph,

Thank you for your response.When i ping from outside upto router i can get a normal response but i am seeing some latency to the devices beyond to the core-switch.

Is this network latency due to the output drops?

Can i go and change the cable between router and switch?

Any additional configuration is required in the switch to avoid this issue?

Core_Switch#sh running-config int gi1/1/1
Building configuration...

Current configuration : 135 bytes
!
interface GigabitEthernet1/1/1
switchport access vlan 32
switchport mode access
speed 100
duplex full
end

Core_Switch#sh int gi1/1/1
GigabitEthernet1/1/1 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is a44c.1125.378d (bia a44c.1125.378d)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 10/255, rxload 7/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, link type is auto, media type is 10/100/1000BaseTX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:25, output 00:00:00, output hang never
Last clearing of "show interface" counters 05:23:04
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 17681
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 3070000 bits/sec, 1155 packets/sec
5 minute output rate 3959000 bits/sec, 706 packets/sec
     22809172 packets input, 8884818718 bytes, 0 no buffer
     Received 16000 broadcasts (4547 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 4547 multicast, 0 pause input
     0 input packets with dribble condition detected
     14189775 packets output, 9303603992 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     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

Joseph W. Doherty · ‎07-29-2014

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

The additional latency you're seeing, pinging past your router, might be congestion (although queues need to be somewhat deep at 100 Mbps).

Although you have drops, they are down in the .1% range, which is normally not adverse.

Danny Morris · ‎07-31-2014

I agree with Joseph. Less than 1% output drops should not be harmful to your network.

In my case, I did not even notice there were any output drops on my network until we deployed Solarwinds. I fought with this for months trying to eliminate these output drops that always occurred on trunk links or switch to router links. In the end, I just removed the Solarwinds alerts for these interfaces.

I can't seem to find the document now, but I remember reading a Cisco document describing how total output drops less than 1% of the total packet output was considered normal behavior. If I find it I will re-post it here.

antilope1 · ‎03-26-2015

Hello everybody,

I would like to know which reference do you take for total packets count to get the percentage of total drops.

In my case to see total output drops, I look:

gh inter gi1/0/x stats

Switch model is 2960X or 3750G

SH INTER gi1/0/19 stats
GigabitEthernet1/0/19
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 0 0 592191 49119124
Route cache 0 0 0 0
Total 0 0 592191 49119124

I take as total pkts output 592191 but I don`t know if this is right.

Do you know if there is another better command to get this? And command:

sh inter gi1/0/19 counters

has to do anything with this?

In my case the output seems not to show output packets:

sh inter gi1/0/19 counters

Port InOctets InUcastPkts InMcastPkts InBcastPkts
Gi1/0/19 283723984 1703350 2038 3303

Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts
Gi1/0/19 3913234602 2816627 1776580 1014199

Thank you everybody!!!

Joseph W. Doherty · ‎03-26-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

I normally just look at the show interface counters, e.g.:

Core_Switch#sh int gi1/1/1
GigabitEthernet1/1/1 is up, line protocol is up (connected)
.

.

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 17681
.

.

14189775 packets output, 9303603992 bytes, 0 underruns

.

antilope1 · ‎03-27-2015

Good morning Joseph,

Ok, so you just take this command to get total packets. It is true it has this information, and to be true, I had not seen it!!

Thank you very much and if somebody could tell me if in output:

SH INTER gi1/0/19 stats
GigabitEthernet1/0/19
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 0 0 592191 49119124
Route cache 0 0 0 0
Total 0 0 592191 49119124

all the packets in processor mean there is no fast-switching in this switch. I have not disabled anything about this in this switch and I do not know why all interfaces give this result (2960X). I supposed ip route-cache was enabled by default in any switch.

Thank you!!

Joseph W. Doherty · ‎03-27-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

Some of the switches don't always update all the "buckets" you would think they should. The processor switching stats might only count software forwarded packets, which might not exclude CEF switching.

On a 2960X the bulk of your packet switching should be at the ASIC level.

antilope1 · ‎03-27-2015

Ok Joseph,

Thank you very much for your help!

Only one question more, why the bulk of packet switching should be at the ASIC level on this switch? If I see a 3750G it is the same.

When the CAM is created and goes filling up, I supposed the bulk of the switching would be through fast-switching rather than SW mechanism.

Thank you again!!!

Joseph W. Doherty · ‎03-30-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

Yes, the bulk, ideally all, switching should be at the ASIC level. Why? Well because ASICs provide hardware switching which is what provides their high performance.

If the TCAM fills up, then you have CPU switching, which is much, much slower. This can be avoided, on some switches, by using different TCAM profiles. The 3750G calls them SDM.

antilope1 · ‎03-30-2015

Ok, Joseph. Thank you very much. Now I understand a bit better all this.