January 1997

I started the usr-tc list not because I have an overwhelming knowledge of the Total Control system. Just the opposite, we just purchased 13 racks and I've got the daunting task of switching from Xylogics to USR in the next month. There seemed to be a need for a list judging from the recent discussion on comp.dcom.servers, and I waited and waited for someone else to do it. So after waiting a while, I just did it myself. Now I've got a few questions to pose to the subscribers: 1. Is anyone using an initial menu with their TC system? We currently have one that looks like: XMission Login Menu: 1) Guest Services 2) Login an existing XMission account 3) Connect with PPP 4) Connect with SLIP/CSLIP 5) Hangup Enter Number: It also attempts to authenticate with PAP before getting to this point. In browsing the documentation, I noted that you can have a welcome message and a prompt, but I couldn't see any method of assigning tasks to numbers as above. 2. The manual has a nice discussion of subnetting class C addresses, but no actual method of doing so. Is this possible? USR told me that RIP2 was "out" with the latest release. Is anyone using it? What about this out-of-date RFC business about 255.255.255.128 subnets? 3. Do each of the power supplies really use 10 AMPS? Ei yi yi! -- Pete XMission

On Friday, January 03, 1997 4:39 PM, Pete Ashdown wrote: > I started the usr-tc list not because I have an overwhelming knowledge of the > Total Control system. Just the opposite, we just purchased 13 racks and I've > got the daunting task of switching from Xylogics to USR in the next month. On PRIs or channelized-Ts? > There seemed to be a need for a list judging from the recent discussion on > comp.dcom.servers, and I waited and waited for someone else to do it. So > after waiting a while, I just did it myself. And I for one am much obliged, thanks. > Now I've got a few questions to > pose to the subscribers: > > 1. Is anyone using an initial menu with their TC system? We currently have > one that looks like: > > XMission Login Menu: > > 1) Guest Services > 2) Login an existing XMission account > 3) Connect with PPP > 4) Connect with SLIP/CSLIP > 5) Hangup > > Enter Number: > > It also attempts to authenticate with PAP before getting to this point. In > browsing the documentation, I noted that you can have a welcome message and a > prompt, but I couldn't see any method of assigning tasks to numbers as above. I do not know the answer to this (we only do PPP/SLIP, and the PAP-or-login-prompt duality works great), but have you looked at Livingston-related resources? Since the USR NetServer is derived from (old) Livingston code, this issue may have been addressed there. Megazone? > 2. The manual has a nice discussion of subnetting class C addresses, but no > actual method of doing so. Is this possible? USR told me that RIP2 was "out" > with the latest release. Is anyone using it? What about this out-of-date > RFC business about 255.255.255.128 subnets? Works fine for us. The command is: add netmask Network Netmask And: sh tab netmask Note also that ether0's network is implicitly subnetted on its netmask, and that a network can only have one netmask (no VLSM). > 3. Do each of the power supplies really use 10 AMPS? Ei yi yi! Dunno. -- /// Marcus Needham /// marcus@theriver.com \\\ VP & Webmaster \\\ The River, Tucson AZ USA, http://www.theriver.com/

Once upon a time Marcus Needham shaped the electrons to say... >> XMission Login Menu: >> >> 1) Guest Services >> 2) Login an existing XMission account >> 3) Connect with PPP >> 4) Connect with SLIP/CSLIP >> 5) Hangup >> >> Enter Number: This is the menuing that Xylogics boxes have built in. >> It also attempts to authenticate with PAP before getting to this point. In Autodetect settings, yep. >> browsing the documentation, I noted that you can have a welcome message and >> prompt, but I couldn't see any method of assigning tasks to numbers as above The TC is based on ComOS 3.1.4 - ComOS does not do menuing. Sorry. With current Livingston boxes and RADIUS 2.0 from us you can do menus - but they come up AFTER authentication. The user authenticates, RADIUS replies with a menu, then the user picks the type of connection from the menu. It isn't possible, at this time, to do menus before authentication. The kicker is - RADIUS 2.0 can only be used by Livingston owners legally. Now, if you have just one Livignston box on your network, you can use it on everything (including the TC), but you have to own Livingston HW. I'm also not completely sure the RADIUS menuing system works with ComOS before 3.3.1, but I believe it does. >issue may have been addressed there. Megazone? So, how'd you know I'd be here? ;-) >> 2. The manual has a nice discussion of subnetting class C addresses, but no >> actual method of doing so. Is this possible? USR told me that RIP2 was "ou Since it is based on 3.1.4 I expect it has our old Netmask Table hack. But since we don't do RIPv2 yet (we do OSPF now, we did that first, RIPv2 is coming) that must be something USR added to the code. I don't know how that works, or how it interfaces with the Netmask table. >> with the latest release. Is anyone using it? What about this out-of-date >> RFC business about 255.255.255.128 subnets? You mean the inability to use the first and last subnet. That has never been a limitation of ComOS, it would be weird if USR added the limitation. >Works fine for us. The command is: >add netmask Network Netmask >And: >sh tab netmask This is the Netmask Table hack we had to work with RIPv1 If they do RIPv2 I don't know how it works together. >Note also that ether0's network is implicitly subnetted on its netmask, >and that a network can only have one netmask (no VLSM). VLSM comes with CIDR and OSPF in ComOS 3.5. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Fri, 3 Jan 1997 22:05:25 -0000, Marcus Needham wrote: >On Friday, January 03, 1997 4:39 PM, Pete Ashdown wrote: >> 3. Do each of the power supplies really use 10 AMPS? Ei yi yi! > >Dunno. Unless changed in more recent production, the power supplies (2) are collectively rated at 10-amps *combined* for the primary (120-volt) side line current. The rack will run fine on a single supply (output load rated at 35 Amps) and each single supply has a max *primary* side current rating of 5 amps. Dual supplies are very cheap insurance and wise redundancy. Internally the power supplies have primary side 6.3A line fuses, and they fuse both the hot & neutral legs since the PS can be strapped internally for either a 120 or 240 volt line. I've seen some documentation in the past where devices capable of being strapped 120/240 may actually run slightly more efficiently on 240 vs 120 volts. In big systems that tends to insure good load balancing between AC phases, but I'd want to run that by the MFR before making any big changes.

Once upon a time Marcus Needham shaped the electrons to say... >owner too). You seem to active on "EVERY" list right now--how do you make >time to work?? Mialing filters help, and when I'm short on time I just search the folder for things like 'livingston', 'portmaster', and 'pm'. So I don't have to read entire lists like INET-ACCESS which are so noisy. As far as the Livingston Lists go - I run all of them, it is part of my job to monitor them to make sure they are working ok and to keep things on topic. It's a small step from that to actually answering things, so I do. I also work long hours to keep on top of things. And it helps *me* when working with other vendors boxes to know the issues users are seeing. That's why I originally got on the Ascend-users list - so many interoperability issues with them since they ae so wide spread in ISDN land. And I'm a geek and a technology junkie - I'd probably be reading the lists just for my own knowledge. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Saturday, January 04, 1997 3:43 PM, MegaZone wrote: > Once upon a time Marcus Needham shaped the electrons to say... > >issue may have been addressed there. Megazone? > > So, how'd you know I'd be here? ;-) Lucky guess? No, actually I did a "who" on the list to see how quickly membership was growing and noticed your name. You have helped me with Livingston problems in the past (thanks, and BTW I am a happy Livingston owner too). You seem to active on "EVERY" list right now--how do you make time to work??

