Netflow Collectors


Running through varying products looking at their capabilities and functionality. NTOP sits at the top of my list but by some method of madness the Manage Engine solution (which uses ntop) provides a better functioning interface for ease and use.

worth more than a peek


Sensible logging & timestamps from a northern munky


As they say you never know everything and more often than not you ocoassionally miss out on some real gems of configurations..

# clock timezone gmt 0 0
# clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 3:00
# service timestamps log datetime localtime
# logging buffer informational
# logging host <ip address> informational

thanks Hoppy..!

De-mystifing the “Underruns and show interface Ethernet x” command


The years I’ve spent networking has found a common question which is continually raised by myself and or colleagues that I’ve worked with. A very simple question which has offered a myriad of viable, crazy and misunderstood offerings. As such I’ve dug around to identify the best sources of information on the errors seen when reviewing the stats from a show interface on a Cisco device. The order is not in any particular order and the references have been sought from Cisco’s own description. A key characteristic to remember is that some errors may increment multiple counters.

Output Hang

This identifies the time since the interface was last reset due to a transmission that took to long. Never is shown if a hang condition hang not occurred.

No Buffers

This indicates packets which had to be discarded when received on an interface due to the lack of buffer space on the router. This if seen as a regularly incrementing may indicate that the router is under spec’d, a consideration for additional memory may assist in resolving the issue. If this is not so regular then it may be an issue caused by a broadcast storm (the next field under a wireshark capture in the packet will assist in identifying if this is the case).

Received Broadcasts

The use of broadcasts in an IPV4 network is common place and actually part of the standard process of Ethernet. The primary example of this is the function of ARP.


A runt is a packet which is less than the minimum length of 64 bytes. If an Ethernet interface processes a packet less than 72 bytes is seen as an error condition. It is possible that an Ethernet collision will generate a runt. However, other causes may generate runts such as faulty hardware and or line protocol issues. It should be highlighted that runts are dropped.


A giant is a packet seen to exceed the standard Ethernet byte level (my understanding is that this is 1518 bytes and in some documentation there is reference that a standard Ethernet frame is 1500 bytes) and the RFC denotes 1518 bytes. As with runts it should be highlighted that giants are dropped.


A router will shutdown its interface recover function if the memory buffer and or processor are overloaded. This is what is considered a throttle and is identifiably a hardware capacity issue. If this is in conjunction with buffer errors then the hardware should be considered insufficient.

Input Errors

Input errors are the most complicated from my experience as they cover a number of varying elements. The other errors such as runts, giants, buffer, CRC, ignored and overrun may all be indicative and identified as an input error.

CRC Errors

>1% is an issue… The definition of a CRC error is in comparison to it’s name. If more than 1% of traffic sent is identified as an error then there may be a myriad of other issues ranging from hardware through to line faults. My experience has shown duplex mismatches to be  a cause of  most issues.

Frame Errors

Frame errors occur  when a CRC occurs. The primary cause of a frame error is in parallel with failing hardware or excessive collisions. I know it’s not a direct answer but hey it’s better than you’ve understood before.


This is the number of packets the hardware interface ignored due to the capability of the interface.


This usually relates to a memory and buffer issue with  the received packets exceeding the routers capability.

Dribble Condition

A dribble is a frame which is oversized. If the CRC is identified to match then the consideration is the issue is due to noise on the line.


This is identified as the opposite to the overrun and where the packets are received at a rate far below that of the capability of the interface.

Output Errors

This is probably the most sophisticated of the pre-identified errors as it is a sum of all of the above if they prevent the forwarding of packets across the network.


This will affect the data transmitted in an Ethernet network and in most instances may refer to a number of issues related to the cable. historically the 5-4-3 rule was a key view of excessive collisions when investigation of performance faults.

Interface resets

This is generally caused when the transmission of packets cannot be transmitted and an interface reset occurs.


Babbler1= Rob Randall

Babbler2= James Broomfield

Babbles occur when either of the above talk to much or the transmit timer expires.

Late Collisions

Usually, coursed by an excessive cable length