cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
67655
Views
0
Helpful
5
Replies

Detected a Loop back. Port has been Disabled

blin
Level 1
Level 1

One of our Cisco 3560 switches keeps showing this warning: Description: Gi0/15: Detected a Loop back. Port has been Disabled. Recommendation: Check Configuration of the switch, also make sure devices connected to the switch are not mirroring the traffic back to switch. Enable this port again. However, there is no thing connect to the port Gi0/15 as shown this link: http://www.howtocisco.com/cisco/switchissues.htm. Why do you get this warning?

2 Accepted Solutions

Accepted Solutions

Daniel Mckibbin
Level 1
Level 1

I couldn't check your link, because it keeps forwarding me to spam websites. Anyway I looked this up on Cisco.com and found the following:


Loopback error

A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network that the spanning tree has not blocked. The source interface receives the keepalive packet that it sent out, and the switch disables the interface (errdisable). This message occurs because the keepalive packet is looped back to the port that sent the keepalive:

    %PM-4-ERR_DISABLE: loopback error detected on Gi4/1, putting Gi4/1 in
    err-disable state

Keepalives are sent on all interfaces by default in Cisco IOS Software Release 12.1EA-based software. In Cisco IOS Software Release 12.2SE-based software and later, keepalives are not sent by default on fiber and uplink interfaces. For more information, refer to Cisco bug ID CSCea46385 ( registered customers only) .

The suggested workaround is to disable keepalives and upgrade to Cisco IOS Software Release 12.2SE or later.

Source: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00806cd87b.shtml

So if it is a fiber interface it may have to do with Cisco bug ID CSCea46385.  A temporary solution would be able to disable keepalives on the interface or prevent this condition from err-disabling an interface. If what you say is true and there is nothing connected to the interface why isn't it shut down? If nothing is connected and this is still happening you can try opening a TAC case.

View solution in original post

blin,

With Ethernet I don't believe there is a command to see keepalive statistics in real time or a record of keepalives over a period of time. I know with Serial interfaces you can issue a debug interface serial (#) and it will show keep alives sent and received. Since the port is not being used does the no keepalive interface config mode command stop the loopback alarms? If you plug a host PC in the port are these alarms still being received. To me it sounds like an IOS bug or a port failure within the Ethernet Module. You can however confirm that keepalives are configured for an interface with the show interface "interface type/mod/#" enable mode command. See the output below:

FastEthernet0/1 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0013.80e2.a981 (bia 0013.80e2.a981)
  Description: Trunk to Internet_Router
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)

If the error is only received when a host is not plugged in and the no keepalive prevents the alarms from being received, then I would disable keepalives when the interface is not in use, and enable them when it is in use. If this is not something you would like to do I would try a different IOS version. If an IOS upgrade or downgrade does not solve the issue I would engage Cisco TAC.

View solution in original post

5 Replies 5

Daniel Mckibbin
Level 1
Level 1

I couldn't check your link, because it keeps forwarding me to spam websites. Anyway I looked this up on Cisco.com and found the following:


Loopback error

A loopback error occurs when the keepalive packet is looped back to the port that sent the keepalive. The switch sends keepalives out all the interfaces by default. A device can loop the packets back to the source interface, which usually occurs because there is a logical loop in the network that the spanning tree has not blocked. The source interface receives the keepalive packet that it sent out, and the switch disables the interface (errdisable). This message occurs because the keepalive packet is looped back to the port that sent the keepalive:

    %PM-4-ERR_DISABLE: loopback error detected on Gi4/1, putting Gi4/1 in
    err-disable state

Keepalives are sent on all interfaces by default in Cisco IOS Software Release 12.1EA-based software. In Cisco IOS Software Release 12.2SE-based software and later, keepalives are not sent by default on fiber and uplink interfaces. For more information, refer to Cisco bug ID CSCea46385 ( registered customers only) .

The suggested workaround is to disable keepalives and upgrade to Cisco IOS Software Release 12.2SE or later.

Source: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00806cd87b.shtml

So if it is a fiber interface it may have to do with Cisco bug ID CSCea46385.  A temporary solution would be able to disable keepalives on the interface or prevent this condition from err-disabling an interface. If what you say is true and there is nothing connected to the interface why isn't it shut down? If nothing is connected and this is still happening you can try opening a TAC case.

Thank you for the help.

1. This is not fiber interface. The port configuration:

switchport mode access

spanning-tree portfast

2. The Switch is running 12.2SE.

3. How can I check the keepalive status on the switch?

4. I am sure no device connecting to the port. That is why I posted the link to show the picture. Can I send it to you by email?

Update

I have been monitoring this switch and no one touch the switch. No device is connecting to it and sh int  gi0/43 status notconnect as shown the result below. At 9:31 AM, it has another error. sh int  gi0/43 status Port      Name              Status      Vlan      Duplex  Speed Type Gi0/43                      notconnect  1            auto  auto 10/100/1000B seTX

blin,

With Ethernet I don't believe there is a command to see keepalive statistics in real time or a record of keepalives over a period of time. I know with Serial interfaces you can issue a debug interface serial (#) and it will show keep alives sent and received. Since the port is not being used does the no keepalive interface config mode command stop the loopback alarms? If you plug a host PC in the port are these alarms still being received. To me it sounds like an IOS bug or a port failure within the Ethernet Module. You can however confirm that keepalives are configured for an interface with the show interface "interface type/mod/#" enable mode command. See the output below:

FastEthernet0/1 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 0013.80e2.a981 (bia 0013.80e2.a981)
  Description: Trunk to Internet_Router
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)

If the error is only received when a host is not plugged in and the no keepalive prevents the alarms from being received, then I would disable keepalives when the interface is not in use, and enable them when it is in use. If this is not something you would like to do I would try a different IOS version. If an IOS upgrade or downgrade does not solve the issue I would engage Cisco TAC.

Hi,

Thanks por sharing.

It is happening on a catalyst 9300, it is not STP, it just turns off the port and these errors appear in the log... Any ideas how to solve it without the tac?

%PLATFORM_PM-3-LOOP_BACK_DETECTED: Loop-back detected on GigabitEthernet1/0/1.
006643:

%PM-4-ERR_DISABLE: loopback error detected on Gi1/0/1, putting Gi1/0/1 in err-disable state
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/1, changed state to down
%LINK-3-UPDOWN: Interface GigabitEthernet1/0/1, changed state to down

CiroGMele_0-1716386199934.pngCiroGMele_1-1716386254327.png

Thanks a lot

Best rigards.

Ciro Gustavo Mele.

Review Cisco Networking for a $25 gift card