On Sat, 4 Jan 1997, MegaZone wrote: > And it helps *me* when working with other vendors boxes to know the issues > users are seeing. That's why I originally got on the Ascend-users list - > so many interoperability issues with them since they ae so wide spread in > ISDN land. I know this is a bit off-topic, but I'm an Ascend user right now and was unaware of the Ascend-users list. Got a subscribe address? Also, I'm looking to possibly move off of Max 4000's and 4004's to the TotalControl. Thoughts? -- Robert A. Pickering Jr. Internet Services Manager Cincinnati Bell Telephone pickerin@fuse.net A Rough Whimper of Insanity (Information Superhighway) PGP key ID: 75CAFF7D 1995/05/09 PGP Fingerprint: B1 63 0C 09 D8 2E 5D 69 BB 61 A2 92 22 37 63 C3

Robert A. Pickering Jr. said once upon a time: >Also, I'm looking to possibly move off of Max 4000's and 4004's to the >TotalControl. Thoughts? According to the tests done by Datacomm Magazine, the 4000 performed rather dismally in comparison to the TC. See the review at: http://www.data.com/lab_tests/remote_servers.html

Robert A. Pickering Jr. said once upon a time: >Also, I'm looking to possibly move off of Max 4000's and 4004's to the >TotalControl. Thoughts? According to the tests done by Datacomm Magazine, the 4000 performed rather dismally in comparison to the TC. See the review at: http://www.data.com/lab_tests/remote_servers.html

On Monday, January 06, 1997 5:50 AM, Robert A. Pickering Jr. wrote: > On Sat, 4 Jan 1997, MegaZone wrote: > > > And it helps *me* when working with other vendors boxes to know the issues > > users are seeing. That's why I originally got on the Ascend-users list - > > so many interoperability issues with them since they ae so wide spread in > > ISDN land. > > I know this is a bit off-topic, but I'm an Ascend user right now and > was unaware of the Ascend-users list. Got a subscribe address? > > Also, I'm looking to possibly move off of Max 4000's and 4004's to the > TotalControl. Thoughts? Why are you changing? I have seen all kinds of discussion about the pros and cons of the two products, but nothing showing sufficient cause to junk an existing installation in favor of the other.

Anyone know anything about the EC (NOT ETC!!) cellular protocol? USR promised a while ago, but I havent seen it yet. TIA Bob _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

In a message dated 97-01-06 12:55:50 EST, you write: << Also, I'm looking to possibly move off of Max 4000's and 4004's to the TotalControl. >> Do you mind if I ask why, exactly, you're thinking of leaving Ascend for USR ?

When I asked the USR tech about linking our UNIX passwd/shadow database into USR's security server they said it was possible. However, now that I've received the security server for Solaris, it isn't mentioned anywhere. Is anyone doing this? -- Pete XMission

Once upon a time Pete Ashdown shaped the electrons to say... >When I asked the USR tech about linking our UNIX passwd/shadow database into >USR's security server they said it was possible. However, now that I've >received the security server for Solaris, it isn't mentioned anywhere. Is >anyone doing this? Isn't their security server RADIUS? If it is RADIUS, even if theirs does not (for some odd reason) allow the use of UNIX passwd files, there are many versions that do. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

MegaZone said once upon a time: >Isn't their security server RADIUS? > >If it is RADIUS, even if theirs does not (for some odd reason) allow the >use of UNIX passwd files, there are many versions that do. So I found out. I got the Merit RADIUS server and looked over the source.

Our TCs are fed from US West channelized-Ts, which due to US West's pricing structure are line-side (analog lines redigitized at the CO in a channel bank) trunks rather than being digital all the way. Does anyone else have to suffer the indiginity of not having trunks fully digital from the CO? If so, what kind of initial connect speeds do you get? A fair number of our users have reported lower reported connect rates (26400 24000) than they used to get on our previous analog Courier system.

Our POP was indeed fairly close before we moved/changed. Excellent info thanks. But your data seem to indicate that practically noone would get >26400 connects, where I myself from home (I happen to dial into the same CO as the T1s come out of for the ISP site) get 31200 and 33600 all the time with a Sportster (one of older "classic" models when they cared about the Sportster line, with the V34+ EPROM) and others have also reported excellent connects. Also can you recommend any tweaks that we or US West can make to wrong the best we can out of the line-side trunks until tariffs/CAP-availability changes? On Thursday, January 09, 1997 7:30 PM, Bill Garfield wrote: > >A fair number of our users have reported lower reported connect rates (26400 24000) > >than they used to get on our previous analog Courier system. > > I think that's an accurate observation from the user's standpoint. The > channel bank at the CO introduces an additional digital-to-analog then > back to digital conversion which in turn introduces additional > quantization noise resulting in at least 2db and often 3db reduction in > the signal-to-noise ratio. Also the filters in the channel card wipe > out the precious top end frequency response. > > Likely back when you were taking analog delivery there was one less > D-to-A conversion and your POP was likely close enough to the central > office that physical cable distance was not a detriment. You were > in fat city and didn't realize it. > > Here's some line sweep data I've gathered that demonstrates the various > methods of delivery. First snapshot is of analog delivery over physical > copper where the POP is approx 1 mile from the telco central office: ...

On Thursday, January 09, 1997 9:48 PM, Bill Garfield wrote: > On Thu, 9 Jan 1997 20:54:49 -0000, Marcus Needham <marcus@theriver.com> > wrote: > > >Our POP was indeed fairly close before we moved/changed. > >Excellent info thanks. > > >But your data seem to indicate that practically no one would get > >>26400 connects, where I myself from home (I happen to dial into the same > >CO as the T1s come out of for the ISP site) get 31200 and 33600 > >all the time with a Sportster (one of older "classic" models when they > >cared about the Sportster line, with the V34+ EPROM) and others have > >also reported excellent connects. > > Two factors at work here Marcus. Most importantly you are calling > within the same switching machine meaning you avoid the D-to-A > conversion on the incoming trunk... You're already there. The second > factor is your 'on-the-mark' observation that yesterday's Sportsters are > a damn site better than the Sportster coming down the assembly line > today. Ah, finally it all makes sense. I did not know that my incoming call would be remaining analog as it crossed the CO to the ISP-bound channel bank. But is it not the A-to-D conversions that are the killers, not so much the D-to-As?

At 09:58 PM 1/9/97 -0000, you wrote: >On Thursday, January 09, 1997 9:48 PM, Bill Garfield wrote: >> On Thu, 9 Jan 1997 20:54:49 -0000, Marcus Needham <marcus@theriver.com> >> wrote: >> >> >Our POP was indeed fairly close before we moved/changed. >> >Excellent info thanks. >> >> >But your data seem to indicate that practically no one would get >> >>26400 connects, where I myself from home (I happen to dial into the same >> >CO as the T1s come out of for the ISP site) get 31200 and 33600 >> >all the time with a Sportster (one of older "classic" models when they >> >cared about the Sportster line, with the V34+ EPROM) and others have >> >also reported excellent connects. >> >> Two factors at work here Marcus. Most importantly you are calling >> within the same switching machine meaning you avoid the D-to-A >> conversion on the incoming trunk... You're already there. The second >> factor is your 'on-the-mark' observation that yesterday's Sportsters are >> a damn site better than the Sportster coming down the assembly line >> today. > >Ah, finally it all makes sense. I did not know that my incoming call >would be remaining analog as it crossed the CO to the ISP-bound channel >bank. > >But is it not the A-to-D conversions that are the killers, not so much the >D-to-As? > > > >

On Thu, 9 Jan 1997 10:53:38 -0000, Marcus Needham <marcus@theriver.com> wrote: >Our TCs are fed from US West channelized-Ts, which due to US West's = pricing >structure are line-side (analog lines redigitized at the CO in a channel= bank)=20 >trunks rather than being digital all the way. Does anyone else have to = suffer the >indiginity of not having trunks fully digital from the CO? If so, what = kind of >initial connect speeds do you get? =20 >A fair number of our users have reported lower reported connect rates = (26400 24000) >than they used to get on our previous analog Courier system. I think that's an accurate observation from the user's standpoint. The channel bank at the CO introduces an additional digital-to-analog then back to digital conversion which in turn introduces additional quantization noise resulting in at least 2db and often 3db reduction in the signal-to-noise ratio. Also the filters in the channel card wipe out the precious top end frequency response. Likely back when you were taking analog delivery there was one less D-to-A conversion and your POP was likely close enough to the central office that physical cable distance was not a detriment. You were in fat city and didn't realize it. Here's some line sweep data I've gathered that demonstrates the various methods of delivery. First snapshot is of analog delivery over physical copper where the POP is approx 1 mile from the telco central office: SYSTEM: ANALOG DELIVERY, USR COURIER HOST +-----+-----------------------------+ | Modulation V.34+ | | Speed 31200/31200 | | Symbol Rate 3429/3429 | | Carrier Frequency 1959/1959 | | Trellis Code 64S-4D/64S-4D | | Nonlinear Encoding ON/ON | | Precoding ON/OFF | | Shaping ON/OFF | | Preemphasis 2/4 | | Rx Lev/TX Lev/SNR 20.5/11.9/35.3 |<-- Note the 35.3 SNR - Nice line!! | Echo Loss Near 33.7 Far 8.4 | | Roundtrip Delay 9 | | Retrains Request/Grant 0/0 | +-----------------------------------+ The gentle staircase-effect here is characteristic of a short, non-loaded analog copper line. Note also only 20 db rolloff +---------------------------------------------------------------+ | -18 | . . x x x x x x x x . . . . . . . . . . . . . . . | 0 | | -20 | . X X X X X X X X X X X X X x x x . . . . . . . . | 2 | | -22 | . X X X X X X X X X X X X X X X X X X X x x . . . | 4 | | -24 | X X X X X X X X X X X X X X X X X X X X X X x . . | 6 | | -26 | X X X X X X X X X X X X X X X X X X X X X X X . . | 8 | | -28 | X X X X X X X X X X X X X X X X X X X X X X X . . | 10 | | -30 | X X X X X X X X X X X X X X X X X X X X X X X X . | 12 | | -32 | X X X X X X X X X X X X X X X X X X X X X X X X . | 14 | | -34 | X X X X X X X X X X X X X X X X X X X X X X X X . | 16 | | -36 | X X X X X X X X X X X X X X X X X X X X X X X X . | 18 | | -38 | X X X X X X X X X X X X X X X X X X X X X X X X X | 20 | |Level+---------------------------------------------------+Atten| | 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 | | 1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7 | | 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 | | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | +---------------------------------------------------------------+ Next here's another but with full digital delivery, and trunk-side integration (no channel banks at either end) SYSTEM: FULL DIGITAL, TRUNK-SIDE DELIVERY COURIER TC HOST +-----+-----------------------------+ | Modulation V.34+ | | Speed 31200/31200 | | Symbol Rate 3429/3429 | | Carrier Frequency 1959/1959 | | Trellis Code 64S-4D/64S-4D | | Nonlinear Encoding ON/ON | | Precoding OFF/OFF | | Shaping OFF/OFF | | Preemphasis 2/2 | | Rx Lev/TX Lev/SNR 15.3/12.1/37.2 | <-- Note the 37.2 SNR !! | Echo Loss Near 32.1 Far 17.3 | | Roundtrip Delay 9 | | Retrains Request/Grant 0/0 | +-----------------------------------+ and look at the beautiful line sweep here - only 16db rolloff!!! +---------------------------------------------------------------+ | -14 | . x x x x x x x x x x x x x x x x x . . . . . . . | 0 | | -16 | . X X X X X X X X X X X X X X X X X X X X x . . . | 2 | | -18 | x X X X X X X X X X X X X X X X X X X X X X X . . | 4 | | -20 | X X X X X X X X X X X X X X X X X X X X X X X . . | 6 | | -22 | X X X X X X X X X X X X X X X X X X X X X X X x . | 8 | | -24 | X X X X X X X X X X X X X X X X X X X X X X X X . | 10 | | -26 | X X X X X X X X X X X X X X X X X X X X X X X X . | 12 | | -28 | X X X X X X X X X X X X X X X X X X X X X X X X . | 14 | | -30 | X X X X X X X X X X X X X X X X X X X X X X X X x | 16 | |Level+---------------------------------------------------+Atten| | 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 | | 1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7 | | 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 | | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | +---------------------------------------------------------------+ =46inally, here is a TC system using Line-Side trunks. His users are screaming, and rightly so: SYSTEM: Digital delivery w/Line-side translation +-----+-----------------------------+ | Modulation V.34 | | Speed 26400/26400 | <-- Arggh! | Symbol Rate 3429/3429 | | Carrier Frequency 1959/1959 | | Trellis Code 64S-4D/64S-4D | | Nonlinear Encoding ON/ON | | Precoding ON/ON | | Shaping ON/ON | | Preemphasis 2/4 | | Rx Lev/TX Lev/SNR 16.6/11.9/32.8 | <-- Note the 32.8 SNR | Echo Loss Near 32.4 Far 20.3 | | Roundtrip Delay 12 | | Retrains Request/Grant 0/0 | +-----------------------------------+ His line sweep is flat as a pancake but suffers 31db rolloff on the high end. No way Jose will you get 28.8 to this guy. +---------------------------------------------------------------+ | -16 | . x X X X X X X X X X X X X X X X X X x . . . . . | 1 | | -18 | . X X X X X X X X X X X X X X X X X X X X x . . . | 3 | | -20 | . X X X X X X X X X X X X X X X X X X X X X . . . | 5 | | -22 | . X X X X X X X X X X X X X X X X X X X X X X . . | 7 | | -24 | X X X X X X X X X X X X X X X X X X X X X X X . . | 9 | | -26 | X X X X X X X X X X X X X X X X X X X X X X X . . | 11 | | -28 | X X X X X X X X X X X X X X X X X X X X X X X . . | 13 | | -30 | X X X X X X X X X X X X X X X X X X X X X X X x . | 15 | | -32 | X X X X X X X X X X X X X X X X X X X X X X X X . | 17 | | -34 | X X X X X X X X X X X X X X X X X X X X X X X X . | 19 | | -36 | X X X X X X X X X X X X X X X X X X X X X X X X . | 21 | | -38 | X X X X X X X X X X X X X X X X X X X X X X X X . | 23 | | -40 | X X X X X X X X X X X X X X X X X X X X X X X X . | 25 | | -42 | X X X X X X X X X X X X X X X X X X X X X X X X . | 27 | | -44 = |=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX=3DX= =3DX=3DX=3DX=3DX=3DX=3DX=3D.=3D| 29 | | -46 | X X X X X X X X X X X X X X X X X X X X X X X X X | 31 | |Level+---------------------------------------------------+Atten| | 0 0 0 0 0 0 1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 3 3 3 | | 1 3 4 6 7 9 0 2 3 5 6 8 9 1 2 4 5 7 8 0 1 3 4 6 7 | | 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 0 5 | | 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 | +---------------------------------------------------------------+ This last one is also typical of what the lines look like when there's a SLC-96 loop concentrator and the HOST is taking analog delivery, as in the case where the host has an analog modem bay but gets channelized T1 delivery into a channel bank at the host end. Definitely not the way to go. Where tarrifs are right, the ultimate results are obtained with ISDN PRI delivery. Second-best but approx equal thereto from a performance standpoint is full digital trunk-side integration. Third best is plain- vanilla analog copper delivery into an analog rack, provided your POP is within a mile or less of the (preferably digital) switching office and you're on new UNLOADED cable that is the same wire guage end-to-end. Poor results occur with line-side trunks or channel-bank delivery and absolutely rotten results are seen with physically long analog copper lines (15,000 cable feet or more from the CO) with multiple load coils. Of course what the customer is faced with on his half of the call only exacerbates the problem. But if you as the ISP are unable to provision YOUR half of the call with the very best line the telco has to offer, your customer hasn't a chance in hell of experiencing good connect (and throughput) speeds. +-----------------------------------------------+ | Do Not Walk In Front Of Me.I Will Not Follow. | | And Do Not Walk Behind Me, I cannot Lead You. | | Please Just Walk Beside Me and Be My Friend. | +-----------------------------------------------+

