I seem to have observed this phenomenon very often on all at least decently recent IOSes for 2960 and alike switches. It was always in a lab setting, a single switch with no other connections or work to do whatsoever, directly connected to a PC running a TFTP server software, and the TFTP download producing exactly these kinds of timeouts. There was no reason for high CPU (although I haven't verified that to be honest), no congestion on the single 100Mbps link between the PC and the switch. Yet, I have been able to see these timeouts reproducibly. A 2950 Catalyst in the same setting will download its own IOS from the same PC and TFTP server just fine.
My personal gut feeling is that there must be some regression in the TFTP client code in these recent IOSes. Because of this, I have moved over to using HTTP for IOS downloads.
About 20 hours ago (0100 GMT, 27 February 2015), I had to do an IOS upgrade (using the TAR file) on a 2960S and using the FastEthernet0 port. I saw no such thing. For obvious reasons, CPU was high but nothing abnormal.
At work, I use ZeroTouch to build switches and also never observe such thing.
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...