September 2001

Howdy, While browsing about for more info on v.92 on the consumer side, I came across this. Commworks just isn't faring well here. Cisco is already shipping code??? http://808hi.com/56k/v92s.htm And I assume we're still at a point where quads will NOT be supported? Are there any other catches, like "you must buy hiper nmcs to load the new code"? Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com

Also sprach Charles Sprickman >While browsing about for more info on v.92 on the consumer side, I came >across this. Commworks just isn't faring well here. Cisco is already >shipping code??? >http://808hi.com/56k/v92s.htm >And I assume we're still at a point where quads will NOT be supported? Yes, quads will not be supported...they haven't budged on that piece of idiocy. >Are there any other catches, like "you must buy hiper nmcs to load the >new code"? You hit the nail on the head. You have to have at least HiPer NMCs to run V.92. I think it was already said that it is going to be a feature enable key, and thus added cost as well. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Anyone know what these things price out to? http://www.cisco.com/warp/public/cc/pd/as/as5350/prodlit/as53_ds.htm I'm trying to figure cost for replacing 10 T's of quads and 6 HiPer NMC's vs. another dial product... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Sat, 1 Sep 2001, Jeff Mcadams wrote: > Also sprach Charles Sprickman > >While browsing about for more info on v.92 on the consumer side, I came > >across this. Commworks just isn't faring well here. Cisco is already > >shipping code??? > > >http://808hi.com/56k/v92s.htm > > >And I assume we're still at a point where quads will NOT be supported? > > Yes, quads will not be supported...they haven't budged on that piece of > idiocy. > > >Are there any other catches, like "you must buy hiper nmcs to load the > >new code"? > > You hit the nail on the head. You have to have at least HiPer NMCs to > run V.92. I think it was already said that it is going to be a feature > enable key, and thus added cost as well. > -- > 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. >

Also sprach Charles Sprickman >Anyone know what these things price out to? >http://www.cisco.com/warp/public/cc/pd/as/as5350/prodlit/as53_ds.htm >I'm trying to figure cost for replacing 10 T's of quads and 6 HiPer >NMC's vs. another dial product... 2, 4, or 8 spans? And let me get back to work (Tues.) and I can give you ballpark pricing. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

A Cisco AS5301-CH with 48 ports (Cisco part # AS53-48-CH) would run you about $17000.00 give or take. You could move up to a AS5300 with 96 port and redundant power for about $32000.00. This should give you a ballpark figure. Lance Eves KanOkla Communications 620-845-5500 leves@kanokla.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com] On Behalf Of Charles Sprickman Sent: Sunday, September 02, 2001 1:59 PM Anyone know what these things price out to? http://www.cisco.com/warp/public/cc/pd/as/as5350/prodlit/as53_ds.htm I'm trying to figure cost for replacing 10 T's of quads and 6 HiPer NMC's vs. another dial product... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Sat, 1 Sep 2001, Jeff Mcadams wrote: > Also sprach Charles Sprickman > >While browsing about for more info on v.92 on the consumer side, I > >came across this. Commworks just isn't faring well here. Cisco is > >already shipping code??? > > >http://808hi.com/56k/v92s.htm > > >And I assume we're still at a point where quads will NOT be > >supported? > > Yes, quads will not be supported...they haven't budged on that piece > of idiocy. > > >Are there any other catches, like "you must buy hiper nmcs to load > >the new code"? > > You hit the nail on the head. You have to have at least HiPer NMCs to > run V.92. I think it was already said that it is going to be a > feature enable key, and thus added cost as well. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. For information > on digests or retrieving files and old messages send "help" to the > same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Also sprach Lance Eves >A Cisco AS5301-CH with 48 ports (Cisco part # AS53-48-CH) would run you >about $17000.00 give or take. You could move up to a AS5300 with 96 >port and redundant power for about $32000.00. This should give you a >ballpark figure. Keep in mind that the AS5300 is different from the AS5350, though. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Had a good talk with Tom from 3Com in my office last week. The V.92 upgrade will not be an extra cost item other than the fact you must have a contract to get the download. The quads apparently don't have the available space and processing power to handle V.92, though if you want to work on it you can figure it out and make a ton of money on the grey market. Not sure why the requirement for the hipernmc but the old ones are too slow anyway for larger chassis configurations. The primary reservation I have against paying for support and upgrading has to do with 'end of life on the hiperarc's and hipernmc's. 3Com is moving to faster processors, but the old ones should run the same code base. If they make a public promise for continuing support for the same codebase with an exception for processing power I will go with the upgrade, otherwise, too much of my current investment is EOL. BTW, when we talk V.92 we need to talk complete featuer sets. Some of the other vendors have major caveats in their support in order to claim they have it now. Mark Thornton San Marcos Internet, Inc 512-393-5300 ----- Original Message ----- Sent: Saturday, September 01, 2001 8:04 AM > Also sprach Charles Sprickman > >While browsing about for more info on v.92 on the consumer side, I came > >across this. Commworks just isn't faring well here. Cisco is already > >shipping code??? > > >http://808hi.com/56k/v92s.htm > > >And I assume we're still at a point where quads will NOT be supported? > > Yes, quads will not be supported...they haven't budged on that piece of > idiocy. > > >Are there any other catches, like "you must buy hiper nmcs to load the > >new code"? > > You hit the nail on the head. You have to have at least HiPer NMCs to > run V.92. I think it was already said that it is going to be a feature > enable key, and thus added cost as well. > -- > 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.

Also sprach Mark Thornton >Had a good talk with Tom from 3Com in my office last week. The V.92 >upgrade will not be an extra cost item other than the fact you must >have a contract to get the download. Hrmm...ok...I was under the impression that it would be a feature enable on the NMC...which I guess doesn't necessarily equate to added-cost, so that doesn't absolutely prove my thoughts wrong, but it does make them less likely. >The quads apparently don't have the available space and processing >power to handle V.92, Space, sort of...there are so many obsolete protocols supported in the quads that could be removed with no damage to their functionality that its not funny (HST anyone?). Not having enough processing power is a bunch of hooey. It takes less processing power to convert PCM samples to data then it does an analog waveform. >Not sure why the requirement for the hipernmc but the old ones are too >slow anyway for larger chassis configurations. Sure...I have a chassis with 8 DSPs on it with a 486 NMC...and its certainly feeling it, but it is useable with it. Once again, 3Com EOL'ing a product for no good reason. >The primary reservation I have against paying for support and upgrading >has to do with 'end of life on the hiperarc's and hipernmc's. Amen to that. I don't even own a single HiPer NMC and they're already being EOL'ed? That's a joke. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 3 Sep 2001, Mark Thornton wrote: > Not sure why the > requirement for the hipernmc but the old ones are too slow anyway for larger > chassis configurations. Depends on what you do with them. Mine serve three purposes: -monitoring scripts hit them, and scripts are very patient :) -initial config (completely bearable, speedwise) -software updates That means I actually have hands-on "oh this is a tad slow" experiences maybe twice a year. I can live with that. > The primary reservation I have against paying for > support and upgrading has to do with 'end of life on the hiperarc's and > hipernmc's. Hello?? What's that? I'm still getting over the quads being unsupported. My HiPer DSP and ARC's still seem so new... Is this definite? I've not heard anything about that. Isn't this akin to Cisco dumping everything but the 5800? > 3Com is moving to faster processors, but the old ones should run > the same code base. If they make a public promise for continuing support for > the same codebase with an exception for processing power I will go with the > upgrade, otherwise, too much of my current investment is EOL. Weird. I don't think you'll get a promise from them, their track-record in this area is pretty grim. They certainly are helping the decision-making process along pretty well. Charles > Mark Thornton > San Marcos Internet, Inc > 512-393-5300 > > > ----- Original Message ----- > From: "Jeff Mcadams" <jeffm@iglou.com> > To: <usr-tc@lists.xmission.com> > Sent: Saturday, September 01, 2001 8:04 AM > Subject: Re: (usr-tc) v.92 info > > > > Also sprach Charles Sprickman > > >While browsing about for more info on v.92 on the consumer side, I came > > >across this. Commworks just isn't faring well here. Cisco is already > > >shipping code??? > > > > >http://808hi.com/56k/v92s.htm > > > > >And I assume we're still at a point where quads will NOT be supported? > > > > Yes, quads will not be supported...they haven't budged on that piece of > > idiocy. > > > > >Are there any other catches, like "you must buy hiper nmcs to load the > > >new code"? > > > > You hit the nail on the head. You have to have at least HiPer NMCs to > > run V.92. I think it was already said that it is going to be a feature > > enable key, and thus added cost as well. > > -- > > Jeff McAdams Email: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Also sprach Charles Sprickman >Anyone know what these things price out to? >http://www.cisco.com/warp/public/cc/pd/as/as5350/prodlit/as53_ds.htm >I'm trying to figure cost for replacing 10 T's of quads and 6 HiPer >NMC's vs. another dial product... List pricing that I have (and this may not be exact): 2 T1 ports - $20,500 4 T1 ports - $38,000 8 T1 ports - $67,000 Keep in mind that these are *list* prices, so apply your typical discount to figure out what you'll actually pay. My understanding is that these prices include enough DSPs on the systems to run those ports at max capacity. Also keep in mind that these are Cisco's Universal Ports which means they can do modem, fax, isdn, voice, TDM switching and format conversion, clear channel data (or any T1 fraction thereof), you name it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi, I'd like to know if some of you have any complain like this. I have some windows users that are telling that when the connection becomes slow, they can improve the "speed" of that pinging some hosts in my LAN. I got many logs of constants pings with snort and when we ask the users why, they told me that. I'm using TC chassis with 7 Hiper DSPs, HArc 4.1.59. I can imagine that it's some Windows bizarre bug. Could it have a technical answer? - Marcelo

Will the Masterswitch allow you to power up a dead chassis? At 11:40 PM 10/28/00 -0400, you wrote: >Also sprach Charles Sprickman > >Not recommended to keep running at that temp, but I could find no way > >to power down remotely :) > >APC MasterSwitches are your friend. :) > >Actually...we don't have our chassis on MasterSwitches...yet...haven't >convinced the folks with the purse-strings of the benefits yet...I'm >still working on it though. We do use them for our servers though >(mostly Sparcs), they're great. >-- >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. > > >-=-=- >SBG-Priority: 3 (Normal) http://www.internz.com/SpamBeGone/

Weekly TOTAL CONTROL inventory: Added some Cisco b/c of the conversations of late. Those of you selling out for GREENER PASTURES please send me list of your available TC hardware. Hiper DSP T1 $1600 Hiper DSP E1 $2000 Hiper ARC (64MB) $1200 Hiper NMC (P5) EdgeServer PRO $1200 Hiper DSP T1 Bundles $5500 Hiper DSP E1 Bundle $6500 Quad Modem Bundles $1500 Some others refurbished in stock: Adtran TSU LT $250 Adtran TSU $300 Motorola FT100s $300 Cisco 2501 $600 Cisco 4500M $950 CISCO AS5300-120-VOIP-A...About $15,000..usually less :) Full line of ISP hardware available. If you are looking for round figures for refurbished hardware, I am happy to help you out. Contact srivera@wrca.net

Sorry for the additional post, these just came in.... I have 3 available in NEW Condition. MultiSpan 96 port DSP card set P/N 3C0504222-00 Asking $12,000each...This price should beat everyone, including Source-T. If not let me know and I'll work to match it.

