Why the router refuses to let you telnet
Introduction
I have been working with Cisco equipment for several years now, but I ran into this problem for the first time. Although it may not be the first time :). I can’t say for sure, as there were a lot of troubles and misunderstandings, due to the fact that I set up the work and studied them at the same time. But earlier, most likely everything was decided by an ordinary hard cutter, but now I figured out what was wrong.
What was the occasion?
One day I needed to go remotely to one of the Cisco routers to see the output of sh ver. I usually log in from my Windows OS machine using Putty. As usual, the terminal window opened, and ..., without giving out any text information with the velcom and an invitation to login, it immediately closed without giving any reasons.
I tried from the linux server:
')
After trying a few more times with the same result from other hosts, I decided a bit
kick your wall to think :)
And that's what was discovered and invented.
Since there was no firewall and ACL from me in the direction of the router, and I went to the router before this many times last week, setting up a tunnel, I concluded that the free vty line ended. Of course, I came to this conclusion not so quickly and immediately, there were various assumptions, but it helped that I hadn’t met any glitches in the tsiska, the router for routing information and cdp worked, I really don’t believe in miracles, I went to the router just a couple of days back and still remember about the config, plus the other day I read the blog of one tsiskovod, where he just tuned these same vty line .
What was done?
Last week, I set up a tunnel through the partner networks to another such router on this router (by the way, Cisco 1841). In order for the terminal window not to close due to inactivity during debug output, in the line vty settings I set the exec-timeout 0 0 parameter (the idle time is 0 minutes 0 seconds, that is, the session will hang almost forever).
In the process of setting up several times went out of order, that is, simply closed the terminal window. As a result, all of my telnet sessions remained open and busy, and when I tried to log on to the router again, I wasn’t allowed to go.
It was only lucky that the http protocol was still open and it helped diagnose and solve the problem.
What should be done ?
You need to see the consolidated status of TCP connections:
The first column is the TCB address (Transmission Control Block address of the established TCP connection). By analogy with * nix, we can say that this is the PID of the process that can be killed:
to confirm by pressing "y" we kill this session.
Thus, after removing TCP sessions, I freed up the vty lines and was able to telnet to the router.
I would also like to note that in more detail about a TCP connection, you can find out by entering the command:
For example:
PS I read Habr for a long time, often there is a desire to comment on this or that post. So, documenting the above in my wiki, I thought that maybe it would be interesting for someone else too.
Taking advantage of this opportunity, I want to note that this is my first post on Habré and, I hope, not the last :)
PSS Today I found on the same opennet the same solution, but published in 2004 - http://www.opennet.ru/tips/info/720.shtml . I want to note that my post is not plagiarism, but 100% independent work.
I have been working with Cisco equipment for several years now, but I ran into this problem for the first time. Although it may not be the first time :). I can’t say for sure, as there were a lot of troubles and misunderstandings, due to the fact that I set up the work and studied them at the same time. But earlier, most likely everything was decided by an ordinary hard cutter, but now I figured out what was wrong.
What was the occasion?
One day I needed to go remotely to one of the Cisco routers to see the output of sh ver. I usually log in from my Windows OS machine using Putty. As usual, the terminal window opened, and ..., without giving out any text information with the velcom and an invitation to login, it immediately closed without giving any reasons.
I tried from the linux server:
')
[valent@linux ~]$ telnet 10.15.xxx.yy
Trying 10.15.xxx.yy...
telnet: connect to address 10.15.xxx.yy: Connection refused
telnet: Unable to connect to remote host: Connection refused
After trying a few more times with the same result from other hosts, I decided a bit
And that's what was discovered and invented.
Since there was no firewall and ACL from me in the direction of the router, and I went to the router before this many times last week, setting up a tunnel, I concluded that the free vty line ended. Of course, I came to this conclusion not so quickly and immediately, there were various assumptions, but it helped that I hadn’t met any glitches in the tsiska, the router for routing information and cdp worked, I really don’t believe in miracles, I went to the router just a couple of days back and still remember about the config, plus the other day I read the blog of one tsiskovod, where he just tuned these same vty line .
What was done?
Last week, I set up a tunnel through the partner networks to another such router on this router (by the way, Cisco 1841). In order for the terminal window not to close due to inactivity during debug output, in the line vty settings I set the exec-timeout 0 0 parameter (the idle time is 0 minutes 0 seconds, that is, the session will hang almost forever).
In the process of setting up several times went out of order, that is, simply closed the terminal window. As a result, all of my telnet sessions remained open and busy, and when I tried to log on to the router again, I wasn’t allowed to go.
It was only lucky that the http protocol was still open and it helped diagnose and solve the problem.
What should be done ?
You need to see the consolidated status of TCP connections:
cisco#show tcp brief
TCB Local Address Foreign Address (state)
8173B78C 10.15.xxx.yy.23 10.15.aa.bb.2530 ESTAB
...
80CCEB24 10.15.xxx.yy.23 10.15.aa.bb.4427 ESTAB
The first column is the TCB address (Transmission Control Block address of the established TCP connection). By analogy with * nix, we can say that this is the PID of the process that can be killed:
router#clear tcp tcb 8173B78C
[confirm]
to confirm by pressing "y" we kill this session.
Thus, after removing TCP sessions, I freed up the vty lines and was able to telnet to the router.
I would also like to note that in more detail about a TCP connection, you can find out by entering the command:
show tcp tcb [TCB address]For example:
router#show tcp tcb 80CCF254
Connection state is ESTAB, I/O status: 1, unread input bytes: 1
Local host: 10.15.xxx.yy, Local port: 23
Foreign host: 10.15.aa.bb, Foreign port: 1840
Enqueued packets for retransmit: 1, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x374828A8):
Timer Starts Wakeups Next
Retrans 123 7 0x374829CB
TimeWait 0 0 0x0
AckHold 128 11 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
iss: 2866020113 snduna: 2866027408 sndnxt: 2866027946 sndwnd: 65097
irs: 672352072 rcvnxt: 672352285 rcvwnd: 3916 delrcvwnd: 212
SRTT: 302 ms, RTTO: 319 ms, RTV: 17 ms, KRTT: 0 ms
minRTT: 156 ms, maxRTT: 564 ms, ACK hold: 200 ms
Flags: passive open, higher precedence, retransmission timeout
Datagrams (max data segment is 536 bytes):
Rcvd: 248 (out of order: 0), with data: 137, total data bytes: 212
Sent: 166 (retransmit: 7, fastretransmit: 0), with data: 154, total data bytes: 8368
PS I read Habr for a long time, often there is a desire to comment on this or that post. So, documenting the above in my wiki, I thought that maybe it would be interesting for someone else too.
Taking advantage of this opportunity, I want to note that this is my first post on Habré and, I hope, not the last :)
PSS Today I found on the same opennet the same solution, but published in 2004 - http://www.opennet.ru/tips/info/720.shtml . I want to note that my post is not plagiarism, but 100% independent work.
Source: https://habr.com/ru/post/82694/
All Articles