Explicit configuration of "exec" under line vty??

[Vadym.BYELYAYEV]

Hello,

I have had an issue, where an ASR 1002-X 03.16.6S XE did not allow the incoming connections (telnet or ssh), without explicitly configuring the "exec" command under line vty..

This is a strange behavior, because first, it did not have "no exec" under the line vty and second, because after I issued "exec " command, it took it, but it does not appear in the config..

The issue was resolved after manually issuing the command.

The message was "the connection was closed by foreign host"

And the debug showed that the ssh session terminated normally

00:12:43: SSH2 0: MAC compared for #8 :ok
00:12:43: SSH2 0: input: padlength 12 bytes
00:12:43: SSH2 0: send:packet of  length 16 (length also includes padlen of 6)
00:12:43: SSH2 0: computed MAC for sequence no.#8 type 99
00:12:43: SSH2 0: shell request
00:12:43: SSH2 0: shell message received
00:12:43: SSH2 0: starting shell for vty
00:12:43: SSH2 0: send:packet of  length 48 (length also includes padlen of 18)
00:12:43: SSH2 0: computed MAC for sequence no.#9 type 98
00:12:43: SSH2 0: send:packet of  length 16 (length also includes padlen of 6)
00:12:43: SSH2 0: computed MAC for sequence no.#10 type 96
00:12:43: SSH2 0: send:packet of  length 16 (length also includes padlen of 6)
00:12:43: SSH2 0: computed MAC for sequence no.#11 type 97
00:12:43: SSH0: Session terminated normally

I would like to know if anyone ever experienced this?

[Richard Burts]

It is hard to know what the original problem was. But it sounds like something got out of sync in the running config which impacted remote access. Enabling exec seems to have got it back in sync and restored the functionality. The fact that exec does not show up in the output of show run is expected behavior. Most default behaviors do not show up in the output of show running-config.

HTH

Rick

[Vadym.BYELYAYEV]

Thank you Richard.

I have another ASR1002-X to replace this week, if I can reproduce the issue, is it logical to assume that this is some kind of a bug?

[Richard Burts]

If another ASR1002-X does show the same symptom it might point toward some type of bug. There are a number of things that we do not know about your situation which might be helpful to explore:

- is this a new config on a not used before router?

- or has this router been deployed for a while and then developed the symptom?

- if it has been deployed for a while were there any recent changes?

- was the attempt at access from a single host or did multiple hosts attempt access and experience the same problem?

HTH

Rick

[Vadym.BYELYAYEV]

-This config was previously used on an 1800 router, which was in production for years. I am migrating the config to this ASR and removing an intermediate ISP switch (connecting the ASR directly to 2 ISP last mile devices)

-The access was first performed with a local user during a maintenance window by one coworker. Later this behavior was confirmed by me (telneting a directly connected switch and then initiating another backward telnet to this same router. In that moment I thought that maybe such connections were not allowed, if you enter a directly connected device and then initate a telnet/ssh back to the original device, but it seems that it was not the case) Later, when the tacacs config was uploaded to router, the issue persisted. When you were introducing a tacacs username it would just not let you in.

The router was also rebooted, but the issue persisted until explicitly configured with exec command.

[Richard Burts]

Thanks for the additional information. The config may have been used on 1800 router. But there is so much different between the code for 1800 and for ASR that we should consider this as a fresh config on not used before hardware. So there is not any consideration of whether there have been changes in a working config.

It is good to know that the symptoms were observed in attempts from multiple hosts. And to know that the router was rebooted but that did not affect the symptoms. It is interesting that the debug shows normal processing on the ASR for the attempt to SSH. If there had really been a "no exec"in the config then I would expect to see no SSH processing. So I continue to believe that something got out of sync and that configuring exec reset something and got it back into sync. Please do let us know if another ASR has the same symptoms.

HTH

Rick

[Vadym.BYELYAYEV]

I resolved the issue by looking for an ssh debug and googling it.

You know, when you explicitly configure no exec under line vty the ssh shows the same (that the session terminated normally)

I used this link

https://supportforums.cisco.com/t5/wan-routing-and-switching/telnet-ssh-not-working-strange/td-p/1498434

Anyway, I will have another window this week and see how another ASR behaves.

Thanks a lot Richard!!

[Richard Burts]

In the link that you reference the issue clearly was that "no exec" was configured on the vty. That does not seem to be the case with your issue. Please do let us know what happens with your next ASR.

HTH

Rick 

[Vadym.BYELYAYEV]

Hello Richard,

I think it was my mistake. For some reason the ASR1002-X created:

line vty 0

no-exec

line vty 0 4

login local

transport input ssh

line vty 5 15

login local transport input ssh

Every new connection I was initiating was falling under vty 0 which had no-exec..

First I did line vty 1 15, exec, but that did not fix the issue (because vty 0 still had no-exec...)

I must have confused the line vty 0 with a case where for example you have 2 line consoles in a router, where the first one is where you are connected and the second one is disconnected..

Sorry for any confusion caused!

[Richard Burts · Accepted solution]

Thanks for the additional information and explanation. Yes if vty 0 had configured no exec then every attempt for remote connection would have attempted vty 0 and would fail. I am glad that you figured out what was going on and successfully resolved the issue.

HTH

Rick