February 2000 - USR-TC - mailman.xmission.com

(usr-tc) Does 3Com Monitor List
by Ted Mecimore 04 Feb '00

04 Feb '00

I was wondering if any 3Com folks are lurking out there. With all the "adventure" dealing the DSP vs HCF battle I am wondering how they plan to respond. -- Ted Mecimore Operations Manager Vista Technology - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

13 22

(usr-tc) Netserver 3.7.24 and RIP
by Andy Dills 04 Feb '00

04 Feb '00

Hello, I'm trying to establish RIP routing between my USR TC with a Netserver running 3.7.24 and my cisco 3640 (so I can redistribute it OSPF and have the routes propogate throughout my network.) However, it doesn't seem to be working. I have very limited documentation, as I inherited the USR from an ISP we acquired. Does anybody have any suggestions as to settings to check, and/or ways to debug this? Thanks, Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Network Administrator Fax 301-695-4060 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

4 5

Re: long -- Re: (usr-tc) 3com not doing V.90 as well as Ascends
by John Mies 04 Feb '00

04 Feb '00

GMTA. Am buying a PM3 and hooking up another trunk just for these problems. At 09:26 AM 8/21/99 -0500, you wrote: >On Tue, 10 Aug 1999, Allen Marsalis wrote: > > > At 01:24 AM 8/10/99 -0400, Ed wrote: > > >3com not doing V.90 as well as Ascend's..... > > > > > >We have tested and found it to be true that Ascend's authenticate and work > > >at V.90 speeds much more often than 3com. It even happens when using a > > >3com/USR modem. It takes certain a certain situation for this to > happen but > > >it does happen... > > > > > >Just wondered if others out there have noticed it or had their competitors > > >using Ascend's have customers that say "Well I get 56K speeds on so and so > > >Internet Service, why not yours?" > > > > We have been 100% USR/3COM for 3 years and we recently received a Max > > TNT for eval to address the above problem.. Both chassis will be > > at the same NOC. 2 new PRI's for the TNT should be up this week.. > > I'll keep you posted as to the results and try to provide some statistical > > data.. > >Sorry for the length here, but I think it's a good read, eventhough I did >write it myself :) > >We did some churn analysis for customers that are no longer active or no >longer customers. We looked at at customers lost since March 1999 because >of: > >a) reported problems connecting, staying connected, or poor performance >b) unexplained non-payers/dead-beats >c) customers cancelled but did not give a reason (and did not > return our calls when we tried to followed up). > >We had 103 total cancellations for these reasons since March 1999. > >We had enough data to determine that 57% of these 103 had problems were >directly attributable to connection quality. Of these 59 (103*0.57) >customers lost: > > 50% of them had not established a connection in 1999 (many of > them reported this trouble) > > 40% had a large number of <1 minute connections, and showed a pattern > of having to redial when they did stay on longer than a few minutes > > 10% had connect speeds that varied more than a few "rungs" between > 2400-52000 > > >Let's see...If we had an alternate modem pool with a different NAS type, >we might have saved these 59 customers. That's about $1000/month at an >average revenue of $17/customer/month. We are still likely to continue >loosing more if we don't take action. > >Alternatively Scot Desort <scot(a)njaccess.net>, wrote: > > "When all else > fails, pull $35 out of petty cash and send the customer a Paradise > Winmodem (LT chipset, PCI), for free. These things are GREAT, will save > you hours of tech support headaches, and inevitably win you over a > customer that, in the long run, is worth a lot more than the $35 you > spent on the modem. We even offer to install it for free if they bring > the box in. Let's remember that the goal is to KEEP the customer a > PAYING customer. And nothing makes them more warm and fuzzy then getting > something for free." > >This is interesting. Upgrading these customer's modems would have cost us >$2065 in hardware and perhaps $400-500 in labor estimated to retain the >$1000/month in revenue if this actually fixed the problem. I can see >several problems though. You could get a considerable number of calls from >unhappy customers like "my friend got a free modem now he gets 52K but I >only get 42K or 28.8K. I want one too." The customer's computer needs to >be sufficiently powered to run with a winmodem. How much time is spent >explaining that only certain customers qualify and how exactly are those >qualifications set? This also doesn't account for telco line issues. Many >customers now can't even tell you what kind of modem they have or what >processor they have, others may guess or argue that their's _should_ >qualify for the free upgrade. For the program to not piss off any other >customers, it needs to be made available to everyone. Otherwise trouble >seems inevitable. > >On the other hand, although it takes some capital (not much with eq >leasing and zero install PRIs) and increases network complexity a little, >it's not that big of a deal for a reasonably clued provider to add another >NAS and move PRIs over to them in a separate hunt or just install a couple >new PRIs and gradually grow the alternate modem pool. But really doesn't >add much cost to the operation in the long run and the customers are >retained as well. Also: > >1) it's available to everyone, >2) it only takes a minute to help them change phone numbers >3) and in most cases, if this doesn't solve the problem, they're not > likely to be satisfied with anyone else and helps prove the problem > is theirs, motivating them to follow your recommedations. > >The main thing that tweaks me is having to take this action in the first >place. Not to mention that we've got 7 or 8 hdsps from quad trades and arc >upgrades and such that we are paying for but won't be using this year now, >depending on the demand for the alternate pool. Cost of doing business. > >Time to get a MAX on eval and give it a whirl. > >============================================================================ >Jeffrey A. Lynch | JORSM Internet, Regional Internet Services >email: jeff(a)jorsm.com | 7 Area Codes in Chicagoland and NW Indiana >Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN >Autoresponse: info(a)jorsm.com | Quality Service, Affordable Prices >http://www.jorsm.com | Serving Gov, Biz, Indivds Since 1995 > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the 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(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

