Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member



I'm getting the following error message in my environment.. Can you please shed some light on this issue... 


%ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet0/43.
%PM-4-ERR_DISABLE: loopback error detected on Gi0/43, putting Gi0/43 in err-disable state


Got few 3560x and 3750x switches (Source) (GigabithEthernet) centrally connected to a pair of 3560x switches (Destination) on the GigabithEthernet ports...

On the Source switches, the Gi ports are configured as Access ports and IP is assigned on the SVI for that particular VLAN... On the Destination Switch, the switchports are configured as Private VLAN - Isolated... 

The Interlink between Destination Switches allows only the private VLAN numbers and native vlan...


I receive the above mentioned logs on the Source switches and the ports go err-disabled... If I've 3 source switches, only one port is UP and rest of the 2 Source switch ports go to err-disabled... If I shut and no shut any one of the err-disabled port, the previously UP port goes into err-disabled port while the new port comes up... 


Searched through few forums and I found that it could be due to some faulty cables or Keepalive being received on the same port... I tried changing the cables but no use... Disabling keepalive would be an ugly workaround as it doesn't help me to find the root cause... 


IOS Version: 15.2(1)E1



Hall of Fame Super Silver

Sri I had a situation where



I had a situation where we were receiving that error message. I tracked it down to a vlan mismatch on one of the other switches in the network (not the one where I was receiving the error message). There was actually a layer 2 loop created but Spanning Tree did not detect the loop and it was allowing the keepalive from my interface to be forwarded back to the originating interface and causing it to be errored out. Spanning Tree did not detect the loop because one side was sending BPDUs for vlan 2 but the other side was in vlan 3 and did not process the BPDU and therefore did not detect the loop. It sounds to me like you may have a similar issue in terms of vlan mismatch.





CreatePlease login to create content