On Thu, 9 Jan 1997 20:54:49 -0000, Marcus Needham <marcus@theriver.com> wrote: >Our POP was indeed fairly close before we moved/changed. >Excellent info thanks. >But your data seem to indicate that practically no one would get >>26400 connects, where I myself from home (I happen to dial into the = same >CO as the T1s come out of for the ISP site) get 31200 and 33600 >all the time with a Sportster (one of older "classic" models when they=20 >cared about the Sportster line, with the V34+ EPROM) and others have=20 >also reported excellent connects. Two factors at work here Marcus. Most importantly you are calling within the same switching machine meaning you avoid the D-to-A conversion on the incoming trunk... You're already there. The second factor is your 'on-the-mark' observation that yesterday's Sportsters are a damn site better than the Sportster coming down the assembly line today. >Also can you recommend any tweaks that we or US West can make to wrong >the best we can out of the line-side trunks until = tariffs/CAP-availability >changes? If you can convince US Worst to use "PulseCom AUA178i revision B1=20 issue 2" channel bank cards it'll help. These specific cards have a better filter network and don't chop off the high end as steeply. I'm told that you must use the "issue 2" cards. According to folks who've used these in channel bank installations they are about the best you can expect short of a fully integrated trunk side delivery. +----------------------------------------------------------------------+ | SHOPPER ADVISORY: Current shipping models of the USR V34 Sportster | | may not be the same modem that the magazine reviewers and testing | | labs spoke so highly of last year. | +----------------------------------------------------------------------+

On Thu, 9 Jan 1997 21:58:37 -0000, Marcus Needham <marcus@theriver.com> wrote: >On Thursday, January 09, 1997 9:48 PM, Bill Garfield wrote: >> On Thu, 9 Jan 1997 20:54:49 -0000, Marcus Needham = <marcus@theriver.com> >> wrote: >>=20 >> >Our POP was indeed fairly close before we moved/changed. >> >Excellent info thanks. >>=20 >> >But your data seem to indicate that practically no one would get >> >>26400 connects, where I myself from home (I happen to dial into the = same >> >CO as the T1s come out of for the ISP site) get 31200 and 33600 >> >all the time with a Sportster (one of older "classic" models when = they=20 >> >cared about the Sportster line, with the V34+ EPROM) and others have=20 >> >also reported excellent connects. >>=20 >> Two factors at work here Marcus. Most importantly you are calling >> within the same switching machine meaning you avoid the D-to-A >> conversion on the incoming trunk... You're already there. The second >> factor is your 'on-the-mark' observation that yesterday's Sportsters = are >> a damn site better than the Sportster coming down the assembly line >> today. > >Ah, finally it all makes sense. I did not know that my incoming call >would be remaining analog as it crossed the CO to the ISP-bound channel=20 >bank. =20 > >But is it not the A-to-D conversions that are the killers, not so much = the=20 >D-to-As? If your analog subscriber line is in the same switching machine as your POP and your POP takes Line-Side trunks it would be unnecessary for that switching machine to digitize the inbound analog only to hand it off analog to the carrier bay. The problem callers in this instance would be cross-town callers coming in from another switch, and thus coming across town on a *digital* intermachine trunk that, with line-side integration in your CO, would have to be demuxed to be handed off by the switch to the carrier bay (channel bank) only to be remuxed back to digital again.=20 There can be numerous factors involved, including the type of switching machine the caller is on (ie, an old 1A or 2B analog switcher or a digital 5E or DMS100, etc. also the type switching machine the host POP is on.... is *it* digital or analog?) Depending on the switch types at each end the resultant signal to noise ratio and bandwidth and frequency response will vary and so too will the quality of connection. Modern telephony is really somewhat of an exact science just that you have to know what all the variables are that are getting plugged into the equation along the way. We've already touched on most of them in the course of this thread. Sketching it out on the white board in the conference room for the mind to *see* what is taking place and suddenly you can see light bulbs coming on in people's heads. Modern voice grade telephony is all digital inside the modern day switching network, including digital switchers and digital cross-town trunks and digital cross-country trunks. The problems start coming into playonly when we try to interface this digital network with the analog local loop out to the enduser/subscriber. Alas too, there are still quite a few analog switching machines still in use, but things are changing, especially in the metropolitan areas. But understanding that the main infrastructure is digital, and understanding that anytime and every time we have to make a conversion or interface with an analog leg we impart some quantization noise, it should become clear that it behooves us to AVOID any UNNECESSARY digital to analog conversions. =20 It too is within our power to do some RESEARCH before locating our POP 8 miles away from Lum-N-Abner's General Store and Telephone Company, Bait and Boats Rented. If you know the right questions to ask and can find the right people who have the answers to those questions, you can put up an inexpensive POP just around the corner from a new digital switching office and be the connectivity envy of all your competitors. You know, the guys who thought it was more important to seek out some stylish business LOCATION and the phone lines were just phone lines. If you need to entertain the high-roller clients you can get yourself a small office in some fancy location for that express purpose, but build your engine room over in the low rent district next to the phone office. Your POP =3Dcan=3D be stylish in appearance but the one thing it *must* be is functionally and technologically fine tuned, starting with the phone lines.

On Mon, 6 Jan 1997, Marcus Needham wrote: > Why are you changing? I have seen all kinds of discussion about the > pros and cons of the two products, but nothing showing sufficient cause > to junk an existing installation in favor of the other. > Two big reasons: 1) Modem quality 2) Management Quality I find the Ascend products VERY difficult to manage for a large bank. They keep telling me they are working on Java management tools, but I haven't seen them for the 4000 series. I get VERY poor modem connects. Under load they drop calls, and the quality of the connects themselves is poor. I'm looking to move to ANYTHING but the Max product. I'm currently looking at the Microcom AI, the Cisco 5210, and the TC. I am also receiving a lot of pressure from users about 56K. USR has a solution today. It might not end up being the standard, but they'll be able to flash to the standard when it's approved. Thoughts? (p.s. DOES anyone know the address for the Ascend list?) -- Robert A. Pickering Jr. Internet Services Manager Cincinnati Bell Telephone pickerin@fuse.net A Rough Whimper of Insanity (Information Superhighway) PGP key ID: 75CAFF7D 1995/05/09 PGP Fingerprint: B1 63 0C 09 D8 2E 5D 69 BB 61 A2 92 22 37 63 C3

