The user receives the "%ETHCNTR-3-LOOP_BACK_DETECTED" error message on a Cisco Catalyst switch that runs Cisco IOS® Software.
The %ETHCNTR-3-LOOP_BACK_DETECTED:loop-back detected error message is recorded in the syslog. In addition, the interface in question goes into an administratively down state without manual configuration.
This issue can occur on Cisco Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560, 3750 and other fixed configuration Catalyst switches under one of these conditions:
The wrong cable is accidentally plugged into the port.
The keepalive packet is looped back to the port that sent the keepalive.
If the incorrect type of cable is connected and the loopback condition is desired, no action is required.
Otherwise, connect the correct cable. Issue the no shutdown command in interface configuration mode to bring the port up.
If the keepalive packet is looped back to the port that sent the keepalive, issue the no keepalive interface command to disable keepalives. This prevents the port from being disabled.
Keepalive packets are used for Balun detection on copper interfaces and are enabled by default on all interfaces.
Disabling keepalives on fiber interfaces should reduce the likelihood of a temporary loop causing part of the network to go down.
The issue has been reported, and keepalives are disabled by default from 12.2x SE code.
This issue is documented in Cisco bug ID CSCea46385.
ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on gig0/2 - CSCea46385
An interface on a Catalyst switch is error disabled after detecting a loopback.
Mar 7 03:20:40: %ETHCNTR-3-LOOP_BACK_DETECTED: Loop-back detected on
GigabitEthernet0/2. The port is forced to linkdown.
Mar 7 03:20:42: %LINK-5-CHANGED: Interface GigabitEthernet0/2, changed state
to administratively down
Mar 7 03:20:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet0/2, changed state to down
This might be seen on a Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550, 3560
or 3750 switch running 12.1EA or 12.2SE based code.
Disable keepalives by using the no keepalive interface command. This
will prevent the port from being errdisabled, but it does not resolve the root
cause of the problem. Please see section below for more information.
The problem occurs because the keepalive packet is looped back to the port that
sent the keepalive. There is a loop in the network. Although disabling the
keepalive will prevent the interface from being errdisabled, it will not remove
The problem is aggravated if there are a large number of Topology Change
Notifications on the network. When a switch receives a BPDU with the Topology
Change bit set, the switch will fast age the MAC Address table. When this
happens, the number of flooded packets increases because the MAC Address table
Keepalives are sent on the Catalyst 2940, 2950, 2950-LRE, 2955, 2970, 3550,
3560 or 3750 switch to prevent loops in the network. The primary reason for
the keepalives is to prevent loops as a result of Type 2 cabling. For more
Hi all, I have to replace some X4500 pairs running with vss through new 95k pairs.I think vss is not compatible to stackwise virtual so what is the best way to replace the X4500 without big issues?regardsChris
Hi,Need suggestion regarding SDA setup for wireless using the latest 9K series catalyst switches for SDA deployment.What is the recommendation to setup SDA specifically for WLAN out of following options:1. Using cisco 9300 / 9500 as border devices and act...
Hi,I have the below topology Internet browsing is very slow for wireless users. So i started to shut down one by one to isolate any link issues, When I shutdown the 10g on the right side it worked fine .So my question is why does it not a...