Also sprach John Mies >Will the Masterswitch allow you to power up a dead chassis? Not exactly sure what you mean by "dead chassis." Obviousvly, if there is a *problem* with the cahssis, the MasterSwitch won't help you there. Think of the MasterSwitch as a power strip with individual power toggles for each outlet on the strip, and those toggles are under software control. That software also has a telnet, web and snmp server as the connectivity to get to it from the network. Its really pretty cool. >At 11:40 PM 10/28/00 -0400, you wrote: >>Also sprach Charles Sprickman >> >Not recommended to keep running at that temp, but I could find no >> >way to power down remotely :) >>APC MasterSwitches are your friend. :) >>Actually...we don't have our chassis on MasterSwitches...yet...haven't >>convinced the folks with the purse-strings of the benefits yet...I'm >>still working on it though. We do use them for our servers though >>(mostly Sparcs), they're great. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

No, don't mean totally dead. We have had instances where the chassis would power off during a brownout, etc. Wondered if the MasterSwitch could power it back up remotely so we wouldn't have to travel there just to flip a switch. At 01:44 PM 9/4/01 -0400, you wrote: >Also sprach John Mies > >Will the Masterswitch allow you to power up a dead chassis? > >Not exactly sure what you mean by "dead chassis." Obviousvly, if there >is a *problem* with the cahssis, the MasterSwitch won't help you there. > >Think of the MasterSwitch as a power strip with individual power toggles >for each outlet on the strip, and those toggles are under software >control. That software also has a telnet, web and snmp server as the >connectivity to get to it from the network. Its really pretty cool. > > >At 11:40 PM 10/28/00 -0400, you wrote: > >>Also sprach Charles Sprickman > >> >Not recommended to keep running at that temp, but I could find no > >> >way to power down remotely :) > > >>APC MasterSwitches are your friend. :) > > >>Actually...we don't have our chassis on MasterSwitches...yet...haven't > >>convinced the folks with the purse-strings of the benefits yet...I'm > >>still working on it though. We do use them for our servers though > >>(mostly Sparcs), they're great. >-- >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. > > >-=-=- >SBG-Priority: 4 (Low) http://www.internz.com/SpamBeGone/

Also sprach John Mies >No, don't mean totally dead. We have had instances where the chassis >would power off during a brownout, etc. Wondered if the MasterSwitch >could power it back up remotely so we wouldn't have to travel there >just to flip a switch. I've never known a chassis to do this, so I'm not exactly sure what's required to recover them from this situation. Essentially, think of it as having the capability to remote flip the power switch on the *power strip* off and back on again. It does nothing to actually toggle the power supply of the chassis itself, just the power supplied *through* the power strip *to* the chassis. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 03:45 PM 9/4/01 -0400, you wrote: >Also sprach John Mies > >No, don't mean totally dead. We have had instances where the chassis > >would power off during a brownout, etc. Wondered if the MasterSwitch > >could power it back up remotely so we wouldn't have to travel there > >just to flip a switch. > >I've never known a chassis to do this, so I'm not exactly sure what's >required to recover them from this situation. Here's a response from another user who had this happen. I received it last fall: We had a simliar experience... It turned out that the UPS was not "BIG" enough to handle the power requirements for the chassis. We would get a "brownout" and the chassis would shut down. I ask about this over a year ago on the list and no one seemed to have the answer. KRISH told me that the power sensing switches on the newer chassis were a little more sensative. We upgraded the UPS and have not had the chassis drop offline again! Moral of the story... Upgrade to a little larger UPS! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite Q FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== >Essentially, think of it as having the capability to remote flip the >power switch on the *power strip* off and back on again. > >It does nothing to actually toggle the power supply of the chassis >itself, just the power supplied *through* the power strip *to* the >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. > > >-=-=- >SBG-Priority: 3 (Normal) http://www.internz.com/SpamBeGone/

And we do have to toggle the switch off and on. Unplugging and re-plugging doesn't do any good. Anyone have a workaround? At 03:45 PM 9/4/01 -0500, you wrote: >At 03:45 PM 9/4/01 -0400, you wrote: > >>Also sprach John Mies >> >No, don't mean totally dead. We have had instances where the chassis >> >would power off during a brownout, etc. Wondered if the MasterSwitch >> >could power it back up remotely so we wouldn't have to travel there >> >just to flip a switch. >> >>I've never known a chassis to do this, so I'm not exactly sure what's >>required to recover them from this situation. > >Here's a response from another user who had this happen. I received it >last fall: > >We had a simliar experience... It turned out that the UPS was not >"BIG" enough to handle the power requirements for the chassis. We would >get a "brownout" and the chassis would shut down. I ask about this over a >year ago on the list and no one seemed to have the answer. KRISH told me >that the power sensing switches on the newer chassis were a little more >sensative. We upgraded the UPS and have not had the chassis drop offline >again! Moral of the story... Upgrade to a little larger UPS! > >============================================================================== >Phillip Ferraro WorldNet Access, Inc >pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service >Voice (910) 346-0835 824 Gumbranch Square, Suite Q >FAX (910) 455-1933 Jacksonville, Nc 28540-6269 >============================================================================== > > > >>Essentially, think of it as having the capability to remote flip the >>power switch on the *power strip* off and back on again. >> >>It does nothing to actually toggle the power supply of the chassis >>itself, just the power supplied *through* the power strip *to* the >>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. >> >> >>-=-=- >>SBG-Priority: 3 (Normal) http://www.internz.com/SpamBeGone/ > > >- >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. > > >-=-=- >SBG-Priority: 4 (Low) http://www.internz.com/SpamBeGone/

I'm trying to convert from RIP to OSPF on a pair of HIPERARCs and so far OSPF is able to announce the addresses in the multi-aggregate address pools to the rest of the net. It's picking up routes from the other devices (a mix of Ciscos, Redbacks, Junipers, and Ascend MAX) as well as the default route from our border routers. However, when a PPP dialer receives their IP address via RADIUS instead of from the configured address pool, OSPF doesn't announce the address. The address is seen if one does a 'list ip network' and it's pingable. But none of the other devices on the LAN receive any announcement from the HIPERARC. I do have an OSPF sendpolicy that covers every possible address we might announce. If I revert back to RIP, the address learned from RADIUS is announced via RIP. Anybody have an idea on what I might be missing here? anunu2> show ospf global GLOBAL OSPF SETTINGS Router ID: 64.65.64.36 Administrative Status: ENABLED OSPF Version Number: 2 Area Border Router Status: DISABLED Autonomous System Border Router Status: DISABLED Type-of-service (TOS) Support: OFF External LSDB Limit: -1 Multicast Extensions Support: OFF Exit Overflow Interval: 0 Router's Support for OSPF Demand Routing: OFF OSPF Traps: ENABLED anunu2> list ospf host OSPF HOST TABLE HostIpAddr/Mask Metric AreaId 64.65.75.176/28 1 0.0.0.1 64.65.75.192/26 1 0.0.0.1 64.65.76.0/26 1 0.0.0.1 64.65.76.64/27 1 0.0.0.1 64.65.76.96/28 1 0.0.0.1 anunu2> list ospf send OSPF Send Policies: Source Address/Mask Action ANY 000.000.000.000/0 Do Not Advertise LOCAL 064.065.064.000/18 Advertise anunu2> list ospf int OSPF INTERFACE TABLE IfIpAddr/IfInd AreaId IfType AdminStat IfState Metric 64.65.64.36 0.0.0.1 BC ENABLED OtherDsgRtr 1 anunu2> show ip network backbone SHOW IP NETWORK backbone SETTINGS: Interface: eth:1 Network Address: 64.65.64.36/25 Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.128 Station: 64.65.64.36 Broadcast Algorithm: IETF Max Reassembly Size: 8192 WAN Type: N/A Remote IP Address: 0.0.0.0 IP Routing Protocols: OSPF IP Routing Metric: 1 RIP Interface Export Metric: 0 IP RIP Routing Policies: IP RIP Authentication Key:

I've seen this when i've been using a bad phone line... never figured out why.... Its not isolated to windows, as i was using both solaris and mac's at the time. Regards, Richard ----- Original Message ----- Sent: Tuesday, September 04, 2001 11:58 PM > Hi, > > I'd like to know if some of you have any complain like this. > I have some windows users that are telling that when the > connection becomes slow, they can improve the "speed" of that pinging some > hosts in my LAN. > I got many logs of constants pings with snort and when we ask the > users why, they told me that. > I'm using TC chassis with 7 Hiper DSPs, HArc 4.1.59. > I can imagine that it's some Windows bizarre bug. > Could it have a technical answer? > > - 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. >

OK, time to get some facts... Does the Patton equipment fully support V.92 at this time? Modem on-hold, fast-connect, fast-upload, and V.44? The last info I can find indicates only modem on-hold and fast connect are implemented. Does the Cisco implementation still not support fast-upload? What about V.44? When is it to be released, if ever? What about Lucent/Ascend? The last word I had on the 3Com code was that it would support all four in the initial release. Anyone willing to give us a heads-up? Do we have any feedback on modem compatability and connectivity issues? On the financial side, a first look at the math show it to be a dead heat between completing the required upgrades to my chassis along with support contracts vs. new Patton equipment when I look at annual costs for the next few years. I haven't yet gotten info on the other vendors. Mark Thornton San Marcos Internet, Inc 512-393-5300

On Wed, 5 Sep 2001, Charles Sprickman wrote: > What happens if you enable ASBR? If I recall correctly, there was no change in behaviour. However, I've fiddled with so many parameters the past couple of days that I might have been hitting the wrong combination while ASBR was enabled. I'll enable it again and we'll see what happens.

v.92 will probibly follow the kflex/X2/v.90 path.... everyone has thier own blend initially, then as they see the base grow add in whatever comes next. Since there are no v.92 modems available in quantity (or being shipped with PC's) I would wait at least till 4q 01 to even try and get code on your RAS. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 5 Sep 2001, Mark Thornton wrote: > OK, time to get some facts... > > Does the Patton equipment fully support V.92 at this time? Modem on-hold, > fast-connect, fast-upload, and V.44? The last info I can find indicates only > modem on-hold and fast connect are implemented. > > Does the Cisco implementation still not support fast-upload? What about > V.44? When is it to be released, if ever? > > What about Lucent/Ascend? > > The last word I had on the 3Com code was that it would support all four in > the initial release. Anyone willing to give us a heads-up? > > Do we have any feedback on modem compatability and connectivity issues? > > On the financial side, a first look at the math show it to be a dead heat > between completing the required upgrades to my chassis along with support > contracts vs. new Patton equipment when I look at annual costs for the next > few years. I haven't yet gotten info on the other vendors. > > Mark Thornton > San Marcos Internet, Inc > 512-393-5300 > > > > - > 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 happens if you enable ASBR? Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Wed, 5 Sep 2001, Antonio Querubin wrote: > I'm trying to convert from RIP to OSPF on a pair of HIPERARCs and so far > OSPF is able to announce the addresses in the multi-aggregate address > pools to the rest of the net. It's picking up routes from the other > devices (a mix of Ciscos, Redbacks, Junipers, and Ascend MAX) as well as > the default route from our border routers. > > However, when a PPP dialer receives their IP address via RADIUS instead of > from the configured address pool, OSPF doesn't announce the address. The > address is seen if one does a 'list ip network' and it's pingable. But > none of the other devices on the LAN receive any announcement from the > HIPERARC. I do have an OSPF sendpolicy that covers every possible address > we might announce. If I revert back to RIP, the address learned from > RADIUS is announced via RIP. Anybody have an idea on what I might be > missing here? > > anunu2> show ospf global > > GLOBAL OSPF SETTINGS > Router ID: 64.65.64.36 > Administrative Status: ENABLED > OSPF Version Number: 2 > Area Border Router Status: DISABLED > Autonomous System Border Router Status: DISABLED > Type-of-service (TOS) Support: OFF > External LSDB Limit: -1 > Multicast Extensions Support: OFF > Exit Overflow Interval: 0 > Router's Support for OSPF Demand Routing: OFF > OSPF Traps: ENABLED > > anunu2> list ospf host > OSPF HOST TABLE > HostIpAddr/Mask Metric AreaId > 64.65.75.176/28 1 0.0.0.1 > 64.65.75.192/26 1 0.0.0.1 > 64.65.76.0/26 1 0.0.0.1 > 64.65.76.64/27 1 0.0.0.1 > 64.65.76.96/28 1 0.0.0.1 > > anunu2> list ospf send > > OSPF Send Policies: > Source Address/Mask Action > ANY 000.000.000.000/0 Do Not Advertise > LOCAL 064.065.064.000/18 Advertise > > anunu2> list ospf int > OSPF INTERFACE TABLE > IfIpAddr/IfInd AreaId IfType AdminStat IfState Metric > 64.65.64.36 0.0.0.1 BC ENABLED OtherDsgRtr 1 > > anunu2> show ip network backbone > > SHOW IP NETWORK backbone SETTINGS: > Interface: eth:1 > Network Address: 64.65.64.36/25 > Frame Type: ETHERNET_II > Status: ENABLED > Reconfigure Needed: FALSE > Mask: 255.255.255.128 > Station: 64.65.64.36 > Broadcast Algorithm: IETF > Max Reassembly Size: 8192 > WAN Type: N/A > Remote IP Address: 0.0.0.0 > IP Routing Protocols: > OSPF > IP Routing Metric: 1 > RIP Interface Export Metric: 0 > IP RIP Routing Policies: > IP RIP Authentication Key: > > > - > 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. >

yOn Wed, 5 Sep 2001, Antonio Querubin wrote: > Date: Wed, 5 Sep 2001 11:05:13 -1000 (HST) > From: Antonio Querubin <tony@lava.net> > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) OSPF doesn't announce RADIUS learned addresses? > > On Wed, 5 Sep 2001, Charles Sprickman wrote: > > > What happens if you enable ASBR? > > If I recall correctly, there was no change in behaviour. However, I've > fiddled with so many parameters the past couple of days that I might have > been hitting the wrong combination while ASBR was enabled. I'll enable it > again and we'll see what happens. That seems to have done the trick. Even works with the default send-policy. Thanks for the hint!