On Sunday, January 12, 1997 4:19 PM, Bill Garfield wrote: > >I am also receiving a lot of pressure from users about 56K. USR has > >a solution today. It might not end up being the standard, but they'll > >be able to flash to the standard when it's approved. > > > >Thoughts? > > Yes, one. > IMO this 56k thing is going to start ISP wars the likes of which we've > not seen before. I think it's *VERY* premature to invest in the > direction of -anyone's- 56k technology, brand loyalties and existing > platforms notwithstanding. > > Right now all we have is a manufacturer posturing themselves with vague > and ambiguous statements in press releases, stating only that test > results show the technology as being able to provide "nearly twice" the > speed as "standard modem connections" for a high percentage of users. > Well folks, just what the hell does that statement say that you can hold > someone to? Zero. > > I ask you, what does the word "nearly" suggest to you? And just exactly > what speed does a "standard modem" connect at? How naive are you? I'm > sorry, call me a doubting Thomas, but this old Missourian has gotta be > showed. Me too. I think the manufacturers (and USR the worst alas) are deliberately peddling this "technology" to our USERS more than to the ISP community, and creating huge amounts of FUD in the hopes of selling a few modems. I had one user email me about our 56k plans who said he HAD a 56k USR modem. I saw a USR modem box in Egghead and the 56k logos were much more prominent than the "upgradable to..." small print around them. I suppose I would like to be proven wrong but I am extremely skeptical.

On Sunday, January 12, 1997 2:54 PM, Robert A. Pickering Jr. wrote: > On Mon, 6 Jan 1997, Marcus Needham wrote: > > > Why are you changing? I have seen all kinds of discussion about the > > pros and cons of the two products, but nothing showing sufficient cause > > to junk an existing installation in favor of the other. > > > > Two big reasons: > > 1) Modem quality > 2) Management Quality > > I find the Ascend products VERY difficult to manage for a large bank. > They keep telling me they are working on Java management tools, but I > haven't seen them for the 4000 series. > > I get VERY poor modem connects. Under load they drop calls, and the > quality of the connects themselves is poor. > > I'm looking to move to ANYTHING but the Max product. I'm currently > looking at the Microcom AI, the Cisco 5210, and the TC. > > I am also receiving a lot of pressure from users about 56K. USR has > a solution today. It might not end up being the standard, but they'll > be able to flash to the standard when it's approved. > > Thoughts? Must be an expensive move to junk several Maxen, can you see an ROI? > > (p.s. DOES anyone know the address for the Ascend list?) Send a subscribe to ascend-users-request@bungi.com

Once upon a time Robert A. Pickering Jr. shaped the electrons to say... >I'm looking to move to ANYTHING but the Max product. I'm currently >looking at the Microcom AI, the Cisco 5210, and the TC. I'd add the Livingston PortMaster-3 to that list too, it is in the same category, >I am also receiving a lot of pressure from users about 56K. USR has >a solution today. It might not end up being the standard, but they'll >be able to flash to the standard when it's approved. Keep this in mind - USR has less than 20% of the end user modem market. Lucent and Rockwell together have over 70%. So, while USR is going to be first, as soon as the others ship they will be in a minority. And you'll likely end up with more users demanding a Lucent/Rockwell compatible solution than a USR X2 solution - and the TC is not. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Sunday, January 12, 1997 7:45 PM, MegaZone wrote: > Once upon a time Robert A. Pickering Jr. shaped the electrons to say... > >I'm looking to move to ANYTHING but the Max product. I'm currently > >looking at the Microcom AI, the Cisco 5210, and the TC. > > I'd add the Livingston PortMaster-3 to that list too, it is in the same > category, > > >I am also receiving a lot of pressure from users about 56K. USR has > >a solution today. It might not end up being the standard, but they'll > >be able to flash to the standard when it's approved. > > Keep this in mind - USR has less than 20% of the end user modem market. > Lucent and Rockwell together have over 70%. > > So, while USR is going to be first, as soon as the others ship they will > be in a minority. And you'll likely end up with more users demanding a > Lucent/Rockwell compatible solution than a USR X2 solution - and the TC > is not. ...although it may be flash-able to it, or at least to a merged standard. Regardless though, your point is well made. USR are probably the biggest single brand in the market place but NOT the biggest chipset vendor by volume. And the current FUD campaigns for 56k technology do nothing whatsoever to educate buyers as to the standards deficit and interoperability gulf. All I ever heard referred to by less technical poeple is "THE" 56k modems.

On Sun, 12 Jan 1997 16:54:13 -0500 (EST), "Robert A. Pickering Jr." <pickerin@fuse.net> wrote: >On Mon, 6 Jan 1997, Marcus Needham wrote: > >> Why are you changing? I have seen all kinds of discussion about the >> pros and cons of the two products, but nothing showing sufficient cause >> to junk an existing installation in favor of the other. >Two big reasons: >1) Modem quality >2) Management Quality > >I find the Ascend products VERY difficult to manage for a large bank. >They keep telling me they are working on Java management tools, but I >haven't seen them for the 4000 series. > >I get VERY poor modem connects. Under load they drop calls, and the >quality of the connects themselves is poor. > >I'm looking to move to ANYTHING but the Max product. I'm currently >looking at the Microcom AI, the Cisco 5210, and the TC. > >I am also receiving a lot of pressure from users about 56K. USR has >a solution today. It might not end up being the standard, but they'll >be able to flash to the standard when it's approved. > >Thoughts? Yes, one. IMO this 56k thing is going to start ISP wars the likes of which we've not seen before. I think it's *VERY* premature to invest in the direction of -anyone's- 56k technology, brand loyalties and existing platforms notwithstanding. Right now all we have is a manufacturer posturing themselves with vague and ambiguous statements in press releases, stating only that test results show the technology as being able to provide "nearly twice" the speed as "standard modem connections" for a high percentage of users. Well folks, just what the hell does that statement say that you can hold someone to? Zero. I ask you, what does the word "nearly" suggest to you? And just exactly what speed does a "standard modem" connect at? How naive are you? I'm sorry, call me a doubting Thomas, but this old Missourian has gotta be showed. Bill Garfield wdg@hal-pc.org (formerly bubba@insync.net)

On Sun, 12 Jan 1997 17:41:52 -0000, Marcus Needham <marcus@theriver.com> wrote: >On Sunday, January 12, 1997 4:19 PM, Bill Garfield wrote: >> IMO this 56k thing is going to start ISP wars the likes of which we've >> not seen before. I think it's *VERY* premature to invest in the >> direction of -anyone's- 56k technology, brand loyalties and existing >> platforms notwithstanding. >> Right now all we have is a manufacturer posturing themselves with vague >> and ambiguous statements in press releases, stating only that test >> results show the technology as being able to provide "nearly twice" the >> speed as "standard modem connections" for a high percentage of users. >> Well folks, just what the hell does that statement say that you can hold >> someone to? Zero. >> I ask you, what does the word "nearly" suggest to you? And just exactly >> what speed does a "standard modem" connect at? How naive are you? I'm >> sorry, call me a doubting Thomas, but this old Missourian has gotta be >> showed. >Me too. I think the manufacturers (and USR the worst alas) are >deliberately peddling this "technology" to our USERS more than >to the ISP community, and creating huge amounts of FUD in the >hopes of selling a few modems. I had one user email me about >our 56k plans who said he HAD a 56k USR modem. I saw a USR modem box >in Egghead and the 56k logos were much more prominent than the >"upgradable to..." small print around them. I suppose >I would like to be proven wrong but I am extremely skeptical. I think FUD is a pretty reasonable description, given the track record. IN THEORY at least, this 56k looks plausible when sketched out on the white board in the conference room, but in practice I believe the enduser/subscriber may be in for something of a letdown. How many clients are actually achieving 28.8k (or higher) now? 30 percent? Less? Uhuh... How many of your subscribers are within 15,000 cable feet of their telco central office? About the same 30% ? Uhuh... Goodness knows we've enough problems now with subscribers buying what has been hyped as "28.8" and "33.6" modems when in simple fact they are plain ordinary V.34 modems which are technically CAPABLE of these speeds, only given the right line conditions and proper phase of the moon. Gee, the box doesn't say that. Are people buying these "56k" modems going to be satisfied with 43K when they thought they were buying 56k? And what about the fact that the customer is NOT being told that his client-to-client connections will only be the standard V34 speeds they've had all along? I think the whole thing could turn into a ticking bomb and I'd be thrilled to be proven wrong on this one.

Pete, Hi, I wasn't aware of your list. How do you join etc. I don't mind at all joining both lists. As soon as you tell me how you join your's I can post a notice that mine will disband, please subscribe to .... (your's). Mine never really did a whopping business. A few things different times but not much more besides. I've saved many of the posts that I thought had good data in them so I could send them to you to archive with your's also. Just let me know what you need. Thanks, Ray Kopp Syracuse Unviersity Computing and Media Services Network Systems rjkopp@mailbox.syr.edu 207 Machinery Hall Syracuse, New York 13244 Voice (315)443-5776 Fax (315)443-3817 Owner: usrtc@listserv.syr.edu On Fri, 10 Jan 1997, Pete Ashdown wrote: > jlacour@usr.com said once upon a time: > > >I recently learned that you started a Total Control mailing list. Perhaps youw > >ere unaware that Ray Kopp of Syracuse University has been running a list for > >some time now. > > > >Unfortunately, the level of traffic has been minimal. I think this is mainly > >because many people are unaware of the list. The new list seems to be > >sustaining some traffic however. > > > >Anyway we can get these two aligned? > > I'd be happy to cooperate with Ray to get things together. How does ray feel > about merging things over here? I can provide archive space and so forth. > > >Also, I can and will provide information about the list(s) on > >http://totalservice.usr.com if you folks are agreeable. > > Sounds good. >

MegaZone said once upon a time: >Keep this in mind - USR has less than 20% of the end user modem market. >Lucent and Rockwell together have over 70%. Market share doesn't mean much if you can't connect to the other 30%. I've used both in pools and where USR has a 100% connect, Rockwell doesn't even come near that.

Once upon a time Pete Ashdown shaped the electrons to say... >Market share doesn't mean much if you can't connect to the other 30%. I've >used both in pools and where USR has a 100% connect, Rockwell doesn't even >come near that. With 56K modems though, USR will be unable to connect to ANY Rockwell or Lucent modem. Whereas both of them have agreed to interoperate. So no matter how good the USR modems are (and I do recommend Couriers all the time for external modems) it won't matter. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

The real question for ISP's is whether you can afford to wait for the other solution to show up. Unless the x2 solution is a total flop, ISP's are going to lose a lot of customers to others with the x2 service. Rockwell is 4-6 months behind in the race from everthing I've read. If you can survive the 4-6 months waiting for what you want, more power to you. This is going to get real nasty in the next month or so. At 05:04 PM 1/13/97 -0800, you wrote: >Once upon a time Pete Ashdown shaped the electrons to say... >>Market share doesn't mean much if you can't connect to the other 30%. I've >>used both in pools and where USR has a 100% connect, Rockwell doesn't even >>come near that. > >With 56K modems though, USR will be unable to connect to ANY Rockwell or >Lucent modem. Whereas both of them have agreed to interoperate. So no >matter how good the USR modems are (and I do recommend Couriers all the time >for external modems) it won't matter. > >-MZ >-- >Livingston Enterprises - Chair, Department of Interstitial Affairs >Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com >For support requests: support@livingston.com <http://www.livingston.com/> >Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > > > > Thanks, Greg Coffey, CoffeyNet ISP for Casper, Rawlins, Wheatland, Douglas, Lander & Lusk, Wyoming +--------------------------------------------------------------------+ | Coffey Computers | 307-234-5443 Voice | Web site: | | 142 S. Center St. | 307-234-5446 Fax | WWW.COFFEY.COM | | Casper, WY 82601 | | | +--------------------------------------------------------------------+

On Monday, January 13, 1997 7:33 PM, Greg Coffey wrote: > The real question for ISP's is whether you can afford to wait for the other > solution to show up. Unless the x2 solution is a total flop, ISP's are > going to lose a lot of customers to others with the x2 service. Rockwell is > 4-6 months behind in the race from everthing I've read. If you can survive > the 4-6 months waiting for what you want, more power to you. This is going > to get real nasty in the next month or so. And almost everyone will suffer. ISPs will be forced to spend cash on equipment and lines that have little benefit. Users will spend money on buying hyped modems which given them little benefit. Then the latter will blame the former for their disappointment. Non-x2 ISPs will not lose customers if x2 is debunked as pipe dream and they continue to server their customers to the best of their abilities.

Once upon a time Pete Ashdown shaped the electrons to say... >My experience with Rockwell was speaking for the other 99% of the modem base, >which is a bigger concern than 56K interoperability. Besides, they are BOTH >vying standards. Once one is accepted, they'll both merge to that. You have Lucent, Rockwell, and USR all going to the ITU-T. Lucents proposal is the most technically advanced, with 45K upload ability using new technology. The Lucent/Rockwell effort has a completely overwhelming majority of backers. However - I will wager NONE of them will win. I expect the ITU-T to do what they have done in the past. Namely, blend all of the proposals and produce a new, hybrid spec as the standard. So that NONE of the existing 56K modems will be standard, and all will need to upgrade. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

MegaZone said once upon a time: > >Once upon a time Pete Ashdown shaped the electrons to say... >>Market share doesn't mean much if you can't connect to the other 30%. I've >>used both in pools and where USR has a 100% connect, Rockwell doesn't even >>come near that. > >With 56K modems though, USR will be unable to connect to ANY Rockwell or >Lucent modem. Whereas both of them have agreed to interoperate. So no >matter how good the USR modems are (and I do recommend Couriers all the time >for external modems) it won't matter. My experience with Rockwell was speaking for the other 99% of the modem base, which is a bigger concern than 56K interoperability. Besides, they are BOTH vying standards. Once one is accepted, they'll both merge to that.

I have no problem connecting to 56k... it fast and better then 33.6 .. I hope I have the lastest beta version.. At 11:07 AM 1/14/97 -0700, you wrote: >MegaZone said once upon a time: >> >>Once upon a time Pete Ashdown shaped the electrons to say... >>>Market share doesn't mean much if you can't connect to the other 30%. I've >>>used both in pools and where USR has a 100% connect, Rockwell doesn't even >>>come near that. >> >>With 56K modems though, USR will be unable to connect to ANY Rockwell or >>Lucent modem. Whereas both of them have agreed to interoperate. So no >>matter how good the USR modems are (and I do recommend Couriers all the time >>for external modems) it won't matter. > >My experience with Rockwell was speaking for the other 99% of the modem base, >which is a bigger concern than 56K interoperability. Besides, they are BOTH >vying standards. Once one is accepted, they'll both merge to that. > >

I have added the archives of Ray Kopp's usrtc list (which has been merged with this one) to ftp://ftp.xmission.com/pub/lists/usr-tc/archive. My archiver split everything up in usr-tc.yearmonth format, but left in bits of residue from mail headers. I'm too buzy|lazy to clean it up further, but eventually I'll get a search engine on them. They're also mirrored on the web at: http://www.xmission.com:80/pub/lists/usr-tc/archive -- Pete XMission

I just got off the phone with support, and I was a bit baffled at what they told me. In order to get the NMC card visible on the network, I have to plug it into an external ethernet hub that the Netserver card is plugged into. The Netserver is at a POP node and connected over V.35 and frame relay. The NMC can not talk to the Netserver over the bus. It needs an external hub. It can not use a "flipped" ethernet cable either. It needs a hub. So essentially, I need to buy a small hub for POP sites because one card can not talk to the card sitting right next to it. Is this baloney? -- Pete XMission

On Wed, 22 Jan 1997, Pete Ashdown wrote: > I just got off the phone with support, and I was a bit baffled at what they > told me. > > In order to get the NMC card visible on the network, I have to plug it into an > external ethernet hub that the Netserver card is plugged into. The Netserver > is at a POP node and connected over V.35 and frame relay. > > The NMC can not talk to the Netserver over the bus. It needs an external > hub. It can not use a "flipped" ethernet cable either. It needs a hub. So > essentially, I need to buy a small hub for POP sites because one card can not > talk to the card sitting right next to it. > I seem to recall seeing in the documentation that the NMC must be installed in the farthest right slot, right next to the power supplies, but that the internal bus does not extend into that slot, it stops at the slot right next to that. Jason Kohles -- System Administrator -- XMission Internet Access robobob@xmission.com (at work) robobob@mindwell.com (at play) "We're not surrounded, we're in a target-rich environment!"

On Wednesday, January 22, 1997 12:53 PM, Pete Ashdown wrote: > I just got off the phone with support, and I was a bit baffled at what they > told me. > > In order to get the NMC card visible on the network, I have to plug it into an > external ethernet hub that the Netserver card is plugged into. The Netserver > is at a POP node and connected over V.35 and frame relay. > > The NMC can not talk to the Netserver over the bus. It needs an external > hub. It can not use a "flipped" ethernet cable either. It needs a hub. So > essentially, I need to buy a small hub for POP sites because one card can not > talk to the card sitting right next to it. > > Is this baloney? I do not think you can get to the NMC card via the Netserver via the internal bus, but I do not see why a "null modem" style Ethernet cable would not work. SO LONG AS you you correctly set those two Ethernet ports up as a true LAN with proper IPs and an appropriate netmask.

: > In order to get the NMC card visible on the network, I have to plug : > it into an external ethernet hub that the Netserver card is plugged : > into. Maybe it's just magic, but our NMC talks to the NetServer dandily. Our setup is as follows: |T1 |NetServer|ModemsModemsModemsModems| |NMC|PS|PS| |Card| | | | | | | We have 2 T1s going to the T1 card, one cat5/rj45 to the NetServer, and two power cables to the to PS'. Everything seems to work fine, including SNMP. --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

Are there any archives of this usr-tc mailing list ? Marino -- Marino Duregon, Mentor Graphics Corp. | email: marino_duregon@mentorg.com 8005 SW Boeckman Road | phone: (503) 685-4796 Wilsonville, OR 97070-7777 |

On Wed, 22 Jan 1997, Marino Duregon wrote: > Are there any archives of this usr-tc mailing list ? > Yes, ftp://ftp.xmission.com/pub-lists/usr-tc Jason Kohles -- System Administrator -- XMission Internet Access robobob@xmission.com (at work) robobob@mindwell.com (at play) "We're not surrounded, we're in a target-rich environment!"

On Wed, 22 Jan 1997, Jason S Kohles wrote: > On Wed, 22 Jan 1997, Marino Duregon wrote: > > > Are there any archives of this usr-tc mailing list ? > > > Yes, ftp://ftp.xmission.com/pub-lists/usr-tc > Oops, this should of course be ftp://ftp.xmission.com/pub/lists/usr-tc Jason Kohles -- System Administrator -- XMission Internet Access robobob@xmission.com (at work) robobob@mindwell.com (at play) "We're not surrounded, we're in a target-rich environment!"

Suddenly, tonight, several of our digital modems have started acting weird. We have the quad modem cards, and I've had to busy out 5 of them (through the T1 NAC) so they won't cause trouble; as it is, they were receiving the call, but weren't initializing the handshake. Mere soft resets were of no avail; any ideas? Thanks. --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

mark@vielle.datasys.net (Mark R. Lindsey) writes: > Suddenly, tonight, several of our digital modems have started acting > weird. We have the quad modem cards, and I've had to busy out > 5 of them (through the T1 NAC) so they won't cause trouble; as it > is, they were receiving the call, but weren't initializing the > handshake. > > Mere soft resets were of no avail; any ideas? Are these digital modems connecting to a NETServer over the packet bus or to some other device through the RS232 port on the NIC? If the former, then verify that your packet bus links are active and ready on the NETServer. Having a packet bus link down would cause the modem to be unable to receive an acknowledgement from the NETServer that it should answer the call, and you could get the behavior you are seeing. This could occur if the cards were recently reseated/replaced, or reset at the slot level. And once inactive, the NETServer will latch the ports in that state, so a software reset of the modem won't clear it. You need to reset the ports from the NETServer side. If you've got traps enabled on the modems in questions, you should be receiving a dteRingNoAnswer trap if this scenario is being triggered. I believe this scenario can also occur when using the RS232 NIC as your DTE device, if the DTR signal is not present, but have less experience with this. Under normal analog line situations, this condition would cause the modem not even to pick up the call. However, when accessed through a digital T1 line, the timing requirements of the T1 signaling require that the T1 card respond to the incoming call slightly in advance of when the modem actually knows if it should pick up the phone. Then, if the modem ends up thinking it shouldn't pick up the phone, you never actually enter into the training sequence, but instead the call drops. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

: > We have the quad modem cards, and I've had to busy out 5 of them : > (through the T1 NAC) so they won't cause trouble; as it is, they : > were receiving the call, but weren't initializing the handshake. : : Are these digital modems connecting to a NETServer over the packet bus : or to some other device through the RS232 port on the NIC? They're on the packet bus; in every case, it's only one out of the four modems on a card that has problems, so I can't reseat a card without knocking offline three happy customers. : If the former, then verify that your packet bus links are active and : ready on the NETServer. Having a packet bus link down would cause the : modem to be unable to receive an acknowledgement from the NETServer : that it should answer the call, and you could get the behavior you are : seeing. Apparently they think they should answer the call, because the LED goes orange, as if it's in the negotiation phase. : However, when accessed through a digital T1 line, the timing : requirements of the T1 signaling require that the T1 card respond to : the incoming call slightly in advance of when the modem actually knows : if it should pick up the phone. Then, if the modem ends up thinking : it shouldn't pick up the phone, you never actually enter into the : training sequence, but instead the call drops. I think I understand what you're saying; so it could be that the modem cards are actually confused. What would you suggest we do to correct it? We can do anything in the maintenance window, and it'd be good to have these modems back online. Thanks much. --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

The RADIUS server sent to me from US Robotics is over two years old. It doesn't support simultaneous user restrictions either. I have managed to get the Merit RADIUS server to work, but apparently it doesn't support scripting like the USR server supposedly does. Does anyone have a recommendation on a RADIUS server that supports scripting and simultaneous user restrictions? -- Pete XMission

Once upon a time Pete Ashdown shaped the electrons to say... >The RADIUS server sent to me from US Robotics is over two years old. It >doesn't support simultaneous user restrictions either. RADIUS is NOT good at simultaneous user restrictions - at the protocol level. ALL of the RADIUS servers that attempt it have major failure states. This is unavoidable. RADIUS was *deliberately* designed to *not* be a resource management protocol. It was designed explicitly to be good at authorization and accounting. Issues: RADIUS auth does NOT have ack packets from the NAS, nor does it have ANY way of knowing the user has logged out. Only RADIUS accounting says that a user logged in or logged out on the NAS. That means you have to weld both servers together, when the protocol was designed not to need this. And even then it isn't good enough. RADIUS accounting packets have a completely different - lower - priority than auth on all the NASes I know of. That means the notification that someone logged out may lag for several *minutes*, possibly quite a few, as retries are not as agressive. Acct was written to NOT be time sensitive - to get the info there, eventually. So there is a VERY common state where a user logs off, or is dropped, turns around to log back in - and RADIUS thinks they are still in! So it denies them. If you offer ISDN connections this is *easy* - ISDN can take less than a second to connect. Even if we used auth packets, they can take up to 30 seconds to get through. And what if the NAS hard crashes? There is no provision in RADIUS for keep alives - and quite deliberately so. They are not needed for what the protocol is designed to do. If the NAS crashes uses will be dumped, and the server receives no notice of this. So ALL of them will be denied when they dial into another NAS to reconnect. And there are more issues. This is just with one server - try coordinating multiple servers for fallback. People don't seem to understand these issues, so they keep asking the protocol to do things it was deliberately designed NOT to do. ESVA RADIUS has simultaneous limits - and you can only run ONE server to use it. Even then all of the above failure states can, and will, bite you. Merit RADIUS is a more robust, yet still doesn't adress most of RADIUSNT also has major failure states. This has come up in the IETF WG several times and the basic agreement is there needs to be another protocol to handle resource management - RADIUS is not suited to it and should not be kludged to do it. No one, as of yet, has seriously pursued forming another WG to address this. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Once upon a time Pete Ashdown shaped the electrons to say... >OK, since it looks like simultaneous user restrictions are out, any comments >on scripting? I would like to be able to build a protocol selection menu >before authentication (this is the way my old Annexes do it). RADIUS isn't contacted until *after* authentication. It is possible to do menus with RADIUS post-authentication - we do. Actually - you could follow the letter of the RFC and bend the spirit a little and have some kind of bogus 'menu user' that the NAS used to get a pre auth menu. We've been mulling that over. >Can I purchase the Livingston Radius server, even though I don't have their >boxes? Sorry, no. It is only available to owners of our hardware. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

OK, since it looks like simultaneous user restrictions are out, any comments on scripting? I would like to be able to build a protocol selection menu before authentication (this is the way my old Annexes do it). Rummaging through the Merit radius code shows the ability to send messages via "port_msg" but all attempts at using it has failed. Can I purchase the Livingston Radius server, even though I don't have their boxes?

I can't believe that I am the only person on the planet who has tried to do protocol selection with the TC. Forget the before/after authentication menus, is anyone doing it at all? -- Pete XMission

We are not, we do not offer shell accounts, only PPP. I know a popular hack is to have two user names for a user, Puser, which starts a PPP session, and Suser which connects them to a shell account server. The latest RADIUS, if you have it (ie you also have Livingston hardware somewhere) makes this easy, as presumably do some of the RADIUS varients. On Wednesday, January 29, 1997 4:03 PM, Pete Ashdown wrote: > I can't believe that I am the only person on the planet who has tried to do > protocol selection with the TC. Forget the before/after authentication > menus, is anyone doing it at all? > > -- > Pete > XMission > -- /// Marcus Needham /// marcus@theriver.com \\\ VP & Webmaster \\\ The River, Tucson AZ USA, http://www.theriver.com/

Pete Ashdown <pashdown@xmission.com> writes: > I can't believe that I am the only person on the planet who has tried to do > protocol selection with the TC. Forget the before/after authentication > menus, is anyone doing it at all? I'm assuming that by "with the TC" above you are actually referring to a NETServer in a TC - if that is incorrect, the following won't apply. Yep, but at least in our case, the protocol is normally tied to the authentication and dictated by the login - e.g., it isn't quite like the command line prompt you might get with an Annex or Cisco where you actually enter in a "slip" or "ppp" command. It's certainly feasible to do the latter, but you would likely have to handle it through challenges via a RADIUS server. And with the "set radius" options provided in release 3.2 or greater, you can actually have your RADIUS server take control of the session prior to the login or password prompts, and thus make the system look like anything you want. Very flexible (although you lose autodetect of PPP if you hand control to RADIUS prior to the login: prompt). Unfortunately, I don't think any publically available RADIUS servers (such as Merit) directly support such an approach, but since source code is available, modifications are always possible. I don't have any direct experience with the Windows server that USR provides, as we use our own proprietary server, so I don't know the USR capabilities in this area. Barring that, another way you might handle it is via separate realms (to borrow a term from the Merit server) such that the requested protocol was dictated by the login. For example, if I were to login as "db3l@slip" I'd be requesting a SLIP session, while "db3l@ppp" would be a PPP session. Since the login information is available to the RADIUS server, it can configure things appropriately. How this is configured (and to what extent you need to duplicate common attributes) would depend on the server in question. I think you might be able to setup default attributes for the realm (slip/ppp in this case) and then just code specific stuff for the users. Now that I've reread the above, I'm not sure this message is all that helpful. The underlying functionality is there, but the problem may end up being that no commercial or available server fully supports the functionality without local development. But I'll send the note anyway :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

David Bolen said once upon a time: >Barring that, another way you might handle it is via separate realms >(to borrow a term from the Merit server) such that the requested >protocol was dictated by the login. For example, if I were to login >as "db3l@slip" I'd be requesting a SLIP session, while "db3l@ppp" This is the approach I'm currently taking. >Now that I've reread the above, I'm not sure this message is all that >helpful. The underlying functionality is there, but the problem may >end up being that no commercial or available server fully supports the >functionality without local development. But I'll send the note >anyway :-) What bothers me is that the functionality is there, but I can't find any software to utilize it. What is USR thinking?

Pete Ashdown <pashdown@xmission.com> writes: > What bothers me is that the functionality is there, but I can't find any > software to utilize it. What is USR thinking? I think it's just a classic race between various aspects of a product, and requirements that apply both to the actual device as well as to software that might run the device. It's possible for one to leapfrog the other, or for functional priorities of one to be slightly different than the other. I for one, am very glad that the underlying functionality is there, but don't actually mind it missing in the software, simply because I use the functionality directly via my own software. Obviously that's not always the case, and no reason not to support it in the official software (which again, I can't speak directly to), but it does mean that at times base functionality may show up in advance of software support and yet still be of use to (some) customers. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/