I think, as is often the case, I wasn't clear enough. Let me try to restate the issue another way.
When you connect a terminal server to a console port, the telnet protocol is not operating on that link. That link is a simple async serial terminal session. Because of that, I don't understand why "transport input telnet" works: the input is *not* telnet, it's async serial! If you telnet to a terminal server and from there do a reverse telnet to a device, your actual telnet session--and I'm being very specific here--stops at the terminal server. The protocol being carried on the async line is *not* telnet. Does that make more sense? Okay, back to the coffee for me... Thanks, John ---- On Mon, 28 Jan 2002, Daniel Cotts ([EMAIL PROTECTED]) wrote: > "all" works because telnet is a subset of "all" - it is included without > being specifically named. Do a "show line" to determine the mapping of > line > numbers to ports - then do a "show line 1" or whatever. Lots more > output! > Look on the line that starts "Allowed transports" > We are used to configuring terminal servers with ip host mapping a name > to > an ip and port. A more bare bones implementation would have us "telnet > 2002" > or whatever port we wished to reach. Try that. > > > -----Original Message----- > > From: John Neiberger [mailto:[EMAIL PROTECTED]] > > Sent: Monday, January 28, 2002 4:28 PM > > To: [EMAIL PROTECTED] > > Subject: Transport Input Telnet and Terminal Servers [7:33511] > > > > > > I was in a discussion with someone this weekend regarding terminal > > server configuration and the following issue came up. CCO states that > > on the terminal server, at the very least "transport input > > telnet" needs > > to be configured, if not "transport input all". Why is this? > > > > With a terminal server, we are connecting to a console port > > that has no > > concept of IP or telnet. You connect to the console port using async > > serial terminal protocols, *not* telnet. Sure, it may be > > called Reverse > > Telnet, but the telnet protocol is not end-to-end; it stops at the > > terminal server. From the terminal server to the device it > > is connected > > to you are simply using async serial. So, why do we need transport > > input telnet?? > > > > We did verify that without this command it will not work. Also, why > > would the ALL keyword work? As far as I can see, none of the > > available > > protocols make any sense in this context. > > > > Just curious. Perhaps I'm suffering from a brain cloud today. :-) > > > > John [EMAIL PROTECTED] > > ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=33538&t=33511 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
