strange behaviour

[chipitsine1]

<5500G-EI>system-view


 Command synchronization failed, please try later...


<5500G-EI>


 

what is it ?

[Fred_Mancen_1]

Are your switches stacked? If the answer is ' yes', this is why because the units in the stack are running the synchronization process (configuration file, switching and routing tables, etc).

Regards

[chipitsine1]

yes, switches are stacked. could synchronization be running for hours ? how can I check what exactly is being synchronized ? And does it take so long ?

[chipitsine1]

up

[chipitsine1]

up

[Fred_Mancen_1]

Hi. No, this process does not take so much time. There is a problem in your stack, probably. Make a double check in it:

1. Check the file system of the units in the stack. All of the switches need to have exactly the same firmware version, and the same.

2. Check the sysname of the units; all the switches need to have the same sysname.

3. Check the physical connections of the stack cables.

If all the requirements above are ok, I would suggest you to perform a firmware upgrade in the whole stack, then reboot it. Sometimes even a .cfg file with a different name or that is corrupted can force a sync loop.

HTH

[chipitsine1]

1. how to check filesystem ?

2. sysname is identical, stack had been running for months

3. nothing happened to cables. I was just playing with line speed and duplex on certain port and stack became broken

4. there's no new firmware for 5500G-EI since March 2010

yes, reboot did help. but it was not a good idea, there're many servers and we cannot reboot entire stack frequently.

[Fred_Mancen_1]

In order to check the stack file system, enter the command:

dir /fabric

The console will show you all the unit's file system. Compare it and fix any inconsistency. What do the commands dis xrn and dis ftm topology shows in the output?

A couple years ago I was troubleshooting a case like yours, and the problem was the configuration file of one unit in the stack. At that case I just performed a backup of the configuration file of the failed unit, edit it, and then uploaded it again to the unit, writing the new file with the command save. Before save the configuration I renamed the corrupted file as 3comoscfg-old.cfg and then uploaded the new file. In less than 7 minutes the stack was running fine again.

HTH