Hi, How exactly does the software upload feature work in TCM? I've been trying to update some cards from behind a firewall, and have not had much luck. I've opened up incoming tftp (udp port 69), but I still get the "tftp timed out" error. Is there a (semi) easy way to just do this with ucd-snmp, some perl, a tftp server, and the correct OID's? How are the cards indexed for software download? Thanks, Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com

Also sprach Charles Sprickman >How exactly does the software upload feature work in TCM? I've been >trying to update some cards from behind a firewall, and have not had >much luck. I've opened up incoming tftp (udp port 69), but I still get >the "tftp timed out" error. >Is there a (semi) easy way to just do this with ucd-snmp, some perl, a >tftp server, and the correct OID's? How are the cards indexed for >software download? It can be done. If I remember correctly, and its been a while since I've really looked into this. There are SNMP values that are set on a row in a table to tell the NMC to download the code using tftp. (Which you probably figured out so far) I don't remember the SNMP values off the top of my head, but I think I remember that it is documented in a lot of the software upgrade release notes from 3Com. Should be able to grab that and it'll tell you. The problem that I suspect that you're running into is that tftp will often "float" its port numbers....meaning that the initial contact is made to the tftp server on port 69, with the source port being a higher port number, then when the tftp server responds, it will use the port that the client sourced the connection from along with its own high port number...this means that the tftp "connection" (its udp, so its not a "true" connection in the tcp sense) no longer uses port 69 at all. This may be where your firewall is running into problems. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 7 Sep 2001, Jeff Mcadams wrote: > The problem that I suspect that you're running into is that tftp will > often "float" its port numbers....meaning that the initial contact is > made to the tftp server on port 69, with the source port being a higher > port number, then when the tftp server responds, it will use the port > that the client sourced the connection from along with its own high port > number...this means that the tftp "connection" (its udp, so its not a > "true" connection in the tcp sense) no longer uses port 69 at all. This > may be where your firewall is running into problems. :/ Yeah, I started seeing all sorts of random ports being hit, so I just opened up all tcp/udp between the tch and laptop. Now it went ahead and erased flash, then crapped out. Just sitting there. Nothing in the firewall logs showing what's up, and it's real addresses behind the fw, no nat. I like "copy tftp://some.server/path/to/code slot0:" much better :) C > -- > 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. >

