Subject: (usr-tc) Basic TC Question

From: Brad Gass <[email-masked]>
Date: Mon, 26 Feb 2001 01:10:26 +0000

You'll have to forgive me for being a tad new to the USR gear.  I've
worked with Ariel and Multitech, but this is my first exposure to any USR
TC equipment.

I've got a chance to buy a 48 port v.34 TC chassis (12 quad v.34 modems,
NetServer PRI, Dual PRI NAC, Management Card, etc), but my question is
pretty basic -

Is a TC chassis configured and equipped for PRI also useable in a
channelized T1 environment (non-PRI)?  I know some equipment will work
with either/or, and others will work with one or the other and not both.

I don't have PRI available at the POP I've got in mind for this gear, and
since it's super-rural, v.90 is completely worthless.  That's why v.34
digital (and fully managed) is ideal.

I'm also not totally sure everything I need is in this chassis, but I can
deal with that later, after I pester 3Com in the morning to correct the
links to all their documentation!

Thanks in advance.

Brad

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Mon, 26 Feb 2001 04:06:40 +0000

Also sprach Brad Gass
>I've got a chance to buy a 48 port v.34 TC chassis (12 quad v.34
>modems, NetServer PRI, Dual PRI NAC, Management Card, etc), but my
>question is pretty basic -

I'll say ahead of time...the NETServer PRI is a bad idea.  They have
been end-of-lifed at 3Com (read: no support at all), and had quite a few
rather significant bugs in their software code at the time they were
discontinued.

>with either/or, and others will work with one or the other and not

Sort of...the hardware is perfectly capable of it.  The only change that
needs to be made is that the dual-PRI card needs to have the
channelized-t1 card code flashed to it.  The Dual-PRI card and the
Chan-T1 card were sold as seperate cards, but they were basically the
same...at least later on.  Early Chan-T1 cards used 186 processors and
are only chan-t1 cards, later chan-t1 cards and all dual-pri cards used
386 processors and could be either chan-t1 or pri, the only thing that
changed was the software flashed to it.  Since it says dual-pri card,
you're good, since all dual-pri cards could be flashed back with the
chan-t1 code and run chan-t1 with no problem.

>I don't have PRI available at the POP I've got in mind for this gear,
>and since it's super-rural, v.90 is completely worthless.  That's why
>v.34 digital (and fully managed) is ideal.

The upgrade from v.34 digital to v.90 is a software flash and a software
enable key for the NMC, so if you want to give v.90 a shot, its probably
not much hassle to give it a shot (you'd be surprised where you *can*
get v.90 connections sometimes).

>I'm also not totally sure everything I need is in this chassis, but I
>can deal with that later, after I pester 3Com in the morning to correct
>the links to all their documentation!

It sounds, from your description above, like you're pretty much set...at
least all the NACs that you need are there.

TC terminology is that the longer cards that go in the front of the
chassis are NACs, the shorter ones in the back are NICs.  With a fully
digital setup like you're talking about, you'd need the dual-pri/chan-t1
NAC, and NIC, the 12 quad digital modem NACs (no need for NICs on these,
they just draw power and aren't used for anything in this setup), some
sort of gateway card NAC and NIC (you mentioned the NETServer PRI, I'd
*strongly* suggest that you consider getting a HiPer Arc in its place,
you'll be much happier), then the management (NMC = Network Management
Card) NAC and NIC, and of course, power supply or supplies NACs and
NICs.  These chassis can run fully redundant power supplies on them, but
in the configuration that you're talking about, it certainly doesn't
need it.  With the newer style chassis (with the integrated fan tray)
you even have 2 seperate power cords, so you can plug them into diverse
power sources if you want to go that far with your redundancy.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: mark ross <[email-masked]>
Date: Tue, 27 Feb 2001 06:01:50 +0000

> rather significant bugs in their software code at the time they were

Hi Jeff,
Are you refering to the "NETServer PRI" or "NETServer's" in general ?

The reason I ask is that I have two different styles of cards in my TC
boxes

Netserver & Netserver PRI

My understanding was that the only difference was that the "NETServer
PRI" was able to do ISDN calls with less overhead, somthing about an
enhanced packet bus and a munich daughter card...

Looking at the 3com software matrix I don't see different versions of
software for the "PRI" vs "non PRI" netservers. 

So a "HiPer Arc" can just be installed in place of the Netserver card ?
Is the command line syntax for the HiPer Arc the same as Netserver ?

thanks

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 27 Feb 2001 06:27:51 +0000

Also sprach mark ross
>> been end-of-lifed at 3Com (read: no support at all), and had quite a
>> few rather significant bugs in their software code at the time they
>> were discontinued.

>Are you refering to the "NETServer PRI" or "NETServer's" in general ?

Uhm...I'm referring to NETServer cards in the TC chassis in general.
Note that this doesn't necessarily cover the NETServer units which are
not chassis based and are just generally inferior all the way around.
To the best of my knowledge, the code base is the same for the NETServer
card, and the NETServer PRI card that I believe you are asking about.

>enhanced packet bus and a munich daughter card...

I wouldn't say less overhead.

Uhm...this is gonna proly get into more than you really cared to know
about TC chassis history.  :)

