This is a classic case of one link being bad in an ether channel.
When the traffic has to traverse an ether channel, it first undergoes a hashing algorithm, that will decide which port of the ether channel will be used to forward the traffic.
The Hashing algorithm currently benign used can be checked with the command.
show etherchannel load-balance.
If one of the links/ports is bad and is dropping packets, then only certain streams of traffic , which hash to that port, will be affected.
Once you have identified the bad link, you have to look for issues like layer 1, interface errors, cabling etc.
How to identify which port of etherchannel is bad?
1. Shut one port at a time. This will make the Etherchannel has algo to recalculate the Hashes. In your case, since you have only two ports, all the traffic will be moved to the remaining port.
With this method you will be able to identify the culprit port in maximum 2 steps.
2. Second way to identify is more methodological and quite “cool” ! ;-)
In this method, we will use the Cisco CLI to identify which port the problematic stream ( Source IP and Destination IP ) are hashing to.
The command on 2960/3750 is
test etherchannel load-balance interface port-channel number {ip | mac} [source_ip_add |
For Example.
{ 1/0/49 ———————— 1/0/47 }
2960 — PO1 PO1 — 3850
{1/0/50————————— 2/0/47}
You say you cannot ping 192.168.1.1 from 2960. For illustration, lets say the interface on 2960 is 192.168.1.2.
We should check the following command on the 2960.
test etherchannel load-balance interface port-channel 1 ip 192.168.1.2 192.168.1.1
Let me know how it goes.
My bet is the culprit port is 1/0/50. I say this because,when you unbundle the ether channel, there will be two redundant links. The spanning-tree will put 1/0/49 in forwarding state, as it is the lower port number. 1/0/50 should be in blocked state.
More information of ether-channel load-balancing.
http://www.cisco.com/c/en/us/support/docs/lan-switching/etherchannel/12023-4.html#cat2950_3550