Also sprach Charles Sprickman >Yeah, I started seeing all sorts of random ports being hit, so I just >opened up all tcp/udp between the tch and laptop. Now it went ahead >and erased flash, then crapped out. Just sitting there. Nothing in >the firewall logs showing what's up, and it's real addresses behind the >fw, no nat. >I like "copy tftp://some.server/path/to/code slot0:" much better :) There is a sort of minimalist beauty to it, isn't there? ;) What type card are you upgrading? (I don't remember if you stated this in your original message)... If its a .sdl/.nac file combo, then the sdl file is downloaded before the erasing of flash occurs, so you have another problem than tftp being blocked. If its a .dmf file type (ie, the newer HiPer type cards), then they just download in one go, but I don't think they erase flash do they? Now I don't remember. If its the older .sdl/.nac combo, then there is two steps, you download the .sdl, then it erases flash, then you have to tell the NMC to download the nac file in another SNMP operation if I remember correctly. Again, the release notes for some of the later software releases I believe details the operations...its been so long since I've done this, and I don't know that I've ever done it fully manually, that I'm a bit fuzzy on it. I seem to remember that Mike Andrews had a utility that did software upgrades on cards as well...are you still on the list Mike? Am I remembering all of this correctly or not? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Yup, the util's still on my web page, tho it's probably bit-rotted to hell by now. :) I know it's broken for flashing 486 NMCs right now. It also only works on Unix as-is, because it does a system() call to the tftp binary directly. (And tftp thru a firewall really is asking for trouble, because of the random port number issue.) Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet access for Frankfort, Lexington, Louisville and surrounding counties www.fark.com: If it's not news, it's Fark. (Or something like that.) On Fri, 7 Sep 2001, Jeff Mcadams wrote: > Also sprach Charles Sprickman > >Yeah, I started seeing all sorts of random ports being hit, so I just > >opened up all tcp/udp between the tch and laptop. Now it went ahead > >and erased flash, then crapped out. Just sitting there. Nothing in > >the firewall logs showing what's up, and it's real addresses behind the > >fw, no nat. > > >I like "copy tftp://some.server/path/to/code slot0:" much better :) > > There is a sort of minimalist beauty to it, isn't there? ;) > > What type card are you upgrading? (I don't remember if you stated this > in your original message)... > > If its a .sdl/.nac file combo, then the sdl file is downloaded before > the erasing of flash occurs, so you have another problem than tftp being > blocked. If its a .dmf file type (ie, the newer HiPer type cards), then > they just download in one go, but I don't think they erase flash do > they? Now I don't remember. > > If its the older .sdl/.nac combo, then there is two steps, you download > the .sdl, then it erases flash, then you have to tell the NMC to > download the nac file in another SNMP operation if I remember correctly. > Again, the release notes for some of the later software releases I > believe details the operations...its been so long since I've done this, > and I don't know that I've ever done it fully manually, that I'm a bit > fuzzy on it. > > I seem to remember that Mike Andrews had a utility that did software > upgrades on cards as well...are you still on the list Mike? Am I > remembering all of this correctly or not? > -- > 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. >

ARC v4.1.59-6 right? What about the DSPs? Connected to CT1 or PRI switch? Any errors on the T1s? Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 ----- Original Message ----- Sent: Sunday, September 09, 2001 11:12 AM > I have a 3com Total Control hub V4.1.59, with 7 DSP modem cards. > > I'm getting a ton of complaints from dialup users that all "receiving > traffic" stops, > while they are surfing, or checking mail, or whatever. > > I've monitored one of these users via (monitor ppp), and notice that I am > receiving the PPP packets from the user, but nothing is being sent back. > > I try to ping the IP of the modem, and I get a timeout. > > There is a route in the routing table, for their IP, and it did point to > their modem port. > I checked the status of the port (show int slot:#/mod:#) , and it shows > nothing out of the ordinary. > > I realize that it could be the phone lines, but I have to be sure. > > Has anyone came across this problem before, or know of a better way I can > confirm -where- the problem is ? > > > > - > 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 3com Total Control hub V4.1.59, with 7 DSP modem cards. I'm getting a ton of complaints from dialup users that all "receiving traffic" stops, while they are surfing, or checking mail, or whatever. I've monitored one of these users via (monitor ppp), and notice that I am receiving the PPP packets from the user, but nothing is being sent back. I try to ping the IP of the modem, and I get a timeout. There is a route in the routing table, for their IP, and it did point to their modem port. I checked the status of the port (show int slot:#/mod:#) , and it shows nothing out of the ordinary. I realize that it could be the phone lines, but I have to be sure. Has anyone came across this problem before, or know of a better way I can confirm -where- the problem is ?

CT1, going to PRI's. No line errors on the T1's that I can tell. But, I've done some snmp queries for the modem ports, and found that I have modem ports that have above 20 failed calls (out of 220+ incoming calls). I've had one particular user be online for a long time, all of a sudden, all traffic stops. :co very strange. :c( ----- Original Message ----- Sent: Sunday, September 09, 2001 12:35 PM : ARC v4.1.59-6 right? : What about the DSPs? Connected to CT1 or PRI switch? Any errors on the : T1s? : : Marshall Morgan : : Internet Doorway, Inc (aka NETDOOR) : http://www.netdoor.com : : 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 : ----- Original Message ----- : From: "Clint Alexander" <calexander@cybrtown.com> : To: <usr-tc@xmission.com> : Sent: Sunday, September 09, 2001 11:12 AM : Subject: (usr-tc) Total Control loosing dialup connections... : : : > I have a 3com Total Control hub V4.1.59, with 7 DSP modem cards. : > : > I'm getting a ton of complaints from dialup users that all "receiving : > traffic" stops, : > while they are surfing, or checking mail, or whatever. : > : > I've monitored one of these users via (monitor ppp), and notice that I am : > receiving the PPP packets from the user, but nothing is being sent back. : > : > I try to ping the IP of the modem, and I get a timeout. : > : > There is a route in the routing table, for their IP, and it did point to : > their modem port. : > I checked the status of the port (show int slot:#/mod:#) , and it shows : > nothing out of the ordinary. : > : > I realize that it could be the phone lines, but I have to be sure. : > : > Has anyone came across this problem before, or know of a better way I can : > confirm -where- the problem is ? : > : > : > : > - : > 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. :

How do you flash the ARC card from the console port? I've only tried it through the ethernet port. Please reply to jdn@adoptable.com Thanks, JD >Return-Path: <owner-usr-tc@lists.xmission.com> >Date: Fri, 24 Aug 2001 12:56:28 +0900 >From: Jonathan Byrne <byrnej@gol.com> >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Flashing Hyper Arc >Mail-Followup-To: usr-tc@lists.xmission.com >X-Abuse-Complaints: abuse@gol.com >Sender: owner-usr-tc@lists.xmission.com >Reply-To: usr-tc@lists.xmission.com > >Steve Johnson (linuxnut@sonic.net) wrote: > >> smoothly untill I hit 80% then I get an TFTP error, Access Violation and it > >I see also, but see it a lot less on 128 meg ARCs. If it's >nearby, I just go there and flash it over the console port, which >works fine. > >Cheers, > >Jonathan >-------- ><PLUG TYPE="shameless"> >Leaving Japan end of September, available for employment in California. ></PLUG> > > >- > 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. > David DenHollander (403)254-1100 Main (403)201-2815 Fax List your equipment for free http://www.adoptable.com/

We have had these same complaints running ARC 4.2.32, and DSP 2.0.51 (PRI&CT1). At first I thought it was some kind of MTU mis-match, but I have changed all settings on the ARC, and through radius to make them match. Anyone else having these problems with newer code releases? ************************ Jason Watkins jwatkins@iland.net I-Land Network Operations http://www.iland.net ************************* ----- Original Message ----- Sent: Sunday, September 09, 2001 11:53 AM CT1, going to PRI's. No line errors on the T1's that I can tell. But, I've done some snmp queries for the modem ports, and found that I have modem ports that have above 20 failed calls (out of 220+ incoming calls). I've had one particular user be online for a long time, all of a sudden, all traffic stops. :co very strange. :c( ----- Original Message ----- Sent: Sunday, September 09, 2001 12:35 PM : ARC v4.1.59-6 right? : What about the DSPs? Connected to CT1 or PRI switch? Any errors on the : T1s? : : Marshall Morgan : : Internet Doorway, Inc (aka NETDOOR) : http://www.netdoor.com : : 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 : ----- Original Message ----- : From: "Clint Alexander" <calexander@cybrtown.com> : To: <usr-tc@xmission.com> : Sent: Sunday, September 09, 2001 11:12 AM : Subject: (usr-tc) Total Control loosing dialup connections... : : : > I have a 3com Total Control hub V4.1.59, with 7 DSP modem cards. : > : > I'm getting a ton of complaints from dialup users that all "receiving : > traffic" stops, : > while they are surfing, or checking mail, or whatever. : > : > I've monitored one of these users via (monitor ppp), and notice that I am : > receiving the PPP packets from the user, but nothing is being sent back. : > : > I try to ping the IP of the modem, and I get a timeout. : > : > There is a route in the routing table, for their IP, and it did point to : > their modem port. : > I checked the status of the port (show int slot:#/mod:#) , and it shows : > nothing out of the ordinary. : > : > I realize that it could be the phone lines, but I have to be sure. : > : > Has anyone came across this problem before, or know of a better way I can : > confirm -where- the problem is ? : > : > : > : > - : > 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.

Have you looked at the retrains in the session monitor? If they're going up like wildfire you have your answer. Also compare ping times on your customers from time to time and see what's going on on average. You might have a faulty PRI or T1 or a CLEC time/framing issue (bi-polar violations). Those bi/po's are hard to pin down sometimes. Each vendor in the loop points at the other one, and if it were Verizon, they'd say you are crazy and the circuit is fine :) Been there. Good luck. Al Thiel WebSTABLE, Inc. At 12:12 PM 9/9/2001 -0400, you wrote: >I have a 3com Total Control hub V4.1.59, with 7 DSP modem cards. > >I'm getting a ton of complaints from dialup users that all "receiving >traffic" stops, >while they are surfing, or checking mail, or whatever. > >I've monitored one of these users via (monitor ppp), and notice that I am >receiving the PPP packets from the user, but nothing is being sent back. > >I try to ping the IP of the modem, and I get a timeout. > >There is a route in the routing table, for their IP, and it did point to >their modem port. >I checked the status of the port (show int slot:#/mod:#) , and it shows >nothing out of the ordinary. > >I realize that it could be the phone lines, but I have to be sure. > >Has anyone came across this problem before, or know of a better way I can >confirm -where- the problem is ? > > > >- > 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. > > Al Thiel, MIS Spec.Net Internet Services of New York http://www.spec.net "I'm workin' on it!"

I know the Cisco tftp server has a text window that displays what is happening if that would work for you. Mark Thornton San Marcos Internet, Inc 512-393-5300 ----- Original Message ----- Sent: Monday, September 10, 2001 3:45 PM > On Fri, 7 Sep 2001, Mike Andrews wrote: > > > Yup, the util's still on my web page, tho it's probably bit-rotted to hell > > by now. :) I know it's broken for flashing 486 NMCs right now. > > How about T1/PRI cards (going through a 486 NMC)? I've pulled my TCM box > out from behind the firewall, and still no-go on flashing this CT1 card > over to PRI. TFTP timeout. Blinky-Blinky on the RUN/FLT. > > I'd like to do this using some non-windows tftp server so I can see what's > happening... Is it asking for the file or not, etc... > > > It also only works on Unix as-is, because it does a system() call to the > > tftp binary directly. (And tftp thru a firewall really is asking for > > trouble, because of the random port number issue.) > > Wait, yours pushes TO the NMC? > > Charles > > > > > Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com > > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > > Internet access for Frankfort, Lexington, Louisville and surrounding counties > > www.fark.com: If it's not news, it's Fark. (Or something like that.) > > > > On Fri, 7 Sep 2001, Jeff Mcadams wrote: > > > > > Also sprach Charles Sprickman > > > >Yeah, I started seeing all sorts of random ports being hit, so I just > > > >opened up all tcp/udp between the tch and laptop. Now it went ahead > > > >and erased flash, then crapped out. Just sitting there. Nothing in > > > >the firewall logs showing what's up, and it's real addresses behind the > > > >fw, no nat. > > > > > > >I like "copy tftp://some.server/path/to/code slot0:" much better :) > > > > > > There is a sort of minimalist beauty to it, isn't there? ;) > > > > > > What type card are you upgrading? (I don't remember if you stated this > > > in your original message)... > > > > > > If its a .sdl/.nac file combo, then the sdl file is downloaded before > > > the erasing of flash occurs, so you have another problem than tftp being > > > blocked. If its a .dmf file type (ie, the newer HiPer type cards), then > > > they just download in one go, but I don't think they erase flash do > > > they? Now I don't remember. > > > > > > If its the older .sdl/.nac combo, then there is two steps, you download > > > the .sdl, then it erases flash, then you have to tell the NMC to > > > download the nac file in another SNMP operation if I remember correctly. > > > Again, the release notes for some of the later software releases I > > > believe details the operations...its been so long since I've done this, > > > and I don't know that I've ever done it fully manually, that I'm a bit > > > fuzzy on it. > > > > > > I seem to remember that Mike Andrews had a utility that did software > > > upgrades on cards as well...are you still on the list Mike? Am I > > > remembering all of this correctly or not? > > > -- > > > 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. > > > > > - > 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, 7 Sep 2001, Mike Andrews wrote: > Yup, the util's still on my web page, tho it's probably bit-rotted to hell > by now. :) I know it's broken for flashing 486 NMCs right now. How about T1/PRI cards (going through a 486 NMC)? I've pulled my TCM box out from behind the firewall, and still no-go on flashing this CT1 card over to PRI. TFTP timeout. Blinky-Blinky on the RUN/FLT. I'd like to do this using some non-windows tftp server so I can see what's happening... Is it asking for the file or not, etc... > It also only works on Unix as-is, because it does a system() call to the > tftp binary directly. (And tftp thru a firewall really is asking for > trouble, because of the random port number issue.) Wait, yours pushes TO the NMC? Charles > > Mike Andrews * mandrews@dcr.net * mandrews@bit0.com * http://www.bit0.com > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet access for Frankfort, Lexington, Louisville and surrounding counties > www.fark.com: If it's not news, it's Fark. (Or something like that.) > > On Fri, 7 Sep 2001, Jeff Mcadams wrote: > > > Also sprach Charles Sprickman > > >Yeah, I started seeing all sorts of random ports being hit, so I just > > >opened up all tcp/udp between the tch and laptop. Now it went ahead > > >and erased flash, then crapped out. Just sitting there. Nothing in > > >the firewall logs showing what's up, and it's real addresses behind the > > >fw, no nat. > > > > >I like "copy tftp://some.server/path/to/code slot0:" much better :) > > > > There is a sort of minimalist beauty to it, isn't there? ;) > > > > What type card are you upgrading? (I don't remember if you stated this > > in your original message)... > > > > If its a .sdl/.nac file combo, then the sdl file is downloaded before > > the erasing of flash occurs, so you have another problem than tftp being > > blocked. If its a .dmf file type (ie, the newer HiPer type cards), then > > they just download in one go, but I don't think they erase flash do > > they? Now I don't remember. > > > > If its the older .sdl/.nac combo, then there is two steps, you download > > the .sdl, then it erases flash, then you have to tell the NMC to > > download the nac file in another SNMP operation if I remember correctly. > > Again, the release notes for some of the later software releases I > > believe details the operations...its been so long since I've done this, > > and I don't know that I've ever done it fully manually, that I'm a bit > > fuzzy on it. > > > > I seem to remember that Mike Andrews had a utility that did software > > upgrades on cards as well...are you still on the list Mike? Am I > > remembering all of this correctly or not? > > -- > > 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. >

On Fri, 7 Sep 2001, Jeff Mcadams wrote: > I seem to remember that Mike Andrews had a utility that did software > upgrades on cards as well...are you still on the list Mike? Am I > remembering all of this correctly or not? Does he ever! I'd downloaded a mess of his tools back when we still had netservers and all quads, and kind of put off using them... Grabbed them again today. wow! Fixed my PRI card! Kudos to Mike... This is my new way to update code. ---- oscar [/usr/local/home/spork/tch]$ ./usrflash.pl Name of NMC in target chassis: nmc-2 Making sure the hostname and community names are valid... OK. Enter the card number(s) to flash. If flashing multiple cards, they must be identical. Separate numbers with spaces: 1 Lastly, enter the names of the SDL (or DMF) file and the NAC file (if needed). Use full paths if necessary. NO CHECKING is done to make sure the file you specify is appropriate for the type of card you've selected -- this assumes you know what you are doing! Enter NAC or DMF filename: DP030105.NAC Enter SDL filename (leave blank for NMC cards): DP010001.SDL WARNING WARNING DISCLAIMER WARNING WARNING [snip] About to do an SDL Version 1 upload of NAC/DMF file "DP030105.NAC" and SDL file "DP010001.SDL" to nmc-2 cards 1 LAST CHANCE! Enter YES in all caps to proceed: YES Here goes... Sending command 5 to nmc... Command 'Software download' sent to nmc. Status (attempt 1): 1 Software download : In progress / No Error Success. TFTPing DP010001.SDL to nmc... tftp> Verbose mode on. tftp> mode set to octet tftp> putting DP010001.SDL to nmc:SDL [octet] Sent 28210 bytes in 6.9 seconds [32707 bits/sec] tftp> DEBUG: tftp returned code 0 Status (attempt 1): 1 Software download : In progress / Erasing flash Status (attempt 2): 1 Software download : In progress / Erasing flash Status (attempt 3): [etc.] 1 Software download : In progress / Downloading NAC file Success. TFTPing DP030105.NAC to nmc-2... tftp> Verbose mode on. tftp> mode set to octet tftp> putting DP030105.NAC to nmc:DP030105.NAC [octet] Sent 915100 bytes in 257.2 seconds [28463 bits/sec] tftp> DEBUG: tftp returned code 0 Status (attempt 1): 1 Software download : In progress / Resetting NAC Status (attempt 2): 1 Software download : Success / No Error Success. Flash complete! Just to check it, another fine tool: oscar [/usr/local/home/spork/tch]$ ./usrinv.pl nmc Querying nmc....... SL Description P.Code HW ver SW ver Serial # RAM Flash Dipswitches 1 3COM PRI-T1/E1 NAC 0NJ 5.0.0 3.1.5 xxxxxxxx 4096 1024 0x0005 Thanks much Jeff, for reminding me of this, and Mike for writing it. And so as not to taunt people looking at archives: http://www.dcr.net/~mandrews/usrtoys/ Well worth the effort of putting all your gear in the config files. Charles > -- > 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. >

