07-29-2014 11:52 AM - edited 03-07-2019 08:13 PM
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.
07-29-2014 12:26 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
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.
07-29-2014 02:17 PM
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
07-29-2014 05:03 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
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.
07-31-2014 08:31 AM
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.
03-26-2015 02:01 AM
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!!!
03-26-2015 09:34 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
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
.
.
03-27-2015 01:15 AM
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!!
03-27-2015 03:05 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
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.
03-27-2015 09:15 AM
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!!!
03-30-2015 03:11 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
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.
03-30-2015 03:11 AM
Ok, Joseph. Thank you very much. Now I understand a bit better all this.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide