03-02-2012 03:46 AM
Dear all, I want to tell you about a very funny incident that happened recently to me and my colleague.
We did an upgrade and reconfiguration for a customer system that internally uses two Brocade 5100 switches. We had to perform FOS upgrade and introduce lots of zoning changes, and we've got a small private LAN switch to perform all of this from our laptops. So we disconnected customer management LAN cables from the switches and let them hung in the rack near the switches as they were fixed with the plastic stripes all over the place, then plugged in our own cables into the LAN management ports and started working.
FOS upgrade from 6.3.x to 6.4.2b went just fine and we started doing the zoning stuff. In the meantime, another customer technician came in and extracted a bunch of the Ethernet cables from under the floor and arranged them into the same rack. These cables were also required for upgrading of the LAN-related components of the same system.
In a few minutes after that, I was done with the bunch of new aliases and thought it's a good time to save my work. I typed "cfgsave", hit Enter, and ... the shell prompt did not came back. I waited for a couple of minutes - nothing has changed. I closed my PuTTY session, opened a new one and immediately checked with "cfgtransshow" to discover that the transaction is hung and is not abortable. "killtelnet" showed me a hung session, then killed this hung session, but "cfgtransshow" output didn't change. Well, a quick discussion with the colleague: the system is completely offline for this large upgrade, both switches are internal to the system without any ISLs - so we decided that "hareboot is always good". Then hareboot didn't work. Then reboot didn't work... Finally, we had to physically turn off/on the switch power supplies.
OK, let's get back to the work. I was copying/pasting my aliases from the closed session into the current one, when my colleague told me that he's got the same issue. The only difference is that he performed "cfgenable" - anyway the shell prompt didn't get back. In a few minutes we end up powercycling another switch. While it was powering up, we opened FOS 7.x release notes and looked through the defects found in 6.4. Of course, nothing is mentioned that would look like what we are facing...
To cut a long story short, when we've got a couple more hangs and power cycles, my colleague discovered that the original customer LAN management cables are inserted into RJ-45 console sockets of the switches... Apparently, the guy who brought the new Ethernet cables into the rack, found a couple of hanging cables and silently stuck them into the most "appropriate-looking" sockets...
So, we removed the wrong "console" cables and then performed cfgsave/cfgenable at least a dozen times without any problems.
Hope that this story might help you sometime,
Good luck and best regards,
06-24-2013 05:40 AM
i had a similar issue. Brocade 5300 with FOS6.4.1a. Very often, zoning modifications were not completed successfully
Current transaction token is 0xfffffff0
Or command cfgsave hang or reboot command did not work.
our setup is an active lan cable in the normal Brocade mgt port.
The serial port is attached to a serial console routers which runs ssh to allow for remote mgt.
After disconnecting console router from Brocade serial port no further issues with zoning activation or reboot command
06-24-2013 06:50 AM
Thank you for sharing it with us, It seems that you had an entertaining day because of this...
On the other hand, it is hard to find but this behavior is reported and documented by Brocade in the Solution SLN605
but, as you have mentioned, there is no DEFECT associated. I assume that Brocade does not consider this an issue, but a non-supported operation instead.
06-24-2013 10:20 AM
well, i agree, in my case (as well as in the mentioned kb solution) we are talking about misconfiguration. nobody should insert ETHERNET cable into the RS232 socket and suppose that this will work
06-25-2013 01:23 AM
I suppose that in the situation described by Stefan, the issue is similar: I reckon that the problem here is that the device in the other end of the cable (serial or ethernet) was not sending the correct signals and that overloaded the switch CPU preventing it from working as expected.
06-06-2014 12:18 PM
We have the same issue with 48K with 6.4.3.c and any suggestions. We are stuck and waiting to do HA failover and then harboot if this doesnt solve.
Any suggestions would be appreciated.
06-10-2014 02:07 AM
The root cause of the issue reported in this post was that there was a live ethenet cable connected to the Console port. This caused the switch to misbehave. If this is your case, please remove the ethernet cable from the console port, if this is not your case, your switch is suffering a different issue, so please open a new message and we'll try to help you out.