RE: RE: Transport Input Telnet and Terminal Servers [7:33511]
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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=33562t=33511 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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=7i=33605t=33511 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: RE: Transport Input Telnet and Terminal Servers [7:33511]
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