Hello, We've lost the router that provides backhaul at one of our POPs in downtown Manhattan. Our equipment is in the restricted zone east of the World Trade Center area, so we are unable to reach it for repairs, and have so far been unable to contact the personnel on duty for assistance in verifying the status of the router. As a workaround, I'm looking to do some hackery. The only POP we have physical access to has lots of spare POTS lines, and an old Netserver-based 45A chassis. The crippled POP has ARCs, and I can dial in and authenticate locally to get access to the CLI. What I would like to do is the following: -set up a local user on the arc that has no session timeout and allows up to 8 sessions to be bonded together with MLPPP -set up the netserver to dial out on 8 POTS lines to the crippled location and log in as the user set up above -set the default route on the ARC to point to the dial-in session Essentially I want to get bandwidth from POP to POP via 8 POTS lines as a band-aid measure until I can get to the crippled POP to replace/reboot/repair the router. It will be slow, but... better than nothing, which is what we've got. My main problems are: -can I point default to a dialed-in session on the arc, and how -my netserver skills have really faded... -I'm thinking I'll get stuck on MLPPP, setting up the local user to dial out, and nailing the session up. Anyone around that can answer that arc question (and give some hints on making a local user) and/or remembers a good deal about the netserver cli? Thanks, Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com

Also sprach Charles Sprickman >-can I point default to a dialed-in session on the arc, and how Yes, I *believe* you do this with the command: set network user <username> ip default_route_option enable >-my netserver skills have really faded... As have mine, but I do have one or two sitting on a shelf that I could slap in a unit and try to figure out what needs to be set to do what you need to do... Give me a call (numbers in the .sig) if you want me to do so (I'll let you call since I suspect you'll be *much* busier than I today ;). My extension is 1153. >-I'm thinking I'll get stuck on MLPPP, setting up the local user to >dial out, and nailing the session up. >Anyone around that can answer that arc question (and give some hints on >making a local user) and/or remembers a good deal about the netserver >cli? You *might* find it easier to use the on-demand routing in the Arc to make the calls. The Arc can look in the user's table for users that can dial to a remote gateway on-demand...it can use this as a default route as well I believe. Alternatively, you could run RIPv2 over this connection from your NETServer and even get dynamic routing on it...or inject default into your RIPv2 cloud and let RIPv2 handle the default. Again...I'm available for any help that I can give... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I don't have the old manuals, but I do remember an entire section dedicated to connecting one TC hub to another via dialup connections, just like the current manuals have. It is possible, the problem will be getting the correct information to do so. If you have a current 3Com contract you could search the archives. The last time I did they had manuals online going back to the dark ages. Jeff is probably the most knowledgable person on this list to have on your side, and his willingness to break out an antique and fire it up should be considered a great act of kindness. I know I have an old netserver on the shelf somewhere, but no code for it, and no manuals. Mark Thornton San Marcos Internet, Inc 512-393-5300 ----- Original Message ----- Sent: Thursday, September 13, 2001 11:34 AM > On Thu, 13 Sep 2001, Jeff Mcadams wrote: > > > Also sprach Charles Sprickman > > >-can I point default to a dialed-in session on the arc, and how > > > > Yes, I *believe* you do this with the command: > > set network user <username> ip default_route_option enable > > Can anyone else confirm this? > > Thanks, > > Charles > > > - > 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.

Charles, I don't think that you have an option for default_route on the Netserver. However I know that I can do this for you. What you need is setup a location and a corresponding user, based on the location you can start the lan to lan and one of the options on the location is to have the default route. If you need help - send me an email or page me - send an email to page@iyka.com and will help you do this. V On Thu, 13 Sep 2001, Charles Sprickman wrote: > On Thu, 13 Sep 2001, Jeff Mcadams wrote: > > > Also sprach Charles Sprickman > > >-can I point default to a dialed-in session on the arc, and how > > > > Yes, I *believe* you do this with the command: > > set network user <username> ip default_route_option enable > > Can anyone else confirm this? > > Thanks, > > Charles > > > - > 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, 13 Sep 2001, Jeff Mcadams wrote: > Also sprach Charles Sprickman > >-can I point default to a dialed-in session on the arc, and how > > Yes, I *believe* you do this with the command: > set network user <username> ip default_route_option enable Can anyone else confirm this? Thanks, Charles

Also sprach ved@iyka.com >I don't think that you have an option for default_route on the >Netserver. However I know that I can do this for you. What you need >is setup a location and a corresponding user, based on the location you >can start the lan to lan and one of the options on the location is to >have the default route. Actually, I think he needs to the default route on the Arc to point *to* the NETServer. Either could probably do the actual dialing, but the Arc is in the facility in NY with no backhaul access, so its the one that needs the default route to point over the dial-up link. The NETServer would have a default route pointing out over its ethernet interface as a typical setup would be. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I haven't had a chance to test this out as I've got bigger fish to fry... Thanks for all the input though, I very much appreciate it... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Thu, 13 Sep 2001, Jeff Mcadams wrote: > Also sprach ved@iyka.com > >I don't think that you have an option for default_route on the > >Netserver. However I know that I can do this for you. What you need > >is setup a location and a corresponding user, based on the location you > >can start the lan to lan and one of the options on the location is to > >have the default route. > > Actually, I think he needs to the default route on the Arc to point *to* > the NETServer. Either could probably do the actual dialing, but the Arc > is in the facility in NY with no backhaul access, so its the one that > needs the default route to point over the dial-up link. The NETServer > would have a default route pointing out over its ethernet interface as a > typical setup would be. > -- > 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'll tell you one good thing about the usr gear... It seems to operate just fine when the ambient temperature outside the cabinet is 106 degrees... Sadly, the little Cisco did not like that temperature... | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Fri, 14 Sep 2001, Charles Sprickman wrote: > I haven't had a chance to test this out as I've got bigger fish to fry... > > Thanks for all the input though, I very much appreciate it... > > Charles > > | Charles Sprickman | Internet Channel > | INCH System Administration Team | (212)243-5200 > | spork@inch.com | access@inch.com > > On Thu, 13 Sep 2001, Jeff Mcadams wrote: > > > Also sprach ved@iyka.com > > >I don't think that you have an option for default_route on the > > >Netserver. However I know that I can do this for you. What you need > > >is setup a location and a corresponding user, based on the location you > > >can start the lan to lan and one of the options on the location is to > > >have the default route. > > > > Actually, I think he needs to the default route on the Arc to point *to* > > the NETServer. Either could probably do the actual dialing, but the Arc > > is in the facility in NY with no backhaul access, so its the one that > > needs the default route to point over the dial-up link. The NETServer > > would have a default route pointing out over its ethernet interface as a > > typical setup would be. > > -- > > 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. >

Is there a difference in the T1 and E1 DSP's? Can an E1 DSP be configured as a T1 DSP? Mark Thornton

The E1 (HiPER) DSP card has 6 more dsp chips on it, either on a daughter board, or the new card has space on the actual board. I've tried to use the e1 flash code on the t1 board with no luck, but not the other way around...... The e1 nic (from memory) is also hard wired with a 2.048Mhz rock, so I don't think you'll have too much luck on the 1.5ish Mhz T1 service. Having said that, us e1'ers are always looking for e1 gear!! Regards, Richard ----- Original Message ----- Sent: Tuesday, September 18, 2001 3:10 AM > Is there a difference in the T1 and E1 DSP's? Can an E1 DSP be configured as > a T1 DSP? > > Mark Thornton > > > > > > - > 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 HyperDSP that was a member of a NFAS group that I am trying to set up without an NFAS group. I cannot find where to turn off NFAS. The docs are not very descriptive of the NFAS commands anyway, and I have found no reference to deleting NFAS. Anyone have some experience they can share? Mark Thornton San Marcos Internet, Inc 512-393-5300

Can somebody help me with one of the weirdest problems? I have 4xquad analog/digital modem cards in a total control hub. = I also have an NMC and an Edgeserver Pro card. The strange thing is that the modems do not detect or respond to incoming = calls. I have configured them as per the edgeserver documentation and have set dip switches 3,5&8 up. I have also followe= d to the letter every step in the edgeserver config. Can anybody offer advice on this? mail2web - Check your email from the web at http://mail2web.com/ .

I am trying to find 2 used HiperDSPs. Our company has emailed and called the ISP-NETWROKHARDWARE guy who's always advertising on the list, but still haven't heard back. Has anyone dealt with these people before or can anyone suggest another place to pick up a couple used DSPs? Thank you, Jobe Bittman System Administrator Terracom Network Services

I've recently experienced some cases in which my ARC appears to have spontaneously rebooted, dropping all dial-up connections. I haven't found any logging info that might shed light on this. Anyone know what the issue might be? ARC 4.2.32 DSP 2.0.81 Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Do you think USR 3 Commworks will figure out that most of their future growth is running away from them for EOLing all of their older gear? If I had a say in their company I would tell the engineers to get busy real fast and develop a FREE upgrade for V.92 for all cards from Quad through the 96 Port cards. I have been bled enough and so has the majority of the other ISP's I talk to. We are getting ready for the cold season when everyone buys ports. Will you be buying TC's? I doubt I will. John Scrivner

Also sprach John Scrivner >Do you think USR 3 Commworks will figure out that most of their future >growth is running away from them for EOLing all of their older gear? If >I had a say in their company I would tell the engineers to get busy >real fast and develop a FREE upgrade for V.92 for all cards from Quad >through the 96 Port cards. I have been bled enough and so has the >majority of the other ISP's I talk to. We are getting ready for the >cold season when everyone buys ports. Will you be buying TC's? I doubt >I will. Given that they've been told this, explicitely, multiple times and they exhibit no evidence of understanding this. No. Someone seriously needs to slap Irfan Ali upside the head a bit and get him to realize this. Perhaps someone needs to slap Bruce Claflin upside the head to get him to realize the situation as it exists with CommWorks and us. I am personally still astounded that Al Huefner still has a job with CommWorks. If I were the 3Com shareholder and knew the situation as I know it as a customer of 3Com, I'd be considering filing a shareholder lawsuit at the clear incompetence exhibited by not putting this man on the street. He is personally responsible for the support policies at CommWorks, and therefore is personally responsible for the vast majority of CommWorks' customer loses over the past 3 years. As a reminder...3Com uses standard email addresses for employees, so email can be sent to these people, and anyone else in the company, by using the pattern firstname_lastname@3com.com. al_huefner@3com.com irfan_ali@3com.com bruce_claflin@3com.com That all is, of course, unless your me and your email is blocked at their email server, because of some bogus claims of violating 3Com's security. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Is v.92 supported on the HiPerDSP's? On Mon, 24 Sep 2001, John Scrivner wrote: > Do you think USR 3 Commworks will figure out that most of their future > growth is running away from them for EOLing all of their older gear? If > I had a say in their company I would tell the engineers to get busy real > fast and develop a FREE upgrade for V.92 for all cards from Quad through > the 96 Port cards. I have been bled enough and so has the majority of > the other ISP's I talk to. We are getting ready for the cold season when > everyone buys ports. Will you be buying TC's? I doubt I will. > John Scrivner > -- Aaron Nabil

