Why the name Reverse Telnet ?

Unanswered Question
Jul 28th, 2010

Forgive me for this simple ( and to some, stupid) question. Why is reaching the console ports of devices attached to a terminal server called Reverse Telnet. I am confused about the "Reverse" part.

1. You reach "terminal server" by some suiteable means (telnet, ssh, console) from a device say your computer.

    c:\> telnet

    termsrv >

2. You effectivily telnet to localhost (terminal server) on a specific port bound to certain TTY connection

    termsrv > R1                                  ! ip host R1 2001 <<loopback_address_termsrv>>


Whats different for this second telnet is, instead of the telnet server (running on terminal server) presenting you with a second command shell it connects the mapped console port to the new telnet session. Effectively you read from or write to console port of R1.

R1 is oblivious about this whole operation. What's so "Reverse" about this second telnet session ?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Richard Burts Fri, 07/30/2010 - 15:38

I have never seen any "official" explanation of the term but I am glad to share with you what are my thoughts on it.

First, let me review a concept: on the term server for reverse telnet to work you configure host names that associate the host name with a specific (special) port (20xx) and the 20xx ports are associated with async lines on the router. So you configure a host name for R1 that associates it with a specific port (and indirectly) with a specific asyn line.

So my understanding of the term:

- normal telnet is a command that is issued on the local device and it establishes a connection to a remote device.

- reverse telnet is a command that is issued on the local device and it establishes a connection to the local device (that is the reverse part) and the connection on the local device is to a async port that takes you to the remote device.



seabird505 Fri, 07/30/2010 - 23:41

Thanks for your reply. The way you understood is no doubt a step closer to a clearer concept; although one may argue that still its Self Telnet not Reverse Telnet. I must confess that for some time, my concept about this very simple to implement task was that its just Telnet but in reverse direction like from the managed device (router/switch) to the terminal server itsself. What I failed to realize then was the link between the two is serial and the relationship between the two is not client-server w.r.t. Telnet protocol.

Some argue that direction of data (who reads to or writes from the connection) is reversed. But I don't think that happens. In normal telnet, you give input on the extended command prompt on client side which is passed on by the Telnet server to the operating system, results fetched and send back to the client by the telnet server. In Reverse Telnet, same things happens. Client type commands, instead of being passed to OS they are placed on the serial line (through a port number in 2xxx range) and results fetched from the serial line to be send back to the client. Sort of a Proxy Telnet !

Similar confusion happened to me with VTP (Vlan Trunking Protocol) which I think should be appropriatly renamed as Vlan Replication Protocol

Thanks for sharing your thoughts.

Richard Burts Sat, 07/31/2010 - 07:24

Thinking about your comments, perhaps it is enough to say that in normal telnet the destionation is outbound from the local interface and in reverse telnet the destination is inbound to the local interface and so it is the reverse of normal telnet.



Paolo Bevilacqua Fri, 08/20/2010 - 05:17

Similar confusion happened to me with VTP (Vlan Trunking Protocol) which  I think should be appropriatly renamed as Vlan Replication Protocol

The moniker name is another actually. Very Troubled Protocol. Just think VTP v3

Phillip Remaker Tue, 08/17/2010 - 14:53

Ah, this is a good question.  Step into my time machine, and travel with me back to late eighties.  The 3Com 3C501 PC Ethernet card was released at the bargain basement price of $999 USD and the mighty Interl 386-DX33 was released to great fanfare.  Windows ran on top of DOS and all PC IP networking stacks were 3rd-party bolt-ons.  When you communicated with a computer, whether DEC, IBM or whomever you did it with a DUMB TERMINAL.  A terminal, for thos eof you who have never sern one,  was either a keyboard and a printer combo (like a Decwriter 100)  or a CRT text screen (Like a VT220, 80 columns by 24 lines) and a keyboard.  What you typed went out the serial port to a computer, and the computer sent text and screen drawing back commands through that same serial port.  That was the common human-computer interface of that era.

In the bad old days, the terminals were connected directly to the computers by serial interface cards and RS-232 cable.  As computers got faster, more and more terminals could be supported.  This started to get ridiculous as many serial lines emerged from these computers.  The bigger computers  looked like a mutant octopus.

Enter the TERMINAL SERVER, one of Cisco's early products. (The ASM)

The Cisco ASM terminal server took up to 96 terminals in an area and provided serial port connections for them.  It then multiplexed those terminals over Ethernet in order to reach an Ethernet connected computer (host).  The host computers were now freed from the sea of serial cables and could service dozens to hundreds of terminals thorough a single Ethernet port!   As a result, dozens to hundreds of slow, lightly used 9600 bps serial cables were replaced by a single 10 Mbit/sec connection.

The Cisco ASM software provided a telnet client to each serial port so that each terminal could connect to any telnet server (host) on the any network.  This allowed users to connect to multiple computers and relieved the load of computers providing telnet client services to directly attached terminals.  In this model, connections were initiated from a terminal on the port of the Cisco ASM to some distant computer.

Over time, Cisco noticed that there were computers and other devices (like the IBM 7171) that could not support Ethernet conenctions, but had dozens upon dozens of physical serial ports.  To make it so that network based telnet clients all over the Internet could access such an Ethernet-free computer, Cisco implemented a telnet SERVER function in the ASM.  Connections from a distant telnet client could now conenct through the ASM telnet server and reach these serial ports which had previously been limited to local terminals or expensive modem connections.  Since this activity was the exact reverse of the original use of the ASM, the function became known as "Reverse telnet."

In summary:  When a serially attached device CONSUMES service FROM the network, that is TELNET.  (The original design!)

When a serially attached device PROVIDES services TO the network, that is REVERSE TELNET. (The opposite of the original design.  But useful!)

Now, I will wait for people who have been in the industry longer than I have to go on about SNA, 3270s, paper tape and punch cards.

Paolo Bevilacqua Fri, 08/20/2010 - 05:15

Great story Phillip

The only way I could make better would be interspersing it with ridicouosly low IOS versions for ACS, like 8.0 (if ever existed ?!?)

There was still some 9.x box around when I started tinkering with routers. Cisco was not making anything else back then. But I liked what I saw and jumped in, got my fair share of tales to tell

BTW, 96 (working) lines - still an impressive number even today!

Phillip Remaker Fri, 08/20/2010 - 14:40

I started using the ASM in 1989, with the 7.1 code (it didn't get called "IOS" until the 10.0 release and branding campaign).

More trivia notes on the ASM:

The lines were originally numbered in octal.  The command "service decimal-tty" was added to reduce confusion.

The system has 9 slots:  An NVRAM card, a Processor, a Network Card, and up to 6 16 port cards:

The 96 line limit was raised to 112 when the multibus NVRAM card was replaced by a slotless memory card connecting to the processor with a ribbon cable.  An optional form of that card also introduced Flash Memory to the series, which had previously only been upgradeable by TFTP loading an image to RAM or changing out the EPROMS.

The pre 10.0 IOS version progression (from my memory) was:

6.1, 7.0, 7.1, 8.0, 8.1, 8.2, 8.3, 9.0, 9.1, 9.21 (with special spurs of 9.14 for the new Cisco 4000 and 9.17 for the new Cisco 7000).

Docs back to 8.3 can be found at http://www.cisco.com/univercd/cc/td/doc/product/software/index.htm.

Once you started to use IOS 9.21 with the 'new' parser, line editing and command completion, you chould never go back to 9.1.

Thus ends today's IOS archeaology report.


This Discussion