On Cisco routers, the asynchronous ports by default are set to send traffic with the TxD (transmit data) pin when activated by a protocol. As soon as input is received on the RxD (receive data) pin, the router engages an Exec process. I only said this to get a point of reference going. This is the natural forward direction of communication flow. It's more useful to think of this process by assuming the Cisco router is set up only to receive traffic and then engaging an exec process to handle the traffic.
The reverse direction is to INITIATE communication by binding the asynchronous ports to some sort of transport protocol. This 'transport protocol' could be any communication capable protocol. Instead of waiting for an exec process starting because traffic was received on the RxD pins, the router is set up to activate an exec process as soon as a transport protocol is initiated by a user. In the case of the tcp transport protocol the router is set up to initiate communication whenever a tcp socket (tcp port 2000 + line number for telnet in Ascii mode) is established from any active IP address on the router. It would bring up the async line and send what ever data tcp sends over the async line. Telnet is a method as well as an application that manages the tcp protocol stream from the user perspective. It resides totally within the data portion of a tcp segment. Telnet is active on a tcp stream whenever you use the telnet application or any application that communicates with such a protocol. Take a look at RFC 854-856 for a more involved study of telnet. WAYNE BAETY, MCSE, A1C, USAF Network Systems Trainer > -----Original Message----- > From: John Neiberger [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 6:15 AM > To: [EMAIL PROTECTED] > Subject: RE: RE: Transport Input Telnet and Terminal Servers [7:33511] > > 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=33625&t=33511 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
