Cisco Support Community
Community Member

Front-End Loopback Test on Catalyst 2955 causes connected hardware to "die"

I have recently purchased a Cisco Catalyst model WS-2955C-12 switch. During POST (boot), the console reports that the switch undergoes what is known as a "FRONT-END LOOPBACK TEST". During this test the 14 port lights on the device light up amber for a moment, connectivity is lost, and after a second or two the lights go off and connectivity returns. We've found that the moment the lights go off at the end of this test, if we have a specific device (with a specific ethernet chip) directly connected to the switch the ethernet chip is adversely affected by this test - the device "goes dark" and is not capable of communicating with anything (including other switches, routers, etc...) until it is power-cycled. What exactly does this FRONT-END LOOPBACK TEST do, and what does it send across the wire that could be causing my ethernet chip onboard the device to go bonkers?




Re: Front-End Loopback Test on Catalyst 2955 causes connected ha

Cisco IOS Release 12.1(22)EA1 runs on Catalyst 2955, Catalyst 2950, and Catalyst 2940 switches.

Review the new software features, open caveats, and resolved caveats sections for information specific to your switch. The information in this document refers to all the switches, unless otherwise noted.

These release notes include important information about this release and any limitations, restrictions, and caveats that apply to it. To verify that these are the correct release notes for your switch:

If you are installing a new switch, refer to the Cisco IOS release label on the rear panel of your switch.

If your switch is running, you can use the show version user EXEC command. See the "Finding the Software Version and Feature Set" section.

If you are upgrading to a new release, refer to the software upgrade filename for the Cisco IOS version.

Community Member

Re: Front-End Loopback Test on Catalyst 2955 causes connected ha

After speaking with an STMicro engineer, and doing some more investigation on our own, we were able to determine the following:

1. We are observing a "bug" in the STE10/100A chip that deals with Autonegotiation.

2. When a port is disabled, it still responds to autonegotiation requests but the capabilities list is "empty", i.e. the port reports that it supports no valid configuration states.

3. The STE10/100A chip hangs in the autonegotiation because there is no valid configuration that it can set itself to.

4. We must kick-start the autonegotiation manually until the autonegotiation is a success.

It appears all other ethernet chips ignore autonegotiation attempts where the link partner reponds that there is no valid configuration supported.

My question now is: Is this part of the spec? Are disabled ports supposed to still respond to autonegotiation, and then respond with no capabilities supported?


CreatePlease to create content