Hello Athan,
Catalyst switches send out simple frames called the LOOP frames out of every switched port. These frames are special in that their source and destination MAC addresses are set to the same value - the MAC address of the sending switchport. Essentially, every LOOP frame is a frame "from me to me". However, such frames are never expected to arrive back to their originating switchport. If a Catalyst switch receives a LOOP frame on a switchport that originated it (the source and destination MAC addresses of the frame match the MAC address of the switchport alone), it will err-disable the port with the loopback error cause - just like the one you are experiecing yourself.
In a properly working network, such frames will never come back to their sending port because any other switch that receives a LOOP frame would be forced to send it out the same port it came in (because the sender MAC = destination MAC). But no switch can send back a frame, no matter how addressed, back the very port it was received on - that is a basic operating rule of all switches.
So if a LOOP frame nonetheless comes back to its originating port, it indicates there is a looping condition in the network. It might be a switching loop involving a single switch or multiple switches. It may be a misbehaving switch or a NIC that reflects back frames on the port it receives them. It may be a poorly coded software switch that does not abide by all rules of Ethernet switching. It may be a misconfiguration (such as feeding a SPAN destination port back to the network that is being SPANned). It may be a physical layer problem looping back the frames (miswiring, damaged cable with short circuits, split fiber, ...).
Either way, an arrival of a LOOP frame back to its port of origin, and the err-disabling of the port, is a symptom of a possibly grave misbehavior of the network attached to that port.
Configuring "no keepalive" stops sending out the LOOP frames. That is why it seems to resolve your problem, but in the reality, you are just disabling the mechanism that detects the problem but the problem itself remains. It's like sweeping it under carpet and pretending it is not there - but it is there, and may come back to bite you badly.
This problem definitely requires further troubleshooting down of Gi1/0/24 of the switch that is seeing the port being err-disabled.
It might be possible that if you disable the keepalives, your Gi1/0/24 will still be blocked by STP if even STP hears back its own BPDUs - in that case, the port will be marked as Broken (BKN) in the "show spanning-tree" output.
But even if it isn't, there is no valid acceptable reason for the LOOP frames from Gi1/0/24 to come back to Gi1/0/24. Deactivating the LOOP frames with "no keepalive" under these circumstances is a ticking bomb waiting to go off.
So you are saying the Gi1/0/24 of the Cat9200 switch you were able to show us is connected to the other Cat9200 switch? How is that switch configured? How is the connection done - is it a direct UTP connection and a cable run with no devices, active or passive, on it, or are there any patch panels, patch cords, cable splices / connectors, ...?
Best regards,
Peter
