~ At my previous job we used Digi terminal servers. These terminal ~ servers allowed multiple connections to the same TTY port. For ~ example, you could do this: ~ telnet 2001 ~ telnet 2001 ~ telnet 2001 ~ and then have 3 connections to the same port. This was great for ~ debugging issues.
So to get clear ... you have three TCP connections to the terminal server, and all three of these simultaneously connect to the same physical async line?
Does this mean: all data received from the async line is transmitted on all three TCP connections? And that any data received from any one of the TCP connections, is transmitted out the async line?
If so: we do not have such a feature, sorry. [*]
~ Now I have a new job, and we use Cisco AS2511-RJ terminal servers and ~ I cannot get it to accept multiple connections. After going through ~ the online manuals I found the ?session-limit? command that is used in ~ ?line configuration? mode. This appeared to be what I needed. ~ session-limit session-number - Sets the maximum number of ~ simultaneous sessions. ~
formatting link
This session-limit only applies to what we call "outgoing" connections i.e. where there is a terminal (or equivalent) physically connected to the given async line, and where it uses the IOS CLI (the "exec") to make multiple "outgoing" telnet (or other protocol) connections. In this scenario, one async line can have multiple concurrent connections ... however, only one of these connections is active at any one time.
This does not however apply to your scenario, where you have "incoming" aka "reverse telnet" connections. Only a single connection per physical line is supported.
One feature you may be able to take advantage of (if you have recent enough IOS) is the "monitor traffic" command.
formatting link
will still have a single "reverse telnet" connection to the router, whose client->server data would be forwarded to the async line, and whose server->client data path would get the data received from the async line. However, one or more other telnet sessions into the router could monitor the async line's data path at the same time. (Alas, these sessions can only watch the line data in one direction - receive or transmit, but not both at the same time.)
Hth,
Aaron
[*] You actually might be able to cobble something together using udptn. I.e. each async line would participate in a udptn multicast group on a UDP port unique to that line. To talk to that line, you would then telnet to a router vty, and then launch a udptn session to the desired multicast group.
In fact I tested this just now (on a 3640 running 12.4(19)), and it did seem to work. I.e. it goes something like this:
line aux 0 ! this is the physical async line of interest here exec modem dialin ! if the device on this line does not hold the signal that's strapped to our DSR ! high, then either loop our DTR back to our DSR, or else use "no modem dialin" ! and "no activation-character" - this will then depend on the device to send some ! data in order to bring up the exec and start UDPTN udptn 255.255.255.255 1111 line vty 0 4 ! on your 2511, you'd want to have a LOT of vtys transport output all ! enables udptn
So now, if I want to talk to line aux 0, instead of doing a "telnet router.ip.addr 2017" (assuming that aux 0 is line 17), I would just do a "telnet route.ip.addr" then at the exec prompt, enter "udptn 255.255.255.255 1111".
(A more sophisticated implementation would use real multicast, not just broadcast.)