Re: (usr-tc) Radius and VPN-Neighbor
by G. Douglas Davidson 03 Feb '00

03 Feb '00

On Feb 3, 12:28pm, Brian wrote: > Subject: Re: (usr-tc) Radius and VPN-Neighbor > > What attribute id are you using. I have used: > > VENDORATTR 429 USR-VPN-Neighbor 36872 ipaddr > > successfully. It has to be one hop away to work however. > I have tried both of these attribute formats: ATTRIBUTE USR-PW_VPN_Neighbor 0x9008 ipaddr ATTRIBUTE USR-PW_VPN_Neighbor 36872 ipaddr And neither seems to work. The interface for the X-Stop box I am trying to VPN to is on the same subnet and pings. I've got RIPV2 and RIPV1 receive off (as per instructions.) Is there any way that I can tell (without sniffing traffic) whether this attribute is making it to the TC? I'll try the traffic stuff, but it really looks like it is going out. Also, I turned off the RIPV1 and V2 receive but did not reboot. Not sure if that is necessary or not. Thanks! -- ----- G Douglas Davidson | CityNet, Inc. douglas(a)city-net.com | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) DSP console error msg
by Mike Andrews 03 Feb '00

03 Feb '00

This just started appearing on the console port of a 2.0.51 (hardware rev .55) DSP that I'm about to bring into service later today... should I be worried? :) (Ch.254): 05:04:21:102 Logic Error - Inv pSOS Msg Id error = 00001102 Task = CCT Line # 532 File cc.c Data = 33816631 Opt = 17 Actually it's popped up several times, with "Opt = " starting at 1 and incrementing by 2 each time. While writing this it got all the way to 23. Haven't seen anything since, though. This is set up for Channelized T1, and it's my first one (I'm used to PRI) so I'm not ruling out config problems yet. It just looked kinda weird. Mike Andrews (MA12) * mandrews(a)dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) Radius and VPN-Neighbor
by G. Douglas Davidson 03 Feb '00

03 Feb '00