Especially now that the other vendors who have v.92 product with 1 year free support are giving up to $5000 trade per 96 port unit it looks like some more of us are going to be come x-3com. I especially dont like the thumb in the nose that I got from 3com's president after several email dialogs and seemingly a viable discussion, then suddenly nothing......even tho I re-emailed several times. P.S. I still have 100 shares of 3Com stock! That makes me a shareholder. Did you hear about the Sony chairman giving attention to his shareholders because he doesnt want to "lose face"! --Rich Adams, President-Dayton Internet Services, Dayton, Ohio-- --w8mfd@dayton.net--www.dayton.net--www.dayton.com--937-586-2500-- ---------- Forwarded message ---------- Reply-To: usr-tc@lists.xmission.com Also sprach John Scrivner >Do you think USR 3 Commworks will figure out that most of their future >growth is running away from them for EOLing all of their older gear? If >I had a say in their company I would tell the engineers to get busy >real fast and develop a FREE upgrade for V.92 for all cards from Quad >through the 96 Port cards. I have been bled enough and so has the >majority of the other ISP's I talk to. We are getting ready for the >cold season when everyone buys ports. Will you be buying TC's? I doubt >I will. Given that they've been told this, explicitely, multiple times and they exhibit no evidence of understanding this. No. Someone seriously needs to slap Irfan Ali upside the head a bit and get him to realize this. Perhaps someone needs to slap Bruce Claflin upside the head to get him to realize the situation as it exists with CommWorks and us. I am personally still astounded that Al Huefner still has a job with CommWorks. If I were the 3Com shareholder and knew the situation as I know it as a customer of 3Com, I'd be considering filing a shareholder lawsuit at the clear incompetence exhibited by not putting this man on the street. He is personally responsible for the support policies at CommWorks, and therefore is personally responsible for the vast majority of CommWorks' customer loses over the past 3 years. As a reminder...3Com uses standard email addresses for employees, so email can be sent to these people, and anyone else in the company, by using the pattern firstname_lastname@3com.com. al_huefner@3com.com irfan_ali@3com.com bruce_claflin@3com.com That all is, of course, unless your me and your email is blocked at their email server, because of some bogus claims of violating 3Com's security. -- 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.

Also sprach nabil@spiritone.com >Is v.92 supported on the HiPerDSP's? V.92 isn't supported on anything from 3Com yet...as far as I know, its yet to be released, but the word I've gotten (several times) is that, yes, it will be supported on HiPerDSPs (single span cards). Be aware that if you have the older 486 based NMCs, those will need to be upgraded to support V.92 as well. This is something that is apparently catching quite a few folks by surprise...3Com hasn't hidden this information, but it hasn't gotten the attention the some of the other EOL'ed products have. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

File against them Rich (since you are a stockholder)... you would have my support! -- Edgar D. Taylor President/CEO FIRST USA Inc. Voice: (800) 716-6190 Fax: (740) 695-7258 Email: ed@1st.net Web: http://www.1st.net -- Simply 1st in Internet Solutions! -- -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dayton Internet Sent: Monday, September 24, 2001 7:07 PM Cc: al_huefner@3com.com; bruce_clafline@3com.com; jeffm@iglou.com; usr-tc@lists.xmission.com Especially now that the other vendors who have v.92 product with 1 year free support are giving up to $5000 trade per 96 port unit it looks like some more of us are going to be come x-3com. I especially dont like the thumb in the nose that I got from 3com's president after several email dialogs and seemingly a viable discussion, then suddenly nothing......even tho I re-emailed several times. P.S. I still have 100 shares of 3Com stock! That makes me a shareholder. Did you hear about the Sony chairman giving attention to his shareholders because he doesnt want to "lose face"! --Rich Adams, President-Dayton Internet Services, Dayton, Ohio-- --w8mfd@dayton.net--www.dayton.net--www.dayton.com--937-586-2500-- ---------- Forwarded message ---------- Reply-To: usr-tc@lists.xmission.com Also sprach John Scrivner >Do you think USR 3 Commworks will figure out that most of their future >growth is running away from them for EOLing all of their older gear? If >I had a say in their company I would tell the engineers to get busy >real fast and develop a FREE upgrade for V.92 for all cards from Quad >through the 96 Port cards. I have been bled enough and so has the >majority of the other ISP's I talk to. We are getting ready for the >cold season when everyone buys ports. Will you be buying TC's? I doubt >I will. Given that they've been told this, explicitely, multiple times and they exhibit no evidence of understanding this. No. Someone seriously needs to slap Irfan Ali upside the head a bit and get him to realize this. Perhaps someone needs to slap Bruce Claflin upside the head to get him to realize the situation as it exists with CommWorks and us. I am personally still astounded that Al Huefner still has a job with CommWorks. If I were the 3Com shareholder and knew the situation as I know it as a customer of 3Com, I'd be considering filing a shareholder lawsuit at the clear incompetence exhibited by not putting this man on the street. He is personally responsible for the support policies at CommWorks, and therefore is personally responsible for the vast majority of CommWorks' customer loses over the past 3 years. As a reminder...3Com uses standard email addresses for employees, so email can be sent to these people, and anyone else in the company, by using the pattern firstname_lastname@3com.com. al_huefner@3com.com irfan_ali@3com.com bruce_claflin@3com.com That all is, of course, unless your me and your email is blocked at their email server, because of some bogus claims of violating 3Com's security. -- 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 I am having a really major problem here. I now have TWO total control chassis, and my quad analog/digital modems will not= respond to incoming calls in either. Is there something I'm not doing? Can anybody help ? mail2web - Check your email from the web at http://mail2web.com/ .

I am running HiperARC 4.1.59. We have not changed any code or setting on this box for over a year. Of late, the call volume into this box has been very high, often maxing it out (this box only has 4 PRI's on HiperDSP's coming into it). Suddenly, every 10 days or so, users are no longer to route to anything outside of the TC box. They can connect. They can ping the ethernet port on the TC, but anything beyond that dies. I can dial into another TC box and telnet to this TC, so the ethernet port is actually responding to traffic from outside interfaces. It's just that users connected to that physical box can't route out. Issuing a reboot command at the HARC console corrects the problem for another week or 2. Is there anything I should be looking for that might be causing this? Is this a memory issue (wouldn't think so with only 4 PRI's connected)? Is this a code issue - I know the code rev is a little old, but is has proven very stable for us in every other aspect. Never once experienced the hung modem pairs on this box. When call volume into this box was lower, it had been running without a reboot for 16 months. I am not running RIP or OSPF on this box either. Any thoughts? -- Scot

Are you using them in analog mode or digital? If analog, using the Total Control Manager, make sure that you have elected the input source to be from the NIC, not the TDM bus. Alternately, if digital, make sure you have the input source the TDM bus and not the NIC. Pat On Tue, 25 Sep 2001, notuteye@mail.ucomgh.com wrote: > Hi > I am having a really major problem here. I now have TWO total control chassis, and my quad analog/digital modems will not respond to incoming calls in either. Is there something I'm not doing? Can anybody help ? > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.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. > -- Patrick C. Wolf SDC Internet pwolf@sdc.org 722 N California Suite 4 (505) 838-1620 Socorro, NM 87801

Are you using them in analog mode or digital? If analog, using the Total Control Manager, make sure that you have elected the input source to be from the NIC, not the TDM bus. Alternately, if digital, make sure you have the input source the TDM bus and not the NIC. Pat On Tue, 25 Sep 2001, notuteye@mail.ucomgh.com wrote: > Hi > I am having a really major problem here. I now have TWO total control chassis, and my quad analog/digital modems will not respond to incoming calls in either. Is there something I'm not doing? Can anybody help ? > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.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. > -- Patrick C. Wolf SDC Internet pwolf@sdc.org 722 N California Suite 4 (505) 838-1620 Socorro, NM 87801

Does anyone know if the 486 Hiper NMC's came with v.90 enabled or was that an optional feature? Mitch Dailey NileNet, Ltd. mtd@nilenet.com

As far as I know, the x2 key is what you pay for. Have to have that to enable v90 though. It is an option for all NMC's, I believe. You can move the key (or 3Com can) from one NMC to another. At 04:21 PM 9/25/2001 -0600, you wrote: >Does anyone know if the 486 Hiper NMC's came with v.90 enabled or was that >an optional feature? > >Mitch Dailey >NileNet, Ltd. >mtd@nilenet.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. Thanks, Greg Coffey, V 307-234-5443 x11 ===================================================================== 100 N. Center St. #201, Casper, WY 82601

