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 "majordomo@xmission.com" 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.
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.
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.
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Jeff Mcadams wrote:
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.
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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach mark ross
Jeff Mcadams wrote:
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.
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.
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...
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.
Looking at the 3com software matrix I don't see different versions of software for the "PRI" vs "non PRI" netservers.
To the best of my knowledge, they use the same code base.
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 ?
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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. Jeff Mcadams wrote:
Also sprach mark ross
Jeff Mcadams wrote:
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.
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.
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...
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.
Looking at the 3com software matrix I don't see different versions of software for the "PRI" vs "non PRI" netservers.
To the best of my knowledge, they use the same code base.
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 ?
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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 lack of performance ?
Nope, I don't.
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.
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.
Also did you try setting "ppp in modem" to help reduce the load on the 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.
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.....
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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..... Jeff Mcadams wrote:
Also sprach mark ross
Jeff Mcadams wrote:
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.
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.
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...
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.
Looking at the 3com software matrix I don't see different versions of software for the "PRI" vs "non PRI" netservers.
To the best of my knowledge, they use the same code base.
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 ?
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Also sprach mark ross
I re-read your email tonight and I had a couple more questions for you...
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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (4)
-
Brad Gass -
Jeff Mcadams -
mark ross -
netboss＠cyberport.net