C.Chaundy@its.unimelb.edu.au (04/12/91)
Is it possible to use SLIP with an STS-10X terminal servers to connect two IP networks together, or are there plans to provide this functionality? I have heard that STS-10X servers only permit a single host to be connected via SLIP (i.e., they do not handle routing for networks other than those defined for the SLIP interfaces). Chris Chaundy Technical Manager, Networks, Information Technology Services, The University of Melbourne Internet: C.Chaundy@its.unimelb.EDU.AU (DTE 505233430003) Phone: +61 3 344 7045 Cables Unimelb Fax: +61 3 347 4803 Telex AA35185 Post: Parkville, Victoria 3052 Australia
schoff@psi.com (Martin Lee Schoffstall) (04/12/91)
It is not possible. They do not route. You have to buy a trouter to to what you are interested in. Speaking of sts-10x's and msm's, does anyone out there beside us have a strong desire to see them upgraded to support async PPP? (Routing I can do without). Marty ------- Is it possible to use SLIP with an STS-10X terminal servers to connect two IP networks together, or are there plans to provide this functionality? I have heard that STS-10X servers only permit a single host to be connected via SLIP (i.e., they do not handle routing for networks other than those defined for the SLIP interfaces). Chris Chaundy Technical Manager, Networks, Information Technology Services, The University of Melbourne Internet: C.Chaundy@its.unimelb.EDU.AU (DTE 505233430003) Phone: +61 3 344 7045 Cables Unimelb Fax: +61 3 347 4803 Telex AA35185 Post: Parkville, Victoria 3052 Australia
danj@cac.washington.edu (Dan Jordt) (04/13/91)
> Speaking of sts-10x's and msm's, does anyone out there beside us > have a strong desire to see them upgraded to support async PPP? > (Routing I can do without). > Marty Yes, we've been asking for this for months. We see this as our only scalable option for dial-up IP. -Dan Jordt, UW-Seattle
RAF@CU.NIH.GOV (Roger Fajman) (04/13/91)
> Speaking of sts-10x's and msm's, does anyone out there beside us > have a strong desire to see them upgraded to support async PPP? > (Routing I can do without). > > Marty Me too. I would also like to see the hardware upgraded to better support high speed async modems with bidirectional RTS/CTS flow control. The new crop of V.32bis dial modems run at 14,400 bps (full duplex) on the wire. With the V.42bis compression they can hit peaks of 57,600 bps on the RS-232 interface. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV
"Martin Lee Schoffstall" <schoff@psi.com> (04/13/91)
Unfortunately according to the documentation it appears that both the STS-10x and the MSM are only capable of 38.4kbps on the DTE. This is reasonable in the case of the STS-10x, you can't expect a lot out of the 68000 (other than PPP and extended tacacs). I could be persuaded that this is reasonable even on a msm/3, if I could be assured of having 16-32 ports doing 38.4 which I don't think it will actually do. 38.4Kbps for PPP, SLIP, or X is pretty nice. Marty ------------- Me too. I would also like to see the hardware upgraded to better support high speed async modems with bidirectional RTS/CTS flow control. The new crop of V.32bis dial modems run at 14,400 bps (full duplex) on the wire. With the V.42bis compression they can hit peaks of 57,600 bps on the RS-232 interface. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV
"Martin Lee Schoffstall" <schoff@psi.com> (04/13/91)
16 is not too bad, certainly better than my expectations of a 386 netblazer (though it does support PPP). given X's io style, output performance working at 38.4 will be fine. Marty -------- I was told recently by cisco that a CSC/3 processor could support 16 lines sending data flat out at 38.4 Kbps (8 lines for a CSC/2). I was also told that the limit is less for incoming data at 38.4 Kbps. This isn't a lot. Cisco lets the modem flow control the terminal server, but not vice-versa, so incoming characters could get dropped. If you connect a hundred lines to an ASM/3, it wouldn't be very hard to overrun it.
"Roger Fajman" <RAF@CU.NIH.GOV> (04/13/91)
> 16 is not too bad, certainly better than my expectations of a 386 > netblazer (though it does support PPP). > > given X's io style, output performance working at 38.4 will be fine. What about other applications, such as FTP? I'm not bothered so much by the limit being what it is, as by the way that I might find out that I've hit it. Users using SLIP or PPP will experience slowdowns as packets get garbled, dropped, and retransmitted. Users with actual terminals will be seeing data dropped at arbitrary points in their sessions. Not friendly. MNP and V.42bis provide error detection and correction on the phone line, but not on the RS-232 interface. I could watch CPU utilization on the CSC/3 processor, but the problem will likely be quite intermittent when it starts to occur, so I would have to be watching at just the right time. Would the new SNMP MIB for RS-232 devices help here?
brian@telebit.com (Brian Lloyd) (04/13/91)
-- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
brian@telebit.com (Brian Lloyd) (04/13/91)
If you are interested in connecting two or more networks together using dial-up modems and SLIP or PPP, consider looking at the Telebit NetBlazer. It was explicitly designed as a dial-up IP router. -- Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333
BILLW@mathom.cisco.com (WilliamChops Westfield) (04/16/91)
Using a TCP connection (sun sending to port 40xx of a terminal server), the csc/3, csc/2 and sts10 have aggregate data rates (apparently interrupt limited) of about 60k, 30k, and 12k bytes/sec, respectively. This is essentially the same for telnet doing output to the screen. SLIP uses a rather different interrupt handler, and its performance has not been measured. It should be somewhat faster... The next release of software (8.3) will support some odd baud rates including 14.4kbps and 57.6kbps (with the same overall throughput). It will also support NCD's "Xremote" X compression protocol, which makes X rather nice even over a 9.6kbps link. While some TS vendors advertise the ability to operate all lines at max speed in both directions concurrently, what this generally means is that they are vastly over-engineered for the normal operating point of a terminal server... Bill Westfield cisco Systems. -------
RAF@CU.NIH.GOV (Roger Fajman) (04/16/91)
> While some TS vendors advertise the ability to operate all lines at > max speed in both directions concurrently, what this generally means > is that they are vastly over-engineered for the normal operating point > of a terminal server... > > Bill Westfield > cisco Systems. > ------- It isn't that the cisco terminal servers can't support all lines running at max speed that really bothers me, it's that they will simply drop data if they reach saturation, rather than just slowing down. Since I don't know in advance exactly what my users will be doing, it's difficult to be sure that my configuration won't saturate. Since the penalty is so severe for overloading the box, I will have to over-design the configuration anyway.
schoff@psi.com (Martin Lee Schoffstall) (04/16/91)
While some TS vendors advertise the ability to operate all lines at max speed in both directions concurrently, what this generally means is that they are vastly over-engineered for the normal operating point of a terminal server... And hence have higher life cycle cost.... A good point. M
schoff@psi.com (Martin Lee Schoffstall) (04/16/91)
But for SLIP/PPP that's just fine, that how's we do congestion control in datagram networks................ Marty It isn't that the cisco terminal servers can't support all lines running at max speed that really bothers me, it's that they will simply drop data if they reach saturation, rather than just slowing down. Since I don't know in advance exactly what my users will be doing, it's difficult to be sure that my configuration won't saturate. Since the penalty is so severe for overloading the box, I will have to over-design the configuration anyway.
RAF@CU.NIH.GOV (Roger Fajman) (04/16/91)
> But for SLIP/PPP that's just fine, that how's we do congestion control > in datagram networks................ > > Marty That's true, of course, for SLIP/PPP (although it's more common to drop whole packets rather than pieces of packets), but dropping data out of terminal sessions where there is no provision for retransmission is not so fine. With MNP or V.42 modems there is error detection and correction on the phone lines. In that case, the weak link is that short RS-232 cable between the modem and the terminal server. Genuine errors due to noise on the RS-232 cable are not terribly likely, so if there is an error it will probably be the terminal server dropping bytes due to overload. I don't want to have to explain that to our users.
tcs@uunet.UU.NET (Terry Slattery) (04/17/91)
>While some TS vendors advertise the ability to operate all lines at >max speed in both directions concurrently, what this generally means >is that they are vastly over-engineered for the normal operating point >of a terminal server... For a terminal server, yes. But for a SLIP (or PPP) communications server, they are much closer to what is needed, particularly if you are running X over the link. -tcs
RAF@CU.NIH.GOV (Roger Fajman) (04/20/91)
> While some TS vendors advertise the ability to operate all lines at > max speed in both directions concurrently, what this generally means > is that they are vastly over-engineered for the normal operating point > of a terminal server... > > And hence have higher life cycle cost.... > > A good point. > > M Yes, but implementing hardware flow control on the RS-232 interfaces shouldn't cost much.
schoff@psi.com (Martin Lee Schoffstall) (05/03/91)
I assume that you are using ISDN terminal adapters. Just imagine if you could have a PRI interface for your terminal server. dozens of boxes and cables go away. Marty ------------------ Bill, YEAH! Let me voice *hearty* approval for the 57.6 Kbps speed, and the support of Xremote. Both are extremely important for ISDN applications (as you know :-). Right now we're playing with ISDN/ASM/Xremote at 19.2 'cause we're waiting for 38.4 async ISDN equipment to arrive. We presently go through the cisco to a Sun running Xremote. It'll be great to do this directly in the cisco. Whenever NCD supports 57.6 kbps, we can begin to *really* jam! Joel
replogle@ncsa.uiuc.edu (Joel Replogle) (05/03/91)
Bill, YEAH! Let me voice *hearty* approval for the 57.6 Kbps speed, and the support of Xremote. Both are extremely important for ISDN applications (as you know :-). Right now we're playing with ISDN/ASM/Xremote at 19.2 'cause we're waiting for 38.4 async ISDN equipment to arrive. We presently go through the cisco to a Sun running Xremote. It'll be great to do this directly in the cisco. Whenever NCD supports 57.6 kbps, we can begin to *really* jam! Joel
replogle@ncsa.uiuc.edu (Joel Replogle) (05/04/91)
>I assume that you are using ISDN terminal adapters. Yes. >Just imagine if you could have a PRI interface for your terminal >server. dozens of boxes and cables go away. Absolutely. That is rather close to heaven in comparison to the current situation here. What we have had in the past is more like the opposite state :-) We have had several switched-56 lines for remote (home) access as a prototype experiment. Handstands were in order to get things to work - the number of converter boxes was amazing (but it *did* work :-). Using the ISDN TA's at basic rate cut our piece count in half, but unfortuntately the TA's we have only go up to 19.2 async (big deal). The potential is there but we have yet to really see it (they say the 38.4 TA's are on their way). A PRI interface would be even better, as instead of having 28 BRI lines with NT1's and TA's, we could just have a single set of ISDN boxes. I'd be extremely excited if any equipment comes out for this soon, and right now I'd be happy with more BRI ISDN equipment becoming available. Later, Joel