I have a 486 NMC that I tried to upgrade to the Hiper code (which requires the upgraded ram and flash). I failed to notice the larger flash requirements before attempting the update and needless to say the card won't boot now. The rn/fl light flashes green. I know that means it needs a download but I've tried several times to download with the pcsdl utility but I've never been able to establish communication. The NMC in question was v.90 enabled, but given my luck the unlock code is now fried (the entire chassis was bought used so I'm probably out of luck for 3com to move the unlock code). Any suggestions? I found a deal on an NMC with the Hiper code and upgraded ram and the 10/100 nic so I was just planning on buying a new one (which is kind of dumb but I'd really like to get this box in service). -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Coffey Sent: Tuesday, September 25, 2001 4:45 PM As far as I know, the x2 key is what you pay for. Have to have that to enable v90 though. It is an option for all NMC's, I believe. You can move the key (or 3Com can) from one NMC to another. At 04:21 PM 9/25/2001 -0600, you wrote: >Does anyone know if the 486 Hiper NMC's came with v.90 enabled or was that >an optional feature? > >Mitch Dailey >NileNet, Ltd. >mtd@nilenet.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. Thanks, Greg Coffey, V 307-234-5443 x11 ===================================================================== 100 N. Center St. #201, Casper, WY 82601 - 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.

Partial Listing...All in stock. Prices negotiable within reason. WTB: (STANDARD) USR NMC v90 enabled Want to Sell: Hiper NMC sets $1000 Hiper DSP sets $1400 Hiper ARC sets 64MB $1200 MultiSpan 96port DSP sets (NEW) $11,999...Best price on market! Hiper Bundles - HD Chassis with 70A power NMC Hiper ARC 2x Hiper DSP $5000 Quad Bundles - Classic chassis with dual 45a power nmc non v90 netserver card 12x analog/digital modem sets dual pri/t1 $1100 Netserver PRI $200 Dual PRI $200 NMC non v90 $200 All flavors of quad modems...shott me an email if your interested.

Nobody is in the Market for 3com products anymore(due to their Support and attitude towards their customers). No use advertising on here. You might as well have a yardsale and try and get a couple bucks while you can! -- Edgar D. Taylor President/CEO FIRST USA Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of ISP-NetworkHardware.com Sent: Tuesday, September 25, 2001 5:29 PM Partial Listing...All in stock. Prices negotiable within reason. WTB: (STANDARD) USR NMC v90 enabled Want to Sell: Hiper NMC sets $1000 Hiper DSP sets $1400 Hiper ARC sets 64MB $1200 MultiSpan 96port DSP sets (NEW) $11,999...Best price on market! Hiper Bundles - HD Chassis with 70A power NMC Hiper ARC 2x Hiper DSP $5000 Quad Bundles - Classic chassis with dual 45a power nmc non v90 netserver card 12x analog/digital modem sets dual pri/t1 $1100 Netserver PRI $200 Dual PRI $200 NMC non v90 $200 All flavors of quad modems...shott me an email if your interested. - 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.

Patric Thanks for the response, it seems to have cleared the initial problem. Now I'm faced with the fact that the modems seem t= o work in some slots but not in others. For instance, if I put a modem into slot 1 or slot 2, it works fine, but putting = the same modem card and NIC into slot 11 doesn't produce any result. What is going on? Is there a chassis config command = I've neglected?? Original Message:

I believe that the x2/V.90 key is only necessary for Quad cards. A 486 NMC with HiperDSPs doesn't need a key to support V.90. Mike Wilker Director of Network Operations Tiger Communications DBA Local Link USA, Globaleyes Comm, Protocom ----- Original Message ----- Sent: Tuesday, September 25, 2001 5:21 PM Does anyone know if the 486 Hiper NMC's came with v.90 enabled or was that an optional feature? Mitch Dailey NileNet, Ltd. mtd@nilenet.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.

Also sprach Mike Wilker >I believe that the x2/V.90 key is only necessary for Quad cards. A 486 >NMC with HiperDSPs doesn't need a key to support V.90. That is correct. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

hello all I have rather strange problem. My RADIUS server is rejecting the authentication requests... but the ARC's (two of them) are letting users on online. The user in question is NOT in the users table. The same RADIUS server is working 'correctly' with PATTON 2800's and 2996's (you cannot connect with the 'disabled' accounts). For a starter here is sho radius RADIUS SETTINGS Fill Null Attributes : DISABLED Attribute Style: STANDARD Authentication Algorithm: ROUND_ROBIN Interim Accounting Interval Status: DISABLED Interim Accounting Interval: 240 seconds IEA Radius Source Port Authentication ENABLED IEA User Radius supplied username DISABLED Send Unauthenticated STOP record ENABLED Send Accounting records for default user: ENABLED Report Acct IP Addr only for Primary Link: DISABLED Send only STOP Acct for failed services: DISABLED Test the authentication locally via radtest: radtest jericho xxxxx localhost s1 xxxxx Sending request to server localhost, port 1812. radrecv: Reply from host 127.0.0.1 code=3, id=84, length=20 Access denied. yet TC gives me: HiPer>> _auth jericho xxxxx CLI - User: jericho is Authenticated But the radius server records the denial: Wed Sep 26 18:27:16 2001: Auth: unix_pass: [jericho]: invalid shell Wed Sep 26 18:27:16 2001: Auth: Login incorrect: [jericho/xxxxx] -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545

We have several TC chassis with quad modems that we want to convert to PRI. One of chassis has a DSP (2.1.9) card that works fine with a PRI. They all have HyperArc with 5.0.99 software. The process I went through on a chassis was to load the current PRI software on the T1/PRI card, and set the trunk setting b8zs,esf, switch type 5ess, (although I believe they have a CTI switch). The other settings match (dnis,eandmtypeII, wink, etc) the CT1 settings. Then on the Quad modems I set the "Line Interface Source" from t1Tdm to priTdm. Save and reboot. When everything is connected, I have all green lights, and the switch guy sees the d channel come up. When we dial into that line, the switch guy sees the call come in on the first trunk but the modem doesn't answer. I don't see any lights flash on the modem card to indicate a call coming in. The default config on the PRI card is round robin allocation of modems as opposed to fixed assignment which I didn't change. The DSP card is using fixed assignment routing. If the switch guy converts it back to a CT1, and I load the CT1 software back in, and switch the line interface source on the quad cards, then it works fine. Can anyone tell me what I am missing, or point me in a direction to look? Thanks. Randy McMillan PacInfo

Paul, First off - we need more info. What radius server? Version? Which ARC code? How many ARCs on the network? How many radius servers do you have (why is ROUND_ROBIN enabled?) what does sh authentication contain? What does your radius DEFAULT entry (or entries) look like? Was it working before? What changed? Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 ----- Original Message ----- Sent: Wednesday, September 26, 2001 6:01 PM > hello all > > I have rather strange problem. My RADIUS server is rejecting the > authentication requests... but the ARC's (two of them) are letting users > on online. The user in question is NOT in the users table. > > The same RADIUS server is working 'correctly' with PATTON 2800's and > 2996's (you cannot connect with the 'disabled' accounts). > > For a starter here is sho radius > > RADIUS SETTINGS > Fill Null Attributes : DISABLED > Attribute Style: STANDARD > Authentication Algorithm: ROUND_ROBIN > Interim Accounting Interval Status: DISABLED > Interim Accounting Interval: 240 seconds > IEA Radius Source Port Authentication ENABLED > IEA User Radius supplied username DISABLED > Send Unauthenticated STOP record ENABLED > Send Accounting records for default user: ENABLED > Report Acct IP Addr only for Primary Link: DISABLED > Send only STOP Acct for failed services: DISABLED > > > Test the authentication locally via radtest: > > radtest jericho xxxxx localhost s1 xxxxx > > Sending request to server localhost, port 1812. > radrecv: Reply from host 127.0.0.1 code=3, id=84, length=20 > Access denied. > > yet TC gives me: > > HiPer>> _auth jericho xxxxx > CLI - User: jericho is Authenticated > > But the radius server records the denial: > > Wed Sep 26 18:27:16 2001: Auth: unix_pass: [jericho]: invalid shell > Wed Sep 26 18:27:16 2001: Auth: Login incorrect: [jericho/xxxxx] > > -- > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > 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. > >

2 Chassis like the following: =================== 1 Dual T1 (CT1/PRI) Card 12 Digital Quad Modems 1 HiperARC w/64 Megs 1 NMC (x2/v90) enabled w/16-20 Megs 1 70A AC Power Supply TOTAL SHIPPED (Contential US) = $2500.00 Additional 70A PS = $250.00 TCM 8.0.10 included. Will configure, deliver and warranty for 90 days. Free basic support. Just came out of service. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838

Have you run the radius diagnostics on the HiperArc themselves and look at what the received packets are? If you do and want something to compare it to I could do the same on mine. Ours are authenticating against Vircom VopRadius and I know the disable function works because we use it to get payment from a small percentage of clients. It is amazing how fast they call after they are disabled. Mark Thornton San Marcos Internet, Inc 512-393-5300 ----- Original Message ----- Sent: Thursday, September 27, 2001 11:50 AM > I don't know how long its not been working correctly.... I just discovered > it this week. No major changes to the radius server, or any other part of > the radius system. > > The Pattons work fine (4 of them off this 1 radius server) only the TC's > are not honoring the REJECT from the server. > > Even if I point the TC's at the secondary RADIUS server it still has the > same results.... Pattons deny corrrectly, TC's allow it. > > As I stated before, the user list on the TC's are empty, save admin and > DEFAULT. And from my understanding there is no way to set the > authentication to 'allow all' from the default entry. > > I looked at the radius info going to and coming from the server (CISTRON > 1.6.4) and they are correct (same REJECT response sent to Patton and TC > auth requests). > > So it's either a bug in the TC ARC code or a config item. But my search > has not uncovered any type of 'allow all' scheme for dial in users. > > And since I have no support contract from 3COM, even if it is a software > bug (I can't see how, it worked fine before) I do not have access to any > code. > > The ARC's are running different ARC software as one is a 486 and one is a > Pentium. I do not have access to the version now.. at a remote site on a > laptop with no access to the NMC's for TCM to tell me what they are > running. > > -- > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Thu, 27 Sep 2001, Marshall Morgan wrote: > > > Paul, > > > > First off - we need more info. > > > > What radius server? Version? > > Which ARC code? How many ARCs on the network? > > How many radius servers do you have (why is ROUND_ROBIN enabled?) > > what does sh authentication contain? > > What does your radius DEFAULT entry (or entries) look like? > > Was it working before? What changed? > > > > Marshall Morgan > > > > Internet Doorway, Inc (aka NETDOOR) > > http://www.netdoor.com > > > > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > > ----- Original Message ----- > > From: "Paul Farber" <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Wednesday, September 26, 2001 6:01 PM > > Subject: (usr-tc) ARC not denying logins > > > > > > > hello all > > > > > > I have rather strange problem. My RADIUS server is rejecting the > > > authentication requests... but the ARC's (two of them) are letting users > > > on online. The user in question is NOT in the users table. > > > > > > The same RADIUS server is working 'correctly' with PATTON 2800's and > > > 2996's (you cannot connect with the 'disabled' accounts). > > > > > > For a starter here is sho radius > > > > > > RADIUS SETTINGS > > > Fill Null Attributes : DISABLED > > > Attribute Style: STANDARD > > > Authentication Algorithm: ROUND_ROBIN > > > Interim Accounting Interval Status: DISABLED > > > Interim Accounting Interval: 240 seconds > > > IEA Radius Source Port Authentication ENABLED > > > IEA User Radius supplied username DISABLED > > > Send Unauthenticated STOP record ENABLED > > > Send Accounting records for default user: ENABLED > > > Report Acct IP Addr only for Primary Link: DISABLED > > > Send only STOP Acct for failed services: DISABLED > > > > > > > > > Test the authentication locally via radtest: > > > > > > radtest jericho xxxxx localhost s1 xxxxx > > > > > > Sending request to server localhost, port 1812. > > > radrecv: Reply from host 127.0.0.1 code=3, id=84, length=20 > > > Access denied. > > > > > > yet TC gives me: > > > > > > HiPer>> _auth jericho xxxxx > > > CLI - User: jericho is Authenticated > > > > > > But the radius server records the denial: > > > > > > Wed Sep 26 18:27:16 2001: Auth: unix_pass: [jericho]: invalid shell > > > Wed Sep 26 18:27:16 2001: Auth: Login incorrect: [jericho/xxxxx] > > > > > > -- > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > > > > - > > > 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.

I don't know how long its not been working correctly.... I just discovered it this week. No major changes to the radius server, or any other part of the radius system. The Pattons work fine (4 of them off this 1 radius server) only the TC's are not honoring the REJECT from the server. Even if I point the TC's at the secondary RADIUS server it still has the same results.... Pattons deny corrrectly, TC's allow it. As I stated before, the user list on the TC's are empty, save admin and DEFAULT. And from my understanding there is no way to set the authentication to 'allow all' from the default entry. I looked at the radius info going to and coming from the server (CISTRON 1.6.4) and they are correct (same REJECT response sent to Patton and TC auth requests). So it's either a bug in the TC ARC code or a config item. But my search has not uncovered any type of 'allow all' scheme for dial in users. And since I have no support contract from 3COM, even if it is a software bug (I can't see how, it worked fine before) I do not have access to any code. The ARC's are running different ARC software as one is a 486 and one is a Pentium. I do not have access to the version now.. at a remote site on a laptop with no access to the NMC's for TCM to tell me what they are running. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 27 Sep 2001, Marshall Morgan wrote: > Paul, > > First off - we need more info. > > What radius server? Version? > Which ARC code? How many ARCs on the network? > How many radius servers do you have (why is ROUND_ROBIN enabled?) > what does sh authentication contain? > What does your radius DEFAULT entry (or entries) look like? > Was it working before? What changed? > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, September 26, 2001 6:01 PM > Subject: (usr-tc) ARC not denying logins > > > > hello all > > > > I have rather strange problem. My RADIUS server is rejecting the > > authentication requests... but the ARC's (two of them) are letting users > > on online. The user in question is NOT in the users table. > > > > The same RADIUS server is working 'correctly' with PATTON 2800's and > > 2996's (you cannot connect with the 'disabled' accounts). > > > > For a starter here is sho radius > > > > RADIUS SETTINGS > > Fill Null Attributes : DISABLED > > Attribute Style: STANDARD > > Authentication Algorithm: ROUND_ROBIN > > Interim Accounting Interval Status: DISABLED > > Interim Accounting Interval: 240 seconds > > IEA Radius Source Port Authentication ENABLED > > IEA User Radius supplied username DISABLED > > Send Unauthenticated STOP record ENABLED > > Send Accounting records for default user: ENABLED > > Report Acct IP Addr only for Primary Link: DISABLED > > Send only STOP Acct for failed services: DISABLED > > > > > > Test the authentication locally via radtest: > > > > radtest jericho xxxxx localhost s1 xxxxx > > > > Sending request to server localhost, port 1812. > > radrecv: Reply from host 127.0.0.1 code=3, id=84, length=20 > > Access denied. > > > > yet TC gives me: > > > > HiPer>> _auth jericho xxxxx > > CLI - User: jericho is Authenticated > > > > But the radius server records the denial: > > > > Wed Sep 26 18:27:16 2001: Auth: unix_pass: [jericho]: invalid shell > > Wed Sep 26 18:27:16 2001: Auth: Login incorrect: [jericho/xxxxx] > > > > -- > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > 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. >

It working now... there must be some sort of cache in the CISTRON server.... tries the _auth cmd this morning and all of a sudden they fail. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 27 Sep 2001, Mark Thornton wrote: > Have you run the radius diagnostics on the HiperArc themselves and look at > what the received packets are? If you do and want something to compare it to > I could do the same on mine. Ours are authenticating against Vircom > VopRadius and I know the disable function works because we use it to get > payment from a small percentage of clients. It is amazing how fast they call > after they are disabled. > > Mark Thornton > San Marcos Internet, Inc > 512-393-5300 > > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, September 27, 2001 11:50 AM > Subject: Re: (usr-tc) ARC not denying logins > > > > I don't know how long its not been working correctly.... I just discovered > > it this week. No major changes to the radius server, or any other part of > > the radius system. > > > > The Pattons work fine (4 of them off this 1 radius server) only the TC's > > are not honoring the REJECT from the server. > > > > Even if I point the TC's at the secondary RADIUS server it still has the > > same results.... Pattons deny corrrectly, TC's allow it. > > > > As I stated before, the user list on the TC's are empty, save admin and > > DEFAULT. And from my understanding there is no way to set the > > authentication to 'allow all' from the default entry. > > > > I looked at the radius info going to and coming from the server (CISTRON > > 1.6.4) and they are correct (same REJECT response sent to Patton and TC > > auth requests). > > > > So it's either a bug in the TC ARC code or a config item. But my search > > has not uncovered any type of 'allow all' scheme for dial in users. > > > > And since I have no support contract from 3COM, even if it is a software > > bug (I can't see how, it worked fine before) I do not have access to any > > code. > > > > The ARC's are running different ARC software as one is a 486 and one is a > > Pentium. I do not have access to the version now.. at a remote site on a > > laptop with no access to the NMC's for TCM to tell me what they are > > running. > > > > -- > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Thu, 27 Sep 2001, Marshall Morgan wrote: > > > > > Paul, > > > > > > First off - we need more info. > > > > > > What radius server? Version? > > > Which ARC code? How many ARCs on the network? > > > How many radius servers do you have (why is ROUND_ROBIN enabled?) > > > what does sh authentication contain? > > > What does your radius DEFAULT entry (or entries) look like? > > > Was it working before? What changed? > > > > > > Marshall Morgan > > > > > > Internet Doorway, Inc (aka NETDOOR) > > > http://www.netdoor.com > > > > > > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax > 601.969.3838 > > > ----- Original Message ----- > > > From: "Paul Farber" <farber@admin.f-tech.net> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Wednesday, September 26, 2001 6:01 PM > > > Subject: (usr-tc) ARC not denying logins > > > > > > > > > > hello all > > > > > > > > I have rather strange problem. My RADIUS server is rejecting the > > > > authentication requests... but the ARC's (two of them) are letting > users > > > > on online. The user in question is NOT in the users table. > > > > > > > > The same RADIUS server is working 'correctly' with PATTON 2800's and > > > > 2996's (you cannot connect with the 'disabled' accounts). > > > > > > > > For a starter here is sho radius > > > > > > > > RADIUS SETTINGS > > > > Fill Null Attributes : DISABLED > > > > Attribute Style: STANDARD > > > > Authentication Algorithm: ROUND_ROBIN > > > > Interim Accounting Interval Status: DISABLED > > > > Interim Accounting Interval: 240 seconds > > > > IEA Radius Source Port Authentication ENABLED > > > > IEA User Radius supplied username DISABLED > > > > Send Unauthenticated STOP record ENABLED > > > > Send Accounting records for default user: ENABLED > > > > Report Acct IP Addr only for Primary Link: DISABLED > > > > Send only STOP Acct for failed services: DISABLED > > > > > > > > > > > > Test the authentication locally via radtest: > > > > > > > > radtest jericho xxxxx localhost s1 xxxxx > > > > > > > > Sending request to server localhost, port 1812. > > > > radrecv: Reply from host 127.0.0.1 code=3, id=84, length=20 > > > > Access denied. > > > > > > > > yet TC gives me: > > > > > > > > HiPer>> _auth jericho xxxxx > > > > CLI - User: jericho is Authenticated > > > > > > > > But the radius server records the denial: > > > > > > > > Wed Sep 26 18:27:16 2001: Auth: unix_pass: [jericho]: invalid shell > > > > Wed Sep 26 18:27:16 2001: Auth: Login incorrect: [jericho/xxxxx] > > > > > > > > -- > > > > Paul Farber > > > > Farber Technology > > > > farber@admin.f-tech.net > > > > Ph 570-628-5303 > > > > Fax 570-628-5545 > > > > > > > > > > > > - > > > > 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. > > > > - > 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 do you identify the different types of HiperNMC's? What is a P5NMC vs. a NMC(333)? Mark Thornton San Marcos Internet, Inc 512-393-5300 ----- Original Message ----- Sent: Friday, September 28, 2001 10:09 AM > Hi, > > Just went through the same thing... > > Spent some time trying to find my mistake, then started poking around the > "performance monitor" both on the PRI level and timeslot level. I found > that the modems were showing "remote out of service" on all lines. Passed > this on to the switch tech, and he did something (switch is a DMS-100) and > the lines went to "in service". The whole time my D-channel was up, > switch saw it up as well. > > Anyhow, looking at the line status in performance monitor in TCM may point > you in the right direction... > > Charles > > | Charles Sprickman | Internet Channel > | INCH System Administration Team | (212)243-5200 > | spork@inch.com | access@inch.com > > On Thu, 27 Sep 2001, Randy McMillan wrote: > > > We have several TC chassis with quad modems that we want to convert to PRI. > > One of chassis has a DSP (2.1.9) card that works fine with a PRI. They all > > have HyperArc with 5.0.99 software. > > > > The process I went through on a chassis was to load the current PRI software > > on the T1/PRI card, and set the trunk setting b8zs,esf, switch type 5ess, > > (although I believe they have a CTI switch). The other settings match > > (dnis,eandmtypeII, wink, etc) the CT1 settings. Then on the Quad modems I > > set the "Line Interface Source" from t1Tdm to priTdm. Save and reboot. > > > > When everything is connected, I have all green lights, and the switch guy > > sees the d channel come up. When we dial into that line, the switch guy > > sees the call come in on the first trunk but the modem doesn't answer. I > > don't see any lights flash on the modem card to indicate a call coming in. > > The default config on the PRI card is round robin allocation of modems as > > opposed to fixed assignment which I didn't change. The DSP card is using > > fixed assignment routing. > > > > If the switch guy converts it back to a CT1, and I load the CT1 software > > back in, and switch the line interface source on the quad cards, then it > > works fine. > > > > Can anyone tell me what I am missing, or point me in a direction to look? > > Thanks. > > > > Randy McMillan > > PacInfo > > > > > > - > > 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, Just went through the same thing... Spent some time trying to find my mistake, then started poking around the "performance monitor" both on the PRI level and timeslot level. I found that the modems were showing "remote out of service" on all lines. Passed this on to the switch tech, and he did something (switch is a DMS-100) and the lines went to "in service". The whole time my D-channel was up, switch saw it up as well. Anyhow, looking at the line status in performance monitor in TCM may point you in the right direction... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com On Thu, 27 Sep 2001, Randy McMillan wrote: > We have several TC chassis with quad modems that we want to convert to PRI. > One of chassis has a DSP (2.1.9) card that works fine with a PRI. They all > have HyperArc with 5.0.99 software. > > The process I went through on a chassis was to load the current PRI software > on the T1/PRI card, and set the trunk setting b8zs,esf, switch type 5ess, > (although I believe they have a CTI switch). The other settings match > (dnis,eandmtypeII, wink, etc) the CT1 settings. Then on the Quad modems I > set the "Line Interface Source" from t1Tdm to priTdm. Save and reboot. > > When everything is connected, I have all green lights, and the switch guy > sees the d channel come up. When we dial into that line, the switch guy > sees the call come in on the first trunk but the modem doesn't answer. I > don't see any lights flash on the modem card to indicate a call coming in. > The default config on the PRI card is round robin allocation of modems as > opposed to fixed assignment which I didn't change. The DSP card is using > fixed assignment routing. > > If the switch guy converts it back to a CT1, and I load the CT1 software > back in, and switch the line interface source on the quad cards, then it > works fine. > > Can anyone tell me what I am missing, or point me in a direction to look? > Thanks. > > Randy McMillan > PacInfo > > > - > 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. >

Cistron requires a reload to read flat users files (/etc/raddb/users). We start ours everyday at 7:00 AM just in case we didn't the day before when making changes. PS: How were the Patton boxes working with it? Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 ----- Original Message ----- Sent: Thursday, September 27, 2001 6:50 PM > It working now... there must be some sort of cache in the CISTRON > server.... tries the _auth cmd this morning and all of a sudden they > fail. > > -- > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Thu, 27 Sep 2001, Mark Thornton wrote: > > > Have you run the radius diagnostics on the HiperArc themselves and look at > > what the received packets are? If you do and want something to compare it to > > I could do the same on mine. Ours are authenticating against Vircom > > VopRadius and I know the disable function works because we use it to get > > payment from a small percentage of clients. It is amazing how fast they call > > after they are disabled. > > > > Mark Thornton > > San Marcos Internet, Inc > > 512-393-5300

I don't know... and the RADIUS server WAS restarted (verified in the logs). I wonder if a cache is on the TC's? I'm baffeled... the radius server had ALWAYS rejected the auth request... only the ARC's didn't. Go figure. -- Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 28 Sep 2001, Marshall Morgan wrote: > Cistron requires a reload to read flat users files (/etc/raddb/users). We > start ours everyday at 7:00 AM just in case we didn't the day before when > making changes. > > PS: How were the Patton boxes working with it? > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838 > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, September 27, 2001 6:50 PM > Subject: Re: (usr-tc) ARC not denying logins > > > > It working now... there must be some sort of cache in the CISTRON > > server.... tries the _auth cmd this morning and all of a sudden they > > fail. > > > > -- > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Thu, 27 Sep 2001, Mark Thornton wrote: > > > > > Have you run the radius diagnostics on the HiperArc themselves and look > at > > > what the received packets are? If you do and want something to compare > it to > > > I could do the same on mine. Ours are authenticating against Vircom > > > VopRadius and I know the disable function works because we use it to get > > > payment from a small percentage of clients. It is amazing how fast they > call > > > after they are disabled. > > > > > > Mark Thornton > > > San Marcos Internet, Inc > > > 512-393-5300 > > > > - > 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 testing OSPF on a HiPerARC running version 5.1.99 firmware over the past several weeks. It's been working ok except for one possible problem. The routing table suggests the HiPerARC is actually picking up its default route from the NMC rather than through OSPF: Destination Prot NextHop Metric Interface 0.0.0.0/0 NetMgr 64.65.64.2 1 eth:1 4.24.134.16/30 OSPF 64.65.64.66 20 eth:1 10.1.2.144/29 OSPF 64.65.64.4 20 eth:1 63.0.0.0/A OSPF 64.65.64.2 20 eth:1 64.65.64.0/22 LOCAL 64.65.64.2 1 eth:1 ... Is there some configuration setting needed to tell the HiPerARC to use the default route learned from OSPF rather than the NMC?

On Sun, 30 Sep 2001, Antonio Querubin wrote: > I've been testing OSPF on a HiPerARC running version 5.1.99 firmware over > the past several weeks. It's been working ok except for one possible > problem. The routing table suggests the HiPerARC is actually picking up > its default route from the NMC rather than through OSPF: > > Destination Prot NextHop Metric Interface > 0.0.0.0/0 NetMgr 64.65.64.2 1 eth:1 > 4.24.134.16/30 OSPF 64.65.64.66 20 eth:1 > 10.1.2.144/29 OSPF 64.65.64.4 20 eth:1 > 63.0.0.0/A OSPF 64.65.64.2 20 eth:1 > 64.65.64.0/22 LOCAL 64.65.64.2 1 eth:1 > ... > > Is there some configuration setting needed to tell the HiPerARC to use the > default route learned from OSPF rather than the NMC? Uh, disregard. It turns out the static defaultroute should be removed BEFORE enabling OSPF.