I am having some difficulty getting VPN-Neighbor to work. My setup is as follows: HyperArc Version: 4.2.32 IEA Next Hop Routing: ENABLED IEA Send Unsolicited Proxy Arp: DISABLED IEA Force Next Hop Route: DISABLED IP proxy ARP for all dialin addresses: DISABLED IP RIP Flags: METRICS SEND_REQUEST I am using an altered version of Livingston's 2.1 Radius. On the Livingston side it _appears_ that the VPN-Neighbor attribute is being sent: Thu Feb 3 11:29:14 2000: [24758] sending accept to 198.144.34.36/1645.66 Thu Feb 3 11:29:14 2000: [24758] Service-Type = Framed-User Thu Feb 3 11:29:14 2000: [24758] Framed-Protocol = PPP Thu Feb 3 11:29:14 2000: [24758] USR-PW_VPN_Neighbor = 198.144.34.46 Thu Feb 3 11:29:14 2000: [24758] Framed-IP-Address = 255.255.255.254 Thu Feb 3 11:29:14 2000: [24758] Framed-MTU = 1500 Thu Feb 3 11:29:14 2000: [24758] message sent to 198.144.34.36/1645.66 code=2, length=50 But when I am doing a "mon radius" for the user on the USR box it only shows receipt of all of the attributes with the _exception_ of the VPN Neighbor attribute. Does "mon radius" show all attributes transmitted, or only those that are acted on or understood? I'd like to know if the VPN-Neighbor attribute is even being transmitted (although from the Radius stats, it looks like it is.) Thanks! -- ----- G Douglas Davidson | CityNet, Inc. douglas(a)city-net.com | Pittsburgh, PA voice: 412.481.5406 | fax: 412.431.1315 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the 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 1

(usr-tc) Good news or bad news? You decide...
by Jeff Mcadams 03 Feb '00

03 Feb '00

Well...this is either good news or bad news...I'll let each decide for themselves. :) Right before I left the office I got a call from a gentleman at 3Com trying to followup on our issues and see what could be done about them. This is the good news part...at least they're trying to do something. The bad news perspective of it though...he was from the technical support department. This means that his concerns, and areas where he would be able to help, would be if there were any outside issues with the actual equipment/software/whatever. While there are some outstanding issues...they're not of that magnitude IMO (v.90 compatibility, early disconnects...stuff like that), and, for the most part, they're being dealt with fairly well. The main issues that I have been dealing with, and I shared this with this gentleman were the issues of obtaining support *contracts*, not obtaining *support*. So, the bad news being...while 3Com is listening and trying to address issues...they don't seem to be doing a terribly good job of it...or at least they're not delegating the problem to the right people. The gentleman that I spoke to listened to what I had to say about the support contract issues, understood my position, then pretty much indicated that this was kinda outside his area of being able to do anything, but that if we had any outside trouble tickets or whatever that weren't being dealt, that he could indeed help there. Like I said...I didn't have anything earth shattering...I wish I would've mentioned the v.90 compatibility problems, but didn't, but by and large, this guy wasn't in a position to help out with the issues that we've been throwing email back and forth about today. He did mention that he would mention the substance of my issues to his boss...so there is still some hope that the right people will get notified of these things before its all over and done with. I do appreciate 3Com folks at least making an effort to get a response in motion...hopefully we can get the right people involved and really make some forward progress. :) My decision is that this is "qualified good news". It shows that things are at least moving...though we're still to see how efficiently. -- Jeff McAdams Email: jeffm(a)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(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

4 5

RE: (usr-tc) Good news or bad news? You decide...
by Stainforth, Matthew 03 Feb '00

03 Feb '00