Originally, the TC chassis was not capable of doing ISDN at all...it
came out before ISDN really existed to any real degree.  You had (this
is neglecting the age of dual modem cards, of which I still have a few
in service believe it or not!) a channelized T1 card, modem cards and
the NETServer card to be the gateway.  The modem cards were just that,
modems only.  When ISDN started to become prevelent, USR/3Com came out
with the Courier I-modem high-end consumer equipment, which was a device
that could do either ISDN, or modem protocols over an ISDN line.  The
decision was made that the TC chassis should have essentially the same
capability.  The modem cards were slated to be upgraded to handle ISDN,
and essentially be I-modems, but in the meantime, a solution was needed
to handle ISDN calls on the current modem card software base.  The
NETServer PRI was introduced.  The enhanced packet bus is basically
irrelevant in this, but the NETServer PRI card did have the Munich
daughter card, which was essentially a co-processor card that handled
termination and signaling for ISDN in the chassis.  Essentially, the
card handle some number of ISDN terminations in the place of the modems.
Eventually, the modem card code was developed to handle ISDN as well as
modem, and they became I-modems, and the Munich daughter card became
redundant.  For some time, while the modem card code was still working
out some of its bugs, it was a good idea to switch back to using the
Munich daughter card to troubleshoot problems.  Eventually, since the
development effort was being put into the modem card code, the modem
cards became considerably more reliable and gave better performance than
the Munich daughtercard for terminating ISDN, so pretty much everyone
switched to using the quad cards for ISDN termination.  With the switch
to the HiPer Arc, they don't even have the Munich daughtercard, so it
quads and DSPs for ISDN termination, or nothing.

>software for the "PRI" vs "non PRI" netservers. 

To the best of my knowledge, they use the same code base.

>Is the command line syntax for the HiPer Arc the same as Netserver ?

Yup, the Arc would take the place of the NETServer card (minus the
Munich daughtercard of course ;).  The syntax is radically different,
but also rather better.  The processor on the Arc is also rather more
powerful (a PPC 603e I believe it is, compared to the NETServer's 486)
The NETServer started running into performance issues (the dreaded
so-called "Quake Lag") at around 30 ports of usage (note that this is
less than the number of ports that you'll be dealing with), and running
it in a double-play chassis (12 quads and 2 dsps) as was originally
suggested when the dsps were first announced was virtually suicide for
an ISPs with any significant number of gamers.

The NETServer code base was derived (very directly) from the Livingston
ComOS code-base.  USRobotics originally had licensed ComOS from
Livingston to use in the NETServer, USR got bought by 3Com, and
Livingston got bought by Lucent.  3Com never did develop the "Pilgrim"
code base (the code base of what now runs on the HiPer Arc, and several
other 3Com products) to run on the NETServer as they promised.  Instead,
the NETServer product was End-Of-Lifed with all of about 4 months notice
to those of us using them.

If you'd like, I can probably dig up versions of code for the NETServer
right up until the last day that 3Com has the legal rights to work with
the code.  I was working desperately with 3Com to find and squash a bug
in the MPIP handling code of the NETServers...I was not successful in
that quest.  There are other outstanding bugs in the NETServer code,
which, due to the lack of source code access at 3Com, and that the
product is long-dead at 3Com, will never be fixed.  Among these, the
MPIP bug(s) I mentioned, the Quake Lag (which 3Com will claim was just a
performance limitation inherent in the NETServer card...I think that's a
load of hooey to this day), and probably others that I have (thankfully)
forgotten.

Anyway...if you're still reading at this point, hopefully you've got
some idea of why you *really* *really* want to stay away from the
NETServer.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: mark ross <[email-masked]>
Date: Tue, 27 Feb 2001 07:02:48 +0000

Hi Jeff,
Thanks a lot for taking the time to explain all this, It sounds like you
have been using this platform for a while....

Do you think the 486 processor is the reason for the Netserver card's
lack of performance ?

The reason I ask is that, I think the pm3 only has a 486 processer
onboard and I have not heard of any "quake lag" with the pm3.

Also did you try setting "ppp in modem" to help reduce the load on the
Netserver ? did it help ?

About half of our modem server are tc with netserver cards, the other
half are pm3's. It never fails that the tc's hunt group fills up with
users while our pm3 hunt groups have avail lines.....

any idea on what Hyper arc's are going for ?????

see ya.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 27 Feb 2001 15:09:03 +0000

Also sprach mark ross
>Thanks a lot for taking the time to explain all this, It sounds like
>you have been using this platform for a while....

For about 6 years, yeah.  :)

>Do you think the 486 processor is the reason for the Netserver card's

Nope, I don't.

>onboard and I have not heard of any "quake lag" with the pm3.

Don't think so, I'm pretty sure the pm3 has a 386 processor in it.
Which is why I don't think the 486 is the limitation in the NETServer.
If a 386 can handle 30 ports without any Quake Lag, a 486 should be able
to handle 48 without breaking a sweat.  3Com borked something in the
code when they were mucking with it, plain and simple.

>Netserver ? did it help ?

It helps a bit, I had forgotten about that setting.  I believe I
remember correctly that you hit quake lag with about 30 ports active
with ppp in modem set...if you didn't have it set, I'd guess you'd hit
it at around 25 or so.

Let me expound on "Quake Lag" a bit.  As the name implies, this was
discovered as part of the game Quake's rising popularity.  Many games
along those lines use a large number of very small UDP packets to
communicate with the server.  This is about the worst punishment you can
give a router as its the way to get the highest number of route lookup
and packet processing overhead while still keeping the actual bandwidth
pushed as low as possible.  The claim by 3Com is that Quake Lag is only
experienced when there is a combination of traffic patterns, some
connections using small udp packets, some using large tcp packets for
example.  I don't know that this was ever confirmed by users.

>users while our pm3 hunt groups have avail lines.....

TC's have (or at least had...not sure about recently) better modem code.

>any idea on what Hyper arc's are going for ?????

Don't know pricing, no, sorry.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: [email-masked]
Date: Tue, 27 Feb 2001 16:55:21 +0000

Does anyone out there have a complete set of the latest code for the TC
chassis?  T1, various flavors of the Quad modem card, netserver and NMC, or
know how I can get them?

Also, does anyone have any certs for the 56k upgrade that they would like
to sell?  I know some companies bought in bulk and then ended up with
leftovers.

-

---

From: mark ross <[email-masked]>
Date: Fri, 09 Mar 2001 07:37:28 +0000

Hi Jeff,

Not much activity on the usr-tc list lately ......

I re-read your email tonight and I had a couple more questions for
you...
What is "MPIP" ?
Any idea which version of the Netserver code seemed to work the best ?

TIA.....

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 09 Mar 2001 14:27:31 +0000

Also sprach mark ross

>What is "MPIP" ?

Multi-link Ppp Interspan Protocol.  Its the proprietary (there is no
open standard that does this really) protocol that 3Com uses to
coordinate the bundling of multi-link ppp links that belong in the same
bundle but get connected to different access servers.

>Any idea which version of the Netserver code seemed to work the best ?

Don't really remember...I don't remember any version of code doing MPIP
anywhere near correctly.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-