July 1999

Thanks, We have been through all the firmware updates - the iMac firmware, then the apple modem updater 1.3.5. The 3COM Knowledge Base says 1.3.5 is supposed to fix the problems but hasn't in these cases. It's pretty annoying when they can connect to AOL at a better rate than to us. This isn't an isolated case either - we have several people with this problem now - and these are only the ones that call to let us know and are willing to ride it out while we find a solution. Are there any tweaks with the USR unit we can do to work with this? decibal build out on the PRI/ISDN or any of the other numerous switches in the DSP card itself?

Mike Andrews said once upon a time: >You could hook the NMC's console port to, say, the aux port of a Cisco and >set it up to telnet to that, though -- that's what we do for the (few) >times we actually need the menu interface for anything. What was the cabling schematic you used to do this, and how do you configure the Cisco for using the AUX as a terminal?

We will be seeing the last of these very soon.......Stock up - (3) In stock- USR Total Control Units (1)FAN TRAY External (1) NET SERVER CARD REV.5 486DX/4 16MB USR#001369-00 with token Ring NIC (1) NETWORK MANAGEMENT CARD REV.3 USR#000978-00 with token Ring NIC (15) QUAD V.34 ANALOG/DIGITAL MODEM REV.2 USR#000793-04 (60 Analog Ports) (15) NIC ANALOG ADAPTERS USR#000385-00 (2) AC PSU 45A CARD USR BUILD DATE 10/28/96 Price $2,950.00 + Shipping We have about (20) Quad digital/analog modem cards left. USR PART#000793-04 Price $175 each + Shipping Also Have (2) High Speed USR WAN CONSOLE CARDS USR PART # 001003-00 R:F Price: Offer Please correspond via private email All units in stock ready to ship today.. DOA warranty. We accept VISA/MC/AMEX/DISCOVER FL residents add 6.5% sales tax Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

If they can connect to other services at high speeds, then the problem is not with their subscriber lines. Make sure they have the latest drivers for their modems. Apple has an updater for the iMac (and internal modems on G3s) and Global Village has the updates for their external modems. They usually work well with the TC after the update. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan > Sent: Wednesday, June 30, 1999 8:42 PM > To: usr-tc@xmission.com > Subject: (usr-tc) Global Village, iMac modems > > > Hi, > > We're having some awful problems with iMacs and Global Village modems > connecting. Some seem to be okay and others get 24,000 and > 26,400 connects. > This is subscriber line problems since they can get into AOL and > others at > high speed. > > Are there any settings on our Hiper DSP units that we can > fiddle with to > help get these connect speed numbers up and more reliable? > > Thanks, > > - Mike > > - > 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. >

On Thu, 1 Jul 1999, Michael DeMan wrote: > It's pretty > annoying when they can connect to AOL at a better rate than to us. This According to a friend of mine at Cisco, AOL is moving to the AS5800 for a dial solution, so maybe they have in your area. I know in the past we could say "well AOL is using the same equipment, so if you connect there you should be able to connect here"... But I'm not sure that's the case anymore. Just a data point, Charles > > ---------- > >From: "Wayne Barber" <barberw@tidewater.net> > >To: <usr-tc@lists.xmission.com> > >Subject: RE: (usr-tc) Global Village, iMac modems > >Date: Thu, Jul 1, 1999, 10:08 AM > > > > >If they can connect to other services at high speeds, then the problem is > >not with their subscriber lines. > > > >Make sure they have the latest drivers for their modems. Apple has an > >updater for the iMac (and internal modems on G3s) and Global Village has the > >updates for their external modems. They usually work well with the TC after > >the update. > > - > 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. >

Take an old PM2e and set it up as a Terminal server at 9600bps and telnet to the ports 2001 for port s1, etc... This is a solution that costs a few buck$ and it's worth gold to grab a console on anything. This setup is flawless. A PM with 9600bps consoles will never crash... and as it loads in a minute, you could grab one of those timers which switch on the power at precise moments in the day (like shut down the PM between 2am and 2:15am), which will eliminate all possible memory leak in the PM. My only wish is that 3com should give one console cable with every thing they sell (HDM's included !), or give me a price for 50 console cables, for my remaining DSP's and my laptop ;-) Cheers, Robert -----Original Message----- From: Mike Andrews [SMTP:mandrews@termfrost.org] Sent: jeudi, 1. juillet 1999 00:20 To: usr-tc@lists.xmission.com Subject: RE: (usr-tc) Access to NMC You're not supposed to be able to telnet to an NMC. The only way to get to the command prompt is via the console port. (And like you said, if you can't ping it, that's the only way into it.) About all they speak is SNMP. You could hook the NMC's console port to, say, the aux port of a Cisco and set it up to telnet to that, though -- that's what we do for the (few) times we actually need the menu interface for anything. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

Would some kind soul provide the CLI commands to configure the Netserver 8i+ to connect to an ISP, preferably on a permanent basis, if not permanent connection, at least one with a long time out, we have enough traffic throughout day, that unit would stay up. Currently, we have an external router connecting to ISP, I'd like to eliminate that box & let the Netserver do all routing & dial in/out functions. TIA John Schmerold Katy Computer, LLC 20 Meramec Station Rd Valley Park, MO 63088 314-316-9000 v 314-316-9200 f email: john@katy.com

Yesterday morning I was out to upgrade one of our ARC's with 4.1.59-6. I was doing this at around 3 am so I wouldn't make that many people mad, of course. Anyways the sdl went fine, software reset also went fine, then when I went to reset the hardware, and the fit hit the shan. The ARC would not reset, it just turned yellow and sat there. Anyone out there run into this problem? What did you do? Thanks for the Help. -John- >=========================================================< > -John Nelson | email: < > --Technical Support | johnn@jorsm.com < > ---JORSM Internet | < > ----Toll Free # 1-877-JORSM95 | < >=========================================================< >=========================================================< > JORSM Internet < > Regional Premium Internet Service Provider < > Serving Chicagoland and NW Indiana < > 927 Sheffield Ave Dyer, IN < > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < >=========================================================<

> Yesterday morning I was out to upgrade one of our ARC's with 4.1.59-6. I > was doing this at around 3 am so I wouldn't make that many people mad, of > course. Anyways the sdl went fine, software reset also went fine, then > when I went to reset the hardware, and the fit hit the shan. The ARC would > not reset, it just turned yellow and sat there. Anyone out there run into > this problem? What did you do? > > Thanks for the Help. Try pulling and reseating the card. If that does not work, do the 4.1.59-6 upgrade again and see what happens.

Well I did try the sdl again, and It kept saying that the file I was downloading was not an sdl, and TCM would not let me download again, then we went up there and pulled the card, threw it back in, that was a no go too. We eventually took another ARC from a chassis that doesn't really get alot of calls and set it up for that chassis. At 10:22 AM 7/2/99 -0500, you wrote: > >> Yesterday morning I was out to upgrade one of our ARC's with 4.1.59-6. I >> was doing this at around 3 am so I wouldn't make that many people mad, of >> course. Anyways the sdl went fine, software reset also went fine, then >> when I went to reset the hardware, and the fit hit the shan. The ARC >would >> not reset, it just turned yellow and sat there. Anyone out there run into >> this problem? What did you do? >> >> Thanks for the Help. > > >Try pulling and reseating the card. If that does not work, do the 4.1.59-6 >upgrade again and see what happens. > > > >- > 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. > > >=========================================================< > -John Nelson | email: < > --Technical Support | johnn@jorsm.com < > ---JORSM Internet | < > ----Toll Free # 1-877-JORSM95 | < >=========================================================< >=========================================================< > JORSM Internet < > Regional Premium Internet Service Provider < > Serving Chicagoland and NW Indiana < > 927 Sheffield Ave Dyer, IN < > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < >=========================================================<

I just had a customer call and complain that his WebTV Plus box has a hard time dialing into our service. It eventually connects, but it may take him several tries. Does anyone have any more experience with these than I do? (It wouldn't be hard). We are currently running: Quad modems: 5.9.9 HiperDSP: 1.2.60 HiperARC: 4.1.59_6 NMC: 5.5.5 Thanks, Wayne Barber Coastal Telco Services

My leases on my USR 2059 bundles start to expire soon. I need to decide if I get new chassis with Hiper DSPs or lease the 2059 bundles for another year. How do the Hiper DSPs compare vs the Quad modems for V.90? I'm using CT1s, so ISDN is not an issue. BTW, 3Com's pricing is really pissing me off! I can buy a double play kit and get 48 ports, plus either 24 ports free or trade in 48 quads towards Hiper DSPs. But, I cannot buy a full chassis and get any free modems! I need at least one regular bundle so I get a HiperARC. Brian

Can you get to the console? Do you see anything at the console at all? Is the card in a reboot state etc? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 2 Jul 1999, John Nelson wrote: > Well I did try the sdl again, and It kept saying that the file I was > downloading was not an sdl, and TCM would not let me download again, then > we went up there and pulled the card, threw it back in, that was a no go > too. We eventually took another ARC from a chassis that doesn't really get > alot of calls and set it up for that chassis. > > > > At 10:22 AM 7/2/99 -0500, you wrote: > > > >> Yesterday morning I was out to upgrade one of our ARC's with 4.1.59-6. I > >> was doing this at around 3 am so I wouldn't make that many people mad, of > >> course. Anyways the sdl went fine, software reset also went fine, then > >> when I went to reset the hardware, and the fit hit the shan. The ARC > >would > >> not reset, it just turned yellow and sat there. Anyone out there run into > >> this problem? What did you do? > >> > >> Thanks for the Help. > > > > > >Try pulling and reseating the card. If that does not work, do the 4.1.59-6 > >upgrade again and see what happens. > > > > > > > >- > > 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. > > > > > >=========================================================< > > -John Nelson | email: < > > --Technical Support | johnn@jorsm.com < > > ---JORSM Internet | < > > ----Toll Free # 1-877-JORSM95 | < > >=========================================================< > >=========================================================< > > JORSM Internet < > > Regional Premium Internet Service Provider < > > Serving Chicagoland and NW Indiana < > > 927 Sheffield Ave Dyer, IN < > > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < > >=========================================================< > > - > 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. >

On Fri, 2 Jul 1999, John Nelson wrote: >Well I did try the sdl again, and It kept saying that the file I was >downloading was not an sdl, and TCM would not let me download again, then >we went up there and pulled the card, threw it back in, that was a no go >too. We eventually took another ARC from a chassis that doesn't really get >alot of calls and set it up for that chassis. Don't use TCM to upgrade an ARC... it's too **** slow and the arc will let you tftp the file (name it netserve.dmf) directly to/from the card. If it doesn't like the image it was sent, zmodem upload the dmf from the console with a flash reformat -- "AT{ZF}" I think. --Ricky

Same thing happened to me. I tried to a day to get it back with no luck so I called and had a replacement shipped overnight. If you get it back, let us know how you did it. Mark Green Apple Inc ----- Original Message ----- Sent: Friday, July 02, 1999 10:58 AM > Yesterday morning I was out to upgrade one of our ARC's with 4.1.59-6. I > was doing this at around 3 am so I wouldn't make that many people mad, of > course. Anyways the sdl went fine, software reset also went fine, then > when I went to reset the hardware, and the fit hit the shan. The ARC would > not reset, it just turned yellow and sat there. Anyone out there run into > this problem? What did you do? > > Thanks for the Help. > > -John- > >=========================================================< > > -John Nelson | email: < > > --Technical Support | johnn@jorsm.com < > > ---JORSM Internet | < > > ----Toll Free # 1-877-JORSM95 | < > >=========================================================< > >=========================================================< > > JORSM Internet < > > Regional Premium Internet Service Provider < > > Serving Chicagoland and NW Indiana < > > 927 Sheffield Ave Dyer, IN < > > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < > >=========================================================< > > - > 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. >

I've only done limited testing, so if you think this affects you you may want to test it for yourself. For compatibility, the HiperArc will accept the old Netserver syntax for filters passed via Radius in "IP-(direction)-Filter" attribute. The "fall off the end" rule for a real, native Netserver filter is to block. The "fall off the end" rule for a HiperArc filter is pass thru. The "fall off the end" rule for a HiperArc when sent a "legacy" Netserver filter as a radius attribute is pass thru. The risks are obvious. (I have not, nor will I be, testing stored filtered. If you have some, you may want to.) -- Aaron Nabil

Yesterday we installed a second Arc into our chassis. Everything appeared to be OK at first glance. No errors on any cards. Then last night when traffic picked up we discovered that the 6th dsp will not answer. When you dial in and slots 1-5 are busy instead of hearing a handshake you get dead silence. We use CT-1's for our dial up trunks. We have swaped cards and reset cards nothing has helped. Any help would be appreciated as my administrator headed out for the holiday after the upgrades yesterday and won't be back till Monday. Greg Owens Magnolia Internet Services

I think we've had the best luck setting the VanJacobsen compression on in Radius and doing a ppp authentication_preference PAP on the HARC. Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org -----Original Message----- >I just had a customer call and complain that his WebTV Plus box has a hard >time dialing into our service. It eventually connects, but it may take him >several tries. >Does anyone have any more experience with these than I do? (It wouldn't be >hard). > >We are currently running: >Quad modems: 5.9.9 >HiperDSP: 1.2.60 >HiperARC: 4.1.59_6 >NMC: 5.5.5 > >Thanks, >Wayne Barber >Coastal Telco Services > > >- > 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. >

Can you provide me with the output of "list chassis" on both ARCs? Also do a "list interface" on both ARCs and make sure that all the modems that should be in service are showing "up" for both adminstrative and operational status. -Steve Greg Owens wrote: > > Yesterday we installed a second Arc into our chassis. Everything appeared to > be OK at first glance. No errors on any cards. Then last night when traffic > picked up we discovered that the 6th dsp will not answer. When you dial in > and slots 1-5 are busy instead of hearing a handshake you get dead silence. > We use CT-1's for our dial up trunks. We have swaped cards and reset cards > nothing has helped. Any help would be appreciated as my administrator > headed out for the holiday after the upgrades yesterday and won't be back > till Monday. > Greg Owens > Magnolia Internet Services > > - > 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.

On Sat, 3 Jul 1999, Greg Owens wrote: > Yesterday we installed a second Arc into our chassis. Everything appeared to > be OK at first glance. No errors on any cards. Then last night when traffic > picked up we discovered that the 6th dsp will not answer. When you dial in > and slots 1-5 are busy instead of hearing a handshake you get dead silence. > We use CT-1's for our dial up trunks. We have swaped cards and reset cards > nothing has helped. Any help would be appreciated as my administrator > headed out for the holiday after the upgrades yesterday and won't be back > till Monday. ok, I am assuming the CT1 has no alarms on it, the hdm is green right? console into the hdm, chdev span, and do "dis spnstats" and make sure its F1 Operational with no alarms. on the arc that controls the hdm, do "list chassis" and make sure it shows slot 6 as a hdm_24 with 24 channels owner yes. when calls come in, do the led's light up, or is their not even lights? are you sure the "start type" is right? ground/loop/wink............... Brian > Greg Owens > Magnolia Internet Services > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

OK did all that and everything showed up as it should be. but no lights would come on when a call hit the span. SO I did what I probably should have done before I paniced :-) and move one of the known good dial up trunks and move it to the dsp card in question. When I did this it started taking calls. So I guess I can assume that all is well with the chassis and the problem is a bad CT-1 trunk that just happen to go down at the same time we made the changes to the system ( If I am wrong in assuming this let me know). SWB is supposed to be looking at the line now.... Brian and Steve thanks for offering your help. I really appreciate it. Have a Happy 4th -----Original Message----- >On Sat, 3 Jul 1999, Greg Owens wrote: > >> Yesterday we installed a second Arc into our chassis. Everything appeared to >> be OK at first glance. No errors on any cards. Then last night when traffic >> picked up we discovered that the 6th dsp will not answer. When you dial in >> and slots 1-5 are busy instead of hearing a handshake you get dead silence. >> We use CT-1's for our dial up trunks. We have swaped cards and reset cards >> nothing has helped. Any help would be appreciated as my administrator >> headed out for the holiday after the upgrades yesterday and won't be back >> till Monday. > >ok, I am assuming the CT1 has no alarms on it, the hdm is green right? >console into the hdm, chdev span, and do "dis spnstats" and make sure its >F1 Operational with no alarms. > >on the arc that controls the hdm, do "list chassis" and make sure it shows >slot 6 as a hdm_24 with 24 channels owner yes. > >when calls come in, do the led's light up, or is their not even lights? > >are you sure the "start type" is right? ground/loop/wink............... > >Brian > > >> Greg Owens >> Magnolia Internet Services >> >> >> - >> 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. >> > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > >- > 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. >

Ok, for what its worth, I ran into a puzzling situation yesterday with a new CT1 provided by an ILEC to a new HiPer setup, and thought I would share the solution I found that worked in my case... problem: whenever a call came into the DSP card, we would get total silence. The utilization graph on the front of the DSP card would light up, and 'display atstat' on the DSP card showed the incoming call on the first DS0. A few seconds later, the caller would hear a soft click on the line, and the DSP card showed the channel was idle again. No carrier tones, nothing. All T1 span statistics showed the line was perfectly clean, 'list interfaces' showed all modems were active, IP pools and all that jazz were correct, but for some reason the modems would not answer. The solution seemed to be by turning off DNIS on the DSP card. (Program Settings->Trunk Settings->Dial In Address) Changed from 'dnis' to 'noAddress'. After this, it has not missed a beat. Not 100% sure if the telco was actually sending us DNIS and/or ANI information or not, as the the switch technician I was dealing with left for vacation after installing the circuit. This may not be the solution to everyone's problems, but worked in my case... a notion to entertain anways. Maybe it will save somebody else a little grief. :) --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net

On Sat, 3 Jul 1999, Greg Owens wrote: > OK did all that and everything showed up as it should be. but no lights > would come on when a call hit the span. SO I did what I probably should have > done before I paniced :-) and move one of the known good dial up trunks and > move it to the dsp card in question. When I did this it started taking > calls. So I guess I can assume that all is well with the chassis and the > problem is a bad CT-1 trunk that just happen to go down at the same time we > made the changes to the system ( If I am wrong in assuming this let me > know). SWB is supposed to be looking at the line now.... Brian and Steve > thanks for offering your help. I really appreciate it. Have a Happy 4th If you have the trunk start type wrong, it will still show green, and behave just as you said below. If its loop start try ground start, or if its ground start try loop start.............you never know with these telcos, but thats usually a common thing for them to screw up on a ct1. Brian > -----Original Message----- > From: Brian <signal@shreve.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Saturday, July 03, 1999 3:22 PM > Subject: Re: (usr-tc) DSP's Not Answering...Help > > > >On Sat, 3 Jul 1999, Greg Owens wrote: > > > >> Yesterday we installed a second Arc into our chassis. Everything appeared > to > >> be OK at first glance. No errors on any cards. Then last night when > traffic > >> picked up we discovered that the 6th dsp will not answer. When you dial > in > >> and slots 1-5 are busy instead of hearing a handshake you get dead > silence. > >> We use CT-1's for our dial up trunks. We have swaped cards and reset > cards > >> nothing has helped. Any help would be appreciated as my administrator > >> headed out for the holiday after the upgrades yesterday and won't be back > >> till Monday. > > > >ok, I am assuming the CT1 has no alarms on it, the hdm is green right? > >console into the hdm, chdev span, and do "dis spnstats" and make sure its > >F1 Operational with no alarms. > > > >on the arc that controls the hdm, do "list chassis" and make sure it shows > >slot 6 as a hdm_24 with 24 channels owner yes. > > > >when calls come in, do the led's light up, or is their not even lights? > > > >are you sure the "start type" is right? ground/loop/wink............... > > > >Brian > > > > > >> Greg Owens > >> Magnolia Internet Services > >> > >> > >> - > >> 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. > >> > > > >----------------------------------------------------- > >Brian Feeny (BF304) signal@shreve.net > >318-222-2638 x 109 http://www.shreve.net/~signal > >Network Administrator ShreveNet Inc. (ASN 11881) > > > > > >- > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake Walt Gnann >I think we've had the best luck setting the VanJacobsen compression on in >Radius For the most part, that's as good as not having set that setting at all. VanJacobsen is negotiated as part of LCP, PAP, occurs after LCP, the reply item specifying VanJacobsen is received with the RADIUS authentication response during PAP, at that point, VanJacobsen has already been negotiated as part of LCP. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Just to update some of the people who were nice enough to help me. All of our channels of the T3 were set correctly except for 1. I had AMI set on all of the trunks except for one which I accidently had set to B8ZS. All of our chanelized T1s are AMI. Once I found the error, I noticed that the line that was set to B8ZS was performing far better than the ones that were set correctly. I left the Mux set to AMI and changed all of the chanelized T1s to B8ZS in the HiperDSPs. This has worked in all cases. From what I understand, AMI allows only 56k per channel max where B8ZS is 64k. I am not sure why this is working, but it is. Russ Miescke Power Web Connect ----- Original Message ----- Sent: Saturday, June 19, 1999 1:20 AM > On Fri, 18 Jun 1999, Frank Basso wrote: > >If you are using channleized t-1's then you have your answer. Can you say Robbed Bit Signalling ? > > > >---------- Original Message ---------------------------------- > >From: "Russ Miescke" <russm@powerweb.net> > >Reply-To: usr-tc@lists.xmission.com > >Date: Fri, 18 Jun 1999 23:22:46 -0500 > > > >>We recently changed to a T3 mux from individual T1s for our dial-up trunks. > >>Since then we have noticed that our disconnect rates for users has tripled. > > RBS ain't a problem until something thinks it's got a 64k path end-to-end > even tho' it has not been explicitely told so. If it's not digital > end-to-end (i.e. a PRI/BRI digital serviced call), then you should never > assume you have the entire 64k channel as there could be any number of > points using in-band signalling (RBS.) > > There could be timing problems between the DSP and the telco and the remote > modem. Drop a PCM code here and there and all hell insues... What kind of > distribution of connect termination reasons are you seeing? I've seen CT1's > all over (800 service almost always is) and never seen any problems. (Ok, > so I did in one idiot case where BTI sold us a "PRI" for 800 access... all > they did was trunk a CT1 into a PRI. Brilliant! Also 99% unusable -- I > could dial the digital switch directly and it worked fine.) > > I'll also add the DSP card could be dropping calls for perceived signal > errors -- e.g. it failed to see a PCM code here and there. This might be > reported as any number of disconnect reasons. (There is, of course, no > proof this happens (or doesn't.)) [The HDSP is much more powerful, but it > also has 40x more to do.] > > --Ricky > > > > - > 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. >

HOw is th e hiper arc setup up? Do a list chassis and send it over please. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 3 Jul 1999, Greg Owens wrote: > Yesterday we installed a second Arc into our chassis. Everything appeared to > be OK at first glance. No errors on any cards. Then last night when traffic > picked up we discovered that the 6th dsp will not answer. When you dial in > and slots 1-5 are busy instead of hearing a handshake you get dead silence. > We use CT-1's for our dial up trunks. We have swaped cards and reset cards > nothing has helped. Any help would be appreciated as my administrator > headed out for the holiday after the upgrades yesterday and won't be back > till Monday. > Greg Owens > Magnolia Internet Services > > > - > 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. >

Even though we have one 3Com box, we decited to go with 15 other Lucent's PM3's since we couldn't wait for 3Com to release of their ComOS with OSPF. 3Com has been promising OSPF for 3 years and still nothing... Their modems are good but their technical support is completely worthless.... I mean completely... Unless you never have technical problems or need help in any way, buy 3Com otherwise I would start looking into some other RAS like the PM3. JB On Sun, 04 Jul 1999, you wrote: > What is the status on OSPF for the Hiper Arc? > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > my next purchase (Cisco 5396 is too expensive and complicated for my > needs.)? > > If the Hiper ARC will have OSPF soon, that will greatly influence my > decision. > > Brian > > > - > 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.

No, it's no VSA 0x9870... Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870 -- Aaron Nabil

What is the status on OSPF for the Hiper Arc? I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for my next purchase (Cisco 5396 is too expensive and complicated for my needs.)? If the Hiper ARC will have OSPF soon, that will greatly influence my decision. Brian

Well, I have heard rumors of it, but if it anything like NFAS in the new code, you'll get it, but won't have any DOCS to ell you how to set it up! I am still trying to get an answer from 3Com on how to set up one D-channel on a DSP that will support 3 DSPs..>!! Still no response! It's nice to have the ability to set thing up, but if you are not told how to do it, the new software revisions are USELESS! Anyway, I am satisfied with the performace of the HiperArc/DSP and quads! Very few customer complaints and the code now seems stable! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Sun, 4 Jul 1999, Brian Elfert wrote: > What is the status on OSPF for the Hiper Arc? > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > my next purchase (Cisco 5396 is too expensive and complicated for my > needs.)? > > If the Hiper ARC will have OSPF soon, that will greatly influence my > decision. > > Brian > > > - > 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 there, The OSPF code I'm trying out works as advertised. It performs exactly as it should in both STUB and TRANSIT areas. And yes, it did come with complete docs on OSPF as well as the new features included in the code release. I haven't tried using the ARC as an Area Border Router yet, as I have no network setups that require this feature yet. pferraro@wna-linknet.com wrote: > > Well, > > I have heard rumors of it, but if it anything like NFAS in the new code, > you'll get it, but won't have any DOCS to ell you how to set it up! I am > still trying to get an answer from 3Com on how to set up one D-channel on > a DSP that will support 3 DSPs..>!! Still no response! It's nice to > have the ability to set thing up, but if you are not told how to do it, > the new software revisions are USELESS! > > Anyway, I am satisfied with the performace of the HiperArc/DSP and > quads! Very few customer complaints and the code now seems stable! > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Sun, 4 Jul 1999, Brian Elfert wrote: > > > What is the status on OSPF for the Hiper Arc? > > > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > > my next purchase (Cisco 5396 is too expensive and complicated for my > > needs.)? > > > > If the Hiper ARC will have OSPF soon, that will greatly influence my > > decision. > > > > Brian > > > > > > - > > 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. -- Nicolas St-Pierre Systems Engineer Internet Access Solutions Ltd. Tel (905) 469-4953 Fax (905) 469-4954

All I know is it wouldn't work without that setting in Radius. Don't know why...don't care why...just happy it works. Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org -----Original Message----- >Thus spake Walt Gnann >>I think we've had the best luck setting the VanJacobsen compression on in >>Radius > >For the most part, that's as good as not having set that setting at all. >VanJacobsen is negotiated as part of LCP, PAP, occurs after LCP, the >reply item specifying VanJacobsen is received with the RADIUS >authentication response during PAP, at that point, VanJacobsen has >already been negotiated as part of LCP. >-- >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. >

Thus spake Walt Gnann >All I know is it wouldn't work without that setting in Radius. Don't know >why...don't care why...just happy it works. I'd be interested in seeing a trace of the login and a bit of usage on one of these customers (mostly as a curiosity) maybe one with the setting, and one without...perhaps someone is lying during LCP negotiation saying they'll accept VJ and then doing so? Perhaps by setting it off in RADIUS, the Arc is deciding not to send any VJ compressed frames, so that avoids the problem? Just a shot in the dark...as its feasible for the RADIUS entry to tell the Arc not to send any VJ compressed frames, but there's really no way for the RADIUS setting to inform the other side that it won't accept them as its already been negotiated. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hello! Has anybody gotton working configuration with: 1) Dual E1 R2 CAS + Quad Digital Modem 2) Hiper ARC 3) RADIUS Citron/Livingston with ANI support? What is R2 version and software relise? Best regards, Vadim Tulinov.

will OSPF routing be available for the older style Total Control units (non hiper) ? JB On Mon, 05 Jul 1999, you wrote: > 4.2 code which is in final beta has ospf. Should be released shortly. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Sun, 4 Jul 1999, Brian Elfert wrote: > > > What is the status on OSPF for the Hiper Arc? > > > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > > my next purchase (Cisco 5396 is too expensive and complicated for my > > needs.)? > > > > If the Hiper ARC will have OSPF soon, that will greatly influence my > > decision. > > > > Brian > > > > > > - > > 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.

We have ad trouble with Lucent Winmodem LTs, HCFs and HSPs. Usually we give a init string to disable all but v.34 and send customer to get the patch to upgrade. We are using 5.10.9 on our modems and was wondering if the newer patches (6.0.6) would take care of these issues on our side w/o customer patching? Thank you Thomas Spaulding, MCP http://www.talweb.com/tsplding/ Staff@TalWeb.com http://www.talweb.com/ Valeyard* in Everquest's E'ci server. Kali Registration # 0978

4.2 code which is in final beta has ospf. Should be released shortly. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sun, 4 Jul 1999, Brian Elfert wrote: > What is the status on OSPF for the Hiper Arc? > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > my next purchase (Cisco 5396 is too expensive and complicated for my > needs.)? > > If the Hiper ARC will have OSPF soon, that will greatly influence my > decision. > > Brian > > > - > 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. >

Thus spake T.Spaulding >We have ad trouble with Lucent Winmodem LTs, HCFs and HSPs. Usually we give >a init string to disable all but v.34 and send customer to get the patch to >upgrade. >We are using 5.10.9 on our modems and was wondering if the newer patches >(6.0.6) would take care of these issues on our side w/o customer patching? We're using 5.9.9 and 5.10.9 on our quads...Lucent Winmodems with code prior to 5.32 on them were absolutely worthless. While I haven't tried the 6.0.6 code on the quads, my best guess is that you're doing the best thing you can with those winmodems. I think winmodems are crap anyway...and this particular type was *really* sucky. Newer drivers got better, but that's really not saying much. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I have a new customer with a pipeline 75 that will be dialing into a tc hub. I am subnetting a /27 to them. I have my cisco and tc box set up. I will not be able to visit their site and have to configure this over the phone with them. I have used pipeline 130's before in my network but not with a customer. I also did not find anything on ascend's web site that was specific to the 75 to total control config on the customer end. I am sure there are only 5 or 6 parameters that need to be set. Can anyone give me a url to a config for the customer or a set of instructions that would make this go smooth for them? All help is appreciated. thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

No, it's not VSA 0x9870... Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870 -- Aaron Nabil

NO Available only for Hiper arc. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 5 Jul 1999, Jorg B. wrote: > will OSPF routing be available for the older style Total Control units (non > hiper) ? > > JB > > > On Mon, 05 Jul 1999, you wrote: > > 4.2 code which is in final beta has ospf. Should be released shortly. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Sun, 4 Jul 1999, Brian Elfert wrote: > > > > > What is the status on OSPF for the Hiper Arc? > > > > > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > > > my next purchase (Cisco 5396 is too expensive and complicated for my > > > needs.)? > > > > > > If the Hiper ARC will have OSPF soon, that will greatly influence my > > > decision. > > > > > > Brian > > > > > > > > > - > > > 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. >

I have a copy of an old online (now offline) document that used to be on Ascend's web site. I hope this helps you... I change the values appropriately and fax/email them to our customers. Enjoy! Jason Routing IP between a Pipeline Unit and a USR Total Control Table of Contents =B7 Scope =B7 Abstract =B7 Requirements =B7 Steps =B7 Common Configuration Errors =B7 See Also=85 Scope This document applies to the following Ascend products: =B7 Pipeline 50, 75, 85, and 130 routers Abstract This guide helps you configure an Ascend Pipeline ISDN router to dial int= o a USR Total Control (TC) with digital service delivered on a switched T1 or PRI. A "local user's profile" on a NETServer card (the ISDN gateway for = the TC) will be used for authentication. Requirements Network related: =B7 The TC is assigning IP addresses from a pool or DHCP server OR the Pipeline unit is configured with a Static IP address. =B7 RADIUS is not being used. =B7 The user is a dial-in network-user. =B7 PAP or CHAP authentication is implemented. =B7 Multi-Link Point to Point Protocol (MLPPP or MP) is enabled. =B7 Van Jacobson (VJ) compression being used. =B7 The ISDN ports on the NETServer card are configured properly. =B7 The call to the TC is delivered on a switched T1 (56K or 64K) or PRI. User related: =B7 You have access to your Pipeline unit's Menu Interface. If your Pipel= ine unit is configured with an IP address on your LAN, use telnet to access t= he unit to manipulate the menus. If you have not configured the Pipeline uni= t with an IP address, connect to the Pipeline unit through its terminal por= t. For help, refer to Connect to your Pipeline through its Terminal Port. Steps 1. Configuring the Pipeline unit for Static IP address assignment Main Edit Menu... Configure... My Name =3D (user or login name provided to you by your ISP -- case sensi= tive) My Addr =3D (IP address that your ISP has assigned specifically for your Pipeline unit) NETServer only uses host-based routing -- the netmask will always be 255.255.255.0 or no subnetting Rem Name =3D (your ISP's name or name of their NETServer card) Rem Addr =3D (NETServer's IP address -- net0) Dial # =3D (phone number to your ISP's router you will be dialing into) Route =3D IP Bridge =3D No Send Auth =3D PAP or CHAP (Your ISP must tell you which to select) Send PW =3D (The case sensitive password assigned to you) Recv Auth =3D (Leave at default setting) Recv PW =3D (Leave at default setting) Save =3D * (Go ahead and save your changes) Main Edit Menu... Ethernet... Static Rtes... Default... Name =3D Default Active =3D Yes Dest =3D 0.0.0.0/0 Gateway =3D (Your ISP's router IP address--same as Rem Addr) Metric =3D (Leave at default setting) Preference =3D (Leave at default setting if you have this option) Private =3D (Leave at default setting) 2. Configuring the Pipeline unit for Dynamic IP address assignment from NETServer Card Main Edit Menu... Configure... My Name =3D (user or login name provided to you by your ISP--case sensiti= ve) My Addr =3D (enter a bogus IP address (for example, an unregistered addre= ss on your private network). This address must have three digits in each octet (192.168.100.100/24 would work, 192.168.99.1/24 would not). Make sure th= e single workstation you are connecting has an IP address on the same netwo= rk. For example, if your Pipeline unit has an address of 200.200.200.200/24, then set your workstation to an address of 192.168.100.101 with a subnet mask of 255.255.255.0.) Rem Name =3D (ISP name or name of their NETServer card ) Rem Addr =3D (enter the IP address of your ISP's NAS [the NETServer's IP address - net0]. Entering another bogus address that is NOT on your loca= l network will work. You MUST enter something. Leaving the address at 0.0.0= .0 will not work.) Dial # =3D (phone number to your ISP's router you will be dialing into) Route =3D IP Bridge =3D No Send Auth =3D PAP or CHAP (your ISP must tell you which to select) Send PW =3D (case sensitive password assigned to you) Recv Auth =3D (leave at default setting) Recv PW =3D (leave at default setting) Save =3D * (save your changes) Main Edit Menu... Ethernet... Mod Config... NAT Routing =3D Yes NAT Profile =3D (same name entered under "Rem Name") Common Configuration Errors The TC will terminate the ISDN call on the Dual PRI card. The call passes= to the HDLC processors on the ISDN Gateway (the NETServer card). The user's table is defined, with specifics pertaining to your connection profile. A= lso included are parameters pertaining to the port types, default gateway, IP Pool Addresses, and a number of other things. Check to make sure that NETServer card is using PAP or CHAP. Use this information to set the values on your Pipeline unit accordingly. If VJ compression is turned on in the NETServer card (but not on the Pipeline unit) it will not be used (and vice versa). > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of eric@dol.net > Sent: Tuesday, July 06, 1999 1:21 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Pipe line 75 config > > > I have a new customer with a pipeline 75 that will be dialing into > a tc hub. I am subnetting a /27 to them. I have my cisco and > tc box set up. I will not be able to visit their site and have > to configure this over the phone with them. I have used pipeline > 130's before in my network but not with a customer. I also did > not find anything on ascend's web site that was specific to the > 75 to total control config on the customer end. > I am sure there are only 5 or 6 parameters that need to be set. > Can anyone give me a url to a config for the customer or a set > of instructions that would make this go smooth for them? > All help is appreciated. > thanks > eric > > Delaware Online!.........The SMART Choice! > With 56K V.90 & X2 & Flex Modems > Phone : 302-762-0375 > Fax: 302-762-3462 > Failure is NOT an option... > > > > - > 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. >

On Mon, 5 Jul 1999, Vadim Tulinov wrote: |Has anybody gotton working configuration with: | |1) Dual E1 R2 CAS + Quad Digital Modem |2) Hiper ARC |3) RADIUS Citron/Livingston with ANI support? | |What is R2 version and software relise? | |Best regards, |Vadim Tulinov. Yes, but the chassis with quads use Netserver not ARC. The versions are: Dual E1 CAS: 1.3.4 Quads: 6.1.6 or 6.0.6 But they work fine, since the previous release. Radius: Livingston RADIUS 2.0.1 What is your real problem? - Marcelo

I don't think you're going to be able to get around patching the modems. We've found that upgrading the LT Winmodems to any code revision past 5.39 usually does the trick...probably the best winmodem out there (bang-for-buck) with up-to-date drivers. The LT drivers are very easy to install so most lusers should be able to do it no problem. I've decided there's no hope for the HCF modems. There's some good resources on both modems at http://808hi.com/56k/ Walt Walter N. Gnann ISLC, President 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org -----Original Message----- >We have ad trouble with Lucent Winmodem LTs, HCFs and HSPs. Usually we give >a init string to disable all but v.34 and send customer to get the patch to >upgrade. > >We are using 5.10.9 on our modems and was wondering if the newer patches >(6.0.6) would take care of these issues on our side w/o customer patching? > >Thank you > > >Thomas Spaulding, MCP http://www.talweb.com/tsplding/ >Staff@TalWeb.com http://www.talweb.com/ >Valeyard* in Everquest's E'ci server. >Kali Registration # 0978 > > > > >- > 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. >

On Tue, 6 Jul 1999, Brian Elfert wrote: > Even though I'd love to be able to buy more PM3s, I have been buying more > USR/3Com stuff because the modems just work. Yup. Our experience has been Cisco (non-MICA) and USR had the best modem code, with Cisco being the top of the line and USR somewhere in the middle. Recent USR modem code puts USR close to Cisco so we might start buying more HiperDSP cards instead of Ciscos 8) > The Portmaster list is still full of people bitching about the modems not > working. The point most people seem to be missing is that it doesnt matter whether the term server CLI gives the ISP warm fuzzies or whether it does OSPF or BGP4 or XYZABC. What matters is if the customers can *connect reliably*, and *stay connected*. If an ISP values the satisfaction of its admins over the satisfaction of its customers, its not going to be around for very long. -Dan

On Sun, 4 Jul 1999, Jorg B. wrote: > Even though we have one 3Com box, we decited to go with 15 other > Lucent's PM3's since we couldn't wait for 3Com to release of their ComOS > with OSPF. 3Com has been promising OSPF for 3 years and still nothing... Sure, the PM3s are nice technically, and the support is pretty good, but the modem code is pure crap. I like to get new customers, and retain current ones, so I need modems that don't spontaneously disconnect, actually connect, and connect at 56k speeds. Some modems will connect at 33.6 to a PM3 but at 56k speeds to a USR/3Com TC. I originally went with USR to get 56k speeds before the others. I bought a PM3 quite a while later to be able to support both K56Flex and x2. Even though I'd love to be able to buy more PM3s, I have been buying more USR/3Com stuff because the modems just work. The Portmaster list is still full of people bitching about the modems not working. Brian

> The point most people seem to be missing is that it doesnt matter whether > the term server CLI gives the ISP warm fuzzies or whether it does OSPF or > BGP4 or XYZABC. What matters is if the customers can *connect reliably*, > and *stay connected*. If an ISP values the satisfaction of its admins > over the satisfaction of its customers, its not going to be around for > very long. Amen! And every time one of the "other" vendors comes around asking me to demo their equipment, this is basically what I tell them. Of course, the sales people always believe their modems are just as good, but typically, the can never match USR/3COM. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Senior Vice President - Exec-PC, Inc. - A Voyager.net company |

On Mon, 5 Jul 1999, Jorg B. wrote: >will OSPF routing be available for the older style Total Control units (non >hiper) ? In a word: NO. Only those things based on "Pilgram" will ever have any hope of OSPF. The Netserver card is "dead." (I believe the prefered term is EOL.) --Ricky

Hi all! What happens when I change pbus reported_port_density on production equipment? Does current connected users get stop accounting records with new nas port or old? Using 4.1.59-6 on harc. Thanks, __________________________________ Kalev Nurklik MicroLink Online Sakala 19, 10141 Tallinn, Estonia Tel: +372 6 308 909 Fax: +372 6 308 901 E-mail: k.nurklik@online.ee http://www.online.ee

On Thu, 1 Jul 1999, Pete Ashdown wrote: > Mike Andrews said once upon a time: > > >You could hook the NMC's console port to, say, the aux port of a Cisco and > >set it up to telnet to that, though -- that's what we do for the (few) > >times we actually need the menu interface for anything. > > What was the cabling schematic you used to do this, and how do you > configure the Cisco for using the AUX as a terminal? line aux 0 password blah login modem Host transport input all stopbits 1 An easy 3-wire pinout is at http://www.dcr.net/~mandrews/usrtoys/rj45pinouts.html Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

Hello! Marcelo Souza wrote: > On Mon, 5 Jul 1999, Vadim Tulinov wrote: > > |Has anybody gotton working configuration with: > | > |1) Dual E1 R2 CAS + Quad Digital Modem > |2) Hiper ARC > |3) RADIUS Citron/Livingston with ANI support? > | > |What is R2 version and software relise? > | > |Best regards, > |Vadim Tulinov. > > Yes, but the chassis with quads use Netserver not ARC. > The versions are: > > Dual E1 CAS: 1.3.4 > Quads: 6.1.6 or 6.0.6 > > But they work fine, since the previous release. > > Radius: Livingston RADIUS 2.0.1 > > What is your real problem? We haven't gotton problem yet, but our customer is interested this configuration. They can't get ISDN PRI. Do you use R2 Brasil or other type? > > > - Marcelo > > - > 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. Best regards, Vadim.

On Tue, 6 Jul 1999, Vadim Tulinov wrote: |Hello! | |Marcelo Souza wrote: | |> On Mon, 5 Jul 1999, Vadim Tulinov wrote: |> |> |Has anybody gotton working configuration with: |> | |> |1) Dual E1 R2 CAS + Quad Digital Modem |> |2) Hiper ARC |> |3) RADIUS Citron/Livingston with ANI support? |> | |> |What is R2 version and software relise? |> | |> |Best regards, |> |Vadim Tulinov. |> |> Yes, but the chassis with quads use Netserver not ARC. |> The versions are: |> |> Dual E1 CAS: 1.3.4 |> Quads: 6.1.6 or 6.0.6 |> |> But they work fine, since the previous release. |> |> Radius: Livingston RADIUS 2.0.1 |> |> What is your real problem? | |We haven't gotton problem yet, but our customer is interested this |configuration. They can't get ISDN PRI. | |Do you use R2 Brasil or other type? Yes, R2 Brazil. - Marcelo

Thus spake Brett Murphy >I have a Dual T1/E1 NAC (the one with a 186 in it) and it is currently >flashed to the dual chanelised T1 code (3.5.0) and I need to use it in >Australia. I have a dual E1 NIC allready, and it has been suggested >that all I need to do is flash it with the dual E1 PRI firmware, >however pcsdl reports that the hardware is incompatable with the flash >code. Do I need to erase the flash first? if so how? Thanks! Nope, the 186 based card can't do PRI...sorry. The 386 based card can be flashed back to be a dual T1/E1 card, but a T1/E1 card, which is the 186 based card, can't be flashed up to support PRI. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Brett Murphy >Thanks Jeff, why are they called "Dual T1/E1 cards" then?! Because they'll run channelized T1/E1 service...just not ISDN PRI service. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hello Folks, Just a Hot list for you :) Let me know if you have any questions. All available now! USRobotics 1- 2059 Bundle (NMC v90, Netserver PRI, 12- Quad Modems, NO WAN CARD) $3500 1- Chassis, nmc, netserver pri $1700 2- Chassis, nmc $1100each 2- 1866 Chassis with integral fan tray no power $750 1- Dual DC45A Chassis $350 1- Total Switch w/ console module (Any Config) $750 (10BTX8, 100BTX2, 100FX2) 3- Netserver 8 v34 $850 3- Netserver 8I $1500 1- MP8 v34 $700 3- Netserver 16I Plus $3500 (unused in original box) PARTS!!!! MP16I, Netserver 16 v34, Netserver 8I...call or email ******** Also have a gentlemen who is interested in departing with 4 to 6 Hyper DSP cards. He asking $3200. If interested I will pass you the name and email address.

Hi All, I have a Dual T1/E1 NAC (the one with a 186 in it) and it is currently flashed to the dual chanelised T1 code (3.5.0) and I need to use it in Australia. I have a dual E1 NIC allready, and it has been suggested that all I need to do is flash it with the dual E1 PRI firmware, however pcsdl reports that the hardware is incompatable with the flash code. Do I need to erase the flash first? if so how? Thanks! All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

Why didn't you just redistribute rip into ospf for now..........I mean why make that decision based on just that the tc doesn't have ospf yet? On Sun, 4 Jul 1999, Jorg B. wrote: > Even though we have one 3Com box, we decited to go with 15 other Lucent's PM3's > since we couldn't wait for 3Com to release of their ComOS with OSPF. 3Com has > been promising OSPF for 3 years and still nothing... Their modems are good but > their technical support is completely worthless.... I mean completely... Unless > you never have technical problems or need help in any way, buy 3Com otherwise I > would start looking into some other RAS like the PM3. > > > JB > > > On Sun, 04 Jul 1999, you wrote: > > What is the status on OSPF for the Hiper Arc? > > > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > > my next purchase (Cisco 5396 is too expensive and complicated for my > > needs.)? > > > > If the Hiper ARC will have OSPF soon, that will greatly influence my > > decision. > > > > Brian > > > > > > - > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Why didn't you just redistribute rip into ospf for now..........I mean why make that decision based on just that the tc doesn't have ospf yet? On Sun, 4 Jul 1999, Jorg B. wrote: > Even though we have one 3Com box, we decited to go with 15 other Lucent's PM3's > since we couldn't wait for 3Com to release of their ComOS with OSPF. 3Com has > been promising OSPF for 3 years and still nothing... Their modems are good but > their technical support is completely worthless.... I mean completely... Unless > you never have technical problems or need help in any way, buy 3Com otherwise I > would start looking into some other RAS like the PM3. > > > JB > > > On Sun, 04 Jul 1999, you wrote: > > What is the status on OSPF for the Hiper Arc? > > > > I'm trying to decide between the Hiper stuff, Assured Access, or PM3/4 for > > my next purchase (Cisco 5396 is too expensive and complicated for my > > needs.)? > > > > If the Hiper ARC will have OSPF soon, that will greatly influence my > > decision. > > > > Brian > > > > > > - > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I agree. 3Com is the "benchmark" that other vendors seem to use when engineering new modems. Usually your odds are best with 3Com for reliable connects. On Tue, 6 Jul 1999, Curt Shambeau wrote: > > The point most people seem to be missing is that it doesnt matter whether > > the term server CLI gives the ISP warm fuzzies or whether it does OSPF or > > BGP4 or XYZABC. What matters is if the customers can *connect reliably*, > > and *stay connected*. If an ISP values the satisfaction of its admins > > over the satisfaction of its customers, its not going to be around for > > very long. > > Amen! And every time one of the "other" vendors comes around asking me to > demo their equipment, this is basically what I tell them. Of course, the > sales people always believe their modems are just as good, but typically, > the can never match USR/3COM. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Senior Vice President - Exec-PC, Inc. - A Voyager.net company | > -------------------------------------------------------------------------- > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I agree. 3Com is the "benchmark" that other vendors seem to use when engineering new modems. Usually your odds are best with 3Com for reliable connects. On Tue, 6 Jul 1999, Curt Shambeau wrote: > > The point most people seem to be missing is that it doesnt matter whether > > the term server CLI gives the ISP warm fuzzies or whether it does OSPF or > > BGP4 or XYZABC. What matters is if the customers can *connect reliably*, > > and *stay connected*. If an ISP values the satisfaction of its admins > > over the satisfaction of its customers, its not going to be around for > > very long. > > Amen! And every time one of the "other" vendors comes around asking me to > demo their equipment, this is basically what I tell them. Of course, the > sales people always believe their modems are just as good, but typically, > the can never match USR/3COM. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Senior Vice President - Exec-PC, Inc. - A Voyager.net company | > -------------------------------------------------------------------------- > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Just received in (3) USR Total Control Chassis (15) Quad Analog/Digital modem cards Netserver PRI card. token ring nac Net-management card . token ring nac 70 A PSU integrated fan tray $2,975.00 each

Thanks Jeff, why are they called "Dual T1/E1 cards" then?! All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. -----Original Message----- >Thus spake Brett Murphy >>I have a Dual T1/E1 NAC (the one with a 186 in it) and it is currently >>flashed to the dual chanelised T1 code (3.5.0) and I need to use it in >>Australia. I have a dual E1 NIC allready, and it has been suggested >>that all I need to do is flash it with the dual E1 PRI firmware, >>however pcsdl reports that the hardware is incompatable with the flash >>code. Do I need to erase the flash first? if so how? Thanks! > >Nope, the 186 based card can't do PRI...sorry. The 386 based card can >be flashed back to be a dual T1/E1 card, but a T1/E1 card, which is the >186 based card, can't be flashed up to support PRI. >-- >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. >

On Wed, 7 Jul 1999, Brian wrote: >Why didn't you just redistribute rip into ospf for now..........I mean why >make that decision based on just that the tc doesn't have ospf yet? I understand peoples desire to have a "good" routing protocol on the NAS. However, the NAS _is_ an edge device. As such, it doesn't need to have the brains of Cisco 12000. Personally, I'd like to see just about anything other than RIP -- I hate broadcast protocols and RIP isn't "stateful". Having been one of the ARC 4.2 ALPHA testers -- i.e. "the nut" -- to throw an OSPF enabled ARC into the core of an ISP network, you may not be 100% satisfied with the way the ARC does OSPF. It clearly is not a "router" in the full sense, but it does know how to speak OSPF well enough to do away with RIP. (For the record, my ARC attempted to load a _full_ 63,000+ route route table... well, it tried :-) That was back in Feb. And I worked with 3Com on this right up until I left. I'll leave it up to 3Com to reveal why it wouldn't take 63k routes.) --Ricky

Ricky Beam said once upon a time: >Personally, I'd like to see just about anything other than RIP -- I hate >broadcast protocols and RIP isn't "stateful". RIP from my ARC subnet takes more processor on my Cisco 7513 than anything else, and we run a whole lot of other stuff off that 7513.

Thus spake Ricky Beam >On Wed, 7 Jul 1999, Brian wrote: >>Why didn't you just redistribute rip into ospf for now..........I mean why >>make that decision based on just that the tc doesn't have ospf yet? >I understand peoples desire to have a "good" routing protocol on the NAS. >However, the NAS _is_ an edge device. As such, it doesn't need to have >the brains of Cisco 12000. Eh, not necessarily...in typical installations it is, but that's not an absolute statement. Regardless, a nas, even as an edge device, is also a router and has to make routing decisions...sometimes complicated ones, and having a decent routing protocol on there helps tremendously there. I currently don't have much need for such complicated routing decisions on my arcs, but that's largely because I've constrained my network config because the arcs only support RIP...once OSPF support is on there, I'll be making some enhancements to my network design that will take advantage of the benefits that a real routing protocol provides (multiple exits from access networks for example). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 7 Jul 1999, Jeff Mcadams wrote: >Thus spake Ricky Beam >>I understand peoples desire to have a "good" routing protocol on the NAS. >>However, the NAS _is_ an edge device. As such, it doesn't need to have >>the brains of Cisco 12000. > >Eh, not necessarily...in typical installations it is, but that's not an >absolute statement. Regardless, a nas, even as an edge device, is also >a router and has to make routing decisions...sometimes complicated ones, >and having a decent routing protocol on there helps tremendously there. >I currently don't have much need for such complicated routing decisions >on my arcs, but that's largely because I've constrained my network >config because the arcs only support RIP...once OSPF support is on >there, I'll be making some enhancements to my network design that will >take advantage of the benefits that a real routing protocol provides >(multiple exits from access networks for example). All I'm saying is the ARC is not the core of your network. Yes, it may need to know much more than RIP can tell it to do a good job of moving packets around, but seldom is the ARC going to have a large enough choice for me to call it a "router." The only distinction I can make between an ARC and any other classical edge device is the number of connections it's handling. One ARC may be handling the network traffic for 300+ modems (from 300 baud to 64k ISDN [ignoring ML]). That means the ARC needs to have better-than-average internal routing glue to be able to move packets from the ethernet to the correct switched interface. Just count the number of switched interfaces running a high level routing protocol (i.e. > RIP) Yes, the ARC has two 100M ethernet interfaces, but that doesn't mean people are using the ARC to move (route) packets between those interfaces. You certainly can, but you could do the same thing with your windows 95 box at home. Anyone can certainly design all kinds of complicated, convoluted network schemes with the ARC in the thick of it. HOWEVER, the ARC was never designed or envisioned to be part of the core routing within a network. (Well, maybe 3Com envisioned it, but the way the Pilgram code has been written, that's clearly not the case.) And for the record (as should already know,) I never follow the rules. I've never been quoted as saying, "I never thought of that..." --Ricky "Egad, Brain, Brilliant! Oh. No. Wait a minute. What if the dragon eats us?" -- Pinky (Pinky & the Brain)

Thus spake Ricky Beam >All I'm saying is the ARC is not the core of your network. Yes, it may need >to know much more than RIP can tell it to do a good job of moving packets >around, but seldom is the ARC going to have a large enough choice for me >to call it a "router." I guess I'm being a bit more generous to 3Com than what you are at this point...of course, I think pretty much all nasen are routers...this is more semantics than anything, but no, I wouldn't at this point, want an Arc at the core of my network...but I do think it has the potential to be there. Yeah, there are some obstacles to overcome (63k routes ain't gonna hack it here in the next month or so), and if its really gonna be a core router, it'll have to have BGP support. I think at this point...once I see OSPF be in the Arc and solid, I think I'd feel comfortable using it as part of our internal backbone, but obviously, with the lack of ability to handle more than 63k routes I couldn't use it as a full backbone router (ie, it wouldn't be able to be in our iBGP mesh yet). I guess I just see some decent potential for this code base ultimately...yeah, its got a ways to go, but its the first time I've seen something from 3Com that actually seems to work as advertised, (at least close anyway) and has possibilities for future development. >The only distinction I can make between an ARC and any other classical edge >device is the number of connections it's handling. One ARC may be handling >the network traffic for 300+ modems (from 300 baud to 64k ISDN [ignoring >ML]). That means the ARC needs to have better-than-average internal routing >glue to be able to move packets from the ethernet to the correct switched >interface. Just count the number of switched interfaces running a high level >routing protocol (i.e. > RIP) You're looking at the possibility of having 5 in the very near future, and that's without running any high level protocols on *any* "switched" interfaces. 4.2 is gonna have support for a couple of different NICs to the Arcs, one will be a 1 fe, 4 t1 (integrated csu/dsu's), card...that has quite a few possibilities there...and if they keep coming out with greater varieties of NICs in the future, I really do think this platform has some real possibilities ahead of it. >Yes, the ARC has two 100M ethernet interfaces, but that doesn't mean people >are using the ARC to move (route) packets between those interfaces. I'm seriously thinking about it. :) >You certainly can, but you could do the same thing with your windows 95 >box at home. Blech...as much as I like to bash 3Com, they're light-years ahead of win95 in the routing department. >Anyone can certainly design all kinds of complicated, convoluted network >schemes with the ARC in the thick of it. HOWEVER, the ARC was never designed >or envisioned to be part of the core routing within a network. (Well, maybe >3Com envisioned it, but the way the Pilgram code has been written, that's >clearly not the case.) I think the code has been written with the idea that it will eventually do these things...yes there are bugs and parts of it that are poorly written and limiting....those things can be fixed though. >And for the record (as should already know,) I never follow the rules. I've >never been quoted as saying, "I never thought of that..." >"Egad, Brain, Brilliant! Oh. No. Wait a minute. What if the dragon eats > us?" -- Pinky (Pinky & the Brain) Wow...a PaTB fan too? Cool! -- Jeff McAdams | "I think so Brain, but where are we going to IgLou Internet Services | find a duck and a hose at this hour of the e-mail: jeffm@iglou.com | night?" -- Pinky (Pinky & the Brain)

Thus spake Pete Ashdown >Ricky Beam said once upon a time: >>Personally, I'd like to see just about anything other than RIP -- I hate >>broadcast protocols and RIP isn't "stateful". >RIP from my ARC subnet takes more processor on my Cisco 7513 than anything >else, and we run a whole lot of other stuff off that 7513. If you can pull it off, "passive-interface" is your friend. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Scot Desort said once upon a time: >Assuming these settings are contained within the HiperARC, can they be >overridden through RADIUS attributes? For example, I want to send RIP >updates to a customer who has their own subnet, I'd obviously want to >initiate traffic on my side. Why do you want to send RIP to a customer who has a subnet? Don't they know what their own subnet is? Even so, this information should be gleaned from PPP. Routing information isn't needed on the stub, just a static default.

Jeff Mcadams said once upon a time: > >Thus spake Pete Ashdown >>Ricky Beam said once upon a time: >>>Personally, I'd like to see just about anything other than RIP -- I hate >>>broadcast protocols and RIP isn't "stateful". > >>RIP from my ARC subnet takes more processor on my Cisco 7513 than anything >>else, and we run a whole lot of other stuff off that 7513. > >If you can pull it off, "passive-interface" is your friend. :) Already done. The only interface that has RIP going in is the subnet from the ARC's. I even have a filter blocking outgoing RIP from the Cisco back to the ARC's.

On Wed, 7 Jul 1999, Pete Ashdown wrote: >>Personally, I'd like to see just about anything other than RIP -- I hate >>broadcast protocols and RIP isn't "stateful". > >RIP from my ARC subnet takes more processor on my Cisco 7513 than anything >else, and we run a whole lot of other stuff off that 7513. Right... not "stateful". RIP only tells you (every 30 seconds) what routes I'm handling. It never says when to remove a route. The Cisco is having to maintain timer(s) for all that RIP sh*t to know when to remove it from the route table. (Plus it has to almost continuously update the route table.) OSPF, OTOH, only sends a short "hello" every 30 seconds. It tells it's neighbors what routes it's handling and can tell anyone to remove any number of routes at any point. If there are no changes to the topology, then there aren't any routes being transmitted (only the hello's.) Sure, it's got some work to do when a router leaves the OSPF group, but that's only one walk of the route table and one timer. (Ok, so there's more than one timer, but you get the point.) --Ricky

TC chassis with HiperARC/DSP's. What are the necessary commands to set on the HiperARC to prevent it from broadcasting ANY traffic to the dialup user, unless the user initiates the request? I have a some customers for whom the idle timeout is not working, and I want to eliminate the possibility that WE (meaning the TC) is not initiating the traffic and resetting the idle timer. Assuming these settings are contained within the HiperARC, can they be overridden through RADIUS attributes? For example, I want to send RIP updates to a customer who has their own subnet, I'd obviously want to initiate traffic on my side. On another note, I posted a message last week or so about not being able to access my NMC after I changed the IP address, and I was looking for a way to connect to it through ARC. No dice, I know. But I was fiddling around in the ARC CLI, and when I typed 'list chassis', the NMC is _not_ there. I know that when I left my co-lo facility, I had all green lights and no errors anywhere. Why would it not show in the list? Should I do anything when I finally get out to my co-lo to correct the IP address ( I imagine this has a LOT to do with the fact that I can't even ping the NMC right now). Thanks, Scot

Thus spake Pete Ashdown >Jeff Mcadams said once upon a time: >>If you can pull it off, "passive-interface" is your friend. :) >Already done. The only interface that has RIP going in is the subnet from >the ARC's. I even have a filter blocking outgoing RIP from the Cisco back >to the ARC's. Uhm...so, you're not sending RIP back to the Arcs from the Cisco? Then passive-interface that too. :) passive-interface doesn't stop the router from receiving rip routes, just from advertising them out. Right now, the router is going through all the process of creating the route adverts, then dropping them on the floor before it broadcasts them when it checks the ACL. :) Just passive-interface it and be done. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Pete Ashdown >Scot Desort said once upon a time: >>Assuming these settings are contained within the HiperARC, can they be >>overridden through RADIUS attributes? For example, I want to send RIP >>updates to a customer who has their own subnet, I'd obviously want to >>initiate traffic on my side. >Why do you want to send RIP to a customer who has a subnet? Don't they >know what their own subnet is? Even so, this information should be gleaned >from PPP. Routing information isn't needed on the stub, just a static >default. Depending on the setup, that won't work. For example, if the customers subnet is not the "subnet" that the ppp interface IP address is in, then it can't be communicated via IPCP. Regardless, though, throwing RIP down at them doesn't help either. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

OK, let's forget RIP. I still need to know how to setup the ARC and/or RADIUS attributes so that the TC does not initiate traffic when the connection is idle. Also, any thoughts on why by NMC doesn't show under 'list chassis' in ARC CLI? ...Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams > Sent: Wednesday, July 07, 1999 7:05 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) How to eliminate unwanted traffic > > > Thus spake Pete Ashdown > >Scot Desort said once upon a time: > >>Assuming these settings are contained within the HiperARC, can they be > >>overridden through RADIUS attributes? For example, I want to send RIP > >>updates to a customer who has their own subnet, I'd obviously want to > >>initiate traffic on my side. > > >Why do you want to send RIP to a customer who has a subnet? Don't they > >know what their own subnet is? Even so, this information should > be gleaned > >from PPP. Routing information isn't needed on the stub, just a static > >default. > > Depending on the setup, that won't work. For example, if the customers > subnet is not the "subnet" that the ppp interface IP address is in, then > it can't be communicated via IPCP. Regardless, though, throwing RIP > down at them doesn't help either. :) > -- >

Thus spake Scot Desort >OK, let's forget RIP. I still need to know how to setup the ARC and/or >RADIUS attributes so that the TC does not initiate traffic when the >connection is idle. Well...the trick is to figure out what traffic is being sent and deal with it on a case by case basis. Once you figure out what's sending the traffic, figuring out how to stop it should be the easy part. :) >Also, any thoughts on why by NMC doesn't show under 'list chassis' in ARC >CLI? Hrmm...doesn't show up on mine either. Is there any particular reason that the Arc would need to know about the NMC? If its getting chassis awareness messages, you kinda have to assume that the NMC is there, right? :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 7 Jul 1999, Jeff Mcadams wrote: > Thus spake Pete Ashdown > >Ricky Beam said once upon a time: > >>Personally, I'd like to see just about anything other than RIP -- I hate > >>broadcast protocols and RIP isn't "stateful". > > >RIP from my ARC subnet takes more processor on my Cisco 7513 than anything > >else, and we run a whole lot of other stuff off that 7513. > > If you can pull it off, "passive-interface" is your friend. :) all interfaces should be in passive-interface (the way I see it). passive-interface all interfaces, and redistribute into ospf is what we do > -- > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Wed, 7 Jul 1999, Pete Ashdown wrote: > Jeff Mcadams said once upon a time: > > > >Thus spake Pete Ashdown > >>Ricky Beam said once upon a time: > >>>Personally, I'd like to see just about anything other than RIP -- I hate > >>>broadcast protocols and RIP isn't "stateful". > > > >>RIP from my ARC subnet takes more processor on my Cisco 7513 than anything > >>else, and we run a whole lot of other stuff off that 7513. > > > >If you can pull it off, "passive-interface" is your friend. :) > > Already done. The only interface that has RIP going in is the subnet from > the ARC's. I even have a filter blocking outgoing RIP from the Cisco back > to the ARC's. you shouldn't need a filter, "passive-interface" is an outgoing directive I believe, and setting that on interfaces stop them from broadcasting. > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Wed, 7 Jul 1999, Scot Desort wrote: > OK, let's forget RIP. I still need to know how to setup the ARC and/or > RADIUS attributes so that the TC does not initiate traffic when the > connection is idle. > > Also, any thoughts on why by NMC doesn't show under 'list chassis' in ARC > CLI? It doens't matter, it doesn't show up for me, perhaps this is because the nmc is not on the packet bus. > > > ...Scot > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams > > Sent: Wednesday, July 07, 1999 7:05 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) How to eliminate unwanted traffic > > > > > > Thus spake Pete Ashdown > > >Scot Desort said once upon a time: > > >>Assuming these settings are contained within the HiperARC, can they be > > >>overridden through RADIUS attributes? For example, I want to send RIP > > >>updates to a customer who has their own subnet, I'd obviously want to > > >>initiate traffic on my side. > > > > >Why do you want to send RIP to a customer who has a subnet? Don't they > > >know what their own subnet is? Even so, this information should > > be gleaned > > >from PPP. Routing information isn't needed on the stub, just a static > > >default. > > > > Depending on the setup, that won't work. For example, if the customers > > subnet is not the "subnet" that the ppp interface IP address is in, then > > it can't be communicated via IPCP. Regardless, though, throwing RIP > > down at them doesn't help either. :) > > -- > > > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

>Well...the trick is to figure out what traffic is being sent and deal >with it on a case by case basis. Once you figure out what's sending the >traffic, figuring out how to stop it should be the easy part. :) So generally speaking, is there a "basic" checklist of things that should be set either through ARC or RADIUS to eliminate un-needed broadcasts? Or is packet logging and tracing my only recourse? >Hrmm...doesn't show up on mine either. Is there any particular reason >that the Arc would need to know about the NMC? If its getting chassis >awareness messages, you kinda have to assume that the NMC is there, >right? :) The only reason why I bring it up is because last week I started a thread about my NMC where I preconfigured it on my local network, then prepared to move it to my co-lo, changed the IP, set it up at co-lo, got back to ops, and I can't even ping it. I thought that it not showing in ARC had something to do with it, but perhaps not. ...Scot

Thus spake Scot Desort >>Well...the trick is to figure out what traffic is being sent and deal >>with it on a case by case basis. Once you figure out what's sending the >>traffic, figuring out how to stop it should be the easy part. :) >So generally speaking, is there a "basic" checklist of things that should be >set either through ARC or RADIUS to eliminate un-needed broadcasts? Or is >packet logging and tracing my only recourse? Well...step one would be "Framed-Routing = None" in RADIUS to turn off RIP. :) After that, packet logging and tracing would probably be necessary to figure out what's going over the link. >The only reason why I bring it up is because last week I started a thread >about my NMC where I preconfigured it on my local network, then prepared to >move it to my co-lo, changed the IP, set it up at co-lo, got back to ops, >and I can't even ping it. I thought that it not showing in ARC had something >to do with it, but perhaps not. I don't think so...mine didn't show a slot 17 at all...and it shows "--EMPTY--" for slots which don't have any cards in them...I just don't think its programmed to show slot 17 and what's in it. (Does the NMC even include itself in chassis awareness messages? I don't know) And I'm relatively positive that there's no way to get from the Arc over to the NMC to do anything...sucks, but I just don't see any way around it. Maybe a virtual console thing like they have for the DSP's could be implemented in the future? That'd be nice to have for just this type of situation. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake das >I'm not sure, but I beleive slot 17 doesn't have access to the packet bus. >That could be the reason. Yeah...true...but that information is all derived from the chassis awareness messages I believe, which are sent out over the management bus, which the NMC definitely does have access to. Not having access to the packet bus could, however, put a crimp in the virtual console thing...I believe that's done over the packet bus as well... :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thanks for the input Jeff. I _think_ I'm already sending 'Framed-Routing=None', but I'll check tomorrow. ...Scot -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Wednesday, July 07, 1999 9:50 PM Thus spake Scot Desort >>Well...the trick is to figure out what traffic is being sent and deal >>with it on a case by case basis. Once you figure out what's sending the >>traffic, figuring out how to stop it should be the easy part. :) >So generally speaking, is there a "basic" checklist of things that should be >set either through ARC or RADIUS to eliminate un-needed broadcasts? Or is >packet logging and tracing my only recourse? Well...step one would be "Framed-Routing = None" in RADIUS to turn off RIP. :) After that, packet logging and tracing would probably be necessary to figure out what's going over the link. >The only reason why I bring it up is because last week I started a thread >about my NMC where I preconfigured it on my local network, then prepared to >move it to my co-lo, changed the IP, set it up at co-lo, got back to ops, >and I can't even ping it. I thought that it not showing in ARC had something >to do with it, but perhaps not. I don't think so...mine didn't show a slot 17 at all...and it shows "--EMPTY--" for slots which don't have any cards in them...I just don't think its programmed to show slot 17 and what's in it. (Does the NMC even include itself in chassis awareness messages? I don't know) And I'm relatively positive that there's no way to get from the Arc over to the NMC to do anything...sucks, but I just don't see any way around it. Maybe a virtual console thing like they have for the DSP's could be implemented in the future? That'd be nice to have for just this type of situation. -- 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.

Are proper settings for the HiPerDSP NFAS parameters documented anywhere? Telco (Pac Bell) tells me I need to set the "NFAS Interface ID" to 0 on the "Package 1" span that has the primary D channel and to 1 on the "Package 2" spans that are B-channel only. They haven't a clue about the "Logical Group Number". I assume that the "NFAS Span D-Channel Type should be set to "dChannelPrimary" on the Package 1 and "dChannelNone" on the Package 2s and that the "Logical Group Type" should be set to "nfas" rather than "fas" or "ss7" but I could be dead wrong. Also, when I upgrade the firmware from 1.2.x to 2.0.81 on a DSP the Loopback/D-alarm LED comes on, even though the card isn't showing any alarms and isn't in loop[back. I've read and re-read the 2.0.81 release notes to no avail. What am I missing? My on-site staff who are trying to find some jumpers (none appear to have been provided) for strapping J9 on the DSPs as specified in the 2.0.81 release notes report that J9 is a 5-position header rather than 3-position as shown in the release notes. Does anyone know which pins should be jumpered? TIA for any help. I don't relish the thought of spending days on the phone with Pac Bell trying all possible combinations of the parameters. I relish the thought of spending all day on the phone with a 3com junior chipmonk tech support troll that wants to dive into my chassis with both feet... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Hi: Dumb question :-( I have a couple of ana/dig quad cards that went wacko after a chassis shutdown restart. If I get replacements that are used but were not in x2/v.90 chassis, will they flash to x2/v.90 in my chassis's that are x2/v.90 feature enabled? I would think so, since the chassis/pri card is what handles the feature enable, but I want to make sure before ordering the cards. Thanks in advance. Bill William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

On Wed, 7 Jul 1999, Scot Desort wrote: >Also, any thoughts on why by NMC doesn't show under 'list chassis' in ARC >CLI? Chassis Awareness turned off? --Ricky

For some reason when I telnet to a HiPer ARC it tries to send accounting information to my radius server. I have made sure the root user's type is set to manage, and that they do not belong to any modem_groups. Any suggestions on what I could do to stop it sending accounting data for the root user??? TIA. ***************************************** Jason Watkins jwatkins@iland.net I-Land NOC Tech, Q2 Admin http://www.iland.net ***************************************** Fast, Dependable Access! *****************************************

I'm not sure, but I beleive slot 17 doesn't have access to the packet bus. That could be the reason. das Jeff Mcadams (jeffm@iglou.com) spake: > Thus spake Scot Desort > >>Well...the trick is to figure out what traffic is being sent and deal > >>with it on a case by case basis. Once you figure out what's sending the > >>traffic, figuring out how to stop it should be the easy part. :) > > >So generally speaking, is there a "basic" checklist of things that should be > >set either through ARC or RADIUS to eliminate un-needed broadcasts? Or is > >packet logging and tracing my only recourse? > > Well...step one would be "Framed-Routing = None" in RADIUS to turn off > RIP. :) After that, packet logging and tracing would probably be > necessary to figure out what's going over the link. > > >The only reason why I bring it up is because last week I started a thread > >about my NMC where I preconfigured it on my local network, then prepared to > >move it to my co-lo, changed the IP, set it up at co-lo, got back to ops, > >and I can't even ping it. I thought that it not showing in ARC had something > >to do with it, but perhaps not. > > I don't think so...mine didn't show a slot 17 at all...and it shows > "--EMPTY--" for slots which don't have any cards in them...I just don't > think its programmed to show slot 17 and what's in it. (Does the NMC > even include itself in chassis awareness messages? I don't know) And > I'm relatively positive that there's no way to get from the Arc over to > the NMC to do anything...sucks, but I just don't see any way around it. > Maybe a virtual console thing like they have for the DSP's could be > implemented in the future? That'd be nice to have for just this type of > situation. > -- > 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. -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ____________________________________________

Version 7.x code ? When did this code become avail, and what does it accomplish? At 12:14 PM 7/8/99 -0400, you wrote: >Another thing to consider when purchasing the older cards. I am learning >that there are cards out there that are single sided and two sided as far >as chip sets go. Single sided being the newer version. There has been >instances where my customers have had problem upgrading the older cards to >more recent code. What I have learned to save yourself the problem is to >upgrade the code in sequence. What I mean is dont go from a 4.x version to >7.x. Actually most wont take it. Must be upgraded to a 5.x version then the >upgrade to the 7.x...Something to do with the code...Somewhere in the 5.x >the code could differnetiate between single and double sided. > > >At 11:32 AM 7/8/99 -0400, you wrote: >>Thus spake William M Sheeler Sr >>>Dumb question :-( >> >>>I have a couple of ana/dig quad cards that went wacko after a chassis >>>shutdown restart. >> >>>If I get replacements that are used but were not in x2/v.90 chassis, will >>>they flash to x2/v.90 in my chassis's that are x2/v.90 feature enabled? I >>>would think so, since the chassis/pri card is what handles the feature >>>enable, but I want to make sure before ordering the cards. >> >>Actually, the NMC card is what handles the feature enable codes. So, as >>long as you have the feature enable code in the NMC, and the quads have >>recent enough code to support v.90 and x2 in them, they'll work like a >>charm. >>-- >>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. William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

Thus spake William M Sheeler Sr >Dumb question :-( >I have a couple of ana/dig quad cards that went wacko after a chassis >shutdown restart. >If I get replacements that are used but were not in x2/v.90 chassis, will >they flash to x2/v.90 in my chassis's that are x2/v.90 feature enabled? I >would think so, since the chassis/pri card is what handles the feature >enable, but I want to make sure before ordering the cards. Actually, the NMC card is what handles the feature enable codes. So, as long as you have the feature enable code in the NMC, and the quads have recent enough code to support v.90 and x2 in them, they'll work like a charm. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Dave, With the code you are using the functionality of the loopback LED has changed. The changes went into Hiper DSP code for the implementation of NFAS In addition to reflecting loopback it now also reflects the D channel state (including NFAS states). A summary of the LED states is listed in the NAC product reference guide, Chapter 1 page 30. The manual is available on totalservice along side the code. LPBK Off Span is CHT1, E1/R2 or NFAS with no D-Channel Green D-Channel is up Flashing green Backup D-Channel is up (NFAS) Red D-Channel is down Yellow Loopback test in progress I hope this helps. John -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com] On Behalf Of Dave Martin Sent: Thursday, July 08, 1999 11:08 AM Are proper settings for the HiPerDSP NFAS parameters documented anywhere? Telco (Pac Bell) tells me I need to set the "NFAS Interface ID" to 0 on the "Package 1" span that has the primary D channel and to 1 on the "Package 2" spans that are B-channel only. They haven't a clue about the "Logical Group Number". I assume that the "NFAS Span D-Channel Type should be set to "dChannelPrimary" on the Package 1 and "dChannelNone" on the Package 2s and that the "Logical Group Type" should be set to "nfas" rather than "fas" or "ss7" but I could be dead wrong. Also, when I upgrade the firmware from 1.2.x to 2.0.81 on a DSP the Loopback/D-alarm LED comes on, even though the card isn't showing any alarms and isn't in loop[back. I've read and re-read the 2.0.81 release notes to no avail. What am I missing? My on-site staff who are trying to find some jumpers (none appear to have been provided) for strapping J9 on the DSPs as specified in the 2.0.81 release notes report that J9 is a 5-position header rather than 3-position as shown in the release notes. Does anyone know which pins should be jumpered? TIA for any help. I don't relish the thought of spending days on the phone with Pac Bell trying all possible combinations of the parameters. I relish the thought of spending all day on the phone with a 3com junior chipmonk tech support troll that wants to dive into my chassis with both feet... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers" - 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 Dave, Configuring NFAS is documented in the HiPer DSP NAC Product Reference Ver 2.0 Chapter 18 (available for download in the 'latest code' section on totalservice alongside the 2.0.19 code). Real quick though, here's how you should configure your cards in 'Span level/Programmed Settings/NFAS Settings' : SPAN 1 SPAN 2 NFAS Interface ID 0 1 Logical Group Number 0 0 NFAS Span D-Channel Type dChannelPri dChannelNone Logical Group Type NFAS NFAS Execute 'Card Level/ActionsCommands/Software/ Save T1 E1 to NVRAM' Execute 'Card Level/ActionsCommands/Hardware/Hardware Reset' The logical group number parameter is local to the hub. This allows you to have several NFAS groups in the same chassis. Say for example that after you get this up and running you want to add 4 more HDSP cards and have another NFAS group of spans brought out to your location. Those spans won't be part of your first NFAS group so you'll have to choose a number for the second NFAS group. So, your first group of NFAS spans will have a logical group number of 0 and your second NFAS group will have a logical group number of 1, or some other number you choose. This way the HiPer DSPs know which NFAS group they belong to. Each HDSP card will advertise and listen for it's group # on the packet bus and it will be able to 'see' the other group members. The LED activity you are seeing is normal. The loopback LED now represents D-Channel states in addition to it's previous loopback functionality. See the NAC Product Reference guide again, chapter 1 page 5. The jumpers being referred to in the Release Notes are for the NIC card rev 2. I'm guessing you might be looking at the NAC? Most likely, you don't have to worry about the jumpers. If you have a NIC rev 1 card just read and understand the section about removing your DS0s from service before removing the NAC (page 12 and 13 of the 2.0.81 release notes) . If you have a NIC rev 2, you don't have to do anything... it comes configured for your application out of the factory. Hope this helps. Regards, David Dave Martin <dpm@netcetera.com> on 07/08/99 11:08:08 AM Please respond to usr-tc@lists.xmission.com Sent by: Dave Martin <dpm@netcetera.com> cc: (David Bachta/MW/US/3Com) Are proper settings for the HiPerDSP NFAS parameters documented anywhere? Telco (Pac Bell) tells me I need to set the "NFAS Interface ID" to 0 on the "Package 1" span that has the primary D channel and to 1 on the "Package 2" spans that are B-channel only. They haven't a clue about the "Logical Group Number". I assume that the "NFAS Span D-Channel Type should be set to "dChannelPrimary" on the Package 1 and "dChannelNone" on the Package 2s and that the "Logical Group Type" should be set to "nfas" rather than "fas" or "ss7" but I could be dead wrong. Also, when I upgrade the firmware from 1.2.x to 2.0.81 on a DSP the Loopback/D-alarm LED comes on, even though the card isn't showing any alarms and isn't in loop[back. I've read and re-read the 2.0.81 release notes to no avail. What am I missing? My on-site staff who are trying to find some jumpers (none appear to have been provided) for strapping J9 on the DSPs as specified in the 2.0.81 release notes report that J9 is a 5-position header rather than 3-position as shown in the release notes. Does anyone know which pins should be jumpered? TIA for any help. I don't relish the thought of spending days on the phone with Pac Bell trying all possible combinations of the parameters. I relish the thought of spending all day on the phone with a 3com junior chipmonk tech support troll that wants to dive into my chassis with both feet... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers" - 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.

Another thing to consider when purchasing the older cards. I am learning that there are cards out there that are single sided and two sided as far as chip sets go. Single sided being the newer version. There has been instances where my customers have had problem upgrading the older cards to more recent code. What I have learned to save yourself the problem is to upgrade the code in sequence. What I mean is dont go from a 4.x version to 7.x. Actually most wont take it. Must be upgraded to a 5.x version then the upgrade to the 7.x...Something to do with the code...Somewhere in the 5.x the code could differnetiate between single and double sided. At 11:32 AM 7/8/99 -0400, you wrote: >Thus spake William M Sheeler Sr >>Dumb question :-( > >>I have a couple of ana/dig quad cards that went wacko after a chassis >>shutdown restart. > >>If I get replacements that are used but were not in x2/v.90 chassis, will >>they flash to x2/v.90 in my chassis's that are x2/v.90 feature enabled? I >>would think so, since the chassis/pri card is what handles the feature >>enable, but I want to make sure before ordering the cards. > >Actually, the NMC card is what handles the feature enable codes. So, as >long as you have the feature enable code in the NMC, and the quads have >recent enough code to support v.90 and x2 in them, they'll work like a >charm. >-- >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. >

I am by no means a expert on these machines or cards. I was given that version a valid v90 code. I have only seen the 4.x and 5.x At 11:26 AM 7/8/99 -0400, you wrote: >Version 7.x code ? When did this code become avail, and what does it >accomplish? > > > > > >At 12:14 PM 7/8/99 -0400, you wrote: >>Another thing to consider when purchasing the older cards. I am learning >>that there are cards out there that are single sided and two sided as far >>as chip sets go. Single sided being the newer version. There has been >>instances where my customers have had problem upgrading the older cards to >>more recent code. What I have learned to save yourself the problem is to >>upgrade the code in sequence. What I mean is dont go from a 4.x version to >>7.x. Actually most wont take it. Must be upgraded to a 5.x version then the >>upgrade to the 7.x...Something to do with the code...Somewhere in the 5.x >>the code could differnetiate between single and double sided. >> >> >>At 11:32 AM 7/8/99 -0400, you wrote: >>>Thus spake William M Sheeler Sr >>>>Dumb question :-( >>> >>>>I have a couple of ana/dig quad cards that went wacko after a chassis >>>>shutdown restart. >>> >>>>If I get replacements that are used but were not in x2/v.90 chassis, will >>>>they flash to x2/v.90 in my chassis's that are x2/v.90 feature enabled? I >>>>would think so, since the chassis/pri card is what handles the feature >>>>enable, but I want to make sure before ordering the cards. >>> >>>Actually, the NMC card is what handles the feature enable codes. So, as >>>long as you have the feature enable code in the NMC, and the quads have >>>recent enough code to support v.90 and x2 in them, they'll work like a >>>charm. >>>-- >>>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. > >William M Sheeler, Sr www.talon.net >ceo >TCRA Computers and voice 610.670.6491 >TALON Network Services, Inc voice 610.670.4923 >Fax for both fax 610.670.6495 > >( Total Area Linked Online Nationwide Network Services, Inc) > > >" Live with Passion " > >" It's in your moments of decision that your destiny is shaped " > ANTHONY ROBBINS > >- > 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. >

FAS is Facility Associated Signaling or 1 D per span NFAS is Non Facility Associated Signaling or 1 D w/ optional backup D per group of spans SS7 is Singaling System 7 or out of band singnaling For more information about SS7 and the Total Control Hub see : http://www.3com.com/europe/news/1998/nov0398a.html and http://www.3com.com/technology/tech_net/white_papers/503022.html Regards, David matthews <matthews@staff.brunnet.net> on 07/08/99 12:00:21 PM Please respond to usr-tc@lists.xmission.com Sent by: matthews <matthews@staff.brunnet.net> cc: (David Bachta/MW/US/3Com) On Thursday, July 08, 1999 1:45 PM, David Bachta [SMTP:David_Bachta@mw.3com.com] wrote: > > SPAN 1 SPAN 2 > > NFAS Interface ID 0 1 > Logical Group Number 0 0 > NFAS Span D-Channel Type dChannelPri dChannelNone > Logical Group Type NFAS NFAS What is the function of having a choice of Logical Group Types? Under what circumstances would one choose SS7 or FAS over NFAS? - 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.

----- Original Message ----- Sent: Thursday, July 08, 1999 11:44 AM >For some reason when I telnet to a >HiPer ARC it tries to send accounting >information to my radius server. I have >made sure the root user's type is set >to manage, and that they do not belong >to any modem_groups. Any suggestions >on what I could do to stop it sending >accounting data for the root user??? > I was wondering the same thing. It's spamming my radius error log, since console users don't send a port number in their accounting packet. Any info on this would be greatly appreciated. Peter D. Mayer NetWalk Systems Administrator dmayer@netwalk.com

On Thursday, July 08, 1999 1:45 PM, David Bachta [SMTP:David_Bachta@mw.3com.com] wrote: > > SPAN 1 SPAN 2 > > NFAS Interface ID 0 1 > Logical Group Number 0 0 > NFAS Span D-Channel Type dChannelPri dChannelNone > Logical Group Type NFAS NFAS What is the function of having a choice of Logical Group Types? Under what circumstances would one choose SS7 or FAS over NFAS?

David, I want to thank you for FINALLY clearing this issue up.... I have tried for the last 3 weeks to get someone to tell us how this is configured!! Thanks again! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Thu, 8 Jul 1999, David Bachta wrote: > > > Hi Dave, > > Configuring NFAS is documented in the HiPer DSP NAC Product Reference Ver 2.0 > Chapter 18 (available for download in the 'latest code' section on totalservice > alongside the 2.0.19 code). > > Real quick though, here's how you should configure your cards in 'Span > level/Programmed Settings/NFAS Settings' : > > SPAN 1 SPAN 2 > > NFAS Interface ID 0 1 > Logical Group Number 0 0 > NFAS Span D-Channel Type dChannelPri dChannelNone > Logical Group Type NFAS NFAS > > Execute 'Card Level/ActionsCommands/Software/ Save T1 E1 to NVRAM' > Execute 'Card Level/ActionsCommands/Hardware/Hardware Reset' > > The logical group number parameter is local to the hub. This allows you to have > several NFAS groups in the same chassis. Say for example that after you get > this up and running you want to add 4 more HDSP cards and have another NFAS > group of spans brought out to your location. Those spans won't be part of your > first NFAS group so you'll have to choose a number for the second NFAS group. > So, your first group of NFAS spans will have a logical group number of 0 and > your second NFAS group will have a logical group number of 1, or some other > number you choose. This way the HiPer DSPs know which NFAS group they belong > to. Each HDSP card will advertise and listen for it's group # on the packet bus > and it will be able to 'see' the other group members. > > The LED activity you are seeing is normal. The loopback LED now represents > D-Channel states in addition to it's previous loopback functionality. See the > NAC Product Reference guide again, chapter 1 page 5. > > The jumpers being referred to in the Release Notes are for the NIC card rev 2. > I'm guessing you might be looking at the NAC? Most likely, you don't have to > worry about the jumpers. If you have a NIC rev 1 card just read and understand > the section about removing your DS0s from service before removing the NAC (page > 12 and 13 of the 2.0.81 release notes) . If you have a NIC rev 2, you don't > have to do anything... it comes configured for your application out of the > factory. > > Hope this helps. > > Regards, > David > > > > > > Dave Martin <dpm@netcetera.com> on 07/08/99 11:08:08 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: Dave Martin <dpm@netcetera.com> > > > To: usr-tc@lists.xmission.com > cc: (David Bachta/MW/US/3Com) > Subject: (usr-tc) NFAS parameters > > > > > Are proper settings for the HiPerDSP NFAS parameters documented anywhere? > > Telco (Pac Bell) tells me I need to set the "NFAS Interface ID" to 0 on the > "Package 1" span that has the primary D channel and to 1 on the "Package 2" > spans that are B-channel only. They haven't a clue about the "Logical > Group Number". I assume that the "NFAS Span D-Channel Type should be set > to "dChannelPrimary" on the Package 1 and "dChannelNone" on the Package 2s > and that the "Logical Group Type" should be set to "nfas" rather than "fas" > or "ss7" but I could be dead wrong. > > Also, when I upgrade the firmware from 1.2.x to 2.0.81 on a DSP the > Loopback/D-alarm LED comes on, even though the card isn't showing any > alarms and isn't in loop[back. I've read and re-read the 2.0.81 release > notes to no avail. What am I missing? > > My on-site staff who are trying to find some jumpers (none appear to have > been provided) for strapping J9 on the DSPs as specified in the 2.0.81 > release notes report that J9 is a 5-position header rather than 3-position > as shown in the release notes. Does anyone know which pins should be > jumpered? > > TIA for any help. I don't relish the thought of spending days on the phone > with Pac Bell trying all possible combinations of the parameters. I relish > the thought of spending all day on the phone with a 3com junior chipmonk > tech support troll that wants to dive into my chassis with both feet... > > ------------------------------------------------------------------------ > Dave Martin Netcetera, Inc. dpm@netcetera.com > "Infinity Welcomes Careful Drivers" > ------------------------------------------------------------------------ > > > > - > 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. >

On Thu, 8 Jul 1999, David Bachta wrote: >For more information about SS7 and the Total Control Hub see : >http://www.3com.com/europe/news/1998/nov0398a.html >and >http://www.3com.com/technology/tech_net/white_papers/503022.html The last one talks about SS7/IP which is sort of worthless in this discussion (the DSP ain't an IP device.) The first one suggests there is a card+software to tie a hiperDSP into an SS7 trunked group. Is this true? Is the software referred to the same 2.0 code people currently have? Is the SS7 NIC available? (This adds a whole new level to the "weird shit" I can think up.) --Ricky

Need nic and nac. If you have any available I would be interested in buying. Doesnt have to be Pro series. Older style is fine. Also looking for modem cards, and dual t1 cards. Always buying USR Steve Rivera WRCA, Inc. www.wrca.net

Jeff Mcadams said once upon a time: >Uhm...so, you're not sending RIP back to the Arcs from the Cisco? > >Then passive-interface that too. :) passive-interface doesn't stop the >router from receiving rip routes, just from advertising them out. > >Right now, the router is going through all the process of creating the >route adverts, then dropping them on the floor before it broadcasts them >when it checks the ACL. :) Just passive-interface it and be done. :) Thanks Jeff. Looks like that dropped my load by about 10%!

I am looking for any qty. Would prefer 12 right off the bat :) Can buy more. Let me know what you have and we an work out a buy price.

Steve, I have these... possibly 50 in stock Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Thursday, July 08, 1999 3:35 PM I am looking for any qty. Would prefer 12 right off the bat :) Can buy more. Let me know what you have and we an work out a buy price. - 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.

Have a part number, any body know what this is ? Need (5) 3COM NetServer Cards USR# 80-002470-00 any help? Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

I've got a question that probably has a simple answer. I'm running Quad A/D's and a Netserver authenticating against Microsoft IAS. When a user logs in with and win x machine using a terminal program, they are prompted for a username. I enter a username and immediately get a response back of "host is currently unavailable." Quick fix please. Thanks.

Need (5) 000976-0 USR card sets. Please email me in private if you have them. Need ASAP Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

I figured it out. -----Original Message----- Sent: Thursday, July 08, 1999 4:15 PM I've got a question that probably has a simple answer. I'm running Quad A/D's and a Netserver authenticating against Microsoft IAS. When a user logs in with and win x machine using a terminal program, they are prompted for a username. I enter a username and immediately get a response back of "host is currently unavailable." Quick fix please. 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.

how much per set (nic/nac)? At 03:38 PM 7/8/99 -0400, you wrote: >Steve, > >I have these... possibly 50 in stock > >Andrew Shlensky >**************************** >PC Global, Inc. >(305) 667-2111 tel >(305) 667-3636 fax >(305) 216-8638 mobile >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >ALSO:SALES of New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** >----- Original Message ----- >From: Steve Rivera <sales@wrca.net> >To: <usr-tc@lists.xmission.com> >Sent: Thursday, July 08, 1999 3:35 PM >Subject: (usr-tc) wtb: Quad Modem Cards > > >I am looking for any qty. Would prefer 12 right off the bat :) >Can buy more. >Let me know what you have and we an work out a buy price. > >- > 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. >

we just found out about the trade-in on these things... Probably more than youre willing to pay: $295.00 30 day warranty Thanks Steve Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Thursday, July 08, 1999 5:06 PM how much per set (nic/nac)? At 03:38 PM 7/8/99 -0400, you wrote: >Steve, > >I have these... possibly 50 in stock > >Andrew Shlensky >**************************** >PC Global, Inc. >(305) 667-2111 tel >(305) 667-3636 fax >(305) 216-8638 mobile >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >ALSO:SALES of New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** >----- Original Message ----- >From: Steve Rivera <sales@wrca.net> >To: <usr-tc@lists.xmission.com> >Sent: Thursday, July 08, 1999 3:35 PM >Subject: (usr-tc) wtb: Quad Modem Cards > > >I am looking for any qty. Would prefer 12 right off the bat :) >Can buy more. >Let me know what you have and we an work out a buy price. > >- > 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. > - 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.

Thus spake Ricky Beam >On Thu, 8 Jul 1999, David Bachta wrote: >>For more information about SS7 and the Total Control Hub see : >>http://www.3com.com/europe/news/1998/nov0398a.html >>and >>http://www.3com.com/technology/tech_net/white_papers/503022.html >The last one talks about SS7/IP which is sort of worthless in this >discussion (the DSP ain't an IP device.) The first one suggests there >is a card+software to tie a hiperDSP into an SS7 trunked group. Is >this true? Is the software referred to the same 2.0 code people >currently have? Is the SS7 NIC available? I believe 3Com is working on an SS7 solution of some kind, but I'm not sure how close it is to the light of day...it definitely will be for really high end situations though...not something your everyday ISP is gonna wanna use. >(This adds a whole new level to the "weird shit" I can think up.) Woo hoo...more fun :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Thu, 8 Jul 1999, Jeff Mcadams wrote: >I believe 3Com is working on an SS7 solution of some kind, but I'm not >sure how close it is to the light of day...it definitely will be for >really high end situations though...not something your everyday ISP is >gonna wanna use. Depends on one's definition of an "everyday ISP." Sure, most of the small ISPs will continue to use traditional services, but the larger ISPs -- i.e. regional and larger -- will love to be able to use SS7. (esp. if they are a "telco" and can trunk dialtone from all over back to a central location.) >>(This adds a whole new level to the "weird shit" I can think up.) Correction, ... already thought up... almost a year ago. SS7 is a _wonderful_ thing for anyone wanting to centralize their dialup services. I did the math once... 99% of Interpath's dialup lines could be trunked back to a single rack full of hiperDSP/ARC's (that's multiple TC's) pushing almost all of the dialup IP traffic to a central high speed network on a single high speed port microseconds from the border of the ISP network. That was a year ago... now they have their own DMS500 and tandem interconnects making SS7 much much more attractive. (Of course they are drooling for glitchless fail over -- 1) they're nuts. and 2) they're nuts. I know the DSP/ARC won't do that -- the current calls will drop, but they can dial right back in. I don't think the AS5800 can do that either, but they seemed to think they can get Cisco to walk on water if they asked (read: complained) properly.) --Ricky

Thus spake Ricky Beam >On Thu, 8 Jul 1999, Jeff Mcadams wrote: >>I believe 3Com is working on an SS7 solution of some kind, but I'm not >>sure how close it is to the light of day...it definitely will be for >>really high end situations though...not something your everyday ISP is >>gonna wanna use. >Depends on one's definition of an "everyday ISP." Sure, most of the small >ISPs will continue to use traditional services, but the larger ISPs -- i.e. >regional and larger -- will love to be able to use SS7. (esp. if they are >a "telco" and can trunk dialtone from all over back to a central location.) But then, it comes down to cost. From what I've been told by 3Com folks, if you're talking bringing it down to a single rack of equipment full of DSP's and Arcs (about 6 chassis'?) an SS7 solution is going to be considerably more expensive than PRI. There might be useability wins, but that's much harder to put a value on. I was told the business case worked up within 3Com was for a application with ~50,000 lines for SS7 (no, I didn't put too many "0"'s in there). So, its definitely not for your small or even regional ISP's. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi, Does anyone have prices for an X2 key for a total control server thanks

Hi All, I have a number of HyperDSP E1/T1 Nics that I need to get going on E1 PRI. They dont have the extra daughter board to allow 30 channels, but I am happy to get them going for the time being with 23 or 24 ports Is it possible to use 2 quad cards to make up the extra channels? If not where can I get the daughter boards from? All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. -----Original Message-----

Hi- Need these TODAY! Need (5) USR/ 3COM NETSERVER NAC CARDS PART NUMBER 69-0001393 REV. K OR 7 Also need (3) 69-0001003 REV.F OR REV. 3 ETHERNET NIC Will purchase immediately! Please call or private email price and availability Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

On Fri, 9 Jul 1999, Jeff Mcadams wrote: >But then, it comes down to cost. From what I've been told by 3Com >folks, if you're talking bringing it down to a single rack of equipment >full of DSP's and Arcs (about 6 chassis'?) an SS7 solution is going to >be considerably more expensive than PRI. There might be useability >wins, but that's much harder to put a value on. Not when you own the network. Let's add in the co-lo and equipment for dozens of POPs as well as any local line charges (if any.) From a management and equipment standpoint, it's much cheaper to put 6 or 8 fully loaded hiper chassi at the operation center (where there are spares and people with at least 1/8th of a clue as to what to do if something breaks.) Let's take Interpath as an example (I don't work there anymore and I never signed any NDA *grin*)... When I was "in charge" of the dialup stuff, there were 41 chassi in 30 POPs (28 physical locations.) That added up to around 3000 modems. That's between 5 and 8 full hiper chassi (I'd have to pull up some spreedsheets to get the exact numbers.) With their own DMS and trunking to every tandem, it's much easier (and almost free) to have the dialtone for all those POPs come out of the DMS locally. Using SS7, things can be managed much easier -- balanced loads, adding and removing hardware, maint., etc. Even if you simply backhaul PRI's from other telco's, there is a great deal of cost savings in condensing the termination hardware. (Plus, there's the added marketing plus of all those LEDs!) >I was told the business case worked up within 3Com was for a application >with ~50,000 lines for SS7 (no, I didn't put too many "0"'s in there). >So, its definitely not for your small or even regional ISP's. Personaly, I put zero faith in any of the numbers 3Com pushes out. Their RADIUS server numbers are laughable -- I've shown it can do 100 times their "best case." (It's hard for them to simulate the real world... they don't live in it.) --Ricky

I just got a customer for whom I need to buy and set up their ISDN modem/router. I'm not sure which one will be easiest for them to use, and provide the best connections to my HiPer...ARC 4.1.59-6, DSP 1.2.60 Suggestions? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Ascend Pipeline 50 is pretty easy with NAT and DHCP running. Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Friday, July 09, 1999 2:25 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Which ISDN modem > > > I just got a customer for whom I need to buy and set up their ISDN > modem/router. I'm not sure which one will be easiest for them to use, and > provide the best connections to my HiPer...ARC 4.1.59-6, DSP 1.2.60 > Suggestions? > > Thanks, > Kirk >

Add a thumb for the Netgear RT328 Easy to setup, works well & is cheap. At 04:11 PM 7/9/99 -0500, you wrote: >2 thumbs up for the Netopia's. Very easy to setup. Then they just keep >going. They did have some funky config limitiations with un-numbered >interfaces, but I think it's real smooth now. I've only been running 3COM >gear for 3 weeks, but have had zero problems with my existing Netopia >customers who now dial into the TC. > >Scot >NJ Internet Access > > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell >> Sent: Friday, July 09, 1999 3:25 PM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) Which ISDN modem >> >> >> I just got a customer for whom I need to buy and set up their ISDN >> modem/router. I'm not sure which one will be easiest for them to use, and >> provide the best connections to my HiPer...ARC 4.1.59-6, DSP 1.2.60 >> Suggestions? >> >> Thanks, >> Kirk >> >> >> -- >> Kirk Mitchell-General Manager mitch@keyconn.net >> Keystone Connect Unlock Your World >> Altoona, PA 814-941-5000 http://www.keyconn.net >> >> >> - >> 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. John Schmerold Katy Computer, LLC 20 Meramec Station Rd Valley Park, MO 63088 314-316-9000 v 314-316-9200 f email: john@katy.com

Thus spake Marshall Morgan >Ascend Pipeline 50 is pretty easy with NAT and DHCP running. Ack...Ascend and easy to use in the same sentence? (well...not really, but it was mentioned in response to easy to use) You've got to be joking, right? :) Try the Netopias...10 times easier to setup than that hideous ascend psuedo-horribly-organized-menu-screen. (Bet you can't tell what I think about Ascend :) >> I just got a customer for whom I need to buy and set up their ISDN >> modem/router. I'm not sure which one will be easiest for them to use, >> and provide the best connections to my HiPer...ARC 4.1.59-6, DSP >> 1.2.60 >> Suggestions? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

2 thumbs up for the Netopia's. Very easy to setup. Then they just keep going. They did have some funky config limitiations with un-numbered interfaces, but I think it's real smooth now. I've only been running 3COM gear for 3 weeks, but have had zero problems with my existing Netopia customers who now dial into the TC. Scot NJ Internet Access > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Friday, July 09, 1999 3:25 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Which ISDN modem > > > I just got a customer for whom I need to buy and set up their ISDN > modem/router. I'm not sure which one will be easiest for them to use, and > provide the best connections to my HiPer...ARC 4.1.59-6, DSP 1.2.60 > Suggestions? > > Thanks, > Kirk > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > 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. >

On Fri, 9 Jul 1999, Scot Desort wrote: >2 thumbs up for the Netopia's. Very easy to setup. Then they just keep >going. They did have some funky config limitiations with un-numbered >interfaces, but I think it's real smooth now. I've only been running 3COM >gear for 3 weeks, but have had zero problems with my existing Netopia >customers who now dial into the TC. I've used netopia's with USR hardware for several years. "It just works." There _is_ one small problem with the netopia... excessive LAN traffic eats too much CPU with the net result of the poor thing losing the D-chan. (We used to have a few customers with that problem. And I can recreate at pretty much at will with the 655 I've got at home.) I've got no problems with either Ascend or Netopia, but I'm a fair bit more intelligent than the average end-user *grin*. Both have good points and bad points. Personally, I like the funky ascend menus -- I like information overload :-) (The netopia is more cut-n-paste friendly.) --Ricky

Thus spake John Schmerold >Add a thumb for the Netgear RT328 >Easy to setup, works well & is cheap. I use a netgear 328 at home as well...nice little box...not a huge number of features, but once everything is set up, it does work well... The 348 is the same box really, just with 4 twisted pair jacks in the back instead of the aui that the 328 has. Same software though. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

My NT system has the US Robotics 56K X2 voice modem and an ethernet card. Although, I have Plug and Play enabled on NT, I choose to use manual COM port/IRQ settings. System BIOS has been set to COM 1 3F8 IRQ4 COM2 2E8 IRQ3 The jumpers on modem card are set to COM2 and IRQ 3. Control Panel settings for COM Ports, reflect the BIOS settings. I finding it very difficult to install this modem. I changed the BIOS settings to differrent combinations and changed the hardware to different slots hoping that PNP will adjust the other card settings. For a while, I tried to use PNP on the modem, and that did not work, so I am resorting to using manual (jumpers) settings for the modem. I would appreciate any help from people with experience in this area. Thank you in advance. Subba Rao subb3@ibm.net PS - The system BIOS has only the following combinations for the serial ports 3F8 IRQ4 2F8 IRQ3 3E8 IRQ4 2E8 IRQ3

Most modems are not big on sharing IRQs or COm ports. If you do not require com2 on your system ,then disable it on the motherboard and your modem should work OK.. If the com2 port still reports as being there, you will need to select com3 and a higher unused IRQ. This is a manually jumper configurable modem isn't it? If not, you will probably have to leave it on PNP, and then go into the bios and manually assign an IRQ to the slot that it is in. These are what we usually do, when using an internal modem, but normally in NT, we use external modems connected to DIGI cards, or the like, to facilitate bypassing the antiquated IRQ, I/O, Com problems that have plagued PCs since Microsoft came on the scene. :-) At 09:54 AM 7/10/99 -0400, you wrote: >My NT system has the US Robotics 56K X2 voice modem and an ethernet >card. > >Although, I have Plug and Play enabled on NT, I choose to use manual COM > >port/IRQ settings. > >System BIOS has been set to > COM 1 3F8 IRQ4 > COM2 2E8 IRQ3 > >The jumpers on modem card are set to COM2 and IRQ 3. > >Control Panel settings for COM Ports, reflect the BIOS settings. > >I finding it very difficult to install this modem. I changed the BIOS >settings to differrent combinations and changed the hardware to >different slots hoping that PNP will adjust the other card settings. >For a while, I tried to use PNP on the modem, and that did not >work, so I am resorting to using manual (jumpers) settings for the >modem. > >I would appreciate any help from people with experience in this area. > >Thank you in advance. > >Subba Rao >subb3@ibm.net > > >PS - The system BIOS has only the following combinations for the >serial ports > >3F8 IRQ4 >2F8 IRQ3 >3E8 IRQ4 >2E8 IRQ3 > > > > > >- > 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. William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Your mail has been delivered to the proper email box for "erichard@netdoor.com". I will be out of the office from 7/10/99 until 7/18/99. Please direct all questions and comments to "noc@netdoor.com". The appropriate personnel will receive your mail and respond as quickly as possible. Thank you for choosing NETDOOR. Edward Richards Network Operations NETDOOR - Mississippi's ISP 1.800.952.1570 Ext. 27 1.601.969.3629 Ext. 27

Does anyone know why this call keeps getting rejected? Outgoing PPP Data on interface: slot:1/mod:18 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 16 04 2c 5b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:1/mod:18 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 16 04 2c 5b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:18 LCP CFG_REQ 00 00 MRU 05 f4 MPP_MRRU 05 f4 MPP_ENDPTID 03 00 c0 7b 4f 65 a8 Outgoing PPP Data on interface: slot:1/mod:18 LCP CFG_REJ 00 00 Outgoing PPP Data on interface: slot:1/mod:18 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 16 04 2c 5b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:18 LCP CFG_REQ 00 00 MRU 05 f4 MPP_MRRU 05 f4 MPP_ENDPTID 03 00 c0 7b 4f 65 a8 Outgoing PPP Data on interface: slot:1/mod:18 LCP CFG_REJ 00 00 Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Kirk: If you are considering a Cisco product, you might want to consider a Cisco 1000, or a later model. We can now support the MicroSoft CBCP (Call Back Control Protocol) in ER code, and it should be part of the general Release in 4.2.x code for the Hiper ARC. Unfortunately Cisco only supports this in IOS 11.3 or later, and this can only be loaded on to the 1000 or better products. For an ISDN customer this could be very important. Many Telcos have found ways to extract more money from your ISDN End Users by charging fees if usage exceeds some arbitrary amount of time (usually 150 hours). If this customer requires 24x7 service this could get very expensive. The work around for this is to implement call back on the chassis since the Telco's don't (and some don't seem to be permittied) to charge for inbound ISDN calls (but DO check your local area). CBCP is the easiest way to implement this fix for your dial on demand ISDN customers. Just my 2 Cents..... Hope this helps. Todd ;-} PS: If anyone wants a good article on CBCP go to Cisco's web site and search on "CBCP" Their article describes in detail what CBCP is and how it works. K Mitchell <mitch@keyconn.net> on 07/12/99 08:39:34 AM Please respond to usr-tc@lists.xmission.com Sent by: K Mitchell <mitch@keyconn.net> cc: (Todd Keister/MW/US/3Com) I appreciate all the input on this, unfortunately, I may not be able to use this. I just got a "someone told me the Cisco 766 was a great unit" message from them. Anybody using them? Good, bad, ugly? :) Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - 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.

I appreciate all the input on this, unfortunately, I may not be able to use this. I just got a "someone told me the Cisco 766 was a great unit" message from them. Anybody using them? Good, bad, ugly? :) Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

I'd much rather have a Cisco 804 than a 766. Same basic idea, except the 804 runs IOS 12.0 and the 766 runs something completely different. It's not super-easy to set up if you don't know IOS though... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate." On Mon, 12 Jul 1999, K Mitchell wrote: > I appreciate all the input on this, unfortunately, I may not be able to use > this. I just got a "someone told me the Cisco 766 was a great unit" message > from them. Anybody using them? Good, bad, ugly? :)

On Sun, 11 Jul 1999, Brian wrote: >Does anyone know why this call keeps getting rejected? [snip] >Incoming PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ 00 00 > MRU 05 f4 > MPP_MRRU 05 f4 > MPP_ENDPTID 03 00 c0 7b 4f 65 a8 ... First, the client is sending the same request over and over (CFG_REQ 00 00) which is illegal. Second, the client is not sending a magic number -- I'll assume it's waiting for the servers number before sending it's number. My quess is the client modem is setup wrong in some way. It looks like the client cannot see anything the ARC is sending it -- thus the repeated configure requests and lack of answers to the ARC's requests. --Ricky

Thus spake Mike Andrews >I'd much rather have a Cisco 804 than a 766. Same basic idea, except the >804 runs IOS 12.0 and the 766 runs something completely different. It's >not super-easy to set up if you don't know IOS though... The something different, fwiw, is the old CombiNet code. Cisco bought CombiNet (and the 700 series as part of the deal), thus the introduction of the 800's to replace the 700's...same basic functionality, but true cisco technology. I must agree with Mike though...if you're going to go with Cisco...go with the 800's. Personally, for CPE dial equipment though, I'd avoid Cisco entirely. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Looks to me like... Incoming PPP Data on interface: slot:1/mod:18 LCP CFG_REQ 00 00 MRU 05 f4 MPP_MRRU 05 f4 MPP_ENDPTID 03 00 c0 7b 4f 65 a8 is rejected twice - either the chassis doesn't like the mru, mmru, or the endpoint id. Just a cursory look at it from this end... Kevin On Sun, 11 Jul 1999, Brian wrote: > Date: Sun, 11 Jul 1999 12:21:28 -0500 (CDT) > From: Brian <signal@shreve.net> > Reply-To: usr-tc@lists.xmission.com > To: USRobotics TC Mailing List <usr-tc@xmission.com> > Subject: (usr-tc) PPP debug > > > Does anyone know why this call keeps getting rejected? > > > > Outgoing PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 16 04 2c 5b > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Outgoing PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 16 04 2c 5b > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ 00 00 > MRU 05 f4 > MPP_MRRU 05 f4 > MPP_ENDPTID 03 00 c0 7b 4f 65 a8 > > Outgoing PPP Data on interface: slot:1/mod:18 > LCP CFG_REJ 00 00 > > Outgoing PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 16 04 2c 5b > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ 00 00 > MRU 05 f4 > MPP_MRRU 05 f4 > MPP_ENDPTID 03 00 c0 7b 4f 65 a8 > > Outgoing PPP Data on interface: slot:1/mod:18 > LCP CFG_REJ 00 00 > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

On Mon, 12 Jul 1999, Kevin Benton wrote: >Incoming PPP Data on interface: slot:1/mod:18 > LCP CFG_REQ 00 00 > MRU 05 f4 > MPP_MRRU 05 f4 > MPP_ENDPTID 03 00 c0 7b 4f 65 a8 > >is rejected twice - either the chassis doesn't like the mru, mmru, or the >endpoint id. Just a cursory look at it from this end... No, look at the CFG_REJ... it doesn't like the "00 00" but the client continues to spew it out. --Ricky

On Mon, 12 Jul 1999, Ricky Beam wrote: > On Sun, 11 Jul 1999, Brian wrote: > >Does anyone know why this call keeps getting rejected? > [snip] > >Incoming PPP Data on interface: slot:1/mod:18 > > LCP CFG_REQ 00 00 > > MRU 05 f4 > > MPP_MRRU 05 f4 > > MPP_ENDPTID 03 00 c0 7b 4f 65 a8 > ... > > First, the client is sending the same request over and over (CFG_REQ 00 00) > which is illegal. Second, the client is not sending a magic number -- I'll > assume it's waiting for the servers number before sending it's number. > > My quess is the client modem is setup wrong in some way. It looks like > the client cannot see anything the ARC is sending it -- thus the repeated > configure requests and lack of answers to the ARC's requests. The client is a pipeline P50..........running 6.0.10. I will look further......... > > --Ricky > > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

We have a chassis that only has users assigned static ip's/subnets. Yet whenever one of these users dials in, the ARC logs: Jul 12 11:38:26 usr4ts1 At 16:37:19, Facility "IP", Level "CRITICAL":: No IP Address Pools created is this really necessary, I mean its not like they requested a dynamic ip. That same chassis, is just a few HDM's and an ARC, and logs sometimes: Jul 12 11:37:35 usr4ts1 At 16:36:28, Facility "MPIP", Level "UNUSUAL":: File : ../../src/mpip_process.c Line : 564 MPIP Link registration failed, because no MPIP server configured Is this normal? I would think it should not need MPIP since its just one ARC. Would it help at all to just make the ARC an MPIP server and list itself as a client? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I have (55) USR/3COM Quad digital/analog modem cards in stock ready to ship only have (4) of the analog/RS-232 card NICS left part #000385-0 Price w/o NIC: $ 225.00 Price w/ NIC $ 300.00 Qty discount---please email in private or call if interested. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

At 05:49 PM 7/12/99 +0300, richard bosire <bosire@africaonline.co.ke> wrote: > >Hi ''s > >Is it possible to monitor a HiperArc [System Version: V4.1.11 ] using >mrtg What exactly are you trying to monitor...modems in use, cpu useage, etc? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

hello, has anybody HiperARC MIBS full description? -- _______________________________________________ best regards, vadim tulinov.

I will sell you one for $1050 if you need a 3COM VAR to help you out. $960 if you buy something else with it. Regards, Greg, Toll free 877-DYNAVAR At 09:24 AM 7/9/99 -0700, you wrote: >Hi, >Does anyone have prices for an X2 key for a total control server > >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. > > Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.

On Mon, 12 Jul 1999, Brian wrote: >We have a chassis that only has users assigned static ip's/subnets. Yet >whenever one of these users dials in, the ARC logs: > >Jul 12 11:38:26 usr4ts1 At 16:37:19, Facility "IP", Level "CRITICAL":: No IP Address Pools created > >is this really necessary, I mean its not like they requested a dynamic ip. Do you have "hint assigned" turned on? The ARC is preselecting an address (or trying to) prior to authentication so it can report it to the RADIUS server. I'd assume it's doing this even if it's not reporting it. >That same chassis, is just a few HDM's and an ARC, and logs sometimes: > >Jul 12 11:37:35 usr4ts1 At 16:36:28, Facility "MPIP", Level "UNUSUAL":: >File : ../../src/mpip_process.c Line : 564 MPIP Link registration failed, >because no MPIP server configured > > >Is this normal? I would think it should not need MPIP since its just one >ARC. Would it help at all to just make the ARC an MPIP server and list >itself as a client? Did you configure MPIP? Could someone's second channel be rolling into this ARC? --Ricky

I've got two x2 keys I can sell you for $900 each. You can also make an offer on purchasing them both simultaneously. Brian Brian Becker Poplar Bluff Internet, Inc. http://www.semo.net Home of JerusalemPerspective.com Bookstore http://www.JerusalemPerspective.com TotallyFabricated.com's Webgabber Chat Software http://www.TotallyFabricated.com and my personal page http://www.Tonionio.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark Ross Sent: Friday, July 09, 1999 11:25 AM Hi, Does anyone have prices for an X2 key for a total control server 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.

Just upgraded from 1.2.43 to 2.0.81. Now all I get is dead air. What's the quick way to reconfigure these for CT1? I have set robbed bit and the the switch type, reset the channels from template 1 and hard reset all. Does 2.0.81 not work with CT1? Any quick sugestions? Terry Kennedy Olypen, Inc.

Make sure you have the tone type set correctly (mf or dtmf) Save the parameters to nvram and reset the card. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Monday, July 12, 1999 3:51 PM Just upgraded from 1.2.43 to 2.0.81. Now all I get is dead air. What's the quick way to reconfigure these for CT1? I have set robbed bit and the the switch type, reset the channels from template 1 and hard reset all. Does 2.0.81 not work with CT1? Any quick sugestions? Terry Kennedy Olypen, Inc. - 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.

Did that. Just powered down the rack in desperation. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric Billeter Sent: Monday, July 12, 1999 4:07 PM Make sure you have the tone type set correctly (mf or dtmf) Save the parameters to nvram and reset the card. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Monday, July 12, 1999 3:51 PM Just upgraded from 1.2.43 to 2.0.81. Now all I get is dead air. What's the quick way to reconfigure these for CT1? I have set robbed bit and the the switch type, reset the channels from template 1 and hard reset all. Does 2.0.81 not work with CT1? Any quick sugestions? Terry Kennedy Olypen, Inc. - 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.

Hi ''s Is it possible to monitor a HiperArc [System Version: V4.1.11 ] using mrtg Any help will be appreciated .. TIA ciao bosire --

I am having a problem plauge me, where its becoming difficult for isdn users to get a dual channel connection. I am trying to track the problem down, by using my own personal account (I am experiencing these problems as well). When I goto set a tap on my account, I get this: HiPer>> list tap Id Type Perm Interface User Out Fmt Facility Levl Address 1 USER No signal SYSL ASC LOG_LOCAL0UNUS 2 USER No slot:1/mod:20 signal SYSL ASC LOG_LOCAL0UNUS 3 USER No slot:1/mod:22 signal SYSL ASC LOG_LOCAL0UNUS Why would I show up 3 times when I am only logged in twice? I have done "list connections" before, and seen similar things, where a username does not show up, its just blank. I am getting the feeling that the arc thinks that someone is already connected, and that may be one reason for the reject. Also is the above TAP setup right? I am not seeing anything on log.local0. Instead I see everything on the facility that is configured for the ARC instead........sigh......I reported this long ago: HiPer>> list sysLOGS SYSLOG SINKS SysLog Log Level Msg Count Facility Allow all Auth levels 208.206.76.27 UNUSUAL 89492 LOG_LOCAL4YES So the arc logs to local4, and the tap to local0. yet the tap in this case goes to local4!!!!!! I have tried this over and over again, on a variety of arc's running 4.1.59-6, totally reproducable. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

> From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark Ross > Sent: Friday, July 09, 1999 11:25 AM > To: isp-equipment@isp-equipment.com; isp-services@ispc.org; TCU > Subject: (usr-tc) WTB X2 key for total control > > > Hi, > Does anyone have prices for an X2 key for a total control server > The x2 keys are linked to the serial number of the NMC card. You would need the NMC card serial number and based on that 3com can get you the x2 key for that particular chassis. It is only necessary if you are using the quad. The DSP do not have any x2 keys. krish > 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. > > > - > 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. >

Is their any way to log all PPP call setup to syslog? something similar to a MONITOR PPP? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

First, anyone know how to watch PPP events, like LCP negotiation etc, on a P50? I am having all kinds of wierd stuff happen, like I had said in previous emails, wierd things like P50's sending CFG_REQ for 00 00, and now this: [signal@shadow signal]$ ping 208.206.76.1 PING 208.206.76.1 (208.206.76.1) from 208.214.45.5 : 56 data bytes 64 bytes from 208.206.76.1: icmp_seq=1 ttl=253 time=58.3 ms 64 bytes from 208.206.76.1: icmp_seq=4 ttl=253 time=1053.2 ms wrong data byte #11 should be 0x47 but was 0x46 37 8a a4 46 0 d 42 1a 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 64 bytes from 208.206.76.1: icmp_seq=5 ttl=253 time=94.2 ms 64 bytes from 208.206.76.1: icmp_seq=6 ttl=253 time=55.6 ms 64 bytes from 208.206.76.1: icmp_seq=10 ttl=253 time=59.5 ms 64 bytes from 208.206.76.1: icmp_seq=13 ttl=253 time=1055.1 ms wrong data byte #11 should be 0x50 but was 0x4f 37 8a a4 4f 0 d 42 19 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 64 bytes from 208.206.76.1: icmp_seq=14 ttl=253 time=100.1 ms To me, it looks like corruption. Could it be telco? I say this, because its taking me like 15 times to get a connection (isdn) and when I do, alot of times its like above, with serious voodoo packet loss. Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

At 04:50 PM 7/9/99 -0400, you wrote: >Try the Netopias...10 times easier to setup than that hideous ascend >psuedo-horribly-organized-menu-screen. I think I have the customer convinced that it doesn't have to be a Cisco, but I'm totally confused at which Netopia to even look at; http://www.insight.com/cgi-bin/bp/761976563/web/networking_result.html? CATA=NM&A=S&F=P&D=&T=&C=N++++&SC=NM+&M=&P=34 URL BROKEN INTO 2 PARTS This is for the office of a nursing home with 4-8 networked workstations that will be using the connection for database coordination between it and other homes of the chain, email, and light surfing. Their network is already running TCP/IP and has a firewall installed, so I'm guessing the only things I need on it are NAT and snmp management? Insight has Pipeline 75's for a decent price also, so I'm considering that, but not sure about ease of setup. Thanks for the assistance, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

On Mon, 12 Jul 1999, Brian wrote: >First, anyone know how to watch PPP events, like LCP negotiation etc, on a >P50? I think you can from the debug layer... >To me, it looks like corruption. Could it be telco? I say this, because >its taking me like 15 times to get a connection (isdn) and when I do, alot >of times its like above, with serious voodoo packet loss. Could be a bad P50. --Ricky

On Mon, 12 Jul 1999, Jeff Mcadams wrote: > Thus spake Mike Andrews > >I'd much rather have a Cisco 804 than a 766. Same basic idea, except the > >804 runs IOS 12.0 and the 766 runs something completely different. It's > >not super-easy to set up if you don't know IOS though... > > The something different, fwiw, is the old CombiNet code. Cisco bought > CombiNet (and the 700 series as part of the deal), thus the introduction > of the 800's to replace the 700's...same basic functionality, but true > cisco technology. Yup. That Combinet stuff doesn't impress me much. They're based on 386sx's I think... and as hard as IOS is to set up, the 766 was worse. (Mostly due to unfamiliarity and flimsy docs.) > I must agree with Mike though...if you're going to go with Cisco...go > with the 800's. Personally, for CPE dial equipment though, I'd avoid > Cisco entirely. Why, other than that IOS is a bit overkill for the job and a bit hard to set up? :) We haven't had that much trouble getting 1600's to connect to our ARCs. I like my two 804's at home, though there's some weird POTS bugs and it wasn't exactly easy to get them configured right... but considering it was replacing two Ass-end P25fx's... (Shame I have to throw it all out to get DSL soon. Bridging sucks.) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

I have a very buggy and very very very ugly program that does something like this... watches for incoming calls, turns the tap on just long enough to catch the connect and the option negotation, decodes and prints it, then turns the tap off when it sees an IP packet. I've been too embarassed about the code to release it so far, but check the usrtoys page tomorrow and maybe I'll have some of it up... it'll still need work though. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate." On Mon, 12 Jul 1999, Brian wrote: > Is their any way to log all PPP call setup to syslog? something similar to > a MONITOR PPP?

Brian, Is this a 64kbs or 128kbs connection ? I've seen this before when you have Radius set to limit them to one channel but the Pipeline is trying to bring up the second one regularly. Jeff Binkley ASA Network Computing U>First, anyone know how to watch PPP events, like LCP negotiation etc, U>on a P50? U>I am having all kinds of wierd stuff happen, like I had said in U>previous emails, wierd things like P50's sending CFG_REQ for 00 00, U>and now this: U>[signal@shadow signal]$ ping 208.206.76.1 U>PING 208.206.76.1 (208.206.76.1) from 208.214.45.5 : 56 data bytes U>64 bytes from 208.206.76.1: icmp_seq=1 ttl=253 time=58.3 ms U>64 bytes from 208.206.76.1: icmp_seq=4 ttl=253 time=1053.2 ms U>wrong data byte #11 should be 0x47 but was 0x46 U> 37 8a a4 46 0 d 42 1a 8 9 a b c d e f 10 11 12 13 14 15 16 17 U>18 19 1a 1b 1c 1d 1e 1f U> 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f U>64 bytes from 208.206.76.1: icmp_seq=5 ttl=253 time=94.2 ms U>64 bytes from 208.206.76.1: icmp_seq=6 ttl=253 time=55.6 ms U>64 bytes from 208.206.76.1: icmp_seq=10 ttl=253 time=59.5 ms U>64 bytes from 208.206.76.1: icmp_seq=13 ttl=253 time=1055.1 ms U>wrong data byte #11 should be 0x50 but was 0x4f U> 37 8a a4 4f 0 d 42 19 8 9 a b c d e f 10 11 12 13 14 15 16 17 U>18 19 1a 1b 1c 1d 1e 1f U> 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f U>64 bytes from 208.206.76.1: icmp_seq=14 ttl=253 time=100.1 ms U>To me, it looks like corruption. Could it be telco? I say this, U>because its taking me like 15 times to get a connection (isdn) and U>when I do, alot of times its like above, with serious voodoo packet U>loss. U>----------------------------------------------------- U>Brian Feeny (BF304) signal@shreve.net U>318-222-2638 x 109 http://www.shreve.net/~signal U>Network Administrator ShreveNet Inc. (ASN 11881) U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

Thus spake Mike Andrews >Why, other than that IOS is a bit overkill for the job and a bit hard to >set up? :) Not that its overkill...more that its just not very good at dial from what I can tell...it just seems like their dial setups are all cruft and kludge, just not a very clean setup, or at least wasn't...haven't looked in the past year or so, so maybe the later code revs. have cleaned it up some. >(Shame I have to throw it all out to get DSL soon. Bridging sucks.) Hey...bridging has its place, and indeed can be pretty cool at times. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 13 Jul 1999, Ricky Beam wrote: > On Mon, 12 Jul 1999, Brian wrote: > >First, anyone know how to watch PPP events, like LCP negotiation etc, on a > >P50? > > I think you can from the debug layer... > > >To me, it looks like corruption. Could it be telco? I say this, because > >its taking me like 15 times to get a connection (isdn) and when I do, alot > >of times its like above, with serious voodoo packet loss. > > Could be a bad P50. nod, its not just me though. What is the definitive, end all way, to debugging a session on the ARC that will give you *everything*. Is doing s TAP on a user/interface about the best thing? Does that show all PPP negotiation as well? I really need to find out whats going on with these boxes. > > --Ricky > > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I need to monitor among other things, -modems in usage [ who is logged on , ip 's assigned , etc] -memory usage -bandwidth utilization -cpu usage -temperature of the system ciao and TIA bosire K Mitchell wrote: > At 05:49 PM 7/12/99 +0300, richard bosire <bosire@africaonline.co.ke> wrote: > > > >Hi ''s > > > >Is it possible to monitor a HiperArc [System Version: V4.1.11 ] using > >mrtg > > What exactly are you trying to monitor...modems in use, cpu useage, etc? > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > - >

On Tue, 13 Jul 1999, Jeff Binkley wrote: > > > > Brian, > > Is this a 64kbs or 128kbs connection ? I've seen this before when you > have Radius set to limit them to one channel but the Pipeline is trying > to bring up the second one regularly. I think it was 1 out of two channels.........but in radius they are set for two channels, none of that has changed, but i'll double check. > > > Jeff Binkley > ASA Network Computing > > > > U>First, anyone know how to watch PPP events, like LCP negotiation etc, > U>on a P50? > > U>I am having all kinds of wierd stuff happen, like I had said in > U>previous emails, wierd things like P50's sending CFG_REQ for 00 00, > U>and now this: > > U>[signal@shadow signal]$ ping 208.206.76.1 > U>PING 208.206.76.1 (208.206.76.1) from 208.214.45.5 : 56 data bytes > U>64 bytes from 208.206.76.1: icmp_seq=1 ttl=253 time=58.3 ms > U>64 bytes from 208.206.76.1: icmp_seq=4 ttl=253 time=1053.2 ms > U>wrong data byte #11 should be 0x47 but was 0x46 > U> 37 8a a4 46 0 d 42 1a 8 9 a b c d e f 10 11 12 13 14 15 16 17 > U>18 19 1a 1b 1c 1d 1e 1f > U> 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > U>64 bytes from 208.206.76.1: icmp_seq=5 ttl=253 time=94.2 ms > U>64 bytes from 208.206.76.1: icmp_seq=6 ttl=253 time=55.6 ms > U>64 bytes from 208.206.76.1: icmp_seq=10 ttl=253 time=59.5 ms > U>64 bytes from 208.206.76.1: icmp_seq=13 ttl=253 time=1055.1 ms > U>wrong data byte #11 should be 0x50 but was 0x4f > U> 37 8a a4 4f 0 d 42 19 8 9 a b c d e f 10 11 12 13 14 15 16 17 > U>18 19 1a 1b 1c 1d 1e 1f > U> 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f > U>64 bytes from 208.206.76.1: icmp_seq=14 ttl=253 time=100.1 ms > > > U>To me, it looks like corruption. Could it be telco? I say this, > U>because its taking me like 15 times to get a connection (isdn) and > U>when I do, alot of times its like above, with serious voodoo packet > U>loss. > > > U>----------------------------------------------------- > U>Brian Feeny (BF304) signal@shreve.net > U>318-222-2638 x 109 http://www.shreve.net/~signal > U>Network Administrator ShreveNet Inc. (ASN 11881) > > > U>- > U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > U> with "unsubscribe usr-tc" in the body of the message. > U> For information on digests or retrieving files and old messages send > U> "help" to the same address. Do not use quotes in your message. > > CMPQwk 1.42 9999 > > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Kirk- Netopia P/N's: R3100-UP-12 = 12 User NAT, ISDN-U interface, 2 POTS jacks R3100-U-12 = 12 User NAT, ISDN-U interface, no POTS jacks Both models include an integrated 8 port ethernet hub (10baseT) You can take a look-see at http://www.netopia.com/equipment/routers/r3100/index.html ...Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Monday, July 12, 1999 11:57 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Which ISDN modem > > > At 04:50 PM 7/9/99 -0400, you wrote: > >Try the Netopias...10 times easier to setup than that hideous ascend > >psuedo-horribly-organized-menu-screen. > > I think I have the customer convinced that it doesn't have to > be a Cisco, > but I'm totally confused at which Netopia to even look at; > http://www.insight.com/cgi-bin/bp/761976563/web/networking_result.html? > CATA=NM&A=S&F=P&D=&T=&C=N++++&SC=NM+&M=&P=34 URL BROKEN INTO 2 PARTS > This is for the office of a nursing home with 4-8 networked workstations > that will be using the connection for database coordination between it and > other homes of the chain, email, and light surfing. Their network is > already running TCP/IP and has a firewall installed, so I'm guessing the > only things I need on it are NAT and snmp management? Insight has Pipeline > 75's for a decent price also, so I'm considering that, but not sure about > ease of setup. > > Thanks for the assistance, > Kirk > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > 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. >

On Tue, 13 Jul 1999, Tatai SV Krishnan wrote: > On Mon, 12 Jul 1999, Brian wrote: > > > Is their any way to log all PPP call setup to syslog? something similar to > > a MONITOR PPP? > > Do a tap - log it syslog - set the format to hex Ok, I will look at this. You did see my message about how tap is screwed up as far as facilities go right? I have the arc set to log_local4, and set log_local0 for the tap user, and nothing shows up in the file I have for log_local0, instead everything for that arc goes to log_local4........which was what the arc was set to syslog to. > > krish > > > > > Brian > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > 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. > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Mon, 12 Jul 1999, Brian wrote: > Is their any way to log all PPP call setup to syslog? something similar to > a MONITOR PPP? Do a tap - log it syslog - set the format to hex krish > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. >

On Tue, 13 Jul 1999, Brian wrote: > On Tue, 13 Jul 1999, Tatai SV Krishnan wrote: > > > On Mon, 12 Jul 1999, Brian wrote: > > > > > Is their any way to log all PPP call setup to syslog? something similar to > > > a MONITOR PPP? > > > > Do a tap - log it syslog - set the format to hex > > Ok, I will look at this. You did see my message about how tap is screwed > up as far as facilities go right? I have the arc set to log_local4, and > set log_local0 for the tap user, and nothing shows up in the file I have > for log_local0, instead everything for that arc goes to > log_local4........which was what the arc was set to syslog to. > That is totally configuration on your syslog demon - check your syslog.conf file. You should configure different levels to different locations. We can and have setup syslog levels to different locations (files) and tested the same with Hiper arc also. krish > > > > > krish > > > > > > > > Brian > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > 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. > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >

On Tue, 13 Jul 1999, Tatai SV Krishnan wrote: > On Tue, 13 Jul 1999, Brian wrote: > > > On Tue, 13 Jul 1999, Tatai SV Krishnan wrote: > > > > > On Mon, 12 Jul 1999, Brian wrote: > > > > > > > Is their any way to log all PPP call setup to syslog? something similar to > > > > a MONITOR PPP? > > > > > > Do a tap - log it syslog - set the format to hex > > > > Ok, I will look at this. You did see my message about how tap is screwed > > up as far as facilities go right? I have the arc set to log_local4, and > > set log_local0 for the tap user, and nothing shows up in the file I have > > for log_local0, instead everything for that arc goes to > > log_local4........which was what the arc was set to syslog to. > > > > That is totally configuration on your syslog demon - check your > syslog.conf file. You should configure different levels to different > locations. We can and have setup syslog levels to different locations > (files) and tested the same with Hiper arc also. tatai, nod.........I showed you the hiper portion, the syslog.conf looks like: local0.* /var/log/shrevenet/signal local1.* /var/log/shrevenet/shv1 local2.* /var/log/shrevenet/shv2 local3.* /var/log/shrevenet/shv3 local4.* /var/log/shrevenet/shv4 local5.* /var/log/shrevenet/mar local6.* /var/log/shrevenet/min local7.* /var/log/shrevenet/cisco Anyways, i'll keep messing with it, but we log *alot* of syslog stuff, remote machines, remote routers, every nas box going to a different file etc. Unless I am just totally missing something here, I would say I know syslog pretty well, and can't get tap to go to a specific facility spereate from that of the arc. > > krish > > > > > > > > > > krish > > > > > > > > > > > Brian > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > - > > > > 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. > > > > > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Tue, 13 Jul 1999, Brian wrote: > tatai, > > nod.........I showed you the hiper portion, the syslog.conf looks like: > > local0.* /var/log/shrevenet/signal > local1.* /var/log/shrevenet/shv1 > local2.* /var/log/shrevenet/shv2 > local3.* /var/log/shrevenet/shv3 > local4.* /var/log/shrevenet/shv4 > local5.* /var/log/shrevenet/mar > local6.* /var/log/shrevenet/min > local7.* /var/log/shrevenet/cisco > > > Anyways, i'll keep messing with it, but we log *alot* of syslog stuff, > remote machines, remote routers, every nas box going to a different file > etc. Unless I am just totally missing something here, I would say I know > syslog pretty well, and can't get tap to go to a specific facility > spereate from that of the arc. > Check the first few lines in your syslog .conf things like - *.err;kern.notice;auth.notice;local6.none; local7.none;local5.none /dev/sysmsg *.err;kern.debug;daemon.notice;mail.crit;user.none;local7.none;local5.none; /var/adm/messages auth. These files typically log all types of info - that should be restricted. also if you enable local7.* to one file you must disable the same from the rest of the other entries. > > > krish > > > > > > > > > > > > > > krish > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > Brian Feeny (BF304) signal@shreve.net > > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > > > > - > > > > > 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. > > > > > > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) >

Do you know if it is the same logic for cellular key? Thanks. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan Sent: 1999,July,12 9:18 PM > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark Ross > Sent: Friday, July 09, 1999 11:25 AM > To: isp-equipment@isp-equipment.com; isp-services@ispc.org; TCU > Subject: (usr-tc) WTB X2 key for total control > > > Hi, > Does anyone have prices for an X2 key for a total control server > The x2 keys are linked to the serial number of the NMC card. You would need the NMC card serial number and based on that 3com can get you the x2 key for that particular chassis. It is only necessary if you are using the quad. The DSP do not have any x2 keys. krish > thanks >

Thus spake Brian >Anyways, i'll keep messing with it, but we log *alot* of syslog stuff, >remote machines, remote routers, every nas box going to a different file >etc. Unless I am just totally missing something here, I would say I know >syslog pretty well, and can't get tap to go to a specific facility >spereate from that of the arc. Works great here...regular logging to local3, tap to local6. local3.debug ifdef(`LOGHOST', /var/log/netserver, @loghost) local6.debug ifdef(`LOGHOST', /var/log/tap, @loghost) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 08:39 AM 7/13/99 -0400, Scot Desort wrote: >Kirk- > >Netopia P/N's: > >R3100-UP-12 = 12 User NAT, ISDN-U interface, 2 POTS jacks >R3100-U-12 = 12 User NAT, ISDN-U interface, no POTS jacks > >Both models include an integrated 8 port ethernet hub (10baseT) Got it, thanks. They currently have their LAN set up with a 3Com SuperStack hub, so I'd just be plugging it into the uplink port(1). They have about 30 workstations on the LAN, but only have a need for 6-8 to have Internet connectivity, so the 12-user NAT would suffice, or do I need unlimited? Also, I'm kinda unclear on the POTS jacks(can you tell I'm new at this? :) A phone or fax machine plugged into them, when used, would cause the router to drop one of the B channels and use it to make an analog call? What about receiving calls? Thanks again, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

NMC OID for temp in Celsius : 1.3.6.1.4.1.429.1.2.2.5.0 We have an external perl program that can output info compatible with MRTG. If anyone wants to see it just let me know and I will get a webpage together for it. Our app converts the temp to F as well. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > Sent: Tuesday, July 13, 1999 12:52 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Monitoring HiperArc using MRTG > > > On Tuesday, July 13, 1999 2:48 PM, K Mitchell [SMTP:mitch@keyconn.net] > wrote: > > I believe MRTG can do all of these, with the exception that it won't be > > able to monitor temperature unless the hardware is able to send that > > information. > > I believe the NMC can send that. I don't know what the OID would be > though... > > Matthew... > > > > - > 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. > >

At 08:20 AM 7/13/99 +0300, richard bosire <bosire@africaonline.co.ke> wrote: >I need to monitor among other things, >-modems in usage [ who is logged on , ip 's assigned , etc] MRTG can monitor the number of modems used, but for usernames, IP's, etc, you'll need to use the ARC console or something similar. >-memory usage >-bandwidth utilization >-cpu usage >-temperature of the system I believe MRTG can do all of these, with the exception that it won't be able to monitor temperature unless the hardware is able to send that information. I can't help with the memory/CPU useage, but I am monitoring bandwidth and modems in use on my HiPer chassis. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Thus spake Stainforth, Matthew >On Tuesday, July 13, 1999 2:48 PM, K Mitchell [SMTP:mitch@keyconn.net] >wrote: >> I believe MRTG can do all of these, with the exception that it won't be >> able to monitor temperature unless the hardware is able to send that >> information. >I believe the NMC can send that. I don't know what the OID would be >though... enterprises.usr.nas.nmc.nmcStat.nmcStatTemperature .1.3.6.1.4.1.429.1.2.2.5 -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

A slightly more user-friendly spot to find the oid might be the tcm/tcm_dat/nm###### directory (where ###### reflects your NMC's s/w compatibility version- you can find the version from TCM under NMC card ID). You can usually do a text search in this directory for a string such as 'temperature' and find the oid (.1.3.6.1.4.1.....) that it maps to. Watch what file you find it in though- some cards have different objects depending on the card type. ds0 timeslot status on HiperDSPs and Dual Trunk cards each use a different oid for instance. Steve K Mitchell <mitch@keyconn.net> on 07/13/99 02:10:38 PM Please respond to usr-tc@lists.xmission.com Sent by: K Mitchell <mitch@keyconn.net> cc: (Steve Valiunas/MW/US/3Com) At 02:41 PM 7/13/99 -0400, Paul Farber wrote: >No, you can get usernames/IP/connect speeds, modems in use via SNMP. > >Just browse the mib directectoy in the Total control folder (if you use >WIN) and pick out what you like. I haven't the slightest clue how to read them, or translate them into a OID that MRTG can use :) >I just ran snmpwalk and printed out the entire USR tree. Picked out what >I wanted and use MRTG and Perl to build some simple monitoring graphs. snmpwalk? Who, what, how, where? >Try www.f-tech.net/visitor.html and you'll see a partial list of what the >script does. File not found Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - 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.

No, you can get usernames/IP/connect speeds, modems in use via SNMP. Just browse the mib directectoy in the Total control folder (if you use WIN) and pick out what you like. I just ran snmpwalk and printed out the entire USR tree. Picked out what I wanted and use MRTG and Perl to build some simple monitoring graphs. Try www.f-tech.net/visitor.html and you'll see a partial list of what the script does. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 13 Jul 1999, K Mitchell wrote: > At 08:20 AM 7/13/99 +0300, richard bosire <bosire@africaonline.co.ke> wrote: > >I need to monitor among other things, > >-modems in usage [ who is logged on , ip 's assigned , etc] > > MRTG can monitor the number of modems used, but for usernames, IP's, etc, > you'll need to use the ARC console or something similar. > > >-memory usage > >-bandwidth utilization > >-cpu usage > >-temperature of the system > > I believe MRTG can do all of these, with the exception that it won't be > able to monitor temperature unless the hardware is able to send that > information. I can't help with the memory/CPU useage, but I am monitoring > bandwidth and modems in use on my HiPer chassis. > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > 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. >

On Tue, 13 Jul 1999, K Mitchell wrote: > >-memory usage > >-bandwidth utilization > >-cpu usage > >-temperature of the system > > I believe MRTG can do all of these, with the exception that it won't be > able to monitor temperature unless the hardware is able to send that > information. I can't help with the memory/CPU useage, but I am monitoring > bandwidth and modems in use on my HiPer chassis. ARC memory: 1.3.6.1.4.1.429.4.3.1.3.0 ARC CPU: 1.3.6.1.4.1.429.4.3.1.13.0 I think everyone else got the others. :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

On Tue, 13 Jul 1999, Paul Farber wrote: > No, you can get usernames/IP/connect speeds, modems in use via SNMP. > > Just browse the mib directectoy in the Total control folder (if you use > WIN) and pick out what you like. > > I just ran snmpwalk and printed out the entire USR tree. Picked out what > I wanted and use MRTG and Perl to build some simple monitoring graphs. > > Try www.f-tech.net/visitor.html and you'll see a partial list of what the > script does. I get a 404 on that one... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

On Tuesday, July 13, 1999 2:48 PM, K Mitchell [SMTP:mitch@keyconn.net] wrote: > I believe MRTG can do all of these, with the exception that it won't be > able to monitor temperature unless the hardware is able to send that > information. I believe the NMC can send that. I don't know what the OID would be though... Matthew...

At 02:41 PM 7/13/99 -0400, Paul Farber wrote: >No, you can get usernames/IP/connect speeds, modems in use via SNMP. > >Just browse the mib directectoy in the Total control folder (if you use >WIN) and pick out what you like. I haven't the slightest clue how to read them, or translate them into a OID that MRTG can use :) >I just ran snmpwalk and printed out the entire USR tree. Picked out what >I wanted and use MRTG and Perl to build some simple monitoring graphs. snmpwalk? Who, what, how, where? >Try www.f-tech.net/visitor.html and you'll see a partial list of what the >script does. File not found Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

At 02:27 PM 7/13/99 -0400, Jeff Mcadams wrote: >enterprises.usr.nas.nmc.nmcStat.nmcStatTemperature >.1.3.6.1.4.1.429.1.2.2.5 What do you set maxbytes to? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

On Tue, 13 Jul 1999, K Mitchell wrote: > At 02:27 PM 7/13/99 -0400, Jeff Mcadams wrote: > >enterprises.usr.nas.nmc.nmcStat.nmcStatTemperature > >.1.3.6.1.4.1.429.1.2.2.5 > > What do you set maxbytes to? We use 100, though if it really hits 100 degrees centigrade, we're in a lot of trouble. :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

Thus spake Mike Andrews >On Tue, 13 Jul 1999, K Mitchell wrote: >> What do you set maxbytes to? >We use 100, though if it really hits 100 degrees centigrade, we're in a >lot of trouble. :) Can't you set mrtg to auto-scale graphs? I'm pretty sure we do (though I didn't do the mrtg setup here) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 03:23 PM 7/13/99 -0400, Mike Andrews wrote: >On Tue, 13 Jul 1999, K Mitchell wrote: > >> At 02:27 PM 7/13/99 -0400, Jeff Mcadams wrote: >> >enterprises.usr.nas.nmc.nmcStat.nmcStatTemperature >> >.1.3.6.1.4.1.429.1.2.2.5 >> >> What do you set maxbytes to? > >We use 100, though if it really hits 100 degrees centigrade, we're in a >lot of trouble. :) This isn't farenheit? Yours had a .0 at the end that Jeff's didn't, I figured his was F and the .0 made it C(Obviously I know nothing about this shit :) I'm doing something wrong here apparently, I added the entry to mrtg.cfg and it locked it up, removed it and MRTG went back to normal... Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5:community_string@204.171.31.3 MaxBytes[NMC-Temp]: 150 Title[NMC-Temp]: Keystone Connect NMC PageTop[NMC-Temp]: <H1>HiPer NMC Temperature </H1> <TABLE> <TR><TD>System:</TD><TD>Keystone Connect </TD></TR> <TR><TD>Maintainer:</TD><TD>Keystone Connect</TD></TR> <TR><TD>Interface:</TD><TD>HiPer NMC (2)</TD></TR> <TR><TD>IP:</TD><TD>nmc.keyconn.net (204.171.31.3)</TD></TR> <TR><TD>Max Temp:</TD> <TD>150 deg F</TD></TR> </TABLE> -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Thus spake K Mitchell >This isn't farenheit? Yours had a .0 at the end that Jeff's didn't, I >figured his was F and the .0 made it C(Obviously I know nothing about this >shit :) Nope, most snmp tools will automagically add the .0 if the .0 is the only node in the tree from that point, so my and Mike's strings were functionally (with most snmp tools) similar...technically, the OID does have the .0 at the end. >I'm doing something wrong here apparently, I added the entry to >mrtg.cfg and it locked it up, removed it and MRTG went back to >normal... >Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5:community_string@204.171.31.3 Try adding the .0 to the OID...not sure about how intelligent mrtg is about this. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 13 Jul 1999, K Mitchell wrote: > At 03:23 PM 7/13/99 -0400, Mike Andrews wrote: > >On Tue, 13 Jul 1999, K Mitchell wrote: > > > >> At 02:27 PM 7/13/99 -0400, Jeff Mcadams wrote: > >> >enterprises.usr.nas.nmc.nmcStat.nmcStatTemperature > >> >.1.3.6.1.4.1.429.1.2.2.5 > >> > >> What do you set maxbytes to? > > > >We use 100, though if it really hits 100 degrees centigrade, we're in a > >lot of trouble. :) > > This isn't farenheit? Yours had a .0 at the end that Jeff's didn't, I > figured his was F and the .0 made it C(Obviously I know nothing about this > shit :) Nope. It's all C, and I don't think it works at all without the .0 on the end. If you wanted F, you *might* be able to stick " * 9 / 5 + 32" on the end of the Target line and MRTG might do the math, but MRTG doesn't do floating point numbers very well. I ended up using a shell script to do it, and I can't remember why I did that now. Have a look at http://www.dcr.net/~mandrews/usrtoys/mrtg.shtml -- most of the stuff there is pulled straight out of a working config. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

Thus spake Mike Andrews >On Tue, 13 Jul 1999, K Mitchell wrote: >Nope. It's all C, and I don't think it works at all without the .0 on the >end. Might just be my snmptools that I'm using: quiz:/home/jeffm> snmpget -q -s -R host comm nmcStatTemperature nmcStatTemperature.0 33 Man that one is pretty hot. :) Top of a stack. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 13 Jul 1999, Jeff Mcadams wrote: > Thus spake Mike Andrews > >On Tue, 13 Jul 1999, K Mitchell wrote: > >Nope. It's all C, and I don't think it works at all without the .0 on the > >end. > > Might just be my snmptools that I'm using: > quiz:/home/jeffm> snmpget -q -s -R host comm nmcStatTemperature > nmcStatTemperature.0 33 Ow, and I thought 29 degrees was hot. UCD-SNMP, right? It's smart enough to do the .0. MRTG is stupid. (If this is UCD-SNMP 3.6.1 or better I wouldn't mind seeing a copy of your mibs; I've had trouble getting UCD-SNMP to understand them all without a lot of error messages. I've got 'em all except the ARC one and the Trap one OK...)

http://www.f-tech.net/online/visitor.html -----Original Message----- >On Tue, 13 Jul 1999, Paul Farber wrote: > >> No, you can get usernames/IP/connect speeds, modems in use via SNMP. >> >> Just browse the mib directectoy in the Total control folder (if you use >> WIN) and pick out what you like. >> >> I just ran snmpwalk and printed out the entire USR tree. Picked out what >> I wanted and use MRTG and Perl to build some simple monitoring graphs. >> >> Try www.f-tech.net/visitor.html and you'll see a partial list of what the >> script does. > >I get a 404 on that one... > > >Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY >mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org >"If you're not part of the solution.... you're part of the precipitate." > > > >- > 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. >

http://www.f-tech.net/online/visitor.html -----Original Message----- >On Tue, 13 Jul 1999, Paul Farber wrote: > >> No, you can get usernames/IP/connect speeds, modems in use via SNMP. >> >> Just browse the mib directectoy in the Total control folder (if you use >> WIN) and pick out what you like. >> >> I just ran snmpwalk and printed out the entire USR tree. Picked out what >> I wanted and use MRTG and Perl to build some simple monitoring graphs. >> >> Try www.f-tech.net/visitor.html and you'll see a partial list of what the >> script does. > >I get a 404 on that one... > > >Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY >mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org >"If you're not part of the solution.... you're part of the precipitate." > > > >- > 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. >

Thus spake Mike Andrews >On Tue, 13 Jul 1999, Jeff Mcadams wrote: >Ow, and I thought 29 degrees was hot. UCD-SNMP, right? It's smart enough >to do the .0. MRTG is stupid. yeah, ucd...thought it might be the snmpget that was being intelligent about it. >(If this is UCD-SNMP 3.6.1 or better I wouldn't mind seeing a copy of your >mibs; I've had trouble getting UCD-SNMP to understand them all without a >lot of error messages. I've got 'em all except the ARC one and the Trap >one OK...) It is 3.6.1, but I've mucked with my mibs so much I'm not sure they'd be any help in figuring out what you have to do with yours...I've mostly found the error messages to be fairly explanatory though. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Mark- i am sure you have it by now but, if you don't the p/n is 002083-0 list price is $1600. i have a couple for $300. each. can you advise if you still need them or not.?? thanks for the reply ion advance. i am going to post them up at $500. and see what happens soon. Mark Ross wrote: > Hi, > Does anyone have prices for an X2 key for a total control server > > 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.

Kirk- The 12 user count will only allow 12 of your internal IP addresses to send traffic out of the router to the internet. I don't _think_ it cares that there are another 20 workstations on the LAN, but you might want to check with Netopia on that. Correct- if someone tries to use the POTS line while both B channels are up, the 2nd channel drops for the duration of the analog call. If I'm not mistaken, an incoming analog call when both B channels are up would get a busy. ...Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Tuesday, July 13, 1999 11:24 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Which ISDN modem > > > > Got it, thanks. They currently have their LAN set up with a 3Com > SuperStack hub, so I'd just be plugging it into the uplink port(1). They > have about 30 workstations on the LAN, but only have a need for > 6-8 to have > Internet connectivity, so the 12-user NAT would suffice, or do I need > unlimited? > Also, I'm kinda unclear on the POTS jacks(can you tell I'm new at this? > :) A phone or fax machine plugged into them, when used, would cause the > router to drop one of the B channels and use it to make an analog call? > What about receiving calls? > > Thanks again, > Kirk

At 03:43 PM 7/13/99 -0400, you wrote: >>Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5:community_string@204.171.31.3 > >Try adding the .0 to the OID...not sure about how intelligent mrtg is >about this. Ok, so it's +0 or repeat? Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5.0:STRING@204.171.31.3 or Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5&1.3.6.1.4.1.429.1.2.2.5:STRING@204.171.31.3 as on http://www.dcr.net/~mandrews/usrtoys/mrtg.shtml Which is better and what's the difference? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

On Tue, 13 Jul 1999, K Mitchell wrote: > At 03:43 PM 7/13/99 -0400, you wrote: > >>Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5:community_string@204.171.31.3 > > > >Try adding the .0 to the OID...not sure about how intelligent mrtg is > >about this. > > Ok, so it's +0 or repeat? > Target[NMC-Temp]: 1.3.6.1.4.1.429.1.2.2.5.0:STRING@204.171.31.3 or > Target[NMC-Temp]: > 1.3.6.1.4.1.429.1.2.2.5&1.3.6.1.4.1.429.1.2.2.5:STRING@204.171.31.3 > as on http://www.dcr.net/~mandrews/usrtoys/mrtg.shtml > Which is better and what's the difference? It should be both +0 and repeated. My web page has a typo (now fixed). My live config calls a shell script to convert to degrees fahrenheit, and I goofed when I dumbed down the entry to remove the shell script. :) The first OID is the "transmit" graph, and the second OID is the "receive" graph -- bandwidth graphs have to show both directions of traffic. If you only have one OID to graph, you have to give it twice -- according to the MRTG documentation. The .0 is required because MRTG is too dumb to add it. It's really part of the OID, but some command line utils, like UCD-SNMP's "snmpget" automatically add it. MRTG doesn't. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

Are most of you configured for ppp like: HiPer>> show ppp PPP AUTHENTICATION DIAL_IN Users Authenticate: PAP PPP Authentication Preference: PAP PPP offloading: ENABLED CCP will be attempted for call type(s): DIGITAL UNCOMPRESSED_ANALOG PPP Address Field Compression: ENABLED PPP Protocol Field Compression: ENABLED PPP Multilink PPP: ENABLED PPP BACP and BAP: DISABLED PPP Bap Hunt Group Phone Number: PPP Receive ACCM: DISABLED ??? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I am running out of contiguous ips to assign to my total control ( netserver ) boxes. Can I assign for example two /27s to a box, giving it 60 addreses but not having the addresses be contiguous? Since I have an class c that is different from my router's class c shouldn't I be able to route subnets to the tc box so it has those ips? Problem is that I don't have enough addresses to give it a /26 with 62 ips. thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

On Tue, 13 Jul 1999, Scot Desort wrote: >The 12 user count will only allow 12 of your internal IP addresses to send >traffic out of the router to the internet. I don't _think_ it cares that >there are another 20 workstations on the LAN, but you might want to check >with Netopia on that. Those limits are (or were) subnet sized limits... which makes me wonder "why 12?" >Correct- if someone tries to use the POTS line while both B channels are up, >the 2nd channel drops for the duration of the analog call. If I'm not >mistaken, an incoming analog call when both B channels are up would get a >busy. Not necessarily... a profile can be set for 2-B (non-prempt) so no B channel would be dropped. If the phone company has enough of a clue to configure "ACO" (Additional Call Offering) then the netopia is supposed to be able to ring a phone without dropping a channel -- obviously a channel would drop it you answered it :-) Disclaimer: I've never actually tested either of these cases :-) I never plug anything other than a modem (to annoy damned telemarketers) into my netopia. And the only way I would ever be able to get BellSouth to do ACO is to go program their switch for them :-( --Ricky

Yes, that's precisely why I didn't even bring it up. I've tried getting BA to setup ACO a few times to no avail, though not into a Netopia -- into my personal 3COM Impact at home. I'm not even sure the Netopia supports ACO. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam Sent: Tuesday, July 13, 1999 8:15 PM >Correct- if someone tries to use the POTS line while both B channels are up, >the 2nd channel drops for the duration of the analog call. If I'm not >mistaken, an incoming analog call when both B channels are up would get a >busy. Not necessarily... a profile can be set for 2-B (non-prempt) so no B channel would be dropped. If the phone company has enough of a clue to configure "ACO" (Additional Call Offering) then the netopia is supposed to be able to ring a phone without dropping a channel -- obviously a channel would drop it you answered it :-) Disclaimer: I've never actually tested either of these cases :-) I never plug anything other than a modem (to annoy damned telemarketers) into my netopia. And the only way I would ever be able to get BellSouth to do ACO is to go program their switch for them :-( --Ricky

At 05:43 PM 7/13/99 -0400, you wrote: >The first OID is the "transmit" graph, and the second OID is the "receive" >graph -- bandwidth graphs have to show both directions of traffic. If you >only have one OID to graph, you have to give it twice -- according to the >MRTG documentation. Ok, got them running ok, couple of questions though(you knew it, didn't ya?). On the CPU Load and ARC Memory graphs, what are we really measuring, i.e. sys-mem vs real-mem 1min vs Out Thanks, Kirk Another one for the gurus...is it possible to monitor traffic by website using MRTG? The sites are on NT4/IIS4 and each have their own IP. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Brian writes... >DIAL_IN Users Authenticate: PAP >PPP Authentication Preference: PAP I'm running ANY & PAP. -a

Brian writes... >DIAL_IN Users Authenticate: PAP >PPP Authentication Preference: PAP I'm running ANY & PAP. -a

I have a customer who has a laptop with a PCMCIA ISDN TA (brand???). He previously had no problems with our old Microcom/Compaq dialup servers (which actually used MS PPTP to establish a RAS session into RRAS -- real nasty setup, but it worked). Now we are on TC. All of my other users (so far) can connect without any change to their equipment, with 2B channels. He cannot get the second B channel up. Here is the monitor PPP from the FIRST B channel: ======================== Outgoing PPP Data on interface: slot:1/mod:23 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 79 d9 85 2a PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:23 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 68 0e d2 PROTO_COMP AC_COMP CALLBACK 06 MPP_MRRU 05 dc MPP_ENDPTID 01 98 01 00 00 d1 0e 68 00 60 5a f2 c5 3b 25 00 00 Outgoing PPP Data on interface: slot:1/mod:23 LCP CFG_REJ CALLBACK 06 Incoming PPP Data on interface: slot:1/mod:23 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 68 0e d2 PROTO_COMP AC_COMP MPP_MRRU 05 dc MPP_ENDPTID 01 98 01 00 00 d1 0e 68 00 60 5a f2 c5 3b 25 00 00 Outgoing PPP Data on interface: slot:1/mod:23 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 68 0e d2 PROTO_COMP AC_COMP MPP_MRRU 05 dc MPP_ENDPTID 01 98 01 00 00 d1 0e 68 00 60 5a f2 c5 3b 25 00 00 Outgoing PPP Data on interface: slot:1/mod:23 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 79 d9 85 2a PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:23 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 79 d9 85 2a PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:23 PAP REQUEST USERNAME = xxx PASSWORD = xxx Outgoing PPP Data on interface: slot:1/mod:23 PAP ACK Outgoing PPP Data on interface: slot:1/mod:23 IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00 NEW_ADDRS cf ca 53 7d <snip> ====================== Now here is the SECOND channel coming up: ====================== Outgoing PPP Data on interface: slot:1/mod:20 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 52 19 20 95 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:20 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 61 da a6 PROTO_COMP AC_COMP CALLBACK 06 MPP_MRRU 05 dc MPP_ENDPTID 01 98 01 00 00 b5 c0 61 00 e8 db f1 c5 3b 25 00 00 Outgoing PPP Data on interface: slot:1/mod:20 LCP CFG_REJ CALLBACK 06 Incoming PPP Data on interface: slot:1/mod:20 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 61 da a6 PROTO_COMP AC_COMP MPP_MRRU 05 dc MPP_ENDPTID 01 98 01 00 00 b5 c0 61 00 e8 db f1 c5 3b 25 00 00 Outgoing PPP Data on interface: slot:1/mod:20 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 61 da a6 PROTO_COMP AC_COMP MPP_MRRU 05 dc MPP_ENDPTID 01 98 01 00 00 b5 c0 61 00 e8 db f1 c5 3b 25 00 00 Outgoing PPP Data on interface: slot:1/mod:20 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 52 19 20 95 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:20 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 52 19 20 95 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:1/mod:20 PAP REQUEST USERNAME = xxx PASSWORD = xxx Outgoing PPP Data on interface: slot:1/mod:20 PAP ACK Tracing stopped, Return/Enter to re-start, ESCA PE to quit. ============================ As you can see, the TC sends an ACK to the authentication, but doesn't seem to hear anything back from the client. Ironically, at the SAME moment the PAP ACK is sent to the client on the 2ND B channel, the follow packet comes across the 1ST B channel: Outgoing PPP Data on interface: slot:1/mod:23 CCP RESET_REQ I've tried various changes to his radius profile, such as disabling STAC compression, disabling header compression, nothing seems to work. The second channel just drops and he stays connect at 64K. Sorry about all of the log above, but I thought something in there may mean something to someone. Thanks for any ideas, Scot

Disable ccp on the hiper arc and check if that helps - Normally ccp has nothing to do with multilink ppp - but if you say that getting a ccp-reset is the only thing that you see - you can try disabling the ccp. I would guess that your client on receiving ccp is corrupting the data. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 13 Jul 1999, Scot Desort wrote: > I have a customer who has a laptop with a PCMCIA ISDN TA (brand???). He > previously had no problems with our old Microcom/Compaq dialup servers > (which actually used MS PPTP to establish a RAS session into RRAS -- real > nasty setup, but it worked). > > Now we are on TC. All of my other users (so far) can connect without any > change to their equipment, with 2B channels. He cannot get the second B > channel up. > > Here is the monitor PPP from the FIRST B channel: > > ======================== > > Outgoing PPP Data on interface: slot:1/mod:23 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 79 d9 85 2a > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:23 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 68 0e d2 > PROTO_COMP > AC_COMP > CALLBACK 06 > MPP_MRRU 05 dc > MPP_ENDPTID 01 98 01 00 00 d1 0e 68 > 00 60 5a f2 c5 3b 25 00 > 00 > > Outgoing PPP Data on interface: slot:1/mod:23 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:1/mod:23 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 68 0e d2 > PROTO_COMP > AC_COMP > MPP_MRRU 05 dc > MPP_ENDPTID 01 98 01 00 00 d1 0e 68 > 00 60 5a f2 c5 3b 25 00 > 00 > > Outgoing PPP Data on interface: slot:1/mod:23 > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 68 0e d2 > PROTO_COMP > AC_COMP > MPP_MRRU 05 dc > MPP_ENDPTID 01 98 01 00 00 d1 0e 68 > 00 60 5a f2 c5 3b 25 00 > 00 > > Outgoing PPP Data on interface: slot:1/mod:23 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 79 d9 85 2a > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:23 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 79 d9 85 2a > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:23 > PAP REQUEST USERNAME = xxx > PASSWORD = xxx > Outgoing PPP Data on interface: slot:1/mod:23 > PAP ACK > Outgoing PPP Data on interface: slot:1/mod:23 > IPCP CFG_REQ COMPR_TYPE 00 2d 0f 00 > NEW_ADDRS cf ca 53 7d > > <snip> > ====================== > > Now here is the SECOND channel coming up: > > ====================== > Outgoing PPP Data on interface: slot:1/mod:20 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 52 19 20 95 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:20 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 61 da a6 > PROTO_COMP > AC_COMP > CALLBACK 06 > MPP_MRRU 05 dc > MPP_ENDPTID 01 98 01 00 00 b5 c0 61 > 00 e8 db f1 c5 3b 25 00 > 00 > > Outgoing PPP Data on interface: slot:1/mod:20 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:1/mod:20 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 61 da a6 > PROTO_COMP > AC_COMP > MPP_MRRU 05 dc > MPP_ENDPTID 01 98 01 00 00 b5 c0 61 > 00 e8 db f1 c5 3b 25 00 > 00 > > Outgoing PPP Data on interface: slot:1/mod:20 > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 61 da a6 > PROTO_COMP > AC_COMP > MPP_MRRU 05 dc > MPP_ENDPTID 01 98 01 00 00 b5 c0 61 > 00 e8 db f1 c5 3b 25 00 > 00 > > Outgoing PPP Data on interface: slot:1/mod:20 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 52 19 20 95 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:20 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 52 19 20 95 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:1/mod:20 > PAP REQUEST USERNAME = xxx > PASSWORD = xxx > Outgoing PPP Data on interface: slot:1/mod:20 > PAP ACK Tracing stopped, Return/Enter to re-start, > ESCA > PE to quit. > > ============================ > > As you can see, the TC sends an ACK to the authentication, but doesn't seem > to hear anything back from the client. Ironically, at the SAME moment the > PAP ACK is sent to the client on the 2ND B channel, the follow packet comes > across the 1ST B channel: > > Outgoing PPP Data on interface: slot:1/mod:23 > CCP RESET_REQ > > I've tried various changes to his radius profile, such as disabling STAC > compression, disabling header compression, nothing seems to work. The second > channel just drops and he stays connect at 64K. > > Sorry about all of the log above, but I thought something in there may mean > something to someone. > > Thanks for any ideas, > > > Scot > > > - > 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. >

On Tue, 13 Jul 1999, Jeff Mcadams wrote: > Thus spake eric@dol.net > >I am running out of contiguous ips to assign to my total control ( > >netserver ) boxes. Can I assign for example two /27s to a box, giving > >it 60 addreses but not having the addresses be contiguous? > > Not with the NETServer card. The HiPer Arc can do this by just setting > another 'add ip pool ...' command to it, but the NETServer only dealt > with a single ip pool. Actually you can setup IP pools in the netserver - but once that is setup the ip pool will be private pool - you must set the radius to assign the pool name in that case. There fore if your radius supports VSA you can do it. krish > > >Since I have an class c that is different from my router's class c > >shouldn't I be able to route subnets to the tc box so it has those ips? > >Problem is that I don't have enough addresses to give it a /26 with 62 > >ips. > > The routing wouldn't be a problem...you could either staticly route them > or do RIP and let the NETServer advertise the routes it has, but you > can't do the discontiguous ip pools on the NETServer so that's kind of a > moot point. > -- > 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. >

Thus spake Ricky Beam >Disclaimer: I've never actually tested either of these cases :-) I never plug >anything other than a modem (to annoy damned telemarketers) into my netopia. >And the only way I would ever be able to get BellSouth to do ACO is to go >program their switch for them :-( Actually...I did manage to get Hellsouth to provision an additional call appearance for me once when I had a bitsurfer pro (blech) when I lived with my parents...worked great. I realized that I don't get any inbound calls on my isdn line, so I didn't bother with it in the last two places that I've lived...just let the line drop when I dial out...if people get a busy dialing in to it...doesn't bother me 'cause if they're calling that line, I don't want to talk to them. :) Of course, since I use BOD, and I don't do much that's bandwidth intensive, I usually only have one channel up so it rings through anyway. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake eric@dol.net >I am running out of contiguous ips to assign to my total control ( >netserver ) boxes. Can I assign for example two /27s to a box, giving >it 60 addreses but not having the addresses be contiguous? Not with the NETServer card. The HiPer Arc can do this by just setting another 'add ip pool ...' command to it, but the NETServer only dealt with a single ip pool. >Since I have an class c that is different from my router's class c >shouldn't I be able to route subnets to the tc box so it has those ips? >Problem is that I don't have enough addresses to give it a /26 with 62 >ips. The routing wouldn't be a problem...you could either staticly route them or do RIP and let the NETServer advertise the routes it has, but you can't do the discontiguous ip pools on the NETServer so that's kind of a moot point. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Scot Desort >Here is the monitor PPP from the FIRST B channel: >Incoming PPP Data on interface: slot:1/mod:23 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MPP_ENDPTID 01 98 01 00 00 d1 0e 68 > 00 60 5a f2 c5 3b 25 00 > 00 >Now here is the SECOND channel coming up: >Incoming PPP Data on interface: slot:1/mod:20 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MPP_ENDPTID 01 98 01 00 00 b5 c0 61 > 00 e8 db f1 c5 3b 25 00 > 00 These two monitor traces are from the same dialin attempt with the two different channels? If so, then the problem is the MP endpoint discriminators are different coming from the other system. The Arc will see this and think that these two calls are not in the same MP bundle...but if that's the case, it should have sent an IPCP CFG_REQ out and you didn't see that. >As you can see, the TC sends an ACK to the authentication, but doesn't seem >to hear anything back from the client. Well...in a working MP setup, after the authentication on the subsequent links (ie, any links other than the initial call in) you won't see any negotiation of options. After the authentication, the end system will use the userid and endpoint id to determine if the link should be bundled into an already existing bundle...if it determines that it is to be bundled in, it just starts firing data down the channel. If it determines that it doesn't belong to an already existing bundle, then it will proceed with normal PPP startup (ie, CCP, IPCP, etc.) >Ironically, at the SAME moment the >PAP ACK is sent to the client on the 2ND B channel, the follow packet comes >across the 1ST B channel: >Outgoing PPP Data on interface: slot:1/mod:23 > CCP RESET_REQ Hrmm...I wonder if possibly one side thinks the two links are bundled together and the other side doesn't...if they're running compression on the bundle head rather than the individual links, it could really screw up CCP, thus causing one side to try to start from scratch with a RESET_REQ. >I've tried various changes to his radius profile, such as disabling STAC >compression, disabling header compression, nothing seems to work. The second >channel just drops and he stays connect at 64K. Double-check the endpoint ids that are being sent...for two channels in the same bundle, they must be the same. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 13 Jul 1999 eric@dol.net wrote: > I am running out of contiguous ips to assign to my > total control ( netserver ) boxes. Can I assign for > example two /27s to a box, giving it 60 addreses but not > having the addresses be contiguous? Since I have an yes > class c that is different from my router's class c > shouldn't I be able to route subnets to the tc box so it > has those ips? Problem is that I don't have enough addresses yes, or just have your tc "announce" it and your router "listen" for it via RIPv2. > to give it a /26 with 62 ips. > thanks > eric > Delaware Online!.........The SMART Choice! > With 56K V.90 & X2 & Flex Modems > Phone : 302-762-0375 > Fax: 302-762-3462 > Failure is NOT an option... > > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Krish- <Excuse newbie question> Is that set with: set ppp ccp_modemtype_accept ?? If so, you are saying to disallow compression on DIGITAL calls? ...Scot -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan Sent: Tuesday, July 13, 1999 11:25 PM Cc: usr list Disable ccp on the hiper arc and check if that helps - Normally ccp has nothing to do with multilink ppp - but if you say that getting a ccp-reset is the only thing that you see - you can try disabling the ccp. I would guess that your client on receiving ccp is corrupting the data. krish

Anyone ever get anything other than 0? s5a> _sh ver V4.1.59 - 6 us5a> show cpu util CPU Utilization: Instantaneous : 0% Last Minute : 0% Last Hour : 0% Last Day : 0% us5a> -- Aaron Nabil

SO if that were the case then how is it that 3com claims that the HiperARC cannot handle more than seven DSP cards due to CPU load ? Just curious..... or are they full of it .... Ricky Beam wrote: > > On Wed, 14 Jul 1999, Aaron Nabil wrote: > >Anyone ever get anything other than 0? > > *laugh* Yes. Turn on OSPF... > > Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way > overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on > there at once and might go over 20%. > > --Ricky > > - > 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. -- Thank you, -- Frank Basso Senior Network Engineer Got.Net? - The Internet Connection, Inc. Santa Cruz, California Voice: 831-460-2000 x117 FAX: 831-460-2004 "Never mess with the one who has control of the Cisco, as "He Is God, and not just Root... :)" When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it.

What MRTG variables are you using for Modem usage ? I never could get that to work.... Actually track how many modems in use... Bandwidth is easy. K Mitchell wrote: > > At 09:46 AM 7/14/99 -0500, jeff.binkley@asacomp.com (Jeff Binkley) wrote: > > > > > >Kirk, > > > >What MRTG variable are you using to track bandwidth ? Can you post a > >copy of the MRTG entry ? We are currently doing the modem monitoring. > > Target[ARC-Traffic]: 3:COMMUNITY_STRING@204.171.31.2 > MaxBytes[ARC-Traffic]: 1250000 > Title[ARC-Traffic]: ARC Bandwidth > Options[ARC-Traffic]: bits > Xsize[ARC-Traffic]: 600 > Ysize[ARC-Traffic]: 200 > PageTop[ARC-Traffic]: <H1>Traffic Analysis for Keystone Connect ARC > </H1> > <TABLE> > <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR> > <TR><TD>Maintainer:</TD><TD>Kirk Mitchell</TD></TR> > <TR><TD>Interface:</TD><TD>3Com HiPer ARC </TD></TR> > <TR><TD>IP:</TD><TD>tc.arc1.keyconn.net (204.171.31.2)</TD></TR> > <TR><TD>Max Speed:</TD> > <TD>10.0 mbits/s (ethernetCsmacd)</TD></TR> > </TABLE> > > gives me http://www.keyconn.net/MRTG/arc-traffic.html > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > - > 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. -- Thank you, -- Frank Basso Senior Network Engineer Got.Net? - The Internet Connection, Inc. Santa Cruz, California Voice: 831-460-2000 x117 FAX: 831-460-2004 "Never mess with the one who has control of the Cisco, as "He Is God, and not just Root... :)" When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it.

At 01:23 AM 7/14/99 -0700, Aaron Nabil <nabil@spiritone.com> wrote: > >Anyone ever get anything other than 0? > >s5a> _sh ver >V4.1.59 - 6 >us5a> show cpu util > >CPU Utilization: >Instantaneous : 0% >Last Minute : 0% >Last Hour : 0% >Last Day : 0% Not yet, but mine's only been running for about 18 hours. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Kirk, What MRTG variable are you using to track bandwidth ? Can you post a copy of the MRTG entry ? We are currently doing the modem monitoring. Jeff Binkley ASA Network Computing U>At 08:20 AM 7/13/99 +0300, richard bosire <bosire@africaonline.co.ke> U>wrote: >I need to monitor among other things, U>>-modems in usage [ who is logged on , ip 's assigned , etc] U>MRTG can monitor the number of modems used, but for usernames, IP's, U>etc, you'll need to use the ARC console or something similar. U>>-memory usage U>>-bandwidth utilization U>>-cpu usage U>>-temperature of the system U>I believe MRTG can do all of these, with the exception that it won't U>be able to monitor temperature unless the hardware is able to send U>that information. I can't help with the memory/CPU useage, but I am U>monitoring bandwidth and modems in use on my HiPer chassis. U>-- U>Kirk Mitchell-General Manager mitch@keyconn.net U>Keystone Connect Unlock Your World U>Altoona, PA 814-941-5000 http://www.keyconn.net U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

After upgrading I noticed that dat compression was set to none. The default says it should be set to autoenable. Is there a reason that this code set it it none? Should I set it back to autoenable? These are CT1's taking only analog calls. Terry Kennedy Olypen, Inc.

We have channelized T1 lines feeding a TC hub running 4.1.59-6 and 1.2.43 code. Users with standard POTS lines with V90 capable modems have no problem achieving v90 connections. I have a customer with an ISDN BRI circuit with a 3Com I-Modem that can only receive a v34plus connection with us. He can call the 3Com v90 test number and get a v90 connection. He can also call another provider and receive a v90 connection. Is there a specific setting within the DSP that I am missing? Is the channelized T1 messed up? Is there an I-modem setting that is limiting the protocol? ********************************************** Mark A. Cooper, Owner Fayette Area Internet Services Technical Support Associates 135 W. Travis La Grange, TX 78945 (409)968-3999 Voice (409)968-3225 FAX ********************************************

On Wed, 14 Jul 1999, Aaron Nabil wrote: >Anyone ever get anything other than 0? *laugh* Yes. Turn on OSPF... Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on there at once and might go over 20%. --Ricky

On Wed, 14 Jul 1999, Vadim Tulinov wrote: > Hello, > > > I am sorry, but I have to write again. We very need full HiperARC MIBS > description. I can't get it from 3com. > Has anybody this "secret documentaion" ? > With every release of hiper arc code you will also have a mib file usr_hiper.mib that contains all the mib values for hiper arc - if you do not have for a particular release let me know and I will send it to you. krish > Best regards, > Vadim Tulinov. > > > - > 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. >

On Wed, 14 Jul 1999, Frank Basso wrote: > SO if that were the case then how is it that 3com claims that the > HiperARC cannot handle more than seven DSP cards due to CPU load ? Just > curious..... or are they full of it .... No - thats not what we claim - If you are using IPX then we support only 7 DSPs in 4.1.x release - That has nothing to do with CPU It has to do with IPX/DSP/HIper arc stability. krish > > Ricky Beam wrote: > > > > On Wed, 14 Jul 1999, Aaron Nabil wrote: > > >Anyone ever get anything other than 0? > > > > *laugh* Yes. Turn on OSPF... > > > > Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way > > overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on > > there at once and might go over 20%. > > > > --Ricky > > > > - > > 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. > > -- > > Thank you, > > -- > Frank Basso > Senior Network Engineer > Got.Net? - The Internet Connection, Inc. > Santa Cruz, California > Voice: 831-460-2000 x117 > FAX: 831-460-2004 > > "Never mess with the one who has control of the Cisco, as "He Is God, > and not just Root... :)" > > When they took the fourth amendment, I was quiet because I didn't deal > drugs. > When they took the sixth amendment, I was quiet because I was innocent. > When they took the second amendment, I was quiet because I didn't own a > gun. > Now they've taken the first amendment, and I can say nothing about it. > > - > 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. >

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Vadim Tulinov |Sent: Wednesday, July 14, 1999 4:22 AM |To: usr-tc@xmission.com |Subject: (usr-tc) Hiper ARC MIBS | | |Hello, | | |I am sorry, but I have to write again. We very need full HiperARC MIBS |description. I can't get it from 3com. |Has anybody this "secret documentaion" ? | |Best regards, |Vadim Tulinov. | There is no doccument.. The descriptions are in the mib. There is no other detailed information available. What are you looking for?? -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scot Desort |Sent: Tuesday, July 13, 1999 10:39 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Problems with ISDN 2B | | |Krish- | |<Excuse newbie question> | |Is that set with: | |set ppp ccp_modemtype_accept ?? | |If so, you are saying to disallow compression on DIGITAL calls? | That was only an attempt to see if Compression was the culprit.. But your trace does point to the TA sending two different EDO's.. If that is the case the user will never get a bundle established.. -M

At 09:46 AM 7/14/99 -0500, jeff.binkley@asacomp.com (Jeff Binkley) wrote: > > >Kirk, > >What MRTG variable are you using to track bandwidth ? Can you post a >copy of the MRTG entry ? We are currently doing the modem monitoring. Target[ARC-Traffic]: 3:COMMUNITY_STRING@204.171.31.2 MaxBytes[ARC-Traffic]: 1250000 Title[ARC-Traffic]: ARC Bandwidth Options[ARC-Traffic]: bits Xsize[ARC-Traffic]: 600 Ysize[ARC-Traffic]: 200 PageTop[ARC-Traffic]: <H1>Traffic Analysis for Keystone Connect ARC </H1> <TABLE> <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR> <TR><TD>Maintainer:</TD><TD>Kirk Mitchell</TD></TR> <TR><TD>Interface:</TD><TD>3Com HiPer ARC </TD></TR> <TR><TD>IP:</TD><TD>tc.arc1.keyconn.net (204.171.31.2)</TD></TR> <TR><TD>Max Speed:</TD> <TD>10.0 mbits/s (ethernetCsmacd)</TD></TR> </TABLE> gives me http://www.keyconn.net/MRTG/arc-traffic.html -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Hi Mark, The BBS and V.90 test number are answered by Quad Modems. Quad modems support Symmetric Mode x2 for 56 or 64k connections up and downstream, x2 Server mode for 53k downstream, V,90 Server mode for 53k downstream. (there is no standard yet for V.90 symmetrical connections). The HiPer DSP supports x2 Server mode for 53k downstream and V.90 Server mode for 53k downstream. The HiPer DSP does not support x2 Symmetric Mode. The I-Modem supports x2 Server mode, V.90 Server mode, and x2 Symmetric Mode. The Courier analog modem supports x2 client mode and V.90 client mode. So, with that out of the way... In order to establish a V.90 connection to a HiPer DSP the client modem you are dialing with must have support for V.90 client mode. The I-Modem does not support V.90 client mode. When an I-Modem dials a HiPer DSP the highest compatible protocol between the two is V.34+. When a I-Modem dials a Quad Modem the highest compatible protocol is x2 Symmetric Mode for 56 or 64k up and downstream. My guess is the user is seeing the CONNECT 56000/ARQ/X2/LAPM/V42BIS for a Symmetric Mode connection and just generically calling this a 'v90' connection because it is 56k. Hope this clears things up for you. If you have any questions let me know... Regards, David "Mark A. Cooper" <mcooper@fais.net> on 07/14/99 10:27:49 AM Please respond to usr-tc@lists.xmission.com Sent by: "Mark A. Cooper" <mcooper@fais.net> cc: (David Bachta/MW/US/3Com) We have channelized T1 lines feeding a TC hub running 4.1.59-6 and 1.2.43 code. Users with standard POTS lines with V90 capable modems have no problem achieving v90 connections. I have a customer with an ISDN BRI circuit with a 3Com I-Modem that can only receive a v34plus connection with us. He can call the 3Com v90 test number and get a v90 connection. He can also call another provider and receive a v90 connection. Is there a specific setting within the DSP that I am missing? Is the channelized T1 messed up? Is there an I-modem setting that is limiting the protocol? ********************************************** Mark A. Cooper, Owner Fayette Area Internet Services Technical Support Associates 135 W. Travis La Grange, TX 78945 (409)968-3999 Voice (409)968-3225 FAX ******************************************** - 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.

Ricky Beam said once upon a time: >Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way >overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on >there at once and might go over 20%. I have 253 calls on one and it it is still 0%.

On Wed, 14 Jul 1999, Frank Basso wrote: >SO if that were the case then how is it that 3com claims that the >HiperARC cannot handle more than seven DSP cards due to CPU load ? Just >curious..... or are they full of it .... There were problems (as I'm told) in older versions that made it unstable with too many ports. I'm of the opinion "they are full of it." It's not a CPU horsepower issue to handle the PPP traffic for 336 modems. I've watched a 386-16 with 4M of RAM running from a floppy handle 96 115.2k serial ports without a problem, so a 200MHz PPC should have no problem at all if it's been programmed with any sanity. I'd assume they hardcoded the interface table size, etc. (which they seem to love to do -- the idea of anything being dynamicly sized must be horrifying) which is why things don't work too well when there are too many cards per ARC. HOWEVER, as you add functionality (OSPF, PPTP, L2TP, IPSec, ...) the available pool of CPU is going down (rapidly.) Partly because these things are complex, but also, partly because the code written to handle them is *ahem* less than optimal (they ain't Cisco after all :-)) --Ricky PS: Let's not forget, we don't know how that CPU Util number is being gened. So it could be a partial fabrication. (much like the solaris "load avg.")

At 08:19 AM 7/14/99 -0700, Frank Basso <frank@got.net> wrote: >What MRTG variables are you using for Modem usage ? I never could get >that to work.... Actually track how many modems in use... Bandwidth is >easy. I'm using; Target[tch1]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:COMMUNITY_STRING@ARC IP MaxBytes[tch1]: 46 Unscaled[tch1]:ymwd Title[tch1]: Total Control Hub #1 PageTop[tch1]: <H1>Keystone Connect Modem Utilization </H1> <TABLE> <TR><TD>System:</TD><TD>3Com Enterprise Network Hub </TD></TR> <TR><TD>Maintainer:</TD><TD>Keystone Connect</TD></TR> <TR><TD>Interface:</TD><TD>HiPer DSP (2)</TD></TR> <TR><TD>Configuration:</TD><TD>ISDN, USR x2 and v.90 56k protocols</TD></TR> <TR><TD>Capacity as configured:</TD> <TD><b>46 modems (23 per DSP)</b></TD></TR> </TABLE> YLegend[tch1]:Modem Useage Options[tch1]:gauge Xsize[tch1]: 600 Ysize[tch1]: 200 ShortLegend[tch1]:Modems Legend1[tch1]:Modem Utilization &nbsp Legend2[tch1]:Modem Utilization &nbsp LegendI[tch1]:&nbsp Utilization &nbsp LegendO[tch1]:&nbsp Utilization &nbsp This is for a chassis with DSPs only. Maxbytes would be set to your total number of in-service modems. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

On Wed, 14 Jul 1999, Mark A. Cooper wrote: >I have a customer with an ISDN BRI circuit with a 3Com I-Modem that can only >receive a v34plus connection with us. He can call the 3Com v90 test number >and get a v90 connection. He can also call another provider and receive a >v90 connection. Interesting... there could be something funky in the call routing causing too many conversions. >Is there a specific setting within the DSP that I am missing? Is the >channelized T1 messed up? Is there an I-modem setting that is limiting the >protocol? Not likely. If any of those were true, then no one would get a v90 connection nor would he be able to connect to anyone else with v90. Use the "standard" 'aty11' debugging method to see what might be going on. (That's documented somewhere.) --Ricky

I would assume that there is no way to get the I-Modem to do v90 client? If the customer sets the I-Modem to act as a TA and uses a Sportster 56K external modem, he shouldn't then be limited by the v90 server only aspect of the I-Modem? ********************************************** Mark A. Cooper, Owner Fayette Area Internet Services Technical Support Associates 135 W. Travis La Grange, TX 78945 (409)968-3999 Voice (409)968-3225 FAX ******************************************** > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bachta > Sent: Wednesday, July 14, 1999 11:26 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) V90 connections from a Courier I-Modem > > > > > Hi Mark, > > The BBS and V.90 test number are answered by Quad Modems. Quad > modems support > Symmetric Mode x2 for 56 or 64k connections up and downstream, x2 > Server mode > for 53k downstream, V,90 Server mode for 53k downstream. (there > is no standard > yet for V.90 symmetrical connections). > > The HiPer DSP supports x2 Server mode for 53k downstream and V.90 > Server mode > for 53k downstream. The HiPer DSP does not support x2 Symmetric Mode. > > The I-Modem supports x2 Server mode, V.90 Server mode, and x2 > Symmetric Mode. > > The Courier analog modem supports x2 client mode and V.90 client mode. > > So, with that out of the way... In order to establish a V.90 > connection to a > HiPer DSP the client modem you are dialing with must have support for V.90 > client mode. The I-Modem does not support V.90 client mode. > When an I-Modem > dials a HiPer DSP the highest compatible protocol between the two > is V.34+. > When a I-Modem dials a Quad Modem the highest compatible protocol is x2 > Symmetric Mode for 56 or 64k up and downstream. My guess is the > user is seeing > the CONNECT 56000/ARQ/X2/LAPM/V42BIS for a Symmetric Mode > connection and just > generically calling this a 'v90' connection because it is 56k. > > Hope this clears things up for you. If you have any questions > let me know... > > Regards, > David > > > > > > > "Mark A. Cooper" <mcooper@fais.net> on 07/14/99 10:27:49 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: "Mark A. Cooper" <mcooper@fais.net> > > > To: usr-tc@lists.xmission.com > cc: (David Bachta/MW/US/3Com) > Subject: (usr-tc) V90 connections from a Courier I-Modem > > > > > We have channelized T1 lines feeding a TC hub running 4.1.59-6 and 1.2.43 > code. > > Users with standard POTS lines with V90 capable modems have no problem > achieving v90 connections. > > I have a customer with an ISDN BRI circuit with a 3Com I-Modem > that can only > receive a v34plus connection with us. He can call the 3Com v90 > test number > and get a v90 connection. He can also call another provider and receive a > v90 connection. > > Is there a specific setting within the DSP that I am missing? Is the > channelized T1 messed up? Is there an I-modem setting that is > limiting the > protocol? > > > ********************************************** > Mark A. Cooper, Owner > Fayette Area Internet Services > Technical Support Associates > 135 W. Travis > La Grange, TX 78945 > (409)968-3999 Voice > (409)968-3225 FAX > ******************************************** > > > - > 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. >

I will have to double check - I'mk pretty sure the logs are from the same call session, but to be sure I will have to ask the end user to try it again. I have also disabled CCP, so I'll call him to test. Thanks, Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski > Sent: Wednesday, July 14, 1999 11:57 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Problems with ISDN 2B > > > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scot Desort > |Sent: Tuesday, July 13, 1999 10:39 PM > |To: usr-tc@lists.xmission.com > |Subject: RE: (usr-tc) Problems with ISDN 2B > | > | > |Krish- > | > |<Excuse newbie question> > | > |Is that set with: > | > |set ppp ccp_modemtype_accept ?? > | > |If so, you are saying to disallow compression on DIGITAL calls? > | > > That was only an attempt to see if Compression was the culprit.. > But your trace > does point to the TA sending two different EDO's.. If that is the > case the user > will never get a bundle established..

That's correct, Mark. There is no way for an I-Modem to do V.90 client mode. Correct again. If the customer hooks up a Sportster 56k modem to the Analog Device Port of the I-Modem then the I-Modem is out of the picture. The Sportster 56k will do V.90 Client mode and the HiPer DSP will do V.90 Server mode (I'm making an assumption that there are no odd-ball network impairments that would prevent a V.90 connection). Regards, David "Mark A. Cooper" <mcooper@fais.net> on 07/14/99 01:01:33 PM Please respond to usr-tc@lists.xmission.com Sent by: "Mark A. Cooper" <mcooper@fais.net> cc: (David Bachta/MW/US/3Com) I would assume that there is no way to get the I-Modem to do v90 client? If the customer sets the I-Modem to act as a TA and uses a Sportster 56K external modem, he shouldn't then be limited by the v90 server only aspect of the I-Modem? ********************************************** Mark A. Cooper, Owner Fayette Area Internet Services Technical Support Associates 135 W. Travis La Grange, TX 78945 (409)968-3999 Voice (409)968-3225 FAX ******************************************** > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bachta > Sent: Wednesday, July 14, 1999 11:26 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) V90 connections from a Courier I-Modem > > > > > Hi Mark, > > The BBS and V.90 test number are answered by Quad Modems. Quad > modems support > Symmetric Mode x2 for 56 or 64k connections up and downstream, x2 > Server mode > for 53k downstream, V,90 Server mode for 53k downstream. (there > is no standard > yet for V.90 symmetrical connections). > > The HiPer DSP supports x2 Server mode for 53k downstream and V.90 > Server mode > for 53k downstream. The HiPer DSP does not support x2 Symmetric Mode. > > The I-Modem supports x2 Server mode, V.90 Server mode, and x2 > Symmetric Mode. > > The Courier analog modem supports x2 client mode and V.90 client mode. > > So, with that out of the way... In order to establish a V.90 > connection to a > HiPer DSP the client modem you are dialing with must have support for V.90 > client mode. The I-Modem does not support V.90 client mode. > When an I-Modem > dials a HiPer DSP the highest compatible protocol between the two > is V.34+. > When a I-Modem dials a Quad Modem the highest compatible protocol is x2 > Symmetric Mode for 56 or 64k up and downstream. My guess is the > user is seeing > the CONNECT 56000/ARQ/X2/LAPM/V42BIS for a Symmetric Mode > connection and just > generically calling this a 'v90' connection because it is 56k. > > Hope this clears things up for you. If you have any questions > let me know... > > Regards, > David > > > > > > > "Mark A. Cooper" <mcooper@fais.net> on 07/14/99 10:27:49 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: "Mark A. Cooper" <mcooper@fais.net> > > > To: usr-tc@lists.xmission.com > cc: (David Bachta/MW/US/3Com) > Subject: (usr-tc) V90 connections from a Courier I-Modem > > > > > We have channelized T1 lines feeding a TC hub running 4.1.59-6 and 1.2.43 > code. > > Users with standard POTS lines with V90 capable modems have no problem > achieving v90 connections. > > I have a customer with an ISDN BRI circuit with a 3Com I-Modem > that can only > receive a v34plus connection with us. He can call the 3Com v90 > test number > and get a v90 connection. He can also call another provider and receive a > v90 connection. > > Is there a specific setting within the DSP that I am missing? Is the > channelized T1 messed up? Is there an I-modem setting that is > limiting the > protocol? > > > ********************************************** > Mark A. Cooper, Owner > Fayette Area Internet Services > Technical Support Associates > 135 W. Travis > La Grange, TX 78945 > (409)968-3999 Voice > (409)968-3225 FAX > ******************************************** > > > - > 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. > - 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.

Hello, I am sorry, but I have to write again. We very need full HiperARC MIBS description. I can't get it from 3com. Has anybody this "secret documentaion" ? Best regards, Vadim Tulinov.

Hi All Our TCM has being running fine w/ 1 PRI line for nearly a year. Recently our 2nd PRI was in place and I plug it into the CH2 of the PRI card. But the 2nd one failed to work. The ch1 still working fine. Currently the PRI NAC light show CD2 - solid green (good) ALRM2 - off (good) LPBK2 - Solid YELLOW (no good) Both PRI line are 5ESS, B*ZS, ESF and each has its own D- Channel. Login to the COM console port show the SPAN2 D-channel is Down. I don't know how to bring it up. I asked the carrier Switch engineer to turn it up. He told me that he tried but their system idicated as "NO RESPONSE" from the TCM. Both PRI are configured as a HUNG group by the carrier. Please take a look of the attached screen shot from the PRI card console . Can you help , please ? Thanks in advance. Sincerely yours Meng tsaim@mft.om - - - - - - - - Attach - - - Copyright (c) 3Com Corporation, 1995-1997 Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) Boot Code Linked Date : Mon Dec 04 17:41:48 1995 Operation Code Linked Date: Fri Sep 05 12:11:37 1997 Power-up Self-test Status RAM: PASSED Flash ROM: PASSED Non-maskable Interrupt: PASSED Watch Dog: PASSED Management Bus UART: PASSED User Interface UART: PASSED Time/space Switch: PASSED Framer 1: PASSED Framer 2: PASSED Line Interface Unit 1: PASSED Line Interface Unit 2: PASSED FLASH ROM 12V Test: PASSED HDLC Channel 1: PASSED HDLC Channel 2: PASSED - - Card Status Current PRI Timing Source: Span Line 1. Current PBus Timing Source: Slave. NIC Type: Dual T1 v2 PRI Chassis Slot Number: 01 NAC Uptime (days::hh:mm:ss): 0::1:19:49 DRAM Installed: 4 M FLASH ROM Installed: 1 M - - - Span Line 2 Alarm/Event Status Time since clear (days::hh:mm:ss): 0::1:20:14 Receiver Gain: 0.0 dB Errored Seconds: 1 Severely Errored Seconds: 1 Failed Seconds: 0 Bipolar Violations: 1 Framing Bit Errors: 0 Change In Frame Alignment: 1 Frame Slips: 1 Bursty Errored Seconds (ESF Only): 0 CRC Errors (ESF Only): 7 Excessive CRC Error (ESF Only): 0 Out of Frame: N Out of Frame: (Red Alarm): N Loss of Signal: N Loss of Signal: (Red Alarm): N Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N Loop Back: None D-Channel Status: Down Press Return to update status, press Ctrl-R to reset counters or - - - Span Line 2 DS0 Status DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ Status Type Chan Status Type Chan 1 IDLE NONE -/- 13 IDLE NONE -/- 2 IDLE NONE -/- 14 IDLE NONE -/- 3 IDLE NONE -/- 15 IDLE NONE -/- 4 IDLE NONE -/- 16 IDLE NONE -/- 5 IDLE NONE -/- 17 IDLE NONE -/- 6 IDLE NONE -/- 18 IDLE NONE -/- 7 IDLE NONE -/- 19 IDLE NONE -/- 8 IDLE NONE -/- 20 IDLE NONE -/- 9 IDLE NONE -/- 21 IDLE NONE -/- 10 IDLE NONE -/- 22 IDLE NONE -/- 11 IDLE NONE -/- 23 IDLE NONE -/- 12 IDLE NONE -/- 24 D-CHANNEL NONE -/- - - - Span Line 2 Configuration Current Setting 1 Framing Mode ESF 2 Line Coding B8ZS 3 Remotely Initiated Loopback Ignore 4 Jitter Attenuation Transmitter 5 Transmit Line Build Out 0.0 dB 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) 7 Idle Byte Sent to TELCO FE Hex 8 DS0 to Modem Slot/Chan Mapping 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel 10 Interface ID 0 11 Span Level Call Type Blocking No Call Blocked 12 Span Level Cause Codes 13 DS0 Level Call Type Blocking 14 DS0 Level Service State 15 Short Haul NIC Line Length Not Applicable 16 Use ALERTING Response NO (NOTE: Changing configuration parameters may effect calls in progress.) Enter menu selection and press Return or press Esc to exit.

Thus spake MFT USER >Our TCM has being running fine w/ 1 PRI line for nearly a year. >Recently our 2nd PRI was in place and I plug it into the CH2 of the >PRI card. But the 2nd one failed to work. The ch1 still working fine. >Currently the PRI NAC light show > CD2 - solid green (good) > ALRM2 - off (good) > LPBK2 - Solid YELLOW (no good) An amber loopback light just indicates that the d-channel is down...which you seem to already know. :) >Login to the COM console port show the SPAN2 D-channel is Down. I don't >know how to bring it up. I asked the carrier Switch engineer to turn >it up. He told me that he tried but their system idicated as "NO >RESPONSE" from the TCM. I don't see any reason in the paste from the console session why the d-channel shouldn't be able to be brought up by the telco...everything looks pretty happy on the pri card. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jason Kelton >Not sure if this helps, but I've seen this same problem on E1 PRI's. The >most common cause we saw were remote loopbacks still enabled at the telco >end. They normally leave these on, even after the service is installed, >until you attach and remove loopback at your end. Then you normally have to >call the telco and get them to remove their remote loopback. >For 5ESS sepcifically? I couldn't answer for you.. Ah...good thought...hadn't considered that...if the telco has a loop at thier end of the circuit pointing toward the tch, you could see exactly this behavior...the ciruit would be up and green because the tch would be talking to itself, but it wouldn't be able to bring up the d-channel with itself. If you have a t-berd, you should be able to through it on the line and send out bit errors...if you get errors back, the line is looped back at you...alternatively, if you can get the telco to do this on their end (yeah, right...hope you're with a clec), they could do the same from their end...then its just a matter of finding the loop and removing it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 14 Jul 1999, Pete Ashdown wrote: >Ricky Beam said once upon a time: >>Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way >>overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on >>there at once and might go over 20%. > >I have 253 calls on one and it it is still 0%. I stand corrected -- "They are full of it." --Ricky

Ricky Beam writes... >On Wed, 14 Jul 1999, Aaron Nabil wrote: >>Anyone ever get anything other than 0? > >*laugh* Yes. Turn on OSPF... > >Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way >overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on >there at once and might go over 20%. I strongly suspect there is a bug in the way 3COM is calculating the CPU utilization. -- Aaron Nabil

On Wednesday, July 14, 1999 3:19 PM, MFT USER [SMTP:tsaim@mft.com] wrote: > I plug it into the CH2 of the PRI card. But the > 2nd one failed to work. The ch1 still working fine. > > Currently the PRI NAC light show > > CD2 - solid green (good) > ALRM2 - off (good) > LPBK2 - Solid YELLOW (no good) This is typically the state that our telco leaves the circuit in between the time they install it and when we call them to turn it up. All that should be required is to get the switch people on the phone and get them to bring up the D channel and then the trunk members. It should be fairly simple to work with your telco to work out what's wrong. > Both PRI line are 5ESS, B*ZS, ESF and each has > its own D- Channel. > > Login to the COM console port show the > SPAN2 D-channel is Down. I don't know how > to bring it up. I asked the carrier Switch engineer > to turn it up. He told me that he tried but > their system idicated as "NO RESPONSE" from the TCM. > > Both PRI are configured as a HUNG group by the carrier. > > Please take a look of the attached screen shot from > the PRI card console . Can you help , please ? > > Thanks in advance. > > Sincerely yours > > Meng > tsaim@mft.om > - - - - - - - - Attach - - - > > Copyright (c) 3Com Corporation, 1995-1997 > > Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) > Boot Code Linked Date : Mon Dec 04 17:41:48 1995 > Operation Code Linked Date: Fri Sep 05 12:11:37 1997 > > Power-up Self-test Status > > RAM: PASSED > Flash ROM: PASSED > Non-maskable Interrupt: PASSED > Watch Dog: PASSED > Management Bus UART: PASSED > User Interface UART: PASSED > Time/space Switch: PASSED > Framer 1: PASSED > Framer 2: PASSED > Line Interface Unit 1: PASSED > Line Interface Unit 2: PASSED > FLASH ROM 12V Test: PASSED > HDLC Channel 1: PASSED > HDLC Channel 2: PASSED > > - - > Card Status > > Current PRI Timing Source: Span Line 1. > Current PBus Timing Source: Slave. > NIC Type: Dual T1 v2 > PRI Chassis Slot Number: 01 > NAC Uptime (days::hh:mm:ss): 0::1:19:49 > DRAM Installed: 4 M > FLASH ROM Installed: 1 M > - - - > Span Line 2 Alarm/Event Status > > Time since clear (days::hh:mm:ss): 0::1:20:14 > Receiver Gain: 0.0 dB > Errored Seconds: 1 > Severely Errored Seconds: 1 > Failed Seconds: 0 > Bipolar Violations: 1 > Framing Bit Errors: 0 > Change In Frame Alignment: 1 > Frame Slips: 1 > Bursty Errored Seconds (ESF Only): 0 > CRC Errors (ESF Only): 7 > Excessive CRC Error (ESF Only): 0 > Out of Frame: N Out of Frame: (Red Alarm): N > Loss of Signal: N Loss of Signal: (Red Alarm): N > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > Loop Back: None > D-Channel Status: Down > Press Return to update status, press Ctrl-R to reset counters or > > - - - > Span Line 2 DS0 Status > > DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ > Status Type Chan Status Type Chan > > 1 IDLE NONE -/- 13 IDLE NONE -/- > 2 IDLE NONE -/- 14 IDLE NONE -/- > 3 IDLE NONE -/- 15 IDLE NONE -/- > 4 IDLE NONE -/- 16 IDLE NONE -/- > 5 IDLE NONE -/- 17 IDLE NONE -/- > 6 IDLE NONE -/- 18 IDLE NONE -/- > 7 IDLE NONE -/- 19 IDLE NONE -/- > 8 IDLE NONE -/- 20 IDLE NONE -/- > 9 IDLE NONE -/- 21 IDLE NONE -/- > 10 IDLE NONE -/- 22 IDLE NONE -/- > 11 IDLE NONE -/- 23 IDLE NONE -/- > 12 IDLE NONE -/- 24 D-CHANNEL NONE -/- > > - - - > Span Line 2 Configuration Current Setting > > 1 Framing Mode ESF > 2 Line Coding B8ZS > 3 Remotely Initiated Loopback Ignore > 4 Jitter Attenuation Transmitter > 5 Transmit Line Build Out 0.0 dB > 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) > 7 Idle Byte Sent to TELCO FE Hex > 8 DS0 to Modem Slot/Chan Mapping > 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel > 10 Interface ID 0 > 11 Span Level Call Type Blocking No Call Blocked > 12 Span Level Cause Codes > 13 DS0 Level Call Type Blocking > 14 DS0 Level Service State > 15 Short Haul NIC Line Length Not Applicable > 16 Use ALERTING Response NO > > (NOTE: Changing configuration parameters may effect calls in progress.) > > Enter menu selection and press Return or press Esc to exit. > > > > > > - > 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.

Thus spake Ricky Beam >On Wed, 14 Jul 1999, Pete Ashdown wrote: >>Ricky Beam said once upon a time: >>>Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way >>>overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on >>>there at once and might go over 20%. >> >>I have 253 calls on one and it it is still 0%. >I stand corrected -- "They are full of it." I seem to remember a post in the past where someone had seen it register 1%, but that the system was almost unuseable when it did...almost like when it was registering 1%, the cpu was actually at 100%....perhaps they for got to add "*100" in the code somewhere? :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Meng, First, don't believe anything the "switch tech of the week" tells you. Lately I've only run into arrogant butt-scratching goofballs; they literally cannot keep employees there for more than a month... As for the setup, we run a few PRI's into a Cisco (look behind you :), and it looks like you've got ACC/TCG/ATT's standard setup as well: isdn switch-type primary-5ess ! controller T1 1/0 framing esf linecode b8zs pri-group timeslots 1-24 ! If it really looks like all is well, try pestering the NOC back in Rochester to get a real tech on the line and you'll have a better chance of finding someone who wants to help you... good luck, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Wed, 14 Jul 1999, MFT USER wrote: > Hi All > > Our TCM has being running fine w/ 1 PRI line for > nearly a year. Recently our 2nd PRI was in place and > I plug it into the CH2 of the PRI card. But the > 2nd one failed to work. The ch1 still working fine. > > Currently the PRI NAC light show > > CD2 - solid green (good) > ALRM2 - off (good) > LPBK2 - Solid YELLOW (no good) > > Both PRI line are 5ESS, B*ZS, ESF and each has > its own D- Channel. > > Login to the COM console port show the > SPAN2 D-channel is Down. I don't know how > to bring it up. I asked the carrier Switch engineer > to turn it up. He told me that he tried but > their system idicated as "NO RESPONSE" from the TCM. > > Both PRI are configured as a HUNG group by the carrier. > > Please take a look of the attached screen shot from > the PRI card console . Can you help , please ? > > Thanks in advance. > > Sincerely yours > > Meng > tsaim@mft.om > - - - - - - - - Attach - - - > > Copyright (c) 3Com Corporation, 1995-1997 > > Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) > Boot Code Linked Date : Mon Dec 04 17:41:48 1995 > Operation Code Linked Date: Fri Sep 05 12:11:37 1997 > > Power-up Self-test Status > > RAM: PASSED > Flash ROM: PASSED > Non-maskable Interrupt: PASSED > Watch Dog: PASSED > Management Bus UART: PASSED > User Interface UART: PASSED > Time/space Switch: PASSED > Framer 1: PASSED > Framer 2: PASSED > Line Interface Unit 1: PASSED > Line Interface Unit 2: PASSED > FLASH ROM 12V Test: PASSED > HDLC Channel 1: PASSED > HDLC Channel 2: PASSED > > - - > Card Status > > Current PRI Timing Source: Span Line 1. > Current PBus Timing Source: Slave. > NIC Type: Dual T1 v2 > PRI Chassis Slot Number: 01 > NAC Uptime (days::hh:mm:ss): 0::1:19:49 > DRAM Installed: 4 M > FLASH ROM Installed: 1 M > - - - > Span Line 2 Alarm/Event Status > > Time since clear (days::hh:mm:ss): 0::1:20:14 > Receiver Gain: 0.0 dB > Errored Seconds: 1 > Severely Errored Seconds: 1 > Failed Seconds: 0 > Bipolar Violations: 1 > Framing Bit Errors: 0 > Change In Frame Alignment: 1 > Frame Slips: 1 > Bursty Errored Seconds (ESF Only): 0 > CRC Errors (ESF Only): 7 > Excessive CRC Error (ESF Only): 0 > Out of Frame: N Out of Frame: (Red Alarm): N > Loss of Signal: N Loss of Signal: (Red Alarm): N > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > Loop Back: None > D-Channel Status: Down > Press Return to update status, press Ctrl-R to reset counters or > > - - - > Span Line 2 DS0 Status > > DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ > Status Type Chan Status Type Chan > > 1 IDLE NONE -/- 13 IDLE NONE -/- > 2 IDLE NONE -/- 14 IDLE NONE -/- > 3 IDLE NONE -/- 15 IDLE NONE -/- > 4 IDLE NONE -/- 16 IDLE NONE -/- > 5 IDLE NONE -/- 17 IDLE NONE -/- > 6 IDLE NONE -/- 18 IDLE NONE -/- > 7 IDLE NONE -/- 19 IDLE NONE -/- > 8 IDLE NONE -/- 20 IDLE NONE -/- > 9 IDLE NONE -/- 21 IDLE NONE -/- > 10 IDLE NONE -/- 22 IDLE NONE -/- > 11 IDLE NONE -/- 23 IDLE NONE -/- > 12 IDLE NONE -/- 24 D-CHANNEL NONE -/- > > - - - > Span Line 2 Configuration Current Setting > > 1 Framing Mode ESF > 2 Line Coding B8ZS > 3 Remotely Initiated Loopback Ignore > 4 Jitter Attenuation Transmitter > 5 Transmit Line Build Out 0.0 dB > 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) > 7 Idle Byte Sent to TELCO FE Hex > 8 DS0 to Modem Slot/Chan Mapping > 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel > 10 Interface ID 0 > 11 Span Level Call Type Blocking No Call Blocked > 12 Span Level Cause Codes > 13 DS0 Level Call Type Blocking > 14 DS0 Level Service State > 15 Short Haul NIC Line Length Not Applicable > 16 Use ALERTING Response NO > > (NOTE: Changing configuration parameters may effect calls in progress.) > > Enter menu selection and press Return or press Esc to exit. > > > > > > - > 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 anybody have the oid handy to extract usernames I had it at one time thanks to this lists but I have misplaced it

Only on boot-up... it goes to 18% just after a reboot when 'show cpu util' is the first command you enter on the CLI... Goes down to 0% after a day or two in service... It's a nice enough feature to graph, as you see when a board has rebooted (or has been rebooted).. Robert -----Original Message----- From: Aaron Nabil [SMTP:nabil@spiritone.com] Sent: mercredi, 14. juillet 1999 10:24 To: usr-tc@lists.xmission.com Subject: (usr-tc) Non-zero CPU utilization Anyone ever get anything other than 0? s5a> _sh ver V4.1.59 - 6 us5a> show cpu util CPU Utilization: Instantaneous : 0% Last Minute : 0% Last Hour : 0% Last Day : 0% us5a> -- Aaron Nabil - 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.

On Wed, 14 Jul 1999, Aaron Nabil wrote: > Ricky Beam writes... > >On Wed, 14 Jul 1999, Aaron Nabil wrote: > >>Anyone ever get anything other than 0? > > > >*laugh* Yes. Turn on OSPF... > > > >Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way > >overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on > >there at once and might go over 20%. > > I strongly suspect there is a bug in the way 3COM is calculating > the CPU utilization. > Some 3 or 4 months back someone asked about the cpu utilization and I sent out a detailed note on how it is calculated. Hiper arc CPU is always utilized irrespective whether there is calls or not. Therefore you need a bench mark on when to start calculating the cpu utilzation. Based on the number of processes there is a set bench mark to start calculating the cpu utilization. So when you have calls or no calls the cpu is being utilized but the level is set to 0. Say you do a write to the flash - save all - at the same time look at the cpu utilization, it will go up. So the cpu utilization starts off at 0 eventhough the cpu is utilized always - that is the lowest bench mark, the cpu utilization goes up as and when you do read/writes and flash access - routing updates etc, and when you have filter rules etc - the cpu utilization goes up. krish > > -- > Aaron Nabil > > - > 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. >

Try .1.3.6.1.4.1.429.4.10.1.1.18 Steve chaos@zebra.net on 07/14/99 05:06:40 PM Please respond to usr-tc@lists.xmission.com Sent by: chaos@zebra.net cc: (Steve Valiunas/MW/US/3Com) Does anybody have the oid handy to extract usernames I had it at one time thanks to this lists but I have misplaced it - 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.

On Wed, 14 Jul 1999, Aaron Nabil wrote: >Ricky Beam writes... >>On Wed, 14 Jul 1999, Aaron Nabil wrote: >>>Anyone ever get anything other than 0? >> >>*laugh* Yes. Turn on OSPF... >> >>Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way >>overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on >>there at once and might go over 20%. > >I strongly suspect there is a bug in the way 3COM is calculating >the CPU utilization. Well, my numbers were based on experience with 4.2 (which apparently is being released tomorrow (7/15)) And trust me, when it says 100%, it means it :-) --Ricky

Hi Jason, A loop was turned on in the carrier's switch was what I thought. Yes, it is a new installation. So it was *very* possible the situation. What beats me was, I personally in the sw room work with the engineer and seeing he held a small version (hand held one) of the TCC Bert Tester. Test from the jack that our TCM plug into. And he told me that , noop, there was no LOOP turned on in their SW. It beats the heck out of me. That was why I posted all the config detail of the PRI to this group. I guess may can I shift the question to be , what to look for when use a "TCC Bert Tester" to trouble shooting the TCM's LPBK Solid Yellow Light problem ? Then I can relay the info, back to the engineer there and ask him to re do the test one more time. Hi Jeff and Matt Thanks for your confimation on what the YELLOW light means. Honestly, I was not too sure about its meaning. Althought I did guess it related to the "D-Channel" Down ... But if the SW engineer *insist* they do nothing wrong, how does the TCM guys show some scientic data to them to prove that was not the case ? Thanks all Sincerely Meng tsaim@mft.com Jason Kelton wrote: > > Meng, > > Not sure if this helps, but I've seen this same problem on E1 PRI's. The > most common cause we saw were remote loopbacks still enabled at the telco > end. They normally leave these on, even after the service is installed, > until you attach and remove loopback at your end. Then you normally have to > call the telco and get them to remove their remote loopback. > > For 5ESS sepcifically? I couldn't answer for you.. > > Regards, > > Jason.. > > ----- Original Message ----- > From: MFT USER <tsaim@mft.com> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, July 15, 1999 4:19 AM > Subject: (usr-tc) Please help - PRI Card, yellow lite on LPBK > > > Hi All > > > > Our TCM has being running fine w/ 1 PRI line for > > nearly a year. Recently our 2nd PRI was in place and > > I plug it into the CH2 of the PRI card. But the > > 2nd one failed to work. The ch1 still working fine. > > > > Currently the PRI NAC light show > > > > CD2 - solid green (good) > > ALRM2 - off (good) > > LPBK2 - Solid YELLOW (no good) > > > > Both PRI line are 5ESS, B*ZS, ESF and each has > > its own D- Channel. > > > > Login to the COM console port show the > > SPAN2 D-channel is Down. I don't know how > > to bring it up. I asked the carrier Switch engineer > > to turn it up. He told me that he tried but > > their system idicated as "NO RESPONSE" from the TCM. > > > > Both PRI are configured as a HUNG group by the carrier. > > > > Please take a look of the attached screen shot from > > the PRI card console . Can you help , please ? > > > > Thanks in advance. > > > > Sincerely yours > > > > Meng > > tsaim@mft.om > > - - - - - - - - Attach - - - > > > > Copyright (c) 3Com Corporation, 1995-1997 > > > > Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) > > Boot Code Linked Date : Mon Dec 04 17:41:48 1995 > > Operation Code Linked Date: Fri Sep 05 12:11:37 1997 > > > > Power-up Self-test Status > > > > RAM: PASSED > > Flash ROM: PASSED > > Non-maskable Interrupt: PASSED > > Watch Dog: PASSED > > Management Bus UART: PASSED > > User Interface UART: PASSED > > Time/space Switch: PASSED > > Framer 1: PASSED > > Framer 2: PASSED > > Line Interface Unit 1: PASSED > > Line Interface Unit 2: PASSED > > FLASH ROM 12V Test: PASSED > > HDLC Channel 1: PASSED > > HDLC Channel 2: PASSED > > > > - - > > Card Status > > > > Current PRI Timing Source: Span Line 1. > > Current PBus Timing Source: Slave. > > NIC Type: Dual T1 v2 > > PRI Chassis Slot Number: 01 > > NAC Uptime (days::hh:mm:ss): 0::1:19:49 > > DRAM Installed: 4 M > > FLASH ROM Installed: 1 M > > - - - > > Span Line 2 Alarm/Event Status > > > > Time since clear (days::hh:mm:ss): 0::1:20:14 > > Receiver Gain: 0.0 dB > > Errored Seconds: 1 > > Severely Errored Seconds: 1 > > Failed Seconds: 0 > > Bipolar Violations: 1 > > Framing Bit Errors: 0 > > Change In Frame Alignment: 1 > > Frame Slips: 1 > > Bursty Errored Seconds (ESF Only): 0 > > CRC Errors (ESF Only): 7 > > Excessive CRC Error (ESF Only): 0 > > Out of Frame: N Out of Frame: (Red Alarm): N > > Loss of Signal: N Loss of Signal: (Red Alarm): N > > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > > Loop Back: None > > D-Channel Status: Down > > Press Return to update status, press Ctrl-R to reset counters or > > > > - - - > > Span Line 2 DS0 Status > > > > DS0 DS0 Device Slot/ DS0 DS0 Device > Slot/ > > Status Type Chan Status Type > Chan > > > > 1 IDLE NONE -/- 13 IDLE > NONE -/- > > 2 IDLE NONE -/- 14 IDLE > NONE -/- > > 3 IDLE NONE -/- 15 IDLE > NONE -/- > > 4 IDLE NONE -/- 16 IDLE > NONE -/- > > 5 IDLE NONE -/- 17 IDLE > NONE -/- > > 6 IDLE NONE -/- 18 IDLE > NONE -/- > > 7 IDLE NONE -/- 19 IDLE > NONE -/- > > 8 IDLE NONE -/- 20 IDLE > NONE -/- > > 9 IDLE NONE -/- 21 IDLE > NONE -/- > > 10 IDLE NONE -/- 22 IDLE > NONE -/- > > 11 IDLE NONE -/- 23 IDLE > NONE -/- > > 12 IDLE NONE -/- 24 D-CHANNEL > -/- > > > > - - - > > Span Line 2 Configuration Current Setting > > > > 1 Framing Mode ESF > > 2 Line Coding B8ZS > > 3 Remotely Initiated Loopback Ignore > > 4 Jitter Attenuation Transmitter > > 5 Transmit Line Build Out 0.0 dB > > 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) > > 7 Idle Byte Sent to TELCO FE Hex > > 8 DS0 to Modem Slot/Chan Mapping > > 9 Signaling Channel Config (Boot time) Config=D-channel > Act.=D-channel > > 10 Interface ID 0 > > 11 Span Level Call Type Blocking No Call Blocked > > 12 Span Level Cause Codes > > 13 DS0 Level Call Type Blocking > > 14 DS0 Level Service State > > 15 Short Haul NIC Line Length Not Applicable > > 16 Use ALERTING Response NO > > > > (NOTE: Changing configuration parameters may effect calls in progress.) > > > > Enter menu selection and press Return or press Esc to exit. > > > > > > > > > > > > - > > 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.

Hi Charles, Thanks for your attention. I wondered how came you know exactly what's our setup until I saw your mail address. First, I spoke w/ the CLEC sw engineer on the spot. He said nothing was unusal in their setup. Absolutely, no loop was turned on. And said our TCM has NO_RESPONSE when he brought up the D-Ch on the 2nd T. I worked there for 3 hours. Then I called Rochester NOC. The operator there said they cann't do anything from there, they have to relay the problem back to the SW room. Imagine that . One people here said never believe what the "Tech of the week" said. It was a joke but it really mean something. I am kind of stuck. Next , I will try to call our sale rep. Thanks again. Sincerely Meng tsaim@mft.com Charles Sprickman wrote: > > Meng, > > First, don't believe anything the "switch tech of the week" tells you. > Lately I've only run into arrogant butt-scratching goofballs; they > literally cannot keep employees there for more than a month... > > As for the setup, we run a few PRI's into a Cisco (look behind you :), and > it looks like you've got ACC/TCG/ATT's standard setup as well: > > isdn switch-type primary-5ess > ! > controller T1 1/0 > framing esf > linecode b8zs > pri-group timeslots 1-24 > ! > > If it really looks like all is well, try pestering the NOC back in > Rochester to get a real tech on the line and you'll have a better chance > of finding someone who wants to help you... > > good luck, > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > On Wed, 14 Jul 1999, MFT USER wrote: > > > Hi All > > > > Our TCM has being running fine w/ 1 PRI line for > > nearly a year. Recently our 2nd PRI was in place and > > I plug it into the CH2 of the PRI card. But the > > 2nd one failed to work. The ch1 still working fine. > > > > Currently the PRI NAC light show > > > > CD2 - solid green (good) > > ALRM2 - off (good) > > LPBK2 - Solid YELLOW (no good) > > > > Both PRI line are 5ESS, B*ZS, ESF and each has > > its own D- Channel. > > > > Login to the COM console port show the > > SPAN2 D-channel is Down. I don't know how > > to bring it up. I asked the carrier Switch engineer > > to turn it up. He told me that he tried but > > their system idicated as "NO RESPONSE" from the TCM. > > > > Both PRI are configured as a HUNG group by the carrier. > > > > Please take a look of the attached screen shot from > > the PRI card console . Can you help , please ? > > > > Thanks in advance. > > > > Sincerely yours > > > > Meng > > tsaim@mft.om > > - - - - - - - - Attach - - - > > > > Copyright (c) 3Com Corporation, 1995-1997 > > > > Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) > > Boot Code Linked Date : Mon Dec 04 17:41:48 1995 > > Operation Code Linked Date: Fri Sep 05 12:11:37 1997 > > > > Power-up Self-test Status > > > > RAM: PASSED > > Flash ROM: PASSED > > Non-maskable Interrupt: PASSED > > Watch Dog: PASSED > > Management Bus UART: PASSED > > User Interface UART: PASSED > > Time/space Switch: PASSED > > Framer 1: PASSED > > Framer 2: PASSED > > Line Interface Unit 1: PASSED > > Line Interface Unit 2: PASSED > > FLASH ROM 12V Test: PASSED > > HDLC Channel 1: PASSED > > HDLC Channel 2: PASSED > > > > - - > > Card Status > > > > Current PRI Timing Source: Span Line 1. > > Current PBus Timing Source: Slave. > > NIC Type: Dual T1 v2 > > PRI Chassis Slot Number: 01 > > NAC Uptime (days::hh:mm:ss): 0::1:19:49 > > DRAM Installed: 4 M > > FLASH ROM Installed: 1 M > > - - - > > Span Line 2 Alarm/Event Status > > > > Time since clear (days::hh:mm:ss): 0::1:20:14 > > Receiver Gain: 0.0 dB > > Errored Seconds: 1 > > Severely Errored Seconds: 1 > > Failed Seconds: 0 > > Bipolar Violations: 1 > > Framing Bit Errors: 0 > > Change In Frame Alignment: 1 > > Frame Slips: 1 > > Bursty Errored Seconds (ESF Only): 0 > > CRC Errors (ESF Only): 7 > > Excessive CRC Error (ESF Only): 0 > > Out of Frame: N Out of Frame: (Red Alarm): N > > Loss of Signal: N Loss of Signal: (Red Alarm): N > > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > > Loop Back: None > > D-Channel Status: Down > > Press Return to update status, press Ctrl-R to reset counters or > > > > - - - > > Span Line 2 DS0 Status > > > > DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ > > Status Type Chan Status Type Chan > > > > 1 IDLE NONE -/- 13 IDLE NONE -/- > > 2 IDLE NONE -/- 14 IDLE NONE -/- > > 3 IDLE NONE -/- 15 IDLE NONE -/- > > 4 IDLE NONE -/- 16 IDLE NONE -/- > > 5 IDLE NONE -/- 17 IDLE NONE -/- > > 6 IDLE NONE -/- 18 IDLE NONE -/- > > 7 IDLE NONE -/- 19 IDLE NONE -/- > > 8 IDLE NONE -/- 20 IDLE NONE -/- > > 9 IDLE NONE -/- 21 IDLE NONE -/- > > 10 IDLE NONE -/- 22 IDLE NONE -/- > > 11 IDLE NONE -/- 23 IDLE NONE -/- > > 12 IDLE NONE -/- 24 D-CHANNEL NONE -/- > > > > - - - > > Span Line 2 Configuration Current Setting > > > > 1 Framing Mode ESF > > 2 Line Coding B8ZS > > 3 Remotely Initiated Loopback Ignore > > 4 Jitter Attenuation Transmitter > > 5 Transmit Line Build Out 0.0 dB > > 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) > > 7 Idle Byte Sent to TELCO FE Hex > > 8 DS0 to Modem Slot/Chan Mapping > > 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel > > 10 Interface ID 0 > > 11 Span Level Call Type Blocking No Call Blocked > > 12 Span Level Cause Codes > > 13 DS0 Level Call Type Blocking > > 14 DS0 Level Service State > > 15 Short Haul NIC Line Length Not Applicable > > 16 Use ALERTING Response NO > > > > (NOTE: Changing configuration parameters may effect calls in progress.) > > > > Enter menu selection and press Return or press Esc to exit. > > > > > > > > > > > > - > > 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.

On Wed, 14 Jul 1999, Jeff Mcadams wrote: > Thus spake Ricky Beam > >On Wed, 14 Jul 1999, Pete Ashdown wrote: > >>Ricky Beam said once upon a time: > >>>Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way > >>>overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on > >>>there at once and might go over 20%. > >> > >>I have 253 calls on one and it it is still 0%. > > >I stand corrected -- "They are full of it." > > I seem to remember a post in the past where someone had seen it register > 1%, but that the system was almost unuseable when it did...almost like > when it was registering 1%, the cpu was actually at 100%....perhaps they > for got to add "*100" in the code somewhere? :) I have seen 1% before, and it wasn't even on a fully loaded chassis. > -- > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

> > Some 3 or 4 months back someone asked about the cpu utilization and I > sent out a detailed note on how it is calculated. > > Hiper arc CPU is always utilized irrespective whether there is calls or > not. Therefore you need a bench mark on when to start calculating the cpu > utilzation. Based on the number of processes there is a set bench mark > to start calculating the cpu utilization. So when you have calls or no > calls the cpu is being utilized but the level is set to 0. Say you do a > write to the flash - save all - at the same time look at the cpu > utilization, it will go up. > > So the cpu utilization starts off at 0 eventhough the cpu is utilized > always - that is the lowest bench mark, the cpu utilization goes up as > and when you do read/writes and flash access - routing updates etc, > and when you have filter rules etc - the cpu utilization goes up. > > krish Ok, so its just a measure of how much extra cpu is being utilized. Maybe it saying cpu utilization "+5%" etc, would make more sense (putting the + their) > > > > > > -- > > Aaron Nabil > > > > - > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake M. Tsai >What beats me was, I personally in the sw room work with the engineer >and seeing he held a small version (hand held one) of the TCC Bert >Tester. Test from the jack that our TCM plug into. And he told me that >, noop, there was no LOOP turned on in their SW. It beats the heck >out of me. That was why I posted all the config detail of the PRI to >this group. The best way that I know of to test this is to send bit errors from the Bert unit (there's proly a button on the front to insert errors), and if you get the errors back, then there's a loop pointed at the bert unit. >I guess may can I shift the question to be , what to look for when use >a "TCC Bert Tester" to trouble shooting the TCM's LPBK Solid Yellow >Light problem ? Then I can relay the info, back to the engineer there >and ask him to re do the test one more time. >But if the SW engineer *insist* they do nothing wrong, how does the TCM >guys show some scientic data to them to prove that was not the case ? I'm not aware of any way to do bit errors from a dual-pri card, nor to do bert testing, so I'm not sure there's any good way to have a solid answer on what the problem is for the switch tech dudes (who I will agree are often pretty much cluebies). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi, One of the things we're doing is pulling in lines from focal to see if they're any better... The only thing I can think of besides very carefully checking that both lines are set up exactly the same on your side is to get the tech to do the same on their side. Have him make sure they are exactly the same and the cross-connect is correct as well. We had a problem where a T1 was going to the wrong place. You can check this by having the tech pull the line out of service and checking if your PRI card shows any alarms. Beyond that, I'm not sure what else to do besides calling Harold repeatedly... thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Wed, 14 Jul 1999, M. Tsai wrote: > Hi Charles, > > Thanks for your attention. I wondered how came > you know exactly what's our setup until I saw your mail address. > > First, I spoke w/ the CLEC sw engineer on the spot. He said nothing > was unusal in their setup. Absolutely, no loop was turned on. And > said our TCM has NO_RESPONSE when he brought up the D-Ch on the 2nd T. > I worked there for 3 hours. Then I called Rochester NOC. The > operator there said they cann't do anything from there, they have > to relay the problem back to the SW room. Imagine that . > > One people here said never believe what the "Tech of the week" said. > It was a joke but it really mean something. I am kind of stuck. > Next , I will try to call our sale rep. > > Thanks again. > > Sincerely > > Meng > tsaim@mft.com > > Charles Sprickman wrote: > > > > Meng, > > > > First, don't believe anything the "switch tech of the week" tells you. > > Lately I've only run into arrogant butt-scratching goofballs; they > > literally cannot keep employees there for more than a month... > > > > As for the setup, we run a few PRI's into a Cisco (look behind you :), and > > it looks like you've got ACC/TCG/ATT's standard setup as well: > > > > isdn switch-type primary-5ess > > ! > > controller T1 1/0 > > framing esf > > linecode b8zs > > pri-group timeslots 1-24 > > ! > > > > If it really looks like all is well, try pestering the NOC back in > > Rochester to get a real tech on the line and you'll have a better chance > > of finding someone who wants to help you... > > > > good luck, > > > > Charles > > > > -- > > =-----------------= = > > | Charles Sprickman Internet Channel | > > | INCH System Administration Team (212)243-5200 | > > | spork@inch.com access@inch.com | > > = =----------------= > > > > On Wed, 14 Jul 1999, MFT USER wrote: > > > > > Hi All > > > > > > Our TCM has being running fine w/ 1 PRI line for > > > nearly a year. Recently our 2nd PRI was in place and > > > I plug it into the CH2 of the PRI card. But the > > > 2nd one failed to work. The ch1 still working fine. > > > > > > Currently the PRI NAC light show > > > > > > CD2 - solid green (good) > > > ALRM2 - off (good) > > > LPBK2 - Solid YELLOW (no good) > > > > > > Both PRI line are 5ESS, B*ZS, ESF and each has > > > its own D- Channel. > > > > > > Login to the COM console port show the > > > SPAN2 D-channel is Down. I don't know how > > > to bring it up. I asked the carrier Switch engineer > > > to turn it up. He told me that he tried but > > > their system idicated as "NO RESPONSE" from the TCM. > > > > > > Both PRI are configured as a HUNG group by the carrier. > > > > > > Please take a look of the attached screen shot from > > > the PRI card console . Can you help , please ? > > > > > > Thanks in advance. > > > > > > Sincerely yours > > > > > > Meng > > > tsaim@mft.om > > > - - - - - - - - Attach - - - > > > > > > Copyright (c) 3Com Corporation, 1995-1997 > > > > > > Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) > > > Boot Code Linked Date : Mon Dec 04 17:41:48 1995 > > > Operation Code Linked Date: Fri Sep 05 12:11:37 1997 > > > > > > Power-up Self-test Status > > > > > > RAM: PASSED > > > Flash ROM: PASSED > > > Non-maskable Interrupt: PASSED > > > Watch Dog: PASSED > > > Management Bus UART: PASSED > > > User Interface UART: PASSED > > > Time/space Switch: PASSED > > > Framer 1: PASSED > > > Framer 2: PASSED > > > Line Interface Unit 1: PASSED > > > Line Interface Unit 2: PASSED > > > FLASH ROM 12V Test: PASSED > > > HDLC Channel 1: PASSED > > > HDLC Channel 2: PASSED > > > > > > - - > > > Card Status > > > > > > Current PRI Timing Source: Span Line 1. > > > Current PBus Timing Source: Slave. > > > NIC Type: Dual T1 v2 > > > PRI Chassis Slot Number: 01 > > > NAC Uptime (days::hh:mm:ss): 0::1:19:49 > > > DRAM Installed: 4 M > > > FLASH ROM Installed: 1 M > > > - - - > > > Span Line 2 Alarm/Event Status > > > > > > Time since clear (days::hh:mm:ss): 0::1:20:14 > > > Receiver Gain: 0.0 dB > > > Errored Seconds: 1 > > > Severely Errored Seconds: 1 > > > Failed Seconds: 0 > > > Bipolar Violations: 1 > > > Framing Bit Errors: 0 > > > Change In Frame Alignment: 1 > > > Frame Slips: 1 > > > Bursty Errored Seconds (ESF Only): 0 > > > CRC Errors (ESF Only): 7 > > > Excessive CRC Error (ESF Only): 0 > > > Out of Frame: N Out of Frame: (Red Alarm): N > > > Loss of Signal: N Loss of Signal: (Red Alarm): N > > > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > > > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > > > Loop Back: None > > > D-Channel Status: Down > > > Press Return to update status, press Ctrl-R to reset counters or > > > > > > - - - > > > Span Line 2 DS0 Status > > > > > > DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ > > > Status Type Chan Status Type Chan > > > > > > 1 IDLE NONE -/- 13 IDLE NONE -/- > > > 2 IDLE NONE -/- 14 IDLE NONE -/- > > > 3 IDLE NONE -/- 15 IDLE NONE -/- > > > 4 IDLE NONE -/- 16 IDLE NONE -/- > > > 5 IDLE NONE -/- 17 IDLE NONE -/- > > > 6 IDLE NONE -/- 18 IDLE NONE -/- > > > 7 IDLE NONE -/- 19 IDLE NONE -/- > > > 8 IDLE NONE -/- 20 IDLE NONE -/- > > > 9 IDLE NONE -/- 21 IDLE NONE -/- > > > 10 IDLE NONE -/- 22 IDLE NONE -/- > > > 11 IDLE NONE -/- 23 IDLE NONE -/- > > > 12 IDLE NONE -/- 24 D-CHANNEL NONE -/- > > > > > > - - - > > > Span Line 2 Configuration Current Setting > > > > > > 1 Framing Mode ESF > > > 2 Line Coding B8ZS > > > 3 Remotely Initiated Loopback Ignore > > > 4 Jitter Attenuation Transmitter > > > 5 Transmit Line Build Out 0.0 dB > > > 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) > > > 7 Idle Byte Sent to TELCO FE Hex > > > 8 DS0 to Modem Slot/Chan Mapping > > > 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel > > > 10 Interface ID 0 > > > 11 Span Level Call Type Blocking No Call Blocked > > > 12 Span Level Cause Codes > > > 13 DS0 Level Call Type Blocking > > > 14 DS0 Level Service State > > > 15 Short Haul NIC Line Length Not Applicable > > > 16 Use ALERTING Response NO > > > > > > (NOTE: Changing configuration parameters may effect calls in progress.) > > > > > > Enter menu selection and press Return or press Esc to exit. > > > > > > > > > > > > > > > > > > - > > > 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. >

Meng, Not sure if this helps, but I've seen this same problem on E1 PRI's. The most common cause we saw were remote loopbacks still enabled at the telco end. They normally leave these on, even after the service is installed, until you attach and remove loopback at your end. Then you normally have to call the telco and get them to remove their remote loopback. For 5ESS sepcifically? I couldn't answer for you.. Regards, Jason.. ----- Original Message ----- Sent: Thursday, July 15, 1999 4:19 AM > Hi All > > Our TCM has being running fine w/ 1 PRI line for > nearly a year. Recently our 2nd PRI was in place and > I plug it into the CH2 of the PRI card. But the > 2nd one failed to work. The ch1 still working fine. > > Currently the PRI NAC light show > > CD2 - solid green (good) > ALRM2 - off (good) > LPBK2 - Solid YELLOW (no good) > > Both PRI line are 5ESS, B*ZS, ESF and each has > its own D- Channel. > > Login to the COM console port show the > SPAN2 D-channel is Down. I don't know how > to bring it up. I asked the carrier Switch engineer > to turn it up. He told me that he tried but > their system idicated as "NO RESPONSE" from the TCM. > > Both PRI are configured as a HUNG group by the carrier. > > Please take a look of the attached screen shot from > the PRI card console . Can you help , please ? > > Thanks in advance. > > Sincerely yours > > Meng > tsaim@mft.om > - - - - - - - - Attach - - - > > Copyright (c) 3Com Corporation, 1995-1997 > > Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) > Boot Code Linked Date : Mon Dec 04 17:41:48 1995 > Operation Code Linked Date: Fri Sep 05 12:11:37 1997 > > Power-up Self-test Status > > RAM: PASSED > Flash ROM: PASSED > Non-maskable Interrupt: PASSED > Watch Dog: PASSED > Management Bus UART: PASSED > User Interface UART: PASSED > Time/space Switch: PASSED > Framer 1: PASSED > Framer 2: PASSED > Line Interface Unit 1: PASSED > Line Interface Unit 2: PASSED > FLASH ROM 12V Test: PASSED > HDLC Channel 1: PASSED > HDLC Channel 2: PASSED > > - - > Card Status > > Current PRI Timing Source: Span Line 1. > Current PBus Timing Source: Slave. > NIC Type: Dual T1 v2 > PRI Chassis Slot Number: 01 > NAC Uptime (days::hh:mm:ss): 0::1:19:49 > DRAM Installed: 4 M > FLASH ROM Installed: 1 M > - - - > Span Line 2 Alarm/Event Status > > Time since clear (days::hh:mm:ss): 0::1:20:14 > Receiver Gain: 0.0 dB > Errored Seconds: 1 > Severely Errored Seconds: 1 > Failed Seconds: 0 > Bipolar Violations: 1 > Framing Bit Errors: 0 > Change In Frame Alignment: 1 > Frame Slips: 1 > Bursty Errored Seconds (ESF Only): 0 > CRC Errors (ESF Only): 7 > Excessive CRC Error (ESF Only): 0 > Out of Frame: N Out of Frame: (Red Alarm): N > Loss of Signal: N Loss of Signal: (Red Alarm): N > Remote Frame Alarm: N Remote Frame Alarm: (Yellow Alarm): N > Alarm Indication Signal: N Alarm Indication Signal: (Blue Alarm): N > Loop Back: None > D-Channel Status: Down > Press Return to update status, press Ctrl-R to reset counters or > > - - - > Span Line 2 DS0 Status > > DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ > Status Type Chan Status Type Chan > > 1 IDLE NONE -/- 13 IDLE NONE -/- > 2 IDLE NONE -/- 14 IDLE NONE -/- > 3 IDLE NONE -/- 15 IDLE NONE -/- > 4 IDLE NONE -/- 16 IDLE NONE -/- > 5 IDLE NONE -/- 17 IDLE NONE -/- > 6 IDLE NONE -/- 18 IDLE NONE -/- > 7 IDLE NONE -/- 19 IDLE NONE -/- > 8 IDLE NONE -/- 20 IDLE NONE -/- > 9 IDLE NONE -/- 21 IDLE NONE -/- > 10 IDLE NONE -/- 22 IDLE NONE -/- > 11 IDLE NONE -/- 23 IDLE NONE -/- > 12 IDLE NONE -/- 24 D-CHANNEL -/- > > - - - > Span Line 2 Configuration Current Setting > > 1 Framing Mode ESF > 2 Line Coding B8ZS > 3 Remotely Initiated Loopback Ignore > 4 Jitter Attenuation Transmitter > 5 Transmit Line Build Out 0.0 dB > 6 Switch Type (Boot time) Config=5ESS(AT&T)Act.=5ESS(AT&T) > 7 Idle Byte Sent to TELCO FE Hex > 8 DS0 to Modem Slot/Chan Mapping > 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel > 10 Interface ID 0 > 11 Span Level Call Type Blocking No Call Blocked > 12 Span Level Cause Codes > 13 DS0 Level Call Type Blocking > 14 DS0 Level Service State > 15 Short Haul NIC Line Length Not Applicable > 16 Use ALERTING Response NO > > (NOTE: Changing configuration parameters may effect calls in progress.) > > Enter menu selection and press Return or press Esc to exit. > > > > > > - > 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.

hehe - or maybe you got one of those new generation cards, where its soo blindingly fast, even a 1000 calls would be lucky to register; or maybe, all your users are sitting idle :) - Jason. ----- Original Message ----- Sent: Thursday, July 15, 1999 4:59 AM > On Wed, 14 Jul 1999, Pete Ashdown wrote: > >Ricky Beam said once upon a time: > >>Normally, a "heavy" load would be in the 3-10% range. A 200MHz PPC is way > >>overkill for just PPP. (Even RIP doesn't eat anything.) Put 300+ calls on > >>there at once and might go over 20%. > > > >I have 253 calls on one and it it is still 0%. > > I stand corrected -- "They are full of it." > > --Ricky > > > > - > 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.

(notice forwarded from 3Com TotalControl mailing list at totalcontrol@totalservice.nsd.usr.com - subscription information listed below) 3Com Customers, 3Com would like to announce the release of Total Control System version 3.6 on the TotalService website at: http://totalservice.3com.com/ Total Control System v3.6 includes all code, release notes, and documentation for the following modules: HiPer Access Router Card - version 4.2.29 HiPer Access Router Manager (Windows) - version 1.2.6 HiPer Access Router Manager (Solaris) - version 1.2.4 Download of this code requires a valid service contract. If you would like to purchase a service contract, please contact your local reseller of 3Com services for more information. To locate your local Value Added Reseller, as well as 3Com sales offices, please go to: http://www.3com.com/products/shop/where2buy_2.html If there are any questions or concerns regarding this System Release, please contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an area not handled by this number, the TotalService website has contact information for other countries and regions. Please go to the TotalService website and click on 'Contacting Tech Support' for more information. The Software Compatibility Matrix on TotalService will be updated later this week to reflect compatibility with other releases of code. Thank you, Will Brien Customer Service Product Planning William_Brien@3com.com (3Com User Forum information available at http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink )

On Wed, 14 Jul 1999, Brian wrote: > > > > Some 3 or 4 months back someone asked about the cpu utilization and I > > sent out a detailed note on how it is calculated. > > > > Hiper arc CPU is always utilized irrespective whether there is calls or > > not. Therefore you need a bench mark on when to start calculating the cpu > > utilzation. Based on the number of processes there is a set bench mark > > to start calculating the cpu utilization. So when you have calls or no > > calls the cpu is being utilized but the level is set to 0. Say you do a > > write to the flash - save all - at the same time look at the cpu > > utilization, it will go up. > > > > So the cpu utilization starts off at 0 eventhough the cpu is utilized > > always - that is the lowest bench mark, the cpu utilization goes up as > > and when you do read/writes and flash access - routing updates etc, > > and when you have filter rules etc - the cpu utilization goes up. > > > > krish > > Ok, so its just a measure of how much extra cpu is being utilized. Maybe > it saying cpu utilization "+5%" etc, would make more sense (putting the + > their) No thats not the case becuase the base line is a mean - When the card has minmal activity meaning no calls no DSP attached ( certain conditions ) you take a value and When the card is fully loaded and no call senario you have another value - the base line is the mid point or the mean. Starting from that when a call comes in and connects cpu is utilized but to a very minimal level, So when you say 0 CPU - the cpu us utilized upto the mean/base point and anything over is the actual cpu utilization krish > > > > > > > > > > > -- > > > Aaron Nabil > > > > > > - > > > 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. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. >

Dear Sir/Madam, I would like to buy one of the x2 upgrade keys (3com p/n 002083-0) for $300. Please let me know if you still have these and I will provide a shipping address. Thanks. Tim Brown SumterNet, Inc 803-436-5531 -----Original Message----- >Mark- >i am sure you have it by now but, if you don't the p/n is 002083-0 list >price is $1600. i have a couple for $300. each. can you advise if you >still need them or not.?? thanks for the reply ion advance. i am going >to post them up at $500. and see what happens soon. > >Mark Ross wrote: > >> Hi, >> Does anyone have prices for an X2 key for a total control server >> >> 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. > > > > >- > 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.

Thus spake Tatai SV Krishnan >No thats not the case becuase the base line is a mean - When the card has >minmal activity meaning no calls no DSP attached ( certain conditions ) >you take a value and When the card is fully loaded and no call senario >you have another value - the base line is the mid point or the mean. >Starting from that when a call comes in and connects cpu is utilized but >to a very minimal level, So when you say 0 CPU - the cpu us utilized upto >the mean/base point and anything over is the actual cpu utilization Might I make a request...from a user perspective...that this be made into an absolute utilization number? The current systems seems just a tad bit overcomplicated for something like this. Having a box sitting there doing nothing but having a cpu utilization of 11% or something doesn't really bother me, and it would actually make this number be useful...which the current consensus from the user community right now is that the current setup for this value is pretty much worthless. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hello all Getting some time tinker with the HiperARC card... two questions... Has anyone set up the ARC to route "internet" (aka non-local) traffic to go out eth:0 and local network traffic out the eth:1 interface? Has anyone ever found out what the WAN port is used for? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net

> doesn;t appear to be on totalservice ... please give mw a link .. Don't go into the "latest code" area. Go into the software library, and choose TCS 3.6 - it's in there. > ----- Original Message ----- > From: William Brien <William_Brien@mw.3com.com> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, July 15, 1999 9:59 AM > Subject: (usr-tc) NOTICE - Total Control System v3.6 (posting complete) > > > > > > > > (notice forwarded from 3Com TotalControl mailing list at > > totalcontrol@totalservice.nsd.usr.com - subscription information listed > below) > > > > 3Com Customers, > > > > 3Com would like to announce the release of Total Control System version > 3.6 on > > the TotalService website at: > > > > http://totalservice.3com.com/ > > > > Total Control System v3.6 includes all code, release notes, and > documentation > > for the following modules: > > > > HiPer Access Router Card - version 4.2.29 > > HiPer Access Router Manager (Windows) - version 1.2.6 > > HiPer Access Router Manager (Solaris) - version 1.2.4 > > > > Download of this code requires a valid service contract. If you would > like to > > purchase a service contract, please contact your local reseller of 3Com > services > > for more information. To locate your local Value Added Reseller, as well > as > > 3Com sales offices, please go to: > > > > http://www.3com.com/products/shop/where2buy_2.html > > > > If there are any questions or concerns regarding this System Release, > please > > contact 3Com Technical Support toll-free at 1-800-231-8770. If you are > calling > > from an area not handled by this number, the TotalService website has > contact > > information for other countries and regions. Please go to the > TotalService > > website and click on 'Contacting Tech Support' for more information. > > > > The Software Compatibility Matrix on TotalService will be updated later > this > > week to reflect compatibility with other releases of code. > > > > Thank you, > > > > Will Brien > > Customer Service Product Planning > > William_Brien@3com.com > > > > (3Com User Forum information available at > > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink ) > > > > > > > > - > > 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. > -- | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Senior Vice President - Exec-PC, Inc. - A Voyager.net company |

On Thu, 15 Jul 1999, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >No thats not the case becuase the base line is a mean - When the card has > >minmal activity meaning no calls no DSP attached ( certain conditions ) > >you take a value and When the card is fully loaded and no call senario > >you have another value - the base line is the mid point or the mean. > >Starting from that when a call comes in and connects cpu is utilized but > >to a very minimal level, So when you say 0 CPU - the cpu us utilized upto > >the mean/base point and anything over is the actual cpu utilization > > Might I make a request...from a user perspective...that this be made > into an absolute utilization number? The current systems seems just a > tad bit overcomplicated for something like this. Sure can be considered and we can put in a request for change. krish > > Having a box sitting there doing nothing but having a cpu utilization of > 11% or something doesn't really bother me, and it would actually make > this number be useful...which the current consensus from the user > community right now is that the current setup for this value is pretty > much worthless. > -- > 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. >

On Thu, 15 Jul 1999, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >No thats not the case becuase the base line is a mean - When the card has > >minmal activity meaning no calls no DSP attached ( certain conditions ) > >you take a value and When the card is fully loaded and no call senario > >you have another value - the base line is the mid point or the mean. > >Starting from that when a call comes in and connects cpu is utilized but > >to a very minimal level, So when you say 0 CPU - the cpu us utilized upto > >the mean/base point and anything over is the actual cpu utilization > > Might I make a request...from a user perspective...that this be made > into an absolute utilization number? The current systems seems just a > tad bit overcomplicated for something like this. Sure can be considered and we can put in a request for change. krish > > Having a box sitting there doing nothing but having a cpu utilization of > 11% or something doesn't really bother me, and it would actually make > this number be useful...which the current consensus from the user > community right now is that the current setup for this value is pretty > much worthless. > -- > 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. >

Thus spake Paul Farber >Getting some time tinker with the HiperARC card... >two questions... >Has anyone set up the ARC to route "internet" (aka non-local) traffic to >go out eth:0 and local network traffic out the eth:1 interface? I've never set it up that way specifically...but I have had an Arc routing traffic out different ethernet interfaces...even routing between them a little. >Has anyone ever found out what the WAN port is used for? Are you talking about the NETServer or is this in the new 4.2, or what? With the new 4.2 that's out as of today, there are two new NICs for the HiPer Arcs...one has a 10/100 ethernet and 2 v.35 ports (frame-relay), the other has a 10/100 ethernet and 4 clear channel or channelized t1 ports (also only frame-relay) with integrated csu/dsu's. The wan interfaces would be used with these other two NICs I suspect... Reading through the release notes...I did find some interesting info...apparently, the 4 t1 ports can be channelized down to the ds0 level...which is pretty nifty on its own...but they can also be aggregated together to provide aggregate bandwidth to a single pvc of greater than a t1's worth of bandwidth. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Oops. I didn't mean to send this to the list. Tim -----Original Message----- >Dear Sir/Madam, >I would like to buy one of the x2 upgrade keys (3com p/n 002083-0) for $300. >Please let me know if you still have these and I will provide a shipping >address. Thanks. >Tim Brown >SumterNet, Inc >803-436-5531 > >-----Original Message----- >From: access1 <access1@simplyweb.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, July 13, 1999 7:10 PM >Subject: Re: (usr-tc) WTB X2 key for total control > > >>Mark- >>i am sure you have it by now but, if you don't the p/n is 002083-0 list >>price is $1600. i have a couple for $300. each. can you advise if you >>still need them or not.?? thanks for the reply ion advance. i am going >>to post them up at $500. and see what happens soon. >> >>Mark Ross wrote: >> >>> Hi, >>> Does anyone have prices for an X2 key for a total control server >>> >>> 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. >> >> >> >> >>- >> 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.

doesn;t appear to be on totalservice ... please give mw a link .. ----- Original Message ----- Sent: Thursday, July 15, 1999 9:59 AM > > > (notice forwarded from 3Com TotalControl mailing list at > totalcontrol@totalservice.nsd.usr.com - subscription information listed below) > > 3Com Customers, > > 3Com would like to announce the release of Total Control System version 3.6 on > the TotalService website at: > > http://totalservice.3com.com/ > > Total Control System v3.6 includes all code, release notes, and documentation > for the following modules: > > HiPer Access Router Card - version 4.2.29 > HiPer Access Router Manager (Windows) - version 1.2.6 > HiPer Access Router Manager (Solaris) - version 1.2.4 > > Download of this code requires a valid service contract. If you would like to > purchase a service contract, please contact your local reseller of 3Com services > for more information. To locate your local Value Added Reseller, as well as > 3Com sales offices, please go to: > > http://www.3com.com/products/shop/where2buy_2.html > > If there are any questions or concerns regarding this System Release, please > contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling > from an area not handled by this number, the TotalService website has contact > information for other countries and regions. Please go to the TotalService > website and click on 'Contacting Tech Support' for more information. > > The Software Compatibility Matrix on TotalService will be updated later this > week to reflect compatibility with other releases of code. > > Thank you, > > Will Brien > Customer Service Product Planning > William_Brien@3com.com > > (3Com User Forum information available at > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink ) > > > > - > 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. > >

Thus spake Jamie Orzechowski >doesn;t appear to be on totalservice ... please give mw a link .. It's not up in the "newest code" section yet...look in the software library...its in there. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jamie Orzechowski >doesn;t appear to be on totalservice ... please give mw a link .. It's not up in the "newest code" section yet...look in the software library...its in there. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

If anyone gets TCS3.6 up and running please post some feedback. Specifically any gotchas that happened during the upgrade, and any bus (er I mean features?) that pop up :) Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake Hostmaster Soho Solutions - Javier Szyszlican >Can I use the Port 1 & 2 of my Netserver to run Frame Relay?? If you're referring to the WAN ports on the NETServer NIC card, yes...they are frame-relay ports and can run up to T1 speeds worth of frame-relay...I'm not sure on the config having never actually set them up to do that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Can I use the Port 1 & 2 of my Netserver to run Frame Relay?? -----Original Message----- >Thus spake Paul Farber >>Getting some time tinker with the HiperARC card... >>two questions... > >>Has anyone set up the ARC to route "internet" (aka non-local) traffic to >>go out eth:0 and local network traffic out the eth:1 interface? > >I've never set it up that way specifically...but I have had an Arc >routing traffic out different ethernet interfaces...even routing between >them a little. > >>Has anyone ever found out what the WAN port is used for? > >Are you talking about the NETServer or is this in the new 4.2, or what? >With the new 4.2 that's out as of today, there are two new NICs for the >HiPer Arcs...one has a 10/100 ethernet and 2 v.35 ports (frame-relay), >the other has a 10/100 ethernet and 4 clear channel or channelized t1 >ports (also only frame-relay) with integrated csu/dsu's. The wan >interfaces would be used with these other two NICs I suspect... > >Reading through the release notes...I did find some interesting >info...apparently, the 4 t1 ports can be channelized down to the ds0 >level...which is pretty nifty on its own...but they can also be >aggregated together to provide aggregate bandwidth to a single pvc of >greater than a t1's worth of bandwidth. >-- >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. >

On Thu, 15 Jul 1999, Hostmaster Soho Solutions - Javier Szyszlican wrote: >But I'm trying to cut costs for instaling a small pop... >I am ok? Words to live by: Because one can do a thing does not mean one necessarily should do a thing. (This coming from one has done many a thing that "should not be done.") As I recall, the WAN ports use a standard Cisco V.35 cable. --Ricky

I set up a NETServer to do frame relay at 128kbps and it only did a mediocre job at it. I'm much happier with a cisco doing the routing now. Matt... On Thursday, July 15, 1999 4:21 PM, Jeff Mcadams [SMTP:jeffm@iglou.com] wrote: > Thus spake Hostmaster Soho Solutions - Javier Szyszlican > >Can I use the Port 1 & 2 of my Netserver to run Frame Relay?? > > If you're referring to the WAN ports on the NETServer NIC card, > yes...they are frame-relay ports and can run up to T1 speeds worth of > frame-relay...I'm not sure on the config having never actually set them > up to do that. > -- > 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.

Thus spake Brian >If anyone gets TCS3.6 up and running please post some feedback. >Specifically any gotchas that happened during the upgrade, and any bus (er >I mean features?) that pop up :) System Version: V4.2.29 Mind you...not taking any calls, but is handling OSPF routes and routing between two subnets (using OSPF to control it) on our network now...also, mind you, I still have a cisco router in place in parallel with this sucker for failover support. Seems to be pretty decent from what I can see...have no comments yet about its handling of PPP and actual calls, so I doubt this really helps much, but its a start...it boots, it participates in OSPF (this one is even a designated router at the moment!) and routes, so its a good start. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

But I'm trying to cut costs for instaling a small pop... I am ok? -----Original Message----- > >I set up a NETServer to do frame relay at 128kbps and it only did a mediocre >job at it. I'm much happier with a cisco doing the routing now. > >Matt... > >On Thursday, July 15, 1999 4:21 PM, Jeff Mcadams [SMTP:jeffm@iglou.com] >wrote: >> Thus spake Hostmaster Soho Solutions - Javier Szyszlican >> >Can I use the Port 1 & 2 of my Netserver to run Frame Relay?? >> >> If you're referring to the WAN ports on the NETServer NIC card, >> yes...they are frame-relay ports and can run up to T1 speeds worth of >> frame-relay...I'm not sure on the config having never actually set them >> up to do that. >> -- >> 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. >

Hi, In regards to the frame relay implementation for V4.2.29 - does anybody know exactly what hardware is needed? Can we use old T1/E1 cards that were earlier in service to support Quad Modems?

On Thu, 15 Jul 1999, Jeff Mcadams wrote: > Thus spake Brian > >If anyone gets TCS3.6 up and running please post some feedback. > >Specifically any gotchas that happened during the upgrade, and any bus (er > >I mean features?) that pop up :) > > System Version: V4.2.29 > > Mind you...not taking any calls, but is handling OSPF routes and routing > between two subnets (using OSPF to control it) on our network > now...also, mind you, I still have a cisco router in place in parallel > with this sucker for failover support. > > Seems to be pretty decent from what I can see...have no comments yet > about its handling of PPP and actual calls, so I doubt this really helps > much, but its a start...it boots, it participates in OSPF (this one is > even a designated router at the moment!) and routes, so its a good > start. Can you post the OSPF portion of your config? I would just want to do the equivelent of like: router ospf network x.x.x.x mask 255.255.255.0 area 1 redistribute connected subnets redistribute static I think I'll setup an ARC with no HDM's assigned just to see how it does with OSPF as well. Brian > -- > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

At 06:02 PM 7/14/99 -0500, you wrote: > > >Try .1.3.6.1.4.1.429.4.10.1.1.18 > >>Does anybody have the oid handy to extract usernames I had it at one >>time thanks to this lists but I have misplaced it Anybody care to share other helpful oid's...connection speeds,etc? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

dir 937358 ./root/USR/hiperARC/configs leaf 937359 ./root/USR/hiperARC/configs/Config-4.1.59 leaf 937376 ./root/USR/hiperARC/configs/Config-4.2.89-1 leaf 937377 ./root/USR/hiperARC/configs/Config-4.2.89-1-OSPF leaf 937378 ./root/USR/hiperARC/configs/Config-4.2.89-1-RIPv2 dir 833863 ./root/USR/hiperARC/Docs leaf 756397 ./root/USR/hiperARC/Docs/ospf_chap.pdf leaf 756398 ./root/USR/hiperARC/Docs/ospf_commands.pdf Should I restore any of these (or plug the drive back in)? I don't remember if those are CLI instructions or bulk configs. --Ricky

Thus spake K Mitchell >Anybody care to share other helpful oid's...connection speeds,etc? mdmCsFinalTxLinkRate .1.3.6.1.4.1.429.1.6.9.1.1.12.<entitynum> -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Ricky Beam >dir 937358 ./root/USR/hiperARC/configs >leaf 937359 ./root/USR/hiperARC/configs/Config-4.1.59 >leaf 937376 ./root/USR/hiperARC/configs/Config-4.2.89-1 >leaf 937377 ./root/USR/hiperARC/configs/Config-4.2.89-1-OSPF >leaf 937378 ./root/USR/hiperARC/configs/Config-4.2.89-1-RIPv2 >dir 833863 ./root/USR/hiperARC/Docs >leaf 756397 ./root/USR/hiperARC/Docs/ospf_chap.pdf >leaf 756398 ./root/USR/hiperARC/Docs/ospf_commands.pdf >Should I restore any of these (or plug the drive back in)? I don't >remember if those are CLI instructions or bulk configs. I probably wouldn't worry with it...basic OSPF setup instructions are in the new users guide that's available...all I did was follow that. I also has the 4.2.89 code at some point, and there's a few more commands to do now than you had to do with 4.2.89, so I'm not sure how much a .89 config would help. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I use balance loading which seems to run nice. Hiper Arc #1 owns odd dsp's while Hiper Arc #2 owns evens. Not sure how to do the fallover if one fails, would be interested in that config though if anyone has it. Brian Gordon Westelcom Internet administrator@westelcom.com ----- Original Message ----- Sent: Friday, July 16, 1999 7:23 AM > Hi all, I have just got my hands on our new Hiper gear. In each Chassis we > have two Arc's, four DSP's and one Hiper NMC. > I would like to check some ideas for best config for resilience that we > could achieve eg. Failover between the two arcs, which should own the DSP's, > IP pool assignments(can you have duplicates?) etc. I have been looking > through the documentation, but seeing as it is TCS 3.1 I thought there might > be some better options that can be done with the newer releases. The > knowledge base and interproc don't seem to be much help. > Thanks a lot, > Phil > > - > 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. >

On Thursday, July 15, 1999 4:50 PM, Ricky Beam [SMTP:jfbeam@bluetopia.net] wrote: > On Thu, 15 Jul 1999, Hostmaster Soho Solutions - Javier Szyszlican wrote: > >But I'm trying to cut costs for instaling a small pop... > >I am ok? > As I recall, the WAN ports use a standard Cisco V.35 cable. Yes, it works, it just doesn't work all that well. And it does take a Cisco v.35 cable. I guess it was sufficient for serving a single PRI span-worth of calls. If I remember correctly, it also doesn't do ANSI LMI. You will have to get your provider to set the LMI type to q933a which is not the typical standard as far as my provider was concerned. That would have been a huge gotcha if I hadn't known about it when I set the equipment up. Matt...

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |Sent: Thursday, July 15, 1999 9:45 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) tcs3.6 comments? | | |Hi, | | In regards to the frame relay implementation for V4.2.29 - does anybody |know exactly what hardware is needed? Can we use old T1/E1 cards that were |earlier in service to support Quad Modems? | | No. We have two frame-relay nics for the HARC. 1) Dual v.35 NIC + 10/100 Ether similar to the old Netserver NIC but not interchangable. 2) Quad T1 NIC + 10/100 Ether .. -M

Thus spake Michael DeMan > In regards to the frame relay implementation for V4.2.29 - does anybody >know exactly what hardware is needed? Can we use old T1/E1 cards that were >earlier in service to support Quad Modems? No...the wan ports refer to the ports on the new NICs available for the HiPer Arc. One with 2 v.35 ports and a 10/100, and one with 4 t1 ports (integrated csu/dsu's) and a 10/100. The wan ports would refer to the v.35 serial ports, and the logical serial ports on the 4 t1's (you channelize the t1's down how you want in the integrated csu/dsu and those channel groupings are presented to the Arc as a "logical" serial port. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Brian >Can you post the OSPF portion of your config? I would just want to do the >equivelent of like: >router ospf > network x.x.x.x mask 255.255.255.0 area 1 > redistribute connected subnets > redistribute static >I think I'll setup an ARC with no HDM's assigned just to see how it does >with OSPF as well. The basic OSPF config in the Product Reference manual (available in pdf on totalservice) will do pretty much what you want...you might need to set up an OSPF sendpolicy or two which I haven't done yet to do the equivalent of redistribution. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

The problem doesn't seem to be totally random. That is some clients are prone to getting it while most never get it. Our syslog entries look like this: Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", Level "COMMON":: Port slot:2/mod:4 user ight session connected, call id 16974191, protocol: PPP - ip address: 0.0.0.0 Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", Level "COMMON":: Port slot:2/mod:4 user ight session disconnected, call id 16974191, protocol: PPP - ip address 0.0.0.0 This particular user is running Windows 98 and is using a Winmodem LT. Any help would be appreciated. Thanks

Thus spake Phil Le Clercq >Hi all, I have just got my hands on our new Hiper gear. In each Chassis we >have two Arc's, four DSP's and one Hiper NMC. >I would like to check some ideas for best config for resilience that we >could achieve eg. Failover between the two arcs, which should own the DSP's, >IP pool assignments(can you have duplicates?) etc. I have been looking >through the documentation, but seeing as it is TCS 3.1 I thought there might >be some better options that can be done with the newer releases. The >knowledge base and interproc don't seem to be much help. The automated way to do this is with nmc chassis awareness, dynamic slot assignment and dsa idle rebalancing...but I'm not sure you'll be happy with the robustness and failover speed...I was pretty underwhelmed when I was playing with it. On the Arcs...make sure neither are set as owners of any of the cards, then do the following on both: enable nmc chassis_awareness enable nmc dynamic_slot_assignment enable nmc dsa_idle_rebalancing Then go have lunch...when you get back, the Arc's (with the help of the NMC) should have worked out who controls what modem cards. If one of the Arcs fails...if you can sit on your hands for long enough, the other Arc should pick up the modem assignments. As far as IP pool assignment...the best way I can think of to get this to work with the above setup is to set each Arc with two ip pools and set: disable ip address_pool_round_robin Then set the first arc with pool 1 first, pool 2 second, and the second arc with pool 2 first and pool 1 second. Again...I haven't tested all this out thoroughly...specifically not the ip pool setup...but I have done a bit of playing with the chassis_awareness, dsa and dsa_idle_rebalancing...it worked...slowly (like 20 minutes for a failover), and not too terribly robustly. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 16 Jul 1999, Jeff Mcadams wrote: >>router ospf >> network x.x.x.x mask 255.255.255.0 area 1 >> redistribute connected subnets >> redistribute static > >The basic OSPF config in the Product Reference manual (available in pdf >on totalservice) will do pretty much what you want...you might need to >set up an OSPF sendpolicy or two which I haven't done yet to do the >equivalent of redistribution. Unless 3Com changed things back, both static and connected networks should be advertised automatically. I had a round with them about that behavior. Static == duh. Connected == your dialup users (mega-duh.) --Ricky

Need to buy (1) USR/3COM CHASSIS PART # 80-003459-00 Description: TCH HiPer, Dual 130A AC, SNMP, Ethernet Need a working used one ASAP! please email me in private if you have one. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

Hi all, I have just got my hands on our new Hiper gear. In each Chassis we have two Arc's, four DSP's and one Hiper NMC. I would like to check some ideas for best config for resilience that we could achieve eg. Failover between the two arcs, which should own the DSP's, IP pool assignments(can you have duplicates?) etc. I have been looking through the documentation, but seeing as it is TCS 3.1 I thought there might be some better options that can be done with the newer releases. The knowledge base and interproc don't seem to be much help. Thanks a lot, Phil

Thus spake Ricky Beam >On Fri, 16 Jul 1999, Jeff Mcadams wrote: >>>router ospf >>> network x.x.x.x mask 255.255.255.0 area 1 >>> redistribute connected subnets >>> redistribute static >>The basic OSPF config in the Product Reference manual (available in pdf >>on totalservice) will do pretty much what you want...you might need to >>set up an OSPF sendpolicy or two which I haven't done yet to do the >>equivalent of redistribution. >Unless 3Com changed things back, both static and connected networks should >be advertised automatically. I had a round with them about that behavior. >Static == duh. >Connected == your dialup users (mega-duh.) I haven't checked this out thoroughly, but it didn't *seem* to do so...I had eth:1 set up for our backbone network and was running ospf on that interface...eth:2 was set up for our server network (in parallel with our 4700-M doing the same thing) and was set up with no routing protocol on it. The directly connected server network did not seem to be advertised into the OSPF domain by the Arc. So...if the Arc advertised addresses from PPP connections automatically, but not on a second ethernet port...there's some inconsistency there that I'd like to see resolved. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Ricky Beam >On Fri, 16 Jul 1999, Jeff Mcadams wrote: >>>router ospf >>> network x.x.x.x mask 255.255.255.0 area 1 >>> redistribute connected subnets >>> redistribute static >>The basic OSPF config in the Product Reference manual (available in pdf >>on totalservice) will do pretty much what you want...you might need to >>set up an OSPF sendpolicy or two which I haven't done yet to do the >>equivalent of redistribution. >Unless 3Com changed things back, both static and connected networks should >be advertised automatically. I had a round with them about that behavior. >Static == duh. >Connected == your dialup users (mega-duh.) I haven't checked this out thoroughly, but it didn't *seem* to do so...I had eth:1 set up for our backbone network and was running ospf on that interface...eth:2 was set up for our server network (in parallel with our 4700-M doing the same thing) and was set up with no routing protocol on it. The directly connected server network did not seem to be advertised into the OSPF domain by the Arc. So...if the Arc advertised addresses from PPP connections automatically, but not on a second ethernet port...there's some inconsistency there that I'd like to see resolved. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

You can set the user definitions either locally or via radius to send that sessions routes into the OSPF domain. To do this, set the users routing protocol to OSPD and his routing to SEND. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Friday, July 16, 1999 12:28 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) tcs3.6 comments? | | |Thus spake Ricky Beam |>On Fri, 16 Jul 1999, Jeff Mcadams wrote: |>>So...if the Arc advertised addresses from PPP connections automatically, |>>but not on a second ethernet port...there's some inconsistency there |>>that I'd like to see resolved. | |>It would only be inconsistent if RIP behaved differently -- which was my |>original complaint (that and I didn't want to put 10,000 sendpolicies in |>there for customer LAN dialups.) | |Oh, bah...just put in a few that covers the range...from what I'm |reading, that should work. IgLou has a grand total of 5 routing |announcements globally...if I really wanted to be lazy I could just add |the 5 blocks that we have total to the sendpolicy and be done with it. |You don't have to match netmask length to match the send policy. |-- |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. |

Thus spake Jeff Mcadams >Thus spake Ricky Beam >>Unless 3Com changed things back, both static and connected networks >>should be advertised automatically. I had a round with them about >>that behavior. >>Static == duh. >>Connected == your dialup users (mega-duh.) >I haven't checked this out thoroughly, but it didn't *seem* to do >so...I had eth:1 set up for our backbone network and was running ospf >on that interface...eth:2 was set up for our server network (in >parallel with our 4700-M doing the same thing) and was set up with no >routing protocol on it. The directly connected server network did not >seem to be advertised into the OSPF domain by the Arc. I checked this out a bit more...at least wrt ethernet interfaces, static and directly connected routes are not automatically inserted into the OSPF domain. Honestly, this is how I would prefer it to be. :) I turned off OSPF on our server network (since nothing else on that network was running OSPF) and added a sendpolicy for it instead and it is being advertised and used...so the send policies do work as well. :) One thing that I would like to be able to change though is that the sendpolicy and receivepolicy only allow you to specify an 8 bit netmask or longer. While I don't have the need to use a 4-bit netmask or anything, I would like to be able to include a 0.0.0.0/0 specification in a (send|receive)policy so I could override defaults like this if necessary. Right now there doesn't seem to be a very easy way to work around the coded in defaults. Like I said...my personal preference in most situations would be to *not* automatically insert local and netmgr (static and connected) routes automatically into the OSPF domain...but I'd like to have the option to set up a policy that *does* do this if necessary. :) I can see in some places where I might want to do something along the lines of: reject 10/8, 172.16/12, 192.168/16 then accept 0/0 Currently I'm not sure how the Arc would handle overlapping definitions like that, and I'm relatively sure it wouldn't accept that accept entry because of the short netmask. Anyway...I see this as a pretty good start for OSPF and the ability to define policy on route definitions, but there's still quite a ways to go before its really ready for the big time IMHO. Oh, and that 3500 route limit to the size of the routing table is definitely gonna have to go bye-bye soon. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 16 Jul 1999, Jeff Mcadams wrote: >So...if the Arc advertised addresses from PPP connections automatically, >but not on a second ethernet port...there's some inconsistency there >that I'd like to see resolved. It would only be inconsistent if RIP behaved differently -- which was my original complaint (that and I didn't want to put 10,000 sendpolicies in there for customer LAN dialups.) --Ricky

On Fri, 16 Jul 1999, Jeff Mcadams wrote: >Like I said...my personal preference in most situations would be to >*not* automatically insert local and netmgr (static and connected) >routes automatically into the OSPF domain...but I'd like to have the >option to set up a policy that *does* do this if necessary. :) And in about two weeks, you'll be complaining for a RADIUS attr to added dynamic OSPF send policies :-) >Oh, and that 3500 route limit to the size of the routing table is >definitely gonna have to go bye-bye soon. :) I bitched contantly for two weeks to get them to even say they hardcoded the lsdb size. It wasn't until a programmer was in the conference call that he (I think it was a he) laughed, "you cannot push 63,000 routes in there, it's only got room for 3000." At which point my head hit the desk. I was _told_ I'd be sent 4.2.89-6(?) that had been recompiled to support 80k entries, but they never sent it to me prior to my leaving Interpath. They obviously never changed the limits or (*shudder*) learned to dynamically allocate space for dynamically sized data. Moral: Don't try to put an OSPF enabled ARC in the core of your network. (If you do, the "CPU util" thread will be a moot point. [When it says 100%, it [censored] means it!]) --Ricky

Thus spake Ricky Beam >On Fri, 16 Jul 1999, Jeff Mcadams wrote: >>So...if the Arc advertised addresses from PPP connections automatically, >>but not on a second ethernet port...there's some inconsistency there >>that I'd like to see resolved. >It would only be inconsistent if RIP behaved differently -- which was my >original complaint (that and I didn't want to put 10,000 sendpolicies in >there for customer LAN dialups.) Oh, bah...just put in a few that covers the range...from what I'm reading, that should work. IgLou has a grand total of 5 routing announcements globally...if I really wanted to be lazy I could just add the 5 blocks that we have total to the sendpolicy and be done with it. You don't have to match netmask length to match the send policy. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Ricky Beam >On Fri, 16 Jul 1999, Jeff Mcadams wrote: >>Like I said...my personal preference in most situations would be to >>*not* automatically insert local and netmgr (static and connected) >>routes automatically into the OSPF domain...but I'd like to have the >>option to set up a policy that *does* do this if necessary. :) >And in about two weeks, you'll be complaining for a RADIUS attr to added >dynamic OSPF send policies :-) Oh, ick...no thanks...just like I have route-maps on my cisco's now, it'd be nice to have the sendpolicies (which seem intended to do largely the same thing) to be able to at least restrict a bit what is allowed to be sent. If you want to only allow the specific ones that are connected or whatever then I'd say you have the wrong idea of what the sendpolicies are intended to be. >>Oh, and that 3500 route limit to the size of the routing table is >>definitely gonna have to go bye-bye soon. :) >I bitched contantly for two weeks to get them to even say they hardcoded the >lsdb size. It wasn't until a programmer was in the conference call that >he (I think it was a he) laughed, "you cannot push 63,000 routes in there, >it's only got room for 3000." At which point my head hit the desk. I was >_told_ I'd be sent 4.2.89-6(?) that had been recompiled to support 80k >entries, but they never sent it to me prior to my leaving Interpath. They >obviously never changed the limits or (*shudder*) learned to dynamically >allocate space for dynamically sized data. Well...I wasn't really referring to the lsdb size limitation (though that could really be a problem as well), but the routing table itself is limited to 3500 routes...which I'm under the impression would be a problem regardless of if you're getting the routes via OSPF or some other method. Its just that OSPF is the only feasible way to get > 3500 routes in the table...it would roll over and die long before it got to 3500 RIP routes, and I know *I'm* certainly not manually inputing 3500 static routes :) (OK...I knew I wasn't dreaming this...its in the Release Notes) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 16 Jul 1999, Mike Wronski wrote: >You can set the user definitions either locally or via radius to send that >sessions routes into the OSPF domain. >To do this, set the users routing protocol to OSPD and his routing to SEND. Umm, by definition, that would _send the customer_ OSPF data as well. And there goes any chance in [bleep] of the line ever being idle :-) --Ricky

On Fri, 16 Jul 1999, Jeff Mcadams wrote: >>It would only be inconsistent if RIP behaved differently -- which was my >>original complaint (that and I didn't want to put 10,000 sendpolicies in >>there for customer LAN dialups.) > >Oh, bah...just put in a few that covers the range...from what I'm >reading, that should work. IgLou has a grand total of 5 routing >announcements globally...if I really wanted to be lazy I could just add >the 5 blocks that we have total to the sendpolicy and be done with it. >You don't have to match netmask length to match the send policy. I did that at first, but that's way too messy in the long run. Maybe not for you, but... Anyway, my main complaint was about the thing not advertizing it's dialup connections by default (which it did with RIP) which is just a stupid idea. What's the point of a dialup "router" that you have to beat into submission to get it to tell others who's connected? That is the entire point of the NAS... 99.99975% of the time, you'll want everyone to know Bob is logged in on NAS-foo. The only time that it makes any sense at all to not announce is where you shouldn't have any routing protocol active anyway. (I can paint an example where you'd want some connections hidden, but it's a Bad Idea (tm) to do something like that.) But we're getting off topic... back to that [censored] 3500 entry lsdb limit. --Ricky

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Friday, July 16, 1999 12:45 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) tcs3.6 comments? | | |On Fri, 16 Jul 1999, Mike Wronski wrote: |>You can set the user definitions either locally or via radius to send that |>sessions routes into the OSPF domain. |>To do this, set the users routing protocol to OSPD and his routing to SEND. | |Umm, by definition, that would _send the customer_ OSPF data as well. |And there goes any chance in [bleep] of the line ever being idle :-) Um NO. LISTEN would send the customer OSPF data. SEND only injects the dial users /32 route or network route if its LAN-2-LAN. -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Friday, July 16, 1999 1:03 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) tcs3.6 comments? | | |On Fri, 16 Jul 1999, Jeff Mcadams wrote: |>>It would only be inconsistent if RIP behaved differently -- which was my |>>original complaint (that and I didn't want to put 10,000 sendpolicies in |>>there for customer LAN dialups.) |> |>Oh, bah...just put in a few that covers the range...from what I'm |>reading, that should work. IgLou has a grand total of 5 routing |>announcements globally...if I really wanted to be lazy I could just add |>the 5 blocks that we have total to the sendpolicy and be done with it. |>You don't have to match netmask length to match the send policy. | |I did that at first, but that's way too messy in the long run. Maybe not |for you, but... | |Anyway, my main complaint was about the thing not advertizing it's dialup |connections by default (which it did with RIP) which is just a stupid idea. |What's the point of a dialup "router" that you have to beat into submission |to get it to tell others who's connected? That is the entire point of the |NAS... 99.99975% of the time, you'll want everyone to know Bob is logged |in on NAS-foo. The only time that it makes any sense at all to not announce |is where you shouldn't have any routing protocol active anyway. (I can paint |an example where you'd want some connections hidden, but it's a Bad Idea (tm) |to do something like that.) | |But we're getting off topic... back to that [censored] 3500 entry lsdb limit. | There is no 3500 limit to lsdb entries. The limit is in the routing/forwarding table.. And I would have to agree 3500 a problem. -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Friday, July 16, 1999 2:42 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) tcs3.6 comments? | | |On Fri, 16 Jul 1999, Mike Wronski wrote: |>Um NO. LISTEN would send the customer OSPF data. SEND only injects the |dial users |>/32 route or network route if its LAN-2-LAN. | |That's not what the RFC says... of course, you guys don't pay those things |a whole lot of attention anyway :-) | What RFC states that setting a users routing type to SEND mean that they will also LISTEN? -M

On Fri, 16 Jul 1999, Mike Wronski wrote: >Um NO. LISTEN would send the customer OSPF data. SEND only injects the dial users >/32 route or network route if its LAN-2-LAN. That's not what the RFC says... of course, you guys don't pay those things a whole lot of attention anyway :-) --Ricky

The problem doesn't seem to be totally random. That is some clients are prone to getting it while most never get it. Our syslog entries look like this: Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", Level "COMMON":: Port slot:2/mod:4 user ight session connected, call id 16974191, protocol: PPP - ip address: 0.0.0.0 Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", Level "COMMON":: Port slot:2/mod:4 user ight session disconnected, call id 16974191, protocol: PPP - ip address 0.0.0.0 This particular user is running Windows 98 and is using a Winmodem LT. Any help would be appreciated. Thanks

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Friday, July 16, 1999 3:59 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) tcs3.6 comments? | | |On Fri, 16 Jul 1999, Mike Wronski wrote: |>What RFC states that setting a users routing type to SEND mean that they will |>also LISTEN? | |I'll get back to ya' -- I've got some fingers to go break... [long bleep] | |"SEND" only says send routing stuff to thise connection. It doesn't say the |NAS is supposed to listen as well (in fact "SEND" only means just that.) And |no, there isn't any stone tablet that says the thing on the otherside MUST |be listening. I can set the thing to send me RIP routes but that doesn't |mean I have to listen to them. | The problem here is that you are confused as to the direction or what the SEND is in respect to. On the HARC SEND means "Send routing information from the user into the LAN" LISTEN means "SEND LAN routing information to the USER". So with respect to OSPF. No OSPF data will be sent to the user if the config I suggested is used. Idle-timeout will work fine. -M

On Fri, 16 Jul 1999, Mike Wronski wrote: >What RFC states that setting a users routing type to SEND mean that they will >also LISTEN? I'll get back to ya' -- I've got some fingers to go break... [long bleep] "SEND" only says send routing stuff to thise connection. It doesn't say the NAS is supposed to listen as well (in fact "SEND" only means just that.) And no, there isn't any stone tablet that says the thing on the otherside MUST be listening. I can set the thing to send me RIP routes but that doesn't mean I have to listen to them. --Ricky

On Fri, 16 Jul 1999, Bryan Wann wrote: > Hi all, > > I've got a HiPer chassis here where the 'Hub Stat' LED on the NMC > card stays red continously. I've read through the docs, which tell me I had something similar which turned out to be a fan failure. Try running SNMP alarm manager, verify it works, and reboot the NMC. I think the only time the NMC sends the fan failure trap is when it boots.

At 08:06 AM 7/16/99 -0400, Jeff Mcadams wrote: >Thus spake K Mitchell >>Anybody care to share other helpful oid's...connection speeds,etc? > >mdmCsFinalTxLinkRate >.1.3.6.1.4.1.429.1.6.9.1.1.12.<entitynum> Have a sample mrtg.cfg entry? I'm trying to picture how this type of data(transmit speeds, users, etc) would get presented by MRTG, and drawing a blank. Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

I don't think it makes much sense to graph connect speeds with MRTG... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate." On Fri, 16 Jul 1999, K Mitchell wrote: > At 08:06 AM 7/16/99 -0400, Jeff Mcadams wrote: > >Thus spake K Mitchell > >>Anybody care to share other helpful oid's...connection speeds,etc? > > > >mdmCsFinalTxLinkRate > >.1.3.6.1.4.1.429.1.6.9.1.1.12.<entitynum> > > Have a sample mrtg.cfg entry? I'm trying to picture how this type of > data(transmit speeds, users, etc) would get presented by MRTG, and drawing > a blank. > > Thanks, > Kirk > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > 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 all, I've got a HiPer chassis here where the 'Hub Stat' LED on the NMC card stays red continously. I've read through the docs, which tell me that this is a critical hardware problem and to call 3com support. The thing is, the chassis has been up and functioning, taking calls for the past 6 months like this. I never paid it much attention to it until I went to upgrade DSP and ARC code (out of sight, out of mind) a couple of weeks ago, and TCM immediately told me the downloads fail. Using a packet sniffer I can see no packets are being sent to the chassis at this point, so I am assuming TCM is halting because of this error condition on the NMC. 2 days ago, the ARC started acting up, and would not hold its flash. (This was called into 3com today, spare is in place now, old one is being shipped in for repairs). Had not touched the chassis before this, it just flat out folded one afternoon. The console would show the "boot prom" message, "loading kernel.. ok", then reboot over and over. first tried reseating the nic/nacs, moved to different slots, no good. Been here done this, so did a AT{Z} upload of 4.1.59-6. After the upload was finished, the card would reboot, get to the same spot (boot prom, loading kernel..ok) as before and reboot. After about the 4th zmodem upload, it finally got me to the boot options screen, tell me loading from flash failed, need to download. At that point I tried to tftp the image (hi jeff), and the sucker would reboot during the download. Had it set to tftp once, but it got to where it would tftp, reboot, tftp, reboot, etc. Left it going like this all night while I fetched a spare. The next morning, tftp appeared to finally worked, got the HiPer>> prompt. Started plugging in our config via CLI, 6 lines in, the sucker reboots again. Eventually got a spare ARC to replace this one, and all is well. Called into 3com today, they agreed the ARC was probably flakey, and it is being shipped back to get examined/fixed/repaired/run-over/etc. Even with the new ARC card in the chassis, the 'Hub stat' LED on the NMC is still on! Looking at the NMC via TCM, Performance -> Status Group shows no errors, everything is OK. Performance -> Failure Reasons shows no failures. The ARC status shows no errors. Tried reseating the front/back of the NMC, the ARC, and the DSPs, the 'Hub stat' is still solid red. Chassis takes calls without missing a beat. NMC is running v 5.6.2, old ARC had 4.1.72-7 (I think?), the current ARC is running 4.1.11. Haven't had a chance to go back and upgrade the ARC yet. Is the NMC crying wolf, or is there something still wrong with the chassis that I'm not looking at? Is it a possiblity that conditions exist that may set me up to fry another ARC that the 'Hub stat' LED is trying to tell me? Suggestions? --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net

> I've got a HiPer chassis here where the 'Hub Stat' LED on the NMC > card stays red continously. I've read through the docs, which tell me > that this is a critical hardware problem and to call 3com support. The > thing is, the chassis has been up and functioning, taking calls for the > past 6 months like this. With the latest NMC code, and TCM, you can go into the performance monitor for the NMC, and there is now an option telling you why the RED light is on, where in the past you had to just guess. Might want to have a look. -- | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Senior Vice President - Exec-PC, Inc. - A Voyager.net company |

On Fri, 16 Jul 1999, Bryan Wann wrote: > I've got a HiPer chassis here where the 'Hub Stat' LED on the NMC > card stays red continously. I've read through the docs, which tell me > that this is a critical hardware problem and to call 3com support. The > thing is, the chassis has been up and functioning, taking calls for the > past 6 months like this. Ok, duh, I think I may have answered this. A couple of people e-mailed me privately that it may be chassis temp, and flipping through list archives a couple of issues point at this. Chassis is holding at 28 degrees (c). Will have to see if increasing spacing causes any change. And I thought my cisco AGS+ was the only thing picky about air flow. :) --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net

On Fri, 16 Jul 1999, Curt Shambeau wrote: > With the latest NMC code, and TCM, you can go into the performance monitor > for the NMC, and there is now an option telling you why the RED light is > on, where in the past you had to just guess. Is is possible to see the reason why a Quad comes up run/fail? ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

At 11:41 PM 7/16/99 -0500, Bryan Wann wrote: > Ok, duh, I think I may have answered this. A couple of people >e-mailed me privately that it may be chassis temp, and flipping through >list archives a couple of issues point at this. Chassis is holding at 28 >degrees (c). Will have to see if increasing spacing causes any change. Since I started monitoring it a couple of days ago, the temp of my chassis has varied from 24 to a high of 32 degrees, usually hanging at 27-28. My NMC hasn't displayed a red(or yellow) LED at all in that time. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

On Fri, 16 Jul 1999, Ricky Beam wrote: > On Fri, 16 Jul 1999, Jeff Mcadams wrote: > >>router ospf > >> network x.x.x.x mask 255.255.255.0 area 1 > >> redistribute connected subnets > >> redistribute static > > > >The basic OSPF config in the Product Reference manual (available in pdf > >on totalservice) will do pretty much what you want...you might need to > >set up an OSPF sendpolicy or two which I haven't done yet to do the > >equivalent of redistribution. > > Unless 3Com changed things back, both static and connected networks should > be advertised automatically. I had a round with them about that behavior. > > Static == duh. > Connected == your dialup users (mega-duh.) ok cool, it would make sense :) > > --Ricky > > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake Bryan Wann >On Fri, 16 Jul 1999, Bryan Wann wrote: >> I've got a HiPer chassis here where the 'Hub Stat' LED on the NMC >> card stays red continously. I've read through the docs, which tell me >> that this is a critical hardware problem and to call 3com support. The >> thing is, the chassis has been up and functioning, taking calls for the >> past 6 months like this. > Ok, duh, I think I may have answered this. A couple of people >e-mailed me privately that it may be chassis temp, and flipping through >list archives a couple of issues point at this. Chassis is holding at 28 >degrees (c). Will have to see if increasing spacing causes any change. Nope...I've got a chassis that regularly sits at 33c...don't think 30 is gonna make it go red. :) Only time I've had a red hub stat that stayed for a long time was a failed/failing fan. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jeff Mcadams >Nope...I've got a chassis that regularly sits at 33c...don't think 30 is >gonna make it go red. :) >Only time I've had a red hub stat that stayed for a long time was a >failed/failing fan. *Now* I find this information...making me do a follow-up to my own post...sheesh... snmpwalk the uchasEnvironTable to get the number of warnings and failures for the fans (I believe this includes both power supply fans and fan tray fans) and temperature, so if its one of those, that will let you know which... .1.3.6.1.4.1.429.1.1.5.1 -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 16 Jul 1999, Bryan Wann wrote: > 2 days ago, the ARC started acting up, and would not hold its >flash. (This was called into 3com today, spare is in place now, old one "These things happen." Did you try a AT{ZF}? (Flash memory does go bad eventually. One would assume 3Com QC would have some that lasts longer than 5 rewrites *grin*) > Even with the new ARC card in the chassis, the 'Hub stat' LED on >the NMC is still on! Looking at the NMC via TCM, Performance -> Status ... There are lots of things that will make the stat light red. Only a very small set of those can be found with TCM. The only way to know it to look for the RADIUS accounting packet from it after it reboots. Depending on your RADIUS setup, it may not log anything at all useful. (That's why I rewrote my RADIUS stuff.) I have seen the same thing a few times before. In one case, there was cable jacketing that had jammed one of the fans... mystery solved. (I wasn't going to drive to Wilmington to see why the other one was doing this.) --Ricky

On Fri, 16 Jul 1999, Bryan Wann wrote: > Ok, duh, I think I may have answered this. A couple of people >e-mailed me privately that it may be chassis temp, and flipping through >list archives a couple of issues point at this. Chassis is holding at 28 >degrees (c). Will have to see if increasing spacing causes any change. Maybe some at 3Com (earth to Wronski...) will post the thermal limits for the TC hardware. I once saw informtion saying 55dC or 85dC as it' max. thermal limit. (Much over 100dC and surface mount componants start falling off :-)) As a point of reference, I've seen to perfectly functional (all green) chassis's running in 100dF rooms -- the NMC registered from 38dC to 40dC. (Yes, I watched them both closely for a week with TCM, RADIUS, and SNMP alarms.) --Ricky

We've been getting people with a new PCI USR Modem, the US Robotics 56K Voice Win RS I believe. These things connect horribly to our HiPer and PM3. I've tried many settings, no luck. I'm running V4.1.59 on the Arc 1.2.43 on the DSP cards with T1s. Anyone else experiencing this?

I upgraded the last ARC in our dialup pool to 4.2.29 today and turned OSPF on, and found that suddenly nobody could authenticate anymore. All my Radius server settings, and some of the auth-related PPP settings, got nuked. Radius accounting server settings were still there though. Anyone else seen this, or does everyone just nuke and re-enter their config every time they do an upgrade? (Kinda hard to do exactly if you don't write down every config command you enter every time...) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org "If you're not part of the solution.... you're part of the precipitate."

On Fri, 16 Jul 1999, Kelly Peterson wrote: > The problem doesn't seem to be totally random. That is some clients are > prone to getting it while most never get it. Our syslog entries look like > this: > > Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", > Level "COMMON":: Port slot:2/mod:4 user ight session connected, call id > 16974191, protocol: PPP - ip address: 0.0.0.0 > Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", > Level "COMMON":: Port slot:2/mod:4 user ight session disconnected, call id > 16974191, protocol: PPP - ip address 0.0.0.0 This information that you see in syslog show up if you have hint assigned enabled and that if the user is disconnected due to some ppp/modem problem. If you take a look above the user is connected and disconnected at the same second. The reason here is hint assigned is suppossed to give a ip address to radius and radius should use it, but this is also used to send a ppp message to the user. Now if the user is not connectected no ip address is hinted to radius thus you see the above message in syslog. There is no way that this user gets 0.0.0.0 - this info tells you that the user did not get connected - thus we did not assign any ip address. krish > > This particular user is running Windows 98 and is using a Winmodem LT. > > Any help would be appreciated. > > 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. >

On Fri, 16 Jul 1999, Kelly Peterson wrote: > The problem doesn't seem to be totally random. That is some clients are > prone to getting it while most never get it. Our syslog entries look like > this: > > Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", > Level "COMMON":: Port slot:2/mod:4 user ight session connected, call id > 16974191, protocol: PPP - ip address: 0.0.0.0 > Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", > Level "COMMON":: Port slot:2/mod:4 user ight session disconnected, call id > 16974191, protocol: PPP - ip address 0.0.0.0 This information that you see in syslog show up if you have hint assigned enabled and that if the user is disconnected due to some ppp/modem problem. If you take a look above the user is connected and disconnected at the same second. The reason here is hint assigned is suppossed to give a ip address to radius and radius should use it, but this is also used to send a ppp message to the user. Now if the user is not connectected no ip address is hinted to radius thus you see the above message in syslog. There is no way that this user gets 0.0.0.0 - this info tells you that the user did not get connected - thus we did not assign any ip address. krish > > This particular user is running Windows 98 and is using a Winmodem LT. > > Any help would be appreciated. > > 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. >

On Sat, 17 Jul 1999, Ricky Beam wrote: > On Fri, 16 Jul 1999, Bryan Wann wrote: > > Ok, duh, I think I may have answered this. A couple of people > >e-mailed me privately that it may be chassis temp, and flipping through > >list archives a couple of issues point at this. Chassis is holding at 28 > >degrees (c). Will have to see if increasing spacing causes any change. > > Maybe some at 3Com (earth to Wronski...) will post the thermal limits for > the TC hardware. I once saw informtion saying 55dC or 85dC as it' max. > thermal limit. (Much over 100dC and surface mount componants start > falling off :-)) > 40dC is the max - We recommend the chassis to be kept and less than 40dC. krish > As a point of reference, I've seen to perfectly functional (all green) > chassis's running in 100dF rooms -- the NMC registered from 38dC to 40dC. > (Yes, I watched them both closely for a week with TCM, RADIUS, and SNMP > alarms.) > > --Ricky > > > > - > 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. >

On 17 Jul 1999 zip-usrtc@ran.zipcon.net wrote: > > We've been getting people with a new PCI USR Modem, the US Robotics 56K > Voice Win RS I believe. These things connect horribly to our HiPer and > PM3. I've tried many settings, no luck. I'm running V4.1.59 on the Arc > 1.2.43 on the DSP cards with T1s. Anyone else experiencing this? First of all you may want to upgrade the DSP to 2.0.81 Service release (Available at http://totalservice.usr.com). That should solve many of the winmodem problems. If you still have problems do open a ticket with 3com and we can get it fixed. krish > > > - > 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. >

On 17 Jul 1999 zip-usrtc@ran.zipcon.net wrote: > > We've been getting people with a new PCI USR Modem, the US Robotics 56K > Voice Win RS I believe. These things connect horribly to our HiPer and > PM3. I've tried many settings, no luck. I'm running V4.1.59 on the Arc > 1.2.43 on the DSP cards with T1s. Anyone else experiencing this? First of all you may want to upgrade the DSP to 2.0.81 Service release (Available at http://totalservice.usr.com). That should solve many of the winmodem problems. If you still have problems do open a ticket with 3com and we can get it fixed. krish > > > - > 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. >

At 02:05 PM 7/17/99 -0700, you wrote: > > We've been getting people with a new PCI USR Modem, the US Robotics 56K >Voice Win RS I believe. These things connect horribly to our HiPer and >PM3. I've tried many settings, no luck. I'm running V4.1.59 on the Arc >1.2.43 on the DSP cards with T1s. Anyone else experiencing this? Have you made sure it's running the newest available drivers? New doesn't necessarily mean that it hasn't been sitting on a shelf somewhere for a few months :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Hi All, I am running quite a few HyperDSP cards on E1's here in Australia, and I am finding V90 on them is un-acceptably unstable. 5% of all calls connecting to these cards drop out in less than 1 minute. I Have tried Quad cards and they seem alot more stable, has anyone else found this? I am running 14 cards on one chassis with one HyperARC, is there any chance I need another HyperARC? I dont do any Multi PPP processing. I am running version 2.0.19 of the DSP firmware and 4.1.59 of the hyperARC firmware. All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. -----Original Message-----

Hello, I was reading through the archives and found this. Could someone elaborate on this? Is the "Jitter Attenuation" for PRI or Channelized? Irrelevant? What is a "loop-timed application? Thank you, blake > -----Original Message----- > From: Aaron Nabil [mailto:nabil@spiritone.com] > Sent: Thursday, February 11, 1999 7:10 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) DSP problems > > > Pete Ashdown writes... > >Aaron Nabil said once upon a time: > >> > >>David Bolen writes... > >>> . . . > >>>The original HDM code (not sure if only beta or the first > production > >>>round) had some issues with selective reject and it got disabled by > >>>default in the configuration - not sure why that hasn't > been changed, > >>>but maybe its only to stay compatible with earlier releases. > >> > >>The hiperdsp jitter attenuation default is also wrong, 3com knows > >>this, but hasn't fixed it. So I'm guessing that it's something more > >>substantial than just a minor tweak to fix. Maybe something to do > >>with compatibility with the stored configuration. > > > >What should this be set to? > > AttenJitterOnRcvr for loop-timed applications. > > > -- > Aaron Nabil > > - > 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. >

http://808hi.com/56k/latest.htm - 56k=v.Unreliable Latest Updates - 3Com modem woes. NEW to the site: 56k Modem owner surveys especially for 3Com modem owners. Ongoing surveys for Lucent LT Win Modem & Rockwell/Conexant HCF indicate around 40% of 56k owners aren't getting 56k - & what rates are being achieved: http://808hi.com/56k/56survey.htm NEW to the site: Lucent LT Win Modem firmware version 5.53 - early reports indicate connectivity improvements for some users. http://808hi.com/56k/ltwin.htm Aloha, Richard http://808hi.com/56k/ 56k=v.Unreliable *** 56k=v.Unreliable is now Y3K-compatible! *** NOTE - my site is copyrighted; many ISP help pages link to one or more of my pages - no permission is needed to do this; however, if you want to COPY info & place on your site, you need to get my permission. Thanks.

Over the past months we have used MRTG to monitor the number of modems in use via MIBs. Recently I notice the numebr was higher than the number of modems that were actually in use. In looking at the HiPerArc and doing a "li sess" I see where we have 15 sessions to the !root user and all via LAN Telnet login. How can we kill these sessions without booting the HiPerArc. A "disc user !root" doesn't seem to make a difference. Thanks in advance, Jeff Binkley ASA Network Computing

I don't believe you can kick them off w/o rebooting. We had the same problem 2 yrs ago. We had to reboot. Also, make sure you close the telnet sessions before killing your telnet client. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley Sent: Monday, July 19, 1999 7:43 Over the past months we have used MRTG to monitor the number of modems in use via MIBs. Recently I notice the numebr was higher than the number of modems that were actually in use. In looking at the HiPerArc and doing a "li sess" I see where we have 15 sessions to the !root user and all via LAN Telnet login. How can we kill these sessions without booting the HiPerArc. A "disc user !root" doesn't seem to make a difference. Thanks in advance, Jeff Binkley ASA Network Computing - 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.

Yow, I'm beginning to regret opening my big mouth. Blake Fithen writes... >Hello, I was reading through the archives and found this. >Could someone elaborate on this? Is the "Jitter Attenuation" >for PRI or Channelized? Both. >Irrelevant? No. >What is a "loop-timed application? Short answer: What you've got. Only slightly longer answer: When the customer equipment gets it's transmit timing by watching the timing coming in from the telco. >Thank you, blake > >> -----Original Message----- >> From: Aaron Nabil [mailto:nabil@spiritone.com] >> Sent: Thursday, February 11, 1999 7:10 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) DSP problems >> >> >> Pete Ashdown writes... >> >Aaron Nabil said once upon a time: >> >> >> >>David Bolen writes... >> >>> . . . >> >>>The original HDM code (not sure if only beta or the first >> production >> >>>round) had some issues with selective reject and it got disabled by >> >>>default in the configuration - not sure why that hasn't >> been changed, >> >>>but maybe its only to stay compatible with earlier releases. >> >> >> >>The hiperdsp jitter attenuation default is also wrong, 3com knows >> >>this, but hasn't fixed it. So I'm guessing that it's something more >> >>substantial than just a minor tweak to fix. Maybe something to do >> >>with compatibility with the stored configuration. >> > >> >What should this be set to? >> >> AttenJitterOnRcvr for loop-timed applications. >> >> >> -- >> Aaron Nabil >> -- Aaron Nabil

us7a> _sh ver V4.2.29 - 1 I can't seem to get the acc maps to do anything. us7a> set net user default ppp receive_acc_map deadbeef The arc still accepts any map from the client, including 0, and won't try to negotiate anything more restrictive. us7a> set net user default ppp transmit_acc_map b00bf00d The arc still opens the negotiation with ASYNC_MAP 00 00 00 00. I'm really only interested in setting the receive map, but tested the transmit as well just to make sure they weren't reversed in the code. I'm assuming these take affect instantly, yes? No need to save/reboot, right? us7a> show user default (...) PARAMETERS for NETWORK PPP USERS Max Channels 2 Channel Decrement Percent: 0 Channel Expansion Percent: 0 Expansion Algorithm: CONSTANT Receive ACC Map: deadbeef Transmit ACC Map: b00bf00d Compression Algorithm: NONE Compression Reset Mode: AUTO Min Compression Size: 256 Encryption Algorithm: NONE Primary DNS Server: 205.139.108.2 Secondary DNS Server: 205.139.108.3 Periodic CHAP Timeout: 0 Source Ip Address Filter: ENABLED -- Aaron Nabil

Thus spake Jason Cropper >I don't believe you can kick them off w/o rebooting. We had the same >problem 2 yrs ago. We had to reboot. Also, make sure you close the >telnet sessions before killing your telnet client. Setting an idle timeout on the management command line could help too. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Ricky et.al I'm pretty certain that the NMC won't complain under 43-45dC, which is also considered nominal based on the technical specs of the TCH. Anything above 65dC is above nominal, and the system should be shutdown. So basically, your max. operating temp, should be between 45-65dC and at 45, its cause for alarm.. Regards - Jase. ----- Original Message ----- Sent: Sunday, July 18, 1999 2:00 AM > On Fri, 16 Jul 1999, Bryan Wann wrote: > > Ok, duh, I think I may have answered this. A couple of people > >e-mailed me privately that it may be chassis temp, and flipping through > >list archives a couple of issues point at this. Chassis is holding at 28 > >degrees (c). Will have to see if increasing spacing causes any change. > > Maybe some at 3Com (earth to Wronski...) will post the thermal limits for > the TC hardware. I once saw informtion saying 55dC or 85dC as it' max. > thermal limit. (Much over 100dC and surface mount componants start > falling off :-)) > > As a point of reference, I've seen to perfectly functional (all green) > chassis's running in 100dF rooms -- the NMC registered from 38dC to 40dC. > (Yes, I watched them both closely for a week with TCM, RADIUS, and SNMP > alarms.) > > --Ricky > > > > - > 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.

On Mon, 19 Jul 1999, Jason Kelton wrote: >So basically, your max. operating temp, should be between 45-65dC and at 45, >its cause for alarm.. if it's 45dC, then you wouldn't want to be in the room for very long :-) --Ricky

some, only some of my hipers are giving ... Jul 19 15:27:57 auth03 radius[6400]: accounting: client xxx.yyy.zz.205/1646 sent accounting-request with invalid request authenticator Jul 19 15:27:58 auth03 radius[6400]: accounting: client xxx.yyy.zz.201/1646 sent accounting-request with invalid request authenticator ad nauseum at 20/second or so. now, I have set accounting secrets, but getting the hiper to tell me what I have set, is obtuse (read, I have no idea where) I did exactly the same as I did for another server and it was happy, is this a known hiperarc version problem? and subject 2, latest dictionary for hiperarc radius accounting lives where? Im seeing new attributes that didnt previously exist showing up. P -- My words, my mail, my meaning.

-> Thus spake Jason Cropper -> >I don't believe you can kick them off w/o rebooting. We had the same -> >problem 2 yrs ago. We had to reboot. Also, make sure you close the -> >telnet sessions before killing your telnet client. -> -> Setting an idle timeout on the management command line could help too. Ok, what is the command for that ? I find it somewhat disappointing that a reboot is the only option. Jeff Binkley ASA Network Computing

Thus spake Jeff Binkley >-> Thus spake Jason Cropper >-> >I don't believe you can kick them off w/o rebooting. We had the same >-> >problem 2 yrs ago. We had to reboot. Also, make sure you close the >-> >telnet sessions before killing your telnet client. >-> >-> Setting an idle timeout on the management command line could help too. >Ok, what is the command for that ? I find it somewhat disappointing that >a reboot is the only option. set command idle_timeout x where is x is measured in minutes. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

OK...long one here...first the tap on the user...some stripped to make it not so long... They've bounced back and forth on what IP address to use for the Netopia (configured wrong...this isn't the problem I'm reporting here) and can't agree...the Netopia wants to be C0 A8 00 FE (192.168.0.254), we want them to be CC FF EB 1B (204.255.235.27) Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 IN: 11: 80 21 01 05 00 10 03 06 C0 A8 00 FE 02 06 00 2D Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 IN: 11: 0F 00 They request the RFC1918 space. Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 OUT: 12: FF 03 80 21 03 05 00 0A 03 06 CC FF EB 1B We NAK it (this cycle has happened several times already...snipped) Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 IN: 13: 80 21 01 06 00 10 03 06 C0 A8 00 FE 02 06 00 2D Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 IN: 13: 0F 00 They request RFC1918 space again. Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 OUT: 14: FF 03 80 21 04 06 00 0A 03 06 CC FF EB 1B We Conf-Rej it this time....no real problem here. Jul 19 15:37:24 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 OUT: 15: FF 03 C0 21 05 03 00 00 ^^^^^ But then...immediately an LCP Term-Req? This seems a bit drastic...but not really a bug...I'd like to see this changed...but can live with it not. The real problem is the highlighted bytes...which are the length field for the packet. 0 is definitely not the length of the packet. :) For this reason, the Netopia seems to silently discard the packet (should it do this? eh...that would be up for discussion...the RFC's indicate it should, but the principle of "Be conservative in what you send, liberal in what you accept would indicate otherwise"). Jul 19 15:37:26 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 IN: 16: 80 21 01 07 00 0A 02 06 00 2D 0F 00 So the Netopia sends a new IPCP Conf-Req...honoring the Conf-Rej and not including the RFC1918 space...this is the opportunity to negotiate the right address...but because the Arc was already shutting down LCP it can't do it here (and again...the Netopia would probably be if the length field weren't bogus). Jul 19 15:37:27 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 OUT: 17: FF 03 C0 21 05 04 00 00 06 CC FF EE 03 05 06 00 Jul 19 15:37:27 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 OUT: 17: 00 04 04 2C 07 36 34 31 30 32 1A 0E 00 00 01 AD (rest of packet 17 snipped for reasons that will be clear in a minute) Here's another potentially serious problem...the Arc sends out another Term-Req...again, with the length field wrong. This time...rather than being the tiny little packet it sent out the first time...its a 520 byte packet or so...and the packet contains seemingly random data...upon further inspection though....it seems to be packet data...other traces that I have in my log file have snippets of HTTP GET requests. One has a couple of phone numbers...one of which would be the DNIS number...I can only assume the other isI can only assume the other is an ANI number for someone else on the box...Obviously, the potential is there for some seriously sensitive information to get sent to someone that shouldn't have it. (At this point, the Netopia tries IPCP a few more times having discarded both LCP Term-Req's because they had invalid length fields) Jul 19 15:37:53 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 IN: 28: FF 03 C0 21 05 06 00 04 Now, the Netopia finally gives up and sends a Term-Req (and theirs has a valid length field). Jul 19 15:37:53 lou-ts5.iglou.com TAP USER pitt on slot:7/mod:3 OUT: 29: FF 03 C0 21 06 06 00 04 To which the Arc replies as it should and the length gets shut down... So...not having the length field correct is not a killer 'cause the same end result comes out of it...the link gets shut down...though it'd be nice to have it done right. :) There is a serious potential problem with the random cruft being included with the second Term-Req. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Any known issues between Rockwell HCF 56k PCI (latest code) and HDM 2.0.81? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

We usually give them 1 of two init strings. +MS=V90 +MS=V34 Turns off V90 They are usually able to connect with one of those strings. Another thing with the Rockwell modems, I have heard that they are coded to only retrain 3 times (total) so after that 3rd time, if the modems try to retrain again it drops them. Hope this helps -John- At 01:29 PM 7/20/99 -0500, you wrote: > >Any known issues between Rockwell HCF 56k PCI (latest code) and HDM >2.0.81? > >Brian > > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > >- > 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. > > >=========================================================< > -John Nelson | email: < > --Technical Support | johnn@jorsm.com < > ---JORSM Internet | < > ----Toll Free # 1-877-JORSM95 | < >=========================================================< >=========================================================< > JORSM Internet < > Regional Premium Internet Service Provider < > Serving Chicagoland and NW Indiana < > 927 Sheffield Ave Dyer, IN < > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < >=========================================================<

--=====================_22599461==_.ALT Content-Type: text/plain; charset="us-ascii" Try sticking a few commas after the phone number in the dialer... It'll make the modem wait through the V.90 handshake and connect... Connections are always slower, but it often works... At 03:36 PM 7/20/99 -0400, you wrote: >We have had so much trouble with these even with the strings it doesn't >always help. > >Why do these company's include such crap? > >Brian Gordon, MCP, A+ >Network Administrator >Westelcom Internet >518-566-6726 Voice >518-566-8348 Fax >http://home.westelcom.com >administrator@westelcom.com >----- Original Message ----- >From: John Nelson <johnn@jorsm.com> >To: <usr-tc@lists.xmission.com> >Sent: Tuesday, July 20, 1999 3:09 PM >Subject: Re: (usr-tc) Rockwell HCF 56k PCI > > >> We usually give them 1 of two init strings. >> +MS=V90 >> +MS=V34 Turns off V90 >> They are usually able to connect with one of those strings. Another thing >> with the Rockwell modems, I have heard that they are coded to only retrain >> 3 times (total) so after that 3rd time, if the modems try to retrain again >> it drops them. >> >> Hope this helps >> >> -John- >> >> >> >> >> At 01:29 PM 7/20/99 -0500, you wrote: >> > >> >Any known issues between Rockwell HCF 56k PCI (latest code) and HDM >> >2.0.81? >> > >> >Brian >> > >> > >> >----------------------------------------------------- >> >Brian Feeny (BF304) signal@shreve.net >> >318-222-2638 x 109 http://www.shreve.net/~signal >> >Network Administrator ShreveNet Inc. (ASN 11881) >> > >> > >> >- >> > 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. >> > >> > >> >=========================================================< >> > -John Nelson | email: < >> > --Technical Support | johnn@jorsm.com < >> > ---JORSM Internet | < >> > ----Toll Free # 1-877-JORSM95 | < >> >=========================================================< >> >=========================================================< >> > JORSM Internet < >> > Regional Premium Internet Service Provider < >> > Serving Chicagoland and NW Indiana < >> > 927 Sheffield Ave Dyer, IN < >> > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < >> >=========================================================< >> >> - >> 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. > Thank You, Joe Priestley FGInet Technical Support (217) 544-2775 www.fgi.net --=====================_22599461==_.ALT Content-Type: text/html; charset="us-ascii" <html><br> <div>Try sticking a few commas after the phone number in the dialer... It'll make the modem wait through the V.90 handshake and connect... Connections are always slower, but it often works...</div> <br> <br> <br> <br> <br> <br> <div>At 03:36 PM 7/20/99 -0400, you wrote:</div> <div>&gt;We have had so much trouble with these even with the strings it doesn't</div> <div>&gt;always help.</div> <div>&gt;</div> <div>&gt;Why do these company's include such crap?</div> <div>&gt;</div> <div>&gt;Brian Gordon, MCP, A+</div> <div>&gt;Network Administrator</div> <div>&gt;Westelcom Internet</div> <div>&gt;518-566-6726 Voice</div> <div>&gt;518-566-8348 Fax</div> <div>&gt;<a href="http://home.westelcom.com/" EUDORA=AUTOURL>http://home.westelcom.com</a></div> <div>&gt;administrator@westelcom.com</div> <div>&gt;----- Original Message -----</div> <div>&gt;From: John Nelson &lt;johnn@jorsm.com&gt;</div> <div>&gt;To: &lt;usr-tc@lists.xmission.com&gt;</div> <div>&gt;Sent: Tuesday, July 20, 1999 3:09 PM</div> <div>&gt;Subject: Re: (usr-tc) Rockwell HCF 56k PCI</div> <div>&gt;</div> <div>&gt;</div> <div>&gt;&gt; We usually give them 1 of two init strings.</div> <div>&gt;&gt; +MS=V90</div> <div>&gt;&gt; +MS=V34&nbsp; Turns off V90</div> <div>&gt;&gt; They are usually able to connect with one of those strings.&nbsp; Another thing</div> <div>&gt;&gt; with the Rockwell modems, I have heard that they are coded to only retrain</div> <div>&gt;&gt; 3 times (total) so after that 3rd time, if the modems try to retrain again</div> <div>&gt;&gt; it drops them.</div> <div>&gt;&gt;</div> <div>&gt;&gt; Hope this helps</div> <div>&gt;&gt;</div> <div>&gt;&gt; -John-</div> <div>&gt;&gt;</div> <div>&gt;&gt;</div> <div>&gt;&gt;</div> <div>&gt;&gt;</div> <div>&gt;&gt; At 01:29 PM 7/20/99 -0500, you wrote:</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;Any known issues between Rockwell HCF 56k PCI (latest code) and HDM</div> <div>&gt;&gt; &gt;2.0.81?</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;Brian</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;-----------------------------------------------------</div> <div>&gt;&gt; &gt;Brian Feeny (BF304)&nbsp;&nbsp;&nbsp;&nbsp; signal@shreve.net</div> <div>&gt;&gt; &gt;318-222-2638 x 109 <a href="http://www.shreve.net/~signal" EUDORA=AUTOURL>http://www.shreve.net/~signal</a></div> <div>&gt;&gt; &gt;Network Administrator&nbsp;&nbsp; ShreveNet Inc. (ASN 11881)</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;-</div> <div>&gt;&gt; &gt; To unsubscribe to usr-tc, send an email to &quot;majordomo@xmission.com&quot;</div> <div>&gt;&gt; &gt; with &quot;unsubscribe usr-tc&quot; in the body of the message.</div> <div>&gt;&gt; &gt; For information on digests or retrieving files and old messages send</div> <div>&gt;&gt; &gt; &quot;help&quot; to the same address.&nbsp; Do not use quotes in your message.</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;</div> <div>&gt;&gt; &gt;=========================================================&lt;</div> <div>&gt;&gt; &gt; -John Nelson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt; --Technical Support&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; johnn@jorsm.com&nbsp; &lt;</div> <div>&gt;&gt; &gt; ---JORSM Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt; ----Toll Free # 1-877-JORSM95&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt;=========================================================&lt;</div> <div>&gt;&gt; &gt;=========================================================&lt;</div> <div>&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; JORSM Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regional Premium Internet Service Provider&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Serving Chicagoland and NW Indiana&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 927 Sheffield Ave Dyer, IN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;</div> <div>&gt;&gt; &gt;&nbsp; Tech hours: M-F 9-9, Sat 10-2&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://www.jorsm.com/" EUDORA=AUTOURL>http://www.jorsm.com</a> &lt;</div> <div>&gt;&gt; &gt;=========================================================&lt;</div> <div>&gt;&gt;</div> <div>&gt;&gt; -</div> <div>&gt;&gt;&nbsp; To unsubscribe to usr-tc, send an email to &quot;majordomo@xmission.com&quot;</div> <div>&gt;&gt;&nbsp; with &quot;unsubscribe usr-tc&quot; in the body of the message.</div> <div>&gt;&gt;&nbsp; For information on digests or retrieving files and old messages send</div> <div>&gt;&gt;&nbsp; &quot;help&quot; to the same address.&nbsp; Do not use quotes in your message.</div> <div>&gt;&gt;</div> <div>&gt;</div> <div>&gt;</div> <div>&gt;-</div> <div>&gt; To unsubscribe to usr-tc, send an email to &quot;majordomo@xmission.com&quot;</div> <div>&gt; with &quot;unsubscribe usr-tc&quot; in the body of the message.</div> <div>&gt; For information on digests or retrieving files and old messages send</div> <div>&gt; &quot;help&quot; to the same address.&nbsp; Do not use quotes in your message.</div> <div>&gt;</div> <br> <br> Thank You,<br> Joe Priestley<br> FGInet Technical Support<br> (217) 544-2775<br> <font color="#0000FF"><u><a href="http://www.fgi.net/" eudora="autourl">www.fgi.net<br> </a></font></u></html> --=====================_22599461==_.ALT--

We have had so much trouble with these even with the strings it doesn't always help. Why do these company's include such crap? Brian Gordon, MCP, A+ Network Administrator Westelcom Internet 518-566-6726 Voice 518-566-8348 Fax http://home.westelcom.com administrator@westelcom.com ----- Original Message ----- Sent: Tuesday, July 20, 1999 3:09 PM > We usually give them 1 of two init strings. > +MS=V90 > +MS=V34 Turns off V90 > They are usually able to connect with one of those strings. Another thing > with the Rockwell modems, I have heard that they are coded to only retrain > 3 times (total) so after that 3rd time, if the modems try to retrain again > it drops them. > > Hope this helps > > -John- > > > > > At 01:29 PM 7/20/99 -0500, you wrote: > > > >Any known issues between Rockwell HCF 56k PCI (latest code) and HDM > >2.0.81? > > > >Brian > > > > > >----------------------------------------------------- > >Brian Feeny (BF304) signal@shreve.net > >318-222-2638 x 109 http://www.shreve.net/~signal > >Network Administrator ShreveNet Inc. (ASN 11881) > > > > > >- > > 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. > > > > > >=========================================================< > > -John Nelson | email: < > > --Technical Support | johnn@jorsm.com < > > ---JORSM Internet | < > > ----Toll Free # 1-877-JORSM95 | < > >=========================================================< > >=========================================================< > > JORSM Internet < > > Regional Premium Internet Service Provider < > > Serving Chicagoland and NW Indiana < > > 927 Sheffield Ave Dyer, IN < > > Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com < > >=========================================================< > > - > 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. >

I've been monitoring the CPU load on my HiPer ARC with MRTG for about the last week and, interestingly enough, it has gone up during the 2 periods that all of my modems(46) were in use. The first period, full DSPs for under 5 minutes, took CPU load to @15%. The second period, in which the modems were full for close to 10 minutes, took the 1-min average to 67% and the load avg. to 29%. I just thought it was interesting considering last week's discussion regarding CPU load never going above 0% :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

my 2 cents: have them pull the modem out of the PC and use it as a new-fangled door stop. Then, get them to buy either a USR Sportster Winmodem or an LT Winmodem. The Paradise PCI winmodem can be had for about $37 with shipping. I have a few customers who I've convinced to torch their HCF's and get one of those 2 modems, and they've all thanked me. Not even Rockwell SERVERS talk well to the HCF chipset. You can get all the scoop at http://808hi.com/56k/rockhcf.htm. ...Scot > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Tuesday, July 20, 1999 2:29 PM > To: USRobotics TC Mailing List > Subject: (usr-tc) Rockwell HCF 56k PCI > > > > Any known issues between Rockwell HCF 56k PCI (latest code) and HDM > 2.0.81? > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. >

I am having a strange problem, where after I dial in, all the sudden some things stop working for my connection. I can resolve names fine. I can only telnet to places that don't display alot of data for the issue file. For example telnetting into a Cisco, works fine. But as soon as I request some data (like "show runn") it freezes. I thought it was routing, so I telnetted into the ARC, but list ip routes froze me up. I had another admin telnet in to check the routes, and all were fine. BTW traceroute and ping work fine. The problem revolves around TCP and around anything but small packets. Below is a tcpdump of me telnetting to the arc. I telnet, login, and then type "list ip routes" and it freezes (toward the end of the trace below). Does anyone see anything strange with the tcpdump? Notice the last couple lines: 21:33:59.779266 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 21:33:59.937582 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: F 72:72(0) ack 94 win 32120 (DF) 21:33:59.979179 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 21:34:00.280382 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 21:34:00.280694 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: R 2126260978:2126260978(0) win 0 Its like the ARC has stopped responding to the telnet session right? If anyone has seen anything like this please let me know. I am running 4.1.59-6. Brian 21:32:47.997612 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: P 1900494611:1900494612(1) ack 1309898613 win 32120 (DF) 21:32:48.197628 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: P 0:1(1) ack 1 win 32120 (DF) 21:32:48.232512 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 1 win 894 21:32:48.236004 208.206.76.71.telnet > shadow.linuxexperts.com.1590: P 1317:1327(10) ack 1 win 894 21:32:48.597556 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: P 0:1(1) ack 1 win 32120 (DF) 21:32:48.638703 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 1 win 894 21:32:50.308922 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: F 1:1(0) ack 1 win 32120 (DF) 21:32:50.343746 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 2 win 894 21:32:50.851701 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 2 win 894 21:32:50.852036 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: R 1900494613:1900494613(0) win 0 21:33:00.758657 shadow.linuxexperts.com.1036 > luna.shreve.net.domain: 5868+ (42) 21:33:00.770414 shadow.linuxexperts.com.1037 > luna.shreve.net.domain: 13771+ (43) 21:33:00.814520 luna.shreve.net.domain > shadow.linuxexperts.com.1036: 5868 NXDomain* 0/1/0 (116) 21:33:00.816588 shadow.linuxexperts.com.1038 > luna.shreve.net.domain: 5869+ (36) 21:33:00.832312 luna.shreve.net.domain > shadow.linuxexperts.com.1037: 13771* 1/2/2 (161) 21:33:00.873761 luna.shreve.net.domain > shadow.linuxexperts.com.1038: 5869* 1/2/2 (133) 21:33:00.885079 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: S 2126260905:2126260905(0) win 32120 <mss 1460,sackOK,timestamp 4791314[|tcp]> (DF) 21:33:00.929998 208.206.76.71.telnet > shadow.linuxexperts.com.1591: S 1362085770:1362085770(0) ack 2126260906 win 1024 <mss 1460> 21:33:00.930336 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 1 win 32120 (DF) 21:33:00.960492 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 1:28(27) ack 1 win 32120 (DF) 21:33:00.972102 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 1:4(3) ack 1 win 1024 21:33:00.972343 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 4 win 32120 (DF) 21:33:01.009664 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 4:41(37) ack 28 win 997 21:33:01.009971 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 28:31(3) ack 41 win 32120 (DF) 21:33:01.040460 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 31 win 994 21:33:01.040695 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 31:34(3) ack 41 win 32120 (DF) 21:33:01.283038 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 34 win 991 21:33:01.622621 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 34:35(1) ack 41 win 32120 (DF) 21:33:01.669620 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 35 win 990 21:33:01.671194 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 41:42(1) ack 35 win 990 21:33:01.687529 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 42 win 32120 (DF) 21:33:01.731281 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 35:36(1) ack 42 win 32120 (DF) 21:33:01.762958 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 42:43(1) ack 36 win 989 21:33:01.777527 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 43 win 32120 (DF) 21:33:01.868722 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 36:37(1) ack 43 win 32120 (DF) 21:33:01.901930 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 37 win 988 21:33:01.903507 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 43:44(1) ack 37 win 988 21:33:01.917539 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 44 win 32120 (DF) 21:33:02.028282 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 37:38(1) ack 44 win 32120 (DF) 21:33:02.062150 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 44:45(1) ack 38 win 987 21:33:02.077318 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 38:39(1) ack 45 win 32120 (DF) 21:33:02.108655 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 39 win 986 21:33:02.110216 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 45:46(1) ack 39 win 986 21:33:02.127542 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 46 win 32120 (DF) 21:33:02.200900 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 39:40(1) ack 46 win 32120 (DF) 21:33:02.231626 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 46:47(1) ack 40 win 985 21:33:02.247539 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 47 win 32120 (DF) 21:33:02.342321 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 40:41(1) ack 47 win 32120 (DF) 21:33:02.373123 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 41 win 984 21:33:02.374713 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 47:48(1) ack 41 win 984 21:33:02.387562 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 48 win 32120 (DF) 21:33:02.439649 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 41:42(1) ack 48 win 32120 (DF) 21:33:02.475639 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 48:49(1) ack 42 win 983 21:33:02.487540 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 49 win 32120 (DF) 21:33:02.625413 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 42:43(1) ack 49 win 32120 (DF) 21:33:02.657628 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 43 win 982 21:33:02.659219 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 49:50(1) ack 43 win 982 21:33:02.677545 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 50 win 32120 (DF) 21:33:02.728003 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 43:44(1) ack 50 win 32120 (DF) 21:33:02.758675 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 50:51(1) ack 44 win 981 21:33:02.777555 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 51 win 32120 (DF) 21:33:02.856337 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 44:45(1) ack 51 win 32120 (DF) 21:33:02.888426 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 45 win 980 21:33:02.888705 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 45:46(1) ack 51 win 32120 (DF) 21:33:02.890273 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 51:52(1) ack 45 win 980 21:33:02.907532 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 52 win 32120 (DF) 21:33:02.940009 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 52:53(1) ack 46 win 979 21:33:02.957538 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 53 win 32120 (DF) 21:33:03.050312 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 46:47(1) ack 53 win 32120 (DF) 21:33:03.080260 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 47 win 978 21:33:03.081841 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 53:54(1) ack 47 win 978 21:33:03.097557 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 54 win 32120 (DF) 21:33:03.552065 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 47:49(2) ack 54 win 32120 (DF) 21:33:03.584535 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 49 win 976 21:33:03.586639 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 54:57(3) ack 49 win 976 21:33:03.597563 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 57 win 32120 (DF) 21:33:03.636153 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 57:67(10) ack 49 win 976 21:33:03.647520 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 67 win 32120 (DF) 21:33:03.739083 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 49:50(1) ack 67 win 32120 (DF) 21:33:03.772123 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 50 win 975 21:33:03.973836 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 50:51(1) ack 67 win 32120 (DF) 21:33:04.006010 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 51 win 974 21:33:04.006352 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 51:52(1) ack 67 win 32120 (DF) 21:33:04.141549 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 52 win 973 21:33:04.141872 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 52:53(1) ack 67 win 32120 (DF) 21:33:04.172543 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 53 win 972 21:33:04.241335 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 53:54(1) ack 67 win 32120 (DF) 21:33:04.382398 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 54 win 971 21:33:04.619962 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 54:56(2) ack 67 win 32120 (DF) 21:33:04.670808 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 56 win 969 21:33:04.672380 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 67:70(3) ack 56 win 969 21:33:04.687554 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 70 win 32120 (DF) 21:33:04.719222 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 70:78(8) ack 56 win 969 21:33:04.737525 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 78 win 32120 (DF) 21:33:05.601702 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 56:57(1) ack 78 win 32120 (DF) 21:33:05.642630 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 57 win 968 21:33:05.643008 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 57:58(1) ack 78 win 32120 (DF) 21:33:05.644466 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 78:79(1) ack 57 win 968 21:33:05.657548 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 79 win 32120 (DF) 21:33:05.691428 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 79:80(1) ack 58 win 967 21:33:05.705563 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 58:59(1) ack 80 win 32120 (DF) 21:33:05.737800 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 59 win 966 21:33:05.739389 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 80:81(1) ack 59 win 966 21:33:05.754524 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 59:60(1) ack 81 win 32120 (DF) 21:33:05.786168 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 81:82(1) ack 60 win 965 21:33:05.796957 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 60:61(1) ack 82 win 32120 (DF) 21:33:05.827803 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 61 win 964 21:33:05.829381 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 82:83(1) ack 61 win 964 21:33:05.847548 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 83 win 32120 (DF) 21:33:06.024624 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 61:62(1) ack 83 win 32120 (DF) 21:33:06.057739 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 62 win 963 21:33:06.059319 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 83:84(1) ack 62 win 963 21:33:06.077577 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 84 win 32120 (DF) 21:33:06.084533 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 62:63(1) ack 84 win 32120 (DF) 21:33:06.118860 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 84:85(1) ack 63 win 962 21:33:06.137543 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 85 win 32120 (DF) 21:33:06.172509 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 63:64(1) ack 85 win 32120 (DF) 21:33:06.203345 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 64 win 961 21:33:06.205086 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 85:86(1) ack 64 win 961 21:33:06.217547 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 86 win 32120 (DF) 21:33:06.305104 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 64:65(1) ack 86 win 32120 (DF) 21:33:06.335390 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 65 win 960 21:33:06.336948 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 86:87(1) ack 65 win 960 21:33:06.347588 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 87 win 32120 (DF) 21:33:06.372770 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 65:66(1) ack 87 win 32120 (DF) 21:33:06.404318 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 66 win 959 21:33:06.405952 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 87:88(1) ack 66 win 959 21:33:06.417546 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 88 win 32120 (DF) 21:33:06.436789 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 66:67(1) ack 88 win 32120 (DF) 21:33:06.467424 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 88:89(1) ack 67 win 958 21:33:06.478235 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 67:68(1) ack 89 win 32120 (DF) 21:33:06.511496 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 68 win 957 21:33:06.513254 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 89:90(1) ack 68 win 957 21:33:06.527517 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 90 win 32120 (DF) 21:33:06.569247 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 68:69(1) ack 90 win 32120 (DF) 21:33:06.600768 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 69 win 956 21:33:06.602323 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 90:91(1) ack 69 win 956 21:33:06.617545 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 91 win 32120 (DF) 21:33:06.663095 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 69:70(1) ack 91 win 32120 (DF) 21:33:06.699576 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 70 win 955 21:33:06.701151 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 91:92(1) ack 70 win 955 21:33:06.717535 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 92 win 32120 (DF) 21:33:06.902977 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 70:72(2) ack 92 win 32120 (DF) 21:33:06.934116 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 72 win 953 21:33:06.935726 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 92:94(2) ack 72 win 953 21:33:06.947563 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 94 win 32120 (DF) 21:33:27.798397 happygirl.com.1067 > icq.mirabilis.com.4000: udp 28 21:33:27.802699 shadow.linuxexperts.com.1038 > luna.shreve.net.domain: 13772+ (43) 21:33:27.864742 luna.shreve.net.domain > shadow.linuxexperts.com.1038: 13772* 1/2/2 (174) 21:33:27.868427 shadow.linuxexperts.com.1038 > luna.shreve.net.domain: 13773+ (45) 21:33:27.903788 icq.mirabilis.com.4000 > happygirl.com.1067: udp 21 21:33:28.174475 luna.shreve.net.domain > shadow.linuxexperts.com.1038: 13773* 1/2/2 (181) 21:33:52.792413 arp who-has shadow.linuxexperts.com tell linuxexperts-gw.linuxexperts.com 21:33:52.792642 arp reply shadow.linuxexperts.com is-at 8:0:20:79:2e:ee 21:33:52.796846 shadow.linuxexperts.com.1038 > luna.shreve.net.domain: 13774+ (43) 21:33:52.860314 luna.shreve.net.domain > shadow.linuxexperts.com.1038: 13774* 1/2/2 (193) 21:33:59.744629 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: F 72:72(0) ack 94 win 32120 (DF) 21:33:59.779266 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 21:33:59.937582 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: F 72:72(0) ack 94 win 32120 (DF) 21:33:59.979179 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 21:34:00.280382 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 21:34:00.280694 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: R 2126260978:2126260978(0) win 0 Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

This is a multi-part message in MIME format. ------=_NextPart_000_00AF_01BED316.D3D5D4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, When I enter a=20 set modem all message=20 command on 4.2.29 with a message thats longer than about 210 characters = the HyperARC reboots! Enjoy... EXCEPTION 0300 CRASH DUMP: GPRs: R0: 0x005F9864 R1: 0x07FACDD0 R2: 0x000BAD04 R3: 0x0000000C =20 R4: 0x006C996C R5: 0x6F6E6E65 R6: 0x4D534720 R7: 0x0002565B =20 R8: 0x0000565D R9: 0x00000000 R10: 0x00002405 R11: 0x00001583 =20 R12: 0x00000000 R13: 0x000C3004 R14: 0x00000000 R15: 0x006C9A40 =20 R16: 0x006C9A1C R17: 0x00002710 R18: 0x00000400 R19: 0x00C2DC48 =20 R20: 0x00000000 R21: 0x00000000 R22: 0x00000000 R23: 0x123919D3 =20 R24: 0x00000000 R25: 0x54435043 R26: 0x00000040 R27: 0x07FACF1C =20 R28: 0x07FACEC0 R29: 0x4D534720 R30: 0x00A26618 R31: 0x00000003 =20 SPRs: CR: 0x24000000 XER: 0x20000004 LR: 0x005F9864 CTR: = 0x00407904 SRR0: 0x005F7EFC SRR1: 0x0000B930 DSISR: 0x42000000 DAR: = 0x6F6E6E6E DMISS: 0x6F6E6E69 DCMP: 0x8000003D HASH1: 0x0001B980 HASH2: = 0x00014640 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: = 0x00000000 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x0000B4FC, Sys Error Addr: 0x00066440 Call Stack: 0x005F7EFC (Exception return address - SRR0) 0x005F9864 0x005FA508 0x0029EDC4 0x0029E0EC 0x0029BD64 0x005FF354 0x005FF4EC 0x00200964 0x00200228 0x00200078 All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. ------=_NextPart_000_00AF_01BED316.D3D5D4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3616.1301"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Hi All,</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>When I enter a = </FONT></DIV> <DIV><FONT size=3D2>set modem all message </FONT></DIV> <DIV><FONT size=3D2>command on 4.2.29 with a message thats longer than = about 210=20 characters the HyperARC reboots!</FONT></DIV> <DIV><FONT size=3D2>Enjoy...</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>EXCEPTION 0300 CRASH DUMP:</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>GPRs:<BR>R0:&nbsp; 0x005F9864&nbsp; R1:&nbsp; = 0x07FACDD0&nbsp;=20 R2:&nbsp; 0x000BAD04&nbsp; R3:&nbsp; 0x0000000C&nbsp; <BR>R4:&nbsp;=20 0x006C996C&nbsp; R5:&nbsp; 0x6F6E6E65&nbsp; R6:&nbsp; 0x4D534720&nbsp; = R7:&nbsp;=20 0x0002565B&nbsp; <BR>R8:&nbsp; 0x0000565D&nbsp; R9:&nbsp; = 0x00000000&nbsp; R10:=20 0x00002405&nbsp; R11: 0x00001583&nbsp; <BR>R12: 0x00000000&nbsp; R13:=20 0x000C3004&nbsp; R14: 0x00000000&nbsp; R15: 0x006C9A40&nbsp; <BR>R16:=20 0x006C9A1C&nbsp; R17: 0x00002710&nbsp; R18: 0x00000400&nbsp; R19:=20 0x00C2DC48&nbsp; <BR>R20: 0x00000000&nbsp; R21: 0x00000000&nbsp; R22:=20 0x00000000&nbsp; R23: 0x123919D3&nbsp; <BR>R24: 0x00000000&nbsp; R25:=20 0x54435043&nbsp; R26: 0x00000040&nbsp; R27: 0x07FACF1C&nbsp; <BR>R28:=20 0x07FACEC0&nbsp; R29: 0x4D534720&nbsp; R30: 0x00A26618&nbsp; R31:=20 0x00000003&nbsp; </FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>SPRs:<BR>CR:&nbsp;&nbsp;&nbsp; 0x24000000&nbsp;=20 XER:&nbsp;&nbsp; 0x20000004&nbsp; LR:&nbsp;&nbsp;&nbsp; 0x005F9864&nbsp; = CTR:&nbsp;&nbsp; 0x00407904<BR>SRR0:&nbsp; 0x005F7EFC&nbsp; SRR1:&nbsp;=20 0x0000B930&nbsp; DSISR: 0x42000000&nbsp; DAR:&nbsp;&nbsp; = 0x6F6E6E6E<BR>DMISS:=20 0x6F6E6E69&nbsp; DCMP:&nbsp; 0x8000003D&nbsp; HASH1: 0x0001B980&nbsp; = HASH2:=20 0x00014640<BR>IMISS: 0x00000000&nbsp; ICMP:&nbsp; 0x00000000&nbsp;=20 RPA:&nbsp;&nbsp; 0x00000000&nbsp; IABR:&nbsp; 0x00000000</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>82660 Registers:<BR>Err Status 1: 0x00, Err Status = 2: 0x00,=20 CPU Err: 0x14, PCI Err: 0x06<BR>CPU/PCI Addr: 0x0000B4FC,&nbsp; Sys = Error Addr:=20 0x00066440</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>Call Stack:<BR>&nbsp;&nbsp;&nbsp; = 0x005F7EFC&nbsp;&nbsp;&nbsp;=20 (Exception return address - SRR0)<BR>&nbsp;&nbsp;&nbsp;=20 0x005F9864<BR>&nbsp;&nbsp;&nbsp; 0x005FA508<BR>&nbsp;&nbsp;&nbsp;=20 0x0029EDC4<BR>&nbsp;&nbsp;&nbsp; 0x0029E0EC<BR>&nbsp;&nbsp;&nbsp;=20 0x0029BD64<BR>&nbsp;&nbsp;&nbsp; 0x005FF354<BR>&nbsp;&nbsp;&nbsp;=20 0x005FF4EC<BR>&nbsp;&nbsp;&nbsp; 0x00200964<BR>&nbsp;&nbsp;&nbsp;=20 0x00200228<BR>&nbsp;&nbsp;&nbsp; 0x00200078<BR></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2><BR>All the best,<BR>Brett = Murphy<BR>Technical=20 Manager, Alphalink (Australia) PTY LTD<BR>ph: +61 3 9486-8844&nbsp; fax: = +61 3=20 9486-6822<BR>email: <A = href=3D"mailto:me@murf.net">me@murf.net</A></FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>The contents of this email message = may not be=20 quoted,<BR>copied, reproduced or published in part or in = whole,<BR>without the=20 written authorization of Brett Murphy,<BR>Director, Alphalink = (Australia) Pty=20 Ltd.</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: = 5px"> <DIV>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_00AF_01BED316.D3D5D4A0--

At 01:17 AM 7/21/99 +1000, "Brett Murphy" <me@murf.net> wrote: > Hi All, When I enter a set modem all message command on 4.2.29 with a >message thats longer than about 210 characters the HyperARC reboots! >Enjoy... And you can't get by with a shorter message? :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Thus spake Scot Desort >my 2 cents: have them pull the modem out of the PC and use it as a >new-fangled door stop. Then, get them to buy either a USR Sportster Winmodem >or an LT Winmodem. Geez...you're recommending winmodems over HCF's? Man, those HCF's must suck even more than I thought! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I don't have a single HCF customer, no matter WHAT driver version they are using, who doesn't have some kind of trouble at one point or another. Those that have taken my advice to dump the HCF and get a winmodem have eliminated all of their problems, and increased their connect speeds at the same time. What can I say.... ...Scot > > Geez...you're recommending winmodems over HCF's? Man, those HCF's must > suck even more than I thought! > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >

Thus spake Scot Desort >I don't have a single HCF customer, no matter WHAT driver version they are >using, who doesn't have some kind of trouble at one point or another. Those >that have taken my advice to dump the HCF and get a winmodem have eliminated >all of their problems, and increased their connect speeds at the same time. >What can I say.... Yeah...I guess coming from total crap (HCF) to something that's just mostly crap (winmodems of various dialects) would be well received. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

|-----Original Message----- |From: owner-totalcontrol@totalservice.3com.com |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of C. M. |Rahman |Sent: Tuesday, July 20, 1999 7:12 PM |Subject: (3Com-TotalControl) new version of hyper arc and memory issue | | |Reply to user-forum-totalcontrol@totalservice.3com.com | |It seems 4.2 needs more memory. They suggested we should upgrade to 128Meg |ram. | |This is the memory situtation on my system | |SYSTEM MEMORY RESOURCES |Total System Memory Resources: 52882 KB |Free Memory: 19001 KB |Code Size: 3815 KB |Initialized Data Size: 646 KB |Uninitialized Data Size: 3844 KB |Stack Size: 512 KB | |Do I need to upgrade ram to install 4.2? I have about 8 dsp card install on |this totalcontrol. Also, can I install another hyperarc card on the same |total control that already has one? Maybe more memory or resource avaliable |?? | |Anybody has any clue? You do not need additional RAM to install 4.2. The additional RAM would be required for singe HARCs running many DSP's with OSPF,IPX and every other bell and whistle turned on. If the configuration and feature set to be used matches 4.1, no attional RAM will be required. I would sugest that if you do not need OSPF, that you stick with the 4.1.59-6 code. There is no performance benefit from the 4.2 code, if you dont need a feature from 4.2, stick with 4.1. -M

Jeff Mcadams wrote: > > Thus spake Scot Desort > >I don't have a single HCF customer, no matter WHAT driver version they are > >using, who doesn't have some kind of trouble at one point or another. Those > >that have taken my advice to dump the HCF and get a winmodem have eliminated > >all of their problems, and increased their connect speeds at the same time. > >What can I say.... > > Yeah...I guess coming from total crap (HCF) to something that's just > mostly crap (winmodems of various dialects) would be well received. :) Rockwell gets worse and worse. I've had three customers that I purchased and mailed out LT-Win's because their computers shipped with "Soft-K56" modems that I can not get to connect at all to my Total Control equipment. I've found it cheaper to give the customer an LT-Win than lose them. At least the 5.34 to the latest driver for the LT-Win works pretty damn good. The worst thing about the Soft-K modems is none of the V.90 disable codes that work on the HCF work on them. +MS=V34 makes the modem play dead. -Ron GLISnet, Inc. +1 810/939.9885

We have found with the SoftModems, that if you get them upgraded to the most recent code that they perform quite well with the TC hubs! But you really have to "CONVINCE" the customer to do it... They never believe that it could be their hardware! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Wed, 21 Jul 1999, Ronald Kushner wrote: > > > Jeff Mcadams wrote: > > > > Thus spake Scot Desort > > >I don't have a single HCF customer, no matter WHAT driver version they are > > >using, who doesn't have some kind of trouble at one point or another. Those > > >that have taken my advice to dump the HCF and get a winmodem have eliminated > > >all of their problems, and increased their connect speeds at the same time. > > >What can I say.... > > > > Yeah...I guess coming from total crap (HCF) to something that's just > > mostly crap (winmodems of various dialects) would be well received. :) > > Rockwell gets worse and worse. I've had three customers that I purchased and > mailed out LT-Win's because their computers shipped with "Soft-K56" modems > that I can not get to connect at all to my Total Control equipment. I've > found it cheaper to give the customer an LT-Win than lose them. At least the > 5.34 to the latest driver for the LT-Win works pretty damn good. > > The worst thing about the Soft-K modems is none of the V.90 disable codes > that work on the HCF work on them. +MS=V34 makes the modem play dead. > > -Ron > GLISnet, Inc. > +1 810/939.9885 > > - > 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. >

What type of memory do the ARC's need? Will just a normal vanilla 128MB SDRAM DIMM work? Brian On Wed, 21 Jul 1999, Mike Wronski wrote: > |-----Original Message----- > |From: owner-totalcontrol@totalservice.3com.com > |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of C. M. > |Rahman > |Sent: Tuesday, July 20, 1999 7:12 PM > |Subject: (3Com-TotalControl) new version of hyper arc and memory issue > | > | > |Reply to user-forum-totalcontrol@totalservice.3com.com > | > |It seems 4.2 needs more memory. They suggested we should upgrade to 128Meg > |ram. > | > |This is the memory situtation on my system > | > |SYSTEM MEMORY RESOURCES > |Total System Memory Resources: 52882 KB > |Free Memory: 19001 KB > |Code Size: 3815 KB > |Initialized Data Size: 646 KB > |Uninitialized Data Size: 3844 KB > |Stack Size: 512 KB > | > |Do I need to upgrade ram to install 4.2? I have about 8 dsp card install on > |this totalcontrol. Also, can I install another hyperarc card on the same > |total control that already has one? Maybe more memory or resource avaliable > |?? > | > |Anybody has any clue? > > You do not need additional RAM to install 4.2. The additional RAM would be > required for singe HARCs running many DSP's with OSPF,IPX and every other bell > and whistle turned on. If the configuration and feature set to be used matches > 4.1, no attional RAM will be required. > > I would sugest that if you do not need OSPF, that you stick with the 4.1.59-6 > code. There is no performance benefit from the 4.2 code, if you dont need a > feature from 4.2, stick with 4.1. > > -M > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I have a customer, who is telling me when he use to dial in to his old ISP, which used Pipeline P400's (yuk!), he would get 550kps with his Pipeline P50. Now he is dogging our USR TC's. If I remember right, STAC Compression is 4:1, and that would mean a 512kps ceiling. Is this correct? Has anyone seen a P50 do those kinds of speeds to a P400 or any NAS? This is downloading webserver log files btw, which although has redundancy of data, I don't believe their is enough to do better than say 2:1/24kBps. Sometimes you just wish you had a reveiew of a P50 showing the best download speed it could do........ I transferred a 1.2MB file, I got 14.68kB/s, and this guy dogged it. To me, that's pretty good speed for a 128k isdn connection, a little compression in their. STAC-9 is the preffered protocol to run to USR TC's from a Pipeline correct? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Hi, How do I confure filters (for use in Radius) in HiPer ARC, I has it on NetServers but I cant find the rights commands on the ARC.. Javier

Does this version still support the 4.1.59-6 code on the HARC? Or do we need to upgrade to the latest release? I assume that the new HARC manager is for the 4.2x code... ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Thus spake Brian >I have a customer, who is telling me when he use to dial in to his old >ISP, which used Pipeline P400's (yuk!), he would get 550kps with his >Pipeline P50. Now he is dogging our USR TC's. Your subject line is very appropriate. >If I remember right, STAC Compression is 4:1, and that would mean a >512kps ceiling. Is this correct? That would be best case...text is about the best case you could get, but you're guess of closer to 2:1 is probably more reasonable. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

From the release notes for HARM 1.2.4 (Windows): HiPer ARM 1.2 does not work with HiPer ARC 4.1. So the correct version of HARM to use with 4.1.59-6 ARC code would be 1.1.8. (It's what I'm using). Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com ----- Original Message ----- Sent: Wednesday, July 21, 1999 12:36 PM > > Does this version still support the 4.1.59-6 code on the HARC? Or >do we need to upgrade to the latest release? I assume that the new HARC >manager is for the 4.2x code...

Is their a way on the ARC to view if a user has compression negotiatied or not and is in use? I was hoping show remote user username would work, but doesn't seem to have that information. Would be usefull to have in a "show remote user". Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake Brian >Is their a way on the ARC to view if a user has compression negotiatied or >not and is in use? I was hoping show remote user username would work, but >doesn't seem to have that information. >Would be usefull to have in a "show remote user". show ppp on interface slot:x/mod:y -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

What do I need to do to accept CHAP/MS-CHAP? My settings are: DIAL_IN USERS AUTHENTICATE: ANY PPP AUTHENTICATION PREFERENCE: PAP When I try to connect through DUN using 'REQUIRE ENCRYPTED PASSWORD', TC NAK's the login. Am I supposed to be able to login this way? Do I need to set something else up in ARC? Is it a limitation of my RADIUS server? Running ARC 4.1.59. Thanks, Scot

Couple of things...both having to do with port numbering in the HiPer Arcs... Its terribly inconsistent, but most of you already knew that I'm sure. :) Here's the deal. NAS-Port RADIUS attribute, according to the RADIUS standard just is a 32-bit number indicating the port number on the NAS, any greater significance for the individual NASen is left up to the vendor to define...no problem so far. So the HiPer Arc user manual, on page E-30 defines how 3Com uses this value. The least two significant bytes define the physical slot and port number of the connection, the physical port number being the least significant byte, and the physical slot being the next least significant byte. Again...no problem so far. The problem comes from the fact that the Arc is off by one on the slot number. :/ So, if your user is on slot 3 port 4, the NAS-Port number would be 516, which indicates slot2 port 4. This is, of course, unless the Arc is numbering from 0 on the slots, which is certainly possible, though, again, inconsistent. The second place where the numbering is funky is in the SNMP tables. It seems (there's no documentation on this, have just worked it out on my own) that the SNMP agent uses largely the same mechanism for assigning port numbers...except that it either doesn't suffer from the off by one, or it counts starting with 1. The other difference is that once it converts the number to decimal for the snmp value...it adds 1,000. I have come up with no explanation for this as of yet. :) So, the example above (slot:3/mod:4) would be numbered in SNMP as 1772 (516, the number from above, plus 256 to adjust for the off by one thing, gives 772, then add 1,000, again...not sure why we're adding 1,000, but that's what it does). I figured I'd post this for explanation of others as I was trying to debug a session and was going through all sorts of gyrations to cross-reference information between these two sources and finally realized the relation between the two. Oh, and just to cement the inconsistancy thing...if you reference that same port via the NMC directly, its 3004, which is the physical slot and port number in decimal! So much for any possibility of consistency here! On a seperate topic...is there any possibility to get the HiPer Arc equivalent of the parameter reference guide that is included in the NMC documentation? I've found this quite useful to have around and would love to have the equivalent for the HiPer Arc, but have been unable to find anything like this as of yet. Thanks! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Has anyone purchased a 3445 or 3447 bundle instead of a 3446 and been able to take advantage of the quad modem trade-in? Brian

Not sure if this will help but try and close your programs that are not being used in your System Tray. Actually close all except for the Explorer and Systray it will free up some resources so you can connect. My company has had a few HCF customers trying to connect and until we close the programs running it would time out with no time out error message. We have a few happy customers now that they connected. Dana

Try 'Monitor Radius' on the Hiperarc. Are you receiving responses to your Access requests? Is the source & dest IP of the access response the reverse of the access request? It needs to be. STeve "Kent Tambling" <Kent@acceleration.net> on 07/22/99 12:21:07 PM Please respond to usr-tc@lists.xmission.com Sent by: "Kent Tambling" <Kent@acceleration.net> cc: (Steve Valiunas/MW/US/3Com) I'm using 5.5.3 SA on NT and can't seem to add another hiper for authorizations. All I get is messages about 'duplicate packet received, NAS will reset in two minutes' or something along those lines at every attempt to authenticate. Its authenticating the other hipers in a different subnet just fine. I added both the NMC and Hiper, and both ports to the allowed client list. I also get ODBC debug messages in debug/verbose mode. Not sure if thats the cause or a symptom. Any ideas? Kent Tambling kent@acceleration.net System Administrator www.acceleration.net - 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.

Thus spake Brett Murphy >I am running quite a few HyperDSP cards on E1's here in Australia, >and I am finding V90 on them is un-acceptably unstable. >5% of all calls connecting to these cards drop out in less than 1 minute. >I Have tried Quad cards and they seem alot more stable, has anyone >else found this? Absolutely...the quads are considerably older and the code on them has had considerably more time to mature and stabilize. The DSP's are definitely coming along though. >I am running 14 cards on one chassis with one HyperARC, is there >any chance I need another HyperARC? I dont do any Multi PPP processing. >I am running version 2.0.19 of the DSP firmware and 4.1.59 of the hyperARC >firmware. As long as you're not otherwise pushing the systems (you said no MP, what about RIP/OSPF, heavy filtering, etc.?) you should be ok with 14 dsps and a single arc. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'm using 5.5.3 SA on NT and can't seem to add another hiper for authorizations. All I get is messages about 'duplicate packet received, NAS will reset in two minutes' or something along those lines at every attempt to authenticate. Its authenticating the other hipers in a different subnet just fine. I added both the NMC and Hiper, and both ports to the allowed client list. I also get ODBC debug messages in debug/verbose mode. Not sure if thats the cause or a symptom. Any ideas? Kent Tambling kent@acceleration.net System Administrator www.acceleration.net

Thus spake Brian Gordon >I use balance loading which seems to run nice. >Hiper Arc #1 owns odd dsp's while Hiper Arc #2 owns evens. >Not sure how to do the fallover if one fails, would be interested in that >config though if anyone has it. enable nmc chassis_awareness enable nmc dynamic_slot_assignment enable nmc dsa_idle_rebalancing This should, at least, switch over the ownership/control of the cards...working out ip pool issues and stuff is left as an exercise for the reader. (hint, check the archives :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

4.1.59-6 is the "latest" service release.. unless you went to TCS 3.6 then I don't know. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Sun, 18 Jul 1999, Brett Murphy wrote: > Hi All, > I am running quite a few HyperDSP cards on E1's here in Australia, > and I am finding V90 on them is un-acceptably unstable. > 5% of all calls connecting to these cards drop out in less than 1 minute. > I Have tried Quad cards and they seem alot more stable, has anyone > else found this? > I am running 14 cards on one chassis with one HyperARC, is there > any chance I need another HyperARC? I dont do any Multi PPP processing. > I am running version 2.0.19 of the DSP firmware and 4.1.59 of the hyperARC > firmware. > > All the best, > Brett Murphy > Technical Manager, Alphalink (Australia) PTY LTD > ph: +61 3 9486-8844 fax: +61 3 9486-6822 > email: me@murf.net > > The contents of this email message may not be quoted, > copied, reproduced or published in part or in whole, > without the written authorization of Brett Murphy, > Director, Alphalink (Australia) Pty Ltd. > -----Original Message----- > From: Ricky Beam <jfbeam@bluetopia.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Sunday, 18 July 1999 2:02 > Subject: Re: (usr-tc) Red 'Hub Stat' LED on working NMC > > - > 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. >

Yes. Depends on how your VAR generates the invoice. As long as they can "swing" the 2 DSP cards as the progam's bundle it should go through. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 22 Jul 1999, Brian Elfert wrote: > Has anyone purchased a 3445 or 3447 bundle instead of a 3446 and been able > to take advantage of the quad modem trade-in? > > Brian > > > - > 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. >

Yes. Depends on how your VAR generates the invoice. As long as they can "swing" the 2 DSP cards as the progam's bundle it should go through. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 22 Jul 1999, Brian Elfert wrote: > Has anyone purchased a 3445 or 3447 bundle instead of a 3446 and been able > to take advantage of the quad modem trade-in? > > Brian > > > - > 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. >

Thus spake Paul Farber >4.1.59-6 is the "latest" service release.. unless you went to TCS 3.6 >then I don't know. TCS 3.6 upgraded the Arc code and only the Arc code. 4.2.29-1 is the version number. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'm looking for some used (or new) dc power supplies for 3com TC chassis. Have some AC supplies to swap if desired. Any leads appreciated. -- Aaron Nabil

I am having a very strange problem. Whenever I add the ip pool to one of our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the front of the ARC are pegged. The pool is added as: add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate Its very strange. 4.1.59-6 Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Does anyone have IPX working with a Radius server (preferably, Merit)? I can not get an IPX pool to work at all. DCP

BTW, this turned out to be a DoS attack on UDP port 22 (ssh) targetted to a dynamic ip that was part of that pool, even though someone wasn't even connected to it. I am not sure how much bandwidth the attack was, but that ARC cpu was at 100%. Brian On Thu, 22 Jul 1999, Brian wrote: > > I am having a very strange problem. Whenever I add the ip pool to one of > our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the > front of the ARC are pegged. > > The pool is added as: > > add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate > > Its very strange. 4.1.59-6 > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

BTW, this turned out to be a DoS attack on UDP port 22 (ssh) targetted to a dynamic ip that was part of that pool, even though someone wasn't even connected to it. I am not sure how much bandwidth the attack was, but that ARC cpu was at 100%. Brian On Thu, 22 Jul 1999, Brian wrote: > > I am having a very strange problem. Whenever I add the ip pool to one of > our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the > front of the ARC are pegged. > > The pool is added as: > > add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate > > Its very strange. 4.1.59-6 > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Thu, 22 Jul 1999, Kurtiss Johnson wrote: > > > Brian, > > Were you able to get any kind of details on the type of DoS attack you saw? Was > it a broadcast attack? A smurf-style attack? its was udp port 22 (ssh). That is all I know, I tcpdumped, saw where it was coming from, called them and had them shut it down. I was surprised the arc choked like it did. > > We're doing a lot of investigation on how to "bulletproof" the ARC against this > type of event, and the feedback would be useful. if it happens again I'll get you a dump. > > Kurtiss Johnson > Product Line Manager > Total Control RAS > 847-222-2279 > > > > > > Brian <signal@shreve.net> on 07/22/99 04:35:50 PM > > Please respond to usr-tc@lists.xmission.com > > Sent by: Brian <signal@shreve.net> > > > To: usr-tc@lists.xmission.com > cc: USRobotics TC Mailing List <usr-tc@xmission.com> (Kurtiss > Johnson/MW/US/3Com) > Subject: Re: (usr-tc) ip pool = 100% cpu utilization > > > > > > BTW, this turned out to be a DoS attack on UDP port 22 (ssh) targetted to > a dynamic ip that was part of that pool, even though someone wasn't even > connected to it. I am not sure how much bandwidth the attack was, but > that ARC cpu was at 100%. > > Brian > > > On Thu, 22 Jul 1999, Brian wrote: > > > > > I am having a very strange problem. Whenever I add the ip pool to one of > > our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the > > front of the ARC are pegged. > > > > The pool is added as: > > > > add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate > > > > Its very strange. 4.1.59-6 > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > 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. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Brian, Were you able to get any kind of details on the type of DoS attack you saw? Was it a broadcast attack? A smurf-style attack? We're doing a lot of investigation on how to "bulletproof" the ARC against this type of event, and the feedback would be useful. Kurtiss Johnson Product Line Manager Total Control RAS 847-222-2279 Brian <signal@shreve.net> on 07/22/99 04:35:50 PM Please respond to usr-tc@lists.xmission.com Sent by: Brian <signal@shreve.net> cc: USRobotics TC Mailing List <usr-tc@xmission.com> (Kurtiss Johnson/MW/US/3Com) BTW, this turned out to be a DoS attack on UDP port 22 (ssh) targetted to a dynamic ip that was part of that pool, even though someone wasn't even connected to it. I am not sure how much bandwidth the attack was, but that ARC cpu was at 100%. Brian On Thu, 22 Jul 1999, Brian wrote: > > I am having a very strange problem. Whenever I add the ip pool to one of > our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the > front of the ARC are pegged. > > The pool is added as: > > add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate > > Its very strange. 4.1.59-6 > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - 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.

I have 3 (maybe 4) unused DC 70Amp power supplies I would like to swap for AC. John AEI Internet 514/284-4452 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil > Sent: Thursday, July 22, 1999 5:14 PM > To: isp-equipment@isp-equipment.com; usr-tc@xmission.com > Subject: (usr-tc) looking for 3com TC DC power supplies > > > > I'm looking for some used (or new) dc power supplies for 3com TC > chassis. Have some AC supplies to swap if desired. > > Any leads appreciated. > > -- > Aaron Nabil > > - > 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. >

> > You mentioned that the attack was aimed at one of the IP addresses in > the pool...not at the arc itself... Right.......... > > Kurtiss...the command "enable ip address_pool_filtering"...I haven't > investigated (pulling down the product reference and command reference > for 4.2 currently)...what does this command do, and would it have helped > in this situation? I seem to remember there being a command on the Arcs > that will tell them to drop packets for IP addresses in their pools that > aren't in use, and I was thinking this command was it, but I don't Yeah, I remember that. I instituted the command and the arc went into spiral death. Of course this was with 4.0.x a long time ago, maybe they have fixed it. My main reason for using that command then was when a tcp session was established between a user and say our mail server, and the user dropped off, the mail server console would get flooded with redirect messages (even though the arc had a /25 for an ip pool, it doesn't insert an aggregate route entry for the /25 into its routing table, so it looks to the default route (our router) once the interface goes down. The router of course has that pool routed to the arc (since in RIPv2 the ARC broadcasts an aggregate /25) and so a small storm insues between the router and the arc). I always felt, that like the netserver, the arc should not go sending out traffic for ip's in its pools to the default route, it should put an entry in its rtab pertaining to the ip pool in aggregate. > remember. I'm not sure how the Arc handles something like this > internally...not sure if telling it to explicitely drop packets would be > handled better than just letting it try to forward it on into > nothingness...or not sure how the Arc handles it... > -- > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I have some DC power supplies that I would like to unload. If you are interested in these please contact me at sales@wrca.net Trade would be good. At 05:19 PM 7/22/99 -0400, you wrote: >I have 3 (maybe 4) unused DC 70Amp power supplies I would like to swap for >AC. > >John >AEI Internet >514/284-4452 > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil >> Sent: Thursday, July 22, 1999 5:14 PM >> To: isp-equipment@isp-equipment.com; usr-tc@xmission.com >> Subject: (usr-tc) looking for 3com TC DC power supplies >> >> >> >> I'm looking for some used (or new) dc power supplies for 3com TC >> chassis. Have some AC supplies to swap if desired. >> >> Any leads appreciated. >> >> -- >> Aaron Nabil >> >> - >> 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. > Steve Rivera - VP-WRCA, INC. email: sales@wrca.net 732-833-2111 WAN ACCESS SPECIALIST---http://www.wrca.net (Complete Inventory Listing) Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone & More

No, its "enable ip address_pool_filtering". I believe it blackholes traffic for ip's in the ip pools of the arc,when they are not in use. Brian On Thu, 22 Jul 1999 pferraro@wna-linknet.com wrote: > > I believe you are speaking of the "anti-spoofing" The command is: > > enable ip address_source_filter > set network user default PPP_source_ip_filter enabled > > I think this is what you are referring to... > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Thu, 22 Jul 1999, Jeff Mcadams wrote: > > > Thus spake Brian > > >On Thu, 22 Jul 1999, Kurtiss Johnson wrote: > > >> Were you able to get any kind of details on the type of DoS attack > > >> you saw? Was it a broadcast attack? A smurf-style attack? > > > > >its was udp port 22 (ssh). That is all I know, I tcpdumped, saw where it > > >was coming from, called them and had them shut it down. I was surprised > > >the arc choked like it did. > > > > Interesting...ssh really uses port 22 of tcp, doesn't use udp that I'm > > aware of (22/udp is allocated to ssh by iana but it doesn't actually use > > it that I'm aware of). > > > > >> We're doing a lot of investigation on how to "bulletproof" the ARC > > >> against this type of event, and the feedback would be useful. > > > > >if it happens again I'll get you a dump. > > > > You mentioned that the attack was aimed at one of the IP addresses in > > the pool...not at the arc itself... > > > > Kurtiss...the command "enable ip address_pool_filtering"...I haven't > > investigated (pulling down the product reference and command reference > > for 4.2 currently)...what does this command do, and would it have helped > > in this situation? I seem to remember there being a command on the Arcs > > that will tell them to drop packets for IP addresses in their pools that > > aren't in use, and I was thinking this command was it, but I don't > > remember. I'm not sure how the Arc handles something like this > > internally...not sure if telling it to explicitely drop packets would be > > handled better than just letting it try to forward it on into > > nothingness...or not sure how the Arc handles it... > > -- > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

The funky numbering scheme seems to come from the fact that the ARC is set by default to allow 256 ports per slot. So slot 1 reports ports 1-256, slot 2 reports 257-512, slot 3 is 513-768, etc. Someone posted this command a while ago to make the port numbering more sane. I know this affects RADIUS NAS-Port numbers, but I don't know if it changes the numbering for SNMP. set pbus reported_port_density 24 This means Slot 1 reports ports 1-24, slot 2 reports ports 25-48, slot 3 reports 49-72, etc. Much nicer to deal with. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com ----- Original Message ----- Sent: Thursday, July 22, 1999 11:35 AM >Couple of things...both having to do with port numbering in the HiPer >Arcs... > >Its terribly inconsistent, but most of you already knew that I'm sure. >:) > >Here's the deal. NAS-Port RADIUS attribute, according to the RADIUS >standard just is a 32-bit number indicating the port number on the NAS, >any greater significance for the individual NASen is left up to the >vendor to define...no problem so far. > >So the HiPer Arc user manual, on page E-30 defines how 3Com uses this >value. The least two significant bytes define the physical slot and >port number of the connection, the physical port number being the least >significant byte, and the physical slot being the next least significant >byte. Again...no problem so far. The problem comes from the fact that >the Arc is off by one on the slot number. :/ So, if your user is on >slot 3 port 4, the NAS-Port number would be 516, which indicates slot2 >port 4. This is, of course, unless the Arc is numbering from 0 on the >slots, which is certainly possible, though, again, inconsistent. > >The second place where the numbering is funky is in the SNMP tables. It >seems (there's no documentation on this, have just worked it out on my >own) that the SNMP agent uses largely the same mechanism for assigning >port numbers...except that it either doesn't suffer from the off by one, >or it counts starting with 1. The other difference is that once it >converts the number to decimal for the snmp value...it adds 1,000. I >have come up with no explanation for this as of yet. :) So, the >example above (slot:3/mod:4) would be numbered in SNMP as 1772 (516, the >number from above, plus 256 to adjust for the off by one thing, gives >772, then add 1,000, again...not sure why we're adding 1,000, but that's >what it does). > >I figured I'd post this for explanation of others as I was trying to >debug a session and was going through all sorts of gyrations to >cross-reference information between these two sources and finally >realized the relation between the two.

Thus spake Brian >On Thu, 22 Jul 1999, Kurtiss Johnson wrote: >> Were you able to get any kind of details on the type of DoS attack >> you saw? Was it a broadcast attack? A smurf-style attack? >its was udp port 22 (ssh). That is all I know, I tcpdumped, saw where it >was coming from, called them and had them shut it down. I was surprised >the arc choked like it did. Interesting...ssh really uses port 22 of tcp, doesn't use udp that I'm aware of (22/udp is allocated to ssh by iana but it doesn't actually use it that I'm aware of). >> We're doing a lot of investigation on how to "bulletproof" the ARC >> against this type of event, and the feedback would be useful. >if it happens again I'll get you a dump. You mentioned that the attack was aimed at one of the IP addresses in the pool...not at the arc itself... Kurtiss...the command "enable ip address_pool_filtering"...I haven't investigated (pulling down the product reference and command reference for 4.2 currently)...what does this command do, and would it have helped in this situation? I seem to remember there being a command on the Arcs that will tell them to drop packets for IP addresses in their pools that aren't in use, and I was thinking this command was it, but I don't remember. I'm not sure how the Arc handles something like this internally...not sure if telling it to explicitely drop packets would be handled better than just letting it try to forward it on into nothingness...or not sure how the Arc handles it... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I believe you are speaking of the "anti-spoofing" The command is: enable ip address_source_filter set network user default PPP_source_ip_filter enabled I think this is what you are referring to... ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Thu, 22 Jul 1999, Jeff Mcadams wrote: > Thus spake Brian > >On Thu, 22 Jul 1999, Kurtiss Johnson wrote: > >> Were you able to get any kind of details on the type of DoS attack > >> you saw? Was it a broadcast attack? A smurf-style attack? > > >its was udp port 22 (ssh). That is all I know, I tcpdumped, saw where it > >was coming from, called them and had them shut it down. I was surprised > >the arc choked like it did. > > Interesting...ssh really uses port 22 of tcp, doesn't use udp that I'm > aware of (22/udp is allocated to ssh by iana but it doesn't actually use > it that I'm aware of). > > >> We're doing a lot of investigation on how to "bulletproof" the ARC > >> against this type of event, and the feedback would be useful. > > >if it happens again I'll get you a dump. > > You mentioned that the attack was aimed at one of the IP addresses in > the pool...not at the arc itself... > > Kurtiss...the command "enable ip address_pool_filtering"...I haven't > investigated (pulling down the product reference and command reference > for 4.2 currently)...what does this command do, and would it have helped > in this situation? I seem to remember there being a command on the Arcs > that will tell them to drop packets for IP addresses in their pools that > aren't in use, and I was thinking this command was it, but I don't > remember. I'm not sure how the Arc handles something like this > internally...not sure if telling it to explicitely drop packets would be > handled better than just letting it try to forward it on into > nothingness...or not sure how the Arc handles it... > -- > 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. >

I upgraded 4.2.29 on 3 boxes yesterday. Same results. My authentication settings zonked on 3 boxes, and it zeroed my ippool on one box. We finally got everything back up by midnight. At 02:20 AM 7/18/99 -0400, you wrote: >I upgraded the last ARC in our dialup pool to 4.2.29 today and turned OSPF >on, and found that suddenly nobody could authenticate anymore. All my >Radius server settings, and some of the auth-related PPP settings, got >nuked. Radius accounting server settings were still there though. > >Anyone else seen this, or does everyone just nuke and re-enter their >config every time they do an upgrade? (Kinda hard to do exactly if you >don't write down every config command you enter every time...) > > >Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY >mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org >"If you're not part of the solution.... you're part of the precipitate." > >- > 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.

Anyone know of a publicly accessible 3com newsgroups server? It seems like I used to attach to a server housed at or by 3com. But now I can't figure out what I did to get the groups.

Anyone know of a publicly accessible 3com newsgroups server? It seems like I used to attach to a server housed at or by 3com. But now I can't figure out what I did to get the groups.

ssh uses TCP 22, not UDP. I think PCAnywhere uses UDP 22 though.... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY "If you're not part of the solution.... you're part of the precipitate." On Thu, 22 Jul 1999, Brian wrote: > On Thu, 22 Jul 1999, Kurtiss Johnson wrote: > > > > > > > Brian, > > > > Were you able to get any kind of details on the type of DoS attack you saw? Was > > it a broadcast attack? A smurf-style attack? > > its was udp port 22 (ssh). That is all I know, I tcpdumped, saw where it > was coming from, called them and had them shut it down. I was surprised > the arc choked like it did. > > > > > We're doing a lot of investigation on how to "bulletproof" the ARC against this > > type of event, and the feedback would be useful. > > if it happens again I'll get you a dump. > > > > > > Kurtiss Johnson > > Product Line Manager > > Total Control RAS > > 847-222-2279 > > > > > > > > > > > > Brian <signal@shreve.net> on 07/22/99 04:35:50 PM > > > > Please respond to usr-tc@lists.xmission.com > > > > Sent by: Brian <signal@shreve.net> > > > > > > To: usr-tc@lists.xmission.com > > cc: USRobotics TC Mailing List <usr-tc@xmission.com> (Kurtiss > > Johnson/MW/US/3Com) > > Subject: Re: (usr-tc) ip pool = 100% cpu utilization > > > > > > > > > > > > BTW, this turned out to be a DoS attack on UDP port 22 (ssh) targetted to > > a dynamic ip that was part of that pool, even though someone wasn't even > > connected to it. I am not sure how much bandwidth the attack was, but > > that ARC cpu was at 100%. > > > > Brian > > > > > > On Thu, 22 Jul 1999, Brian wrote: > > > > > > > > I am having a very strange problem. Whenever I add the ip pool to one of > > > our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the > > > front of the ARC are pegged. > > > > > > The pool is added as: > > > > > > add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate > > > > > > Its very strange. 4.1.59-6 > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > 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. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > 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. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > 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. >

Thus spake John Schmerold >Anyone know of a publicly accessible 3com newsgroups server? >It seems like I used to attach to a server housed at or by 3com. But now I >can't figure out what I did to get the groups. nntp access is available at totalservice.usr.com -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

same here ... I had to nuke each boxes config and redo it from scratch (happed on 3 out of 3 boxes so far) . ----- Original Message ----- Sent: Thursday, July 22, 1999 7:36 PM > I upgraded 4.2.29 on 3 boxes yesterday. Same results. My authentication > settings zonked on 3 boxes, and it zeroed my ippool on one box. We finally > got everything back up by midnight. > > At 02:20 AM 7/18/99 -0400, you wrote: > >I upgraded the last ARC in our dialup pool to 4.2.29 today and turned OSPF > >on, and found that suddenly nobody could authenticate anymore. All my > >Radius server settings, and some of the auth-related PPP settings, got > >nuked. Radius accounting server settings were still there though. > > > >Anyone else seen this, or does everyone just nuke and re-enter their > >config every time they do an upgrade? (Kinda hard to do exactly if you > >don't write down every config command you enter every time...) > > > > > >Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > >mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > >"If you're not part of the solution.... you're part of the precipitate." > > > >- > > 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. > >

On Thu, 22 Jul 1999, Mike Andrews wrote: > ssh uses TCP 22, not UDP. I think PCAnywhere uses UDP 22 though.... well, I said "udp 22 (ssh)" because i just grepped that out of /etc/services, and tcpdump in fact, gets its information from there as well, so as I was tcpdumping it, it was showing a dst of 22 udp ssh. Brian > > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > "If you're not part of the solution.... you're part of the precipitate." > > On Thu, 22 Jul 1999, Brian wrote: > > > On Thu, 22 Jul 1999, Kurtiss Johnson wrote: > > > > > > > > > > > Brian, > > > > > > Were you able to get any kind of details on the type of DoS attack you saw? Was > > > it a broadcast attack? A smurf-style attack? > > > > its was udp port 22 (ssh). That is all I know, I tcpdumped, saw where it > > was coming from, called them and had them shut it down. I was surprised > > the arc choked like it did. > > > > > > > > We're doing a lot of investigation on how to "bulletproof" the ARC against this > > > type of event, and the feedback would be useful. > > > > if it happens again I'll get you a dump. > > > > > > > > > > Kurtiss Johnson > > > Product Line Manager > > > Total Control RAS > > > 847-222-2279 > > > > > > > > > > > > > > > > > > Brian <signal@shreve.net> on 07/22/99 04:35:50 PM > > > > > > Please respond to usr-tc@lists.xmission.com > > > > > > Sent by: Brian <signal@shreve.net> > > > > > > > > > To: usr-tc@lists.xmission.com > > > cc: USRobotics TC Mailing List <usr-tc@xmission.com> (Kurtiss > > > Johnson/MW/US/3Com) > > > Subject: Re: (usr-tc) ip pool = 100% cpu utilization > > > > > > > > > > > > > > > > > > BTW, this turned out to be a DoS attack on UDP port 22 (ssh) targetted to > > > a dynamic ip that was part of that pool, even though someone wasn't even > > > connected to it. I am not sure how much bandwidth the attack was, but > > > that ARC cpu was at 100%. > > > > > > Brian > > > > > > > > > On Thu, 22 Jul 1999, Brian wrote: > > > > > > > > > > > I am having a very strange problem. Whenever I add the ip pool to one of > > > > our arcs (only this one), the cpu goes to 100% and the RX/TX lights on the > > > > front of the ARC are pegged. > > > > > > > > The pool is added as: > > > > > > > > add ip pool shreveport6 initial 208.249.213.129 size 126 route aggregate > > > > > > > > Its very strange. 4.1.59-6 > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > - > > > > 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. > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > 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. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

If you enable the arc to act as an ASBR (in the ospf global table) it will then redistribute any static or rip routes (including those listed in any radius profiles) into ospf. Just watch out when you upgrade any arc from 4.59-6......we lost our ppp and authentication settings on some of them.... :> Ricky Beam wrote: > On Fri, 16 Jul 1999, Jeff Mcadams wrote: > >>It would only be inconsistent if RIP behaved differently -- which was my > >>original complaint (that and I didn't want to put 10,000 sendpolicies in > >>there for customer LAN dialups.) > > > >Oh, bah...just put in a few that covers the range...from what I'm > >reading, that should work. IgLou has a grand total of 5 routing > >announcements globally...if I really wanted to be lazy I could just add > >the 5 blocks that we have total to the sendpolicy and be done with it. > >You don't have to match netmask length to match the send policy. > > I did that at first, but that's way too messy in the long run. Maybe not > for you, but... > > Anyway, my main complaint was about the thing not advertizing it's dialup > connections by default (which it did with RIP) which is just a stupid idea. > What's the point of a dialup "router" that you have to beat into submission > to get it to tell others who's connected? That is the entire point of the > NAS... 99.99975% of the time, you'll want everyone to know Bob is logged > in on NAS-foo. The only time that it makes any sense at all to not announce > is where you shouldn't have any routing protocol active anyway. (I can paint > an example where you'd want some connections hidden, but it's a Bad Idea (tm) > to do something like that.) > > But we're getting off topic... back to that [censored] 3500 entry lsdb limit. > > --Ricky > > - > 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

We also experienced the same fun... Still wondering how 3com could beta test this for over 6 months and not document it.... Maybe krish can enlighten us on how this obvious bug was not squashed...... Mike Andrews wrote: > I upgraded the last ARC in our dialup pool to 4.2.29 today and turned OSPF > on, and found that suddenly nobody could authenticate anymore. All my > Radius server settings, and some of the auth-related PPP settings, got > nuked. Radius accounting server settings were still there though. > > Anyone else seen this, or does everyone just nuke and re-enter their > config every time they do an upgrade? (Kinda hard to do exactly if you > don't write down every config command you enter every time...) > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > "If you're not part of the solution.... you're part of the precipitate." > > - > 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

> On Sun, 18 Jul 1999, Brett Murphy wrote: > > > Hi All, > > I am running quite a few HyperDSP cards on E1's here in Australia, > > and I am finding V90 on them is un-acceptably unstable. > > 5% of all calls connecting to these cards drop out in less than 1 minute. > > I Have tried Quad cards and they seem alot more stable, has anyone > > else found this? > > I am running 14 cards on one chassis with one HyperARC, is there > > any chance I need another HyperARC? I dont do any Multi PPP processing. > > I am running version 2.0.19 of the DSP firmware and 4.1.59 of the hyperARC > > firmware. We run 14 E1 DSPs with 2 ARCs and we have similar symptoms. we only use 1.2.43 DSP fw. Never knew what to blame: telco, DSP, ARC or stupid user. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Senior Network Engineer Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

> We also experienced the same fun... > > > Still wondering how 3com could beta test this for over 6 months and not > document it.... > > Maybe krish can enlighten us on how this obvious bug was not squashed...... I wish I could - krish > > Mike Andrews wrote: > > > I upgraded the last ARC in our dialup pool to 4.2.29 today and turned OSPF > > on, and found that suddenly nobody could authenticate anymore. All my > > Radius server settings, and some of the auth-related PPP settings, got > > nuked. Radius accounting server settings were still there though. > > > > Anyone else seen this, or does everyone just nuke and re-enter their > > config every time they do an upgrade? (Kinda hard to do exactly if you > > don't write down every config command you enter every time...) > > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > > mandrews@dcr.net -=- mandrews@termfrost.org -=- http://www.termfrost.org > > "If you're not part of the solution.... you're part of the precipitate." > > > > - > > 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. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone > Head of Network Engineering | Monmouth Internet Corporation > 732-842-5366=====extension 102 | http://www.monmouth.com > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > - > 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. >

On Fri, 23 Jul 1999, Jeff Mcadams wrote: > Does anyone know what the command: > set user <user> dnis_reauthentication enabled|disabled > does? Dnis authentication will allow you to enable authentication before or after the user dials in with the DNIS or ANI digits. It can be used to setup DNIS based ip pools, radius re authentication etc. > > I'm curious...perhaps this is the magic make the user re-auth with PAP > after a DNIS|ANI auth switch? > Yes you can do it. > Has anyone used this and/or found out what it does? I've looked in the > documentation and its (as is not terribly uncommon) rather vague to say > the least. Well if you want to know what all you can do with it - probable in a day or two I can come up with a document. krish > -- > 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. >

On 20 Jul 99, at 21:49, Brian <usr-tc@lists.xmission.com> wrote: > The problem revolves around TCP and around anything but small packets. > > Below is a tcpdump of me telnetting to the arc. I telnet, login, and then > type "list ip routes" and it freezes (toward the end of the trace below). > Does anyone see anything strange with the tcpdump? ... > 21:32:47.997612 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: P 1900494611:1900494612(1) ack 1309898613 win 32120 > 21:32:48.197628 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: P 0:1(1) ack 1 win 32120 (DF) > 21:32:48.232512 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 1 win 894 > 21:32:48.236004 208.206.76.71.telnet > shadow.linuxexperts.com.1590: P 1317:1327(10) ack 1 win 894 > 21:32:48.597556 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: P 0:1(1) ack 1 win 32120 (DF) > 21:32:48.638703 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 1 win 894 > 21:32:50.308922 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: F 1:1(0) ack 1 win 32120 (DF) > 21:32:50.343746 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 2 win 894 > 21:32:50.851701 208.206.76.71.telnet > shadow.linuxexperts.com.1590: . ack 2 win 894 > 21:32:50.852036 shadow.linuxexperts.com.1590 > 208.206.76.71.telnet: R 1900494613:1900494613(0) win 0 ... > 21:33:06.699576 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 70 win 955 > 21:33:06.701151 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 91:92(1) ack 70 win 955 > 21:33:06.717535 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 92 win 32120 (DF) > 21:33:06.902977 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: P 70:72(2) ack 92 win 32120 (DF) ... > 21:33:06.934116 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 72 win 953 > 21:33:06.935726 208.206.76.71.telnet > shadow.linuxexperts.com.1591: P 92:94(2) ack 72 win 953 > 21:33:06.947563 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: . ack 94 win 32120 (DF) > 21:33:59.744629 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: F 72:72(0) ack 94 win 32120 (DF) ... > 21:33:59.779266 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 > 21:33:59.937582 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: F 72:72(0) ack 94 win 32120 (DF) ... > 21:33:59.979179 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 > 21:34:00.280382 208.206.76.71.telnet > shadow.linuxexperts.com.1591: . ack 73 win 953 > 21:34:00.280694 shadow.linuxexperts.com.1591 > 208.206.76.71.telnet: R 2126260978:2126260978(0) win 0 ... > Its like the ARC has stopped responding to the telnet session right? hmm, its more like "shadow" terminated the session. starting with "F 72:72(0)" it seems strange. FIN packet was sent with sequence 72:72(0), that is 0 bytes data. FIN should be sent only if session is about to terminate, right? ack from ARC should point at next expected sequence number. And there it is, 73. (Similar sequence can be seen at start of tcp session, when initial sequence numbers are exchanged: "xx:xx(0)" -> "zz:zz(0) ack xx+1" -> "ack zz+1", so ARC seems behaving ok.) Maybe it should be 72, as shadow has stated it is expecting to use 72 as its next sequence number, and maybe they do not agree from here on. Both seem to be confused. Perhaps 73 seems to be invalid for shadow, so it drops it, retransmits 72:72(0) and waits longer. ARC again ack's with 73 which is ignored, has opportunity to retransmit its ack one more time, and then shadow decides to send out RST, terminating the session (or "intruder"). Because nodes do not agree on sequencing, ARC drops the RST packet considering it invalid, and the session gets stuck. Seems like typical problem with RFC interpretation. Who is to blame is beyond me. > If anyone has seen anything like this please let me know. I am running > 4.1.59-6. never went in too deep, but we've had reports of sessions hanging from our users. not to the ARC itself, but routed http, ftp, pop3 sessions. Never had a chance to chase the problem in realtime. It also seemed that some of the sessions recovered themselves. So I'm not sure if this is related at all. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Senior Network Engineer Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Could you send me you cisco config ? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 23 Jul 1999, Mike Andrews wrote: > On Fri, 23 Jul 1999, Jeff Mcadams wrote: > > > > 206.240.130.0/23 -> Null0 > > > 206.240.130.0/25 -> Ethernet0/0 > > > 206.240.130.128/25 -> contains customer subnets > > > 206.240.131.0/24 -> contains customer subnets > > > > >The problem I'm having is that the HiPer ARC is seeing both > > >206.240.130.0/23 (via OSPF) and 206.240.130.0/25 (local route on eth:1)... > > >and is throwing away the /25 and keeping only the /23 in its routing > > >table. It's keeping the LESS specific route, rather than the MORE > > >specific one. A Cisco will keep them both in its routing table and use > > >the more specific one. > > > > Whoa...its keeping the less specific route rather than the more specific > > *AND* its keeping the ospf route over the local one which is also broken > > IMHO...that of course being if the specificity were the same, the local > > should be prefered. > > > Actually, on second look, it's even weirder: > > fra1-arc> list ip route > > IP ROUTES > Destination Prot NextHop Metric Interface > 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 > 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 > 206.240.130.12/H LOCAL 206.240.130.12 1 eth:1 > 206.240.130.128/28 OSPF 206.240.130.11 84 eth:1 > 206.240.131.0/C OSPF 206.240.130.6 20 eth:1 > (lots of other routes deleted) > > .130.12 is the ARC in question. > > It looks like it's taking the OSPF route, but installing it as if it was a > local route -- so what's really wrong here is the netmask it's storing. > > Traceroutes from this ARC to .130.2 bounce through .130.1 first, which > makes even less sense. > > On other ARC that is on the .130.128/28 network, it has .130.0/23 as an > OSPF route as it should be, but, .130.0/25 is still completely missing. > > Weird stuff. Definitely a problem. > > 3Com? > > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > "If you're not part of the solution.... you're part of the precipitate." > > > - > 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 Kelly, The problem here is your client either have the wrong configuration on the dialup client or the client is dialling in the chassis and trying to get a network connection with out a IP stack, If you dial in with a dumb terminal you will see this IP address 0.0.0.0 . The problem here is on your client side. Regards Ray Whelan Kelly Peterson <kellyp@compusmart.ab.ca> on 16/07/99 17:08:20 Please respond to usr-tc@lists.xmission.com Sent by: Kelly Peterson <kellyp@compusmart.ab.ca> cc: (Ray Whelan/IE/3Com) The problem doesn't seem to be totally random. That is some clients are prone to getting it while most never get it. Our syslog entries look like this: Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", Level "COMMON":: Port slot:2/mod:4 user ight session connected, call id 16974191, protocol: PPP - ip address: 0.0.0.0 Jul 15 20:27:11 ns19.interbaun.com At 20:29:22, Facility "Auth Facility", Level "COMMON":: Port slot:2/mod:4 user ight session disconnected, call id 16974191, protocol: PPP - ip address 0.0.0.0 This particular user is running Windows 98 and is using a Winmodem LT. Any help would be appreciated. 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.

Thus spake Peter D. Mayer >The funky numbering scheme seems to come from the fact that the ARC is set by >default to allow 256 ports per slot. So slot 1 reports ports 1-256, slot 2 >reports 257-512, slot 3 is 513-768, etc. >Someone posted this command a while ago to make the port numbering more >sane. I know this affects RADIUS NAS-Port numbers, but I don't know if >it changes the numbering for SNMP. >set pbus reported_port_density 24 I know it can be adjusted...that still doesn't address the fact that its wildly inconsistent depending upon how you address the ports. There are at least 3 ways to address a physical port (NMC SNMP, Arc SNMP, Arc RADIUS) and all 3 use different numbering schemes...that wouldn't be too bad except all 3 use the same concept for it, just variations on it. You'd think if they were going to at least *try* to be consistent, they'd be able to do that, but they seem to have failed miserably in this and just made it even *more* confusing by making people think the numbering would be the same and then not be. >This means Slot 1 reports ports 1-24, slot 2 reports ports 25-48, slot >3 reports 49-72, etc. Much nicer to deal with. Again...except if you're trying to cross-reference with the Arc's SNMP agent, and the NMC's SNMP agent where things are *still* inconsistent. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

It happened on 1 out of 12 here. Still have 13 left to do. I only had to redo the ip pools and auth/acct servers - didn't have to nuke the entire box's config. At 08:09 PM 7/22/99 -0400, you wrote: >same here ... I had to nuke each boxes config and redo it from scratch >(happed on 3 out of 3 boxes so far) . > >----- Original Message ----- >From: John Martin <jmartin@delrio.com> >To: <usr-tc@lists.xmission.com> >Sent: Thursday, July 22, 1999 7:36 PM >Subject: Re: (usr-tc) arc 4.2.29 upgrade killed authentication > > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Thus spake Brian >Yeah, I remember that. I instituted the command and the arc went into >spiral death. Of course this was with 4.0.x a long time ago, maybe >they have fixed it. My main reason for using that command then was >when a tcp session was established between a user and say our mail >server, and the user dropped off, the mail server console would get >flooded with redirect messages (even though the arc had a /25 for an ip >pool, it doesn't insert an aggregate route entry for the /25 into its >routing table, so it looks to the default route (our router) once the >interface goes down. The router of course has that pool routed to the >arc (since in RIPv2 the ARC broadcasts an aggregate /25) and so a small >storm insues between the router and the arc). I always felt, that like >the netserver, the arc should not go sending out traffic for ip's in >its pools to the default route, it should put an entry in its rtab >pertaining to the ip pool in aggregate. Eh...I can definitely see this being a configurable thing...but I don't think necessarily that it should be an absolute. I think I could proly come up with some workarounds for your situation given a few minutes to look at what's going on and figure out how things are interacting. I'm just rather hesitant to have any system automagically insert any routes into its route table without me having told it to do so. The same goes for advertising routes into a routing protocol. I can't say I am a big fan of automatically advertising each IP address of the IP address pool or an aggregate of the pool into the RIP protocol automatically either. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Rick >If you enable the arc to act as an ASBR (in the ospf global table) it >will then redistribute any static or rip routes (including those listed >in any radius profiles) into ospf. See...that just seems backwards...you should tell the Arc what to advertise where, and from that the Arc should figure out whether its an ASBR, ABR, both or neither. As it is, you're telling it whether its an ASBR, ABR, both or netiher, and from that its determining what it should advertise where. That just seems to be reversing cause and effect. >Just watch out when you upgrade any arc from 4.59-6......we lost our ppp and >authentication settings on some of them.... Yeah...so I'm hearing...I think I'll back off on my plans to do this next week so I can come up with a way to make it a bit smoother (I think maybe its time to generate a bulk config file :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

If you do a SAVE CONFIG and SAVE ALL, would that eliminate this problem? Which parameters were lost on your setups? Thanks, Scott Boggs Network Administrator United Bank > -----Original Message----- > From: Clayton Zekelman [SMTP:clayton@MNSi.Net] > Sent: Friday, July 23, 1999 10:22 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) arc 4.2.29 upgrade killed authentication > > It happened on 1 out of 12 here. Still have 13 left to do. > > I only had to redo the ip pools and auth/acct servers - didn't have to > nuke > the entire box's config. > > At 08:09 PM 7/22/99 -0400, you wrote: > >same here ... I had to nuke each boxes config and redo it from scratch > >(happed on 3 out of 3 boxes so far) . > > > >----- Original Message ----- > >From: John Martin <jmartin@delrio.com> > >To: <usr-tc@lists.xmission.com> > >Sent: Thursday, July 22, 1999 7:36 PM > >Subject: Re: (usr-tc) arc 4.2.29 upgrade killed authentication > > > > > > --- > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 875 Ouellette Avenue > Windsor, Ontario > N9A 4J6 > > tel. 519-985-8410 > fax. 519-258-3009 > > - > 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 know what the command: set user <user> dnis_reauthentication enabled|disabled does? I'm curious...perhaps this is the magic make the user re-auth with PAP after a DNIS|ANI auth switch? Has anyone used this and/or found out what it does? I've looked in the documentation and its (as is not terribly uncommon) rather vague to say the least. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

"save all" right before upgrading doesn't help at all. Since I started this, I might as well mention that I got the same results when I upgraded our other two ARCs -- lost accounting and authentication settings, and ppp authentication preference had to be reset back to PAP. I didn't lose any IP pools or anything else though. The release notes mention that they made some changes to Radius to make it more RFC compliant, but it didn't seem like anything that was worth blowing the config away for. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY "If you're not part of the solution.... you're part of the precipitate." On Fri, 23 Jul 1999, Scott Boggs wrote: > If you do a SAVE CONFIG and SAVE ALL, would that eliminate > this problem? Which parameters were lost on your setups? > Thanks, > Scott Boggs > Network Administrator > United Bank > > > > -----Original Message----- > > From: Clayton Zekelman [SMTP:clayton@MNSi.Net] > > Sent: Friday, July 23, 1999 10:22 AM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) arc 4.2.29 upgrade killed authentication > > > > It happened on 1 out of 12 here. Still have 13 left to do. > > > > I only had to redo the ip pools and auth/acct servers - didn't have to > > nuke > > the entire box's config. > > > > At 08:09 PM 7/22/99 -0400, you wrote: > > >same here ... I had to nuke each boxes config and redo it from scratch > > >(happed on 3 out of 3 boxes so far) . > > > > > >----- Original Message ----- > > >From: John Martin <jmartin@delrio.com> > > >To: <usr-tc@lists.xmission.com> > > >Sent: Thursday, July 22, 1999 7:36 PM > > >Subject: Re: (usr-tc) arc 4.2.29 upgrade killed authentication > > > > > > > > > > --- > > Clayton Zekelman > > Managed Network Systems Inc. (MNSi) > > 875 Ouellette Avenue > > Windsor, Ontario > > N9A 4J6 > > > > tel. 519-985-8410 > > fax. 519-258-3009 > > > > - > > 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. >

OK...have a customer with a Cisco router that during LCP is is requesting that our Arc's authentication with PAP to him. While this most likely isn't a critical issue as I don't think it'll be terribly difficult to get the cisco to quit requesting that, I would like to be able to prevent something like this from happening again in the future. The crux of the problem is that the HiPer Arc, during LCP, agrees to authenticate with the remote end, but of course I don't have my equipment set up with an authentication username and password, so it then never starts up its PAP authentication requests with the remote side, so eventually the remote side just hangs up. Is there any way that anyone knows of to tell the Arcs to not accept a request for PAP authentication from the remote end during LCP? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I just noticed a strange problem here after upgrading all my ARCs. If it sees two routes for the same network number but with two different netmasks, it's taking the LESS specific route instead of the MORE specific route. This sounds weird, and maybe I'm just doing something really damn stupid, but I'll try to explain... We have 3 different netblocks, and in our border router, we have routes to Null0 covering the entirety of these netblocks. This is partly for the benefit of BGP (with my current BGP config, if I remove them, our routes don't get advertised).... and partly so that if someone tries to send something to an unused block, the traffic gets dropped, rather than creating a routing loop. All of the normal routes (static and OSPF) are of course there to cover the real subnets we have -- the large route is just there to cover the subnets we don't have and to provide an aggregate that BGP can announce. So in just the first netblock (206.240.130.0/23), for example, the routing table on our Cisco looks like this: 206.240.130.0/23 -> Null0 206.240.130.0/25 -> Ethernet0/0 206.240.130.128/25 -> contains customer subnets 206.240.131.0/24 -> contains customer subnets ...where the Cisco's Ethernet0/0 is attached to the LAN with most of our HiPer ARCs on it. Note the network number is the same as the aggregate but with a different mask. The problem I'm having is that the HiPer ARC is seeing both 206.240.130.0/23 (via OSPF) and 206.240.130.0/25 (local route on eth:1)... and is throwing away the /25 and keeping only the /23 in its routing table. It's keeping the LESS specific route, rather than the MORE specific one. A Cisco will keep them both in its routing table and use the more specific one. The upshot is that it's routing all traffic through the Cisco to get to something on the same LAN. This is a pretty stupid thing for it to do, especially on a LAN segment that is already busier than it needs to be. If this doesn't make sense I can post my routing tables and Cisco config... but can anyone see anything really obviously dumb that I'm doing, other than maybe fixing my BGP config (which I may do anyway)? (I'm going to be in Chicago this weekend -- maybe I should just go hunt down some 3Com engineers :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY "If you're not part of the solution.... you're part of the precipitate."

Thus spake Mike Andrews >I just noticed a strange problem here after upgrading all my ARCs. If it >sees two routes for the same network number but with two different >netmasks, it's taking the LESS specific route instead of the MORE specific >route. >This sounds weird, and maybe I'm just doing something really damn stupid, >but I'll try to explain... >We have 3 different netblocks, and in our border router, we have routes to >Null0 covering the entirety of these netblocks. This is partly for the >benefit of BGP (with my current BGP config, if I remove them, our routes >don't get advertised).... and partly so that if someone tries to send >something to an unused block, the traffic gets dropped, rather than >creating a routing loop. Good use of routing a supernet to null0. I used to do some of the same, but haven't kept up with it...I really should update those... > 206.240.130.0/23 -> Null0 > 206.240.130.0/25 -> Ethernet0/0 > 206.240.130.128/25 -> contains customer subnets > 206.240.131.0/24 -> contains customer subnets >The problem I'm having is that the HiPer ARC is seeing both >206.240.130.0/23 (via OSPF) and 206.240.130.0/25 (local route on eth:1)... >and is throwing away the /25 and keeping only the /23 in its routing >table. It's keeping the LESS specific route, rather than the MORE >specific one. A Cisco will keep them both in its routing table and use >the more specific one. Whoa...its keeping the less specific route rather than the more specific *AND* its keeping the ospf route over the local one which is also broken IMHO...that of course being if the specificity were the same, the local should be prefered. >If this doesn't make sense I can post my routing tables and Cisco >config... but can anyone see anything really obviously dumb that I'm >doing, other than maybe fixing my BGP config (which I may do anyway)? Don't "fix" your BGP config...its right as it is. I don't see anything obviously wrong... I'm setting up a little bit of a lab environment to play with an Arc or two doing OSPF with a cisco and a xedia...I'll be sure to check this out to confirm what's going on. Give me a holler if you need, I think you have my number here. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Tatai SV Krishnan >Well if you want to know what all you can do with it - probable in a >day or two I can come up with a document. Oh...I've already come up with some possible applications based on its behavior...was just trying to confirm that this is indeed what the behavior was. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 23 Jul 1999, Jeff Mcadams wrote: > > 206.240.130.0/23 -> Null0 > > 206.240.130.0/25 -> Ethernet0/0 > > 206.240.130.128/25 -> contains customer subnets > > 206.240.131.0/24 -> contains customer subnets > > >The problem I'm having is that the HiPer ARC is seeing both > >206.240.130.0/23 (via OSPF) and 206.240.130.0/25 (local route on eth:1)... > >and is throwing away the /25 and keeping only the /23 in its routing > >table. It's keeping the LESS specific route, rather than the MORE > >specific one. A Cisco will keep them both in its routing table and use > >the more specific one. > > Whoa...its keeping the less specific route rather than the more specific > *AND* its keeping the ospf route over the local one which is also broken > IMHO...that of course being if the specificity were the same, the local > should be prefered. Actually, on second look, it's even weirder: fra1-arc> list ip route IP ROUTES Destination Prot NextHop Metric Interface 0.0.0.0/0 NetMgr 206.240.130.1 1 eth:1 206.240.130.0/23 LOCAL 206.240.130.1 1 eth:1 206.240.130.12/H LOCAL 206.240.130.12 1 eth:1 206.240.130.128/28 OSPF 206.240.130.11 84 eth:1 206.240.131.0/C OSPF 206.240.130.6 20 eth:1 (lots of other routes deleted) .130.12 is the ARC in question. It looks like it's taking the OSPF route, but installing it as if it was a local route -- so what's really wrong here is the netmask it's storing. Traceroutes from this ARC to .130.2 bounce through .130.1 first, which makes even less sense. On other ARC that is on the .130.128/28 network, it has .130.0/23 as an OSPF route as it should be, but, .130.0/25 is still completely missing. Weird stuff. Definitely a problem. 3Com? Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY "If you're not part of the solution.... you're part of the precipitate."

> > Good use of routing a supernet to null0. I used to do some of the same, > but haven't kept up with it...I really should update those... I always routed the Supernets to Loopback0, mostly for the nailing the routes for BGP..........I am wondering if I too should move to Null0 instead of Loopback0. > -- > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

This is more of a general RADIUS question, but I post it here because it may be related to my TCs. Our company is going to be using RADIUS proxy starting Monday... using Cistron's package. A limitation of this is that CHAP authenication cannot be used for proxy auth requests. The solution to this would appear simple, so I changed all my TCs weeks ago to SET PPP AUTHENICATION_PREFERENCE PAP (or so), instead of the default of CHAP. My understanding is this will still allow CHAP logins, but the server will request the user uses PAP first. My allowed auth types is set to 'ALL'. Watching the progress of my RADIUS servers seems to indicate this is all well, with only a handful of CHAP logins after the change. The problem is, the next day I got a fairly large number of people calling us telling us that they cannot get in. Changed the preference back, and they were able to get in. One of them was a Webramp, which surprised me... my understanding being that Webramp preferred PAP. Anyway, has anyone had this same problem? Was it with particular equipment? What was done to fix it? Thanx in advance. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Do you have existing Quad Modem Cards in your Total Control Chassis? There are only 5 days left to participate in the Quad Trade-Up Program. - - see http://www.3com.com/promotions/hipertrade/index2.html for details and program rules or call 3Com's Quad Trade Up Program hot line at 1-800-475-2588 or e-mail us at tradeup@mw.3Com.com. Please note, Quad Modems eligible for trade up are currently installed modems within the ISPs POP. Customers must have purchased the Quad Modems more than 120 days prior to submission under the Program to be eligible for trade-up under the current rules. Other rules and restrictions may apply.

Thus spake Brian >> Good use of routing a supernet to null0. I used to do some of the same, >> but haven't kept up with it...I really should update those... >I always routed the Supernets to Loopback0, mostly for the nailing the >routes for BGP..........I am wondering if I too should move to Null0 >instead of Loopback0. Don't think it really matters all that much...figure out which one is fast switched and use it. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Ithought this had been extened to the end of august! -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcom Administrator 1 Sent: Friday, July 23, 1999 2:26 PM Do you have existing Quad Modem Cards in your Total Control Chassis? There are only 5 days left to participate in the Quad Trade-Up rogram. - - see http://www.3com.com/promotions/hipertrade/index2.html for details and program rules or call 3Com's Quad Trade Up Program hot line at 1-800-475-2588 or e-mail us at tradeup@mw.3Com.com. Please note, Quad Modems eligible for trade up are currently installed modems within the ISPs POP. Customers must have purchased the Quad Modems more than 120 days prior to submission under the Program to be eligible for trade-up under the current rules. Other rules and restrictions may apply. - 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.

On Fri, 23 Jul 1999, Jeff Mcadams wrote: > Thus spake Brian > >> Good use of routing a supernet to null0. I used to do some of the same, > >> but haven't kept up with it...I really should update those... > > >I always routed the Supernets to Loopback0, mostly for the nailing the > >routes for BGP..........I am wondering if I too should move to Null0 > >instead of Loopback0. > > Don't think it really matters all that much...figure out which one is > fast switched and use it. :) I would think(hope) both are fast switched :), its not like its policy routing or anything. > -- > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Hello, has anyone made a Cisco 7xx work with the Hiper chassis? If so, I would be very appreciative if you could send a working config. for the 7xx. Thanks and have a good weekend. blake > -----Original Message----- > From: K Mitchell [mailto:mitch@keyconn.net] > Sent: Tuesday, July 13, 1999 10:24 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Which ISDN modem > > > At 08:39 AM 7/13/99 -0400, Scot Desort wrote: > >Kirk- > > > >Netopia P/N's: > > > >R3100-UP-12 = 12 User NAT, ISDN-U interface, 2 POTS jacks > >R3100-U-12 = 12 User NAT, ISDN-U interface, no POTS jacks > > > >Both models include an integrated 8 port ethernet hub (10baseT) > > Got it, thanks. They currently have their LAN set up with a 3Com > SuperStack hub, so I'd just be plugging it into the uplink > port(1). They > have about 30 workstations on the LAN, but only have a need > for 6-8 to have > Internet connectivity, so the 12-user NAT would suffice, or do I need > unlimited? > Also, I'm kinda unclear on the POTS jacks(can you tell I'm > new at this? > :) A phone or fax machine plugged into them, when used, would > cause the > router to drop one of the B channels and use it to make an > analog call? > What about receiving calls? > > Thanks again, > Kirk > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > 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. >

Thus spake Brian >On Fri, 23 Jul 1999, Jeff Mcadams wrote: >> Don't think it really matters all that much...figure out which one is >> fast switched and use it. :) >I would think(hope) both are fast switched :), its not like its policy >routing or anything. I know one, not too terribly long ago, was process switched...that may have been changed fairly recently so both are fast switched anymore...not sure. FWIW, most policy routing is fast switched in 11.3 and later I believe...you can still set up some funky policies that make it fall back to process switching, but for the most part its fast switched. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Looking for 2-5 AC Fan Trays for USR Total Control Hubs. These are the external style. If you have any you would like to sell please contact me. Thanks....Steve Steve Rivera - VP-WRCA, INC. email: sales@wrca.net 732-833-2111 WAN ACCESS SPECIALIST---http://www.wrca.net (Complete Inventory Listing) Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone & More

On Mon, 26 Jul 1999 pferraro@wna-linknet.com wrote: > > What is the command that I can use at the CLI to change the IP > address of a HiperArc? Or do I need to "step-thru" the Quick_Setup to do > this? I do not want to do it while the HiperArc is connected to the > network, because we are going to give it an IP of an existing HARC so that > we can "switch" them out... set ip network "ip" interface eth:1 address xxx.xxx.xxx.xxx/xx > > Thanks in advance! > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

What is the command that I can use at the CLI to change the IP address of a HiperArc? Or do I need to "step-thru" the Quick_Setup to do this? I do not want to do it while the HiperArc is connected to the network, because we are going to give it an IP of an existing HARC so that we can "switch" them out... Thanks in advance! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Has anyone had any problems with multilink PPP performance lately? Seems like after going to DSP version 2.0.19 (with either 4.1.59-6 or 4.2.29 ARC code), we've been getting complaints about sluggish multilink PPP performance -- whether it's ISDN or dual modem. Disabling PPP offloading seems to help things slightly, but I'm a bit afraid of what bugs I might reintroduce by doing that. Seems like 3Com Impact IQ's have more trouble bringing up two channels with offloading disabled (but will do it most of the time). Also, with at least ARC 4.2.29, having software compression enabled on the ARC causes users with NT4 SP3 to have serious problems logging it. From looking at a trace of the PPP packets, it looks like it repeatedly tries to negotiate CCP parameters, then finally gives up and continues with each end using an incompatible compression protocol... so the user logs in OK and gets an IP address but you can't ping them or pass IP traffic because of the compression problem. I don't know if this is specific to SP3 or not yet because I haven't had the opportunity to test anything else -- we just shut compression off on the server to take care of it. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY "If you're not part of the solution.... you're part of the precipitate."

-----Original Message----- >At 01:17 AM 7/21/99 +1000, "Brett Murphy" <me@murf.net> wrote: >> Hi All, When I enter a set modem all message command on 4.2.29 with a >>message thats longer than about 210 characters the HyperARC reboots! >>Enjoy... > >And you can't get by with a shorter message? :) Thats not the point! The fact is it worked with the previous firmware. > > >-- >Kirk Mitchell-General Manager mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > 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. >

We have unlimited sets of new HiPer DSP cardsets available with our end of year special pricing. 3446 - Qty 2 - HiPer DSP Card 24port modem cards, V.90 - Qualifies you to trade in 12-Quad cards for another 48 ports of DSP Cards.... Only $8250 3556 - Qty 4 - HiPer DSP Cardsets, 96 ports, $12,000 Special offer only until This Friday July 30th. Call for details. Call us at 877-Dynavar before you buy and we'll save you at least $250 or a Palm Pilot. Regards, Greg Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.

For any of those interested- (please archive for future reference) PC Global, Inc has moved to a larger location 25,000 SQ FT warehouse stocked with goodies for you(And one without any hurricanes- :-) The new address: PC Global, Inc 4910 E Siesta Bldg #2 Phoenix, AZ 85040 Tel: 602 438-6200 Fax: 602 438-1119 Any problems with reaching us? Call (305) 216-8638-this is one line that will for sure get us. This is effective August 10, 1999. Until then, the same old address- PC Global, Inc 7010 SW 63rd Avenue South Miami, FL 33143 Tel: (305) 667-2111 Fax:(305) 667-3636 We look forward to continued business with everyone at our new location. And sorry for this interruption- With Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

On Mon, 26 Jul 1999, Mike Andrews wrote: > Has anyone had any problems with multilink PPP performance lately? definitly. > > Seems like after going to DSP version 2.0.19 (with either 4.1.59-6 or > 4.2.29 ARC code), we've been getting complaints about sluggish multilink > PPP performance -- whether it's ISDN or dual modem. I saw problems with 2.0.81...........is 2.0.19 suppose to be better suited than 2.0.81? > > Disabling PPP offloading seems to help things slightly, but I'm a bit > afraid of what bugs I might reintroduce by doing that. Seems like 3Com > Impact IQ's have more trouble bringing up two channels with offloading > disabled (but will do it most of the time). > > Also, with at least ARC 4.2.29, having software compression enabled on the > ARC causes users with NT4 SP3 to have serious problems logging it. From > looking at a trace of the PPP packets, it looks like it repeatedly tries > to negotiate CCP parameters, then finally gives up and continues with each > end using an incompatible compression protocol... so the user logs in OK > and gets an IP address but you can't ping them or pass IP traffic because > of the compression problem. I don't know if this is specific to SP3 or > not yet because I haven't had the opportunity to test anything else -- we > just shut compression off on the server to take care of it. > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > "If you're not part of the solution.... you're part of the precipitate." > > > - > 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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

I need an HiPer DSP E1.... i'm in Argentina.... Javier -----Original Message----- Friday, July 30th >We have unlimited sets of new HiPer DSP cardsets available with our end of >year special pricing. > >3446 - Qty 2 - HiPer DSP Card 24port modem cards, V.90 - Qualifies you to >trade in 12-Quad cards for another 48 ports of DSP Cards.... Only $8250 > >3556 - Qty 4 - HiPer DSP Cardsets, 96 ports, $12,000 Special offer only >until This Friday July 30th. Call for details. > >Call us at 877-Dynavar before you buy and we'll save you at least $250 or a >Palm Pilot. > >Regards, Greg > >Gregory F. Genge, President, Dynavar Networking, Inc. >Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, >5005 Fax, http://www.dynavar.com >#300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 >Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, >Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, >Microcom (Compaq), Garrett, Sonic, Cobalt. > >- > 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. >

- For Sale HiPer DSP cards with 24 modems, V.90 - brand new in the box $3800 each, $7000 for a set. Brand new Hiper ARC cards $5000 David DenHollander (403)254-1100 Main (403)201-2815 Fax

I have an E1 daughter card for the HiperDSP I can sell you. John AEI Internet > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Hostmaster Soho > Solutions - Javier Szyszlican > Sent: Tuesday, July 27, 1999 3:06 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) FS: Specials on HiPer DSP's, Quad Trade-in ends > this Friday, July 30th > > > I need an HiPer DSP E1.... i'm in Argentina.... > > Javier > -----Original Message----- > From: Greg Genge <greg@dynavar.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Tuesday, July 27, 1999 4:06 PM > Subject: (usr-tc) FS: Specials on HiPer DSP's, Quad Trade-in ends this > Friday, July 30th > > > >We have unlimited sets of new HiPer DSP cardsets available with > our end of > >year special pricing. > > > >3446 - Qty 2 - HiPer DSP Card 24port modem cards, V.90 - Qualifies you to > >trade in 12-Quad cards for another 48 ports of DSP Cards.... Only $8250 > > > >3556 - Qty 4 - HiPer DSP Cardsets, 96 ports, $12,000 Special offer only > >until This Friday July 30th. Call for details. > > > >Call us at 877-Dynavar before you buy and we'll save you at > least $250 or a > >Palm Pilot. > > > >Regards, Greg > > > >Gregory F. Genge, President, Dynavar Networking, Inc. > >Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, > >5005 Fax, http://www.dynavar.com > >#300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 > >Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), > WatchGuard, > >Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, > Compatible, > >Microcom (Compaq), Garrett, Sonic, Cobalt. > > > >- > > 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. >

I am having some difficulty setting up ias to authenticate against a hiper arc. I am successfully able to logon with a username and password when it resides in the hiper arc's user database. Can anyone tell me what attributes I require? I currently have the following. Framed-Protocol: PPP Service-Type: Framed Idle-Timeout: 1200 Framed-Compression: Van-Jacobsen-TCP-IP Framed-IP-Address: 255.255.255.254 Framed-IP-Netmask: 255.255.255.255 Framed-MTU: 1500 Framed-Routing: None Port-Limit: 2 Thanks.

I'm now authenticating but get malformed packets and no record in the accounting log. -----Original Message----- Sent: Tuesday, July 27, 1999 7:01 PM I am having some difficulty setting up ias to authenticate against a hiper arc. I am successfully able to logon with a username and password when it resides in the hiper arc's user database. Can anyone tell me what attributes I require? I currently have the following. Framed-Protocol: PPP Service-Type: Framed Idle-Timeout: 1200 Framed-Compression: Van-Jacobsen-TCP-IP Framed-IP-Address: 255.255.255.254 Framed-IP-Netmask: 255.255.255.255 Framed-MTU: 1500 Framed-Routing: None Port-Limit: 2 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.

This probably sounds stupid, but I'm not sure how to interpret this. I was reaching max modem useage, and did a MON PPP on a few of the users that had been on the longest to verify activity, and the following came up in one of the traces. Is it some sort of keep-alive, or am I mis-interpreting the "Connection: Keep-Alive" notation? Incoming PPP Data on interface: slot:1/mod:11 2d 70 09 ee ce 00 1d 00 47 45 54 20 2f 73 65 72 |-p GET /ser| 76 6c 65 74 2f 42 42 53 65 72 76 6c 65 74 3f 73 |vlet/BBServlet?s| 69 64 3d 31 33 35 38 34 31 30 26 70 61 67 65 3d |id=1358410&page=| 63 6f 6e 74 72 6f 6c 2d 6c 65 66 74 2e 68 74 6d |control-left.htm| 6c 26 75 6e 69 71 75 65 3d 36 34 31 35 33 20 48 |l&unique=64153 H| 54 54 50 2f 31 2e 30 0d 0a 52 65 66 65 72 65 72 |TTP/1.0 Referer| 3a 20 68 74 74 70 3a 2f 2f 62 62 6c 69 74 7a 2e |: http://bblitz.| 75 70 72 6f 61 72 2e 63 6f 6d 2f 73 65 72 76 6c |uproar.com/servl| 65 74 2f 42 42 53 65 72 76 6c 65 74 0d 0a 43 6f |et/BBServlet Co| 6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65 70 2d 41 |nnection: Keep-A| 6c 69 76 65 0d 0a 55 73 65 72 2d 41 67 65 6e 74 |live User-Agent| 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 34 20 5b |: Mozilla/4.04 [| 65 6e 5d 20 28 57 69 6e 39 35 3b 20 49 20 3b 4e |en] (Win95; I ;N| 61 76 29 0d 0a 48 6f 73 74 3a 20 62 62 6c 69 74 |av) Host: bblit| 7a 2e 75 70 72 6f 61 72 2e 63 6f 6d 0d 0a 41 63 |z.uproar.com Ac| 63 65 70 74 3a 20 69 6d 61 67 65 2f 67 69 66 2c |cept: image/gif,| 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 70 | image/x-xbitmap| 2c 20 69 6d 61 67 65 2f 6a 70 65 67 2c 20 69 6d |, image/jpeg, im| 61 67 65 2f 70 6a 70 65 67 2c 20 69 6d 61 67 65 |age/pjpeg, image| 2f 70 6e 67 2c 20 2a 2f 2a 0d 0a 41 63 63 65 70 |/png, */* Accep| 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 6e 0d 0a |t-Language: en | 41 63 63 65 70 74 2d 43 68 61 72 73 65 74 3a 20 |Accept-Charset: | 69 73 6f 2d 38 38 35 39 2d 31 2c 2a 2c 75 74 66 |iso-8859-1,*,utf| 2d 38 0d 0a 45 78 74 65 6e 73 69 6f 6e 3a 20 53 |-8 Extension: S| 65 63 75 72 69 74 79 2f 52 65 6d 6f 74 65 2d 50 |ecurity/Remote-P| 61 73 73 70 68 72 61 73 65 0d 0a 43 6f 6f 6b 69 |assphrase Cooki| 65 3a 20 4e 47 55 73 65 72 49 44 3d 64 31 34 39 |e: NGUserID=d149| 32 33 30 63 2d 31 31 31 2d 39 33 32 36 39 32 32 |230c-111-9326922| 32 31 2d 37 3b 20 50 6c 61 79 65 72 49 44 3d 32 |21-7; PlayerID=2| Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Your mis-interpreting it. This is a standard web page download. At 08:07 PM 7/27/99 , you wrote: >This probably sounds stupid, but I'm not sure how to interpret this. I was >reaching max modem useage, and did a MON PPP on a few of the users that had >been on the longest to verify activity, and the following came up in one of >the traces. Is it some sort of keep-alive, or am I mis-interpreting the >"Connection: Keep-Alive" notation? > >Incoming PPP Data on interface: slot:1/mod:11 > 2d 70 09 ee ce 00 1d 00 47 45 54 20 2f 73 65 72 |-p GET /ser| > 76 6c 65 74 2f 42 42 53 65 72 76 6c 65 74 3f 73 |vlet/BBServlet?s| > 69 64 3d 31 33 35 38 34 31 30 26 70 61 67 65 3d |id=1358410&page=| > 63 6f 6e 74 72 6f 6c 2d 6c 65 66 74 2e 68 74 6d |control-left.htm| > 6c 26 75 6e 69 71 75 65 3d 36 34 31 35 33 20 48 |l&unique=64153 H| > 54 54 50 2f 31 2e 30 0d 0a 52 65 66 65 72 65 72 |TTP/1.0 Referer| > 3a 20 68 74 74 70 3a 2f 2f 62 62 6c 69 74 7a 2e |: http://bblitz.| > 75 70 72 6f 61 72 2e 63 6f 6d 2f 73 65 72 76 6c |uproar.com/servl| > 65 74 2f 42 42 53 65 72 76 6c 65 74 0d 0a 43 6f |et/BBServlet Co| > 6e 6e 65 63 74 69 6f 6e 3a 20 4b 65 65 70 2d 41 |nnection: Keep-A| > 6c 69 76 65 0d 0a 55 73 65 72 2d 41 67 65 6e 74 |live User-Agent| > 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e 30 34 20 5b |: Mozilla/4.04 [| > 65 6e 5d 20 28 57 69 6e 39 35 3b 20 49 20 3b 4e |en] (Win95; I ;N| > 61 76 29 0d 0a 48 6f 73 74 3a 20 62 62 6c 69 74 |av) Host: bblit| > 7a 2e 75 70 72 6f 61 72 2e 63 6f 6d 0d 0a 41 63 |z.uproar.com Ac| > 63 65 70 74 3a 20 69 6d 61 67 65 2f 67 69 66 2c |cept: image/gif,| > 20 69 6d 61 67 65 2f 78 2d 78 62 69 74 6d 61 70 | image/x-xbitmap| > 2c 20 69 6d 61 67 65 2f 6a 70 65 67 2c 20 69 6d |, image/jpeg, im| > 61 67 65 2f 70 6a 70 65 67 2c 20 69 6d 61 67 65 |age/pjpeg, image| > 2f 70 6e 67 2c 20 2a 2f 2a 0d 0a 41 63 63 65 70 |/png, */* Accep| > 74 2d 4c 61 6e 67 75 61 67 65 3a 20 65 6e 0d 0a |t-Language: en | > 41 63 63 65 70 74 2d 43 68 61 72 73 65 74 3a 20 |Accept-Charset: | > 69 73 6f 2d 38 38 35 39 2d 31 2c 2a 2c 75 74 66 |iso-8859-1,*,utf| > 2d 38 0d 0a 45 78 74 65 6e 73 69 6f 6e 3a 20 53 |-8 Extension: S| > 65 63 75 72 69 74 79 2f 52 65 6d 6f 74 65 2d 50 |ecurity/Remote-P| > 61 73 73 70 68 72 61 73 65 0d 0a 43 6f 6f 6b 69 |assphrase Cooki| > 65 3a 20 4e 47 55 73 65 72 49 44 3d 64 31 34 39 |e: NGUserID=d149| > 32 33 30 63 2d 31 31 31 2d 39 33 32 36 39 32 32 |230c-111-9326922| > 32 31 2d 37 3b 20 50 6c 61 79 65 72 49 44 3d 32 |21-7; PlayerID=2| > >Thanks, >Kirk > >-- >Kirk Mitchell-General Manager mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > 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.

Just remember that if you don't put it in radius it will pull the values off the chassis from the "default" user. Currently we just use basic IIS Authentication services which comes with IIS 4.0. > Framed-Protocol: PPP > Service-Type: Framed > Idle-Timeout: 1200 > Framed-Compression: Van-Jacobsen-TCP-IP > Port-Limit: 2 > Framed-MTU: 1500 I think this is what I have. Brian Gordon, MCP Network Administrator Westelcom Internet 518.566.6726 Voice administrator@westelcom.com ----- Original Message ----- Sent: Tuesday, July 27, 1999 10:01 PM > I am having some difficulty setting up ias to authenticate against a hiper > arc. I am successfully able to logon with a username and password when it > resides in the hiper arc's user database. Can anyone tell me what > attributes I require? > > I currently have the following. > > Framed-Protocol: PPP > Service-Type: Framed > Idle-Timeout: 1200 > Framed-Compression: Van-Jacobsen-TCP-IP > Framed-IP-Address: 255.255.255.254 > Framed-IP-Netmask: 255.255.255.255 > Framed-MTU: 1500 > Framed-Routing: None > Port-Limit: 2 > > 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. >

My accounting log does not work either with IAS. Make sure you using PAP. ----- Original Message ----- Sent: Tuesday, July 27, 1999 11:00 PM > I'm now authenticating but get malformed packets and no record in the > accounting log. > > -----Original Message----- > From: Jolliffe, Anu [mailto:ajolliffe@imagen.net] > Sent: Tuesday, July 27, 1999 7:01 PM > To: 'usr-tc@lists.xmission.com' > Subject: (usr-tc) microsoft ias radius and hiper arc > > > I am having some difficulty setting up ias to authenticate against a hiper > arc. I am successfully able to logon with a username and password when it > resides in the hiper arc's user database. Can anyone tell me what > attributes I require? > > I currently have the following. > > Framed-Protocol: PPP > Service-Type: Framed > Idle-Timeout: 1200 > Framed-Compression: Van-Jacobsen-TCP-IP > Framed-IP-Address: 255.255.255.254 > Framed-IP-Netmask: 255.255.255.255 > Framed-MTU: 1500 > Framed-Routing: None > Port-Limit: 2 > > 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. > > - > 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. >

Thanks for the feedback. I fixed all my problems and am now a happy TC camper. On to the FP 2000 extensions.

Is there an Office/Access 2000 version of the 3COm S/A Radius server database yet (still holding my breath for a SQL version) ? We just had to load Access 2000 on one of our web servers, just so we could get the v4.0 ODBC drivers for an Access 2000 database (Hey Microsoft, how about distributing the ODBC drivers seperatley like before ? ) and had to install Access 2000. Of course this will make it difficult down the road in using Access 2000 to read an Access 97 database. If you wonder what I'm talking about, try it sometime. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Has anyone setup VPNs coming off of a HiPerArc and terminating on a Cisco PIXX firewall ? If so, can you share some feedback and what rev of HiperArc code you are running ? Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

IAS (at least the non-WIndows 2000 version) uses the authentication secret for accounting. Try setting the accounting secret on the HiperARC to match the authentication secret. Steve "Jolliffe, Anu" <ajolliffe@imagen.net> on 07/27/99 10:00:29 PM Please respond to usr-tc@lists.xmission.com Sent by: "Jolliffe, Anu" <ajolliffe@imagen.net> cc: (Steve Valiunas/MW/US/3Com) I'm now authenticating but get malformed packets and no record in the accounting log. -----Original Message----- Sent: Tuesday, July 27, 1999 7:01 PM I am having some difficulty setting up ias to authenticate against a hiper arc. I am successfully able to logon with a username and password when it resides in the hiper arc's user database. Can anyone tell me what attributes I require? I currently have the following. Framed-Protocol: PPP Service-Type: Framed Idle-Timeout: 1200 Framed-Compression: Van-Jacobsen-TCP-IP Framed-IP-Address: 255.255.255.254 Framed-IP-Netmask: 255.255.255.255 Framed-MTU: 1500 Framed-Routing: None Port-Limit: 2 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. - 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.

3Com doesn't have an Access 2000 version of S/A, but I've been running our normal 6.0 release under Access 2000 for a while and it seems to work pretty well. I converted the database and ran the 2000 version. Are there any specific problems you have bumped into? STeve jeff.binkley@asacomp.com (Jeff Binkley) on 07/28/99 08:29:00 AM Please respond to usr-tc@lists.xmission.com Sent by: jeff.binkley@asacomp.com (Jeff Binkley) cc: (Steve Valiunas/MW/US/3Com) Is there an Office/Access 2000 version of the 3COm S/A Radius server database yet (still holding my breath for a SQL version) ? We just had to load Access 2000 on one of our web servers, just so we could get the v4.0 ODBC drivers for an Access 2000 database (Hey Microsoft, how about distributing the ODBC drivers seperatley like before ? ) and had to install Access 2000. Of course this will make it difficult down the road in using Access 2000 to read an Access 97 database. If you wonder what I'm talking about, try it sometime. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999 - 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.

I too am interested in VPNs used with HiperArcs... Would be interested in any feedback, setup proceedures, equipment etc... ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Wed, 28 Jul 1999, Jeff Binkley wrote: > > > Has anyone setup VPNs coming off of a HiPerArc and terminating on a > Cisco PIXX firewall ? If so, can you share some feedback and what rev > of HiperArc code you are running ? > > > Thanks, > > Jeff Binkley > ASA Network Computing > > CMPQwk 1.42 9999 > > > - > 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. >

Looking for 4. This is the back card. Slides into the rear of chassis. to interface with backplane which hooks to PSU card in front. Steve Rivera - VP-WRCA, INC. email: sales@wrca.net 732-833-2111 WAN ACCESS SPECIALIST---http://www.wrca.net (Complete Inventory Listing) Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone & More

Steve, I've not converted the database from 97 to 2000. Thus Access 2000 doesn't like to open a database which is in use and allow you to do updates without converting it over. Read only doesn't do much good for administration. I am in the process of writing a complete ASP front end and avoiding the whole issue. I did find the ODBC v4.0 drivers finally on Microsoft's website. They are part of MDAC 2.1 at http://www.microsoft.com/data/ Jeff Binkley ASA Network Computing -> 3Com doesn't have an Access 2000 version of S/A, but I've been running our -> normal 6.0 release under Access 2000 for a while and it seems to work pretty -> well. I converted the database and ran the 2000 version. Are there any -> specific problems you have bumped into? -> -> STeve -> -> jeff.binkley@asacomp.com (Jeff Binkley) on 07/28/99 08:29:00 AM -> Please respond to usr-tc@lists.xmission.com -> -> Sent by: jeff.binkley@asacomp.com (Jeff Binkley) -> -> To: usr-tc@lists.xmission.com -> cc: (Steve Valiunas/MW/US/3Com) -> Subject: (usr-tc) Office 2000 -> -> Is there an Office/Access 2000 version of the 3COm S/A Radius server -> database yet (still holding my breath for a SQL version) ? We just had to -> load Access 2000 on one of our web servers, just so we could get the v4.0 -> ODBC drivers for an Access 2000 database (Hey Microsoft, how about -> distributing the ODBC drivers seperatley like before ? ) and had to install -> Access 2000. Of course this will make it difficult down the road in using -> Access 2000 to read an Access 97 database. If you wonder what I'm talking -> about, try it sometime.

Hello, Has any setup callout? i.e. we call the customer's Netgear 328. -j --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 937-222-8150 FAX: 937-222-8153

This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BED925.1A21E980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am running 4.1.72 and am having a little trouble resolving names from = the command line. it will resolve local names without the domain name attached correctly, = but will not resolve anything else. error message is: icinet>> resolve name yahoo.com CLI - Network Name: yahoo could not be resolved due to a problem interacting with the NameServer. the system has been up for 217 days, which is nice, but I dont know if = this has always been this way, or this just started. I changed nothing = that I know of before this problem was reported. here is the snipped configs: icinet>> li dns servers DNS NAME SERVERS Preference Name Address Status 1 havok.emji.net 12.4.5.5 ACTIVE 2 cyclops.emji.net 207.22.135.5 ACTIVE 3 rogue.emji.net 207.100.24.5 ACTIVE I assume this is something that I am overlooking, any pointers for an = idiot? =20 thanks steve ------=_NextPart_000_0005_01BED925.1A21E980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I am running 4.1.72&nbsp; and am having = a little=20 trouble resolving names from the command line.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>it will resolve local names without the = domain name=20 attached correctly, but will not resolve anything else. error message=20 is:</FONT></DIV> <DIV><FONT face=3DArial size=3D2>icinet&gt;&gt; resolve name = yahoo.com<BR>CLI -=20 Network Name: yahoo<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; could = not be=20 resolved<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; due to a problem=20 interacting with the NameServer.<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>the system has been up for 217 = days,&nbsp; which is=20 nice, but I dont know if this has always been this way, or this just = started. I=20 changed nothing that I know of before this problem was = reported.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>here is the snipped = configs:</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>icinet&gt;&gt; li dns = servers</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>DNS NAME SERVERS<BR>Preference=20 Name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs= p;&nbsp;&nbsp;&nbsp;=20 Address&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 Status<BR>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 havok.emji.net&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 12.4.5.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 ACTIVE<BR>2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 cyclops.emji.net&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb= sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 207.22.135.5&nbsp;&nbsp;&nbsp;=20 ACTIVE<BR>3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 rogue.emji.net&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 207.100.24.5&nbsp;&nbsp;&nbsp; ACTIVE<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>I assume this is something that I am=20 overlooking,&nbsp; any pointers for an idiot?</FONT></DIV> <DIV><FONT face=3DArial size=3D2>&nbsp;</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>thanks</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV> <DIV><FONT face=3DArial size=3D2>steve</FONT></DIV> <DIV><FONT face=3DArial size=3D2>&nbsp;</DIV></FONT></BODY></HTML> ------=_NextPart_000_0005_01BED925.1A21E980--

test __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Hello list, I have 3 questions: 1. Do you consider TCM's Performance Monitor to be a good tool for what it is designed for. If so - good; if not, what would you recommend? 2. Is there are way to "clear/reset" the statistics counters without bumping everyone off? 3. Is there a good reference, in any form, for the functional group parameters that define the parameter, gives "healthy" sample values, and details of what might be the cause of "bad" numbers such as thousands of BLER's within 2 minutes, "excessive attentuation", etc... Thanks for your time. blake

Be Aware.3Com is aware of the games that Dynavar is playing with the quad trade in deal. They will not be accepting quad trade ins from Dyanavar Customers. http://www.3com.com/promotions/hipertrade/quad_to_hiper_rules.html Ed

Why is this guy posting this stuff here. He already posts it in other isp-lists... This is not the place for this. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andrew:PC Global, Inc. Sent: Friday, July 30, 1999 8:00 AM In stock for immediate shipment: (1) Complete US Robotics Total Analog/Digital Control Unit Consisting of: 1 -Netserver PRI 1 -Net Mgt card 15 -Quad V.34 modem cards. 2 -Power supplies (45amp) 1- Fantray Set up token ring Price:$3000 OBO (1) Complete US Robotics Digital Total Control Unit Consisting of: USR Total Control Units 1- Netserver PRI T-1 1 -Net Mgt card 12-Quad V.34 modem cards. 2- Power supplies (45amp) 1- Fantray Set up token ring Price: $3500 OBO No reasonable offers refused! Units guaranteed working We accept Visa/MC/Amex/Discover and COD with references. --Please e-mail in private if interested. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** - 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.

It's called SPAM. To bad he didn't list an 800 number. Gives my modems something to do in the off hours. ;) But he did leave an ICQ number, that's got all kinds of fun security holes in it..... At 08:48 AM 7/30/99 -0700, you wrote: >Why is this guy posting this stuff here. He already posts >it in other isp-lists... This is not the place for this. > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andrew:PC Global, >Inc. >Sent: Friday, July 30, 1999 8:00 AM >To: isp-services@ispc.org; isp-equipment@isp-equipment.com; TCU >Subject: (usr-tc) RE:DIGITAL AND ANALOG USR TCU > > >In stock for immediate shipment: > >(1) Complete US Robotics Total Analog/Digital Control Unit >Warmest Regards, > >Andrew Shlensky >**************************** >PC Global, Inc. >(305) 667-2111 tel >(305) 667-3636 fax >(305) 216-8638 mobile >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >ALSO:SALES of New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** -- Brice Ligget Billings MT ligget@twoalpha.net http://www.twoalpha.net/~bligget DoD#2159 It's as bad as you think -- and they're out to get you.

In stock for immediate shipment: (1) Complete US Robotics Total Analog/Digital Control Unit Consisting of: 1 -Netserver PRI 1 -Net Mgt card 15 -Quad V.34 modem cards. 2 -Power supplies (45amp) 1- Fantray Set up token ring Price:$3000 OBO (1) Complete US Robotics Digital Total Control Unit Consisting of: USR Total Control Units 1- Netserver PRI T-1 1 -Net Mgt card 12-Quad V.34 modem cards. 2- Power supplies (45amp) 1- Fantray Set up token ring Price: $3500 OBO No reasonable offers refused! Units guaranteed working We accept Visa/MC/Amex/Discover and COD with references. --Please e-mail in private if interested. Warmest Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

I have a chassis that I've upgraded to hiperarc and a single hiperdsp (with a bundle package), and as close as it may be to the double-play upgrade it doesnt qualify as one for the recent quad trade in program. Does anyone have a clue why 3com is so strict about this trade in, and if there might be any trade in programs in the future for those of us that got that later bundle upgrade. - lv

If you are about to buy 3COM, Ascend/Lucent, Alteon, or WatchGuard products, you might want to give us a call today at 877-DYNAVAR. Today is the last day of our Fiscal year and we are currently at <bold>$9.5 million</bold> in sales and may possibly break $10Million in annual sales. We are looking to book another $500,000 in orders today (Already booked an unbelievable $300,000). If you want to book your orders, today would definitly be the best day as we are ready to deal!!! I have another 30 sets of 3COM 003446-0 Double Play cardsets - only $8250 - in stock right now ready to ship. These qualify for the Quad Trade-in program which allows you to trade 12Quad cards for another 2 FREE 24port DSP cards from 3COM. http://3com.com/promotions/hipertrade/index2.html We can also book ANY total Control sales for fully loaded chassis, Arc cards, Memory upgrades, Quad cards, whatever you need. Other specials: WatchGuard FireboxII - $3500 Alteon Ace-Directors - $Call Sonic Wall Firewalls. Max6096 $17,995 Regards, Greg Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.

Not sure if there is an archive available for this list, and if there is, I would glady search through it. (Point me in the right direction, if this question is answered elsewhere.) I've recently purchased a USR NetServer 8/I, and am looking to do a specific thing, that I don't know if USR's 4.x OS versions support. I need to do both PAP, and NON-PAP authentication. (I.E. when a user dials in w/ a PAP-Enabled PPP client (such as Win95/Win98/MacOS/Whatever) the Netserver will see that, and start the PAP process automatically.) Yet, I also need the ability for a user to dial in with Procomm, and log in with just a username and password, and get rlogin'ed directly to a shell account. (And also, w/ non-pap type customers, who use a radius prefix 'P' in front of their username, to designate that they want to do PPP.) I can do this with my PM2's, and I know the older NetServer (ComOS based code) could do this. Is there a method to do this, on the new OS? Or am I stuck with either login only, or PAP only? I know the older versions of the NetserverOS have the 'look&feel' of ComOS. But, my Netserver Manager program complains that it isn't a valid image, when I tried to load it on the unit... (I don't MIND using 4.x, if it'll do what I need it to do.) Thanks in advance to anyone who might have an answer. Chad

I'd strongly prefer not to see these ads on this list. I don't have a problem with end-users looking for stuff, or purhaps selling the odd part, but the traffic from the commercial guys is very uncool. I can't for the life of me see how they got the impression such ads would be welcome here. It doesn't help that they have actually carried on conversations, broker-to-broker, on the list. "Do you have X?" , "Yeah, 1.", "How much?", "$2000.", "OK, I'll take it". -a

Pete from Xmission runs the list, and he is also a reseller. I haven't seen Xmission advertise equipment for a while though. Pete, I guess we're waiting for your word. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Lorbieski > Sent: Friday, July 30, 1999 1:38 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) RE:DIGITAL AND ANALOG USR TCU > > > There is no such "US regulation". > > I think that you messages are inappropriate for this mailing list. This > is for discussions about USR/3COM Total Control equipment. I think there > is no excuse to post adverts without the permission of the owner of the > mailing list. > > Just my thoughts. > > "Andrew:PC Global, Inc." wrote: > > > > . When you leave a contact name and phone number, per US > regulations, it is > > not spam. Thanks though for your deep and considerate thoughts on the > > matter. > > > > Regards, > > > > Andrew Shlensky > > **************************** > > PC Global, Inc. > > (305) 667-2111 tel > > (305) 667-3636 fax > > (305) 216-8638 mobile > > URL: http://www.pcglobal.net > > E-MAIL: andrew@pcglobal.net > > ICQ: 21219089 > > Computer Service Parts SpEciaLiSts! > > ALSO:SALES of New/Used PCs,Laptops > > Communication & Networking,Monitors > > Printers, Hard Drives, Midrange/Mainframe. > > Hard to Get Parts. We buy and sell all > > types of GEAR- > > **************************** > > ----- Original Message ----- > > Richard Lorbieski - richard@alpha1.net > Chief Technical Officer - Senior System Administrator > Alpha1 Internet http://www.alpha1.net > 409.731.8236 - 877.4.alpha1 (877.425.7421) > > - > 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. >

I've yet to see $Com ever do something proactive that many of us would agree as productive and customer oriented. What happened to the list that we provided many months ago listing our top 10 grievances? All that I ever heard was that the music on hold got changed. You still pay for their overpriced and practically useless service contract. Unless you have a supplier that is willing to bend the rules, you are probably out of luck on this. I have been in and out of discussions with 3Com for months regarding the trade-up. I received a call last week that all was well and it was going ahead. I was amazed and pleased that for once that 3Com was actually doing the right thing. Those thoughts were dashed an hour later when I got an email simply stating that our purchase did not qualify. We have 9 DSP's that we bought since Feb and at least 96 quad modem cards that should qualify. At this point, none do according to $Com. $Com and my supplier both agree that it is a technicality but neither can do anything about it. Jenifer from $Com advised me to send them back and get a refund. Then order the qualifying SKU and resubmit. That is a viable option for all of us, right? Why we can't just trade paperwork is beyond me. Perhaps you will find someone with some intelligence and understanding. No such luck so far on my journey. The equipment works but not much else at $Com. At 11:12 AM 7/30/99 -0400, you wrote: >I have a chassis that I've upgraded to hiperarc and a single hiperdsp >(with a bundle package), and as close as it may be to the double-play >upgrade it doesnt qualify as one for the recent quad trade in program. > >Does anyone have a clue why 3com is so strict about this trade in, and if >there might be any trade in programs in the future for those of us that >got that later bundle upgrade. > >- lv > > >- > 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. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 ================================================== 142 S. Center St. Casper, Cheyenne, Gillette, Sheridan, Laramie Casper, WY 82601 Evanston, Rawlins, Powell, Rock Springs, Cody WWW.VCN.COM Douglas, Chugwater, Pinedale, & Lander, Wy

Sorry All about the equipment posts. I thought the TCU would be an appropriate place to post TCU equipment but now I know otherwise. Best Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- ****************************

. When you leave a contact name and phone number, per US regulations, it is not spam. Thanks though for your deep and considerate thoughts on the matter. Regards, Andrew Shlensky **************************** PC Global, Inc. (305) 667-2111 tel (305) 667-3636 fax (305) 216-8638 mobile URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! ALSO:SALES of New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Friday, July 30, 1999 12:02 PM It's called SPAM. To bad he didn't list an 800 number. Gives my modems something to do in the off hours. ;) But he did leave an ICQ number, that's got all kinds of fun security holes in it..... At 08:48 AM 7/30/99 -0700, you wrote: >Why is this guy posting this stuff here. He already posts >it in other isp-lists... This is not the place for this. > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andrew:PC Global, >Inc. >Sent: Friday, July 30, 1999 8:00 AM >To: isp-services@ispc.org; isp-equipment@isp-equipment.com; TCU >Subject: (usr-tc) RE:DIGITAL AND ANALOG USR TCU > > >In stock for immediate shipment: > >(1) Complete US Robotics Total Analog/Digital Control Unit >Warmest Regards, > >Andrew Shlensky >**************************** >PC Global, Inc. >(305) 667-2111 tel >(305) 667-3636 fax >(305) 216-8638 mobile >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >ALSO:SALES of New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** -- Brice Ligget Billings MT ligget@twoalpha.net http://www.twoalpha.net/~bligget DoD#2159 It's as bad as you think -- and they're out to get you. - 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.

Randy Cosby said once upon a time: > >Pete from Xmission runs the list, and he is also a reseller. I haven't seen >Xmission advertise equipment for a while though. Pete, I guess we're >waiting for your word. >> There is no such "US regulation". >> >> I think that you messages are inappropriate for this mailing list. This >> is for discussions about USR/3COM Total Control equipment. I think there >> is no excuse to post adverts without the permission of the owner of the >> mailing list. I don't have a problem with infrequent adverts for *TOTAL CONTROL* equipment. Advertisements bordering on spam will most likely result in the sender being banned.

There is no such "US regulation". I think that you messages are inappropriate for this mailing list. This is for discussions about USR/3COM Total Control equipment. I think there is no excuse to post adverts without the permission of the owner of the mailing list. Just my thoughts. "Andrew:PC Global, Inc." wrote: > > . When you leave a contact name and phone number, per US regulations, it is > not spam. Thanks though for your deep and considerate thoughts on the > matter. > > Regards, > > Andrew Shlensky > **************************** > PC Global, Inc. > (305) 667-2111 tel > (305) 667-3636 fax > (305) 216-8638 mobile > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > ICQ: 21219089 > Computer Service Parts SpEciaLiSts! > ALSO:SALES of New/Used PCs,Laptops > Communication & Networking,Monitors > Printers, Hard Drives, Midrange/Mainframe. > Hard to Get Parts. We buy and sell all > types of GEAR- > **************************** > ----- Original Message ----- Richard Lorbieski - richard@alpha1.net Chief Technical Officer - Senior System Administrator Alpha1 Internet http://www.alpha1.net 409.731.8236 - 877.4.alpha1 (877.425.7421)

pferraro@wna-linknet.com said once upon a time: > > > I believe you are speaking of the "anti-spoofing" The command is: > >enable ip address_source_filter >set network user default PPP_source_ip_filter enabled > > I think this is what you are referring to... I don't recall the following question ever being answered. Does this take into account framed-route'd networks?

Thus spake Andrew:PC Global, Inc. >. When you leave a contact name and phone number, per US regulations, it is >not spam. BWAHAHAHAHAHAHAHA Get real! Name and phone number or not...spam is spam. US regulations...heh...funny. >Thanks though for your deep and considerate thoughts on the >matter. I'll throw my $.02 in here as one thinking that messages of such type probably should be on isp-equipment, and finding them annoying to be on here. To be honest, I consider them an annoyance, but not a huge deal. I'd rather not see them here, but if they continue to be posted here I'm not gonna throw a hissie fit. >Andrew Shlensky >**************************** >PC Global, Inc. >(305) 667-2111 tel >(305) 667-3636 fax >(305) 216-8638 mobile >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >ALSO:SALES of New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** And, boy is this .sig just a bit too long. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

-> Sorry All about the equipment posts. I thought the TCU would be an -> appropriate place to post TCU equipment but now I know otherwise. -> Best Regards, -> Andrew Shlensky I personally don't mind them as long as it isn't every other message. I can't believe someone would mind saving a couple of bucks. Jeff Binkley ASA Network Computing

Whoever ED is with the Anonymous posting about Dynavar is absolutely uncorrect. If you truely have something to say, post your name, company and phone number and say whatever you want. Dynavar is following the rules of the trade-in program to the letter and will guarantee that all trade-ins will be accepted. If you have any concern, I would like to have the appropriate 3COM rep in your area call you to confirm that this is absolutely not true. I have heard that another large 3COM VAR has been spreading this rumor in order to win business away from Dynavar. I won't mention their name to give them the benefit of the doubt, but In my opinion , if true, this is a very slimey tactic against Dynavar and is completely unwarranted. They have changed one rule stating that all Quad cards must be owned by the customer for 120 days which should not affect any legitimate trade-in's. To all of you who are voting with their dollars, thanks for your support. Regards, Greg At 10:37 PM 7/29/99 -0400, you wrote: >Be Aware.3Com is aware of the games that Dynavar is playing with the quad >trade in deal. They will not be accepting quad trade ins from Dyanavar >Customers. > >http://www.3com.com/promotions/hipertrade/quad_to_hiper_rules.html > > >Ed > >- > 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. > > Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Friday, July 30, 1999 3:42 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) ip pool = 100% cpu utilization | | |pferraro@wna-linknet.com said once upon a time: |> |> |> I believe you are speaking of the "anti-spoofing" The command is: |> |>enable ip address_source_filter |>set network user default PPP_source_ip_filter enabled |> |> I think this is what you are referring to... | |I don't recall the following question ever being answered. Does this take |into account framed-route'd networks? No, only the host based entries. -M

I agree. The ISP-EQUIPMENT list is a more appropriate place for a sales pitch. Marshall Morgan President Internet Doorway, Inc. (aka NETDOOR) 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil > Sent: Friday, July 30, 1999 2:31 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Dealers on this list > > > > I'd strongly prefer not to see these ads on this list. I don't have > a problem with end-users looking for stuff, or purhaps selling the > odd part, but the traffic from the commercial guys is very uncool. I > can't for the life of me see how they got the impression such ads > would be welcome here. > > It doesn't help that they have actually carried on conversations, > broker-to-broker, on the list. "Do you have X?" , "Yeah, 1.", > "How much?", "$2000.", "OK, I'll take it".

YES PLEASE! Don't we get enough junk mail from the "dealers". This list started as a help list, PLEASE let's keep it that way. If the dealers really care to help, they can monitor this list and if someone asks for something, let them reply to them personally as not to clutter up the list. The ISP-EQUIPMENT list is DEFINITELY a more appropriate place to "COLD sell". Thanks > I agree. The ISP-EQUIPMENT list is a more appropriate place for a sales > pitch. > > I'd strongly prefer not to see these ads on this list. I don't have > > a problem with end-users looking for stuff, or perhaps selling the > > odd part, but the traffic from the commercial guys is very uncool. I > > can't for the life of me see how they got the impression such ads > > would be welcome here. > > > > It doesn't help that they have actually carried on conversations, > > broker-to-broker, on the list. "Do you have X?" , "Yeah, 1.", > > "How much?", "$2000.", "OK, I'll take it". <*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*><*> Len Pikulski lenp@nothinbut.net (856) 222-1514 http://www.nothinbut.net