11-07-2006 01:43 PM - edited 02-21-2020 01:17 AM
Hello everyone-
I have a seemingly simple issue, and I have yet to find an answer. We utilize 18 PIX501 devices for each of our remote terminals.
Recently, I discovered that I cannot execute a successful 'show run' command from certain machines in our home office...and to make it more confusing, it only happens on a few of the PIXs.
All of the machines I have tried are either running Windows XP, 2000, or server 2003...I open a command prompt, telnet to the PIX and enter into the enable prompt with no problems whatsoever.
As soon as I type show run and press enter...the curser just stops, and all I see on the screen is:
User Access Verification
Password:
Type help or '?' for a list of available commands.
panama> en
Password: *************
panama# show run
And the curser just sits and blinks...on the same PIX, from a different machine, I get the config just fine...
Any help would be greatly appreciated. Thanks in advance!!
11-07-2006 02:12 PM
Jake,
There is a software caveat on the PIX where a 'show run' will hang if there is another user on the PIX that has performed the same 'show run' but is at a 'more' prompt.
I think it is possible that a session could be 'left stranded'. Try upgrading or checking bug navigator.
Regards,
Troy
11-08-2006 05:29 AM
Thanks for the reply, Troy. I did check to see if there were any other sessions running...as well as rebooting the PIX just to be sure.
I don't know if it's related, but from the same machine that will hang on the show run, I couldn't do a 'show ?'...seems like anything that returns a great deal of lines.
If I set 'pager lines 24', then I'll get the 24 lines with a
11-08-2006 07:45 AM
You are hitting a bug. The fix is in PIX 6.3.4 software. What version are you running?
I couldn't find the bug id but I did find a reference to corresponded to your exact symptoms.
~Troy
11-08-2006 09:53 AM
Thanks again, Troy.
We are currently running 6.3(5) on all of the PIX devices, including ones where it doesn't hang in the 'show run' on that machine.
User Access Verification
Password:
Type help or '?' for a list of available commands.
panama> en
Password: ***********
panama# show version
Cisco PIX Firewall Version 6.3(5)
Cisco PIX Device Manager Version 3.0(4)
Compiled on Thu 04-Aug-05 21:40 by morlee
11-08-2006 10:12 AM
Jake,
Sorry not to been of much help. This does sound like a bug. I searched through over 1300 software caveats -- I couldn't find anything that fits your description.
Out of curiousity, do you get the same results if you use SSH instead of telnet?
If you would please, open a TAC case. If a TAC engineer can't find a DDTS (software caveat id) then they can capture enough information to file one.
Regards,
Troy
11-13-2006 06:11 AM
Well this weekend, I had a chance to get SSH going on one of the PIXs that would not return a running-config...unfortunately, even SSH has the same issue-
login as: pix
Sent username "pix"
pix@10.150.155.250's password:
Type help or '?' for a list of available commands.
panama>
panama> en
Password: ***********
panama# show run
And that's it- If I get a chance this afternoon, I will open a TAC case. Thanks again for all your help, Troy!
11-08-2006 09:34 PM
I would suggest to use another terminal emulator such as putty.exe and test it in that way it could be an issue related to your telnet application ..
11-09-2006 11:34 AM
Thanks for the input Fernando. We've tried Putty, Hyperterminal, commandline telnet...
And another machine on the same subnet can pull it just fine. I'll try to set up SSH here this evening- see if that gets it.
Thanks for all your help!!
11-13-2006 07:52 AM
This may or may not be related but I've run into an IOS bug that can produce similar symptoms.
If your client machine is too busy to accept the output from your show command it may reduce the TCP window size to throttle the rate at which the output is returned, and may set it to zero to suspend output entirely for a while. When this bug is present, then the far end device stops sending output even when the window size is set back to a non-zero value.
What made this tricky to track down is that "manual" telnet worked fine; this only showed up with an expect script that opened a telnet connection.
About the only way to tell if this is happening is to watch the telnet session with a sniffer and look at the packet headers at the time that it hangs.
Again, I don't know if this applies to your situation or not; but if you can run a sniffer to watch one of these sessions you might learn something useful...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide