That makes sense except for the fact that the telnet protocol is *not* running on the console link! It's called reverse telnet but that doesn't describe the protocol that is actually on the link itself. That's why it's curious to me why I would have to permit telnet for it to work.
I blame you for getting me on this thread in the first place! :-) But I'd really like to find an answer. ---- On Tue, 29 Jan 2002, Ouellette, Tim ([EMAIL PROTECTED]) wrote: > Are you still going on about this *grin* > > Sure feels weird being call the "someone" in your earlier comment of "I > was > in a discussion with someone this weekend regarding terminal server > configuration". Hehhehe. The conclusion I came up with is as > followings. > Let's say your on a router and you ping your ethernet interface. The > pings > actually goes out on the wire and loops back to test your own interface > (obviously loopbacks are different). But I would think that in the > concept > of a telnet, the reverse telnet goes out on the wire to the far end and > then > loops back establishing a connection? Also, as an FYI, when a do a > "transport input all" on my terminal server, it substitues "transport > input > LAT MOP TELNET blah blah" for me. So the telnet is actually a subset of > the > ALL parameter.? > > Did that make any sense or do I need more coffee? > > Tim > > -----Original Message----- > From: John Neiberger [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 28, 2002 9:59 PM > To: [EMAIL PROTECTED] > Subject: Re: RE: Transport Input Telnet and Terminal Servers [7:33511] > > > 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 [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=33605&t=33511 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
