Hello Giovanni
Ah, that’s why I didn’t recognize the output format! I see… Well, as I said before, such drops are typically due to congestion. Those that may point towards a hardware problem, or a cabling problem include FCS errors and some types of collisions.
I hope this has been helpful!
Laz
Hi,
Can you explain about “show interfaces counters errors”? and I found the value error while checking “show interfaces counters errors” and “show interface” it’s different, how is it even possible?
Thanks.
Hello Jisooya
The output of the show interfaces command for a specific interface will show you certain types of errors including those shown in this sample output
437 packets input, 48503 bytes, 0 no buffer
Received 76 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
86 packets output, 25910 bytes, 0 underruns
However, the show counters errors has an output similar this:
Router# show interfaces gigabitethernet 2/4/47 counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards
Gi2/4/47 0 0 0 0 0 0
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts s
Gi2/4/47 0 0 0 0 0 0 0
Port SQETest-Err Deferred-Tx IntMacTx-Err IntMacRx-Err Symbol-Err
Gi2/4/47 0 0 0 0 0
This is a more analytical output with subcategories of errors. The errors are categorized differently, and the interfaces are often polled at different times and different intervals so you won’t see the same total number of errors in the one output as the other. If you see large discrepancies, such as thousands of input errors, runts, CRCs overruns and others in the show interfaces command and you see no errors in the show interfaces counters errors command, then something is very wrong 
.
I hope this has been helpful!
Laz
Hello!
If the delay is set differently on both ends of a connection, lets say, SW1 Fa0/1 is set to 100 usec and on the other end, SW2 Fa0/1 is set to 10 usec, could it cause packet loss or any other issue?
Hello Daniel
The delay, like the bandwidth of an interface, is a value that you can modify as needed, and is used as a label that helps routing protocols calculate their metrics. Delay is taken into account by EIGRP, so any changes to this value will affect metrics.
If you are not using routing protocols, you can set the delay to anything you want, and it will not affect the operation of the network. When routing protocols such as EIGRP are used, it will simply change the metric.
Now the metric of any particular path is measured in an outbound direction only. What that means is that the cumulative metric that EIGRP will create over the full path to a destination involves the delay (and bandwidth) of the interfaces out of which packets will exit. The delay and bandwidth on the interfaces through which packets enter is not taken into account. Take a look at this NetworkLessons note concerning the OSPF metric. The same principle remains true for EIGRP as well.
Now if you have different delays on either side of the link, the only thing that may happen is that return traffic will not take the same path if there are multiple paths available. This is not generally a problem, as far as routing goes, because EIGRP will be able to determine a loop-free return path without any problems. The result is what is known as asymmetric routing. This could potentially be a problem, but not always. Take a look at this lesson that talks a little bit about the possible dangers of asymmetric routing:
I hope this has been helpful!
Laz
Hi @lagapidis ,
How if in the other way, I saw errors on show interfaces counters errors command and no error found in the show interfaces command? and how to reset error value in the show interfaces counters errors command?
Hello Jisooya
You can use the command clear counters to clear all counters associated with interfaces. More information about this command can be found here:
I hope this has been helpful!
Laz
Hello team, appreciated if someone can advice “unknown protocol drops” there is any way we can verify which protocols are drops?
Hello Mohd
In the output of the show interfaces command on a Cisco IOS router, unknown protocol drops refers to the number of packets that were discarded because the router could not identify or process the protocol encapsulated in the packet. Essentially, the Layer 3 protocol used is unidentified or unsupported by the router, so the packet is dropped.
These drops can occur for various reasons, such as:
When a Cisco router receives a packet, it checks the EtherType field in the Layer 2 (Data Link layer) header to determine the encapsulated Layer 3 protocol (such as IPv4, IPv6, or others). If the EtherType field value does not correspond to a known or supported Layer 3 protocol, the router will consider it an unknown protocol and drop the packet.
If you are consistently seeing a high number of unknown protocol drops, it could indicate a network issue, such as misconfigured devices, or faulty hardware or cabling.
I hope this has been helpful!
Laz
Great article, as always!
Would it be perhaps possible to supplement this great article with steps to take in case the counters have certain values? For example, is it a problem if the “lost carrier” counter increases, and what steps must be taken in case the counter reaches value X or Y? I’m not even sure what carrier means here. Is it simply the carrier wave itself, so the physical signal that is transmitted on the wire? So when router R1 sends a signal to router R2, R1 receives an “echo” of R1’s signal, and when the echo is lost, that’s when the “lost carrier” counter increments?
“lost carrier and no carrier—The carrier is an electrical signal that Ethernet devices use to detect whether the wire is currently being used by another transmitting station.”
But why would full-duplex interfaces even care to look for this information if it can send and receive at the same time on the same wire?
Although I’m not sure about the question I raised above, I think I can contribute at least 1 piece of knowledge. What I do know from Todd Lammle’s CCNA book (which is not mentioned in this article) is that when the “no buffer” and “ignored” counters increment, that usually indicate a broadcast storm (because the buffers have no more room).
Have a nice weekend.
Attila
Hello Attila
It would be a good idea to have content that will explain in detail all of the various counters that you may see in the show interfaces command, and how those counters can be interpreted when troubleshooting. I will arrange to create a NetworkLessons note on this in the coming days, and repost it here in this thread.
In the meantime, concerning the “lost carrier” counter, in order to understand it better, you must first understand what a carrier signal is in the context of telecommunications in general, but also Ethernet in particular.
A carrier signal or carrier wave is a waveform that exists on any active telecommunication circuit. This waveform, which most often is in the form of a sinusoidal wave, as shown below, is a wave of alternating current sent over the wire.
This waveform exists on the wire when no data is being exchanged. When data is exchanged, the waveform’s properties are modulated or modified in particular ways. The modifications in the waveform contain data that can be demodulated or interpreted on the other end of the link. The process is quite complex and is the same for both wired (fluctuating voltage) and wireless (fluctuating EM waves) mediums. For fiber, we have a similar concept of a carrier wave, whose properties are modified or modulated to encode data onto the carrier wave. These are demodulated or interpreted on the other end in a similar fashion.
The point here is that whether data is being sent or not, some signal in the form of a carrier wave must be present to consider the link live. This is part of the physical layer of Ethernet. It is a prerequisite to having a successful communication circuit.
Whenever zero voltage is measured on a copper Ethernet cable or zero light pulses are detected on a fiber link for any length of time, this is considered a lost carrier event, and the counter increases.
This is typically caused either by a faulty cable, faulty hardware on the sender’s side, or a combination of both.
I hope this has been helpful!
Laz
Hello Laz,
As always, thank you for the thorough response. 
Just to check my understanding:
When I connect the two ends of a twisted pair (i.e. STP or UTP) or coaxial cable into two devices (or two different ports on the same device), the connection creates an electric current within the cable, even when the cable is not used to transfer data (as long as the given device/s has/have power). And this electric current (which stands by, waiting for data to be transferred) is the carrier?
Similarly, when I connect the two ends of a fiber-optic cable into two devices (or two different ports on the same device), the connection creates a beam of light within the cable, even when the cable is not used to transfer data (as long as the given device/s has/have power). And this beam of light (which stands by, waiting for data to be transferred) is the carrier? (Or in the case of multimode fiber instead of single mode: beams of light.)
And when it comes to radio waves, a working access point is constantly broadcasting its RF signal, even when the access point isn’t used to transfer data. And this RF signal (which stands by, waiting for data to be transferred) is the carrier?
Attila
Hello Attila
I’ve created a new NetworkLessons note with information about some counters. You can find it at the note titled Interface - show interfaces counters explained.
I’ve already added a note concerning the no carrier counter. It’s a start, and over time, it will be added to.
Thanks again for your good idea!
Laz
Hello Attila
Yes, that is correct in all three cases. When information in the form of bits is to be placed on the medium, it is this carrier wave that is modulated or changed. The modulation of the wave contains the information. If there is no information to transmit, the carrier wave remains unchanged.
I hope this has been helpful!
Laz