After my last incident where we were negotiating a price for a service contract and, out of pure coincidence I had a Netserver die on me, she refused to tell me what the warranty period for this equipment was and wouldn't replace it without a service contract. I said I didn't care about next day replacement...I could wait the normal 14 day period for repair...but no. I call that rude. So I ended up raising a fuss and one of the 3Com Canada replaced the NIC on the sly for me. I strongly suggested at that time that Michelle Catalano should be fired but I guess my advice wasn't heeded. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Brian [mailto:signal@shreve.net] > Sent: Thursday, February 03, 2000 1:58 AM > To: usr-tc(a)lists.xmission.com > Subject: Re: (usr-tc) Good news or bad news? You decide... > > > > She shouldn't be rude to you. > > Between about 10 of us on this list, their is probably $10-$15M in > business with 3Com in the last 3-4 years alone. Losing one > client could > mean a million dollars or more to 3Com. They should not let her abuse > people. > > Brian > > > On Wed, 2 Feb 2000, Paul Farber wrote: > > > Well, this has been a pretty good discussion about a pretty > important > > issue. > > > > I like TC... I like what it has done for me. But the issue > remains... I'm > > out $1200, have no support contract, and Michelle on the > other end dosen't > > seem to give a rats ass that this support contract pays her > salary so she > > can be rude on the phone to me. > > > > > > > > Paul Farber > > Farber Technology > > farber(a)admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Wed, 2 Feb 2000, Jeff Mcadams wrote: > > > > > Well...this is either good news or bad news...I'll let > each decide for > > > themselves. :) > > > > > > Right before I left the office I got a call from a > gentleman at 3Com > > > trying to followup on our issues and see what could be > done about them. > > > This is the good news part...at least they're trying to > do something. > > > > > > The bad news perspective of it though...he was from the technical > > > support department. This means that his concerns, and > areas where he > > > would be able to help, would be if there were any outside > issues with > > > the actual equipment/software/whatever. While there are some > > > outstanding issues...they're not of that magnitude IMO (v.90 > > > compatibility, early disconnects...stuff like that), and, > for the most > > > part, they're being dealt with fairly well. > > > > > > The main issues that I have been dealing with, and I > shared this with > > > this gentleman were the issues of obtaining support > *contracts*, not > > > obtaining *support*. So, the bad news being...while 3Com > is listening > > > and trying to address issues...they don't seem to be > doing a terribly > > > good job of it...or at least they're not delegating the > problem to the > > > right people. > > > > > > The gentleman that I spoke to listened to what I had to > say about the > > > support contract issues, understood my position, then pretty much > > > indicated that this was kinda outside his area of being able to do > > > anything, but that if we had any outside trouble tickets > or whatever > > > that weren't being dealt, that he could indeed help there. Like I > > > said...I didn't have anything earth shattering...I wish I would've > > > mentioned the v.90 compatibility problems, but didn't, > but by and large, > > > this guy wasn't in a position to help out with the issues > that we've > > > been throwing email back and forth about today. He did > mention that he > > > would mention the substance of my issues to his boss...so > there is still > > > some hope that the right people will get notified of > these things before > > > its all over and done with. > > > > > > I do appreciate 3Com folks at least making an effort to > get a response > > > in motion...hopefully we can get the right people > involved and really > > > make some forward progress. :) > > > > > > My decision is that this is "qualified good news". It > shows that things > > > are at least moving...though we're still to see how efficiently. > > > -- > > > Jeff McAdams Email: jeffm(a)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(a)xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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(a)xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal(a)shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the 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(a)xmission.com" with "unsubscribe usr-tc" in the body of the 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 1

RE: (usr-tc) User problems completing session
by Blake Fithen 03 Feb '00

03 Feb '00

I believe one of the reasons this happens is when you do not have enough addresses in your defined pool. blake -----Original Message----- From: Cheryl Johnson [mailto:netadmin@seidata.com] Sent: Wednesday, February 02, 2000 3:09 PM To: usr-tc(a)lists.xmission.com Subject: (usr-tc) User problems completing session Anyone seen this before? Unexpected (IPCP) Layer Down, ID 1, Restarting Link 20963392, for <username>. It sounds like a modem issue on the user side. -Cheryl SEI Data Network Service, Inc A Division of SEI Communications - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the 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 1

(usr-tc) hiperarc radius settings
by Laszlo Vecsey 02 Feb '00

02 Feb '00

Whats the hiperarc command to set the primary and secondary radius servers? Also is there a way to set more than two? Perhaps if there was a way to specify a hostname (not just an IP) you could set up a round robin list of IP's to it.. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

3 2