1.%PQUICC_ETHER-3-UNDERFLO: Unit [dec], underflow error During transmission of a frame, the local buffer of the controller chip received insufficient data because the data could not be transferred to the chip fast enough to keep pace with its output rate. Normally, such a problem is temporary, depending on transient peak loads within the system.
Recommended Action: The system should recover. No action is required. If the problem recurs, it indicates a hardware error that might be related to data traffic patterns. If this is the case, copy the error message exactly as it appears on the console or in the system log, contact your Cisco technical support representative, and provide the representative with the gathered information.
Related documents- No specific documents apply to this error message.
As the other poster already noted, the UNDERFLO message indicates a condition where the ethernet controller's transmit FIFO went empty while it was trying to transmit the frame. Generically speaking, most drivers / chipset will use the following process when transmitting:
- The packet is stored in a buffer and the pointer for this packet buffer is passed into the Tx ring of the egress interface.
- The chipset will see that a packet is ready for transmit so it DMA's the packet from the TX ring into it's FIFO queue.
- As soon as the part of the packet is in the FIFO the chipset begins the transmit (while the DMA is still going on)
- If the chipset runs into a condition where the transmit is happening faster than the DMA it will display the UNDERFLO message and that single packet will be aborted.
The condition can occur under a number of scenerio's. On the 1700 platform, certain show commands or other conditions will lock the system bus which can interfer with the DMA process which in turn may cause this message to occur. Since you have only seen it a few times, it is safe to ignore.
The other messages in your log are unrelated to the UNDERFLO message. They are more serious since they are indicating a situtation where the IOS dropped a TCP packet because the internal IOS data structures were either corrupted or the packet had previously been sent but the data structures where not cleaned up properly. In this case, the packet in the buffer was a TCP packet which was being resent due to a timeout and it looks like some other process may have already dealt with that packet (i.e. two processes tried to send the same packet). I would suggest you open a TAC case to have this situation looked into. The TAC will need a show tec and a show log from your router.
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...
Attached policy provides CLI access to the Cisco 4G router over text messaging. Two files are in the attached .tar file:
2. PDF with instructions on how to load and use the .tcl file.