03-12-2010 03:40 AM
I am fairly new to Juniper and am trying to configure an EX4200 switch on the oob interface using putty ssh and noticed some strange behaviour and I am trying to figure out if it is a JunOS bug or something else.
I was using the show command to verify the configuration on the switch and accidentally pushed the "e" key during the output which prompted the "match except:" option. So I pressed ctrl+c to abort and then enter to return to the commandline. now 10 seconds later (or more - timeframe seems to be random) the CLI freezes completely. I then have to reconnect using a new putty session. (however on some occasions it did unfreeze after 10 minutes or so.)
I tested this a few times and noticed that if I do type some characters after the "match except:" prompt and then press the abort sequence this issue does not occur. only when I leave it blank before pressing abort.
So I was just wondering if this was a know issue / bug ?
Solved! Go to Solution.
03-12-2010 05:23 AM
Thanks for your quick reply
I recently upgraded to 10.0S1.1 but I seem to recall having the same issue when I was using version 9.4R1.8 allthough I am not certain of that. But I still have to unpack another switch which should have an older version installed so I will verify if it has the same issue.
03-12-2010 08:13 AM
This behavior occurs on older releases. I have seen it on 9.6 also. It occurs regardless of CLI connection - IP ssh or console connect.
03-12-2010 09:51 AM
I agree with Kevin, the bug I was thinking of was fixed in 10.0R1 and 9.6R3 (and thus also in 10.0S1 - unless you meant 10.0B1...) - can you please confirm that you are still seeing this behaviour in 10.0 ? If so, then it would appear to be a new bug.
03-12-2010 10:53 AM
Hey David - I just tried it on a couple of my test boxes - one running 10.1x and one running 10.0S3.1 - no problems - Ctrl-C aborts the match and keyboard functionality is returned.
03-15-2010 03:22 AM - edited 03-15-2010 03:24 AM
I am using version [10.0S1.1] and I still get the issue I described.
Just to be clear, after the abort I still have keyboard funtionality for a while, sometimes up to 30 seconds and sometimes I am only able to type just one word (like the example below).
root@CORE> show interfaces terse
Interface Admin Link Proto Local Remote
ge-0/0/0 up down
ge-0/0/0.0 up down eth-switch
ge-0/0/1 up down
ge-0/0/1.0 up down eth-switch
ge-0/0/2 up down
ge-0/0/2.0 up down aenet --> ae0.0
ge-0/0/3 up down
ge-0/0/3.0 up down aenet --> ae0.0
ge-0/0/4 up up
ge-0/0/4.0 up up aenet --> ae1.0
ge-0/0/5 up up
ge-0/0/5.0 up up aenet --> ae1.0
ge-0/0/6 up down
ge-0/0/6.0 up down aenet --> ae2.0
ge-0/0/7 up down
ge-0/0/7.0 up down aenet --> ae2.0
ge-0/0/8 up down
ge-0/0/8.0 up down aenet --> ae3.0
ge-0/0/9 up down
ge-0/0/9.0 up down aenet --> ae3.0
ge-0/0/10 up down
ge-0/0/10.0 up down aenet --> ae4.0
Match except: [abort]
At this point I seem to be able to press the abort sequence again, which returns me to the commandline after a few seconds. But then it freezes again a bit later, until at some point abort doesn't seem to work either
Here it got stuck completely, waited for about 5 minutes
03-15-2010 03:50 AM
This is definitely a bug but I'm not aware of any like this in 10.0...
Do you have access to JTAC ? At this point, I would recommend opening a case for further assistance - hopefully, they will be able to reproduce this and submit a new PR.
Is this problem reproducible 100% of the time ? Have you tried using a different "terminal" application just to be sure that this is not a client issue ?
03-16-2010 01:25 AM
well it isn't a big issue anyway because the way to reproduce it is hardly ever used, I stumbled on it by accident. So it is hardly worth creating a case for in my opinion.
I did a few more tests with JTA (Java telnet/ssh). This time the command line does not block while I am stroking random keys after the abort sequence (like it did with putty) but it freezes instantly when I actually press enter.
Anyway I will just have to remember not to abort a "match except" prompt