Switching

Hello,

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 ?

Hi Kirs,

I have seen a couple of similar issues... Could you please let us know what version you are running ? I'll see if I can dig-up a bug.

Thanks,

/david

Hi David,

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.

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.

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.

Regards,

/david

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.

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]

---(more 23%)---
{master:0}
root@CORE> this

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

root@CORE> this[abort]
[abort]
[abort]

               ^
syntax error.
root@CORE> this

Here it got stuck completely, waited for about 5 minutes

Hi Kris,

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 ?

Regards,

/david

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

FYI

I managed to test today on a ex4200-24t straight out of the box, running version  [9.2R3.5] and it does not have this issue.

Hi Kris,

I just came across this bug myself - turns out there is still an issue in recent releases specifically at the "match" prompt when you hit ctrl-c. This is: 493881 - CLI is getting stuck when the user is retrieving interface stats

This PR is fixed in 10.0R3 (due to be released mid-April) and was the one you were hitting in 10.0S1.

Regards,

/david