September 1999

Subject: Re: (usr-tc) TC and Cistron
From: David Ernst <drernst@bloomington.in.us>
Date: 1999-08-31 13:46:27

Your /etc/services is listing ports 1645 & 1646 as "Datametrics". I don't know much about this but apparently datametrics had that port number reserved before RADIUS started using it. Meanwhile Radius is probably being listed as 1812/1813 (did you just upgrade to RedHat 6.0 by any chance?). See RFC 2138 for more information about the history. We fixed this problem just by editing our /etc/services file. Here are the key lines: radius 1645/tcp # datametrics / old radius entry radius 1645/udp # datametrics / old radius entry radacct 1646/tcp # sa-msg-port / old radacct entry radacct 1646/udp # sa-msg-port / old radacct entry #radius 1812/tcp # Radius #radius 1812/udp # Radius #radacct 1813/tcp # Radius Accounting #radacct 1813/udp # Radius Accounting This should bring you back up. I'm sure there's a way to tell the HiperArc to use the "real" radius ports, but I didn't know what that was, and I did know how to do this, and I needed to get it fixed FAST. So, although it thumbs its nose at the Internet Number Assigning Authorities, we did it anyway. David -- David Ernst HoosierNet, Inc. On Tue, 31 Aug 1999, Tavis Morse wrote: >Hello, >I'm trying to set up cistron radius to work with the HiperArc, >does anyone have this working? If so, I'm wondering what typical clients >and users file entries might look like. >I have been trying to get it working unsuccessfully for 2 days., >so far I can't even get the radius.log to show any activity at all with the >-y flag. TCPdump shows 'datametrics' packets coming in. >TIA >Tavis Morse >Norfolk County Internet > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC and Cistron
From: David Ernst <drernst@bloomington.in.us>
Date: 1999-08-31 13:46:27

Subject: Re: (usr-tc) TC and Cistron
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-01 11:57:15

On Tue, 31 Aug 1999, Tavis Morse wrote: > Hello, > I'm trying to set up cistron radius to work with the HiperArc, > does anyone have this working? If so, I'm wondering what typical clients > and users file entries might look like. Works great here. The clients file is easy enough -- hostname of your ARC's and NMC's in the left column, then the Radius shared secret in the right column, with a tab in between. The shared secret is case sensitive, so you might want to put it in quotes on the ARC -- not sure if that's necessary, but doesn't hurt to be sure. Our default users entry is: DEFAULT Auth-Type = System Port-Limit = 1, USR-Max-Channels = 1, USR-IP-SAA-Filter = 1, Session-Timeout = 43200, Idle-Timeout = 1800, Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-Compression = Van-Jacobson-TCP-IP, Framed-MTU = 1500, Filter-Id = "dialup" > I have been trying to get it working unsuccessfully for 2 days., > so far I can't even get the radius.log to show any activity at all with the > -y flag. TCPdump shows 'datametrics' packets coming in. try tcpdump -n so you get actual port numbers, or grep /etc/services and see what "datametrics" maps to... One thing that can trip you up is that some Radius servers (definitely Livingston, maybe Cistron too) look in /etc/services for "radius" and "radacct" to figure out what port to listen on. On FreeBSD at least, /etc/services shows ports 1812 and 1813. The ARC defaults to 1645 and 1646. You can either fix the ARC or fix /etc/services, but you'll have to fix one of them to make things work. We decided to fix /etc/services, but one of these days I may switch to the newer port numbers... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) SNMP OID to reset card
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-01 12:12:12

On Mon, 30 Aug 1999, Paul Farber wrote: > What OID can I send to reset a DSP? It's a set of OIDs, and then there's yet another OID you have to poll for the result code. (tcpdumping a TCM session makes more sense out of it) You should be able to Hardware reset any card with: 1.3.6.1.4.1.429.1.1.7.1.1.4.slotno = integer 4 1.3.6.1.4.1.429.1.1.7.1.1.6.slotno = string "00" then keep checking 1.3.6.1.4.1.429.1.1.7.1.1.7 til you get a 2, and ..1.1.7.1.1.8 until you get a 1. You'll get that when the command goes through, though, not when the card is done resetting... (I hope I don't have that backwards, I'm going off of some source code to a Perl script I never finished...) > Where can I get a good, up to date reference of the SNMP OID's for the > DSP's? ftp://totalservice.3com.com/pub/.docs/24100003.pdf ftp://totalservice.3com.com/pub/.docs/24166100.pdf > Is there a LINUX version of TCM yet? I remember a list post to mail a guy > at 3Com... and luck yet? No, but several people have gotten pretty big chunks of it re-implemented in Perl... > Has anyone got TCM to run under X w/Wine? That's a scary thought. :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: RE: (usr-tc) RE: IP Spoofing
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-01 12:40:45

HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED CLI - Request SET NETWORK USER failed because item is not in table Do I need some kind of default user to take advantage of this? SMT -----Original Message----- Sent: Tuesday, August 31, 1999 10:52 AM Cc: Totalcontrol It is wrong.. the command is "SET NET USER DEFAULT PPP_SOURCE_IP_FILTER_ENABLED" -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil |Sent: Monday, August 30, 1999 5:08 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) IP Spoofing | | | |I'm almost sure that's wrong. I think it's something like... | |set net user default ppp_source_ip_filter enable | |although there might be a global switch you can flip. The |radius attribute does not work. | | |Jamie Orzechowski writes... |>set nework user default spoofing enable/disable |> |>----- Original Message ----- |>From: Russ Miescke <russm@powerweb.net> |>To: <usr-tc@lists.xmission.com> |>Sent: Monday, August 30, 1999 5:02 PM |>Subject: (usr-tc) IP Spoofing |> |> |>> How do I keep people from spoofing an IP address on the TC hub. |>> I know there is an option, but can't find it for the life of me. |>> |>> Russ Miescke |>> Power Web Connect | |-- |Aaron Nabil | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) RE: IP Spoofing
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-01 12:55:58

set net user default ppp_source_ip_filter enabled ...you are correct sir, 'default' needs to be in lower case...! SMT -----Original Message----- Sent: Wednesday, September 01, 1999 12:46 PM Thus spake Scott Trautman >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED >CLI - Request SET NETWORK USER failed because item is not in table >Do I need some kind of default user to take advantage of this? I'm pretty sure usernames are case-sensitive...try default in lower-case. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperDSP T-1/E-1
From: Marty Elliott <marty@2assetrecovery.com>
Date: 1999-09-01 13:17:15

At 02:52 PM 09/01/1999 -0500, you wrote: >Are the T-1 and E-1 cards the same with different code, or do you have to >get different cards to go from T-1 to E-1? Thanks. > >Mike Wilker Mike -- don't get me going on this issue! Same cards -- basically. The E1 version has a daughter card (35-001914-0x) that plugs into the standard DSP NAC (p/n 69-001914-0x). It contains the extra six ports. 3Com refuses to sell them (the daughter cards) separately and insists you buy the card set (p/n 992267-00) for about $2000 more than the danged T1 version. Have been fighting over this for weeks with 3Com from Australia to Singapore to California to Illinois to Europe. Good luck. Marty ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marty Elliott MARS, Inc. 2105 South 48th Street Suite 104 Tempe, AZ 85282 602-426-8272 602-454-0770 fax www.2assetrecovery.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-01 13:36:45

Scott Trautman writes... >..and finally...anyone doing a lot with the ARC filters? Anyone interested >in making some bucks converting a couple Netserver filters to an ARC filter? Easy money, considering the ARC supports netserver syntax filters. -- Aaron Nabil

Subject: Re: (usr-tc) RE: IP Spoofing
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-01 13:45:30

Thus spake Scott Trautman >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED >CLI - Request SET NETWORK USER failed because item is not in table >Do I need some kind of default user to take advantage of this? I'm pretty sure usernames are case-sensitive...try default in lower-case. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) HARC Chassis sold
From: C Thompson <cthompson@wingnet.net>
Date: 1999-09-01 14:31:51

For all who were asking about the Hiper ARC chassis with DSP modems, we have sold it. Thanks. I received far more calls and e-mails than I anticipated and do not have the time to return all of them personally. Craig Thompson, Manager WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net

Subject: (usr-tc) Packet filtering strategies/netbus et al
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-01 14:35:56

Hi-- I'm reviewing my filtering strategies and wondering about the wisdom of putting filters a) on TC unit ethernets b) on individual dialin users c) border routers to combat netbus et al types of attacks. I've got a pretty good list of the ports typically used (yeah, I know, can use other ports too, but could cut down by 95%). Assumptions/questions: -our own users most likely will not attack each other (? assumption) support b,c approach -load/user performance on ARC or Netserver get to be an issue with too much filtering? -how big a problem is it anyway? -how big a filter is too big? I've got about 30 lines in one already, could easily double+ that. Limits on Netserver filters? ARC's? We use Cisco 3640's on our borders, 2501's in smaller pops, TC units for dialup & a couple PM3's for ISDN. Sure wish the netserver filters had a 'log' item on 'em. Really makes debugging a lot easier...as well as more than less proactively tracking down filter problems/attacks w/syslog entries to show.... I'm currently using some pretty modest filtering already. ..and finally...anyone doing a lot with the ARC filters? Anyone interested in making some bucks converting a couple Netserver filters to an ARC filter? Easy way to do it? Trying to get a set of filters I'm happy with then port them to the ARC's. The new format, albeit "improved" and I'm sure more "flexible" is giving me dread... SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

Subject: (usr-tc) HiperDSP T-1/E-1
From: Mike Wilker <mikew@ll.net>
Date: 1999-09-01 14:52:14

Are the T-1 and E-1 cards the same with different code, or do you have to get different cards to go from T-1 to E-1? Thanks. Mike Wilker Operations Manager Local Link, Inc.

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1999-09-01 15:21:19

On Wed, 1 Sep 1999, Mike Andrews wrote: > The ARC has a "log" on it -- sort of. You can have it log a specified > number of bytes of each packet trapped to syslog. What id like to see is some filter rule 'if xyz then dump connection'. Would be a real deterrence to script kiddies if they get disconnected every time they try to backorifice or smurf someone. -Dan

Subject: (usr-tc) Quad Modem problem (Need help!) :)
From: Eric J Merkel <merkel@defnet.com>
Date: 1999-09-01 16:18:12

We had a major fiber cut here locally today and it knocked out several of our T1's, one of which is coming into our TCH into a bank of 6 Quad 4 modems. When the T1 was finally restored to those modems, serveral of them would not takes calls. FWIW we have another 6 quads and 2 hiper dsp's on 3 other T1's in this box that are working ok so it seems to be limited to the first T1 only. They (ports 7,8,9,10,11,12,21,22,23,24) would do one of the following: 1) call and get click, orange light, carrier, light goes dark, click carrier, orange light, disconnect 2) call and get dead silence but orange light comes on I've tried the following to bring these modems back to working condition: 1) Hard and soft reset of the DS0 for those modems 2) Reset the entire T1 coming into those channels 3) Did a hard and soft hardware reset on the quad cards themselves 4) Hard and soft busy and restore on those DS0's 5) Pulled the darn quad cards and reset them 6) Yank the T1 cable out and reset it None of these worked, so I have all of these modems soft busied out until I can think of something else to try. This T1 has been in operation a couple of years but occasionally if it goes down, it starts doing funky things like this. Somehow last time it happened it automagically fixed itself. Unfortunately, it does not look like that is going to happen at this point. Any ideas would be much appreciated. :) Eric Eric Merkel / MetaLink Technologies, Inc ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Email: merkel@metalink.net Phone: 419-782-3472 X304 ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-01 17:38:42

But from previous list discussions the filters were prone to not working. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 1 Sep 1999, Aaron Nabil wrote: > Scott Trautman writes... > >..and finally...anyone doing a lot with the ARC filters? Anyone interested > >in making some bucks converting a couple Netserver filters to an ARC filter? > > Easy money, considering the ARC supports netserver syntax filters. > > > -- > Aaron Nabil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-01 17:51:14

Mike Andrews writes... >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless >the user has a subnet routed to them. We don't use the global switch on >the ARC; we'd rather do it in Radius so it can be turned off on a per-user >basis. This works for you? It doesn't on my V4.2.29 - 1. -- Aaron Nabil

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-01 18:15:01

On Wed, 1 Sep 1999, Scott Trautman wrote: > I'm reviewing my filtering strategies and wondering about the wisdom of > putting filters a) on TC unit ethernets b) on individual dialin users c) > border routers to combat netbus et al types of attacks. I've got a pretty > good list of the ports typically used (yeah, I know, can use other ports > too, but could cut down by 95%). > Assumptions/questions: > -our own users most likely will not attack each other (? assumption) support > b,c approach Depends on how big you are. If you're small like us and only have 2000 customers, this is a mostly-reasonable assumption. If you're AOL or Mindspring or even ExecPC-sized, this is a really bad assumption. :) > -load/user performance on ARC or Netserver get to be an issue with too much > filtering? Hasn't been, but most of our filters are on our border. Filter syntax on the ARC is very difficult for me to grasp -- whether it's counterintuitive, whether I'm stupid, or whether I'm just too used to Cisco, I don't know yet. ;) And as Paul Farber just pointed out, filters were completely broken in some older ARC releases... So my approach is to use the border Cisco to filter things that I want to apply to absolutely everybody... but where there are cases where I may want to toggle them on/off on a per-user basis, use ARC filters. > -how big a problem is it anyway? Depends on how many script kiddies ya got. Usually you know about them really fast because of the questions they ask, or the filters they trigger. For us, it depends more on how many outside script kiddies our own users manage to piss off, which is usually directly proportional to the number of them that use IRC... :) > We use Cisco 3640's on our borders, 2501's in smaller pops, TC units for > dialup & a couple PM3's for ISDN. Sure wish the netserver filters had a > 'log' item on 'em. Really makes debugging a lot easier...as well as more > than less proactively tracking down filter problems/attacks w/syslog entries > to show.... The ARC has a "log" on it -- sort of. You can have it log a specified number of bytes of each packet trapped to syslog. Unfortunately, it does exactly that and nothing more -- dumps the *raw* packet, in hex. It's up to you to parse the packet manually to figure out if it's a TCP/IP packet or not, and then get the source/destination address, protocol, and port numbers or which ICMP message it is. Ugh... Anyway. What I'm doing on the ARC: - Filter TCP port 139 going to and from the user, because of both Winnuke and because of customers doing stupid things with file sharing. - Filter TCP port 25 going to anywhere except our own mail server for customers less than a month old. The idea is to thwart hit-and-run spammers that sign up with a fake address, abuse some offsite open SMTP relay, and never call back when you cancel them. This happened to us twice recently. Twice too many. - In Radius, provide a knob to disable either of these for the few people that legitimately need it -- we just put these people in a particular Unix group and have an alternate default entry pick 'em up. (You'd be surprised how many NT servers at State Government offices are open for file sharing across the Internet...) - In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless the user has a subnet routed to them. We don't use the global switch on the ARC; we'd rather do it in Radius so it can be turned off on a per-user basis. That's all we do on the ARC. The filters are well under 10 lines... so no major CPU impact... and if they cause problems for particular people, we just add 'em to a Unix group and they go away. On our border Cisco 3620, we are a little more facist... :) - Block spoofed and RFC1918 addresses. (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16... and also 127.0.0.0/8) Should be obvious. - "no ip directed-broadcast" on every interface, to prevent smurf amping. "no ip redirects" on the serial interfaces to the Internet. - Block telnet to our ARCs because of the DoS attack mentioned a few weeks ago, at least until a fix is available from 3Com... - Block UDP port 31337 -- first version of Back Orifice. Don't know what BO2K defaults to, if anything. - Block TCP ports 12345, 12346, 20034 -- netbus - Block internal services like SNMP, RIPv2 (hm, I can remove that now that we're all OSPF), Sun RPC, nfs, tftp, MySQL, lpr, Radius, and other oddities like port 0 that occasionally get used by script kiddie attacks... Some of these are only blocked to/from the subnet with our servers, and are open to dialups (just in case someone really does have to use SNMP on a remote system, for example). Some of them are blocked for everyone. (I'm open to suggestions on additions/removals here, by the way. It just now occured to me that echo and chargen might be good candidates to block...) - Log, but do not block, outgoing SMTP connections (syn packets only) from our dialup IP pools. We don't get a lot of hits on too many of these... aside from the occasional port scan and the scan of whole subnets for old Back Orifice setups... and we've got enough CPU left over on the 3620 to handle it. (It's only taking two full BGP views) But surprisingly, the *SMTP* logging actually helped me catch a Netbus install or two that I otherwise wouldn't have noticed. Newer versions can have the infected machine email a message to the attacker saying "hi, I'm awake now, my IP address today is <x.x.x.x>" when the infected machine dials in. When I first put the SMTP logging in, I found one long-time customer was trying to send a ridiculous amount of email to a *.k12.ca.us address. When I ran tcpdump on 'em, the word "netbus" popped up in it a lot. We emailed a pointer to McAfee's web site to the user, and the SMTP attempts stopped a day or two later. Non-3Com-but-somewhat-related-question: Has anyone tried rate limiting ICMP on a Cisco? What's the best way (read: minimal CPU impact) to do it on IOS 11.3? I was considering doing something like generic traffic shaping down to 256K, on an access list that matched all ICMP -- or at least ICMP echo request/reply. (Probably wouldn't shape the one that makes MTU path discovery work. :) The idea would be to reduce -- slightly -- the effect of a smurf attack. It'd still saturate our border router (unless our backbone providers did the same), but at least it wouldn't melt down the customer's router (or modem) as well, and they'd at least be able to use our own network during the attack. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-01 19:05:47

Thus spake Mike Andrews >Depends on how big you are. If you're small like us and only have 2000 >customers, this is a mostly-reasonable assumption. If you're AOL or >Mindspring or even ExecPC-sized, this is a really bad assumption. :) Perhaps, if you don't want to get into putting filters on your Arcs, and are more comfortable with ciscos, you can put the filters at the next hop cisco rather than on the arc directly. Doesn't get the filter quite to the edge, but limits the damage a script kiddie can do within your network. We don't do this, but I probably could. :) >Filter syntax on the ARC is very difficult for me to grasp -- whether it's >counterintuitive, whether I'm stupid, or whether I'm just too used to >Cisco, I don't know yet. ;) Maybe all three? ;) No...there are some aspects of the Arc's filtering language that is a bit on the bizarre side. Putting multiple qualifications for the same check on multiple filter rules is a bit counter-intuitive for me. >For us, it depends more on how many outside script kiddies our own >users manage to piss off, which is usually directly proportional to the >number of them that use IRC... :) Preach it brother. >(You'd be surprised how many NT servers at State Government offices are >open for file sharing across the Internet...) Oh, lovely...I already was whelmed by our state gov. Mostly from popping up at the top of netscan.org when that first came out. You're not inspiring much confidence here. :) >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless >the user has a subnet routed to them. We don't use the global switch on >the ARC; we'd rather do it in Radius so it can be turned off on a per-user >basis. How well does the global switch work? Does it account for network blocks being routed to the customer? How does the mechanism actually work internally? I'm curious as I'm considering using this, but am a little unsure of it at the moment. >On our border Cisco 3620, we are a little more facist... :) >- Block telnet to our ARCs because of the DoS attack mentioned a few weeks >ago, at least until a fix is available from 3Com... We've talked about this before...but turning on the telnet access limitations on the Arc's works like a charm and is safer. >(I'm open to suggestions on additions/removals here, by the way. It just >now occured to me that echo and chargen might be good candidates to >block...) We tend to not block anything going to customers. We're kinda of the thought that they're wanting Internet Access...they get it...warts and all. :) Obviously, if they're getting a flood type of DoS we'll put filters on our side and stuff...but typically their gonna get a lecture about IRC in the process. :) >(It's only taking two full BGP views) BGP isn't very CPU intensive except when its initially syncing up...it *is* memory intensive, but it doesn't hit the CPU very hard (a *whole* lot less than RIP does) >Non-3Com-but-somewhat-related-question: >Has anyone tried rate limiting ICMP on a Cisco? What's the best way >(read: minimal CPU impact) to do it on IOS 11.3? >I was considering doing something like generic traffic shaping down to >256K, on an access list that matched all ICMP -- or at least ICMP echo >request/reply. I wouldn't traffic shape that, but would rate-limit it instead (the difference being traffic-shaping buffers...rate limiting drops) >(Probably wouldn't shape the one that makes MTU path discovery work. :) Host Unreachable: fragmentation needed, but DF (do not fragment) set >The idea would be to reduce -- slightly -- the effect of a smurf attack. >It'd still saturate our border router (unless our backbone providers did >the same), but at least it wouldn't melt down the customer's router (or >modem) as well, and they'd at least be able to use our own network during >the attack. Possibly you're looking for something like priority queueing as well? Let whatever get through, but push the ICMP stuff down to lower priority so web/email/whatever traffic gets through in preference to the ICMP crap. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-01 19:17:07

On Wed, 1 Sep 1999, Dan Hollis wrote: > On Wed, 1 Sep 1999, Mike Andrews wrote: > > The ARC has a "log" on it -- sort of. You can have it log a specified > > number of bytes of each packet trapped to syslog. > > What id like to see is some filter rule 'if xyz then dump connection'. > > Would be a real deterrence to script kiddies if they get disconnected > every time they try to backorifice or smurf someone. hahaha... that would be kinda funny, though false positives would really suck. :) (And of course you can't be sure they're not going to change the port number, and you can't filter on the packet contents...) but it is actually possible though -- just have a script "tail -f" the syslog output, or set up an entry in syslog.conf that sends the output to "|scriptname"... have the program fork off a telnet session to the ARC to "disconnect user blah" when it sees a denied packet come into the log. I've got something similar already that watches for PPP/POP3/FTP logins and logouts, both successful and failed, and throws it into a MySQL database, so we can quickly find out (for example) who's never even tried to read their email. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: (usr-tc) DSP card needed
From: Greg owens <gowens@magnolia-net.com>
Date: 1999-09-01 19:57:53

This is a multi-part message in MIME format. ------=_NextPart_000_0035_01BEF4B4.472EE9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If anyone has a used (or new if the price is right) DSP card they would = like to sell. I would surely love to buy! Need both nic & nac and card = be guarenteed to work. You may email privately if you like. Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 gowens@magnolia-net.com=20 ------=_NextPart_000_0035_01BEF4B4.472EE9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>If anyone has a used (or new if the = price is right)=20 DSP card they would like to sell. I would surely love to buy! Need both = nic=20 &  nac and card be guarenteed to work. You may email privately = if you=20 like. Thanks</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </FONT></DIV> <DIV><FONT face=3DArial size=3D2><A=20 href=3D"mailto:gowens@magnolia-net.com">gowens@magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_0035_01BEF4B4.472EE9A0--

Subject: (usr-tc) strange DS0 states
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-02 09:21:50

Does anyone have any idea why this is happening? It's got me baffled... 01 Idle N/A REMOTE OOS 0x00000000 NONE 0x00000000 02 Conn In 002 REMOTE OOS 0x004E0100 NONE 0x000091EB 03 Conn In 003 REMOTE OOS 0x00400200 NONE 0x00009958 04 Conn In 004 REMOTE OOS 0x00270300 NONE 0x000081CC 05 Conn In 005 REMOTE OOS 0x00310400 NONE 0x000095E7 06 Conn In 006 IS 0x00400500 NONE 0x00009860 07 Conn In 007 REMOTE OOS 0x00240600 NONE 0x00009184 08 Conn In 008 REMOTE OOS 0x004D0700 NONE 0x000084F8 09 Conn In 009 REMOTE OOS 0x00500800 NONE 0x00008D34 10 Conn In 010 REMOTE OOS 0x003F0900 NONE 0x00008955 11 Conn In 011 IS 0x00490A00 NONE 0x00008677 12 Conn In 012 IS 0x00270B00 NONE 0x000096A9 13 Conn In 013 REMOTE OOS 0x00280C00 NONE 0x00008BEF 14 Conn In 014 IS 0x00140D00 NONE 0x00009A27 15 Conn In 015 IS 0x00650E00 NONE 0x00009CF5 16 Conn In 016 IS 0x001F0F00 NONE 0x000086E9 17 Conn In 017 IS 0x00481000 NONE 0x00009A28 18 Conn In 018 REMOTE OOS 0x006B1100 NONE 0x000095E2 19 Conn In 019 IS 0x00351200 NONE 0x00008D41 20 Conn In 020 IS 0x00391300 NONE 0x000098F2 21 Conn In 021 REMOTE OOS 0x003A1400 NONE 0x00009F40 22 Conn In 022 IS 0x002C1500 NONE 0x00008E30 23 Conn In 023 IS 0x00391600 NONE 0x00009AA6 24 Dchan N/A IS 0x00000000 NONE 0x00000000 The trunk members are up and taking calls but some of them are showing out of service. All members appear to be in service as far as the switch guys are concerned looking at it from the DMS100 side. Any ideas?

Subject: RE: (usr-tc) RE: IP Spoofing
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-02 09:36:37

Subject: Re: (usr-tc) RE: IP Spoofing
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-02 09:45:09

What is the command to show all the settings for the default net user? JJ Scott Trautman wrote: > > set net user default ppp_source_ip_filter enabled > > ...you are correct sir, 'default' needs to be in lower case...! > > SMT > > -----Original Message----- > From: Jeff Mcadams [mailto:jeffm@iglou.com] > Sent: Wednesday, September 01, 1999 12:46 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) RE: IP Spoofing > > Thus spake Scott Trautman > >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED > >CLI - Request SET NETWORK USER failed because item is not in table > > >Do I need some kind of default user to take advantage of this? > > I'm pretty sure usernames are case-sensitive...try default in > lower-case. > -- > 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.

Subject: (usr-tc) Couple of Questions
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-09-02 10:09:42

I have two questions that maybe you can help with. 1. I had a 386 NMC that was x2 enabled that I took out of service due to getting some hiperdsp's installed. This was several weeks ago. I had to build a temporary chassis in a hurry yesterday and used the nmc card with 12 quads. It now shows that x2 is not enabled. I know its the right card but I may have swapped the flash and/or ram with another card during the upgrade. Does the key reside in the flash, the ram or somewhere else on the card? Could we lose the key because the card was not in use for several weeks? 2. All of the quads used to take calls in order. Now it is showing calls in the middle of the group or more or less on a random or rotating basis. Is there a setting to get them back where the first call goes to the 1st modem, etc?

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-02 10:46:19

On Wed, 1 Sep 1999, Aaron Nabil wrote: > Mike Andrews writes... > >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless > >the user has a subnet routed to them. We don't use the global switch on > >the ARC; we'd rather do it in Radius so it can be turned off on a per-user > >basis. > > This works for you? It doesn't on my V4.2.29 - 1. It does appear to work here, on 4.2.29. (At least syslog is recording the denied packets.) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: RE: (usr-tc) RE: IP Spoofing
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-02 10:49:01

"show user default" should list all the settings for the default user and default net user. On Thursday, September 02, 1999 10:45 AM, Jim Johnson [SMTP:jim@perigee.net] wrote: > > What is the command to show all the settings for the default net user? > > JJ > > Scott Trautman wrote: > > > > set net user default ppp_source_ip_filter enabled > > > > ...you are correct sir, 'default' needs to be in lower case...! > > > > SMT > > > > -----Original Message----- > > From: Jeff Mcadams [mailto:jeffm@iglou.com] > > Sent: Wednesday, September 01, 1999 12:46 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) RE: IP Spoofing > > > > Thus spake Scott Trautman > > >HiPer>> SET NET USER DEFAULT PPP_SOURCE_IP_FILTER ENABLED > > >CLI - Request SET NETWORK USER failed because item is not in table > > > > >Do I need some kind of default user to take advantage of this? > > > > I'm pretty sure usernames are case-sensitive...try default in > > lower-case. > > -- > > 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.

Subject: Re: (usr-tc) TCM under X/Wine
From: Grzegorz Paszka <grzegorz.paszka@pik-net.pl>
Date: 1999-09-02 11:01:28

On Mon, Aug 30, 1999 at 01:54:30PM -0400, Paul Farber wrote: > Do you have a link to Vmware??? http://www.vmware.com -- Grzegorz Paszka, System Administrator, Gliwice ul. Toszecka 102 e-mail: Grzegorz.Paszka@pik-net.pl tel. 48-32-2799600 wew 333

Subject: (usr-tc) Re: info on aggregating ISDN lines
From: Luke Parrish <lparrish@inet-resources.com>
Date: 1999-09-02 12:08:46

They won't have to have 2 logins, just assign them one RADIUS profile with their max channels set to 4. This way their router can request 4 channels and the access server will allow the customer to bond 4 channels. I have done this several times using an Ascend MAX200. At 12:17 PM 9/2/99 -0500, C Thompson wrote: >We have a customer who wants to aggregate 2 or more ISDN lines for one >large bandwidth channel. How can they do this with a standard dialup? > >I know that I can give them, say, two login names, have them login as >login1 and login2 which can both be set for a 128K login and make it the >responsibility of the equipment to provide the aggregation of 256K total, >but I wanted to check with you guys and see if this is the only way, the >best way, etc. Any equipment you know of or recommend to do this? > >Please reply asap, as we are working on a project with a due date coming >up very soon. > > > >Craig Thompson, Manager >WingNET Internet Services, >P.O. Box 3000 // Cleveland, TN 37320-3000 >423-559-LINK (v) 423-559-5444 (f) >http://www.wingnet.net >- >Send 'unsubscribe' in the body to 'list-request@inet-access.net' to leave. >Eat sushi frequently. inet@inet-access.net is the human contact address. Luke Parrish Internetworking Resources Independent Internet Consultant lparrish@inet-resources.com cell 318.348.7906 fax 815.377.5239 pager 1.800.443.7243 pin# 080765 http://www.inet-resources.com/

Subject: (usr-tc) info on aggregating ISDN lines
From: C Thompson <cthompson@wingnet.net>
Date: 1999-09-02 12:17:09

We have a customer who wants to aggregate 2 or more ISDN lines for one large bandwidth channel. How can they do this with a standard dialup? I know that I can give them, say, two login names, have them login as login1 and login2 which can both be set for a 128K login and make it the responsibility of the equipment to provide the aggregation of 256K total, but I wanted to check with you guys and see if this is the only way, the best way, etc. Any equipment you know of or recommend to do this? Please reply asap, as we are working on a project with a due date coming up very soon. Craig Thompson, Manager WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net

Subject: Re: (usr-tc) info on aggregating ISDN lines
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-02 12:30:54

Thus spake C Thompson >We have a customer who wants to aggregate 2 or more ISDN lines for one >large bandwidth channel. How can they do this with a standard dialup? >I know that I can give them, say, two login names, have them login as >login1 and login2 which can both be set for a 128K login and make it the >responsibility of the equipment to provide the aggregation of 256K total, >but I wanted to check with you guys and see if this is the only way, the >best way, etc. Any equipment you know of or recommend to do this? >Please reply asap, as we are working on a project with a due date coming >up very soon. Uhm...you can multi-link as many channels together as you want with MP. Why not just set his Port-Limit or Max-Channels or whatever it is to 4. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Couple of Questions
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-02 13:24:21

1. My impression is that it's stored on the NMC's NVRAM/EEPROM, not the flash. I could be wrong though. 2. Your dual pri card is probably set to do round-robin modem assignment. If you want your modems used in order and the telco has not set the LTC to round-robin the calls on the trunk group, you can set it to fixed assignment. Otherwise you can set it to route to the first available modem. On Thursday, September 02, 1999 1:10 PM, Greg Coffey [SMTP:gcoffey@vcn.com] wrote: > I have two questions that maybe you can help with. > > 1. I had a 386 NMC that was x2 enabled that I took out of service due to > getting some hiperdsp's installed. This was several weeks ago. I had to > build a temporary chassis in a hurry yesterday and used the nmc card with > 12 quads. It now shows that x2 is not enabled. I know its the right card > but I may have swapped the flash and/or ram with another card during the > upgrade. Does the key reside in the flash, the ram or somewhere else on > the card? Could we lose the key because the card was not in use for > several weeks? > > 2. All of the quads used to take calls in order. Now it is showing calls > in the middle of the group or more or less on a random or rotating > basis. Is there a setting to get them back where the first call goes to > the 1st modem, etc? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Errors on PRI line
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-02 15:18:09

I'm getting some errors on a PRI line which I reported to the telco. They've been scoping it for a few hours now and don't see anything but I'm still getting these errors: span1> disp near total Span1 Near Total Line Index is: 0 Span1 Near Total Errored Seconds is: 25 Span1 Near Total Severely Errored Seconds is: 0 Span1 Near Total Severely Errored Framing Seconds is: 0 Span1 Near Total Unavailable or Failed Seconds is: 0 Span1 Near Total Controlled Slip Seconds is: 0 Span1 Near Total Path Coding Violations is: 301 Span1 Near Total Line Errored Seconds is: 0 Span1 Near Total Bursty Errored Seconds is: 18 Span1 Near Total Degraded Minutes is: 0 Span1 Near Total Line Code Violations is: 0 Does anyone have any idea what might be causing these? And why wouldn't the telco be able to pick these up from a scope?

Subject: Re: (usr-tc) Telepath Modem Woes
From: matthew de Jongh <matthew.de.jongh@the-spa.com>
Date: 1999-09-02 16:13:35

we have had consistent problems with telepath modems for years. i'm sure about specific models but there is definitely a problem. a customer gave us one and we couldn't make it connect no matter what we did. matthew At 04:19 PM 8/23/99 -0500, you wrote: > >I have been getting reports from techs saying that Telepath modems (model >6000905) are having problems connecting to our USR TC chassis. I believe >Gateway packages this modem with their pc's. > >Has anyone else seen problems with this modem? fix? > > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-02 16:19:12

Mike Andrews writes... >On Wed, 1 Sep 1999, Aaron Nabil wrote: > >> Mike Andrews writes... >> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless >> >the user has a subnet routed to them. We don't use the global switch on >> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user >> >basis. >> >> This works for you? It doesn't on my V4.2.29 - 1. > >It does appear to work here, on 4.2.29. I get this... Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870 in my syslog, I didn't think to check if it was actually filtering packets (I'm guessing not). Is it 0x9870 that you are using? >(At least syslog is recording the denied packets.) Yeah, any way to turn that off that you've found? It ignores the Log-Filter-Packet attribute for SAA filtering. I had one user with a broken wingate-ish program that ended up sysloging almost every other packet, ouch. -- Aaron Nabil

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-02 19:02:29

On Wed, 1 Sep 1999, Jeff Mcadams wrote: > Perhaps, if you don't want to get into putting filters on your Arcs, and > are more comfortable with ciscos, you can put the filters at the next > hop cisco rather than on the arc directly. Doesn't get the filter quite > to the edge, but limits the damage a script kiddie can do within your > network. We don't do this, but I probably could. :) For most of our ARCs (Frankfort), the next hop Cisco *is* the border. I know, probably not a great network design, and I could fix it nowadays, but it's one of those evolved vs designed things... > >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless > >the user has a subnet routed to them. We don't use the global switch on > >the ARC; we'd rather do it in Radius so it can be turned off on a per-user > >basis. > > How well does the global switch work? Does it account for network > blocks being routed to the customer? How does the mechanism actually > work internally? I'm curious as I'm considering using this, but am a > little unsure of it at the moment. Don't know because I never tried the global switch, because I didn't know if it could be turned off with Radius. I knew it could be turned on with Radius, so I just did that. It's been said here that it does NOT account for customers with subnets routed to them -- which is why I wanted to be able to turn it off in Radius. But for your average joe dialup guy, it seems to work fine. > >(I'm open to suggestions on additions/removals here, by the way. It just > >now occured to me that echo and chargen might be good candidates to > >block...) > > We tend to not block anything going to customers. We're kinda of the > thought that they're wanting Internet Access...they get it...warts and > all. :) Obviously, if they're getting a flood type of DoS we'll put > filters on our side and stuff...but typically their gonna get a lecture > about IRC in the process. :) Yeah, and that's one thing I try to keep in mind before adding any more filters -- too easy to screw up legitimate use. (Especially with the port 139 one... there are some mp3 leeching programs that use that to make the file transfers harder to track.) But for some of the DoS-prevention ones, I'd rather spend time on the phone explaining filters than time on the phone explaining how to remove Back Orifice from their PC. :) (Been there, done that, wasn't fun) You can get into the same religious argument with spam, and liability for attacks/spam/whatever that do get through (if you don't filter, you're not liable; if you do, you might be) and all the other fun policy crap I got to learn by working at an .edu site for 3 years... :) But we won't get into that here... The trick is to try to find a balance between convenience and security. You always end up having to compromise something on both sides. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) Problems with Connect Speeds going down
From: Ed <ed@taylors.com>
Date: 1999-09-02 21:41:22

Have any of you tried using Ascends to see if it happens with them? I know there is an issue with crossing switches that 3com has and are currently working on. We cross between Bell Atlantic and Ameritech and have this issue. For some reason it seems to not affect the Ascends as much... Ed ----- Original Message ----- Sent: Friday, September 03, 1999 6:56 PM As it happens, GTE in my area has just one switch GTD 5 I believe and it covers all the customers in my area of service. They just recently upgraded the switch to handle more PRI's which is what we use as they were out of capacity to fill PRI orders. Of course if it is because of the recent upgrade to their switch I will have a heck of a time getting them to believe it is something that started when they upgraded and that it has to be related. > I have a bunch of customers who were served from a Bell Atlantic central > office equipped with a Lucent 1A switch. A week ago, BA upgraded the switch > to a 5ESS. Connect speeds from half of the people served by that switch > dropped from 47-50K to below 40. > > GTE would have had to replace a bunch of switches on the user side all at > once for it to have such a sweeping effect as you have described. > > Also, ask them about their tandems. Buggers, they are. May be a whole > geographical section of your customers served by a single tandem switch that > is on the fritz. There are 2 that serve our area, and one of them is ALWAYS > having problems. > > > ...Scot > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-02 22:56:26

Mike Andrews writes... >On Thu, 2 Sep 1999, Aaron Nabil wrote: > >> Mike Andrews writes... >> >On Wed, 1 Sep 1999, Aaron Nabil wrote: >> > >> >> Mike Andrews writes... >> >> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless >> >> >the user has a subnet routed to them. We don't use the global switch on >> >> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user >> >> >basis. >> >> >> >> This works for you? It doesn't on my V4.2.29 - 1. >> > >> >It does appear to work here, on 4.2.29. >> >> I get this... >> >> Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level >> "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870 >> >> in my syslog, I didn't think to check if it was actually filtering >> packets (I'm guessing not). Is it 0x9870 that you are using? > >Yup. Don't suppose you've got 9870 instead of 0x9870? You'd think the >ARC would put the leading 0x on it... VENDORATTR 429 USR-IP-SAA-FILTER 39024 integer VALUE USR-IP-SAA-FILTER USR-IP-SAA-FILTER-No 0 VALUE USR-IP-SAA-FILTER USR-IP-SAA-FILTER-Yes 1 Look like what you've got? (Radiator uses decimal). -- Aaron Nabil

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-03 00:25:30

On Thu, 2 Sep 1999, Aaron Nabil wrote: > Mike Andrews writes... > >On Wed, 1 Sep 1999, Aaron Nabil wrote: > > > >> Mike Andrews writes... > >> >- In Radius, use the USR-IP-SAA-Filter VSA to prevent IP spoofing, unless > >> >the user has a subnet routed to them. We don't use the global switch on > >> >the ARC; we'd rather do it in Radius so it can be turned off on a per-user > >> >basis. > >> > >> This works for you? It doesn't on my V4.2.29 - 1. > > > >It does appear to work here, on 4.2.29. > > I get this... > > Jul 4 10:35:57 us8a At 17:35:56, Facility "User Manager", Level > "UNUSUAL":: AUTH: Unknown attribute passed back from RADIUS Server: 9870 > > in my syslog, I didn't think to check if it was actually filtering > packets (I'm guessing not). Is it 0x9870 that you are using? Yup. Don't suppose you've got 9870 instead of 0x9870? You'd think the ARC would put the leading 0x on it... > >(At least syslog is recording the denied packets.) > > Yeah, any way to turn that off that you've found? It ignores the > Log-Filter-Packet attribute for SAA filtering. I had one user with > a broken wingate-ish program that ended up sysloging almost every > other packet, ouch. Haven't tried. But we syslog every damn thing at debug level anyway -- disk is cheap. (28 gig IDE for $250 now -- it's a shame I hate IDE :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) RE: IP Spoofing
From: Pete Ashdown <pashdown@xmission.com>
Date: 1999-09-03 11:22:25

Mike Wronski said once upon a time: > >There is the global switch "ENABLE IP SOURCE_ADDRESS_FILTER" that would be the >best method of turning on this feature.. Mike, does this still not take into account framed-routes? Will it ever?

Subject: Re: (usr-tc) Problems with Connect Speeds going down
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-09-03 12:37:19

Can anyone connect at a higher rate? Or are we talking about a few customers? At 01:16 PM 9/3/99 -0500, you wrote: >Looking for any help with a new problem that started about a week ago where >customers that connect at 50,666k or 52k are now connecting at 31,2k or >33.6k. We have changed nothing on our Total Control. We use the Hiper DSP >cards with PRI's and Hiper Arc card and we are running Hiper DSP code 1.2.43 >and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week >ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if that >would help but it has not. Our PRI's come from GTE and they say they cannot >find anything wrong on their lines. I have seen this myself from my home and >it does not make sense. > >Any help would be appreciated. > >Thank you, > >Clint R. Sparks >ComQuest Internet Services >csparks@cqc.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 <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446

Subject: RE: (usr-tc) RE: IP Spoofing
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-03 13:07:15

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Friday, September 03, 1999 12:22 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) RE: IP Spoofing | | |Mike Wronski said once upon a time: |> |>There is the global switch "ENABLE IP SOURCE_ADDRESS_FILTER" that would be the |>best method of turning on this feature.. | |Mike, does this still not take into account framed-routes? Will it ever? Yes, and eventually. -M

Subject: (usr-tc) Connect-Speed attribute
From: Scott Boggs <sboggs@unitedbank.net>
Date: 1999-09-03 13:09:15

The RADIUS section of the HARC docs describes a RADIUS attribute Connect-Speed (0x9023) It is described as a "32-bit integer". When I capture this attribute, it appears as a number usually between 20-49. Does anyone know how to translate this "32-bit integer"? TIA. Scott Boggs Network Admin. AccessUnited

Subject: (usr-tc) Problems with Connect Speeds going down
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-03 13:16:14

Looking for any help with a new problem that started about a week ago where customers that connect at 50,666k or 52k are now connecting at 31,2k or 33.6k. We have changed nothing on our Total Control. We use the Hiper DSP cards with PRI's and Hiper Arc card and we are running Hiper DSP code 1.2.43 and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if that would help but it has not. Our PRI's come from GTE and they say they cannot find anything wrong on their lines. I have seen this myself from my home and it does not make sense. Any help would be appreciated. Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com

Subject: Re: (usr-tc) Need Some Quad Modems
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-09-03 13:57:20

I have about 25 in stock... about 8 NICS . These are the V.34 analog/Digital. We have been selling them at $175 each with a 90 day warranty We take all credit cards, Best Regards, Andrew Shlensky **************************** PC Global, Inc. (602) 438-6200 office (NEW TEL NUMBER!) (602) 438-1119 fax (305) 216-8638 mobile New!e-mail my mobile http://www.nextel.com/paging URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! Leader in New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Friday, September 03, 1999 1:45 PM I'm in the market for some digital quads. Email me if you have some to sell. I could use 1-2 dozen of them. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Need Some Quad Modems
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-09-03 13:58:03

sorry that was supposed to be a private reply. Andrew Shlensky **************************** PC Global, Inc. (602) 438-6200 office (NEW TEL NUMBER!) (602) 438-1119 fax (305) 216-8638 mobile New!e-mail my mobile http://www.nextel.com/paging URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! Leader in New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Friday, September 03, 1999 1:45 PM I'm in the market for some digital quads. Email me if you have some to sell. I could use 1-2 dozen of them. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Problems with Connect Speeds going down
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-03 13:58:20

Yes, we are seeing about 55% connecting at 56k speeds, the rest at 33.6k or lower. The odd thing is people that always connected at 50k will now connect at 31,2k 8 times and then 49,333k or 45,333k then the next time 31,2k again. I just received a call from GTE saying they checked all the spans and they see nothing wrong, no errors of any kind. It is affecting numerous customers from all over the city and county. I have another identical setup Total Control in another city which is Ameritech and no problems, speeds are great and no complaints. ----- Original Message ----- Sent: Friday, September 03, 1999 1:37 PM > Can anyone connect at a higher rate? Or are we talking about a few customers? > > At 01:16 PM 9/3/99 -0500, you wrote: > >Looking for any help with a new problem that started about a week ago where > >customers that connect at 50,666k or 52k are now connecting at 31,2k or > >33.6k. We have changed nothing on our Total Control. We use the Hiper DSP > >cards with PRI's and Hiper Arc card and we are running Hiper DSP code 1.2.43 > >and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week > >ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if that > >would help but it has not. Our PRI's come from GTE and they say they cannot > >find anything wrong on their lines. I have seen this myself from my home and > >it does not make sense. > >

Subject: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
From: Brian Becker <brian@semo.net>
Date: 1999-09-03 14:10:18

We have a web tv that can authenticate in one area but not in another. Both circuits are built the same and in the same TELCO. Area that does work--- DSP - 1.2.5 ARC - 4.1.78 NMC - 5.6.2 New PPP Call received on interface slot:1/mod:23 Unexpected (LCP) Layer Down, ID 1, Restarting Link 28814384, to . PPP - Authentication Complete to rhack56. PPP - IP Link UP to rhack56 (199.217.238.231) Local IP Address (199.217.238.227) was configured. Peer PPP at rhack56 Does NOT support AUTO compression, DISABLING. Area that doesn't work--- DSP - 2.0.81 ARC - 4.1.11 NMC - 6.1.17 New PPP Call received on interface slot:1/mod:11 ....Tracing of Call Events; Escape to stop... Unexpected (LCP) Layer Down, ID 1, Restarting Link 28043864, to . Peer has not requested Auth, PPP link down to . PPP connection down to . Brian Becker President, Poplar Bluff Internet http://www.semo.net TotallyFabricated.com Software http://www.TotallyFabricated.com Home of JerusalemPerspective.com http://www.JerusalemPerspective.com Personal Page http://Tonionio.com / http://BenjaminBecker.com

Subject: Re: (usr-tc) Problems with Connect Speeds going down
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-09-03 14:22:53

Could be that the local telco recently installed a SLC due to growth. That would explain losing it in a certain area but not all over town. A SLC takes out a whole area but they also install pairgain in certain locations that will strip out 56k. That is usually at a residence or business. Much smaller scale. At 01:58 PM 9/3/99 -0500, you wrote: >Yes, we are seeing about 55% connecting at 56k speeds, the rest at 33.6k or >lower. The odd thing is people that always connected at 50k will now connect >at 31,2k 8 times and then 49,333k or 45,333k then the next time 31,2k again. >I just received a call from GTE saying they checked all the spans and they >see nothing wrong, no errors of any kind. It is affecting numerous customers >from all over the city and county. I have another identical setup Total >Control in another city which is Ameritech and no problems, speeds are great >and no complaints. > > >----- Original Message ----- >From: Greg Coffey <gcoffey@vcn.com> >To: <usr-tc@lists.xmission.com> >Sent: Friday, September 03, 1999 1:37 PM >Subject: Re: (usr-tc) Problems with Connect Speeds going down > > > > Can anyone connect at a higher rate? Or are we talking about a few >customers? > > > > At 01:16 PM 9/3/99 -0500, you wrote: > > >Looking for any help with a new problem that started about a week ago >where > > >customers that connect at 50,666k or 52k are now connecting at 31,2k or > > >33.6k. We have changed nothing on our Total Control. We use the Hiper DSP > > >cards with PRI's and Hiper Arc card and we are running Hiper DSP code >1.2.43 > > >and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a >week > > >ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if >that > > >would help but it has not. Our PRI's come from GTE and they say they >cannot > > >find anything wrong on their lines. I have seen this myself from my home >and > > >it does not make sense. > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446

Subject: (usr-tc) Need Some Quad Modems
From: Greg Coffey <gcoffey@vcn.com>
Date: 1999-09-03 14:45:42

I'm in the market for some digital quads. Email me if you have some to sell. I could use 1-2 dozen of them. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446

Subject: Re: (usr-tc) Connect-Speed attribute
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-03 15:01:21

On Fri, 3 Sep 1999, Scott Boggs wrote: > The RADIUS section of the HARC docs describes a RADIUS attribute > Connect-Speed (0x9023) > It is described as a "32-bit integer". > When I capture this attribute, it appears as a number usually between 20-49. > Does anyone know how to translate this "32-bit integer"? Yeah. It should be in your dictionary file. Here's a chunk of ours (from Cistron radius): VALUE USR-Initial-Tx-Link-Data-Rate 110-BPS 1 VALUE USR-Initial-Tx-Link-Data-Rate 300-BPS 2 VALUE USR-Initial-Tx-Link-Data-Rate 600-BPS 3 VALUE USR-Initial-Tx-Link-Data-Rate 1200-BPS 4 VALUE USR-Initial-Tx-Link-Data-Rate 2400-BPS 5 VALUE USR-Initial-Tx-Link-Data-Rate 4800-BPS 6 VALUE USR-Initial-Tx-Link-Data-Rate 7200-BPS 7 VALUE USR-Initial-Tx-Link-Data-Rate 9600-BPS 8 VALUE USR-Initial-Tx-Link-Data-Rate 12000-BPS 9 VALUE USR-Initial-Tx-Link-Data-Rate 14400-BPS 10 VALUE USR-Initial-Tx-Link-Data-Rate 16800-BPS 11 VALUE USR-Initial-Tx-Link-Data-Rate 19200-BPS 12 VALUE USR-Initial-Tx-Link-Data-Rate 38400-BPS 13 VALUE USR-Initial-Tx-Link-Data-Rate 75-BPS 14 VALUE USR-Initial-Tx-Link-Data-Rate 450-BPS 15 VALUE USR-Initial-Tx-Link-Data-Rate UNKNOWN-BPS 16 VALUE USR-Initial-Tx-Link-Data-Rate 57600-BPS 17 VALUE USR-Initial-Tx-Link-Data-Rate 21600-BPS 18 VALUE USR-Initial-Tx-Link-Data-Rate 24000-BPS 19 VALUE USR-Initial-Tx-Link-Data-Rate 26400-BPS 20 VALUE USR-Initial-Tx-Link-Data-Rate 28800-BPS 21 VALUE USR-Initial-Tx-Link-Data-Rate 115200-BPS 22 VALUE USR-Initial-Tx-Link-Data-Rate 31200-BPS 23 VALUE USR-Initial-Tx-Link-Data-Rate 33600-BPS 24 VALUE USR-Initial-Tx-Link-Data-Rate 25333-BPS 25 VALUE USR-Initial-Tx-Link-Data-Rate 26666-BPS 26 VALUE USR-Initial-Tx-Link-Data-Rate 28000-BPS 27 VALUE USR-Initial-Tx-Link-Data-Rate 29333-BPS 28 VALUE USR-Initial-Tx-Link-Data-Rate 30666-BPS 29 VALUE USR-Initial-Tx-Link-Data-Rate 32000-BPS 30 VALUE USR-Initial-Tx-Link-Data-Rate 33333-BPS 31 VALUE USR-Initial-Tx-Link-Data-Rate 34666-BPS 32 VALUE USR-Initial-Tx-Link-Data-Rate 36000-BPS 33 VALUE USR-Initial-Tx-Link-Data-Rate 37333-BPS 34 VALUE USR-Initial-Tx-Link-Data-Rate 38666-BPS 35 VALUE USR-Initial-Tx-Link-Data-Rate 40000-BPS 36 VALUE USR-Initial-Tx-Link-Data-Rate 41333-BPS 37 VALUE USR-Initial-Tx-Link-Data-Rate 42666-BPS 38 VALUE USR-Initial-Tx-Link-Data-Rate 44000-BPS 39 VALUE USR-Initial-Tx-Link-Data-Rate 45333-BPS 40 VALUE USR-Initial-Tx-Link-Data-Rate 46666-BPS 41 VALUE USR-Initial-Tx-Link-Data-Rate 48000-BPS 42 VALUE USR-Initial-Tx-Link-Data-Rate 49333-BPS 43 VALUE USR-Initial-Tx-Link-Data-Rate 50666-BPS 44 VALUE USR-Initial-Tx-Link-Data-Rate 52000-BPS 45 VALUE USR-Initial-Tx-Link-Data-Rate 53333-BPS 46 VALUE USR-Initial-Tx-Link-Data-Rate 54666-BPS 47 VALUE USR-Initial-Tx-Link-Data-Rate 56000-BPS 48 VALUE USR-Initial-Tx-Link-Data-Rate 57333-BPS 49 VALUE USR-Initial-Tx-Link-Data-Rate 58666-BPS 50 VALUE USR-Initial-Tx-Link-Data-Rate 60000-BPS 51 VALUE USR-Initial-Tx-Link-Data-Rate 61333-BPS 52 VALUE USR-Initial-Tx-Link-Data-Rate 62666-BPS 53 VALUE USR-Initial-Tx-Link-Data-Rate 64000-BPS 54

Subject: Re: (usr-tc) Problems with Connect Speeds going down
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-03 15:29:10

I have a bunch of customers who were served from a Bell Atlantic central office equipped with a Lucent 1A switch. A week ago, BA upgraded the switch to a 5ESS. Connect speeds from half of the people served by that switch dropped from 47-50K to below 40. GTE would have had to replace a bunch of switches on the user side all at once for it to have such a sweeping effect as you have described. Also, ask them about their tandems. Buggers, they are. May be a whole geographical section of your customers served by a single tandem switch that is on the fritz. There are 2 that serve our area, and one of them is ALWAYS having problems. ...Scot ----- Original Message ----- Sent: Friday, September 03, 1999 2:16 PM > Looking for any help with a new problem that started about a week ago where > customers that connect at 50,666k or 52k are now connecting at 31,2k or > 33.6k. We have changed nothing on our Total Control. We use the Hiper DSP > cards with PRI's and Hiper Arc card and we are running Hiper DSP code 1.2.43 > and Hiper Arc 4.1.59-6. We have had absolutely no problems up until a week > ago, we have rebooted our Hiper DSP cards and Hiper Arc card to see if that > would help but it has not. Our PRI's come from GTE and they say they cannot > find anything wrong on their lines. I have seen this myself from my home and > it does not make sense. > > Any help would be appreciated. > > Thank you, > > Clint R. Sparks > ComQuest Internet Services > csparks@cqc.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. >

Subject: RE: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-09-03 15:55:00

Something else to verify.. From my experience i have found the following webtv units require pap authentication be the default for the chassis they also require vj header compression set in radius -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski Sent: Friday, September 03, 1999 2:57 PM Cc: brian@semo.net Change the code on the HARCs to Match.. You have a strange code combination.. Working area has newer arc code and old DSP code. Non working area has new DSP and very old HARC code.. I would sugest that you use 4.1.59-6 for HARC and 2.0.81 for the DSPs everywhere. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker |Sent: Friday, September 03, 1999 3:10 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500 | | |We have a web tv that can authenticate in one area but not in another. Both |circuits are built the same and in the same TELCO. | |Area that does work--- |DSP - 1.2.5 |ARC - 4.1.78 |NMC - 5.6.2 |New PPP Call received on interface slot:1/mod:23 |Unexpected (LCP) Layer Down, ID 1, Restarting Link 28814384, to . |PPP - Authentication Complete to rhack56. |PPP - IP Link UP to rhack56 (199.217.238.231) |Local IP Address (199.217.238.227) was configured. |Peer PPP at rhack56 Does NOT support AUTO compression, DISABLING. | |Area that doesn't work--- |DSP - 2.0.81 |ARC - 4.1.11 |NMC - 6.1.17 |New PPP Call received on interface slot:1/mod:11 |....Tracing of Call Events; Escape to stop... |Unexpected (LCP) Layer Down, ID 1, Restarting Link 28043864, to . |Peer has not requested Auth, PPP link down to . |PPP connection down to . | |Brian Becker |President, Poplar Bluff Internet | http://www.semo.net |TotallyFabricated.com Software | http://www.TotallyFabricated.com |Home of JerusalemPerspective.com | http://www.JerusalemPerspective.com |Personal Page | http://Tonionio.com / http://BenjaminBecker.com | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-03 16:57:19

Change the code on the HARCs to Match.. You have a strange code combination.. Working area has newer arc code and old DSP code. Non working area has new DSP and very old HARC code.. I would sugest that you use 4.1.59-6 for HARC and 2.0.81 for the DSPs everywhere. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker |Sent: Friday, September 03, 1999 3:10 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Date: Fri, 3 Sep 1999 15:04:50 -0500 | | |We have a web tv that can authenticate in one area but not in another. Both |circuits are built the same and in the same TELCO. | |Area that does work--- |DSP - 1.2.5 |ARC - 4.1.78 |NMC - 5.6.2 |New PPP Call received on interface slot:1/mod:23 |Unexpected (LCP) Layer Down, ID 1, Restarting Link 28814384, to . |PPP - Authentication Complete to rhack56. |PPP - IP Link UP to rhack56 (199.217.238.231) |Local IP Address (199.217.238.227) was configured. |Peer PPP at rhack56 Does NOT support AUTO compression, DISABLING. | |Area that doesn't work--- |DSP - 2.0.81 |ARC - 4.1.11 |NMC - 6.1.17 |New PPP Call received on interface slot:1/mod:11 |....Tracing of Call Events; Escape to stop... |Unexpected (LCP) Layer Down, ID 1, Restarting Link 28043864, to . |Peer has not requested Auth, PPP link down to . |PPP connection down to . | |Brian Becker |President, Poplar Bluff Internet | http://www.semo.net |TotallyFabricated.com Software | http://www.TotallyFabricated.com |Home of JerusalemPerspective.com | http://www.JerusalemPerspective.com |Personal Page | http://Tonionio.com / http://BenjaminBecker.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. |

Subject: Re: (usr-tc) Problems with Connect Speeds going down
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-03 17:56:05

As it happens, GTE in my area has just one switch GTD 5 I believe and it covers all the customers in my area of service. They just recently upgraded the switch to handle more PRI's which is what we use as they were out of capacity to fill PRI orders. Of course if it is because of the recent upgrade to their switch I will have a heck of a time getting them to believe it is something that started when they upgraded and that it has to be related. > I have a bunch of customers who were served from a Bell Atlantic central > office equipped with a Lucent 1A switch. A week ago, BA upgraded the switch > to a 5ESS. Connect speeds from half of the people served by that switch > dropped from 47-50K to below 40. > > GTE would have had to replace a bunch of switches on the user side all at > once for it to have such a sweeping effect as you have described. > > Also, ask them about their tandems. Buggers, they are. May be a whole > geographical section of your customers served by a single tandem switch that > is on the fritz. There are 2 that serve our area, and one of them is ALWAYS > having problems. > > > ...Scot >

Subject: (usr-tc) ARC rebooting over and over...
From: D Mayer <dmayer@netwalk.com>
Date: 1999-09-04 19:30:20

I've got an ARC that's been working normally on 4.1.59-6 since it was installed about 2 weeks ago, and it suddenly started rebooting itself in the middle of the night last night. From console I'm getting the crash dumps included below just after the boot prom menu exits. The first two are what it was getting when I first checked it, it was trying to load normally from flash. I then tried having it boot from TFTP and captured the second two crash dumps (somewhat different). I figure this is a flash corruption or something, but I don't know how to fix it. At one point it did actually boot, and I re-uploaded netserve.dmf (4.1.59-6), but when I rebooted again it started the reboot cycle over again. Any suggestions? TIA, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com Here are the crash dumps: Attempting auto-load from Flash ... EXCEPTION 0300 CRASH DUMP: GPRs: R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BB552DA R4: 0x00000400 R5: 0x00176591 R6: 0x45D8C3FF R7: 0x00168140 R8: 0x00168220 R9: 0x8BB10000 R10: 0x00000000 R11: 0x000000E9 R12: 0x000000A0 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0 R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148 R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF R24: 0x00139AB8 R25: 0x00000001 R26: 0x00000001 : 0x00000400 R28: 0x000000B1 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x307D3FA0 SPRs: CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0x45D6DE92 SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x307D3FA3 DMISS: 0x307D3FA4 DCMP: 0x80000001 HASH1: 0x0001F4C0 HASH2: 0x00010B00 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607E0 Call Stack: 0x0006B26C (Exception return address - SRR0) 0x0006B254 0x0009EE18 0x000967D4 0x00096890 0x0009912C 0x000A1258 0x0009F29C 0x000A0708 0x00046994 0x00045FC8 0x000462A8 0x00045B28 Attempting auto-load from Flash ... EXCEPTION 0300 CRASH DUMP: GPRs: R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BFD3DE2 R4: 0x00000400 R5: 0x0017255D R6: 0x00000000 R7: 0x00168140 R8: 0x00168220 R9: 0x8BF80000 R10: 0x00000000 R11: 0x000000F6 R12: 0x00000037 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0 R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148 R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF R24: 0x0012837C R25: 0x00000001 R26: 0x00000001 R27: 0x00000400 R28: 0x000000F8 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x95ADCDCB SPRs: CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0xFFFDAF0F SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x95ADCDC8 DMISS: 0x95ADCDCF DCMP: 0x80000016 HASH1: 0x0001B700 HASH2: 0x000148C0 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x80050CC0, Sys Error Addr: 0x000607E0 Call Stack: 0x0006B26C (Exception return address - SRR0) 0x0006B254 0x0009EE18 0x000967D4 0x00096890 0x0009912C 0x000A1258 0x0009F29C 0x000A0708 0x00046994 0x00045FC8 0x000462A8 0x00045B28 Attempting auto-load from Network ... Initializing Flash Filesystem ... OK No Change in kernel.dmi (Flash not Updated) Reinitializing decompression module. In : 303800 bytes --10--20--30--40--50--60--70--80--90--100 . EXCEPTION 0200 CRASH DUMP: GPRs: R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000 R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000124 R8: 0x0000012A R9: 0x0000012A R10: 0x00000129 R11: 0x0000001F R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000 R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3 R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510 R24: 0x00000000 R25: 0x0004A2B8 R26: 0x00000000 R27: 0x00010000 R28: 0x00000000 R29: 0x00000002 R30: 0x00000000 R31: 0x00000000 SPRs: CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10EC8 SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 82660 Registers: Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06 CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40 Call Stack: 0x00F10094 (Exception return address - SRR0) 0x00F0E980 0x00F0F4F0 0x00F005A0 0x00F009F0 0x00F00390 0x00F00028 Attempting auto-load from Network ... Initializing Flash Filesystem ... OK No Change in kernel.dmi (Flash not Updated) Reinitializing decompression module. In : 303800 bytes --10--20--30--40--50--60--70--80--90--100 . Can't write. EXCEPTION 0200 CRASH DUMP: GPRs: R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000 R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000208 R8: 0x000001D1 R9: 0x000001D1 R10: 0x0000010A R11: 0x0000001F R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000 R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3 R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510 R24: 0x00000000 R25: 0x00000035 R26: 0x00FAE748 R27: 0x00000008 R28: 0x00000000 R29: 0x00000101 R30: 0x00000072 R31: 0x00000002 SPRs: CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10F80 SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 82660 Registers: Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06 CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40 Call Stack: 0x00F10094 (Exception return address - SRR0) 0x00F0E980 0x00F0F57C 0x00F005A0 0x00F009F0 0x00F00390 0x00F00028

Subject: (usr-tc) Power requirements
From: pferraro@wna-linknet.com
Date: 1999-09-04 22:20:40

Can anyone tell me what the power requirements are for a HIPER Hub with 1 70amp A/C power supply, built in fan tray, 3 Hiper DSPs, HiperArc and NMC card? I have this unit plugged into a TrippLite UPS (the only thing plugged into it) and occassionally when we get some power fluctuations the hub shuts down! We have to actually turn it OFF and then back ON again! How do I figure out the power requirements? Should we move up to a large UPS? Any and all comments appreciated! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) ARC rebooting over and over...
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-09-05 10:39:48

You should try to re-initialize and reload the flash code with the: AT{ZF} After reboot. - Marcelo On Sat, 4 Sep 1999, D Mayer wrote: |I've got an ARC that's been working normally on 4.1.59-6 since it was |installed about 2 weeks ago, and it suddenly started rebooting itself in the |middle of the night last night. From console I'm getting the crash dumps |included below just after the boot prom menu exits. The first two are what |it was getting when I first checked it, it was trying to load normally from |flash. I then tried having it boot from TFTP and captured the second two |crash dumps (somewhat different). | |I figure this is a flash corruption or something, but I don't know how to |fix it. At one point it did actually boot, and I re-uploaded netserve.dmf |(4.1.59-6), but when I rebooted again it started the reboot cycle over |again. Any suggestions? | |TIA, |Peter D. Mayer |NetWalk System Administrator |dmayer@netwalk.com | | |Here are the crash dumps: | |Attempting auto-load from Flash ... | | |EXCEPTION 0300 CRASH DUMP: | |GPRs: |R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BB552DA |R4: 0x00000400 R5: 0x00176591 R6: 0x45D8C3FF R7: 0x00168140 |R8: 0x00168220 R9: 0x8BB10000 R10: 0x00000000 R11: 0x000000E9 |R12: 0x000000A0 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0 |R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148 |R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF |R24: 0x00139AB8 R25: 0x00000001 R26: 0x00000001 : 0x00000400 |R28: 0x000000B1 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x307D3FA0 | |SPRs: |CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0x45D6DE92 |SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x307D3FA3 |DMISS: 0x307D3FA4 DCMP: 0x80000001 HASH1: 0x0001F4C0 HASH2: 0x00010B00 |IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 | |82660 Registers: |Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 |CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607E0 | |Call Stack: | 0x0006B26C (Exception return address - SRR0) | 0x0006B254 | 0x0009EE18 | 0x000967D4 | 0x00096890 | 0x0009912C | 0x000A1258 | 0x0009F29C | 0x000A0708 | 0x00046994 | 0x00045FC8 | 0x000462A8 | 0x00045B28 | | | | |Attempting auto-load from Flash ... | | |EXCEPTION 0300 CRASH DUMP: | |GPRs: |R0: 0x0009EE18 R1: 0x07FCFF28 R2: 0x000B50A4 R3: 0x8BFD3DE2 |R4: 0x00000400 R5: 0x0017255D R6: 0x00000000 R7: 0x00168140 |R8: 0x00168220 R9: 0x8BF80000 R10: 0x00000000 R11: 0x000000F6 |R12: 0x00000037 R13: 0x000BD2AC R14: 0x00000000 R15: 0x0011EEB0 |R16: 0x00000000 R17: 0x00000000 R18: 0x001CF27A R19: 0x07FD0148 |R20: 0x0011EEB0 R21: 0x0000823F R22: 0x0011EEB0 R23: 0x0000FFFF |R24: 0x0012837C R25: 0x00000001 R26: 0x00000001 R27: 0x00000400 |R28: 0x000000F8 R29: 0x00172280 R30: 0x0004B0A8 R31: 0x95ADCDCB | |SPRs: |CR: 0x24000000 XER: 0x20000001 LR: 0x0006B254 CTR: 0xFFFDAF0F |SRR0: 0x0006B26C SRR1: 0x00003930 DSISR: 0x40000000 DAR: 0x95ADCDC8 |DMISS: 0x95ADCDCF DCMP: 0x80000016 HASH1: 0x0001B700 HASH2: 0x000148C0 |IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 | |82660 Registers: |Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 |CPU/PCI Addr: 0x80050CC0, Sys Error Addr: 0x000607E0 | |Call Stack: | 0x0006B26C (Exception return address - SRR0) | 0x0006B254 | 0x0009EE18 | 0x000967D4 | 0x00096890 | 0x0009912C | 0x000A1258 | 0x0009F29C | 0x000A0708 | 0x00046994 | 0x00045FC8 | 0x000462A8 | 0x00045B28 | | | | | |Attempting auto-load from Network ... | |Initializing Flash Filesystem ... OK |No Change in kernel.dmi (Flash not Updated) | |Reinitializing decompression module. |In : 303800 bytes |--10--20--30--40--50--60--70--80--90--100 |. | |EXCEPTION 0200 CRASH DUMP: | |GPRs: |R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000 |R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000124 |R8: 0x0000012A R9: 0x0000012A R10: 0x00000129 R11: 0x0000001F |R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000 |R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3 |R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510 |R24: 0x00000000 R25: 0x0004A2B8 R26: 0x00000000 R27: 0x00010000 |R28: 0x00000000 R29: 0x00000002 R30: 0x00000000 R31: 0x00000000 | |SPRs: |CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10EC8 |SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F |DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0 |IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 | |82660 Registers: |Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06 |CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40 | |Call Stack: | 0x00F10094 (Exception return address - SRR0) | 0x00F0E980 | 0x00F0F4F0 | 0x00F005A0 | 0x00F009F0 | 0x00F00390 | 0x00F00028 | | | | | |Attempting auto-load from Network ... | |Initializing Flash Filesystem ... OK |No Change in kernel.dmi (Flash not Updated) | |Reinitializing decompression module. |In : 303800 bytes |--10--20--30--40--50--60--70--80--90--100 |. |Can't write. | | | |EXCEPTION 0200 CRASH DUMP: | |GPRs: |R0: 0x00F0E980 R1: 0x010FFD58 R2: 0x00F1F748 R3: 0x00000000 |R4: 0x00F1788C R5: 0x00FB6DD0 R6: 0x00FB6DD0 R7: 0x00000208 |R8: 0x000001D1 R9: 0x000001D1 R10: 0x0000010A R11: 0x0000001F |R12: 0x0CBA9E40 R13: 0x00F1FDB0 R14: 0x00000000 R15: 0x00000000 |R16: 0x00000000 R17: 0x00F17E74 R18: 0x00F17E70 R19: 0x0000FDB3 |R20: 0x00F17DE0 R21: 0x00001DAB R22: 0x00F17DE8 R23: 0x00FB6510 |R24: 0x00000000 R25: 0x00000035 R26: 0x00FAE748 R27: 0x00000008 |R28: 0x00000000 R29: 0x00000101 R30: 0x00000072 R31: 0x00000002 | |SPRs: |CR: 0x44000000 XER: 0x20000018 LR: 0x00F0E980 CTR: 0x00F10F80 |SRR0: 0x00F10094 SRR1: 0x0008B930 DSISR: 0x40000000 DAR: 0x38634C4F |DMISS: 0x38634C48 DCMP: 0x80000021 HASH1: 0x00018D00 HASH2: 0x000172C0 |IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 | |82660 Registers: |Err Status 1: 0x20, Err Status 2: 0x00, CPU Err: 0x72, PCI Err: 0x06 |CPU/PCI Addr: 0x0CBA9E40, Sys Error Addr: 0x0CBA9E40 | |Call Stack: | 0x00F10094 (Exception return address - SRR0) | 0x00F0E980 | 0x00F0F57C | 0x00F005A0 | 0x00F009F0 | 0x00F00390 | 0x00F00028 | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. | - Marcelo

Subject: Re: (usr-tc) ARC rebooting over and over...
From: Michael DeMan <michael@prf.org>
Date: 1999-09-05 14:08:03

We had a similar problem. We had to initialize and reload the flash from the command console. It started up again a couple days later, and eventually became non-recoverable - the entire card had to be replaced.

Subject: RE: (usr-tc) SNMP OID to reset card
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-09-06 17:11:18

Yeah, but the solaris version is only compatible to 2.5.1 on SPARC. = This sucks bad as my network management station is an ultra-1 running 2.6 = because of HP OpenView... okay I do have an old HP 9000 lying around somehwere = which I could use for TCM (yet another 20" screen on my desktop ;-) Does anyone have any experience with the HPUX version ? is it = good/bad/same as solaris ? Robert von BISMARCK Systems Engineer _________________________ SPAN* / Petrel Communications SA=20 T=E9l : + 41 22 304 47 47 Fax : + 41 21 304 47 99 e-mail : rvb@petrel.ch Web : http://ww.span.ch/ -----Original Message----- From: Pete Ashdown [SMTP:pashdown@xmission.com] Sent: lundi, 30. ao=FBt 1999 19:55 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) SNMP OID to reset card Paul Farber said once upon a time: >Is there a LINUX version of TCM yet? I remember a list post to mail a guy >at 3Com... and luck yet? I had a long discussion with the person in charge of development. He placed a survey on the list that polled interest in regards to a Linux version. He didn't get a strong response, and was put off by the fact that people think TCM would be a better product if it was open source. Based on this, I don't think TCM Linux is a strong bet. 3com appears to be happy to stick their head in the sand for a few more years based on an informal poll. What baffles me is that they insist on still making the HPUX version. Do they honestly believe that more ISPs/sysadmins are using HPUX than Linux? >Has anyone got TCM to run under X w/Wine? No, but I use it under Solaris and X. The Solaris version is significantly better than the Windoze version. Its worth buying a cheap IPX for the sole purpose of running TCM. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Mr. PC Global and his Spam
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-09-06 17:12:59

Yep, got it too and find it bad, as we didn't get anough spam = already... -----Original Message----- From: Phil Le Clercq [SMTP:phil.le.clercq@cinergy.net] Sent: mardi, 31. ao=FBt 1999 10:21 To: 'usr-tc@lists.xmission.com'; 'andrew@pcglobal.net' Subject: (usr-tc) Mr. PC Global and his Spam Has anyone else on the TCH list received the below spam from pcglobal? The only way my email address would have been nabbed would be from this TCH list. I am formally asking pcglobal to refrain from using these mailing techniques, this was not the reason for which I joined this list and believe it to be bang out of order. Please don't do it again. Phil Le Clercq "Dear Subscriber, You have been asked to be added to our Huge Inventory list. This list will be updated to alert you as we receive in the quantites of computer hardware we notified you of. We just received in the following- We wish to move the lots of equipment as specified in the category: Please submit your offer. Our decision to sell will be made by 3:00 Tuesday Aug, 30 1999 As always, all items are in stock, in OUR inventory. No middlemen, brokers involved. All items FOB Phoenix, AZ PRINTERS: (2) Lexmark Optra R+ W/Duplexer.......more crap ........(15) HP Vectra VL90=20 (20) ATT Globalyst 520 (30) assorted 486 notebooks color/mono PC Global, Inc=20 (602) 438-6200 Tel (602) 438-1119 Fax Customer relations=20 Inventory logistics" -----Original Message----- From: Jack Singer [mailto:jsinger@aaacars.com] Sent: Tuesday, August 31, 1999 2:53 AM To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) Need used TC Units If it is cheap enough.... Jack "Andrew:PC Global, Inc." wrote: > Can you use v.34 token ring chassis? > > Andrew Shlensky > **************************** > PC Global, Inc. > (602) 438-6200 office (NEW TEL NUMBER!) > (602) 438-1119 fax > (305) 216-8638 mobile > New!e-mail my mobile http://www.nextel.com/paging > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > ICQ: 21219089 > Computer Service Parts SpEciaLiSts! > Leader in New/Used PCs,Laptops > Communication & Networking,Monitors > Printers, Hard Drives, Midrange/Mainframe. > Hard to Get Parts. We buy and sell all > types of GEAR- > **************************** > ----- Original Message ----- > From: Jack Singer <jsinger@aaacars.com> > To: <usr-tc@lists.xmission.com> > Sent: Monday, August 30, 1999 12:56 PM > Subject: (usr-tc) Need used TC Units > > Wanted to buy, used Total Control units, prefer X2 or V.90 upgraded. I need > eight or more units, so if you have one or more, please email or call me > directly. > > Internet Connections > 6008 Hermitage Road > Richmond, VA 23228 > (800) 664-5270 > jsinger@i-c.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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.

Subject: (usr-tc) QUAD USR
From: jamie dolan <jamie@powernetonline.com>
Date: 1999-09-06 20:38:42

This is a multi-part message in MIME format. ------=_NextPart_000_0280_01BEF8A7.CEFB5FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, One of my old 2 PRI's quad units has been giving us problems for some = time now. I want to get rid of it. I already have several Hyper = chasies, so I can either use DSP cards or a whole new DSP chassie with = cards in it. I am wondering what someone can suggest, in terms of trade = in programs and how well the programs have or have not worked for you. = If any one has a web site with a current list of all USR and vendor = promos, please let me know. Thanks. PowerNet ------=_NextPart_000_0280_01BEF8A7.CEFB5FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT size=3D2>One of my old 2 PRI's quad units has been giving us = problems=20 for some time now.  I want to get rid of it.  I already have = several=20 Hyper chasies, so I can either use DSP cards or a whole new DSP chassie = with=20 cards in it.  I am wondering what someone can suggest, in terms of = trade in=20 programs and how well the programs have or have not worked for = you.  If any=20 one has a web site with a current list of all USR and vendor promos, = please let=20 me know.</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>Thanks.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>PowerNet</FONT></DIV></BODY></HTML> ------=_NextPart_000_0280_01BEF8A7.CEFB5FC0--

Subject: Re: (usr-tc) Packet filtering strategies/netbus et al
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-07 08:00:20

Thus spake Mike Andrews >On Wed, 1 Sep 1999, Jeff Mcadams wrote: >> Perhaps, if you don't want to get into putting filters on your Arcs, and >> are more comfortable with ciscos, you can put the filters at the next >> hop cisco rather than on the arc directly. Doesn't get the filter quite >> to the edge, but limits the damage a script kiddie can do within your >> network. We don't do this, but I probably could. :) >For most of our ARCs (Frankfort), the next hop Cisco *is* the border. I >know, probably not a great network design, and I could fix it nowadays, >but it's one of those evolved vs designed things... And we're the same way in Louisville, what I was trying to get at was that if your Arc's are spread across multiple networks (ours are, even in Louisville), you can filter on the ethernet leading to the arcs, so, for example, this would keep someone on Arc 1 from killing someone on Arc 5 in our situation by putting the filters on the ethernets rather than the serial interfaces out to our upstream. >Yeah, and that's one thing I try to keep in mind before adding any more >filters -- too easy to screw up legitimate use. (Especially with the port >139 one... there are some mp3 leeching programs that use that to make the >file transfers harder to track.) But for some of the DoS-prevention ones, >I'd rather spend time on the phone explaining filters than time on the >phone explaining how to remove Back Orifice from their PC. :) (Been >there, done that, wasn't fun) We just point them at some of the anti-virus vendors web sites and tell them to go read. :) >You can get into the same religious argument with spam, and liability for >attacks/spam/whatever that do get through (if you don't filter, you're not >liable; if you do, you might be) and all the other fun policy crap I got >to learn by working at an .edu site for 3 years... :) But we won't get >into that here... No doubt...we don't do it so much from a liability point of view, but a bit more practical...I just don't want to have to keep the extra filters up to date. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) WTB: USR Total Control
From: Alex Bernal <alex@chiriqui.com>
Date: 1999-09-07 08:11:11

This is a multi-part message in MIME format. ------=_NextPart_000_0085_01BEF908.8BD80FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: I need to buy used in good working conditions: US Robotics Total Control chassis equipped as follows: Dual PRI card. NetServer card (It have to be with ethernet nic). Net management card (It have to be with ethernet nic). 12 digital/analog quad modems cards WITH analog/rs-232 NICs. Two 45A AC power supplies. 1 Fan tray. =20 Will pay 3,000.00 to 3,500.00 =20 Please respond privately to alex@chiriqui.com =20 =20 Alexander Bernal 011-507-774-2512 ------=_NextPart_000_0085_01BEF908.8BD80FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><BR></DIV> <DIV><FONT face=3DArial size=3D2>Hi:</FONT></DIV> <DIV><FONT face=3DArial size=3D2>I need to buy used in good working=20 conditions:</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>US Robotics Total Control chassis = equipped=20 as follows:</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Dual PRI card.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>NetServer card (It have to be with=20 ethernet nic).</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Net management card (It have to be with = ethernet=20 nic).</FONT></DIV> <DIV><FONT face=3DArial size=3D2>12 digital/analog quad modems cards = WITH=20 analog/rs-232 NICs.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Two 45A AC power = supplies.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>1 Fan tray.</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Will pay 3,000.00 to = 3,500.00</FONT></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Please respond privately to<BR><A=20 href=3D"mailto:alex@chiriqui.com">alex@chiriqui.com</A>  </FONT= ></DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV> <DIV><FONT face=3DArial size=3D2>Alexander Bernal=20 011-507-774-2512<BR></DIV></FONT></BODY></HTML> ------=_NextPart_000_0085_01BEF908.8BD80FC0--

Subject: (usr-tc) Modem product codes
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-09-07 10:22:23

Anyone know a good way of identifying the product code of a USR 56K Int modem with out having the user rip apart their machine or installing Modem Update Wizard? The ultimate goal is to determine if they have the latest firmware revision. ___ ___ (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: (usr-tc) simultanious radius crashes
From: Jim Faulkner <jlf@montrose-colo.com>
Date: 1999-09-07 11:46:23

Hello, I have TC security and accounting version 5.5.3 running on three NT systems. When one crashes the other 2 follow suit. It used to happen a couple times a year now it's been 6 times in three days. Any Ideas? Thanks, Jim Faulkner GWE.NET

Subject: Re: (usr-tc) Modem product codes
From: Andy Berkvam <aberkvam@coredcs.com>
Date: 1999-09-07 12:18:07

On Tue, 7 Sep 1999, Ken Kirchner wrote: > Anyone know a good way of identifying the product code of a USR 56K Int > modem with out having the user rip apart their machine or installing Modem > Update Wizard? The ultimate goal is to determine if they have the latest > firmware revision. > An ATI command (ATI7, I believe) should give you both the Device ID (product code) and the firmware dates and/or versions. You can usually either have the customer use the Diagnostics in the Modem control panel or use HyperTerminal to get the ATI commands (assuming they have Windows 9x). Andy -- =========================================================================== Andy Berkvam | "Only two things are infinite, the universe | and human stupidity, and I'm not sure about Email: | the former." aberkvam@coredcs.com | - Albert Einstein (MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/> ===========================================================================

Subject: (usr-tc) SNMP OID
From: Marius Strom <marius@alpha1.net>
Date: 1999-09-07 19:38:25

Forgive me for asking, as I'm sure it's been asked before, however: I'm looking for an SNMP OID to list how many users are online throughout an entire TC system. I know Livingston has one on their PM3 (.1.3.6.1.2.1.2.1.0).. Would appreciate it greatly! -- Marius Strom <marius@alpha1.net> Professional Geek/Unix System Administrator Alpha1 Internet <http://www.alpha1.net> http://www.marius.org/marius.pgp 0x5645C228 In theory, there is no difference between theory and practice... ...In practice, there is a big difference.

Subject: (usr-tc) found some users logged in as "default"
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-08 02:21:59

I found a couple users logged into a chassis as "default". They were not authenticated by (not was any request made to) my radius server. Anyone seen this happening before? Any clues? config info: us8a> _sh ver V4.2.29 - 1 us8a> show authen RADIUS AUTHENTICATION SETTINGS Local Authentication is: DISABLED Remote Authentication is: ENABLED Hint Assigned is: DISABLED Primary Server is: 205.139.108.2 Primary Destination Port is: 1645 Secondary Server is: 0.0.0.0 Secondary Destination Port is: 1645 Tertiary Server is: 0.0.0.0 Tertiary Destination Port is: 1645 Source Port is: 1645 Retransmission Timeout: 3 seconds Max Retranmissions: 10 Vendor Specific Attribute: ENABLED Active Authentication Server: 205.139.108.2 us8a> show user default INFORMATION FOR USER: default Status: INACTIVE Type: NETWORK Expiration: NONE Message: DNIS Re Authentication: DISABLED Phone Number: Alternate Phone Number: Input Filter: Output Filter: Modem Group: all Session Timeout in seconds: 0 Idle Timeout in seconds: 0 Tap Status: DISABLED Tap Format: ASCII Tap Output: SYSLOG Tap Facility: LOG_AUTH Tap Loglevel: VERBOSE Tap Address: 0.0.0.0 Chat Script Name: accounting radius entries for the call: Code: Accounting-Request Identifier: 143 Attributes: User-Name = "default" NAS-IP-Address = 192.168.0.224 Acct-Status-Type = Start Acct-Session-Id = "34603054" Acct-Delay-Time = 0 Acct-Authentic = Local Service-Type = Framed-User NAS-Port-Type = Async NAS-Port = 65 USR-Modem-Training-Time = 18 USR-Interface-Index = 1785 USR-Chassis-Call-Slot = 3 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 17 USR-Unauthenticated-Time = 22 Calling-Station-Id = "" Called-Station-Id = "5034262600" USR-Modulation-Type = v90Digital USR-Simplified-MNP-Levels = ccittV42 USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 50666_BPS Framed-Protocol = PPP Framed-IP-Address = 206.98.121.68 Code: Accounting-Request Identifier: 117 Authentic: <207>7<18><251><S<252><201><220><170>MV}Wg} Attributes: User-Name = "default" NAS-IP-Address = 192.168.0.224 Acct-Status-Type = Stop Acct-Session-Id = "34603054" Acct-Delay-Time = 0 Acct-Authentic = Local Service-Type = Framed-User NAS-Port-Type = Async NAS-Port = 65 USR-Modem-Training-Time = 18 USR-Interface-Index = 1785 USR-Chassis-Call-Slot = 3 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 17 USR-Unauthenticated-Time = 22 Calling-Station-Id = "" Called-Station-Id = "5034262600" USR-Modulation-Type = v90Digital USR-Simplified-MNP-Levels = ccittV42 USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 50666_BPS Framed-Protocol = PPP Framed-IP-Address = 206.98.121.68 Acct-Session-Time = 6123 Acct-Terminate-Cause = User-Request Acct-Input-Octets = 266748 Acct-Output-Octets = 2667718 Acct-Input-Packets = 4445 Acct-Output-Packets = 6035 -- Aaron Nabil

Subject: Re: (usr-tc) simultanious radius crashes
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 1999-09-08 09:41:54

If you enable debug on the servers and watch for the last received packet, is it the same on more than one server? What was the authentication type- pap/chap/ms-chap? STeve jlf@montrose-colo.com (Jim Faulkner) on 09/07/99 12:46:23 PM Please respond to usr-tc@lists.xmission.com Sent by: jlf@montrose-colo.com (Jim Faulkner) cc: (Steve Valiunas/MW/US/3Com) Hello, I have TC security and accounting version 5.5.3 running on three NT systems. When one crashes the other 2 follow suit. It used to happen a couple times a year now it's been 6 times in three days. Any Ideas? Thanks, Jim Faulkner GWE.NET - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) (USR-TC) SIMULTANIOUS RAD
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-08 10:51:00

Jim, We run 6.0.8 and it does the same thing. I am assuming you are pointing them all at the same MS Access database ? We get an NT access violation when they crash. Jeff Binkley ASA Network Computing U>Hello, U>I have TC security and accounting version 5.5.3 running on three NT U>systems. When one crashes the other 2 follow suit. It used to happen a U>couple times a year now it's been 6 times in three days. Any Ideas? U>Thanks, U>Jim Faulkner U>GWE.NET CMPQwk 1.42 9999

Subject: (usr-tc) Network Management
From: jamie dolan <jamie@powernetonline.com>
Date: 1999-09-08 11:53:11

This is a multi-part message in MIME format. ------=_NextPart_000_0532_01BEF9F0.B9863440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Anyone have a command referance for setting up the new Network Managment = Cards. Working on some special projects, and hoping for a complete = command referance. I can not seem to find one online. Thanks. Jamie ------=_NextPart_000_0532_01BEF9F0.B9863440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Anyone have a command referance for = setting up=20 the new Network Managment Cards.  Working on some special projects, = and=20 hoping for a complete command referance.  I can not seem to find = one=20 online.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Thanks.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Jamie</FONT></DIV></BODY></HTML> ------=_NextPart_000_0532_01BEF9F0.B9863440--

Subject: (usr-tc) Checking DSP CRC errors
From: pferraro@wna-linknet.com
Date: 1999-09-08 13:04:40

Anyone know how to check the DSPs to see how many CRC, etc type errors are received down a span? I assume you can do it at the CLI level, but I don't know the command? ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: RE: (usr-tc) Checking DSP CRC errors
From: pferraro@wna-linknet.com
Date: 1999-09-08 13:25:46

Matt, Is there a command to CLEAR the totals? Thanks Again! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Wed, 8 Sep 1999, Stainforth, Matthew wrote: > On Wednesday, September 08, 1999 2:05 PM, pferraro@wna-linknet.com > [SMTP:pferraro@wna-linknet.com] wrote: > > > > Anyone know how to check the DSPs to see how many CRC, etc type > > errors are received down a span? I assume you can do it at the CLI > > level, but I don't know the command? > > > > at the DSP CLI you would do "disp near total" in order to see the cumulative > errors. "Disp near current" gives you the current interval and "disp near > interval a" gives you all the 15 minute intervals in the last 24 hours. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Checking DSP CRC errors
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-08 14:19:43

On Wednesday, September 08, 1999 2:05 PM, pferraro@wna-linknet.com [SMTP:pferraro@wna-linknet.com] wrote: > > Anyone know how to check the DSPs to see how many CRC, etc type > errors are received down a span? I assume you can do it at the CLI > level, but I don't know the command? > at the DSP CLI you would do "disp near total" in order to see the cumulative errors. "Disp near current" gives you the current interval and "disp near interval a" gives you all the 15 minute intervals in the last 24 hours.

Subject: RE: (usr-tc) Checking DSP CRC errors
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-08 14:34:03

Not the cumulative totals, at last I have never found one. The only error clearing function I found was "clear near" which clears the error count for the current interval only. On Wednesday, September 08, 1999 2:26 PM, pferraro@wna-linknet.com [SMTP:pferraro@wna-linknet.com] wrote: > > Matt, > > Is there a command to CLEAR the totals? > Thanks Again! > ============================================================================ == > > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================ == > > > On Wed, 8 Sep 1999, Stainforth, Matthew wrote: > > > On Wednesday, September 08, 1999 2:05 PM, pferraro@wna-linknet.com > > [SMTP:pferraro@wna-linknet.com] wrote: > > > > > > Anyone know how to check the DSPs to see how many CRC, etc type > > > errors are received down a span? I assume you can do it at the CLI > > > level, but I don't know the command? > > > > > > > at the DSP CLI you would do "disp near total" in order to see the > > cumulative > > errors. "Disp near current" gives you the current interval and "disp near > > interval a" gives you all the 15 minute intervals in the last 24 hours. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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.

Subject: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN
From: das <das@gol.com>
Date: 1999-09-08 15:49:38

A bit of an emergency... I thought that I would upgrade my hipers this morning. I upgraded both to 4.1.59 and once they were rebooted they stopped authenticating ISDN calls. I flashed one to 4.1.11 and it lost various parts of it's configuration (ex. it lost its ip network settings but retained pool settings) I reconfigured it, but it still is having the same problems with ISDN. Analog calls authenticate happily. I have tried flashing the second HARC back to 4.1.59, but now it keeps failing the tftp upload. Also, when I look in the logs, it repeatedly logs: --syslog capture: 2b110903 slot:4/mod:10 --syslog capture:stop each time for the same interface (slot and modem) and then it moves to a different interface. If anyone can offer any insight into this, I'm sure that my customers will be happily and I will be extremely grateful. das -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN
From: das <das@gol.com>
Date: 1999-09-08 15:49:38

Subject: Re: (usr-tc) (USR-TC) SIMULTANIOUS RAD
From: Jim Faulkner <jlf@montrose-colo.com>
Date: 1999-09-08 17:14:01

Thanks Jeff, Actually I have a separate copy of the same database on each machine. I have a batch file that backs up the origonal dbase to each machine when I make changes. I get Dr Watson error warnings on the NT's and an Illegal Program operation on a W98 machine. Jim ----- Original Message ----- Sent: Wednesday, September 08, 1999 9:51 AM > > > > Jim, > > We run 6.0.8 and it does the same thing. I am assuming you are pointing > them all at the same MS Access database ? We get an NT access violation > when they crash. > > > Jeff Binkley > ASA Network Computing > > > > U>Hello, > > U>I have TC security and accounting version 5.5.3 running on three NT > U>systems. When one crashes the other 2 follow suit. It used to happen a > U>couple times a year now it's been 6 times in three days. Any Ideas? > > U>Thanks, > U>Jim Faulkner > U>GWE.NET > > CMPQwk 1.42 9999 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN
From: das <das@gol.com>
Date: 1999-09-08 17:58:12

Arigatou, Kobayashi-san. I am in Japan as well. I seem to have fixed the problem. I had to power cycle the chassis to get rid of it. I put a new HARC in the chassis, reconfigured it and I got the same results. I decided to power cycle the chassis, and it is now happy. Much stress for me though. Thank you for your suggestions. I had tried those steps at earlier stages as well, so it is good to see that I was on the right track. das Yuichi_Kobayashi@jp.3com.com (Yuichi_Kobayashi@jp.3com.com) spake: > > > Das, > > We don't have the similer problem in Japan though , so I am not sure but > Disableing or enabling PPP offloading may cure the problem . In case 'enable PPP > offloading ' then need to set 'DISABLE PPP RECEIVE_ACCM ' as the release note of > 4.1.59-6 . > > Regards, > Kobayashi. > -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: (usr-tc) Server Assigned DNS
From: Ben Tyger (vh.net staff) <bct@vh.net>
Date: 1999-09-08 18:10:09

We are running a Port Master 2e, Total Control Netserver 16 v.34, and NETServer 16 - I Modem Plus. We are running it with 3.3.3 Livingston code. I am interested in running server assigned DNS. Is this possible? If so what changes to I have to do. -- Ben Tyger Virtual Horizons, Inc. technical staff Home Page: www.vh.net Tech email: support@vh.net

Subject: (usr-tc) cisco vs tc
From: eric@dol.net
Date: 1999-09-08 19:04:29

How does the Cisco remote access servers compare to the TC with regards to customer satisfaction and connect speeds for those who have experience with both products? Most of the discussions here have been on the Ascend vs TC. We wanted to evaluate the current cisco solution as well. At what stage in the life cycle is the Cisco product at? thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: Re: (usr-tc) simultanious
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-09 07:13:00

Steve, Maybe Jim can do this. However for me it happens so infrequently that I can't affored to leave debug running and creating huge log files. I am not sure if it related to the version of HiPerArc code we are running or not. For the record we are on 4.1.64 (due to 4.1.56 killing off our WebRamp customers). Jeff Binkley ASA Network Computing u>If you enable debug on the servers and watch for the last received u>packet, is it the same on more than one server? What was the u>authentication type- pap/chap/ms-chap? u> STeve u>jlf@montrose-colo.com (Jim Faulkner) on 09/07/99 12:46:23 PM u>Please respond to usr-tc@lists.xmission.com u>Sent by: jlf@montrose-colo.com (Jim Faulkner) u>To: usr-tc@lists.xmission.com u>cc: (Steve Valiunas/MW/US/3Com) u>Subject: (usr-tc) simultanious radius crashes u>Hello, u>I have TC security and accounting version 5.5.3 running on three NT u>systems. When one crashes the other 2 follow suit. It used to happen a u>couple times a year now it's been 6 times in three days. Any Ideas? u>Thanks, u>Jim Faulkner u>GWE.NET u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

Subject: (usr-tc) Soundblaster Modems
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-09 07:13:00

Is anyone else haviong problems with Soundblaster modems and their TC hubs ? We've had 2 customers so far with them that we've had major problems with. One customer we lost because they never were able to get the modem to train with our TC hub and the other experiences frequent disconnects. In both cases they never got into V.90 territory (i.e. 26.4 - 31.2kbs). We've had the one with the frequent disconnects download the latest modem software from their website to no avail. Anyone else seen the same thing ? Folks are buying these based on name and low price. For our TC we are running both Quads and DSPs and we've seen it happen on both. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: RE: (usr-tc) preventing netserver crash
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-09 09:31:29

I've had the same thing in the past. Isolated to one unit. Various uptime from 48 hours to like 17 days, then crashola. Things I would suggest: 1. try different memory in it. You have 16-20mb in it, right? 2. you have a spare Netserver? Good idea to keep one around. Swap it out and see if the problem goes away. You can pick one up for ~$700. In fact I have several to sell even. 3. Still a problem? Try swapping out the chassis. 4. Still a problem? Try a different dual-T1 card 5. Give up, get a day job :^) Clues: 1. Happen under load? 2. Consistently happen after a certain amount of time? Anaway, that's the process I've gone through several times before (1-4 anyway). Each of the above has at one time or the other solved a "netserver" problem for me. SMT -----Original Message----- Sent: Thursday, September 09, 1999 9:13 AM Hello, I am using a TC with a Netserver (standart packet bus circuit) code 3.8.71. I never got an uptime over a week, using it only for PPP dialin purposes. Anyone has an idea of what I should track down to isolate and resolve this quite annoying problem? 3Com once went to see the crash dump, but did nothing with it.. And latest updates to Netserver code turn quite old, when you look at all the releases for Hiper stuff. I was said it is still supported.. where? TIA, Martin - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) preventing netserver crash
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1999-09-09 10:12:34

Hello, I am using a TC with a Netserver (standart packet bus circuit) code 3.8.71. I never got an uptime over a week, using it only for PPP dialin purposes. Anyone has an idea of what I should track down to isolate and resolve this quite annoying problem? 3Com once went to see the crash dump, but did nothing with it.. And latest updates to Netserver code turn quite old, when you look at all the releases for Hiper stuff. I was said it is still supported.. where? TIA, Martin

Subject: (usr-tc) Static IPs with large dialin pools
From: Christopher Arlis Hanes <chanes@inetconn.net>
Date: 1999-09-09 10:13:47

How does one handle static IPs when the pools used by a particular dialin number span multiple class Cs? (i.e. a user dialing in has the possibility of of dialing into a box whose router card is not on the same network as the user's static IP.) Thanks, Chris Hanes

Subject: Re: (usr-tc) preventing netserver crash
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-09 10:25:17

Thus spake Martin Lathoud >I am using a TC with a Netserver (standart packet bus circuit) code >3.8.71. I never got an uptime over a week, using it only for PPP dialin >purposes. Anyone has an idea of what I should track down to isolate and >resolve this quite annoying problem? 3Com once went to see the crash dump, >but did nothing with it.. And latest updates to Netserver code turn quite >old, when you look at all the releases for Hiper stuff. I was said it is >still supported.. where? The NETServers are supported in hardware only. Attribute that to 3Com's lame-brained decision to not port the pilgrim code to the NETServer hardware. The NETServer code was based on the ComOS code from Livingston (now a part of Lucent and basically killed off), when the licensing ran out, 3Com basically just chopped any support for it. Lovely customer service there. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) preventing netserver crash
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-09 11:35:14

We used to have a bunch of netservers that crashed regularly. Older hardware revs had problems with crashing. USR (3Com now) had an engineering change which appeared to clear up the problem. At 09:31 AM 9/9/99 -0500, you wrote: >I've had the same thing in the past. Isolated to one unit. Various uptime >from 48 hours to like 17 days, then crashola. > >Things I would suggest: > >1. try different memory in it. You have 16-20mb in it, right? >2. you have a spare Netserver? Good idea to keep one around. Swap it out >and see if the problem goes away. You can pick one up for ~$700. In fact >I have several to sell even. >3. Still a problem? Try swapping out the chassis. >4. Still a problem? Try a different dual-T1 card >5. Give up, get a day job :^) > >Clues: > >1. Happen under load? >2. Consistently happen after a certain amount of time? > >Anaway, that's the process I've gone through several times before (1-4 >anyway). >Each of the above has at one time or the other solved a "netserver" problem >for me. > >SMT > > >-----Original Message----- >From: Martin Lathoud [mailto:nytral@enDirect.qc.ca] >Sent: Thursday, September 09, 1999 9:13 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) preventing netserver crash > > >Hello, >I am using a TC with a Netserver (standart packet bus circuit) code >3.8.71. I never got an uptime over a week, using it only for PPP dialin >purposes. Anyone has an idea of what I should track down to isolate and >resolve this quite annoying problem? 3Com once went to see the crash dump, >but did nothing with it.. And latest updates to Netserver code turn quite >old, when you look at all the releases for Hiper stuff. I was said it is >still supported.. where? > >TIA, >Martin > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Quad card refurbishing
From: CyberPort Montana <netboss@cyberport.net>
Date: 1999-09-09 13:26:24

I'll second that. I have a number of cards that also need repairs. Gary At 03:23 PM 9/9/99 -0400, you wrote: >Does anyone refurbish USR Quad cards? I have 4 cards with bad modems on them. > >Internet Connections >jsinger@i-c.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: RE: (usr-tc) preventing netserver crash
From: Brian Elfert <brian@citilink.com>
Date: 1999-09-09 13:33:42

On Thu, 9 Sep 1999, Martin Lathoud wrote: > The chassis is less than 1.5 years old.. I would have expected to get an > Netserver enhanced packet circuit version.. I've been told that it > depended on stock availability, and that it's not meaning much.. As far as > I can see, uptime is not 3Com priority :(. Since I only own one Netserver Just because your chassis reboots, that doesn't necessarily mean it's a widespread problem. My 5 Netserver cards have never rebooted even once that I remember, and I've had them for at least 1.5 years. Brian

Subject: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: William Brien <william_brien@mw.3com.com>
Date: 1999-09-09 13:36:43

3Com Customers, 3Com would like to announce the release of HiPerARC v4.2.32-1 on the TotalService website at: http://totalservice.3com.com/ The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This version has fixes for the upgrade issues from v4.1.59-6, HiperBomb DoS (Denial of Service) attack, and SNMP security issues. If you are using HiPerARC v4.2.29 on your Total Control chassis at this time, you are advised to upgrade to v4.2.32-1 as soon as possible. Download of this code requires a valid service contract. If you would like to purchase a service contract, please contact your local reseller of 3Com services for more information. To locate your local Value Added Reseller, as well as 3Com sales offices, please go to: http://www.3com.com/products/shop/where2buy_2.html If there are any questions or concerns regarding this release, please contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an area not handled by this number, the TotalService website has contact information for other countries and regions. Please go to the TotalService website and click on 'Contacting Tech Support' for more information. The Software Compatibility Matrix on TotalService will be updated later this week to reflect compatibility with other releases of code. Thank you, Chuck Stace and Will Brien Customer Service Product Planning Chuck_Stace@3com.com William_Brien@3com.com

Subject: RE: (usr-tc) preventing netserver crash
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1999-09-09 13:54:04

The chassis is less than 1.5 years old.. I would have expected to get an Netserver enhanced packet circuit version.. I've been told that it depended on stock availability, and that it's not meaning much.. As far as I can see, uptime is not 3Com priority :(. Since I only own one Netserver (except modem code *!*, PM3 is the way to go), no way to do swap tests.. I'd better purchase a new spare NS card (cheaper than renewing the contract support). For the clues: reboot is purely random but always above a couple of days, usage is often >40 ports (not only at crash time) Later, Martin On Thu, 9 Sep 1999, Clayton Zekelman wrote: > We used to have a bunch of netservers that crashed regularly. Older > hardware revs had > problems with crashing. USR (3Com now) had an engineering change which > appeared to clear up the problem. > > At 09:31 AM 9/9/99 -0500, you wrote: > >I've had the same thing in the past. Isolated to one unit. Various uptime > >from 48 hours to like 17 days, then crashola. > > > >Things I would suggest: > > > >1. try different memory in it. You have 16-20mb in it, right? > >2. you have a spare Netserver? Good idea to keep one around. Swap it out > >and see if the problem goes away. You can pick one up for ~$700. In fact > >I have several to sell even. > >3. Still a problem? Try swapping out the chassis. > >4. Still a problem? Try a different dual-T1 card > >5. Give up, get a day job :^) > > > >Clues: > > > >1. Happen under load? > >2. Consistently happen after a certain amount of time? > > > >Anaway, that's the process I've gone through several times before (1-4 > >anyway). > >Each of the above has at one time or the other solved a "netserver" problem > >for me. > > > >SMT

Subject: (usr-tc) Rockwell HCF 56k v.90
From: Levent Cosan <levent21@netzero.net>
Date: 1999-09-09 14:03:05

This is a multi-part message in MIME format. ------=_NextPart_000_0005_01BEFACC.0A10D420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I have a HP computer and the modem is a Rockwell HCF 56k v.90 = speakerphone pci modem. The modem dials out but it doesn't do the = "handshake". I had the modem replaced but i still run into problems = with the new modem. I usually get a, "no answer" or a "modem doesn't = carrier a signal". I've tried numerous ISPs but i get the same error = message. Any help will be appreciated ------=_NextPart_000_0005_01BEFACC.0A10D420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#b8b8b8> <DIV><FONT size=3D2>Hi, </FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>I have a HP computer and the modem is a Rockwell HCF = 56k v.90=20 speakerphone pci modem.  The modem dials out but it doesn't do the=20 "handshake".  I had the modem replaced but i still run into = problems with=20 the new modem.  I usually get a, "no answer" or a "modem doesn't = carrier a=20 signal".  I've tried numerous ISPs but i get the same error = message. =20 Any help will be appreciated</FONT></DIV></BODY></HTML> ------=_NextPart_000_0005_01BEFACC.0A10D420-- ________________________________________________________ NetZero - We believe in a FREE Internet. Shouldn't you? Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html

Subject: RE: (usr-tc) preventing netserver crash
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-09 14:55:33

When we were running Netserver, we had around 25 units installed, and more than 3/4 of them were rock solid and reliable. The remaining units were flaky. At 01:33 PM 9/9/99 -0500, you wrote: > > >On Thu, 9 Sep 1999, Martin Lathoud wrote: > >> The chassis is less than 1.5 years old.. I would have expected to get an >> Netserver enhanced packet circuit version.. I've been told that it >> depended on stock availability, and that it's not meaning much.. As far as >> I can see, uptime is not 3Com priority :(. Since I only own one Netserver > >Just because your chassis reboots, that doesn't necessarily mean it's a >widespread problem. > >My 5 Netserver cards have never rebooted even once that I remember, and >I've had them for at least 1.5 years. > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Brian <signal@shreve.net>
Date: 1999-09-09 15:16:08

On Thu, 9 Sep 1999, Christopher Arlis Hanes wrote: > > How does one handle static IPs when the pools used by a particular > dialin number span multiple class Cs? (i.e. a user dialing in has the > possibility of of dialing into a box whose router card is not on the > same network as the user's static IP.) Static IP's do not have to be on the same "network" as their gateways. In other words, if you had a router that was 192.168.1.1, and a hiper ARC that was 192.168.5.1 and a static IP that was 208.242.79.4, that is perfectly fine. What *matters* is that you have established proper routing on your network. *generally* interface ip's for terminal servers and routing devices with ethernet interfaces are statically routed, perhaps you route a /28 or /27 to your ethernet for use by your terminal servers (arcs, netservers, etc). Dynamic IP pools are setup on these devices, and aggregates for these pools can be announced via ripv2 (or ospf on the newer arc code). Static IP's are also announced via ripv2 (or ospf).........so long as you have your interior routing protocol setup correctly, this is not a problem. > > Thanks, > Chris Hanes > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) Static IPs with large dialin pools
From: Christopher Arlis Hanes <chanes@inetconn.net>
Date: 1999-09-09 15:21:12

Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-09 15:22:50

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Lon R. Stockton, |Jr. |Sent: Thursday, September 09, 1999 3:05 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete) | | | |On Thu, 9 Sep 1999, William Brien wrote: | |> The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This |> version has fixes for the upgrade issues from v4.1.59-6, HiperBomb DoS (Denial |> of Service) attack, and SNMP security issues. If you are using |HiPerARC v4.2.29 |> on your Total Control chassis at this time, you are advised to upgrade to |> v4.2.32-1 as soon as possible. |> |> Download of this code requires a valid service contract. | | |Requiring service contracts to get fixes for well-known, easy to implement |exploits is certainlly a way to sell service contracts. This release is not intended as the fix for the security issues. It replaces 4.2.29, which is a feature enhancement. It does however have the security issues resolved. There will be a 4.1.x service release for the security issues and other resolved bugs shortly. This service release will be made available to everyone for 90 days, as was the previous service release. -M

Subject: Re: (usr-tc) Quad card refurbishing
From: Jack Singer <jsinger@aaacars.com>
Date: 1999-09-09 15:23:31

Does anyone refurbish USR Quad cards? I have 4 cards with bad modems on them. Internet Connections jsinger@i-c.net

Subject: (usr-tc) Static IPs with large dialin pools
From: Christopher Arlis Hanes <chanes@usacars.com>
Date: 1999-09-09 15:31:10

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-09 15:49:39

Thus spake Christopher Arlis Hanes >How does one handle static IPs when the pools used by a particular >dialin number span multiple class Cs? (i.e. a user dialing in has the >possibility of of dialing into a box whose router card is not on the >same network as the user's static IP.) RIPv2 enable ip rip and set ip network <blah> routing_protocol ripv2 should take care of the basics...you'll also need to turn on ripv2 on most of the rest of your network....at least as far up as it might change depending on which Arc they hit. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1999-09-09 16:04:33

On Thu, 9 Sep 1999, William Brien wrote: > The HiPerARC v4.2.32-1 Maintenance Release replaces HiPerARC v4.2.29. This > version has fixes for the upgrade issues from v4.1.59-6, HiperBomb DoS (Denial > of Service) attack, and SNMP security issues. If you are using HiPerARC v4.2.29 > on your Total Control chassis at this time, you are advised to upgrade to > v4.2.32-1 as soon as possible. > > Download of this code requires a valid service contract. Requiring service contracts to get fixes for well-known, easy to implement exploits is certainlly a way to sell service contracts. Before I purchased, I was told this was a 'best-of-breed' device. Now I find that I gotta pay a couple thousand more just to get it fixed so that any 14 year old with a program he got off a website can't crash it. Either that, or turn off features that I was told I'd have in the purchased product. The mafia might not exist, but looks like protection rackets are alive and well.

Subject: Re: (usr-tc) Soundblaster Modems
From: Greg owens <gowens@magnolia-net.com>
Date: 1999-09-09 19:57:14

Jeff...We have one customer (that we know of) that is experiencing very frequent disconnects. We thought at first a phone line issue but after 3 trips SWB says all their stuff is OK. No we have not found a fix for the problem and will probably lose customer very soon.... BTW we are running DSP's.....Any one else seeing this Greg Owens Magnolia Internet Services http://www.magnolia-net.com ----- Original Message ----- Sent: Thursday, September 09, 1999 7:13 AM > > > Is anyone else haviong problems with Soundblaster modems and their TC > hubs ? We've had 2 customers so far with them that we've had major > problems with. One customer we lost because they never were able to get > the modem to train with our TC hub and the other experiences frequent > disconnects. In both cases they never got into V.90 territory (i.e. > 26.4 - 31.2kbs). We've had the one with the frequent disconnects > download the latest modem software from their website to no avail. > Anyone else seen the same thing ? Folks are buying these based on name > and low price. For our TC we are running both Quads and DSPs and we've > seen it happen on both. > > > Jeff Binkley > ASA Network Computing > > CMPQwk 1.42 9999 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) [Fwd: Locating a bad HDSP port / Modems with 'highincomingconnections
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-10 09:38:09

Is anyone else working with USR on this problem? They had some testing code that reset the port after every call, that we decided not to use on our production modems. Is anyone else using this code and is it working? Also, thanks to **Eric Billeter** for writing the script we are running every day look for this automatically. Regards, Jim Jim Johnson wrote: > > David, > > How is the new modem code coming? We are having a problem about once > every two weeks. Haven't had one since last wednesday, and I am getting > worried.... > > Last week, we had two ports flake out at the beginning of the hunt > group. All hell broke loose around here as people called to complain. > :( > > Also, on another note, when will the modem code improve on the DSPs? We > are losing customers right now because they are having disconnect and > poor connect problems. Apparently, ISPs who use Ascend or PMs are > having much better success in connecting these clients. I would suggest > we quit worrying about the HiperARC code and work on the modem code > right now! > > Thanks, > > Jim Johnson > > David Bachta wrote: > > > > Hi Jim, > > > > Thanks for your reply. I'll be sure to drop you a note as soon as we have a > > released version of code to rectify the problem. > > > > Thank you for your comments regarding our support. I'm very sorry to hear your > > past experiences with our support team have been less than favorable. We have > > been striving to improve the quality of our support organization and I think we > > have made some great progress, especially in the last year. If you haven't done > > so already, you may want to check out some of our new support tools that don't > > require a service contract (3KB, ISP Home Page, Totalservice Field Reported > > Issues, 3Com Users forums, etc). > > > > Best Regards, > > David

Subject: (usr-tc) HiperARC Console yes/no
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-10 09:48:10

HiPer>> list chassis Slot Owner Description Ports Type Console 1 YES --EMPTY-- 0 STATIC NO 2 YES --EMPTY-- 0 STATIC NO 3 YES --EMPTY-- 0 STATIC NO 4 YES --EMPTY-- 0 STATIC NO 5 YES --EMPTY-- 0 STATIC NO 6 YES --EMPTY-- 0 STATIC NO 7 YES --EMPTY-- 0 STATIC NO 8 YES --EMPTY-- 0 STATIC NO 9 YES --EMPTY-- 0 STATIC NO 10 YES --EMPTY-- 0 STATIC NO 11 YES --EMPTY-- 0 STATIC NO 12 YES 24 Channel High Density Modem 24 DYNAMIC YES 13 YES 24 Channel High Density Modem 24 DYNAMIC NO 14 YES 24 Channel High Density Modem 24 DYNAMIC YES 15 YES 24 Channel High Density Modem 24 DYNAMIC NO #13, 15 weren't setup any different than #12, 14; it's all working just fine, I'm just curious why Console is "NO" on 13,15. And how does one use this "console" ability anyway??? SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-10 10:10:42

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Horace Demmink |Sent: Friday, September 10, 1999 9:57 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete) | | |On Thu, 9 Sep 1999, Mike Wronski wrote: | |> |Requiring service contracts to get fixes for well-known, easy to implement |> |exploits is certainlly a way to sell service contracts. |> |> This release is not intended as the fix for the security issues. It replaces |> 4.2.29, which is a feature enhancement. It does however have the |security issues |> resolved. |> |> There will be a 4.1.x service release for the security issues and |other resolved |> bugs shortly. This service release will be made available to everyone for 90 |> days, as was the previous service release. |> | |Will there be a 4.2.x service release to solve these issues that will be |made available to everyone? What issues? The 4.2.32-1 does resolve the security issues. (As stated above) -M

Subject: (usr-tc) HiPer Arc improvement thoughts...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-10 10:45:49

I mentioned earlier that I was going to email the list with some thoughts of where I thought the HiPer Arc platform could/should go... I have a little bit of time now, so maybe I can put some of these thoughts down and maybe get some thoughts and discussion from the rest of you about feasibility and maybe some other ideas...In any case...these ideas are thrown out to maybe get some discussion going to help give 3Com an idea of what we, as customers, would like to see out of the Arc. First off...a couple of specific feature requests...I may have mentioned these before....if so, my apologies. 1) Bridging support...both over PPP, and over ethernet interfaces, and any other interfaces that are supported (such as the new frame-relay ones). Imagine plugging your two ethernet interfaces into two different switches in the same IP network...running spanning-tree between them all...then your Arc isn't dependant on its switch being in one piece to be able to communicate. Would require the use of a "virtual" interface that participated in the bridging code as well...similar in some ways to the internal interface that is available for use with OSPF now. Basically, assign the IP address for the Arc to the virtual interface, the Arc sends packets to the virtual interface, when then goes into the bridging code to decide which physical interface its sent out. This is very similar to Cisco's bridge-groups with their integrated routing and bridging for those of you who are familiar with that. 2) Support for a "packet bus interface". This one sounds bizarre...but if you think about it for a bit it starts to make sense...if you have multiple Arc's in a chassis...why make them communicate out their NIC's onto an external network to talk to each other? Some benefits for this... With the first feature....you could have two Arcs, both running briding code as well...each with a single ethernet+4t1 NIC and support 8 frame-relay t1's, and still retain the dual-exit capability described above with briding or routing over the packet bus. You could also theoretically have an Arc handling modems that has no NIC at all! Modem interfaces come in over the packet bus, and that same data is then shipped back out over the packet bus interface to another Arc with NIC card. This method could also be used as a failover scenario if a NIC card failed, or a cable failed, or a switch failed...you get the idea. 3) A larger variety of NIC interfaces. Particularly combined with the packet bus interface, this frees you up to have a much greater variety of NIC types...the Arc can then use the packet bus interface to get out to the ethernet network (via another Arc most likely...either bridged or routed), and allowing...oh....8 t1 NICs, or maybe a t3 nic, a channelized t3 nic would be really sweet...the sky is the limit here once you get the arcs using the packet bus as their ethernet interface... 4) Similar to 3...the DSP cards have a crap-load of processing power in them...could they be used for something more than just modems? It seems...if you look at it in the abstract...that the DSP cards are essentially interface extensions for the Arcs...let's take that farther....this would mean basically totally revamping the code for the DSP's for the new uses, or perhaps coming out with new code that's more generalized. Then, with the possibility of new NICs for the DSP's you could, again, extend the interface possibilities for the Arcs. 5) One that has bugged me for quite some time...PPP support on WAN ports. I really don't particularly liked being restricted to frame-relay encapsulation only...I can deal with it...but it'd be nice to have the option of PPP encap as well. Many low end t1 routers don't have frame-relay encap support, and it would be nice to be able to interoperate with them. In more abstract terms...I've been told by several 3Com folks that they see the Pilgrim/Hiper Arc code as more full routing code rather than just code for an Access Server. My understanding is that 3Com is moving *all* of their routing products to eventually use the Pilgrim based code. With that thought in mind though...3Com seems (from a customer's perspective) to still think of the HiPer Arc, specifically, as an access server alone. I think the HiPer Arc and the Total Control platform as a whole could become a quite capable router chassis product as a whole. Personally speaking...I'd like to see that. In a similar vein...3Com seems to think of the DSP cards as big powerful modem cards...and while that's certainly a good use for them...let's break that paradigm (oh man...a marketing cliche'...my apologies) and see them for more than that...what they really are...a crapload of processing power on a card that could theoretically, to the best of my knowledge, run just about any arbitrary code with just about any arbitrary type of interface on the NIC. That's a *very* powerful thought IMO. Executive summary (I know, this should be at the top)...if you think of the Total Control platform basically as a distributed processing router platform...lot's of possibilities are opened up going forward. The current code on there is getting to be pretty good and solid...but its designed and written for a single specific function...limiting the places where the TC platform could be used. This largely comes down to be a business decision from 3Com (Lord help us there), but if they decide that they don't want to limit the TC platform to being *only* an access server (and personally, I think the distinction between access server and router is a pretty thin line), then they need to start thinking of the Arc as a router, not just an access server, and the DSP's as generic interface cards, not modem/t1/pri cards. These thoughts are probably not articulated very well...they're just thoughts that I've had in the back of my head for a while that I want to get out to some other people to see what you all have to say about the ideas. I know some people wouldn't be interested in all at using some of the features...but what I'm trying to get at here is the overall direction for development of the Arcs/TC's, not specific feature requests...although I have included some specific feature requests in my message...try not to focus on those specifically...they are mostly there as examples for the overall direction I was thinking of. Some of these thoughts have been expressed in the past to some people at 3Com, but I don't think any one person has ever heard the totality of what I was thinking of (not having had time to sit down with anyone for long enough time to fully hash these thoughts out). So...there it is...let's hear what you think. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: Horace Demmink <horace@pathwaynet.com>
Date: 1999-09-10 10:57:25

On Thu, 9 Sep 1999, Mike Wronski wrote: > |Requiring service contracts to get fixes for well-known, easy to implement > |exploits is certainlly a way to sell service contracts. > > This release is not intended as the fix for the security issues. It replaces > 4.2.29, which is a feature enhancement. It does however have the security issues > resolved. > > There will be a 4.1.x service release for the security issues and other resolved > bugs shortly. This service release will be made available to everyone for 90 > days, as was the previous service release. > Will there be a 4.2.x service release to solve these issues that will be made available to everyone? -- Horace Demmink PathWay Computing

Subject: Re: (usr-tc) Soundblaster Modems
From: Brett Murphy <me@murf.net>
Date: 1999-09-10 11:05:14

It amazes me that modem manufacturors whos product only works with a subset of digital access servers considers this to be "OK" All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. -----Original Message----- >Jeff...We have one customer (that we know of) that is experiencing very >frequent disconnects. We thought at first a phone line issue but after 3 >trips SWB says all their stuff is OK. No we have not found a fix for the >problem and will probably lose customer very soon.... BTW we are running >DSP's.....Any one else seeing this >Greg Owens >Magnolia Internet Services >http://www.magnolia-net.com >----- Original Message ----- >From: Jeff Binkley <jeff.binkley@asacomp.com> >To: <usr-tc@lists.xmission.com> >Sent: Thursday, September 09, 1999 7:13 AM >Subject: (usr-tc) Soundblaster Modems > > >> >> >> Is anyone else haviong problems with Soundblaster modems and their TC >> hubs ? We've had 2 customers so far with them that we've had major >> problems with. One customer we lost because they never were able to get >> the modem to train with our TC hub and the other experiences frequent >> disconnects. In both cases they never got into V.90 territory (i.e. >> 26.4 - 31.2kbs). We've had the one with the frequent disconnects >> download the latest modem software from their website to no avail. >> Anyone else seen the same thing ? Folks are buying these based on name >> and low price. For our TC we are running both Quads and DSPs and we've >> seen it happen on both. >> >> >> Jeff Binkley >> ASA Network Computing >> >> CMPQwk 1.42 9999 >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Sawin for Windows silently died?
From: Marcelo Barros <thbarros@ntwxpress.com.br>
Date: 1999-09-10 11:39:14

The correct part number is: USR 000950-07 At 16:19 9/10/99 +0200, you wrote: >Hi >When I went through the latest 3Com price list I could no longer find >the Security and Accounting Server for Windows. Did anybody of you >receive information about this product beeing discontinued? > >Thanks. > >Ralph > > >-- >========================================================================== >R. Helfenberger Internet r.helfenberger@comlight.ch >Comlight AG Tel +41 31 740 40 40 >Industriestr. 17 Fax +41 31 740 40 90 >3178 Boesingen >Switzerland www.comlight.ch >========================================================================== > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-10 12:11:48

On Fri, 10 Sep 1999, Mike Wronski wrote: > What issues? The 4.2.32-1 does resolve the security issues. (As stated above) It doesn't, however, seem to fix the serious problem with route aggregation I mentioned here twice. :( (quick summary: if ARC eth:1 is 10.1.1.0/25, and another router sends 10.1.1.0/23 via OSPF, it puts the /23 route in the routing table instead of the /25, and marks it 'local' instead of 'ospf'. Right route, wrong mask.) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) HiPer Arc improvement thoughts...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-10 12:43:18

Thus spake Brett Murphy >>4) Similar to 3...the DSP cards have a crap-load of processing power in >>them...could they be used for something more than just modems? It >>seems...if you look at it in the abstract...that the DSP cards are >>essentially interface extensions for the Arcs...let's take that >>farther....this would mean basically totally revamping the code for the >>DSP's for the new uses, or perhaps coming out with new code that's more >>generalized. >seti@home !!!!!!!! Heh...well...really wasn't thinking along those lines, but it could really add to your work-unit totals if you did that though. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Need Some Quad Modems
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-09-10 13:01:59

Steve, Honestly, we get more requests for the an/dig than the digitals so I cant do it. we are selling the analog/digitals for $150 each currently. Thanks Steve, Andrew Shlensky **************************** PC Global, Inc. (602) 438-6200 office (NEW TEL NUMBER!) (602) 438-1119 fax (305) 216-8638 mobile New!e-mail my mobile http://www.nextel.com/paging URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! Leader in New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Friday, September 10, 1999 12:48 PM would you be interested in trading 12 analog/digitals of yours, for 12 digital modems of mine? No nics just the nacs. Let me know. At 01:57 PM 09/03/1999 -0700, you wrote: >I have about 25 in stock... about 8 NICS . These are the V.34 >analog/Digital. >We have been selling them at $175 each with a 90 day warranty > >We take all credit cards, > >Best Regards, >Andrew Shlensky >**************************** >PC Global, Inc. >(602) 438-6200 office (NEW TEL NUMBER!) >(602) 438-1119 fax >(305) 216-8638 mobile >New!e-mail my mobile http://www.nextel.com/paging >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >Leader in New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** >----- Original Message ----- >From: Greg Coffey <gcoffey@vcn.com> >To: <usr-tc@lists.xmission.com> >Sent: Friday, September 03, 1999 1:45 PM >Subject: (usr-tc) Need Some Quad Modems > > >I'm in the market for some digital quads. Email me if you have some to >sell. I could use 1-2 dozen of them. > > > >Thanks, Greg Coffey <gcoffey@vcn.com> >Visionary Communications V 307-234-5443 F 307-234-5446 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

Subject: Sorry (usr-tc) Need Some Quad Modems
From: Andrew:PC Global, Inc. <andrew@pcglobal.net>
Date: 1999-09-10 13:09:11

sorry about the post.. hit reply accidentially Have a good weekend USR-TC members! Andrew Shlensky **************************** PC Global, Inc. (602) 438-6200 office (NEW TEL NUMBER!) (602) 438-1119 fax (305) 216-8638 mobile New!e-mail my mobile http://www.nextel.com/paging URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! Leader in New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Friday, September 10, 1999 1:01 PM Steve, Honestly, we get more requests for the an/dig than the digitals so I cant do it. we are selling the analog/digitals for $150 each currently. Thanks Steve, Andrew Shlensky **************************** PC Global, Inc. (602) 438-6200 office (NEW TEL NUMBER!) (602) 438-1119 fax (305) 216-8638 mobile New!e-mail my mobile http://www.nextel.com/paging URL: http://www.pcglobal.net E-MAIL: andrew@pcglobal.net ICQ: 21219089 Computer Service Parts SpEciaLiSts! Leader in New/Used PCs,Laptops Communication & Networking,Monitors Printers, Hard Drives, Midrange/Mainframe. Hard to Get Parts. We buy and sell all types of GEAR- **************************** ----- Original Message ----- Sent: Friday, September 10, 1999 12:48 PM would you be interested in trading 12 analog/digitals of yours, for 12 digital modems of mine? No nics just the nacs. Let me know. At 01:57 PM 09/03/1999 -0700, you wrote: >I have about 25 in stock... about 8 NICS . These are the V.34 >analog/Digital. >We have been selling them at $175 each with a 90 day warranty > >We take all credit cards, > >Best Regards, >Andrew Shlensky >**************************** >PC Global, Inc. >(602) 438-6200 office (NEW TEL NUMBER!) >(602) 438-1119 fax >(305) 216-8638 mobile >New!e-mail my mobile http://www.nextel.com/paging >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >Leader in New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** >----- Original Message ----- >From: Greg Coffey <gcoffey@vcn.com> >To: <usr-tc@lists.xmission.com> >Sent: Friday, September 03, 1999 1:45 PM >Subject: (usr-tc) Need Some Quad Modems > > >I'm in the market for some digital quads. Email me if you have some to >sell. I could use 1-2 dozen of them. > > > >Thanks, Greg Coffey <gcoffey@vcn.com> >Visionary Communications V 307-234-5443 F 307-234-5446 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

Subject: RE: (usr-tc) HiperARC Console yes/no
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-10 13:24:40

You can set up a reverse telnet type service through the arc using these console interfaces so that you can telnet to the DSP consoles. On Friday, September 10, 1999 11:48 AM, Scott Trautman [SMTP:scottt@corp.gdinet.com] wrote: > HiPer>> list chassis > Slot Owner Description Ports Type > Console > 1 YES --EMPTY-- 0 STATIC NO > 2 YES --EMPTY-- 0 STATIC NO > 3 YES --EMPTY-- 0 STATIC NO > 4 YES --EMPTY-- 0 STATIC NO > 5 YES --EMPTY-- 0 STATIC NO > 6 YES --EMPTY-- 0 STATIC NO > 7 YES --EMPTY-- 0 STATIC NO > 8 YES --EMPTY-- 0 STATIC NO > 9 YES --EMPTY-- 0 STATIC NO > 10 YES --EMPTY-- 0 STATIC NO > 11 YES --EMPTY-- 0 STATIC NO > 12 YES 24 Channel High Density Modem 24 DYNAMIC YES > 13 YES 24 Channel High Density Modem 24 DYNAMIC NO > 14 YES 24 Channel High Density Modem 24 DYNAMIC YES > 15 YES 24 Channel High Density Modem 24 DYNAMIC NO > > #13, 15 weren't setup any different than #12, 14; it's all working just > fine, I'm just curious why Console is "NO" on 13,15. And how does one use > this "console" ability anyway??? > > SMT > > > Scott Trautman 608-240-4638,4637fax > Global Dialog Internet www.gdinet.com > 2810 Crossroads, STE LL2 > Madison WI 53718 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-09-10 14:51:01

Chris: An easy way to accomplish what Brian has suggested would be to set your routing protocol: set ip network [network name] routing_protocol [NONE-default, ripv1, or ripv2] enable ip rip enable ip proxy_arp_all_dialin save all Ripv2 is recommended since it will allow for split horizon and poison reverse (more efficient routing). After a protocol is set, you will still need to enable rip. You will also need to enable proxy arp. This will allow the Hiper Arc can act as a proxy agent, and inform the router about the ip addresses of clients that have been given addresses. The Harc will then accept these return packets from your router, and send them to the correct client. Hope this helps. Todd ;-} Brian <signal@shreve.net> on 09/09/99 03:16:08 PM Please respond to usr-tc@lists.xmission.com Sent by: Brian <signal@shreve.net> cc: (Todd Keister/MW/US/3Com) On Thu, 9 Sep 1999, Christopher Arlis Hanes wrote: > > How does one handle static IPs when the pools used by a particular > dialin number span multiple class Cs? (i.e. a user dialing in has the > possibility of of dialing into a box whose router card is not on the > same network as the user's static IP.) Static IP's do not have to be on the same "network" as their gateways. In other words, if you had a router that was 192.168.1.1, and a hiper ARC that was 192.168.5.1 and a static IP that was 208.242.79.4, that is perfectly fine. What *matters* is that you have established proper routing on your network. *generally* interface ip's for terminal servers and routing devices with ethernet interfaces are statically routed, perhaps you route a /28 or /27 to your ethernet for use by your terminal servers (arcs, netservers, etc). Dynamic IP pools are setup on these devices, and aggregates for these pools can be announced via ripv2 (or ospf on the newer arc code). Static IP's are also announced via ripv2 (or ospf).........so long as you have your interior routing protocol setup correctly, this is not a problem. > > Thanks, > Chris Hanes > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Managing a Total Control Chassis
From: Chris Ashcraft <chris_ashcraft@mw.3com.com>
Date: 1999-09-10 15:05:05

3Com is interested in how you manage the Total Control chassis. To help us better serve you, please complete the brief section below and reply to this email with your response. ================================================================================= 1. Simply rate the following Total Control management tools (1=used most; 3=used least) _ MIB browser (please indicate the software package you are using: NerveCenter, CMU SNMP, UCD-SNMP, SNMPc, HP OpenView, other:___________) _ Total Control Manager/HiPer ARC Manager _ Terminal emulation (e.g., Telnet or HyperTerminal) 2. Do you manage the various Total Control cards differently? If so, please list which of the above management tools you most often use for: - Quad Modem:___________________ - Trunk Cards:___________________ - HiPer DSP:___________________ - HiPer ARC:___________________ - EdgeServer Cards:___________________ ================================================================================= Any other comments or suggestions are welcome. Thank you for your time. Carrier Systems Group 3Com Corp.

Subject: Re: (usr-tc) Need Some Quad Modems
From: Steve Rivera <sales@wrca.net>
Date: 1999-09-10 15:48:24

would you be interested in trading 12 analog/digitals of yours, for 12 digital modems of mine? No nics just the nacs. Let me know. At 01:57 PM 09/03/1999 -0700, you wrote: >I have about 25 in stock... about 8 NICS . These are the V.34 >analog/Digital. >We have been selling them at $175 each with a 90 day warranty > >We take all credit cards, > >Best Regards, >Andrew Shlensky >**************************** >PC Global, Inc. >(602) 438-6200 office (NEW TEL NUMBER!) >(602) 438-1119 fax >(305) 216-8638 mobile >New!e-mail my mobile http://www.nextel.com/paging >URL: http://www.pcglobal.net >E-MAIL: andrew@pcglobal.net >ICQ: 21219089 >Computer Service Parts SpEciaLiSts! >Leader in New/Used PCs,Laptops >Communication & Networking,Monitors >Printers, Hard Drives, Midrange/Mainframe. >Hard to Get Parts. We buy and sell all >types of GEAR- >**************************** >----- Original Message ----- >From: Greg Coffey <gcoffey@vcn.com> >To: <usr-tc@lists.xmission.com> >Sent: Friday, September 03, 1999 1:45 PM >Subject: (usr-tc) Need Some Quad Modems > > >I'm in the market for some digital quads. Email me if you have some to >sell. I could use 1-2 dozen of them. > > > >Thanks, Greg Coffey <gcoffey@vcn.com> >Visionary Communications V 307-234-5443 F 307-234-5446 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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. >

Subject: (usr-tc) Sawin for Windows silently died?
From: Ralph Helfenberger <r.helfenberger@comlight.ch>
Date: 1999-09-10 16:19:11

Hi When I went through the latest 3Com price list I could no longer find the Security and Accounting Server for Windows. Did anybody of you receive information about this product beeing discontinued? Thanks. Ralph -- ========================================================================== R. Helfenberger Internet r.helfenberger@comlight.ch Comlight AG Tel +41 31 740 40 40 Industriestr. 17 Fax +41 31 740 40 90 3178 Boesingen Switzerland www.comlight.ch ==========================================================================

Subject: RE: (usr-tc) NOTICE - HiPerARC v4.2.32-1 (posting complete)
From: Horace Demmink <horace@pathwaynet.com>
Date: 1999-09-10 16:31:21

On Fri, 10 Sep 1999, Mike Wronski wrote: > |> There will be a 4.1.x service release for the security issues and > |other resolved > |> bugs shortly. This service release will be made available to everyone for 90 > |> days, as was the previous service release. > |> > | > |Will there be a 4.2.x service release to solve these issues that will be > |made available to everyone? > > What issues? The 4.2.32-1 does resolve the security issues. (As stated above) > Yes, but it is not publicly available. For example, my service contract recently expired, leaving me with the 4.2.29 version. I need OSPF, but also would like the critical bugs fixed. I guess it is a moot point as I just registered another chassis. But what are you supposed to do if you do not feel like cheating the system and are in the same boat? -- Horace Demmink PathWay Computing

Subject: (usr-tc) PRI vs. C-T1
From: T.J. Weber <tjw-pop@ipmedia.net>
Date: 1999-09-10 19:01:40

We currently have several C-T1's and were wondering what the advantages (disadvantages?) were for MX DID (Multi-Exchange, Direct Inbound Dialing) lines were? I know that a C-T1 can only support ISDN DOV connections (vs. true 64k BRI connections), but what other features or advantages does a PRI have over a C-T1? The telco we are using has a C5 switch for each exchange they provide to us and all calling features should be enabled. Thanks, --t.j.

Subject: (usr-tc) Farewell!
From: D Mayer <dmayer@netwalk.com>
Date: 1999-09-10 19:51:21

I've been on this list for close to two years, but now I'm leaving the consumer level ISP biz to work in the R&D division at UUNET! I just wanted to thank everbody who ever responded to my questions, and wish you all the best of luck with your TC systems. This list has been 100 times better support than 3Com could ever give. Thanks! Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: Re: (usr-tc) preventing netserver crash
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-10 20:37:02

Thus spake Bob Purdon (Lists) >> Just because your chassis reboots, that doesn't necessarily mean it's >> a widespread problem. >May well be - there is a revision of the NETserver that hates ISDN - >reboots almost daily. I *think* it's the release with the 'FC3' revision >IC on it. From memory, 'FC2' runs fine... Ah, yes...the infamous fc3 chip...didn't reboot the system...didn't even lock it up...just froze the ethernet interface. If you had console access...or !root dialup access, you could still login and do stuff locally...just couldn't do anything with the ethernet. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPer Arc improvement thoughts...
From: Brett Murphy <me@murf.net>
Date: 1999-09-11 01:44:33

>4) Similar to 3...the DSP cards have a crap-load of processing power in >them...could they be used for something more than just modems? It >seems...if you look at it in the abstract...that the DSP cards are >essentially interface extensions for the Arcs...let's take that >farther....this would mean basically totally revamping the code for the >DSP's for the new uses, or perhaps coming out with new code that's more >generalized. seti@home !!!!!!!! All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

Subject: RE: (usr-tc) preventing netserver crash
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-09-11 09:58:45

> Just because your chassis reboots, that doesn't necessarily mean it's > a widespread problem. May well be - there is a revision of the NETserver that hates ISDN - reboots almost daily. I *think* it's the release with the 'FC3' revision IC on it. From memory, 'FC2' runs fine... Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Subject: Re: (usr-tc) preventing netserver crash
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-09-11 10:48:42

> Ah, yes...the infamous fc3 chip...didn't reboot the system...didn't > even lock it up...just froze the ethernet interface. If you had > console access...or !root dialup access, you could still login and do > stuff locally...just couldn't do anything with the ethernet. Hmmm, ours rebooted. When replaced with an FC2 based NETserver, the reboots went away. We don't do ISDN on these boxes these days anyway, so it's a non-event, but still... Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Subject: RE: (usr-tc) preventing netserver crash
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-11 11:33:34

Exactly right. All our FC3 rev IC Netservers rebooted, and the FC2's didn't. Sometimes you have to peel back the sticker to read the chip rev... At 09:58 AM 9/11/99 +1000, you wrote: > >> Just because your chassis reboots, that doesn't necessarily mean it's >> a widespread problem. > >May well be - there is a revision of the NETserver that hates ISDN - >reboots almost daily. I *think* it's the release with the 'FC3' revision >IC on it. From memory, 'FC2' runs fine... > >------------------------------------------------------------------------ >Bob Purdon, Ground Floor, Marine Board Building >Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 >Southern Internet Services. +61 (3) 6234 7444 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) any way to hang up a user on a hiper arc?
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-13 04:10:36

Short of writing an expect script to telnet into the arc, is there any way via SNMP (or radius) to hang up a user on the arc? I already know how to do this via hanging up the modem, but was looking for a way to do it on the arc itself. thx, -- Aaron Nabil

Subject: (usr-tc) Unique problem - Just changed backbones...
From: John Campbell <sparky@roava.net>
Date: 1999-09-13 07:25:08

I have a unique problem, I just changed backbone providers, got everything changed over.. I have verified all of my DNS numbers and everything.. However, even though most users are navigating and seeing things correctly, other users are ping resolved to the old IP addresses of our old class C for our web and mail servers. IP numbers work just fine, and it is not the same on all users. Any ideas on this... Any help would be appreaciated. John Campbell mailto:sparky@roava.net http://www.roava.net

Subject: (usr-tc) 4.2.32 and MLPPP broke on freebsd
From: d baud <dbaud@bigfoot.com>
Date: 1999-09-13 10:53:44

I just noticed that after upgrading to 4.2.32 the user implementation of PPP on freebsd would not connect any more than one PPP link. I flashed back to 4.2.29 (or any previous 4.1.xx) and the problem disapears. This issue only seem to happen with freebsd's PPP. I noticed that cisco routers connects flawlessly, I also managed to connect a netserver 8i to 4.2.32 in MLPPP I know this is probably not a problem relating to this upgrade, but I am just curious on what setting have changed in this version ? I am including a PPP log for the second PPP link that tries to connect from a freebsd PPP system. The link gets disconnected immediately after receiving an ACK from Hiper4.2.32 HiPer>> sho system SYSTEM DESCRIPTION System Descriptor: 3Com Corporation HiPer Access Router Card Built on Aug 16 1999 at 17:19: 37. Object ID: 1.3.6.1.4.1.429.2.19 System UpTime: 2d 20:43:37 System Services: Internet EndToEnd Applications System Transmit Authentication Name: HiPer System Version: V4.2.32 Reset EEPROM Settings On Bootup: DISABLED Outgoing PPP Data on interface: slot:7/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM f4 3e 57 1e PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 LCP CFG_REQ ASYNC_MAP 00 00 00 00 MRU 05 dc MAGIC_NUM 68 ba c0 da MPP_MRRU 05 dc Outgoing PPP Data on interface: slot:7/mod:4 LCP CFG_ACK ASYNC_MAP 00 00 00 00 MRU 05 dc MAGIC_NUM 68 ba c0 da MPP_MRRU 05 dc Outgoing PPP Data on interface: slot:7/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM f4 3e 57 1e PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:7/mod:4 LCP CFG_REJ PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:7/mod:4 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM f4 3e 57 1e MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:7/mod:4 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM f4 3e 57 1e MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:7/mod:4 PAP REQUEST USERNAME = pppuser PASSWORD = ppppasse Outgoing PPP Data on interface: slot:7/mod:4 PAP ACK

Subject: (usr-tc) Seeing DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-13 14:27:06

I just installed a new DSP but the PRI isn't hooked into it yet. Getting; HiPer>> list chassis Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 YES --EMPTY-- 0 STATIC NO 4 YES --EMPTY-- 0 STATIC NO 5 YES --EMPTY-- 0 STATIC NO How do I get the ARC to recognize the new card(slot 3)? Is it possible w/o rebooting? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) Problems with NI2 and NFAS
From: Christopher Arlis Hanes <chanes@usacars.com>
Date: 1999-09-13 14:41:23

Is there anyone out there using NFAS to support 2 PRIs through a single D channel on the dual pri cards. I've had no luck getting this to work yet. From a configuration standpoint things look correct - 23B+1D on the first span and 24B on the second; however, when I dial in, I get fast busies. The telco techs have been on site and can dial in to their test equipment successfully on the new PRIs. My chassis works fine when I use old PRIs configured for dms100. When I change the switch settings to NI2, set the NFAS id, and plug up the new PRIs - nothing but fast busies. I'm running tcs 3.3 (i.e. 3.02 on the dual pri card). Any help would be GREATLY appreciated. Thanks, Chris Hanes

Subject: (usr-tc) Thanks to all who replied
From: John Campbell <sparky@roava.net>
Date: 1999-09-13 15:05:07

Found my problem with the help of this list... Thanks to everyone who sent me troubleshooting email. John Campbell mailto:sparky@roava.net http://www.roava.net

Subject: RE: (usr-tc) Seeing DSP
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-13 15:33:45

You definately need to Hardware-Reboot the card (IE, not "software reset) for the changes to take effect. SMT -----Original Message----- Sent: Monday, September 13, 1999 3:12 PM At 02:27 PM 9/13/99 -0400, I wrote: >I just installed a new DSP but the PRI isn't hooked into it yet. Getting; >HiPer>> list chassis >Slot Owner Description Ports Type Console >1 YES 24 Channel High Density Modem 23 DYNAMIC NO >2 YES 24 Channel High Density Modem 23 DYNAMIC NO >3 YES --EMPTY-- 0 STATIC NO >4 YES --EMPTY-- 0 STATIC NO >5 YES --EMPTY-- 0 STATIC NO > >How do I get the ARC to recognize the new card(slot 3)? Is it possible w/o >rebooting? Ok, I reseated the card and TCM sees it ok, but it still isn't apparently responding on the D channel. I loaded the config from one of my working cards and saved it, still no go. The only difference in them being that my other DSPs are running 1.2.60 and the new one is showing 2.0.81. Is there something different in 2.0.81 that I need to account for by a difference in config? Also, how do I set it to console: NO? Could that be my problem? HiPer>> li chas Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 YES 24 Channel High Density Modem 23 DYNAMIC YES 4 YES --EMPTY-- 0 STATIC NO Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Seeing DSP
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-13 16:09:26

Be sure and do, in TCM, Configure->Actions Commands->Software->Save Modem/T1 settings before you reboot. Highlight the DSP in question of course. (thanks Jeff for lettin' me get an easy one answered in there :) SMT

Subject: Re: (usr-tc) Seeing DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-13 16:12:16

At 02:27 PM 9/13/99 -0400, I wrote: >I just installed a new DSP but the PRI isn't hooked into it yet. Getting; >HiPer>> list chassis >Slot Owner Description Ports Type Console >1 YES 24 Channel High Density Modem 23 DYNAMIC NO >2 YES 24 Channel High Density Modem 23 DYNAMIC NO >3 YES --EMPTY-- 0 STATIC NO >4 YES --EMPTY-- 0 STATIC NO >5 YES --EMPTY-- 0 STATIC NO > >How do I get the ARC to recognize the new card(slot 3)? Is it possible w/o >rebooting? Ok, I reseated the card and TCM sees it ok, but it still isn't apparently responding on the D channel. I loaded the config from one of my working cards and saved it, still no go. The only difference in them being that my other DSPs are running 1.2.60 and the new one is showing 2.0.81. Is there something different in 2.0.81 that I need to account for by a difference in config? Also, how do I set it to console: NO? Could that be my problem? HiPer>> li chas Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 YES 24 Channel High Density Modem 23 DYNAMIC YES 4 YES --EMPTY-- 0 STATIC NO Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Seeing DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-13 16:56:28

At 03:33 PM 9/13/99 -0500, you wrote: >You definately need to Hardware-Reboot the card (IE, not "software reset) >for the changes to take effect. Ok, I'm loading trunk settings from a working DSP, setting it, then hardware resetting. One of the settings that's reverting back to default is switch type. It should be priSwDMS100 but it keeps reverting to priSw5ESS after the hardware reset. Other fields in trunk settings are changing back also. Any ideas? I'm guessing that I'm doing something wrong, but I don't know what :( Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Seeing DSP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-13 21:07:25

Thus spake Scott Trautman >Be sure and do, in TCM, Configure->Actions Commands->Software->Save >Modem/T1 settings before you reboot. Highlight the DSP in question of >course. >(thanks Jeff for lettin' me get an easy one answered in there :) Heh...I'm not quite as proficient in DSP's as in quads and the gateway cards. :) Think that's largely from my coming from an IP background (I hate dealing with modems, truth be known), and only having recently introduced DSP's into our setup. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Seeing DSP
From: Marshall Morgan <marshall@netdoor.com>
Date: 1999-09-13 21:14:01

set chASSIS slOT 3 coNSOLE nO Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Monday, September 13, 1999 9:05 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Seeing DSP > > > At 04:09 PM 9/13/99 -0500, you wrote: > >Be sure and do, in TCM, Configure->Actions Commands->Software->Save Modem/T1 > >settings > >before you reboot. Highlight the DSP in question of course. > > Ok, that seems to be holding the settings. Now, why is the new card saying > YES to console when none of the others are, and how do I change it? > HiPer>> li chas > Slot Owner Description Ports Type Console > 1 YES 24 Channel High Density Modem 23 DYNAMIC NO > 2 YES 24 Channel High Density Modem 23 DYNAMIC NO > 3 YES 24 Channel High Density Modem 23 DYNAMIC YES > 4 YES --EMPTY-- 0 STATIC NO > > Thanks, > Kirk

Subject: RE: (usr-tc) Seeing DSP
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-13 21:26:33

Interesting....this was what I was looking for a week or so ago, I tried the opposite, set chassis slot 13 console yes, says 11 YES --EMPTY-- 0 STATIC NO 12 YES 24 Channel High Density Modem 24 DYNAMIC YES 13 YES 24 Channel High Density Modem 24 DYNAMIC NO 14 YES 24 Channel High Density Modem 24 DYNAMIC YES 15 YES 24 Channel High Density Modem 24 DYNAMIC NO 16 NO HiPer Access Router NAC 0 DYNAMIC NO HiPer>> set chassis slot 13 console yes ERROR - Cannot change console settings of a dynamic entry ...back to original question...why the two no when there wasn't any difference in setup? Anything to set on the DSP to "allow" console? Anything I might have inadvertantly set on the chassis? SMT > -----Original Message----- > From: Marshall Morgan [mailto:marshall@netdoor.com] > Sent: Monday, September 13, 1999 9:14 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Seeing DSP > > > set chASSIS slOT 3 coNSOLE nO > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > > Sent: Monday, September 13, 1999 9:05 PM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Seeing DSP > > > > > > At 04:09 PM 9/13/99 -0500, you wrote: > > >Be sure and do, in TCM, Configure->Actions > Commands->Software->Save Modem/T1 > > >settings > > >before you reboot. Highlight the DSP in question of course. > > > > Ok, that seems to be holding the settings. Now, why is the > new card saying > > YES to console when none of the others are, and how do I change it? > > HiPer>> li chas > > Slot Owner Description Ports > Type Console > > 1 YES 24 Channel High Density Modem 23 > DYNAMIC NO > > 2 YES 24 Channel High Density Modem 23 > DYNAMIC NO > > 3 YES 24 Channel High Density Modem 23 > DYNAMIC YES > > 4 YES --EMPTY-- 0 > STATIC NO > > > > Thanks, > > Kirk > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Seeing DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-13 22:05:18

At 04:09 PM 9/13/99 -0500, you wrote: >Be sure and do, in TCM, Configure->Actions Commands->Software->Save Modem/T1 >settings >before you reboot. Highlight the DSP in question of course. Ok, that seems to be holding the settings. Now, why is the new card saying YES to console when none of the others are, and how do I change it? HiPer>> li chas Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 YES 24 Channel High Density Modem 23 DYNAMIC YES 4 YES --EMPTY-- 0 STATIC NO Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Seeing DSP
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-14 00:03:16

At 09:14 PM 9/13/99 -0500, you wrote: >set chASSIS slOT 3 coNSOLE nO That didn't work, but I got there...almost; HiPer>> set chassis slot 3 console no ERROR - Cannot change console settings of a dynamic entry HiPer>> set chassis slot 3 type static HiPer>> set chassis slot 3 console no HiPer>> set chassis slot 3 type dynamic CLI - Invalid Argument: dynamic This field is a KEYWORD LIST. The possible values are: [ STATIC ] So, now I got it set to NO, but; HiPer>> li chas Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 YES 24 Channel High Density Modem 23 STATIC NO Now, how do I get it back to dynamic? And what difference does YES or NO on the console setting make anyway? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) TC traffic pauses momentarily
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-14 09:42:41

Running HiperARC 4.1.59 with DSP's. Occasionally, dialup connections will stop receiving IP traffic, then anywhere from 15 seconds to 1 minute later traffic resumes. Customer is in the middle of receiving traffic, it suddenly stops, then resumes. I have experienced this myself. It is not the host that they are connecting to. They can be in the middle of receiving mail from our mail server, and all traffic suddenly stops for a noticeable period of time. They do not get disconnected. I *thought* I saw some mention of this phenomenon on the list, but I'm not sure. Anyone have any ideas? Is this a known issue? ...Scot

Subject: Re: (usr-tc) TC traffic pauses momentarily
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-14 10:41:52

On Tue, 14 Sep 1999, Scot Desort wrote: > Running HiperARC 4.1.59 with DSP's. Occasionally, dialup connections will > stop receiving IP traffic, then anywhere from 15 seconds to 1 minute later > traffic resumes. > > Customer is in the middle of receiving traffic, it suddenly stops, then > resumes. I have experienced this myself. It is not the host that they are > connecting to. They can be in the middle of receiving mail from our mail > server, and all traffic suddenly stops for a noticeable period of time. They > do not get disconnected. > > I *thought* I saw some mention of this phenomenon on the list, but I'm not > sure. Anyone have any ideas? Is this a known issue? Normal modem retraining, maybe? Check the retrain counts on the modem and see if they go up... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: (usr-tc) modem that will not pick up
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-14 11:11:48

I'm having a problem with one modem that refuses to pick up. When I watch the status in performance monitor, I can see the call coming in (RingIn or RingRcvd states), DNIS and ANI information comes up, but the modem never picks up the call. I have replaced the DSP NAC and the problem didn't go away. The only other place I can think to look is to the ARC itself but the modem interface is UP/UP. I've also tried a full reconfig (restore from default, save to nvram, reboot, reconfig, save to nvram, reboot) and no luck. When a user happens to grab that line they hear a long pause of dead air (maybe 5 seconds or more) and then it starts ringing endlessly. Any ideas?

Subject: (usr-tc) HARC 4.1.59 and 4.1.11 won't accept ISDN (fwd)
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-09-14 12:50:06

das, you really dont need to reset config all over again, one can use the bulk file command to save the config and tftp to arc again to relaod config. tftp might not be working for several reasons. List network services should show the tftpd demaon as enabled. If it is not enabled, enable the service. Also, tftp time out may cause this . Best solution is to do AT{ZF} on console of arc. Ahmed ---------- Forwarded message ---------- A bit of an emergency... I thought that I would upgrade my hipers this morning. I upgraded both to 4.1.59 and once they were rebooted they stopped authenticating ISDN calls. I flashed one to 4.1.11 and it lost various parts of it's configuration (ex. it lost its ip network settings but retained pool settings) I reconfigured it, but it still is having the same problems with ISDN. Analog calls authenticate happily. I have tried flashing the second HARC back to 4.1.59, but now it keeps failing the tftp upload. Also, when I look in the logs, it repeatedly logs: --syslog capture: 2b110903 slot:4/mod:10 --syslog capture:stop each time for the same interface (slot and modem) and then it moves to a different interface. If anyone can offer any insight into this, I'm sure that my customers will be happily and I will be extremely grateful. das -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) More new DSP problems
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-14 13:17:28

I finally got the card to retain it's trunk settings, but it's still giving me problems. About every 2 hours it throws itself into a reboot and locks up with all LEDs illuminated steady red. The only way to restore it to service is to reseat the card. this DSp is running 2.0.81 while my other DSP are running 1.2.60, ARC is 4.1.59 Also, I have no idea how to get the type set to dynamic. Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) PRI card needs to be constantly placed in service
From: eric@dol.net
Date: 1999-09-14 14:15:41

I have a pri card in a quad modem chassis software 3.0.2 It seems to go busy every few days and need to be placed in service again with tcm. It gives no visible indication that the pri is dead. Is this a hardware related issue or a software issue? thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: Re: (usr-tc) Connect %'s
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-14 14:19:56

Paul, What Hiper DSP and Hiper Arc code are you running? Clint R. Sparks ComQuest Internet Services csparks@cqc.com ----- Original Message ----- Sent: Tuesday, September 14, 1999 2:04 PM > Hello all... > > Just throwing this out to see if it what others are getting: > > ARC-I Total calls received: 51627 6 DSP's > Total calls failed : 2546 > Connection average : 95.07 > ARC-II Total calls received: 2318 6 Quad's > Total calls failed : 86 > Connection average : 96.29 > > Total calls received: 53894 > Total calls failed : 2631 > Connection average : 95.12 > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > System UpTime: 34d 04:53:31 > > (Some cards have been rebooted to clear hung modems) > > This is from a simple perl script that walk the inConnectAttemptFails and > inConnectEstablished OID's. > > It's been hovering around 95% connection rate..... anyone seeing higher > than this? > > > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net

Subject: RE: (usr-tc) Connect %'s
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-09-14 14:58:23

Total Calls Success 484124 Total calls Failed 24080 Call Failure Rate 4.74% This is over 17 pops Best rate is 2.39 Worst is 6.49 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of USR TC Mailing list account Sent: Tuesday, September 14, 1999 2:16 PM For comparison, I've knocked up some software that dials out with 2 couriers and does testing. This setup is a "perfect" setup, ie, there are no problems with it that would make it fail. According to that, the cumulative logs for the last few days add up to: Calls made: 23822 Calls succeeded: 23501 Calls failed: 327 Failure rate: 1.3% Ring-No-answer fails: 6 Busies: 2 NoCarrier: 248 NoLoginPrompt: 70 NoPPP: 1 The number of failed calls from SNMP works out at 5.52% (93949 success/5492 failed). Ergo, from this roughly 4% of failed calls are due to problems outside the racks. Hope this helps (and "Hi!" to JP, if yer still out there and didn't get eaten in Canada, eh? :-) Cheers, Steve On Tue, 14 Sep 1999, Paul Farber wrote: > Hello all... > > Just throwing this out to see if it what others are getting: > > ARC-I Total calls received: 51627 6 DSP's > Total calls failed : 2546 > Connection average : 95.07 > ARC-II Total calls received: 2318 6 Quad's > Total calls failed : 86 > Connection average : 96.29 > > Total calls received: 53894 > Total calls failed : 2631 > Connection average : 95.12 > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > System UpTime: 34d 04:53:31 > > (Some cards have been rebooted to clear hung modems) > > This is from a simple perl script that walk the inConnectAttemptFails and > inConnectEstablished OID's. > > It's been hovering around 95% connection rate..... anyone seeing higher > than this? > > > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Connect %'s
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-14 15:04:00

Hello all... Just throwing this out to see if it what others are getting: ARC-I Total calls received: 51627 6 DSP's Total calls failed : 2546 Connection average : 95.07 ARC-II Total calls received: 2318 6 Quad's Total calls failed : 86 Connection average : 96.29 Total calls received: 53894 Total calls failed : 2631 Connection average : 95.12 System Date ( Time in GMT ) 14-SEP-1999 14:56:13 System UpTime: 34d 04:53:31 (Some cards have been rebooted to clear hung modems) This is from a simple perl script that walk the inConnectAttemptFails and inConnectEstablished OID's. It's been hovering around 95% connection rate..... anyone seeing higher than this? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net

Subject: Re: (usr-tc) TC traffic pauses momentarily
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-14 16:29:58

Don't think so. Happens with ISDN also. That's how I've personally experienced it.... ...Scot ----- Original Message ----- Sent: Tuesday, September 14, 1999 10:41 AM > On Tue, 14 Sep 1999, Scot Desort wrote: > > > Running HiperARC 4.1.59 with DSP's. Occasionally, dialup connections will > > stop receiving IP traffic, then anywhere from 15 seconds to 1 minute later > > traffic resumes. > > > > Customer is in the middle of receiving traffic, it suddenly stops, then > > resumes. I have experienced this myself. It is not the host that they are > > connecting to. They can be in the middle of receiving mail from our mail > > server, and all traffic suddenly stops for a noticeable period of time. They > > do not get disconnected. > > > > I *thought* I saw some mention of this phenomenon on the list, but I'm not > > sure. Anyone have any ideas? Is this a known issue? > > > Normal modem retraining, maybe? Check the retrain counts on the modem and > see if they go up... > >

Subject: Re: (usr-tc) TC traffic pauses momentarily
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-14 16:41:42

Thus spake Scot Desort >Don't think so. Happens with ISDN also. That's how I've personally >experienced it.... The only cause I remember for something like this was when the user was using bandwidth on demand with Multi-Link and MPIP wasn't functioning correctly. The pause occured when their equipment started to bring up the second line...it didn't get bundled in correctly...one side or the other was trying to send data split across the two lines and because it wasn't bundled correctly, the data was corrupted...eventually the second channel hangs up because the usage has dropped below the threshold level, and at the next resend, everything starts flowing again because it only has the one link so the data is no longer being corrupted. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Connect %'s
From: Allen Marsalis <am@shreve.net>
Date: 1999-09-14 16:55:26

At 03:04 PM 9/14/99 -0400, Paul Farber wrote: > >It's been hovering around 95% connection rate..... anyone seeing higher >than this? > > Nope, it hovers around 95% for us everyday.. Modem Health Check - file: shv1.1 - chassis: usr1 09/13/99 07:00:07 slot:x/mod:y Calls Calls Failed Percent Arrived Established Attempts Success ------------ ------- ----------- -------- ------- slot:1/mod:1 7 7 0 100.00 slot:1/mod:10 21 20 1 95.24 slot:1/mod:11 17 15 2 88.24 slot:1/mod:12 13 13 0 100.00 slot:1/mod:13 6 6 0 100.00 slot:1/mod:14 24 23 1 95.83 slot:1/mod:15 22 19 3 86.36 slot:1/mod:16 12 11 1 91.67 slot:1/mod:17 30 29 1 96.67 slot:1/mod:18 18 17 1 94.44 slot:1/mod:19 25 22 3 88.00 slot:1/mod:2 28 25 3 89.29 slot:1/mod:20 26 23 3 88.46 slot:1/mod:21 26 26 0 100.00 slot:1/mod:22 24 22 2 91.67 slot:1/mod:23 35 34 1 97.14 slot:1/mod:3 25 25 0 100.00 slot:1/mod:4 32 30 2 93.75 slot:1/mod:5 26 25 1 96.15 slot:1/mod:6 38 37 1 97.37 slot:1/mod:7 28 24 4 85.71 slot:1/mod:8 23 23 0 100.00 slot:1/mod:9 31 29 2 93.55 slot:10/mod:1 28 27 1 96.43 slot:10/mod:10 34 33 1 97.06 slot:10/mod:11 34 34 0 100.00 slot:10/mod:12 29 28 1 96.55 slot:10/mod:13 26 26 0 100.00 slot:10/mod:15 29 28 1 96.55 slot:10/mod:16 27 26 1 96.30 slot:10/mod:17 26 26 0 100.00 slot:10/mod:18 15 15 0 100.00 slot:10/mod:21 27 25 2 92.59 slot:10/mod:22 32 28 4 87.50 slot:10/mod:23 16 15 1 93.75 slot:10/mod:3 27 26 1 96.30 slot:10/mod:4 23 22 1 95.65 slot:10/mod:5 29 27 2 93.10 slot:10/mod:6 18 18 0 100.00 slot:10/mod:7 27 24 3 88.89 slot:10/mod:8 9 9 0 100.00 slot:10/mod:9 14 14 0 100.00 slot:2/mod:1 21 19 2 90.48 slot:2/mod:10 26 24 2 92.31 slot:2/mod:11 40 35 5 87.50 slot:2/mod:12 30 30 0 100.00 slot:2/mod:13 31 27 4 87.10 slot:2/mod:14 32 32 0 100.00 slot:2/mod:16 5 4 1 80.00 slot:2/mod:18 31 29 2 93.55 slot:2/mod:19 32 30 2 93.75 Modem Health Check - file: shv1.1 - chassis: usr1 09/13/99 07:00:07 slot:x/mod:y Calls Calls Failed Percent Arrived Established Attempts Success ------------ ------- ----------- -------- ------- slot:2/mod:2 33 32 1 96.97 slot:2/mod:20 22 21 1 95.45 slot:2/mod:21 34 32 2 94.12 slot:2/mod:22 25 25 0 100.00 slot:2/mod:23 5 5 0 100.00 slot:2/mod:3 25 23 2 92.00 slot:2/mod:4 15 15 0 100.00 slot:2/mod:5 18 17 1 94.44 slot:2/mod:6 28 25 3 89.29 slot:2/mod:7 24 24 0 100.00 slot:2/mod:8 30 28 2 93.33 slot:2/mod:9 30 28 2 93.33 slot:3/mod:1 30 29 1 96.67 slot:3/mod:10 29 28 1 96.55 slot:3/mod:11 20 19 1 95.00 slot:3/mod:13 30 30 0 100.00 slot:3/mod:15 31 28 3 90.32 slot:3/mod:18 6 6 0 100.00 slot:3/mod:19 19 19 0 100.00 slot:3/mod:2 21 20 1 95.24 slot:3/mod:20 25 25 0 100.00 slot:3/mod:21 28 27 1 96.43 slot:3/mod:22 29 28 1 96.55 slot:3/mod:3 18 18 0 100.00 slot:3/mod:4 32 31 1 96.88 slot:3/mod:5 23 22 1 95.65 slot:3/mod:6 20 20 0 100.00 slot:3/mod:7 25 23 2 92.00 slot:3/mod:8 27 26 1 96.30 slot:4/mod:1 26 25 1 96.15 slot:4/mod:10 21 21 0 100.00 slot:4/mod:11 33 32 1 96.97 slot:4/mod:12 25 23 2 92.00 slot:4/mod:13 14 13 1 92.86 slot:4/mod:14 36 34 2 94.44 slot:4/mod:15 22 19 3 86.36 slot:4/mod:16 29 29 0 100.00 slot:4/mod:17 27 26 1 96.30 slot:4/mod:18 17 16 1 94.12 slot:4/mod:19 24 22 2 91.67 slot:4/mod:2 29 28 1 96.55 slot:4/mod:20 35 34 1 97.14 slot:4/mod:21 22 22 0 100.00 slot:4/mod:22 18 17 1 94.44 slot:4/mod:23 30 28 2 93.33 slot:4/mod:3 30 27 3 90.00 slot:4/mod:4 17 17 0 100.00 slot:4/mod:7 23 22 1 95.65 slot:4/mod:8 21 21 0 100.00 slot:5/mod:1 13 12 1 92.31 slot:5/mod:10 17 14 3 82.35 Modem Health Check - file: shv1.1 - chassis: usr1 09/13/99 07:00:07 slot:x/mod:y Calls Calls Failed Percent Arrived Established Attempts Success ------------ ------- ----------- -------- ------- slot:5/mod:11 23 21 2 91.30 slot:5/mod:12 27 25 2 92.59 slot:5/mod:13 29 26 3 89.66 slot:5/mod:15 36 35 1 97.22 slot:5/mod:16 11 11 0 100.00 slot:5/mod:18 19 19 0 100.00 slot:5/mod:19 19 19 0 100.00 slot:5/mod:2 7 7 0 100.00 slot:5/mod:20 24 24 0 100.00 slot:5/mod:21 29 28 1 96.55 slot:5/mod:22 25 24 1 96.00 slot:5/mod:23 28 26 2 92.86 slot:5/mod:3 23 22 1 95.65 slot:5/mod:4 15 13 2 86.67 slot:5/mod:5 19 19 0 100.00 slot:5/mod:6 16 15 1 93.75 slot:5/mod:7 30 30 0 100.00 slot:5/mod:8 18 15 3 83.33 slot:5/mod:9 24 21 3 87.50 slot:6/mod:1 34 31 3 91.18 slot:6/mod:10 9 9 0 100.00 slot:6/mod:11 30 24 6 80.00 slot:6/mod:12 15 15 0 100.00 slot:6/mod:13 30 28 2 93.33 slot:6/mod:15 32 31 1 96.88 slot:6/mod:16 23 22 1 95.65 slot:6/mod:17 29 28 1 96.55 slot:6/mod:18 21 20 1 95.24 slot:6/mod:19 16 16 0 100.00 slot:6/mod:2 29 27 2 93.10 slot:6/mod:20 6 6 0 100.00 slot:6/mod:21 24 24 0 100.00 slot:6/mod:22 35 33 2 94.29 slot:6/mod:23 29 28 1 96.55 slot:6/mod:3 28 28 0 100.00 slot:6/mod:4 17 15 2 88.24 slot:6/mod:5 27 25 2 92.59 slot:6/mod:6 11 11 0 100.00 slot:6/mod:7 19 18 1 94.74 slot:6/mod:8 27 26 1 96.30 slot:6/mod:9 13 13 0 100.00 slot:7/mod:1 24 22 2 91.67 slot:7/mod:10 29 27 2 93.10 slot:7/mod:11 25 22 3 88.00 slot:7/mod:12 29 28 1 96.55 slot:7/mod:13 24 22 2 91.67 slot:7/mod:14 24 21 3 87.50 slot:7/mod:15 23 21 2 91.30 slot:7/mod:18 31 29 2 93.55 slot:7/mod:19 24 24 0 100.00 slot:7/mod:2 26 25 1 96.15 Modem Health Check - file: shv1.1 - chassis: usr1 09/13/99 07:00:07 slot:x/mod:y Calls Calls Failed Percent Arrived Established Attempts Success ------------ ------- ----------- -------- ------- slot:7/mod:20 30 28 2 93.33 slot:7/mod:21 5 5 0 100.00 slot:7/mod:22 25 24 1 96.00 slot:7/mod:23 28 28 0 100.00 slot:7/mod:5 14 13 1 92.86 slot:7/mod:6 8 8 0 100.00 slot:7/mod:7 21 20 1 95.24 slot:7/mod:8 29 27 2 93.10 slot:7/mod:9 10 10 0 100.00 slot:8/mod:1 38 35 3 92.11 slot:8/mod:11 19 19 0 100.00 slot:8/mod:12 36 33 3 91.67 slot:8/mod:13 21 21 0 100.00 slot:8/mod:14 27 25 2 92.59 slot:8/mod:15 20 19 1 95.00 slot:8/mod:16 30 29 1 96.67 slot:8/mod:17 32 31 1 96.88 slot:8/mod:18 27 26 1 96.30 slot:8/mod:19 29 28 1 96.55 slot:8/mod:2 32 30 2 93.75 slot:8/mod:20 10 10 0 100.00 slot:8/mod:21 17 17 0 100.00 slot:8/mod:22 27 26 1 96.30 slot:8/mod:23 27 24 3 88.89 slot:8/mod:3 27 25 2 92.59 slot:8/mod:5 29 28 1 96.55 slot:8/mod:6 20 19 1 95.00 slot:8/mod:7 32 28 4 87.50 slot:8/mod:8 31 31 0 100.00 slot:9/mod:1 32 29 3 90.62 slot:9/mod:10 10 10 0 100.00 slot:9/mod:11 21 21 0 100.00 slot:9/mod:12 5 5 0 100.00 slot:9/mod:13 33 33 0 100.00 slot:9/mod:14 9 9 0 100.00 slot:9/mod:15 11 11 0 100.00 slot:9/mod:16 27 23 4 85.19 slot:9/mod:17 27 26 1 96.30 slot:9/mod:18 23 22 1 95.65 slot:9/mod:19 27 24 3 88.89 slot:9/mod:2 25 23 2 92.00 slot:9/mod:20 30 27 3 90.00 slot:9/mod:21 29 29 0 100.00 slot:9/mod:22 34 29 5 85.29 slot:9/mod:23 3 3 0 100.00 slot:9/mod:3 24 20 4 83.33 slot:9/mod:4 3 3 0 100.00 slot:9/mod:5 31 29 2 93.55 slot:9/mod:6 25 23 2 92.00 slot:9/mod:7 19 19 0 100.00 slot:9/mod:8 26 24 2 92.31 Modem Health Check - file: shv1.1 - chassis: usr1 09/13/99 07:00:07 slot:x/mod:y Calls Calls Failed Percent Arrived Established Attempts Success ------------ ------- ----------- -------- ------- slot:9/mod:9 19 18 1 94.74 ================================= 95.12% average for chassis ================================= am

Subject: Re: (usr-tc) More new DSP problems
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-14 17:00:56

At 01:17 PM 9/14/99 -0400, I wrote: > I finally got the card to retain it's trunk settings, but it's still >giving me problems. About every 2 hours it throws itself into a reboot and >locks up with all LEDs illuminated steady red. The only way to restore it >to service is to reseat the card. this DSP is running 2.0.81 while my other >DSP are running 1.2.60, ARC is 4.1.59 > Also, I have no idea how to get the type set to dynamic. Yet more freaking joy with my new $4500 paperweight! Another condition that throws it into a reboot is taking calls. Within 1-2 minutes of a call authenticating on the DSP, it reboots. While testing though, the behavior is inconstistant. About half of the time the reboot freezes with all lights red and needs reseated, the rest of the time it reboots fully and returns to service. Hardware version is 0.53.0 Anybody have any ideas? Thanks again, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Connect %'s
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-14 17:28:04

Paul, Have you tried Hiper DSP code 2.0.81? If so what do you think of it? Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com ----- Original Message ----- Sent: Tuesday, September 14, 1999 4:58 PM > DSP 2.0.19 > ARC 4.1.59 > NMC 6.1.17 > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Tue, 14 Sep 1999, Clint R. Sparks wrote: > > > Paul, > > > > What Hiper DSP and Hiper Arc code are you running? > > > > Clint R. Sparks > > ComQuest Internet Services > > csparks@cqc.com > > > > > > ----- Original Message ----- > > From: Paul Farber <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Tuesday, September 14, 1999 2:04 PM > > Subject: (usr-tc) Connect %'s > > > > > > > Hello all... > > > > > > Just throwing this out to see if it what others are getting: > > > > > > ARC-I Total calls received: 51627 6 DSP's > > > Total calls failed : 2546 > > > Connection average : 95.07 > > > ARC-II Total calls received: 2318 6 Quad's > > > Total calls failed : 86 > > > Connection average : 96.29 > > > > > > Total calls received: 53894 > > > Total calls failed : 2631 > > > Connection average : 95.12 > > > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > > System UpTime: 34d 04:53:31 > > > > > > (Some cards have been rebooted to clear hung modems) > > > > > > This is from a simple perl script that walk the inConnectAttemptFails and > > > inConnectEstablished OID's. > > > > > > It's been hovering around 95% connection rate..... anyone seeing higher > > > than this? > > > > > > > > > > > > Paul D. Farber II > > > Farber Technology > > > Ph. 570-628-5303 > > > Fax 570-628-5545 > > > farber@admin.f-tech.net > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC traffic pauses momentarily
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-14 17:29:27

Hmmm. Can't be the case with the analog dialups -- they are definitely not trying to do multilink. And when I use my 3COM Impact, I have to request 2 channels by entering the phone number twice. And I rarely do. Come to think of it, it has also happened when I dialup analog. Honestly, I thought it was my imagination until I had 2 customers call in a single day to "complain" about the exact same thing. I don't think it is very widespread. Or perhaps it is, and nobody noticed but me and the other tech-heads that we have dialing in. I was going to trying switching to the other ethernet port on the HARC, and then try another port on the Cisco switch. Next time it happens, I'm going to run some traceroutes and see exactly where the packets are dying -- at the HARC, and our core, whatever. But other than that, I'm at a loss... ...Scot ----- Original Message ----- Sent: Tuesday, September 14, 1999 4:41 PM > Thus spake Scot Desort > >Don't think so. Happens with ISDN also. That's how I've personally > >experienced it.... > > The only cause I remember for something like this was when the user was > using bandwidth on demand with Multi-Link and MPIP wasn't functioning > correctly. The pause occured when their equipment started to bring up > the second line...it didn't get bundled in correctly...one side or the > other was trying to send data split across the two lines and because it > wasn't bundled correctly, the data was corrupted...eventually the second > channel hangs up because the usage has dropped below the threshold > level, and at the next resend, everything starts flowing again because > it only has the one link so the data is no longer being corrupted. > -- > 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. >

Subject: Re: (usr-tc) Connect %'s
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-14 17:58:11

DSP 2.0.19 ARC 4.1.59 NMC 6.1.17 Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 14 Sep 1999, Clint R. Sparks wrote: > Paul, > > What Hiper DSP and Hiper Arc code are you running? > > Clint R. Sparks > ComQuest Internet Services > csparks@cqc.com > > > ----- Original Message ----- > From: Paul Farber <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, September 14, 1999 2:04 PM > Subject: (usr-tc) Connect %'s > > > > Hello all... > > > > Just throwing this out to see if it what others are getting: > > > > ARC-I Total calls received: 51627 6 DSP's > > Total calls failed : 2546 > > Connection average : 95.07 > > ARC-II Total calls received: 2318 6 Quad's > > Total calls failed : 86 > > Connection average : 96.29 > > > > Total calls received: 53894 > > Total calls failed : 2631 > > Connection average : 95.12 > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > System UpTime: 34d 04:53:31 > > > > (Some cards have been rebooted to clear hung modems) > > > > This is from a simple perl script that walk the inConnectAttemptFails and > > inConnectEstablished OID's. > > > > It's been hovering around 95% connection rate..... anyone seeing higher > > than this? > > > > > > > > Paul D. Farber II > > Farber Technology > > Ph. 570-628-5303 > > Fax 570-628-5545 > > farber@admin.f-tech.net > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect %'s
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-09-14 18:06:20

DSP 2.0.81 ARC 4.1.59 Total Connects: 46823 Total Fails: 1392 or about 3% Worst modem is 7%. Samuel S. Lowe Director, Data Services UniversalCom, Inc. slowe@universalcom.net ----- Original Message ----- Sent: Tuesday, September 14, 1999 4:58 PM > > > Hello all... > > > > > > Just throwing this out to see if it what others are getting: > > > > > > ARC-I Total calls received: 51627 6 DSP's > > > Total calls failed : 2546 > > > Connection average : 95.07 > > > ARC-II Total calls received: 2318 6 Quad's > > > Total calls failed : 86 > > > Connection average : 96.29 > > > > > > Total calls received: 53894 > > > Total calls failed : 2631 > > > Connection average : 95.12 > > > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > > System UpTime: 34d 04:53:31 > > > > > > (Some cards have been rebooted to clear hung modems) > > > > > > This is from a simple perl script that walk the inConnectAttemptFails and > > > inConnectEstablished OID's. > > > > > > It's been hovering around 95% connection rate..... anyone seeing higher > > > than this? > > > > > > > > > > > > Paul D. Farber II > > > Farber Technology > > > Ph. 570-628-5303 > > > Fax 570-628-5545 > > > farber@admin.f-tech.net > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Connect %'s
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-14 18:16:02

Was this into a dedicated slot/modem or did you just dial into a hunt group? Have you modified the default modem template at all??? Would have been nice if you used something other than a courier... kinda loads up the test in favor of getting a connection... most customers get a .v90 $20 win modem. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 14 Sep 1999, USR TC Mailing list account wrote: > For comparison, I've knocked up some software that dials out with 2 > couriers and does testing. This setup is a "perfect" setup, ie, there are > no problems with it that would make it fail. According to that, the > cumulative logs for the last few days add up to: > > Calls made: 23822 > Calls succeeded: 23501 > Calls failed: 327 > Failure rate: 1.3% > Ring-No-answer fails: 6 > Busies: 2 > NoCarrier: 248 > NoLoginPrompt: 70 > NoPPP: 1 > > The number of failed calls from SNMP works out at 5.52% (93949 > success/5492 failed). > > Ergo, from this roughly 4% of failed calls are due to problems outside the > racks. > > Hope this helps (and "Hi!" to JP, if yer still out there and didn't get > eaten in Canada, eh? :-) > > Cheers, Steve > > On Tue, 14 Sep 1999, Paul Farber wrote:

Subject: Re: (usr-tc) Connect %'s
From: USR TC Mailing list account <usrtc@fop.ns.ca>
Date: 1999-09-14 18:16:19

For comparison, I've knocked up some software that dials out with 2 couriers and does testing. This setup is a "perfect" setup, ie, there are no problems with it that would make it fail. According to that, the cumulative logs for the last few days add up to: Calls made: 23822 Calls succeeded: 23501 Calls failed: 327 Failure rate: 1.3% Ring-No-answer fails: 6 Busies: 2 NoCarrier: 248 NoLoginPrompt: 70 NoPPP: 1 The number of failed calls from SNMP works out at 5.52% (93949 success/5492 failed). Ergo, from this roughly 4% of failed calls are due to problems outside the racks. Hope this helps (and "Hi!" to JP, if yer still out there and didn't get eaten in Canada, eh? :-) Cheers, Steve On Tue, 14 Sep 1999, Paul Farber wrote: > Hello all... > > Just throwing this out to see if it what others are getting: > > ARC-I Total calls received: 51627 6 DSP's > Total calls failed : 2546 > Connection average : 95.07 > ARC-II Total calls received: 2318 6 Quad's > Total calls failed : 86 > Connection average : 96.29 > > Total calls received: 53894 > Total calls failed : 2631 > Connection average : 95.12 > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > System UpTime: 34d 04:53:31 > > (Some cards have been rebooted to clear hung modems) > > This is from a simple perl script that walk the inConnectAttemptFails and > inConnectEstablished OID's. > > It's been hovering around 95% connection rate..... anyone seeing higher > than this? > > > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Connect %'s
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-14 18:20:30

Feels good to be average! Seems that we all have cobbled together our own failure scripts.... Anyone gotten their script to busy out a modem that goes over a threshold value (hung modem)? What OID or you using to set it to busy out?? Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 14 Sep 1999, Eric Billeter wrote: > Total Calls Success 484124 > Total calls Failed 24080 > Call Failure Rate 4.74% > > This is over 17 pops > Best rate is 2.39 > Worst is 6.49 > > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of USR TC Mailing list > account > Sent: Tuesday, September 14, 1999 2:16 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Connect %'s > > > For comparison, I've knocked up some software that dials out with 2 > couriers and does testing. This setup is a "perfect" setup, ie, there are > no problems with it that would make it fail. According to that, the > cumulative logs for the last few days add up to: > > Calls made: 23822 > Calls succeeded: 23501 > Calls failed: 327 > Failure rate: 1.3% > Ring-No-answer fails: 6 > Busies: 2 > NoCarrier: 248 > NoLoginPrompt: 70 > NoPPP: 1 > > The number of failed calls from SNMP works out at 5.52% (93949 > success/5492 failed). > > Ergo, from this roughly 4% of failed calls are due to problems outside the > racks. > > Hope this helps (and "Hi!" to JP, if yer still out there and didn't get > eaten in Canada, eh? :-) > > Cheers, Steve > > On Tue, 14 Sep 1999, Paul Farber wrote: > > > Hello all... > > > > Just throwing this out to see if it what others are getting: > > > > ARC-I Total calls received: 51627 6 DSP's > > Total calls failed : 2546 > > Connection average : 95.07 > > ARC-II Total calls received: 2318 6 Quad's > > Total calls failed : 86 > > Connection average : 96.29 > > > > Total calls received: 53894 > > Total calls failed : 2631 > > Connection average : 95.12 > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > System UpTime: 34d 04:53:31 > > > > (Some cards have been rebooted to clear hung modems) > > > > This is from a simple perl script that walk the inConnectAttemptFails and > > inConnectEstablished OID's. > > > > It's been hovering around 95% connection rate..... anyone seeing higher > > than this? > > > > > > > > Paul D. Farber II > > Farber Technology > > Ph. 570-628-5303 > > Fax 570-628-5545 > > farber@admin.f-tech.net > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect %'s
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-14 18:20:44

Haven't run any stats on my chassis yet since we really just started using it not too long ago. But when we were shopping around, review after review I read (for what they're worth in their "simulated real world environments") consistently showed the top 4 players (Lucent, Ascend, 3COM, Bay/Nortel) averaging between 94 and 97% connect rates. In the real world, 95% is probably pretty good (I think). I can't see any NAS equipment with any true diversity in the area it serves, and with a pretty high volume of calls, getting much over 97-98% at most. ...Scot ----- Original Message ----- Sent: Tuesday, September 14, 1999 3:04 PM > Hello all... > > Just throwing this out to see if it what others are getting: > > ARC-I Total calls received: 51627 6 DSP's > Total calls failed : 2546 > Connection average : 95.07 > ARC-II Total calls received: 2318 6 Quad's > Total calls failed : 86 > Connection average : 96.29 > > Total calls received: 53894 > Total calls failed : 2631 > Connection average : 95.12 > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > System UpTime: 34d 04:53:31 > > (Some cards have been rebooted to clear hung modems) > > This is from a simple perl script that walk the inConnectAttemptFails and > inConnectEstablished OID's. > > It's been hovering around 95% connection rate..... anyone seeing higher > than this? > > > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect %'s
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-14 18:24:02

Speaking of default modem templates, has anyone here made any changes to theirs, and noticed significant improvements in successful calls or higher speeds? Just curious.... ...Scot ----- Original Message ----- Sent: Tuesday, September 14, 1999 6:16 PM > Was this into a dedicated slot/modem or did you just dial into a hunt > group? > > Have you modified the default modem template at all??? > > Would have been nice if you used something other than a courier... kinda > loads up the test in favor of getting a connection... most customers get > a .v90 $20 win modem. > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Tue, 14 Sep 1999, USR TC Mailing list account wrote: > > > For comparison, I've knocked up some software that dials out with 2 > > couriers and does testing. This setup is a "perfect" setup, ie, there are > > no problems with it that would make it fail. According to that, the > > cumulative logs for the last few days add up to: > > > > Calls made: 23822 > > Calls succeeded: 23501 > > Calls failed: 327 > > Failure rate: 1.3% > > Ring-No-answer fails: 6 > > Busies: 2 > > NoCarrier: 248 > > NoLoginPrompt: 70 > > NoPPP: 1 > > > > The number of failed calls from SNMP works out at 5.52% (93949 > > success/5492 failed). > > > > Ergo, from this roughly 4% of failed calls are due to problems outside the > > racks. > > > > Hope this helps (and "Hi!" to JP, if yer still out there and didn't get > > eaten in Canada, eh? :-) > > > > Cheers, Steve > > > > On Tue, 14 Sep 1999, Paul Farber wrote: > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect %'s
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-14 18:32:30

Sam, 3com is working with us right now on a connect speed problem and wants us to go to Hiper DSP code 2.0.81, what do you think of it? Have you had any problems with it? Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com ----- Original Message ----- Sent: Tuesday, September 14, 1999 6:06 PM > DSP 2.0.81 > ARC 4.1.59 > > Total Connects: 46823 > Total Fails: 1392 > or about 3% > > Worst modem is 7%. > > Samuel S. Lowe > Director, Data Services > UniversalCom, Inc. > slowe@universalcom.net > > ----- Original Message ----- > From: Paul Farber <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, September 14, 1999 4:58 PM > Subject: Re: (usr-tc) Connect %'s > > > > > > > Hello all... > > > > > > > > Just throwing this out to see if it what others are getting: > > > > > > > > ARC-I Total calls received: 51627 6 DSP's > > > > Total calls failed : 2546 > > > > Connection average : 95.07 > > > > ARC-II Total calls received: 2318 6 Quad's > > > > Total calls failed : 86 > > > > Connection average : 96.29 > > > > > > > > Total calls received: 53894 > > > > Total calls failed : 2631 > > > > Connection average : 95.12 > > > > > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > > > System UpTime: 34d 04:53:31 > > > > > > > > (Some cards have been rebooted to clear hung modems) > > > > > > > > This is from a simple perl script that walk the inConnectAttemptFails > and > > > > inConnectEstablished OID's. > > > > > > > > It's been hovering around 95% connection rate..... anyone seeing > higher > > > > than this? > > > > > > > > > > > > > > > > Paul D. Farber II > > > > Farber Technology > > > > Ph. 570-628-5303 > > > > Fax 570-628-5545 > > > > farber@admin.f-tech.net > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect %'s
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-14 18:43:15

No, I haven't. From the release notes all it really did was add NFAS and a few other things that I don't really use. Plus my support contract expired, so I don't have access to the proper ARC/NMC software to make it all TCS 3.5(?). Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 14 Sep 1999, Clint R. Sparks wrote: > Paul, > > Have you tried Hiper DSP code 2.0.81? > > If so what do you think of it? > > Thank you, > > Clint R. Sparks > ComQuest Internet Services > csparks@cqc.com > > > ----- Original Message ----- > From: Paul Farber <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, September 14, 1999 4:58 PM > Subject: Re: (usr-tc) Connect %'s > > > > DSP 2.0.19 > > ARC 4.1.59 > > NMC 6.1.17 > > > > Paul D. Farber II > > Farber Technology > > Ph. 570-628-5303 > > Fax 570-628-5545 > > farber@admin.f-tech.net > > > > On Tue, 14 Sep 1999, Clint R. Sparks wrote: > > > > > Paul, > > > > > > What Hiper DSP and Hiper Arc code are you running? > > > > > > Clint R. Sparks > > > ComQuest Internet Services > > > csparks@cqc.com > > > > > > > > > ----- Original Message ----- > > > From: Paul Farber <farber@admin.f-tech.net> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, September 14, 1999 2:04 PM > > > Subject: (usr-tc) Connect %'s > > > > > > > > > > Hello all... > > > > > > > > Just throwing this out to see if it what others are getting: > > > > > > > > ARC-I Total calls received: 51627 6 DSP's > > > > Total calls failed : 2546 > > > > Connection average : 95.07 > > > > ARC-II Total calls received: 2318 6 Quad's > > > > Total calls failed : 86 > > > > Connection average : 96.29 > > > > > > > > Total calls received: 53894 > > > > Total calls failed : 2631 > > > > Connection average : 95.12 > > > > > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > > > System UpTime: 34d 04:53:31 > > > > > > > > (Some cards have been rebooted to clear hung modems) > > > > > > > > This is from a simple perl script that walk the inConnectAttemptFails > and > > > > inConnectEstablished OID's. > > > > > > > > It's been hovering around 95% connection rate..... anyone seeing > higher > > > > than this? > > > > > > > > > > > > > > > > Paul D. Farber II > > > > Farber Technology > > > > Ph. 570-628-5303 > > > > Fax 570-628-5545 > > > > farber@admin.f-tech.net > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect %'s
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-14 19:38:34

On Tue, 14 Sep 1999, Paul Farber wrote: > Hello all... > > Just throwing this out to see if it what others are getting: > > ARC-I Total calls received: 51627 6 DSP's > Total calls failed : 2546 > Connection average : 95.07 > ARC-II Total calls received: 2318 6 Quad's > Total calls failed : 86 > Connection average : 96.29 > > Total calls received: 53894 > Total calls failed : 2631 > Connection average : 95.12 > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > System UpTime: 34d 04:53:31 > > (Some cards have been rebooted to clear hung modems) > > This is from a simple perl script that walk the inConnectAttemptFails and > inConnectEstablished OID's. What's the exact OID's you're using? Those names don't exist in my MIB... Is your script on a web page somewhere, or did you only post it here? Guess I better dig through the list archives. :) FWIW, I've found 4 different OIDs of interest: * usrinCallmodemNotAvail [1.3.6.1.4.1.429.1.27.2.1.10] PER-DSP-CARD (not per channel) counter of "modem unavailable" errors. i.e. call comes in and the DSP refused to pick it up -- the old 'dead-air' syndrome that was pretty much fixed a few releases back. This one seems to stay at zero for me on DSP 2.0.81... * mdmEvInConnectEstabs [1.3.6.1.4.1.429.1.6.10.1.1.4] Successful connects. * mdmEvConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.8] Failed connects. * mdmEvInConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.24] Also failed connects! For Quads, both of the failed connect OID's appear to be identical. But for DSP's, they're a lot different. It appears that on DSP's, the second OID includes things like a voice call hitting the modem pool and hanging up on the answer tone, and the OID above doesn't -- seems to be for DSP problems only. For example, when a DSP card gets rebooted, the first OID counter shoots up to about 50 (as people try to call while it's in the midst of rebooting, even if you busied it out first?), then stays there and never moves much past that. The second one grows for any call failure of any type, whether it's a buggy v.90 modem or whether it's a voice call (hopefully a telemarketer getting an earful of carrier). Since things like voice calls make the failure counters go up, it doesn't make a lot of sense to use this to judge the quality of 3Com's v.90 code. Especially when nobody's doing a similar comparison on, say, Cisco or Ascend servers. Anyone else noticing any other patterns?

Subject: Re: (usr-tc) Connect %'s
From: Sam Lowe <slowe@universalcom.net>
Date: 1999-09-14 19:44:00

Clint, We have had no problems with this code release. We have had a continuing problem with ISDN connections that seemingly lock up (can't route anything but ICMP packets), but this problem was present before we did the last software upgrade. We skipped over the 2.0.19 load entirely. We have seen no decrease in general connect speeds. Sam ----- Original Message ----- Sent: Tuesday, September 14, 1999 6:32 PM > Sam, > > 3com is working with us right now on a connect speed problem and wants us to > go to Hiper DSP code 2.0.81, what do you think of it? > > Have you had any problems with it? > > Thank you, > > Clint R. Sparks > ComQuest Internet Services > csparks@cqc.com > > > ----- Original Message ----- > From: Sam Lowe <slowe@universalcom.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, September 14, 1999 6:06 PM > Subject: Re: (usr-tc) Connect %'s > > > > DSP 2.0.81 > > ARC 4.1.59 > > > > Total Connects: 46823 > > Total Fails: 1392 > > or about 3% > > > > Worst modem is 7%. > > > > Samuel S. Lowe > > Director, Data Services > > UniversalCom, Inc. > > slowe@universalcom.net > > > > ----- Original Message ----- > > From: Paul Farber <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Tuesday, September 14, 1999 4:58 PM > > Subject: Re: (usr-tc) Connect %'s > > > > > > > > > > > Hello all... > > > > > > > > > > Just throwing this out to see if it what others are getting: > > > > > > > > > > ARC-I Total calls received: 51627 6 DSP's > > > > > Total calls failed : 2546 > > > > > Connection average : 95.07 > > > > > ARC-II Total calls received: 2318 6 Quad's > > > > > Total calls failed : 86 > > > > > Connection average : 96.29 > > > > > > > > > > Total calls received: 53894 > > > > > Total calls failed : 2631 > > > > > Connection average : 95.12 > > > > > > > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > > > > System UpTime: 34d 04:53:31 > > > > > > > > > > (Some cards have been rebooted to clear hung modems) > > > > > > > > > > This is from a simple perl script that walk the > inConnectAttemptFails > > and > > > > > inConnectEstablished OID's. > > > > > > > > > > It's been hovering around 95% connection rate..... anyone seeing > > higher > > > > > than this? > > > > > > > > > > > > > > > > > > > > Paul D. Farber II > > > > > Farber Technology > > > > > Ph. 570-628-5303 > > > > > Fax 570-628-5545 > > > > > farber@admin.f-tech.net > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: Re: (usr-tc) Connect %'s
From: USR TC Mailing list account <usrtc@fop.ns.ca>
Date: 1999-09-14 19:56:00

On Tue, 14 Sep 1999, Paul Farber wrote: > Was this into a dedicated slot/modem or did you just dial into a hunt > group? Into the hunt groups. We've got several pools set up, and each rack has calls from up to 5 different pools coming into it. > Have you modified the default modem template at all??? Nothing of note that would affect the connection. > Would have been nice if you used something other than a courier... kinda > loads up the test in favor of getting a connection... most customers get > a .v90 $20 win modem. That's kinda the point. We want to go in and get an idea of how the racks are performing giving a call coming in from a well set up modem. I can then generate a graph showing what the call failure %age is, and what the call failure %age is due to problems on the racks. This is all tied in with SLA's (this is for an ISP that is part of a telco - very weird reporting stuff goes on). To answer your question in a later email as to what to do when I find a bad modem, I have to call a manager who then calls a union supervisor who then calls a union worker to go and reset the modem. I'm not allowed to know the read/write snmp string. Told you it was weird. Cheers, Steve

Subject: (usr-tc) DSP Core Dump
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-14 20:39:34

Connecting to the DSP Console port shows the following shortly after any call is connected to it; *** CORE DUMP *** At 19:43:48 07/02/96 Total Uptime: 00:02:23 S/W Rev. 2.0.81.0 built 04/27/99 12:56:12 Mail() error Task = IDL Q_SEND Failed: ulStatus = 0x7 LAST MSG 214 5 4 IDL(018)=>DST(021) 000 00000000 BEAR FFFFFFFE BESR 00000000 BR0 FC580502 BR1 0C1C4202 BR2 08584202 BR3 1078C200 BR4 04594387 BR5 00594101 BR6 04590A0E BR7 00590A0E DCCR 80008000 DEAR FFFFFFFF ESR 00000000 EVPR 80000000 EXIER 00800009 EXISR 0000000A ICCR 80008001 IOCR 0000C001 MSR 00001200 PVR 00000020 PIT 00000000 SRR0 8000B920 SRR1 00001200 SRR2 3FFEFE00 SRR3 00000000 TBHI 00000002 TBLO 070844ED TCR FC000000 TSR 0C000000 LR 80006BFC ** Stack Trace ** 80005444 80006BF8 80130C14 Does anybody have any ideas what the hell is wrong with my card??? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Connect %'s
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-14 21:41:37

> What's the exact OID's you're using? Those names don't exist in my MIB... They are abbreviations the I used in a perl script. I use > * mdmEvInConnectEstabs [1.3.6.1.4.1.429.1.6.10.1.1.4] > Successful connects. > * mdmEvInConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.24] > Also failed connects! I didn't think of / see the mdmEvConnectAttemptFails MIB.... will have to add that. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 14 Sep 1999, Mike Andrews wrote: > On Tue, 14 Sep 1999, Paul Farber wrote: > > > Hello all... > > > > Just throwing this out to see if it what others are getting: > > > > ARC-I Total calls received: 51627 6 DSP's > > Total calls failed : 2546 > > Connection average : 95.07 > > ARC-II Total calls received: 2318 6 Quad's > > Total calls failed : 86 > > Connection average : 96.29 > > > > Total calls received: 53894 > > Total calls failed : 2631 > > Connection average : 95.12 > > > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > > System UpTime: 34d 04:53:31 > > > > (Some cards have been rebooted to clear hung modems) > > > > This is from a simple perl script that walk the inConnectAttemptFails and > > inConnectEstablished OID's. > > > What's the exact OID's you're using? Those names don't exist in my MIB... > > Is your script on a web page somewhere, or did you only post it here? > Guess I better dig through the list archives. :) > > FWIW, I've found 4 different OIDs of interest: > > * usrinCallmodemNotAvail [1.3.6.1.4.1.429.1.27.2.1.10] > PER-DSP-CARD (not per channel) counter of "modem unavailable" errors. > i.e. call comes in and the DSP refused to pick it up -- the old 'dead-air' > syndrome that was pretty much fixed a few releases back. This one seems > to stay at zero for me on DSP 2.0.81... > > * mdmEvInConnectEstabs [1.3.6.1.4.1.429.1.6.10.1.1.4] > Successful connects. > > * mdmEvConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.8] > Failed connects. > > * mdmEvInConnectAttemptFails [1.3.6.1.4.1.429.1.6.10.1.1.24] > Also failed connects! > > For Quads, both of the failed connect OID's appear to be identical. > > But for DSP's, they're a lot different. > > It appears that on DSP's, the second OID includes things like a voice call > hitting the modem pool and hanging up on the answer tone, and the OID > above doesn't -- seems to be for DSP problems only. > > For example, when a DSP card gets rebooted, the first OID counter shoots > up to about 50 (as people try to call while it's in the midst of > rebooting, even if you busied it out first?), then stays there and never > moves much past that. The second one grows for any call failure of any > type, whether it's a buggy v.90 modem or whether it's a voice call > (hopefully a telemarketer getting an earful of carrier). > > Since things like voice calls make the failure counters go up, it doesn't > make a lot of sense to use this to judge the quality of 3Com's v.90 code. > Especially when nobody's doing a similar comparison on, say, Cisco or > Ascend servers. > > Anyone else noticing any other patterns? > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HiperARC equivalent of portmaster show line0
From: Steve Drees <drees@the-bridge.net>
Date: 1999-09-15 09:04:44

On a portmaster 3 I can issue a show line0 and get a nice table showing alarms and violations on the PRI. What's the equivalent command on a HiperARC?

Subject: Re: (usr-tc) Connect %'s
From: Fred Williams <fwilliams@gtnet.gov.uk>
Date: 1999-09-15 09:26:06

My average is about the same. This is on the UK phone system. On 14 Sep 99, at 15:04, Paul Farber wrote: > Hello all... > > Just throwing this out to see if it what others are getting: > > ARC-I Total calls received: 51627 6 DSP's > Total calls failed : 2546 > Connection average : 95.07 > ARC-II Total calls received: 2318 6 Quad's > Total calls failed : 86 > Connection average : 96.29 > > Total calls received: 53894 > Total calls failed : 2631 > Connection average : 95.12 > > System Date ( Time in GMT ) 14-SEP-1999 14:56:13 > System UpTime: 34d 04:53:31 > > (Some cards have been rebooted to clear hung modems) > > This is from a simple perl script that walk the inConnectAttemptFails > and inConnectEstablished OID's. > > It's been hovering around 95% connection rate..... anyone seeing > higher than this? **************************************************************** * Fred Williams email fwilliams@gtnet.gov.uk * * CCTA voice 01603 704706 * * Rosebery Court GTN 3040 4706 * * St Andrews Business Park fax 01603 704817 * * NORWICH GTN fax 3040 4817 * * NR7 0HS UK * ****************************************************************

Subject: Re: (usr-tc) Connect %'s
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-15 09:45:00

As long as your users aren't buying the Soundblaster 56 modems. We've ended up switching out all of our users that have them. Either they can't connect at all or get random disconnects. Their latest code is no help. We are starting to tell customers that call in with them that either they will need to buy a new modem or go elsewhere. I hate telling customers that. Jeff Binkley ASA Network Computing u>Haven't run any stats on my chassis yet since we really just started u>using it not too long ago. But when we were shopping around, review u>after review I read (for what they're worth in their "simulated real u>world environments") consistently showed the top 4 players (Lucent, u>Ascend, 3COM, Bay/Nortel) averaging between 94 and 97% connect rates. u>In the real world, 95% is probably pretty good (I think). I can't see u>any NAS equipment with any true diversity in the area it serves, and u>with a pretty high volume of calls, getting much over 97-98% at most. u>....Scot u>----- Original Message ----- u>From: Paul Farber <farber@admin.f-tech.net> u>To: <usr-tc@lists.xmission.com> u>Sent: Tuesday, September 14, 1999 3:04 PM u>Subject: (usr-tc) Connect %'s u>> Hello all... u>> u>> Just throwing this out to see if it what others are getting: u>> u>> ARC-I Total calls received: 51627 6 DSP's u>> Total calls failed : 2546 u>> Connection average : 95.07 u>> ARC-II Total calls received: 2318 6 Quad's u>> Total calls failed : 86 u>> Connection average : 96.29 u>> u>> Total calls received: 53894 u>> Total calls failed : 2631 u>> Connection average : 95.12 u>> u>> System Date ( Time in GMT ) 14-SEP-1999 14:56:13 u>> System UpTime: 34d 04:53:31 u>> u>> (Some cards have been rebooted to clear hung modems) u>> u>> This is from a simple perl script that walk the u>> inConnectAttemptFails and inConnectEstablished OID's. u>> u>> It's been hovering around 95% connection rate..... anyone seeing u>> higher than this? u>> u>> u>> u>> Paul D. Farber II u>> Farber Technology u>> Ph. 570-628-5303 u>> Fax 570-628-5545 u>> farber@admin.f-tech.net u>> u>> u>> - u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u>> with "unsubscribe usr-tc" in the body of the message. u>> For information on digests or retrieving files and old messages u>> send "help" to the same address. Do not use quotes in your u>message. > u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42 9999

Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 10:18:18

Thus spake Steve Drees >On a portmaster 3 I can issue a show line0 and get a nice table showing >alarms and violations on the PRI. What's the equivalent command on a >HiperARC? I don't think there is. In the PM's, the whole system is a single system image...meaning the same image that runs the IP stack, also runs the modems, and PRI signaling, etc. In the TC, those are handled by different cards running different software images. The HiPer Arc is responsible for the IP stack, and DTE signaling, there are other cards that have their own images running the modem code and PRI signaling. If you're using DSP's, the modem code and PRI signaling is in one image, but if you're using the old school quads and dual-pri cards, the modem code is obviously on the quad cards and the pri signaling is on the pri-card, so even those functions might be split between cards. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-15 10:20:25

Alarms and Line Violations are tracked on your HiperDSP or Dual PRI card, not the HiperARC. You would have to use TCM's performance monitor or the CLI on the cards to find the information. At 09:04 AM 9/15/99 -0500, you wrote: >On a portmaster 3 I can issue a show line0 and get a nice table showing >alarms and violations on the PRI. What's the equivalent command on a >HiperARC? > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 11:12:23

OK...posted last week some of my thoughts on where I think the HiPer Arc and Total Control platform(s) should go as far as further development. I got exactly one serious response that was sent to me privately and was requested that the post stay private (and I'm happy to honor that). Part of my intentions in posting that message (which I've included below) was to spark some discussion amongst memebers of the list about what you all think on this subject. We're the people using this equipment, we're the people that know best where we want it to go. Let's let 3Com know about it. :) 3Com just posted drivers for their NICs for Linux (to be honest, I did a double-take when I saw that, but think its tres cool!), so apparently they are beginning to foster a corporate culture of listening to customers and what they want (and I can't support this idea enough I don't think). Let's hear what you all think about my proposals...and let's hear some of your own if you have different ideas. Honest folks, I don't care if you don't agree with me, but let's give 3Com a basis for where to go with the development of this stuff.

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-15 11:49:39

I don't really see the TC chassis being a jack of all trades. Doing that means a compromise. I buy 3Com/TC for it's ability to answer phone calls and put ppp on the line. If I want a really good router i'll build a linux box and put some NIC's in it.. or spend the money and buy a router. There are still many issues with the DSP code that need to be resolved... ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc. Fix them first! Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 12:46:15

[rearranging your post a bit...pardon me :)] Thus spake Paul Farber >There are still many issues with the DSP code that need to be resolved... >ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc. >Fix them first! Oh, *please* don't think I was talking about doing *any* of these things at the expense of current development efforts. :) I'm looking more at a strategic long term direction, compared to the things you're mentioning which I would consider more of a tactical nature. :) Sure...v.90 needs to continue to be improved, the DSP code needs to be solidified more...I certainly don't want the DSP code to be thrown out...its just getting the point of being decent... >I don't really see the TC chassis being a jack of all trades. Doing that >means a compromise. I buy 3Com/TC for it's ability to answer phone calls >and put ppp on the line. If I want a really good router i'll build a >linux box and put some NIC's in it.. or spend the money and buy a router. This is a distinction that a lot of people make that I just don't think is particularly valid. :) An access server *is* a router, although a router isn't necessarily an access server. :) Basically, the HiPer Arc, as an access server, is already doing everything that a router is doing...and more...(well...ok...its a router with a rather limited feature set at this point, but it *is* a router, nonetheless) it's dealing with interfaces popping up and down all the time, and authentication, and dynamic configuration...all stuff that plain jain routers don't have to deal with nearly as much. Why not take advantage of the fact that the HiPer Arc, as an access server, already has, (or more accurately, needs to have) all the features of a router (plus the rest that make it an access server as well). Let me throw this out as a possible for instance. Let's assume that 3Com implements the packet bus interface proposal from my message. Let's also assume that new NIC's have come up...say a channelized T3 NIC (28 ports of t1 essentially). Now then...you've got a TC chassis with 14 Arcs that have a channelized T3 NICs (that's 392 ports of t1 service), then two Arcs each with...say...a fast ethernet port, and an unchannelized t3 port. At approximately $3k/Arc, you've got dual-exit output to your network as a whole, dual-t3 uplink capability to Internet connections, and 392 t1 ports....that works out to about $48k dollars for that capability...not anything to sneeze at! This is just one example that I pulled off the top of my head with some fairly simple assumptions (the only one assumption not mentioned would be implementation of BGP in the Arc...something that I understand is already planned). Again...there are plenty of other possibilities here. The HiPer Arc code is developing nicely actually...there's still plenty of things that are on my wishlist for it in a tactical sense (BGP would be nice, but not a huge one, the ability to do some rate-limiting/traffic-shaping stuff would be nice, I'd like bridging/ethernet switching capabilities, etc.), but these are all things that routers do...we're already moving towards router functionality, why not take advantage of it. :) Something that I was just discussing with my co-admin here...the HiPer Arcs are *really* close to be useable for DSL aggregation in most of the cities we serve. GTE does it over frame-relay - frame-relay is supported in the 4.2.x code, BellSouth does it over ATM - ATM is coming...indeed, the code is already in the Arc to do it, just don't think the NICs are available yet, Cincinnati Bell does it over l2tp (I know...I think its bizarre too, but that's how they do it) - l2tp server is already in the Arc. About the only thing that's really missing from the Arc that people might want/need to do DSL aggregation is some traffic-shaping/rate-limiting features, and possibly PPPoE/PPPoA/PPPoF options. Just some more random thoughts. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-09-15 12:58:58

On Wed, 15 Sep 1999, Jeff Mcadams wrote: > OK...posted last week some of my thoughts on where I think the HiPer Arc > and Total Control platform(s) should go as far as further development. > I got exactly one serious response that was sent to me privately and was > requested that the post stay private (and I'm happy to honor that). Didn't have time to read or reply and at the moment, this is about all you'll get from me though I'm sure there are things I could probably comment on. Were in the middle of some huge projects and I'm a point man so... > Part of my intentions in posting that message (which I've included > below) was to spark some discussion amongst memebers of the list about > what you all think on this subject. We're the people using this > equipment, we're the people that know best where we want it to go. > Let's let 3Com know about it. :) See above. > 3Com just posted drivers for their NICs for Linux (to be honest, I did a > double-take when I saw that, but think its tres cool!), so apparently > they are beginning to foster a corporate culture of listening to > customers and what they want (and I can't support this idea enough I > don't think). Great idea except that I don't see spending $10,000 just to get an ESP so I can put Linux on it and run modems off it (even if they are digital). I can spend a heck of a lot less, let an ARC run the dial-up and put a stand-alone Linux box together to perform the rest of those functions... Now... If EdgeServer PRO's were a tad bit more reasonably priced, say in the $2,500 range, then we'd start talking about that potential. Still, the HARC is an excellent dial-up platform and it does what we need it to for the time being. I'm not much for breaking something that isn't broke. > Let's hear what you all think about my proposals...and let's hear some > of your own if you have different ideas. Honest folks, I don't care if > you don't agree with me, but let's give 3Com a basis for where to go > with the development of this stuff. > > > -------------------- > > > I mentioned earlier that I was going to email the list with some > thoughts of where I thought the HiPer Arc platform could/should go... > > I have a little bit of time now, so maybe I can put some of these > thoughts down and maybe get some thoughts and discussion from the rest > of you about feasibility and maybe some other ideas...In any > case...these ideas are thrown out to maybe get some discussion going to > help give 3Com an idea of what we, as customers, would like to see out > of the Arc. > > First off...a couple of specific feature requests...I may have mentioned > these before....if so, my apologies. > > 1) Bridging support...both over PPP, and over ethernet interfaces, and > any other interfaces that are supported (such as the new frame-relay > ones). > > Imagine plugging your two ethernet interfaces into two different > switches in the same IP network...running spanning-tree between > them all...then your Arc isn't dependant on its switch being in > one piece to be able to communicate. Would require the use of a > "virtual" interface that participated in the bridging code as > well...similar in some ways to the internal interface that is > available for use with OSPF now. Basically, assign the IP > address for the Arc to the virtual interface, the Arc sends > packets to the virtual interface, when then goes into the > bridging code to decide which physical interface its sent out. > This is very similar to Cisco's bridge-groups with their > integrated routing and bridging for those of you who are > familiar with that. > > 2) Support for a "packet bus interface". This one sounds bizarre...but > if you think about it for a bit it starts to make sense...if you have > multiple Arc's in a chassis...why make them communicate out their NIC's > onto an external network to talk to each other? Some benefits for > this... > > With the first feature....you could have two Arcs, both running > briding code as well...each with a single ethernet+4t1 NIC and > support 8 frame-relay t1's, and still retain the dual-exit > capability described above with briding or routing over the > packet bus. You could also theoretically have an Arc handling > modems that has no NIC at all! Modem interfaces come in over > the packet bus, and that same data is then shipped back out over > the packet bus interface to another Arc with NIC card. This > method could also be used as a failover scenario if a NIC card > failed, or a cable failed, or a switch failed...you get the > idea. > > 3) A larger variety of NIC interfaces. Particularly combined with the > packet bus interface, this frees you up to have a much greater variety > of NIC types...the Arc can then use the packet bus interface to get out > to the ethernet network (via another Arc most likely...either bridged or > routed), and allowing...oh....8 t1 NICs, or maybe a t3 nic, a > channelized t3 nic would be really sweet...the sky is the limit here > once you get the arcs using the packet bus as their ethernet > interface... > > 4) Similar to 3...the DSP cards have a crap-load of processing power in > them...could they be used for something more than just modems? It > seems...if you look at it in the abstract...that the DSP cards are > essentially interface extensions for the Arcs...let's take that > farther....this would mean basically totally revamping the code for the > DSP's for the new uses, or perhaps coming out with new code that's more > generalized. Then, with the possibility of new NICs for the DSP's you > could, again, extend the interface possibilities for the Arcs. > > 5) One that has bugged me for quite some time...PPP support on WAN > ports. I really don't particularly liked being restricted to > frame-relay encapsulation only...I can deal with it...but it'd be nice > to have the option of PPP encap as well. Many low end t1 routers don't > have frame-relay encap support, and it would be nice to be able to > interoperate with them. > > > In more abstract terms...I've been told by several 3Com folks that they > see the Pilgrim/Hiper Arc code as more full routing code rather than > just code for an Access Server. My understanding is that 3Com is moving > *all* of their routing products to eventually use the Pilgrim based > code. > > With that thought in mind though...3Com seems (from a customer's > perspective) to still think of the HiPer Arc, specifically, as an access > server alone. I think the HiPer Arc and the Total Control platform as a > whole could become a quite capable router chassis product as a whole. > Personally speaking...I'd like to see that. In a similar vein...3Com > seems to think of the DSP cards as big powerful modem cards...and while > that's certainly a good use for them...let's break that paradigm (oh > man...a marketing cliche'...my apologies) and see them for more than > that...what they really are...a crapload of processing power on a card > that could theoretically, to the best of my knowledge, run just about > any arbitrary code with just about any arbitrary type of interface on > the NIC. That's a *very* powerful thought IMO. > > Executive summary (I know, this should be at the top)...if you think of > the Total Control platform basically as a distributed processing router > platform...lot's of possibilities are opened up going forward. The > current code on there is getting to be pretty good and solid...but its > designed and written for a single specific function...limiting the > places where the TC platform could be used. This largely comes down to > be a business decision from 3Com (Lord help us there), but if they > decide that they don't want to limit the TC platform to being *only* an > access server (and personally, I think the distinction between access > server and router is a pretty thin line), then they need to start > thinking of the Arc as a router, not just an access server, and the > DSP's as generic interface cards, not modem/t1/pri cards. > > These thoughts are probably not articulated very well...they're just > thoughts that I've had in the back of my head for a while that I want to > get out to some other people to see what you all have to say about the > ideas. I know some people wouldn't be interested in all at using some > of the features...but what I'm trying to get at here is the overall > direction for development of the Arcs/TC's, not specific feature > requests...although I have included some specific feature requests in my > message...try not to focus on those specifically...they are mostly there > as examples for the overall direction I was thinking of. Some of these > thoughts have been expressed in the past to some people at 3Com, but I > don't think any one person has ever heard the totality of what I was > thinking of (not having had time to sit down with anyone for long enough > time to fully hash these thoughts out). > > So...there it is...let's hear what you think. :) > > --------------------------- > -- > 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. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 13:11:25

Thus spake Kevin Benton >On Wed, 15 Sep 1999, Jeff Mcadams wrote: >> 3Com just posted drivers for their NICs for Linux (to be honest, I did a >> double-take when I saw that, but think its tres cool!), so apparently >> they are beginning to foster a corporate culture of listening to >> customers and what they want (and I can't support this idea enough I >> don't think). >Great idea except that I don't see spending $10,000 just to get an ESP so >I can put Linux on it and run modems off it (even if they are digital). I >can spend a heck of a lot less, let an ARC run the dial-up and put a >stand-alone Linux box together to perform the rest of those functions... No, no, no.... :) This was in reference to ethernet NICs for PC...like 3c509's etc. :) No real connection to TC's...just a comment about 3Com in general. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-15 13:33:54

Again, if I want a router that allow multiple eth or ser ports... I'll but a cisco. Adding ARC's are expensive and limited compared to multi-slot eth/ser chassis. A 2e-2w blade for my 3640 is much cheaper than a new ARC or NIC for a TC (at this point). Having a dedicated packet bus for connecting chassis may be a step backward. 3Com *should* fix the multi-chassis MLPPP, not add circuit traces or cards. USR/3Com has a bad history of supporting new technology like OSPF (yeah.. thats a joke.. some 3Com humor) With very high density alternatives like the PM-4, TC needs to do one thing very well, like answer the phone and route to it. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 15 Sep 1999, Jeff Mcadams wrote: Snip > router isn't necessarily an access server. :) Basically, the HiPer > Arc, as an access server, is already doing everything that a router is > doing...and more...(well...ok...its a router with a rather limited > feature set at this point, but it *is* a router, nonetheless) it's

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 13:45:47

Thus spake Paul Farber >Again, if I want a router that allow multiple eth or ser ports... I'll but >a cisco. Adding ARC's are expensive and limited compared to multi-slot >eth/ser chassis. A 2e-2w blade for my 3640 is much cheaper than a new ARC >or NIC for a TC (at this point). Define "much." Last price list I got for cisco equip puts the 2e2w card at $2500...not much more than a whole Arc NAC/NIC combo. And besides...I'm not talking about having this within the next year or so...this is long-term thinking. >Having a dedicated packet bus for connecting chassis may be a step >backward. Who said anything about connecting chassis' together? I'm talking about letting the Arc's see the packet bus that's already in all of the chassis' that you own as a network interface to communicate between Arcs in the same chassis. >3Com *should* fix the multi-chassis MLPPP, not add circuit >traces or cards. What's wrong with multi-chassis MP? Works like a champ for me (once I got rid of my NETServers). >USR/3Com has a bad history of supporting new technology like OSPF >(yeah.. thats a joke.. some 3Com humor) Which is available and working in 4.2.x...yes it did take a while...but to 3Com's credit, its there and it looks pretty solid. >With very high density alternatives like the PM-4, TC needs to do one >thing very well, like answer the phone and route to it. Have you looked into buying a PM4 recently? You can't...they've been discontinued. PM3's will be soon...PM2's will stick around, but...big deal. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-15 14:44:25

> Define "much." Last price list I got for cisco equip puts the 2e2w card > at $2500...not much more than a whole Arc NAC/NIC combo. And > besides...I'm not talking about having this within the next year or > so...this is long-term thinking. That's a list price... who pays list price? A 2e-2w blade that can support 2 T-1's and 2 10Base-T's is cheaper and performs better then the arc. I would like the TC chassis to be one hell of an ACCESS SERVER. 3Com has routers and switches. Let THEM route and switch. Concentrate on answering the phone and compatibility. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net

Subject: (usr-tc) ARC/quad/NMC compatibility
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1999-09-15 15:06:30

Hi, in my old TCH, I wonder if replacing the Netserver by an ARC is ok? Will it be managed by the ol'NMC with no problems? What about Quad/PRI cards compatibility with the ARC? Regards, Martin

Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-09-15 15:22:08

On Wed, 15 Sep 1999, Steve Drees wrote: |On a portmaster 3 I can issue a show line0 and get a nice table showing |alarms and violations on the PRI. What's the equivalent command on a |HiperARC? At DSP (not HARC) console you can use: >chdev span span>disp spns - Marcelo

Subject: Re: (usr-tc) ARC/quad/NMC compatibility
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 15:25:29

Thus spake Martin Lathoud >in my old TCH, I wonder if replacing the Netserver by an ARC is ok? Will >it be managed by the ol'NMC with no problems? What about Quad/PRI cards >compatibility with the ARC? I run a bunch o quads with 5.9.9 and 5.10.9 with no problems with the Arc. Just make sure your NMC is the 16 meg (8 meg flash) version with the appropriate code and you should be fine as far as the nmc being able to handle the Arc. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) ARC/quad/NMC compatibility
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 15:25:29

Subject: (usr-tc) Question on Hiper DSP Code 2.0.81
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-15 15:40:31

Sometime back I remember seeing a post on the list that stated when using Hiper DSP code 2.0.81 the LPBK/D-ALM light will stay on green, can anyone please confirm this for me (we are not using NFAS right now)? Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com

Subject: (usr-tc) Default User Validation
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-15 15:54:34

This might seem like a stupid question, but I am curious, is there a way to validate a username of default using radius? It would never get sent to radius since it would match the default user in the local user table. Jim Johnson

Subject: Re: (usr-tc) Question on Hiper DSP Code 2.0.81
From: Clint R. Sparks <csparks@cqc.com>
Date: 1999-09-15 16:10:59

Thank you for your help and responding so quick. Clint R. Sparks ComQuest Internet Services csparks@cqc.com > Yes, in 2.0.x, the LPBK/D-ALM light indicates the D-channel state. > Solid green indicates that there is a Primary D channel up on that span. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 >

Subject: Re: (usr-tc) HiperARC equivalent of portmaster show line0
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-15 16:18:59

At 03:22 PM 9/15/99 -0300, you wrote: > At DSP (not HARC) console you can use: > > >chdev span > span>disp spns Here's a question; One of the lines shown in span1>dis spanst is Span1 Modem Not Available Count is: 7 yet all of the modems on that card appear to be working fine. Why's that? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Question on Hiper DSP Code 2.0.81
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-15 16:45:58

Thus spake Clint R. Sparks >Sometime back I remember seeing a post on the list that stated when using >Hiper DSP code 2.0.81 the LPBK/D-ALM light will stay on green, can anyone >please confirm this for me (we are not using NFAS right now)? Yes, in 2.0.x, the LPBK/D-ALM light indicates the D-channel state. Solid green indicates that there is a Primary D channel up on that span. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Weird traceroute problem on TC
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-15 19:54:44

OK, first let me say that I am too new to the TC platform to have even a small clue as to what the hell I'm doing. That being said, here is the situation. Any user dialed into the TC can traceroute out to any host on the net fine. If that same host tries to traceroute back, responses make it back all the way to the HARC ethernet port, then every other packet times out (well, it's the last hop, which is the client modem). In "playing" with different settings in the HARC, I _think_ I remember some CLI command that has something to do with how (or IF) the HARC will allow traces/pings to client modems. If _I_ traceroute to the client modem from MY network (on a different subnet from the HARC) I DO get a complete trace to the client. I can telnet to my core router and that traces OK also. I temporarily removed all access lists from my core to the world, in case I flubbed something up there. Nada. I did implement the fix for the HiperBomb telnet problem mentioned here a few weeks ago. But other than that, I can't think of anything I may have done to cause this. I have NO filters enabled in the HARC. My network with respect to the TC is as follows: TC---->Cisco Switch----->Cisco 3640----->WORLD No RIP. Simple static routing. I stumbled across this situation in trying to troubleshoot my question I posted a few days ago about IP traffic to client modems momentarily pausing then re-starting. I had people off-network tracing back, and every single one could not complete a trace to any connected client modem, yet I can, and they can trace out. You can try to trace in to 207.202.83.106 and see what I mean. Anyone have any ideas? I think I probably touched something I shouldn't have in HARM or the CLI. TIA, Scot NJaccess

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-16 17:31:24

On Wed, 15 Sep 1999, Paul Farber wrote: > There are still many issues with the DSP code that need to be resolved... > ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc. > Fix them first! The off-by-one SNMP errors are finally fixed in the 6.x.x NMC releases -- at least all the off-by-ones that I found. Never had any uptime problems. ISDN's OK for us, mostly. v.90 still needs work. (Be nice if all the Rockwell HCF chips disppeared off the planet first though.) The Quads work a hell of a lot better for this -- why are the code bases so different here? If it's all in assembler I can understand, but if it's in something more portable, I don't see why they have to behave so differently. Multilink PPP got real slow in the last DSP releases and needs work again. The ARC 4.2.x releases have a big problem with handling two routes with the same network number and different netmasks... (NOT fixed in 4.2.32) Other than that things seem to be working fine for us. (knock on plastic) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Igor Brezac <igor@ipass.net>
Date: 1999-09-16 18:04:34

I'd like to add support for the standard RFC Radius VSAs and reiterate the improvement of v90 and ISDN code on DSPs. -Igor > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews > Sent: Thursday, September 16, 1999 5:31 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :) > > > On Wed, 15 Sep 1999, Paul Farber wrote: > > > There are still many issues with the DSP code that need to > be resolved... > > ISDN reliability, v.90 compatibility, uptime, off by snmp 1 > errors, etc. > > Fix them first! > > The off-by-one SNMP errors are finally fixed in the 6.x.x NMC > releases -- > at least all the off-by-ones that I found. > > Never had any uptime problems. > > ISDN's OK for us, mostly. > > v.90 still needs work. (Be nice if all the Rockwell HCF > chips disppeared > off the planet first though.) The Quads work a hell of a lot > better for > this -- why are the code bases so different here? If it's all in > assembler I can understand, but if it's in something more portable, I > don't see why they have to behave so differently. > > Multilink PPP got real slow in the last DSP releases and > needs work again. > > The ARC 4.2.x releases have a big problem with handling two > routes with > the same network number and different netmasks... (NOT fixed > in 4.2.32) > > Other than that things seem to be working fine for us. > (knock on plastic) > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, > Frankfort KY > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Brian Elfert <brian@citilink.com>
Date: 1999-09-16 20:10:46

On Thu, 16 Sep 1999, Igor Brezac wrote: > I'd like to add support for the standard RFC Radius VSAs and reiterate the > improvement of v90 and ISDN code on DSPs. I've never heard of standard VSAs. VSAs are vendor specific attributes, so I have no idea how they could be standardized really. I'm sure there are some attributes the Total Control could support. For instance, Connect-Rate appears to be a valid attribute not used. Brian

Subject: Re: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-16 20:46:53

Thats still of long list of "not quite ready's". Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 16 Sep 1999, Mike Andrews wrote: > On Wed, 15 Sep 1999, Paul Farber wrote: > > > There are still many issues with the DSP code that need to be resolved... > > ISDN reliability, v.90 compatibility, uptime, off by snmp 1 errors, etc. > > Fix them first! > > The off-by-one SNMP errors are finally fixed in the 6.x.x NMC releases -- > at least all the off-by-ones that I found. > > Never had any uptime problems. > > ISDN's OK for us, mostly. > > v.90 still needs work. (Be nice if all the Rockwell HCF chips disppeared > off the planet first though.) The Quads work a hell of a lot better for > this -- why are the code bases so different here? If it's all in > assembler I can understand, but if it's in something more portable, I > don't see why they have to behave so differently. > > Multilink PPP got real slow in the last DSP releases and needs work again. > > The ARC 4.2.x releases have a big problem with handling two routes with > the same network number and different netmasks... (NOT fixed in 4.2.32) > > Other than that things seem to be working fine for us. (knock on plastic) > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com > "If you're not part of the solution.... you're part of the precipitate." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Radius Attribute IP_Pool_Name
From: Brian Becker <brian@semo.net>
Date: 1999-09-17 02:53:40

Reading the docs on the Total Control Radius server (I don't have it but was just reading how it works), I ran across the ability for RADIUS to select which ip pool is used when authenticating a user. This would solve a huge problem. According to 3com HiPerArc Docs - page E-473 Attributes 61 NAS-Port-Type F,L 62 Port-Limit 63 Login_LAT-Port NS 64 Prompt . . 217 Framed-IP-Addr-Pool-Name 250 Char-Noecho And on page E-445 in the Vendor Specific Attributes it says: 0x9024 IP-Address-Pool Sets the name of the IP address pool for Framed PPP/SLIP users. Values: ASCII string. Limit: 16 bytes User Types: Framed Packet Types: Access-Accept Default: None Use the following global command to set this parameter locally: add ip pool <pool_name> I've tried editing my dictionary file (I'm using Livingston v1.16 running a FreeBSD box) for attribute 217: ATTRIBUTE Framed-IP-Addr-Pool-Name 217 string and in my user file I've included the line: Framed-IP-Addr-Pool-Name = "testippool", which is the name of a pool. But I'm still getting the an ip from another pool. I set the pool to private. But still can't get it to use those ips. Also tried ATTRIBUTE IP_Pool_Name 0x9024 string But that hasn't worked either... Any ideas? Thanks, Brian

Subject: (usr-tc) Current Consumption
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-17 09:00:47

Can someone tell me the current consumption for: Quad-NAC Dual-PRI-NIC Dual-PRI-NAC Jim

Subject: Re: (usr-tc) Current Consumption
From: Marcelo Barros <thbarros@ntwxpress.com.br>
Date: 1999-09-17 10:21:00

Current (A) Current (A) Configuration Choices +5.2 Volt +/- 12.2 Volt Watts HiPer ARC 4 20.8 70.9 HiPer ARC Max. Set 7 36.4 124.1 HiPer DSP 4.3 22.4 76.2 HiPer DSP NIC only .6 3.1 10.6 HiPer DSP Set 4.9 25.5 86.9 EdgeServer Set 4.5 23.4 79.8 Digital Quad Modems 2.1 10.9 37.2 Quad Modem NIC 1 5.2 17.7 486 NETServer 3 15.6 53.2 NET Enet NIC 1.5 7.8 26.6 NET Token NIC 2 10.4 35.5 NMC (486SX) 3 15.6 53.2 NMC Enet NIC 1.5 7.8 26.6 Dual PRI NAC 1.5 7.8 26.6 Dual PRI NIC .5 2.6 8.9 At 09:00 9/17/99 -0400, you wrote: > > >Can someone tell me the current consumption for: > > Quad-NAC > Dual-PRI-NIC > Dual-PRI-NAC > >Jim > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Radius Attribute IP_Pool_Name
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-17 11:29:00

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker |Sent: Friday, September 17, 1999 2:54 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Radius Attribute IP_Pool_Name | | |Reading the docs on the Total Control Radius server (I don't have it but was |just reading how it works), I ran across the ability for RADIUS to select |which ip pool is used when authenticating a user. This would solve a huge |problem. | |According to 3com HiPerArc Docs - page E-473 |Attributes |61 NAS-Port-Type F,L |62 Port-Limit |63 Login_LAT-Port NS |64 Prompt |. |. |217 Framed-IP-Addr-Pool-Name |250 Char-Noecho | | |And on page E-445 in the Vendor Specific Attributes it says: |0x9024 IP-Address-Pool |Sets the name of the IP address pool for Framed PPP/SLIP users. |Values: ASCII string. Limit: 16 bytes |User Types: Framed |Packet Types: Access-Accept |Default: None |Use the following global command to set this parameter locally: |add ip pool <pool_name> | |I've tried editing my dictionary file (I'm using Livingston v1.16 running a |FreeBSD box) for attribute 217: | |ATTRIBUTE Framed-IP-Addr-Pool-Name 217 string | |and in my user file I've included the line: |Framed-IP-Addr-Pool-Name = "testippool", | |which is the name of a pool. But I'm still getting the an ip from another |pool. I set the pool to private. But still can't get it to use those ips. 217 Is an ascend attribute. The HARC will accept (some of) these in the 4.2.x code base. See the docs for a more complete list. |Also tried |ATTRIBUTE IP_Pool_Name 0x9024 string | The above will work with any HARC code. But your 1.1.6 Radius does not support 3com VSA's. -M

Subject: Re: (usr-tc) MPIP performance
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-17 12:34:59

Thus spake Robert von Bismarck >I have been trying unsuccessfully to make a MPIP connection to my TC pool >from a cisco 1603 for testing. >The links go up, everything is fine, until I begin a download, performance >is bad. I get something between 8KB/s and 10KB/s, while I get about 7 to >8KB/s with an ISDN TA hooked up to my PC. Hrmm...sounds like you're occasionally getting MP (note, not MPIP, MPIP is the protocol used between the TC's to coordinate MP bundling), and occasionally not. 10KB/s, while not fantastic, is in the range of bundled traffic. >The server is set up like this : >Add mpip client 111.222.333.1 sharedsecret secret >Add mpip client 111.222.333.2 sharedsecret secret >Add mpip client 111.222.333.3 sharedsecret secret >Add mpip client 111.222.333.4 sharedsecret secret >Add mpip client 111.222.333.5 sharedsecret secret >Add mpip client 111.222.333.6 sharedsecret secret >Set mpip server_state on >Set mpip client_state off >Set ntp primary_server ntp.server.ip.address Not sure if its the cause of your problems, but the MPIP server needs to be set up as a client of itself, so you need another add mpip client statement in there with the server's own IP address. >Everything goes through a 10/100Mb Switch (Cisco Catalyst 2924XL) and >default router for all those boards is a Cisco 7206 on the same subnet. Unless there's a problem with something other than the bundling, this really shouldn't matter. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) HiperARC/DSP console setup redux
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-17 14:42:52

Hi-- I've still got one DSP card that refuses to grant me a console; there is just a squeegum of doubt as to whether it was rebooted after upgrade to 2.0.81, but, I do notice one difference between it and the other DSP's; the Hardware rev level is 0.49, vs. my others that are at 0.53 and 0.54. Could the hardware rev have anything to do with anything? I've got exactly 1 other .49 rev level DSP, but...it's in a chassis with a Netserver so no help there.... 12 YES 24 Channel High Density Modem 24 DYNAMIC YES 13 YES 24 Channel High Density Modem 24 DYNAMIC NO 14 YES 24 Channel High Density Modem 24 DYNAMIC YES 15 YES 24 Channel High Density Modem 24 DYNAMIC YES Slot 13 is the one I'm concerned about. Upgrading from 2.0.19 to 2.0.81 DID fix the DSP in slot 15, and I am quite happily using the console feature now-- Anybody know? Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

Subject: (usr-tc) TC Routing Question
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-17 14:45:10

Several ARCs are set up in a single /22 network (CIDR block of 1024 addresses). Dialup IP Address pools are out of this block and the ARC's ethernet ports are also in this block. Now, if I want to set up an account in radius which can route a /28 block, can I use a /28 block out of this /22 block? When I tried it from the same block and the route showed up in the ARC correctly, but the traffic was not routing down the connection for some reason. Radius - Entry is like: test Password=route, Simultaneous-Use=1 Framed-IP-Address=xxx.xxx.62.3, Framed-Route="xxx.xxx.63.8/30 xxx.xxx.62.3 1" Relevant Pieces of the ARC's routing table: 0.0.0.0/0 NetMgr xxx.xxx.60.1 1 eth:1 127.0.0.1/H LOCAL 127.0.0.1 1 loopback xxx.xxx.60.0/22 LOCAL xxx.xxx.60.6 1 eth:1 xxx.xxx.60.6/H LOCAL xxx.xxx.60.6 1 eth:1 xxx.xxx.62.3/H LOCAL xxx.xxx.62.3 1 slot:14/mod:18 xxx.xxx.63.8/30 NetMgr xxx.xxx.62.3 1 slot:14/mod:18 xxx.xxx.63.255/H LOCAL xxx.xxx.63.255 1 eth:1 It seems that it should be able to work. If not, I guess I'll just have to get a completely different network block and break it up for the routed network. Thanks, Jim

Subject: Re: (usr-tc) TC Routing Question
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-17 15:02:08

Thus spake Jim Johnson >Several ARCs are set up in a single /22 network (CIDR block of 1024 >addresses). >Dialup IP Address pools are out of this block and the ARC's ethernet >ports are also in this block. >Now, if I want to set up an account in radius which can route a /28 >block, can I use a /28 block out of this /22 block? Hrmm...you're wanting to depend on proxy arp to take care of this for you then? Not sure specifically how this works, but try: enable ip proxy_arp_all_dialin and see if that does what you need. If not, you'll need to use some sort of active routing protocol (RIPv2 or newly available OSPF). The active routing protocol is the cleaner solution IMHO (I'm not a terribly big fan of proxy arp), but is a bit harder on the systems. FWIW, you shouldn't have to grab a block from outside the /22 just because you're using active routing...should be able to use the block inside the /22 with active routing just fine. >When I tried it from the same block and the route showed up in the ARC >correctly, but the traffic was not routing down the connection for some >reason. Because it never got to the Arc to be routed down the connection. Your next hop router assumed, since the route wasn't advertised via some active routing protocol, that the ip addresses within the /28 were local to the ethernet (based on its interface ip address and mask), sent out an arp request for the ip address it was trying to get to, but the Arc didn't know to proxy arp for it. >It seems that it should be able to work. If not, I guess I'll just have >to get a completely different network block and break it up for the >routed network. I think you should be able to get this to work. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Brian Elfert <brian@citilink.com>
Date: 1999-09-17 15:13:32

On Fri, 17 Sep 1999, Igor Brezac wrote: > > I've never heard of standard VSAs. VSAs are vendor specific > > attributes, > > so I have no idea how they could be standardized really. > > Read http://www.cis.ohio-state.edu/htbin/rfc/rfc2138.html. > There are many vendors who conform to RFC style VSAs: Livingston, RedBack, > even Ascend has an option for VSAs, just to name a few. There are some > features specific to ARC which should be configurable via radius. I guess I was confused. You want the format of the VSA to be standardized, not the VSAs themselves. I thought you wanted every product to output the exact same set of VSAs. Brian

Subject: RE: (usr-tc) TC Routing Question
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-17 15:33:34

Interestingly enough I DID have it enabled and all but one of my customers with routed subnets have been just fine; one on a compatible systems router jus wouldna work until I turned it off. Shrug. SMT -----Original Message----- Sent: Friday, September 17, 1999 3:29 PM On Fri, 17 Sep 1999, Jim Johnson wrote: > Does this have an effect on Framed-Routes? > > ENABLE IP SOURCE_ADDRESS_FILTER Yes -- it makes 'em break, from what I've read. Don't use source address filtering with customers getting subnets routed to them. You could try disabling it on those users via Radius (there's a VSA for it, I forget which one now). Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) TC Routing Question
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-17 15:46:38

Thanks for the quick reply. I was going to add a static route to the router once I got it working rather than turn on RIP. But the thing that is confusing me is that I was telnetted into the ARC and trying to ping or traceroute to an IP on the routed network block and it was not working. That seemed like am easy way to test it. Oh well, I added the static route to the router now and now traffic is dying the ARC board even from the outside. So I am still doing something wrong here. Does this have an effect on Framed-Routes? ENABLE IP SOURCE_ADDRESS_FILTER Jim Jeff Mcadams wrote: > > Thus spake Jim Johnson > >Several ARCs are set up in a single /22 network (CIDR block of 1024 > >addresses). > > >Dialup IP Address pools are out of this block and the ARC's ethernet > >ports are also in this block. > > >Now, if I want to set up an account in radius which can route a /28 > >block, can I use a /28 block out of this /22 block? > > Hrmm...you're wanting to depend on proxy arp to take care of this for > you then? > > Not sure specifically how this works, but try: > enable ip proxy_arp_all_dialin > and see if that does what you need. If not, you'll need to use some > sort of active routing protocol (RIPv2 or newly available OSPF). The > active routing protocol is the cleaner solution IMHO (I'm not a terribly > big fan of proxy arp), but is a bit harder on the systems. FWIW, you > shouldn't have to grab a block from outside the /22 just because you're > using active routing...should be able to use the block inside the /22 > with active routing just fine. > > >When I tried it from the same block and the route showed up in the ARC > >correctly, but the traffic was not routing down the connection for some > >reason. > > Because it never got to the Arc to be routed down the connection. Your > next hop router assumed, since the route wasn't advertised via some > active routing protocol, that the ip addresses within the /28 were local > to the ethernet (based on its interface ip address and mask), sent out > an arp request for the ip address it was trying to get to, but the Arc > didn't know to proxy arp for it. > > >It seems that it should be able to work. If not, I guess I'll just have > >to get a completely different network block and break it up for the > >routed network. > > I think you should be able to get this to work. > -- > 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.

Subject: RE: (usr-tc) HiPer Arc improvement thoughts followup :)
From: Igor Brezac <igor@ipass.net>
Date: 1999-09-17 15:53:37

> I've never heard of standard VSAs. VSAs are vendor specific > attributes, > so I have no idea how they could be standardized really. > Read http://www.cis.ohio-state.edu/htbin/rfc/rfc2138.html. There are many vendors who conform to RFC style VSAs: Livingston, RedBack, even Ascend has an option for VSAs, just to name a few. There are some features specific to ARC which should be configurable via radius. -Igor

Subject: (usr-tc) Filtering telnet access on HiPer ARC
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-17 16:02:41

Hello all, I would like to filter telnet access to the HiPer ARC cards on several of my TC chassis. I have an example filter that does not appear work and is giving me a "anonymous protocol" message when I attempt to verify the filter. Example filter where 10.0.0.2/32 is the one machine which is allowed telnet access to the ARC and 10.1.1.1 is the address of the ARC itself. #filter :IP 010 AND src-addr = 10.0.0.2/32; 011 AND dst-addr = 10.1.1.1/32; 012 ACCEPT tcp-dst-port = 23; 020 AND dst-addr = 10.1.1.1/32; 021 DENY tcp-dst-port = 23; 030 ACCEPT; Any obvious problems with this? I have similar filters working on all of my other equipment, I just don't know what the anonymous protocol message is trying to tell me and I can't seem to find any mention of it in any of the release notes or documentation. Running the latest HiperARC code, 4.2.?? Any suggestions would be appreciated, it is Friday and my brain is starting to shut down for the weekend :) Mike McHenry

Subject: Re: (usr-tc) TC Routing Question
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-17 16:28:33

On Fri, 17 Sep 1999, Jim Johnson wrote: > Does this have an effect on Framed-Routes? > > ENABLE IP SOURCE_ADDRESS_FILTER Yes -- it makes 'em break, from what I've read. Don't use source address filtering with customers getting subnets routed to them. You could try disabling it on those users via Radius (there's a VSA for it, I forget which one now). Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) TC Routing Question
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-17 17:06:55

Hmmmm. DISABLE IP SOURCE_ADDRESS_FILTER The routing started working perfectly. Ummm, maybe I don't understand what that setting does. Is that behavior broken? Jim Scott Trautman wrote: > > Interestingly enough I DID have it enabled and all but one of my customers > with routed subnets have been just fine; one on a compatible systems router > jus wouldna work until I turned it off. Shrug. > > SMT > > -----Original Message----- > From: Mike Andrews [mailto:mandrews@bit0.com] > Sent: Friday, September 17, 1999 3:29 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) TC Routing Question > > On Fri, 17 Sep 1999, Jim Johnson wrote: > > > Does this have an effect on Framed-Routes? > > > > ENABLE IP SOURCE_ADDRESS_FILTER > > Yes -- it makes 'em break, from what I've read. Don't use source address > filtering with customers getting subnets routed to them. You could > try disabling it on those users via Radius (there's a VSA for it, I > forget which one now). > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com > "If you're not part of the solution.... you're part of the precipitate." > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) HiperARC/DSP console setup redux
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-17 17:08:41

Dynamic is a function of a nmc_chassis awareness setting-- If not dynamic, you would have had to specify the type card in a given slot. With it on, it'll figur' it out all by itself. Console, the upgrade to 2.0.81 from 2.0.19 changed "no" to "yes" in all but this one case. Being able to get a console session without plugging in a physical console cable is pretty nifty. I'm running out of pm2 ports...:) SMT > -----Original Message----- > From: K Mitchell [mailto:mitch@keyconn.net] > Sent: Friday, September 17, 1999 4:55 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiperARC/DSP console setup redux > > > At 02:42 PM 9/17/99 -0500, Scott Trautman > <scottt@corp.gdinet.com> wrote: > >Hi-- > > > >I've still got one DSP card that refuses to grant me a > console; there is > >just a squeegum of doubt as to whether it was rebooted after > upgrade to > >2.0.81, but, I do notice one difference between it and the > other DSP's; the > >Hardware rev level is 0.49, vs. my others that are at 0.53 and 0.54. > > > >Could the hardware rev have anything to do with anything? > > > >I've got exactly 1 other .49 rev level DSP, but...it's in a > chassis with a > >Netserver so no help there.... > > > >12 YES 24 Channel High Density Modem 24 > DYNAMIC YES > >13 YES 24 Channel High Density Modem 24 > DYNAMIC NO > >14 YES 24 Channel High Density Modem 24 > DYNAMIC YES > >15 YES 24 Channel High Density Modem 24 > DYNAMIC YES > > I've got the opposite situation, I need 1 card changed to > DYNAMIC(although > I'm not sure what the difference does). All of mine are set > NO to console. > Should they be set to YES? > 1 YES 24 Channel High Density Modem 23 > DYNAMIC NO > 2 YES 24 Channel High Density Modem 23 > DYNAMIC NO > 3 YES 24 Channel High Density Modem 23 > STATIC NO > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) RE: Filtering telnet access on HiPer ARC
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-17 17:21:31

Ack, call me stupid and laugh, it is definately time to go home and sleep... For any interested parties the problem is :IP needs to be IP: in the filter rules... Mike McHenry -----Original Message----- Sent: Friday, September 17, 1999 4:03 PM Hello all, I would like to filter telnet access to the HiPer ARC cards on several of my TC chassis. I have an example filter that does not appear work and is giving me a "anonymous protocol" message when I attempt to verify the filter. Example filter where 10.0.0.2/32 is the one machine which is allowed telnet access to the ARC and 10.1.1.1 is the address of the ARC itself. #filter :IP 010 AND src-addr = 10.0.0.2/32; 011 AND dst-addr = 10.1.1.1/32; 012 ACCEPT tcp-dst-port = 23; 020 AND dst-addr = 10.1.1.1/32; 021 DENY tcp-dst-port = 23; 030 ACCEPT; Any obvious problems with this? I have similar filters working on all of my other equipment, I just don't know what the anonymous protocol message is trying to tell me and I can't seem to find any mention of it in any of the release notes or documentation. Running the latest HiperARC code, 4.2.?? Any suggestions would be appreciated, it is Friday and my brain is starting to shut down for the weekend :) Mike McHenry

Subject: (usr-tc) MPIP performance
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1999-09-17 17:46:33

Hello, I have been trying unsuccessfully to make a MPIP connection to my TC = pool from a cisco 1603 for testing. The links go up, everything is fine, until I begin a download, = performance is bad. I get something between 8KB/s and 10KB/s, while I get about 7 = to 8KB/s with an ISDN TA hooked up to my PC. Oh, yeah, we have 64k ISDN here, not some funky US-specific 56k stuff = ;-)=20 Here's the setup I have 6 HiperARC's that are clients and one HiperARC that is server Clients are : 111.222.333.1, 111.222.333.2, 111.222.333.3, = 111.222.333.4 111.222.333.5, 111.222.333.6 Server is : 111.222.333.10 The clients are set up like this : Add mpip server 111.222.333.10 sharedsecret secret Set mpip client_state on Set mpip server_state off Set ntp primary_server ntp.server.ip.address The server is set up like this : Add mpip client 111.222.333.1 sharedsecret secret Add mpip client 111.222.333.2 sharedsecret secret Add mpip client 111.222.333.3 sharedsecret secret Add mpip client 111.222.333.4 sharedsecret secret Add mpip client 111.222.333.5 sharedsecret secret Add mpip client 111.222.333.6 sharedsecret secret Set mpip server_state on Set mpip client_state off Set ntp primary_server ntp.server.ip.address Everything goes through a 10/100Mb Switch (Cisco Catalyst 2924XL) and default router for all those boards is a Cisco 7206 on the same subnet. Robert von BISMARCK Systems Engineer _________________________ SPAN* / Petrel Communications SA=20 T=E9l : + 41 22 304 47 47 Fax : + 41 21 304 47 99 e-mail : rvb@petrel.ch Web : http://ww.span.ch/

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-17 17:55:01

At 02:42 PM 9/17/99 -0500, Scott Trautman <scottt@corp.gdinet.com> wrote: >Hi-- > >I've still got one DSP card that refuses to grant me a console; there is >just a squeegum of doubt as to whether it was rebooted after upgrade to >2.0.81, but, I do notice one difference between it and the other DSP's; the >Hardware rev level is 0.49, vs. my others that are at 0.53 and 0.54. > >Could the hardware rev have anything to do with anything? > >I've got exactly 1 other .49 rev level DSP, but...it's in a chassis with a >Netserver so no help there.... > >12 YES 24 Channel High Density Modem 24 DYNAMIC YES >13 YES 24 Channel High Density Modem 24 DYNAMIC NO >14 YES 24 Channel High Density Modem 24 DYNAMIC YES >15 YES 24 Channel High Density Modem 24 DYNAMIC YES I've got the opposite situation, I need 1 card changed to DYNAMIC(although I'm not sure what the difference does). All of mine are set NO to console. Should they be set to YES? 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 YES 24 Channel High Density Modem 23 STATIC NO -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) HiperARC/DSP console setup redux
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-17 18:32:52

At 05:08 PM 9/17/99 -0500, you wrote: >Dynamic is a function of a nmc_chassis awareness setting-- >If not dynamic, you would have had to specify the type card in a given slot. >With it on, it'll figur' it out all by itself. Chassis awareness is on, shouldn't all of the cards match then, instead of one showing STATIC? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-17 18:54:21

Thus spake K Mitchell >At 05:08 PM 9/17/99 -0500, you wrote: >>Dynamic is a function of a nmc_chassis awareness setting-- >>If not dynamic, you would have had to specify the type card in a given slot. >>With it on, it'll figur' it out all by itself. >Chassis awareness is on, shouldn't all of the cards match then, instead of >one showing STATIC? Static assignments override chassis awareness. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-17 19:06:10

At 06:54 PM 9/17/99 -0400, Jeff wrote: >Thus spake K Mitchell > >>Chassis awareness is on, shouldn't all of the cards match then, instead of >>one showing STATIC? > >Static assignments override chassis awareness. How do I undo the static assignment? Also, how do I set the cards to Console: YES? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-17 19:47:33

Thus spake K Mitchell >At 06:54 PM 9/17/99 -0400, Jeff wrote: >>Thus spake K Mitchell >>>Chassis awareness is on, shouldn't all of the cards match then, instead of >>>one showing STATIC? >>Static assignments override chassis awareness. >How do I undo the static assignment? Also, how do I set the cards to >Console: YES? Not sure about the console part as I'm still using 1.2.x code, but the static assignment is undone by: set chassis slot x owner no Then if you have chassis_awareness disabled from the NMC, it'll pick up ownership as dynamic (should...may not happen right away). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-17 20:59:50

On Fri, 17 Sep 1999, K Mitchell wrote: > Also, how do I set the cards to Console: YES? set chas slot xx cons yes I think you have to be on static assignment for this to work, though.

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-17 21:03:19

At 07:47 PM 9/17/99 -0400, Jeff wrote: >>How do I undo the static assignment? Also, how do I set the cards to >>Console: YES? > >Not sure about the console part as I'm still using 1.2.x code, but the >static assignment is undone by: >set chassis slot x owner no I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's version numbering scheme, I'm not sure. >Then if you have chassis_awareness disabled from the NMC, it'll pick up >ownership as dynamic (should...may not happen right away). Once the change shows, I'd take ownership back? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-17 21:32:06

On Fri, 17 Sep 1999, K Mitchell wrote: > At 07:47 PM 9/17/99 -0400, Jeff wrote: > >>How do I undo the static assignment? Also, how do I set the cards to > >>Console: YES? > > > >Not sure about the console part as I'm still using 1.2.x code, but the > >static assignment is undone by: > >set chassis slot x owner no > > I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's > version numbering scheme, I'm not sure. 1.2.x code doesn't support the remote console thing anyway, you need 2.x for that... so the console setting is kinda useless there. From oldest to newest: 1.2.5 (oldest) 1.2.68 1.2.60 1.2.59 1.2.43 1.2.37 (newest before 2.x) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-17 21:39:04

Thus spake K Mitchell >At 07:47 PM 9/17/99 -0400, Jeff wrote: >I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's >version numbering scheme, I'm not sure. As Mike mentioned, 1.2.5 is the oldest...not so's you'd know it from the numbering. >>Then if you have chassis_awareness disabled from the NMC, it'll pick up >>ownership as dynamic (should...may not happen right away). >Once the change shows, I'd take ownership back? Well...you *can*, but that kinda defeats the purpuse. :) Once the change shows, it would be just as if the Arc had ownership...actually it *does* have ownership...just assigned by the NMC rather than assigned manually by you the admin. Once the change shows, all the requesite interfaces should be up. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiperARC/DSP console setup redux
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-17 21:44:20

At 09:39 PM 9/17/99 -0400, Jeff wrote: >Thus spake K Mitchell >>At 07:47 PM 9/17/99 -0400, Jeff wrote: >>I'm still running 1.2.x also, BTW is 1.2.5 newer or 1.2.60? With 3Com's >>version numbering scheme, I'm not sure. > >As Mike mentioned, 1.2.5 is the oldest...not so's you'd know it from the >numbering. > >>>Then if you have chassis_awareness disabled from the NMC, it'll pick up >>>ownership as dynamic (should...may not happen right away). > >>Once the change shows, I'd take ownership back? > >Well...you *can*, but that kinda defeats the purpuse. :) Once the >change shows, it would be just as if the Arc had ownership...actually it >*does* have ownership...just assigned by the NMC rather than assigned >manually by you the admin. Once the change shows, all the requesite >interfaces should be up. Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC NO 2 YES 24 Channel High Density Modem 23 DYNAMIC NO 3 NO 24 Channel High Density Modem 23 STATIC NO So I should be setting ownership of 1 and 2 to no also then? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) MPIP performance
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-18 05:17:53

Jeff Mcadams writes... >Not sure if its the cause of your problems, but the MPIP server needs to >be set up as a client of itself, so you need another add mpip client >statement in there with the server's own IP address. My MPIP server is not a client of itself, and it works fine. -- Aaron Nabil

Subject: RE: (usr-tc) Packet filtering strategies/netbus et al
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-18 10:48:20

Well, don't know about that "supports netserver syntax" as it didn't seem to work for me, but, I did get the filters to work just fine with the latest HiperARC Manager and new ARC code. The old ARC manager was a problem with filters. The ARC filters are actually pretty nifty and a lot more flexible than the familiar Netserver/Livingston variety. The AND to do port ranges saves a lot of tedium. For all like me that struggled some with all this, a couple notes: Might be all too obvious for many, but here you go anyway-- Most, I would assume, will want to apply filters per RADIUS authenticated dialup user, rather than the examples they give in the ARC pdf manual about interfaces and local ARC users. RADIUS user filter entry: Framed-Filter = "myfilter" You must then have both a "myfilter.in" and a "myfilter.out" on your ARC. The out generally is just a permit/accept is all, but it has to be there. The .in and .out is assumed by the ARC to the Framed-Filter as was on the Netserver. IE, having a filter on the arc of the name "myfilter" won't do anything for you. To turn on filter access, you'll need to, at the arc: set modem_group all filter_access on If you don't have the filters on the ARC that are being applied (in this example, myfilter.in, out), your users will not be able to get online at all. They'll be dropped right after authentication. modem_group all as in all your interfaces. I also used the verify filter myfilter.in Command on the ARC to get feedback about any errors I had as I edited. Used the ARC Manager to edit them. Chapter 12 in the latest ARC documentation is pretty decent on how the filters work and has enough examples to get you going. Also note that during testing I was trying to view a connection with "sh int slot:x/mod:y", and it does not indicate an Input or Output filter, but there definately is one there as determined by testing. It does show "Filter Access: ON" after doing the set modem_group....command. That's my little filtering brain dump. Wasn't that bad once I got over the dread of doing it. SMT > -----Original Message----- > From: Aaron Nabil [mailto:nabil@spiritone.com] > Sent: Wednesday, September 01, 1999 3:37 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Packet filtering strategies/netbus et al > > > Scott Trautman writes... > >..and finally...anyone doing a lot with the ARC filters? > Anyone interested > >in making some bucks converting a couple Netserver filters > to an ARC filter? > > Easy money, considering the ARC supports netserver syntax filters. > > > -- > Aaron Nabil>

Subject: (usr-tc) FAILED Realm processing error...
From: pferraro@wna-linknet.com
Date: 1999-09-18 12:19:52

Does anyone know what this mans EXACTLY? We have seen a couple of our users get this and it also makes the radiusd dump core. I have no idea how to check out a radiusd.core file. THe radius we are using is MERIT 3.6B Any help or comments appreciated! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-18 15:29:35

OK, got a little challenge for you all. :) On a HiPer ARC... Given a dialup user's IP address, find their username. As fast as possible. (Think CGI here.) I've had code to do this, but it is slow, and it broke on ARC release 4.2.x... forcing me to use an even slower method. :p I'd like to speed it up. The best I can do right now is two snmpwalks, followed by a single snmpget. I'd like to get rid of the snmpwalks, but for some reason the ARC will not let you directly snmpget some variables -- you have to walk the whole table it's contained in. (And this got worse in 4.2.x. A bug, I would think.) Can anyone get it down to just snmpgets? (3Com?) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-18 15:46:30

Quickest way would be to telnet into the ARC.. and snmp solution would involve interating through the entite OID tree till you got a match. An expect scrript or perl script would be much quicker. Just do telnet in, do a sho ip networks and grep the results. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Sat, 18 Sep 1999, Mike Andrews wrote: > OK, got a little challenge for you all. :) > > On a HiPer ARC... Given a dialup user's IP address, find their username. > As fast as possible. (Think CGI here.) > > I've had code to do this, but it is slow, and it broke on ARC release > 4.2.x... forcing me to use an even slower method. :p I'd like to speed > it up. > > The best I can do right now is two snmpwalks, followed by a single > snmpget. I'd like to get rid of the snmpwalks, but for some reason the > ARC will not let you directly snmpget some variables -- you have to walk > the whole table it's contained in. (And this got worse in 4.2.x. A bug, > I would think.) > > Can anyone get it down to just snmpgets? > > (3Com?) > > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com > "If you're not part of the solution.... you're part of the precipitate." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-18 20:44:32

Thus spake Mike Andrews >OK, got a little challenge for you all. :) >On a HiPer ARC... Given a dialup user's IP address, find their username. >As fast as possible. (Think CGI here.) OK...given my knowledge of the hiperarc.mib and snmp (both of which aren't terribly complete). The quickest executing way of doing this would be to snmpwalk usrCipPortIndex (Index'es tend to return considerably faster than when you're actually pulling data), then do gets (so you can have multiple OIDs in one request...again...faster than a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled in with the index values that you collected from the walk. When you find the IP address you need, then you can just do a get on usrCipUserName.xxxx, with "xxxx" this time being the specific index found from the PortIpAddress. Sorta two walks...but one can be implemented as a few gets which will go faster than ping-ponging the walk if you're really pressed for speed. Not sure how some of the perl modules deal with it, but it seems to me, that theoretically you could put multiple getnext requests in an individual SNMP packet to an agent. You would have to have the application have the intelligence to do this, but perhaps some of the perl modules do this? I haven't checked into them enough to know. If they do...you could grab all the information that you need with, essentially, a single walk...just a single walk with multiple SNMP getnext requests. >I've had code to do this, but it is slow, and it broke on ARC release >4.2.x... forcing me to use an even slower method. :p I'd like to speed >it up. >The best I can do right now is two snmpwalks, followed by a single >snmpget. I suspect we're kinda thinkin' of the same way then...maybe I've given you some hints on how you can actually code it (I know...makes the code considerably more complex...but I think the SNMP ops will be considerably quicker) that will help out. >I'd like to get rid of the snmpwalks, but for some reason the >ARC will not let you directly snmpget some variables -- you have to walk >the whole table it's contained in. (And this got worse in 4.2.x. A bug, >I would think.) Eh? Like what? >Can anyone get it down to just snmpgets? Uhm...don't know that I can cleanly. I might be able to come up with a kludge way to do it though. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) A PERSONAL Thank You - A Hurricane Floyd Story
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-18 22:40:27

We were severely impacted by Hurricane Floyd. A major regional Bell Atlantic/AT&T switching facility in Rochelle Park, NJ was flooded out at 6AM on Friday. The building was 4 feet under water. All of our upstream T's go through this facility, so we were dead in the water. There was no power to the building at all. Our primary upstream feed comes from IDT. We were in contact with them, and they indicated that the rest of their network was up. They have NO ISDN POP's AT ALL, so I was unable to bring up any kind of dial backup. We were still dead. And getting real info from BA support is almost impossible. I drove to Rochelle Park myself this morning to assess the damage first-hand. The flood waters had receeded. There were no less than 6 AT&T trailers on site, over 200 people, 30 trucks, the National Guard, and local law enforcement. AC power had been restored, but DC power was still out, which obviously means the frame, all DAC's, fiber equipment and switches were still down. An AT&T "Network Disaster Recovery" team member gave me a little bit of info -- they were trucking in some special DC power equipment and cabling from Southern NJ. Once that was patched into the building, they would try to power the equipment back up. They believed that the damages were limited to power, and that the equipment itself was OK. But they wouldn't know for sure until they could light it up. This outage not only effected all T's into and out of the area, but also the local BA switch, AT&T toll, and cellular for many carriers. In addition, I've beed told that it handles a lot of the AT&T long distance switching for the Northeast corridor, including traffic from northern NJ into NYC, and some international traffic destined for the main AT&T center in Bedminster NJ. At 1PM today, I received a call from another local ISP, Net Access Corporation in Denville, NJ. Their upstream bypasses Rochelle Park, so they were unaffected by it. They offered to allow me to connect, via ISDN, to their network, FREE OF CHARGE, and they would broadcast BGP routes for all of our networks. This call came OUT OF THE BLUE. I hurried over to the ops center, and began configuring a few BRI's on a Cisco 2600 for dial-out. A half-hour later, we were hot, and our routes started propagating. Within an hour, we were back up and online, although crippled, but better than dead. I know that Net Access uses Ascend equipment, so they're probably not on this list. But I wanted to take this opportunity to broadcast this thank you to Alex Rubenstein, and Net Access in general, for extending a helping hand to someone who would normally be considered a competitor. It is so refreshing to see another ISP offer such assistance during a time of crisis. If the need ever arises in the future, I will most certainly reciprocate. And I urge eveyone else on this list to do the same should you ever see the opportunity to help another ISP hit so hard. As of 9:15 PM, the switching center is still out. Traffic is slowly moving in and out of my network. I would have liked to configure the PRI's on my TC to dial out to them, but because I am so new with the TC, it was easier for me to do it with the 2600. If anyone knows how I can configure my TC to dial out, I would appreciate any config tips. I would like to get an entire PRI worth of traffic connected to them, should this problem not be corrected by Monday morning. And once again, thanks Net Access... Regards, Scot NJ Internet Access

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-09-18 22:40:28

On Sat, 18 Sep 1999, Jeff Mcadams wrote: > >On a HiPer ARC... Given a dialup user's IP address, find their username. > >As fast as possible. (Think CGI here.) > > OK...given my knowledge of the hiperarc.mib and snmp (both of which > aren't terribly complete). The quickest executing way of doing this > would be to snmpwalk usrCipPortIndex (Index'es tend to return > considerably faster than when you're actually pulling data), then do > gets (so you can have multiple OIDs in one request...again...faster than > a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled > in with the index values that you collected from the walk. When you > find the IP address you need, then you can just do a get on > usrCipUserName.xxxx, with "xxxx" this time being the specific index > found from the PortIpAddress. Sorta two walks...but one can be > implemented as a few gets which will go faster than ping-ponging the > walk if you're really pressed for speed. (rest deleted) Can you give an example in code? (shell scripts?) Actually, we do it by using an expect script to telnet to the host and get the results back usually within 3-5 seconds no matter how many users are logged on. Of course, it's up to you to parse out what you need vs what you don't need... Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) WARNING: HARC 4.2.32 Crashed after deleting QuickSetup.cfg !!!
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-09-18 22:44:53

See above... After this situation, we could not get the ARC to take 4.2.32 code unless we deleted the router config, then started over with older code. Even still, 4.2.32 would not run properly. We do have an open ticket with 3Com on this. BTW, this was not an isolated incident. I was able to reproduce it on another working HARC which was in service till I hosed it. When I re-loaded the code back to an older version, things went back to semi-normal as usual. (What is normal anyway?) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-19 16:20:44

Thus spake Kevin Benton >On Sat, 18 Sep 1999, Jeff Mcadams wrote: >> OK...given my knowledge of the hiperarc.mib and snmp (both of which >> aren't terribly complete). The quickest executing way of doing this >> would be to snmpwalk usrCipPortIndex (Index'es tend to return >> considerably faster than when you're actually pulling data), then do >> gets (so you can have multiple OIDs in one request...again...faster than >> a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled >> in with the index values that you collected from the walk. When you >> find the IP address you need, then you can just do a get on >> usrCipUserName.xxxx, with "xxxx" this time being the specific index >> found from the PortIpAddress. Sorta two walks...but one can be >> implemented as a few gets which will go faster than ping-ponging the >> walk if you're really pressed for speed. >Can you give an example in code? (shell scripts?) Nope, 'cause I'm *seriously* not a programmer, and none of the snmp util toolkits do this parallelization of snmpwalks that I'm aware of. >Actually, we do it by using an expect script to telnet to the host and get >the results back usually within 3-5 seconds no matter how many users are >logged on. Of course, it's up to you to parse out what you need vs what >you don't need... That doesn't scale to a large number of chassis' well, and also breaks easily on upgrades of code. SNMP should be a bit more robust to code upgrades not breaking the algorithm. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Playing with OSPF
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-20 06:14:55

I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have started looking at switching them from RIP to OSPF. Everything is working as I would expect for host dialins, HOWEVER it seems that the ARC is not advertising any Framed-Routes setup through radius. For example, an entry like the following in radius: username Auth-Type=System Service-Type=Framed-User, Framed-IP-Address = 192.168.0.1, Framed-Route = "10.0.0.1/24 192.168.0.1 1", Framed-Routing = None, Once username dials into the TC the host route for 192.168.0.1 is correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a setting here or is this the normal behavior for the ARC card? Every other piece of equipment I have recognizes this route added in through radius and correctly advertise the route through OSPF. Mike

Subject: Re: (usr-tc) Radius Attribute IP_Pool_Name
From: Brett Murphy <me@murf.net>
Date: 1999-09-20 09:34:02

I hacked cistron radius 1.5.3 with something to the following effect /* BM append the IP POOL name */ /* vendor specific attribute for POOL_NAME is 0x9024 A summary of the Vendor-Specific Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order, as defined in the Assigned Numbers RFC [2]. */ if(ip_pool_name != (char *)NULL) { len = strlen(ip_pool_name); if(len > 0 && len < AUTH_STRING_LEN) { *ptr++ = 26; *ptr++ = len + 10; *ptr++ = 0; *ptr++ = 0; *ptr++ = 1; *ptr++ = 173; *ptr++ = 0; *ptr++ = 0; *ptr++ = 144; *ptr++ = 36; memcpy(ptr, ip_pool_name, len); ptr += len; total_length += len + 10; } All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd. -----Original Message----- > > >|-----Original Message----- >|From: owner-usr-tc@lists.xmission.com >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker >|Sent: Friday, September 17, 1999 2:54 AM >|To: usr-tc@lists.xmission.com >|Subject: (usr-tc) Radius Attribute IP_Pool_Name >| >| >|Reading the docs on the Total Control Radius server (I don't have it but was >|just reading how it works), I ran across the ability for RADIUS to select >|which ip pool is used when authenticating a user. This would solve a huge >|problem. >| >|According to 3com HiPerArc Docs - page E-473 >|Attributes >|61 NAS-Port-Type F,L >|62 Port-Limit >|63 Login_LAT-Port NS >|64 Prompt >|. >|. >|217 Framed-IP-Addr-Pool-Name >|250 Char-Noecho >| >| >|And on page E-445 in the Vendor Specific Attributes it says: >|0x9024 IP-Address-Pool >|Sets the name of the IP address pool for Framed PPP/SLIP users. >|Values: ASCII string. Limit: 16 bytes >|User Types: Framed >|Packet Types: Access-Accept >|Default: None >|Use the following global command to set this parameter locally: >|add ip pool <pool_name> >| >|I've tried editing my dictionary file (I'm using Livingston v1.16 running a >|FreeBSD box) for attribute 217: >| >|ATTRIBUTE Framed-IP-Addr-Pool-Name 217 string >| >|and in my user file I've included the line: >|Framed-IP-Addr-Pool-Name = "testippool", >| >|which is the name of a pool. But I'm still getting the an ip from another >|pool. I set the pool to private. But still can't get it to use those ips. >217 Is an ascend attribute. The HARC will accept (some of) these in the 4.2.x >code base. See the docs for a more complete list. > >|Also tried >|ATTRIBUTE IP_Pool_Name 0x9024 string >| > >The above will work with any HARC code. But your 1.1.6 Radius does not support >3com VSA's. > >-M > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-20 09:52:35

Thus spake Paul Farber >> >Actually, we do it by using an expect script to telnet to the host >> >and get the results back usually within 3-5 seconds no matter how >> >many users are logged on. Of course, it's up to you to parse out >> >what you need vs what you don't need... >> That doesn't scale to a large number of chassis' well, and also breaks >> easily on upgrades of code. SNMP should be a bit more robust to code >> upgrades not breaking the algorithm. :) >Telnet will not break on code upgrades... list ip networks worked on >netserver and ARC. Place a common telnet account on every ARC and use >that. I have 3 ARC's that use this telnet setup to get user info... >hasn't broke with any of the upgrades I've done. No, telnet itself won't break, but the parsing might if the output format changes (which is not uncommon between code revs.) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-20 09:54:45

SNIP > >Actually, we do it by using an expect script to telnet to the host and get > >the results back usually within 3-5 seconds no matter how many users are > >logged on. Of course, it's up to you to parse out what you need vs what > >you don't need... > > That doesn't scale to a large number of chassis' well, and also breaks > easily on upgrades of code. SNMP should be a bit more robust to code > upgrades not breaking the algorithm. :) SNIP Telnet will not break on code upgrades... list ip networks worked on netserver and ARC. Place a common telnet account on every ARC and use that. I have 3 ARC's that use this telnet setup to get user info... hasn't broke with any of the upgrades I've done. Perl's Net:Telnet is pretty damed good and very easy to modify. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-20 10:29:11

Thus spake Paul Farber >It hasen't yet. The seperator for page breaks did... but the information >line has not. Yup, and the Arc is still very young. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-20 10:30:40

It hasen't yet. The seperator for page breaks did... but the information line has not. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 20 Sep 1999, Jeff Mcadams wrote: > Thus spake Paul Farber > >> >Actually, we do it by using an expect script to telnet to the host > >> >and get the results back usually within 3-5 seconds no matter how > >> >many users are logged on. Of course, it's up to you to parse out > >> >what you need vs what you don't need... > > >> That doesn't scale to a large number of chassis' well, and also breaks > >> easily on upgrades of code. SNMP should be a bit more robust to code > >> upgrades not breaking the algorithm. :) > > >Telnet will not break on code upgrades... list ip networks worked on > >netserver and ARC. Place a common telnet account on every ARC and use > >that. I have 3 ARC's that use this telnet setup to get user info... > >hasn't broke with any of the upgrades I've done. > > No, telnet itself won't break, but the parsing might if the output > format changes (which is not uncommon between code revs.) > -- > 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. >

Subject: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up by OSPF broadcasts?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-20 10:40:54

|-----Original Message----- |From: owner-totalcontrol@totalservice.3com.com |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike |McHenry |Sent: Monday, September 20, 1999 7:01 AM |Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF |broadcasts? | | |Reply to user-forum-totalcontrol@totalservice.3com.com | | |I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have |started looking at switching them from RIP to OSPF. Everything is |working as I would expect for host dialins, HOWEVER it seems that the |ARC is not advertising any Framed-Routes setup through radius. | |For example, an entry like the following in radius: | |username Auth-Type=System | Service-Type=Framed-User, | Framed-IP-Address = 192.168.0.1, | Framed-Route = "10.0.0.1/24 192.168.0.1 1", | Framed-Routing = None, | |Once username dials into the TC the host route for 192.168.0.1 is |correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I |missing a setting here or is this the normal behavior for the ARC card? |Every other piece of equipment I have recognizes this route added in |through radius and correctly advertise the route through OSPF. | At this time you have to add a "SEND Policy" to get the framed-routes to advertise. This iss done by "ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE"

Subject: (usr-tc) Another "so this is how you did it with a netserver" question: pt
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 10:50:34

Hi-- Really about the last question on my list about ARC's is how do I do a ptrace on an ARC like I did with Netservers? Was quite simple to add a little filter with the appropriate IP's, then ptrace filter and I'd get the output from the Netserver. Is there an equivilent on the ARC? (please tell me it's as easy to use...too...) SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

Subject: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up by OSPF broadcasts?
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-20 10:58:44

I was thinking along those lines, one question though. Can I specify a superset of the network blocks I want advertised in my SENDPOLICY? For example, I know that all of my framed routes will come out of a supernet of 4 class C blocks, can I specify add ospf sendpolicy 10.0.0.1/22 source REMOTE action ADVERTISE or do I need to list every possible framed-route separately like add ospf sendpolicy 10.0.0.1/28 source REMOTE action ADVERTISE add ospf sendpolicy 10.0.0.64/28 source REMOTE action ADVERTISE add ospf sendpolicy 10.0.0.128/28 source REMOTE action ADVERTISE add ospf sendpolicy 10.0.0.192/28 source REMOTE action ADVERTISE etc... Thanks for your response :) Mike -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski Sent: Monday, September 20, 1999 10:41 AM up by OSPF broadcasts? |-----Original Message----- |From: owner-totalcontrol@totalservice.3com.com |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike |McHenry |Sent: Monday, September 20, 1999 7:01 AM |Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF |broadcasts? | | |Reply to user-forum-totalcontrol@totalservice.3com.com | | |I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have |started looking at switching them from RIP to OSPF. Everything is |working as I would expect for host dialins, HOWEVER it seems that the |ARC is not advertising any Framed-Routes setup through radius. | |For example, an entry like the following in radius: | |username Auth-Type=System | Service-Type=Framed-User, | Framed-IP-Address = 192.168.0.1, | Framed-Route = "10.0.0.1/24 192.168.0.1 1", | Framed-Routing = None, | |Once username dials into the TC the host route for 192.168.0.1 is |correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I |missing a setting here or is this the normal behavior for the ARC card? |Every other piece of equipment I have recognizes this route added in |through radius and correctly advertise the route through OSPF. | At this time you have to add a "SEND Policy" to get the framed-routes to advertise. This iss done by "ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE" - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) RE: Another "so this is how you did it with a netserver" question
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 11:33:36

Okay, so I did a little research and found 'monitor ppp'. Nifty enough except the output is useless to me: Incoming PPP Data on interface: slot:12/mod:17 UTCP_DATA ff 03 00 2f 45 00 00 28 74 44 40 00 40 07 3f e9 9c 2e 7a fa ... Outgoing PPP Data on interface: slot:12/mod:17 IP_DATA 45 00 00 89 61 ea 40 00 30 06 61 e2 ce 87 a0 f2 9c 2e 7a fa ... Incoming PPP Data on interface: slot:12/mod:17 CTCP_DATA ff 03 00 2d 54 07 bd 00 61 48 54 54 50 2f 31 2e 31 20 32 30 ... Outgoing PPP Data on interface: slot:12/mod:17 IP_DATA 45 00 00 28 b2 ea 40 00 30 06 11 43 ce 87 a0 f2 9c 2e 7a fa ... The format with the Netserver ptrace was infinately useful-- Gave the protocol, the ip address source and destination and port source and destination. This must require a "super decoder ring" to figure out-- Anything I'm missing here? SMT From: Scott Trautman Sent: Monday, September 20, 1999 10:51 AM ptrace Hi-- Really about the last question on my list about ARC's is how do I do a ptrace on an ARC like I did with Netservers? Was quite simple to add a little filter with the appropriate IP's, then ptrace filter and I'd get the output from the Netserver. Is there an equivilent on the ARC? (please tell me it's as easy to use...too...) SMT Scott Trautman 608-240-4638,4637fax Global Dialog Internet www.gdinet.com 2810 Crossroads, STE LL2 Madison WI 53718

Subject: RE: (usr-tc) RE: Another "so this is how you did it with a netser
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 11:57:26

Hmmm...well, that's pretty sad then. It took something I was able to do yesterday on a netserver, which was show a user that their connection was misconfigured, (cut and paste into email and there you go) into a long complicated thing my techs will obviously not be able to do, and probably me either. Maybe I'm the only one out there using it, but that was a strong, simple feature. This aint that. Pretty much useless to 99% of the people. Shrug. I <like> that you can specify username, next session, that kind of thing, but getting hex back, who's under the impression that's going to be useful? SMT -----Original Message----- Sent: Monday, September 20, 1999 11:46 AM netserver" question : ptrace Maybe you're looking for 'set packet_logging logging all packet_size 80', wihch tells the ARC to syslog the first 80 bytes of every packet that matches any filter. Unfortunately it does exactly that -- just logs the bytes, without interpreting any of it... so you have to parse the output to decode the TCP/IP headers to make any sense out of it. 'monitor ppp' monitors the entire PPP session, not just the part that matches a filter. And again, that's kinda raw output, which needs a script to decode and make sense of. It sounds like we need a web page like Livingston's old PPP Decoder Ring page, where you could paste 'debug 0x51' output into their web page and get something intelligent back. Maybe we need a worklike for 'monitor ppp'. That'll give me something more interesting to waste the afternoon on than cleaning up our customer database :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." On Mon, 20 Sep 1999, Scott Trautman wrote: > Okay, so I did a little research and found 'monitor ppp'. > > Nifty enough except the output is useless to me: > > Incoming PPP Data on interface: slot:12/mod:17 > UTCP_DATA ff 03 00 2f 45 00 00 28 74 44 40 00 40 07 3f e9 9c 2e 7a fa > ... [munch] > ... > > The format with the Netserver ptrace was infinately useful-- > Gave the protocol, the ip address source and destination and port source and > destination. > This must require a "super decoder ring" to figure out-- > > Anything I'm missing here? > > SMT > > From: Scott Trautman > Sent: Monday, September 20, 1999 10:51 AM > To: 'usr-tc@lists.xmission.com' > Subject: Another "so this is how you did it with a netserver" question: > ptrace > > > Hi-- > > Really about the last question on my list about ARC's is how do I do a > ptrace on an ARC like I did with Netservers? > > Was quite simple to add a little filter with the appropriate IP's, then > ptrace filter > > and I'd get the output from the Netserver. > > Is there an equivilent on the ARC? (please tell me it's as easy to > use...too...) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) RE: Another "so this is how you did it with a netserver"
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-20 12:46:10

Maybe you're looking for 'set packet_logging logging all packet_size 80', wihch tells the ARC to syslog the first 80 bytes of every packet that matches any filter. Unfortunately it does exactly that -- just logs the bytes, without interpreting any of it... so you have to parse the output to decode the TCP/IP headers to make any sense out of it. 'monitor ppp' monitors the entire PPP session, not just the part that matches a filter. And again, that's kinda raw output, which needs a script to decode and make sense of. It sounds like we need a web page like Livingston's old PPP Decoder Ring page, where you could paste 'debug 0x51' output into their web page and get something intelligent back. Maybe we need a worklike for 'monitor ppp'. That'll give me something more interesting to waste the afternoon on than cleaning up our customer database :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." On Mon, 20 Sep 1999, Scott Trautman wrote: > Okay, so I did a little research and found 'monitor ppp'. > > Nifty enough except the output is useless to me: > > Incoming PPP Data on interface: slot:12/mod:17 > UTCP_DATA ff 03 00 2f 45 00 00 28 74 44 40 00 40 07 3f e9 9c 2e 7a fa > ... [munch] > ... > > The format with the Netserver ptrace was infinately useful-- > Gave the protocol, the ip address source and destination and port source and > destination. > This must require a "super decoder ring" to figure out-- > > Anything I'm missing here? > > SMT > > From: Scott Trautman > Sent: Monday, September 20, 1999 10:51 AM > To: 'usr-tc@lists.xmission.com' > Subject: Another "so this is how you did it with a netserver" question: > ptrace > > > Hi-- > > Really about the last question on my list about ARC's is how do I do a > ptrace on an ARC like I did with Netservers? > > Was quite simple to add a little filter with the appropriate IP's, then > ptrace filter > > and I'd get the output from the Netserver. > > Is there an equivilent on the ARC? (please tell me it's as easy to > use...too...)

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-20 12:53:44

All I was really hoping for here was that someone would give me some useful OID's that might be faster than what I was using. :) I did manage to reduce it from two snmpwalks down to one though. What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9 (usrCipPortIpAddress) -- the OIDs returned contain the port number, the values returned contain the IP address. Find the OID that matches, extract the port number, then get the username via an snmpget on 1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName). The performance problem I was having was the snmpwalk I had in Perl didn't return the OIDs, just the values, so I had to do a second walk to the the port numbers. That made the entire process take about 9 seconds from start to end, which is just too long when you've got it in a CGI that's running in a frame on your home page. :) I did some brain surgery on my snmpwalk and got it to return both OIDs and values, and that sped it up to about 4 seconds. It also let me speed up another program or two I had (like 'arcwho') by removing one walk from each of those. Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full second or two faster than the Perl one I have. :p It'd still be nice if there was a way to not have to walk a full table just to find one value... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." On Sat, 18 Sep 1999, Mike Andrews wrote: > OK, got a little challenge for you all. :) > > On a HiPer ARC... Given a dialup user's IP address, find their username. > As fast as possible. (Think CGI here.) > > I've had code to do this, but it is slow, and it broke on ARC release > 4.2.x... forcing me to use an even slower method. :p I'd like to speed > it up. > > The best I can do right now is two snmpwalks, followed by a single > snmpget. I'd like to get rid of the snmpwalks, but for some reason the > ARC will not let you directly snmpget some variables -- you have to walk > the whole table it's contained in. (And this got worse in 4.2.x. A bug, > I would think.) > > Can anyone get it down to just snmpgets? > > (3Com?)

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-20 13:00:46

On Sat, 18 Sep 1999, Jeff Mcadams wrote: > OK...given my knowledge of the hiperarc.mib and snmp (both of which > aren't terribly complete). The quickest executing way of doing this > would be to snmpwalk usrCipPortIndex (Index'es tend to return > considerably faster than when you're actually pulling data), then do > gets (so you can have multiple OIDs in one request...again...faster than > a ping pong walk) on usrCipPortIpAddress.xxxx with "xxxx" being filled > in with the index values that you collected from the walk. When you > find the IP address you need, then you can just do a get on > usrCipUserName.xxxx, with "xxxx" this time being the specific index > found from the PortIpAddress. Sorta two walks...but one can be > implemented as a few gets which will go faster than ping-ponging the > walk if you're really pressed for speed. That's exactly what I had before. :) I removed the usrCipPortIndex walk by using the OIDs returned by the usrCipPortIpAddress walk and peeling the port number off the end. > >I'd like to get rid of the snmpwalks, but for some reason the > >ARC will not let you directly snmpget some variables -- you have to walk > >the whole table it's contained in. (And this got worse in 4.2.x. A bug, > >I would think.) > > Eh? Like what? Well, now that I look at it, it's behaving itself for the tables above... but... there are/were some tables where you cannot snmpget the individual values in the table. For instance: % snmpwalk -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah | grep value enterprises.usr.blah.blah.blah.foo = "value" but then try to get it directly and it fails: % snmpget -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah.foo This name doesn't exist: enterprises.usr.blah.blah.blah.foo Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-20 13:12:14

Thus spake Mike Andrews >That's exactly what I had before. :) I removed the usrCipPortIndex walk >by using the OIDs returned by the usrCipPortIpAddress walk and peeling the >port number off the end. Man...maybe we're using different PERL modules? The one we have will walk through 96 ports of data in something like a second or two...its *quite* fast....and that's displaying the output as it gets it, so its probably slowed down considerably by the display output. We're using http://cpan.valueclick.com/authors/id/GSM/SNMP-1.8.2.tar.gz and it seems to be quite quick. Also seems, from what I can tell so far...haven't checked in depth, to parallelize walks...ie, puts multiple getnext requests of different OIDs into a single request. Rather nice. >but... there are/were some tables where you cannot snmpget the >individual values in the table. For instance: >% snmpwalk -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah | grep value >enterprises.usr.blah.blah.blah.foo = "value" >but then try to get it directly and it fails: >% snmpget -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah.foo >This name doesn't exist: enterprises.usr.blah.blah.blah.foo Wow...I've not run into anything like that, but you're probably hitting more stuff than I am. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Assistance Required
From: Kenny Petrie <kenny@millar-bryce.com>
Date: 1999-09-20 13:25:02

I am looking for some advice, I inherited a U.S. Robotics NetServer/8I and wish to configure the box for 2 purposes:- 1) IP Terminal Server, I've managed to get this to work, so the modems connected to ISDN pri are OK 2) Network Dial In PPP - this is proving to be more difficult, I am unable to get this to work at all I have had to config everything via the CLI as I am unable to connect to the box via the n/work and the GUI tools due to the fact that the box balks at the root! password ? I have the Total Control NETServer 3.1 Windows Management Software as supplied with the box. Another problem seems to be that the commands published with the manuals are out of step with the CLI Can anyone assist with some pointers to a config approach for Network Dial IN via PPP ? TIA regards kenny SYSTEM DESCRIPTION System Descriptor: U.S. Robotics NetServer/8I, Version: V4.1.7, Built on Mar 16 1998 at 21:29:52. Object ID: 1.3.6.1.4.1.429.2.14 System UpTime: 63d 08:25:50 System Contact: System Name: ras1 System Location: System Services: Internet EndToEnd Applications System Transmit Authentication Name: Netserver System Version: V4.1.7 "Any opinions expressed in the email are those of the individual and not necessarily the company. This email and any files transmitted with it are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you have received this email in error please notify the IT Manager by telephone on 44 (0) 131 556 1313."

Subject: (usr-tc) Netserver8 Problem
From: Greg Coffey <greg@coffey.com>
Date: 1999-09-20 13:42:16

I just got off the phone with a 3Com tech regarding an issue that we have with a Netserver8 Plus. The modems hang at least once a day and we have to go in and reset each manually to get them to answer an incoming call. We tried some S register settings and flashed the modems down to an earlier code version with no luck. The modems all still seem to hang at random intervals. I have a fair number of the older netserver16's still in service and we don't have this problem with any of them. This unit is fairly new, much newer than the NS16's that I have. After days of trying different things with them, 3Com now tells me that the code has problems and is nothing that they can or will fix. We can continue to reset the modems manually which is a royal pain and unacceptable. Their other suggestion is that I can upgrade the memory from 2meg to 4meg for $1300 plus $300 for advanced shipping. I knew that memory prices recently went up but not by THAT much. Did I just buy a large doorstop or do any of you have any ideas that we can try? Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446

Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-20 13:59:23

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Monday, September 20, 1999 11:54 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address | | |All I was really hoping for here was that someone would give me some |useful OID's that might be faster than what I was using. :) | |I did manage to reduce it from two snmpwalks down to one though. | |What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9 |(usrCipPortIpAddress) -- the OIDs returned contain the port number, the |values returned contain the IP address. Find the OID that matches, |extract the port number, then get the username via an snmpget on |1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName). | |The performance problem I was having was the snmpwalk I had in Perl didn't |return the OIDs, just the values, so I had to do a second walk to the the |port numbers. That made the entire process take about 9 seconds from |start to end, which is just too long when you've got it in a CGI that's |running in a frame on your home page. :) I did some brain surgery on my |snmpwalk and got it to return both OIDs and values, and that sped it up to |about 4 seconds. | |It also let me speed up another program or two I had (like 'arcwho') by |removing one walk from each of those. | |Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full |second or two faster than the Perl one I have. :p | |It'd still be nice if there was a way to not have to walk a full table |just to find one value... | | | |Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY |mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com |"If you're not part of the solution.... you're part of the precipitate." | |On Sat, 18 Sep 1999, Mike Andrews wrote: | |> OK, got a little challenge for you all. :) |> |> On a HiPer ARC... Given a dialup user's IP address, find their username. |> As fast as possible. (Think CGI here.) |> |> I've had code to do this, but it is slow, and it broke on ARC release |> 4.2.x... forcing me to use an even slower method. :p I'd like to speed |> it up. Can someone clarify the above? What broke? OID? |> The best I can do right now is two snmpwalks, followed by a single |> snmpget. I'd like to get rid of the snmpwalks, but for some reason the |> ARC will not let you directly snmpget some variables -- you have to walk |> the whole table it's contained in. (And this got worse in 4.2.x. A bug, |> I would think.) |> |> Can anyone get it down to just snmpgets? |> |> (3Com?) Since the information you are asking for is not indexed by IP address it can never be retrieved with a single get. For that to work the ip would have to be a part of the OID. IE if the ip assigned was 10.10.10.1 the oid would be USR-PREFIX.10.10.10.1.X where X is the index to say the username or other info about that user record. Unfortunately the user records are organized by port ID (4 digit index). So this is not possible. I have a perl script that calls UCD snmp. I can get the info from a chassis in <2 seconds using a HiperNMC. In my example I process the walk as it comes in. (IE i dont walk the branch, then look for the IP) I look at each leaf and see if it matches the IP desired, if so it does the get to retried the Username. Code follows: (NOTE: Works on 4.1 and 4.2 without a problem) #!/usr/local/bin/perl # Script takes IP address as input and returns user name and slot/modem info. $WALK_BIN = '/usr/local/bin/snmpwalk -s -q -v 1'; $GET_BIN = '/usr/local/bin/snmpget -s -q -v 1'; $IP_LIST_OID = '.1.3.6.1.4.1.429.4.10.1.1.9'; $UNAME_OID = '.1.3.6.1.4.1.429.4.10.1.1.18'; $SLOT_CHAD_OID = '.1.3.6.1.4.1.429.4.10.1.1.25'; die "usage $0 <HOST> <COMMUNITY> <IP_ADDRESS>\n" if $#ARGV != 2; $HOST = $ARGV[0]; $READ_STRING = $ARGV[1]; $TARGET_IP = $ARGV[2]; open(IFILE,"$WALK_BIN $HOST $READ_STRING $IP_LIST_OID |") or die "Cant run snmpwalk!\n"; while ($line = <IFILE>) { if ($line =~ /$TARGET_IP/) { #print "$line"; ($OID,$CRAP) = split / /,$line; #print $OID."\n"; @SOID = split /\./, $OID; $PORT = pop(@SOID); $NAME_LINE = `$GET_BIN $HOST $READ_STRING $UNAME_OID.$PORT`; chomp $NAME_LINE; @SNAME_LINE = split / /,$NAME_LINE; $USERNAME = pop(@SNAME_LINE); # Comment out next 4 lines if slot chan info is not required. $SLOT_LINE = `$GET_BIN $HOST $READ_STRING $SLOT_CHAD_OID.$PORT`; chomp $SLOT_LINE; @SSLOT_LINE = split / /,$SLOT_LINE; $SLOT = pop(@SSLOT_LINE); print "$TARGET_IP is on port $PORT ($SLOT) as user :$USERNAME\n"; } }

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-09-20 15:01:07

On Mon, 20 Sep 1999, Mike Andrews wrote: > All I was really hoping for here was that someone would give me some > useful OID's that might be faster than what I was using. :) > > I did manage to reduce it from two snmpwalks down to one though. > > What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9 > (usrCipPortIpAddress) -- the OIDs returned contain the port number, the > values returned contain the IP address. Find the OID that matches, > extract the port number, then get the username via an snmpget on > 1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName). > > The performance problem I was having was the snmpwalk I had in Perl didn't > return the OIDs, just the values, so I had to do a second walk to the the > port numbers. That made the entire process take about 9 seconds from > start to end, which is just too long when you've got it in a CGI that's > running in a frame on your home page. :) I did some brain surgery on my > snmpwalk and got it to return both OIDs and values, and that sped it up to > about 4 seconds. > > It also let me speed up another program or two I had (like 'arcwho') by > removing one walk from each of those. > > Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full > second or two faster than the Perl one I have. :p > > It'd still be nice if there was a way to not have to walk a full table > just to find one value... Thanks to your message above, I did (I'll leave it up to you to implement the shell script in CGI)... #!/bin/sh chassis=$1 mibname=$2 username=$3 snmpwalk "$chassis" "$mibname" .1.3.6.1.4.1.429.4.10.1.1.18 \ .1.3.6.1.4.1.429.4.10.1.1.19 \ .1.3.6.1.4.1.429.4.10.1.1.25 | \ egrep -1 -e "$username" which produced (sorry for the lack of mib.txt file entries -too long) enterprises.usr.4.10.1.1.9.1521 = IpAddress: 111.222.33.44 enterprises.usr.4.10.1.1.18.1521 = OCTET STRING: "userid" enterprises.usr.4.10.1.1.25.1521 = OCTET STRING: "slot:2/mod:1" and the results came back in less than two seconds consistently using CMU-SNMP for Linux v3.5 which can be found at http://www.gaertner.de/snmp/ User names and IP addresses have been changed to protect their identity. :) Want the user name from the address? Try replacing the egrep above with... egrep -2 -e "$username" | tail +3 Bon Apetite! Kevin > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com > "If you're not part of the solution.... you're part of the precipitate." > > On Sat, 18 Sep 1999, Mike Andrews wrote: > > > OK, got a little challenge for you all. :) > > > > On a HiPer ARC... Given a dialup user's IP address, find their username. > > As fast as possible. (Think CGI here.) > > > > I've had code to do this, but it is slow, and it broke on ARC release > > 4.2.x... forcing me to use an even slower method. :p I'd like to speed > > it up. > > > > The best I can do right now is two snmpwalks, followed by a single > > snmpget. I'd like to get rid of the snmpwalks, but for some reason the > > ARC will not let you directly snmpget some variables -- you have to walk > > the whole table it's contained in. (And this got worse in 4.2.x. A bug, > > I would think.) > > > > Can anyone get it down to just snmpgets? > > > > (3Com?) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) V90 & 2.0.81....problems only at one site
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 15:16:53

Hi-- Anyone else experience problems with v90 and 2.0.81 DSP code? Up until Saturday, was running 1.2.25 code without problems since a similiar problem several months ago in the same location. Could the CO switch type have anything to do with it? Running 2.0.81 quite happily everywhere else, at this site on this DSP, try and negotiate a V90 connection and you get a long ugly tone and that's all. X2, fine. V34 & others, fine. V90? Not at all. I replaced the DSP even and no change. Same thing. Strange!!! SMT Scott M. Trautman 800-482-4638 Global Dialog Internet 608-240-4638,4637fax 2810 Crossroads, STE LL2 scott@gdinet.com Madison WI 53718 http://www.gdinet.com

Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 15:43:27

Just downgraded to 1.25.90, still same thing. V90 squeels and that's it. IS there any CO settings that could have anything to do with this? I just learned that this starting to happen <didn't> start just after the DSP upgrade; users having problems now WERE able to get on until this morning, the upgrade was 24 hours before than and we can show they were able to get V90 connections previous to that. VERY weird.... SMT > -----Original Message----- > From: Scott Trautman [mailto:scottt@corp.gdinet.com] > Sent: Monday, September 20, 1999 3:17 PM > To: 'usr-tc@lists.xmission.com' > Subject: (usr-tc) V90 & 2.0.81....problems only at one site > > > Hi-- > > Anyone else experience problems with v90 and 2.0.81 DSP code? > Up until Saturday, was running 1.2.25 code without problems > since a similiar > problem several months ago in the same location. > > Could the CO switch type have anything to do with it? Running > 2.0.81 quite > happily everywhere else, > at this site on this DSP, try and negotiate a V90 connection > and you get a > long ugly tone and that's all. > X2, fine. V34 & others, fine. V90? Not at all. > > I replaced the DSP even and no change. Same thing. > > Strange!!! > > SMT > > Scott M. Trautman 800-482-4638 > Global Dialog Internet 608-240-4638,4637fax > 2810 Crossroads, STE LL2 scott@gdinet.com > Madison WI 53718 http://www.gdinet.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. >

Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 15:53:23

And all our friends the ever lovely "Rockwells". A 3com modem, DOES connect with V90 just fine..... > -----Original Message----- > From: Scott Trautman [mailto:scottt@corp.gdinet.com] > Sent: Monday, September 20, 1999 3:43 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site > > > Just downgraded to 1.25.90, still same thing. V90 squeels and > that's it. > > IS there any CO settings that could have anything to do with this? > > I just learned that this starting to happen <didn't> start just after > the DSP upgrade; users having problems now WERE able to get on until > this morning, the upgrade was 24 hours before than and we can > show they > were able to get V90 connections previous to that. > > VERY weird.... > > SMT > > > -----Original Message----- > > From: Scott Trautman [mailto:scottt@corp.gdinet.com] > > Sent: Monday, September 20, 1999 3:17 PM > > To: 'usr-tc@lists.xmission.com' > > Subject: (usr-tc) V90 & 2.0.81....problems only at one site > > > > > > Hi-- > > > > Anyone else experience problems with v90 and 2.0.81 DSP code? > > Up until Saturday, was running 1.2.25 code without problems > > since a similiar > > problem several months ago in the same location. > > > > Could the CO switch type have anything to do with it? Running > > 2.0.81 quite > > happily everywhere else, > > at this site on this DSP, try and negotiate a V90 connection > > and you get a > > long ugly tone and that's all. > > X2, fine. V34 & others, fine. V90? Not at all. > > > > I replaced the DSP even and no change. Same thing. > > > > Strange!!! > > > > SMT > > > > Scott M. Trautman 800-482-4638 > > Global Dialog Internet 608-240-4638,4637fax > > 2810 Crossroads, STE LL2 scott@gdinet.com > > Madison WI 53718 http://www.gdinet.com > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-20 16:37:31

On Mon, 20 Sep 1999, Mike Wronski wrote: > |> I've had code to do this, but it is slow, and it broke on ARC release > |> 4.2.x... forcing me to use an even slower method. :p I'd like to speed > |> it up. > > Can someone clarify the above? What broke? OID? It took me a while to dredge up my old code so I can back up silly claims like this (I deleted my old version after fixing it all Saturday... dumb). On 4.1.59, I was doing this: ($portname) = &ma_snmp::snmpwalk ($tsname, $commname, "1.3.6.1.4.1.429.4.19.24.1.10.$ipaddr.255.255.255.255"); to get the port number, then I could (and still can) get the username with: ($username) = &ma_snmp::snmpget ($tsname, $commname, "1.3.6.1.4.1.429.4.10.1.1.18.$portname"); But the snmpwalk broke on upgrading to 4.2.29 and 4.2.32. That's when I switched over to walking two different trees, 1.3.6.1.4.1.429.4.10.1.1.1 to get port numbers and 1.3.6.1.4.1.429.4.10.1.1.9 to get IP addresses. That doubled the runtime. By fixing my snmpwalk to give me the OIDs instead of just the values, I could just walk the ...4.10.1.1.9 tree and get all I needed, get it back down to one snmpwalk, and solve my original problem. And as far as I know it's backward compatible to 4.1.59. As far as the walk/get inconsistency, I'll get to that below. > I have a perl script that calls UCD snmp. I can get the info from a chassis in > <2 seconds using a HiperNMC. > In my example I process the walk as it comes in. (IE i dont walk the branch, then > look for the IP) I look at each leaf and see if it matches the IP desired, if so > it does the get to retried the Username. > > Code follows: (NOTE: Works on 4.1 and 4.2 without a problem) > > #!/usr/local/bin/perl > # Script takes IP address as input and returns user name and slot/modem info. > > $WALK_BIN = '/usr/local/bin/snmpwalk -s -q -v 1'; > $GET_BIN = '/usr/local/bin/snmpget -s -q -v 1'; > $IP_LIST_OID = '.1.3.6.1.4.1.429.4.10.1.1.9'; > $UNAME_OID = '.1.3.6.1.4.1.429.4.10.1.1.18'; > $SLOT_CHAD_OID = '.1.3.6.1.4.1.429.4.10.1.1.25'; [munch] This is exactly what I came up with in the end, except I calculate the slot/channel numbers from the port number. (Subtract 1000 decimal, then the low order byte is the channel, high order byte is the slot.) The rest of my speed problem is probably because I'm using an all-Perl snmpwalk instead of calling /usr/local/bin/snmpwalk. The snmpwalk code I'm using is probably very sloppy and could be optimized. It probably doesn't help that the machine it's running on is only a Pentium 166. :) Now, as far as snmpwalk/snmpget being strange, here's an actual example, using 206.240.130.20 as a dialup IP address currently in use by a user on slot:11/mod:18 (3834 - 1000 = 0xb12).... andrew% snmpwalk -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10 | grep 206.240.130.20 enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.0.1.0 = 3834 enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.1.1.0 = 3834 andrew% snmpwalk -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20 [returns nothing whatsoever] andrew% snmpwalk -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20.255.255.255.255 [also returns nothing whatsoever on 4.2.x, but I believe used to on 4.1.x] andrew% snmpget -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20.255.255.255.255.0.0.1.0 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.0.1.0 andrew% snmpget -v 1 fra1-arc xxxxxx .1.3.6.1.4.1.429.4.19.24.1.10.206.240.130.20.255.255.255.255.0.1.1.0 Error in packet Reason: (noSuchName) There is no such variable name in this MIB. This name doesn't exist: enterprises.usr.common.usrIpRouting.usrIpRTE.usrIpRTEEntry.usrIpRTEIfIndex.206.240.130.20.255.255.255.255.0.1.1.0 Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-20 16:43:22

Okay, so this time I REALLY downgraded it to 1.2.59 (sorry for the typo), and it does in fact work again...V90 that is....very very odd..... SMT > -----Original Message----- > From: Scott Trautman [mailto:scottt@corp.gdinet.com] > Sent: Monday, September 20, 1999 3:43 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) V90 & 2.0.81....problems only at one site > > > Just downgraded to 1.25.90, still same thing. V90 squeels and > that's it. > > IS there any CO settings that could have anything to do with this? > > I just learned that this starting to happen <didn't> start just after > the DSP upgrade; users having problems now WERE able to get on until > this morning, the upgrade was 24 hours before than and we can > show they > were able to get V90 connections previous to that. > > VERY weird.... > > SMT > > > -----Original Message----- > > From: Scott Trautman [mailto:scottt@corp.gdinet.com] > > Sent: Monday, September 20, 1999 3:17 PM > > To: 'usr-tc@lists.xmission.com' > > Subject: (usr-tc) V90 & 2.0.81....problems only at one site > > > > > > Hi-- > > > > Anyone else experience problems with v90 and 2.0.81 DSP code? > > Up until Saturday, was running 1.2.25 code without problems > > since a similiar > > problem several months ago in the same location. > > > > Could the CO switch type have anything to do with it? Running > > 2.0.81 quite > > happily everywhere else, > > at this site on this DSP, try and negotiate a V90 connection > > and you get a > > long ugly tone and that's all. > > X2, fine. V34 & others, fine. V90? Not at all. > > > > I replaced the DSP even and no change. Same thing. > > > > Strange!!! > > > > SMT > > > > Scott M. Trautman 800-482-4638 > > Global Dialog Internet 608-240-4638,4637fax > > 2810 Crossroads, STE LL2 scott@gdinet.com > > Madison WI 53718 http://www.gdinet.com > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) R2 debug codes
From: Vadim Tulinov <vadim_tulinov@rrc.ru>
Date: 1999-09-20 18:32:34

Hello, We try to convert R1 to R2 (ICX c=CFverter) and get following Dual Cas (1.3.4) information: Ph_frame_post_xmit: datagramm: frame: t/p: 8/0030:001de394, status >0x04< What this is mean? Where can I read about this status? Best regards, Vadim Tulinov.

Subject: (usr-tc) R2 debug codes
From: Vadim Tulinov <vadim_tulinov@rrc.ru>
Date: 1999-09-20 18:32:34

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-20 18:44:39

Allen Marsalis writes... >At 01:59 PM 9/20/99 -0500, Mike Wronski wrote: > >>Since the information you are asking for is not indexed by IP address it can >>never be retrieved with a single get. >>For that to work the ip would have to be a part of the OID. IE if the ip >>assigned >>was 10.10.10.1 the oid would be > >Has anyone thought of retrieving the data (via snmp or telnet) on a >regular interval and placing it into a sql database to be served up >via php or other cgi? And indexed any way you like? If you have a >dozen or more ARC's on the network, and/or plan on a high hit rate >for the cgi (entire userbase), then there could be some real savings >by retrieving the data only once a minute instead of (potentially) many >times in a minute. I would think that polling/updating once every 60 >seconds would be sufficient. just a thought.. Uh, I'm assuming they want to do this SNMP rigamarole for some specific reason, and I'm guessing that, like us, they simply save the IP->username association in a database when the person logs in. If it were just a matter of finding out what user corresponds to which IP address (or vice-versa), it's just a couple SQL queries. -- Aaron Nabil

Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
From: Allen Marsalis <am@shreve.net>
Date: 1999-09-20 20:04:30

At 01:59 PM 9/20/99 -0500, Mike Wronski wrote: >Since the information you are asking for is not indexed by IP address it can >never be retrieved with a single get. >For that to work the ip would have to be a part of the OID. IE if the ip >assigned >was 10.10.10.1 the oid would be Has anyone thought of retrieving the data (via snmp or telnet) on a regular interval and placing it into a sql database to be served up via php or other cgi? And indexed any way you like? If you have a dozen or more ARC's on the network, and/or plan on a high hit rate for the cgi (entire userbase), then there could be some real savings by retrieving the data only once a minute instead of (potentially) many times in a minute. I would think that polling/updating once every 60 seconds would be sufficient. just a thought.. Allen

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-20 20:30:14

Most new TC chassis now come with a NMC using P-5 based processor.. not the 486 or (ack) 386's that most of us still have on service. Most P-5's have the screw terminals on the back of the NIC. The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even lightly loaded the 486 is butt slow for snmpwalks. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 20 Sep 1999, Jeff Mcadams wrote: > Thus spake Mike Andrews > >That's exactly what I had before. :) I removed the usrCipPortIndex walk > >by using the OIDs returned by the usrCipPortIpAddress walk and peeling the > >port number off the end. > > Man...maybe we're using different PERL modules? The one we have will > walk through 96 ports of data in something like a second or two...its > *quite* fast....and that's displaying the output as it gets it, so its > probably slowed down considerably by the display output. We're using > http://cpan.valueclick.com/authors/id/GSM/SNMP-1.8.2.tar.gz > and it seems to be quite quick. Also seems, from what I can tell so > far...haven't checked in depth, to parallelize walks...ie, puts multiple > getnext requests of different OIDs into a single request. Rather nice. > > >but... there are/were some tables where you cannot snmpget the > >individual values in the table. For instance: > > >% snmpwalk -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah | grep value > >enterprises.usr.blah.blah.blah.foo = "value" > > >but then try to get it directly and it fails: > > >% snmpget -v 1 chass comm .1.3.6.1.4.1.429.blah.blah.blah.foo > >This name doesn't exist: enterprises.usr.blah.blah.blah.foo > > Wow...I've not run into anything like that, but you're probably hitting > more stuff than I am. > -- > 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. >

Subject: Re: (usr-tc) Netserver8 Problem
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-09-20 20:42:37

Greg, Do you have the box talking to a syslog program?? tony Greg Coffey wrote: > I just got off the phone with a 3Com tech regarding an issue that we have > with a Netserver8 Plus. The modems hang at least once a day and we have to > go in and reset each manually to get them to answer an incoming call. We > tried some S register settings and flashed the modems down to an earlier > code version with no luck. The modems all still seem to hang at random > intervals. I have a fair number of the older netserver16's still in > service and we don't have this problem with any of them. This unit is > fairly new, much newer than the NS16's that I have. After days of trying > different things with them, 3Com now tells me that the code has problems > and is nothing that they can or will fix. We can continue to reset the > modems manually which is a royal pain and unacceptable. Their other > suggestion is that I can upgrade the memory from 2meg to 4meg for $1300 > plus $300 for advanced shipping. I knew that memory prices recently went > up but not by THAT much. Did I just buy a large doorstop or do any of you > have any ideas that we can try? > > Thanks, Greg Coffey <gcoffey@vcn.com> > Visionary Communications V 307-234-5443 F 307-234-5446 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Netserver8 Problem
From: Greg Coffey <greg@coffey.com>
Date: 1999-09-20 21:08:02

I don't know. We log the logins and logouts if that is what you are asking. We don't have anything else that we log that I am aware of. What do you have in mind? At 08:42 PM 9/20/99 -0600, you wrote: >Greg, > Do you have the box talking to a syslog program?? > >tony > > >Greg Coffey wrote: > >> I just got off the phone with a 3Com tech regarding an issue that we have >> with a Netserver8 Plus. The modems hang at least once a day and we have to >> go in and reset each manually to get them to answer an incoming call. We >> tried some S register settings and flashed the modems down to an earlier >> code version with no luck. The modems all still seem to hang at random >> intervals. I have a fair number of the older netserver16's still in >> service and we don't have this problem with any of them. This unit is >> fairly new, much newer than the NS16's that I have. After days of trying >> different things with them, 3Com now tells me that the code has problems >> and is nothing that they can or will fix. We can continue to reset the >> modems manually which is a royal pain and unacceptable. Their other >> suggestion is that I can upgrade the memory from 2meg to 4meg for $1300 >> plus $300 for advanced shipping. I knew that memory prices recently went >> up but not by THAT much. Did I just buy a large doorstop or do any of you >> have any ideas that we can try? >> >> Thanks, Greg Coffey <gcoffey@vcn.com> >> Visionary Communications V 307-234-5443 F 307-234-5446 >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > Thanks, Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 ===================================================================== 142 S. Center St., Casper, WY 82601 WWW.VCN.COM

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-20 21:13:34

Thus spake Paul Farber >Most new TC chassis now come with a NMC using P-5 based processor.. not >the 486 or (ack) 386's that most of us still have on service. >Most P-5's have the screw terminals on the back of the NIC. >The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even >lightly loaded the 486 is butt slow for snmpwalks. Oh, yeah...that's what I hear...I think Mike and I both are 486 based across the board though, so I don't think that's the difference. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-20 21:16:21

Thus spake Allen Marsalis >At 01:59 PM 9/20/99 -0500, Mike Wronski wrote: >>Since the information you are asking for is not indexed by IP address it can >>never be retrieved with a single get. >>For that to work the ip would have to be a part of the OID. IE if the ip >>assigned >>was 10.10.10.1 the oid would be >Has anyone thought of retrieving the data (via snmp or telnet) on a >regular interval and placing it into a sql database to be served up >via php or other cgi? And indexed any way you like? If you have a >dozen or more ARC's on the network, and/or plan on a high hit rate >for the cgi (entire userbase), then there could be some real savings >by retrieving the data only once a minute instead of (potentially) many >times in a minute. I would think that polling/updating once every 60 >seconds would be sufficient. just a thought.. I don't know...it probably would work...at the risk of working on slightly stale data...proly not a big deal, but... Our perl SNMP module that we're using is doing two walks on each chassis with a total of over 1000 ports spread across 3 cities in a matter of about 10 seconds total. These are for queries directly to the Arc, not to the NMCs...somehow I don't think the actual SNMP operations on the network and the agents are the problems. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Andres Kroonmaa <andre@mail.lbi.ee>
Date: 1999-09-20 21:33:16

AFAIK, logical way to get this done is in 2 snmpgets: Given that you look for IP address of "12.45.78.23" $port = snmpget ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.23 $user = snmpget usrCipUserName.$portname and of course 3com is always ready to screw up. You can't snmpget item from ipRouteIfIndex, you can only walk it, or it returns always "0" The only thing positive here is that you can walk subset of the table: snmpwalk ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78 that is you omit last octet from the IP address. You get all ports for given /24, and search your interested IP yourself. Or, an interesting hack that would probably also work is to ask: snmpnext ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.22 instead of: snmpget ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.23 note snmp _next_ request and off by -1 IP address. Basically, we cheat, yet amazingly it seems to work. You might use this as "wild guess", check returned snmpindex and if it doesn't match what you are looking for, fallback to longer walkouts. I believe you wouldn't need to. On 20 Sep 99, at 12:53, Mike Andrews <usr-tc@lists.xmission.com> wrote: > All I was really hoping for here was that someone would give me some > useful OID's that might be faster than what I was using. :) > > I did manage to reduce it from two snmpwalks down to one though. > > What I'm doing now is walking 1.3.6.1.4.1.429.4.10.1.1.9 > (usrCipPortIpAddress) -- the OIDs returned contain the port number, the > values returned contain the IP address. Find the OID that matches, > extract the port number, then get the username via an snmpget on > 1.3.6.1.4.1.429.4.10.1.1.18.$portname (usrCipUserName). > > The performance problem I was having was the snmpwalk I had in Perl didn't > return the OIDs, just the values, so I had to do a second walk to the the > port numbers. That made the entire process take about 9 seconds from > start to end, which is just too long when you've got it in a CGI that's > running in a frame on your home page. :) I did some brain surgery on my > snmpwalk and got it to return both OIDs and values, and that sped it up to > about 4 seconds. > > It also let me speed up another program or two I had (like 'arcwho') by > removing one walk from each of those. > > Now I just have to figure out why ucd-snmp's snmpwalk (in C) is a full > second or two faster than the Perl one I have. :p > > It'd still be nice if there was a way to not have to walk a full table > just to find one value... > > > > Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com > "If you're not part of the solution.... you're part of the precipitate." > > On Sat, 18 Sep 1999, Mike Andrews wrote: > > > OK, got a little challenge for you all. :) > > > > On a HiPer ARC... Given a dialup user's IP address, find their username. > > As fast as possible. (Think CGI here.) > > > > I've had code to do this, but it is slow, and it broke on ARC release > > 4.2.x... forcing me to use an even slower method. :p I'd like to speed > > it up. > > > > The best I can do right now is two snmpwalks, followed by a single > > snmpget. I'd like to get rid of the snmpwalks, but for some reason the > > ARC will not let you directly snmpget some variables -- you have to walk > > the whole table it's contained in. (And this got worse in 4.2.x. A bug, > > I would think.) > > > > Can anyone get it down to just snmpgets? > > > > (3Com?) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Senior Network Engineer Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-20 21:35:03

On Mon, 20 Sep 1999, Jeff Mcadams wrote: > Thus spake Paul Farber > >Most new TC chassis now come with a NMC using P-5 based processor.. not > >the 486 or (ack) 386's that most of us still have on service. > > >Most P-5's have the screw terminals on the back of the NIC. > > >The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even > >lightly loaded the 486 is butt slow for snmpwalks. > > Oh, yeah...that's what I hear...I think Mike and I both are 486 based > across the board though, so I don't think that's the difference. 486SX, yeah. But it's definitely not the difference since we're talking about querying the ARC directly, which only involves the PPC603 on it and not the NMC at all. I'd rather not think about how much slower it would be if I was using the NMC. :) Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate."

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Allen Marsalis <am@shreve.net>
Date: 1999-09-20 22:29:55

At 06:44 PM 9/20/99 -0700, Aaron Nabil wrote: >Allen Marsalis writes... >>Has anyone thought of retrieving the data (via snmp or telnet) on a >>regular interval and placing it into a sql database to be served up >>via php or other cgi? And indexed any way you like? If you have a >>dozen or more ARC's on the network, and/or plan on a high hit rate >>for the cgi (entire userbase), then there could be some real savings >>by retrieving the data only once a minute instead of (potentially) many >>times in a minute. I would think that polling/updating once every 60 >>seconds would be sufficient. just a thought.. > >Uh, I'm assuming they want to do this SNMP rigamarole for some specific >reason, and I'm guessing that, like us, they simply save the IP->username >association in a database when the person logs in. If it were just a >matter of finding out what user corresponds to which IP address (or >vice-versa), it's just a couple SQL queries. > :) nod.. Still, it looks like Mike is linking this cgi off a homepage which can get a lot of hits in some cases.. (Just don't put a nude picture near it mike ;) Allen > >-- >Aaron Nabil >

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Andres Kroonmaa <andre@mail.lbi.ee>
Date: 1999-09-20 23:31:44

On 20 Sep 99, at 21:33, Andres Kroonmaa <usr-tc@lists.xmission.com> wrote: > AFAIK, logical way to get this done is in 2 snmpgets: > Given that you look for IP address of "12.45.78.23" > > $port = snmpget ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.23 > $user = snmpget usrCipUserName.$portname > Or, an interesting hack that would probably also work is to ask: > snmpnext ip.ipRouteTable.ipRouteEntry.ipRouteIfIndex.12.45.78.22 > note snmp _next_ request and off by -1 IP address. sample script: #!/usr/local/bin/perl # ftp://ftp.switch.ch/software/sources/network/snmp/perl/SNMP_Session-0.74.tar.gz use BER; use SNMP_Session; use SNMP_util; my $community = 'public'; my $host = $ARGV[0] || die "usage: $0 target ipaddress"; my $target = $ARGV[1] || die "usage: $0 target ipaddress"; @ip = split(/\./,$target); $ip[3]--; $pretarg = join('.',@ip); @ret = &snmpgetnext("$community\@$host", "1.3.6.1.2.1.4.21.1.2.$pretarg"); foreach $index (@ret) { ($oid, $index) = split(':', $index, 2); if ($oid =~ "\.$target\$") { ($user) = &snmpget("$community\@$host", "1.3.6.1.4.1.429.4.10.1.1.18.$index"); print "$target = $user\n"; } } unix> ptime tcwho Hiper 1.2.3.4 1.2.3.4 = userX real 0.393 user 0.224 sys 0.053 ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Senior Network Engineer Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Subject: (usr-tc) User is disconne
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-21 06:59:00

What does RADIUS show as the disconnect cause ? Jeff Binkley ASA Network Computing u>Hi all, having a problem whilst setting up our DSP's and ARC's, they u>are running on TCS 3.6. u>Basically a dial in user is authenticated fine and connects ok gets u>assigned an IP etc using either chassis users or radius. The user can u>be logged in as long as they want but as soon as traffic starts going u>accross the link the call gets dropped after about 15 seconds. u>I've set session_time out and that has not helped. I can't seem to get u>any other ideas on this at the mo. u>Has anyone had similar before? u>Cheers, Phil u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u> CMPQwk 1.42 9999

Subject: Re: (usr-tc) Netserver8 Problem
From: Tony Loosle <tony@tcsourceone.com>
Date: 1999-09-21 08:12:45

You have to have a syslog deamon or program running. You have to tell the netserver box where to send its messages. If you don't, it will fill up the memory and crash!!!! Tony Greg Coffey wrote: > I don't know. We log the logins and logouts if that is what you are > asking. We don't have anything else that we log that I am aware of. What > do you have in mind? > > At 08:42 PM 9/20/99 -0600, you wrote: > >Greg, > > Do you have the box talking to a syslog program?? > > > >tony > > > > > >Greg Coffey wrote: > > > >> I just got off the phone with a 3Com tech regarding an issue that we have > >> with a Netserver8 Plus. The modems hang at least once a day and we have to > >> go in and reset each manually to get them to answer an incoming call. We > >> tried some S register settings and flashed the modems down to an earlier > >> code version with no luck. The modems all still seem to hang at random > >> intervals. I have a fair number of the older netserver16's still in > >> service and we don't have this problem with any of them. This unit is > >> fairly new, much newer than the NS16's that I have. After days of trying > >> different things with them, 3Com now tells me that the code has problems > >> and is nothing that they can or will fix. We can continue to reset the > >> modems manually which is a royal pain and unacceptable. Their other > >> suggestion is that I can upgrade the memory from 2meg to 4meg for $1300 > >> plus $300 for advanced shipping. I knew that memory prices recently went > >> up but not by THAT much. Did I just buy a large doorstop or do any of you > >> have any ideas that we can try? > >> > >> Thanks, Greg Coffey <gcoffey@vcn.com> > >> Visionary Communications V 307-234-5443 F 307-234-5446 > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > Thanks, > > Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 > ===================================================================== > 142 S. Center St., Casper, WY 82601 WWW.VCN.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.

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-21 09:28:07

Thus spake Paul Farber >SNMP wise it is. The P-5 can whip out an entire chassis in a few seconds >to TCM... teh 486 takes about two minutes. Since all TCM is doing is >balking the majority of the MIB tree to get stats (like your program) the >snmpwalk time diff. on a 486 and P-5 is very noticible. Telnet seems to >have the same speed's for eace processor. Well...since TCM/SNMP is going to the NMC, and telnet is going to the Arc, changing the NMC wouldn't improve telnet speeds much at all. :) Besides...with this whole discussion, we're talking about sending SNMP requests to the Arc directly, so the NMC's SNMP speed wouldn't come into play in our situation either. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-21 09:29:13

SNMP wise it is. The P-5 can whip out an entire chassis in a few seconds to TCM... teh 486 takes about two minutes. Since all TCM is doing is balking the majority of the MIB tree to get stats (like your program) the snmpwalk time diff. on a 486 and P-5 is very noticible. Telnet seems to have the same speed's for eace processor. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Mon, 20 Sep 1999, Jeff Mcadams wrote: > Thus spake Paul Farber > >Most new TC chassis now come with a NMC using P-5 based processor.. not > >the 486 or (ack) 386's that most of us still have on service. > > >Most P-5's have the screw terminals on the back of the NIC. > > >The 486's are dirt compated to the P-5's.. I have 1 and 2 486's... even > >lightly loaded the 486 is butt slow for snmpwalks. > > Oh, yeah...that's what I hear...I think Mike and I both are 486 based > across the board though, so I don't think that's the difference. > -- > 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. >

Subject: (usr-tc) Anyone near Sioux City?
From: Eric Billeter <ebilleter@cableone.net>
Date: 1999-09-21 09:54:24

I lost a power supply on a chassis this morning and the soonest I can get one out there this afternoon at 5:00 (into Omaha) Anyone who can spare a Power Supply in the are would be greatly appreciated. Please call on my cell phone if possible. 602-550-8477 Thanks Eric Billeter Internet Engineer Cable One, Inc. eric.billeter@cableone.net 602-364-6462

Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
From: Allen Marsalis <am@shreve.net>
Date: 1999-09-21 10:24:11

At 10:35 AM 9/21/99 -0400, Charles Sprickman wrote: >On Mon, 20 Sep 1999, Allen Marsalis wrote: > >> At 01:59 PM 9/20/99 -0500, Mike Wronski wrote: >> >> Has anyone thought of retrieving the data (via snmp or telnet) on a >> regular interval and placing it into a sql database to be served up >> via php or other cgi? And indexed any way you like? > >I hate to make another one of those Radiator plugs, but yes, we use it and >it accounts to a mysql db. So something like this is a trivial database >query... Works well and is very quick. Don't have to bother doing any >snmp unless you want the current connection speed, but at least then you >just do one snmpget. I believe alot of the other radius servers are now >offering the option of logging to a database as well... I agree, Radiator rocks the casba.. We use it in conjunction with postgres sql and swear by it. But for Mikes specific 'challenge' at hand, I'd rather impliment a Radiator/sql like methodology, rather than walking the chassis (once or twice) per cgi hit... especially if it was going on homepage(s).. Allen > >Charles >

Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-21 10:35:09

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Allen Marsalis |Sent: Tuesday, September 21, 1999 10:24 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address | | |At 10:35 AM 9/21/99 -0400, Charles Sprickman wrote: |>On Mon, 20 Sep 1999, Allen Marsalis wrote: |> |>> At 01:59 PM 9/20/99 -0500, Mike Wronski wrote: |>> |>> Has anyone thought of retrieving the data (via snmp or telnet) on a |>> regular interval and placing it into a sql database to be served up |>> via php or other cgi? And indexed any way you like? |> |>I hate to make another one of those Radiator plugs, but yes, we use it and |>it accounts to a mysql db. So something like this is a trivial database |>query... Works well and is very quick. Don't have to bother doing any |>snmp unless you want the current connection speed, but at least then you |>just do one snmpget. I believe alot of the other radius servers are now |>offering the option of logging to a database as well... | |I agree, Radiator rocks the casba.. We use it in conjunction with |postgres sql and swear by it. | |But for Mikes specific 'challenge' at hand, I'd rather impliment a |Radiator/sql like methodology, rather than walking the chassis (once |or twice) per cgi hit... especially if it was going on homepage(s).. | I would have to agree here. Either by logging the RADIUS accouting info to a DB or if you set up the harc to send call details in the syslogs (FORMAT_ONE) and either DB that or flat file for some interval, the search will be much faster and non-impacting to the network. -M

Subject: RE: (usr-tc) SNMP challenge: ARC username from IP address
From: Charles Sprickman <spork@inch.com>
Date: 1999-09-21 10:35:14

On Mon, 20 Sep 1999, Allen Marsalis wrote: > At 01:59 PM 9/20/99 -0500, Mike Wronski wrote: > > Has anyone thought of retrieving the data (via snmp or telnet) on a > regular interval and placing it into a sql database to be served up > via php or other cgi? And indexed any way you like? I hate to make another one of those Radiator plugs, but yes, we use it and it accounts to a mysql db. So something like this is a trivial database query... Works well and is very quick. Don't have to bother doing any snmp unless you want the current connection speed, but at least then you just do one snmpget. I believe alot of the other radius servers are now offering the option of logging to a database as well... Charles > If you have a > dozen or more ARC's on the network, and/or plan on a high hit rate > for the cgi (entire userbase), then there could be some real savings > by retrieving the data only once a minute instead of (potentially) many > times in a minute. I would think that polling/updating once every 60 > seconds would be sufficient. just a thought.. > > Allen > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) User is disconnected once traffic starts.
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1999-09-21 10:58:21

Hi all, having a problem whilst setting up our DSP's and ARC's, they are running on TCS 3.6. Basically a dial in user is authenticated fine and connects ok gets assigned an IP etc using either chassis users or radius. The user can be logged in as long as they want but as soon as traffic starts going accross the link the call gets dropped after about 15 seconds. I've set session_time out and that has not helped. I can't seem to get any other ideas on this at the mo. Has anyone had similar before? Cheers, Phil

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-21 11:06:12

I have a script that uses both the ARC and NMC OID's (so I can verify what the chassis tells me via TCM). So I assumed that most others did the same thing. I know that there are tons of MIB viewers.. but using 3Com's TCM as a data backup to verify program outout just makes sense. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Tue, 21 Sep 1999, Jeff Mcadams wrote: > Thus spake Paul Farber > >SNMP wise it is. The P-5 can whip out an entire chassis in a few seconds > >to TCM... teh 486 takes about two minutes. Since all TCM is doing is > >balking the majority of the MIB tree to get stats (like your program) the > >snmpwalk time diff. on a 486 and P-5 is very noticible. Telnet seems to > >have the same speed's for eace processor. > > Well...since TCM/SNMP is going to the NMC, and telnet is going to the > Arc, changing the NMC wouldn't improve telnet speeds much at all. :) > > Besides...with this whole discussion, we're talking about sending SNMP > requests to the Arc directly, so the NMC's SNMP speed wouldn't come into > play in our situation either. > -- > 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. >

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-21 11:09:02

Thus spake Paul Farber >I have a script that uses both the ARC and NMC OID's (so I can verify what >the chassis tells me via TCM). So I assumed that most others did the same >thing. >I know that there are tons of MIB viewers.. but using 3Com's TCM as a data >backup to verify program outout just makes sense. Assuming you're on a platform that supports TCM, and want to put up with some of its braindeadedness (not all of it, but some). I find it terribly tedious to use personally. Besides...most of these data sources and the algorithms used to get this data has been confirmed...just in discussion now is the fastest way to get it. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) wet total control units :((
From: eric@dol.net
Date: 1999-09-21 11:24:00

We had some total control racks get submerged during hurricane Floyd. Has anyone had to recover units like this after sustaining water damage and what is the best way to try and get the units back in shape? thanks eric Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: Re: (usr-tc) wet total control units :((
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-21 12:21:16

eric@dol.net writes... >We had some total control racks get submerged during hurricane Floyd. >Has anyone had to recover units like this after sustaining water damage >and what is the best way to try and get the units back in shape? Short answer, get a professional to do it. Also talk to your insurance company first. If you must do it yourself, here's the basic proceedure. Dissassemble everything, cards out of rack, daughter cards removed, SIMMS out of sockets. First, wash everything with plain old water to get it completely clean (were are talking garden hose here). You may want to use some surfactant, if you can find one that is non-reactive. It may be difficult to get crud out of sockets, but you need to get it completely clean. After the garden hose, wash everything down with some DI (or distilled, if that what you can have handy) water. Shake the water off everything, or let it drip for a few mins. Dunk everything in anyhydrous isopropanol (this dissolves the remaining water out of things like contacts), shake it off. Bake in an oven, say 150F, till dry. -- Aaron Nabil

Subject: Re: (usr-tc) Current Consumption
From: pferraro@wna-linknet.com
Date: 1999-09-21 12:35:21

Are watts added together to get a ballpark consumption rate? For example if I add all the components for a QUAD hub I get 820watts! So if I have a 850watt UPS it will hold it for about 3 minutes... I am looking for a way to spreadload power among UPSz! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Fri, 17 Sep 1999, Marcelo Barros wrote: > > Current (A) Current (A) > Configuration Choices +5.2 Volt +/- 12.2 Volt Watts > > > HiPer ARC 4 20.8 70.9 > HiPer ARC Max. Set 7 36.4 124.1 > HiPer DSP 4.3 22.4 76.2 > HiPer DSP NIC only .6 3.1 10.6 > HiPer DSP Set 4.9 25.5 86.9 > EdgeServer Set 4.5 23.4 79.8 > Digital Quad Modems 2.1 10.9 37.2 > Quad Modem NIC 1 5.2 17.7 > 486 NETServer 3 15.6 53.2 > NET Enet NIC 1.5 7.8 26.6 > NET Token NIC 2 10.4 35.5 > NMC (486SX) 3 15.6 53.2 > NMC Enet NIC 1.5 7.8 26.6 > Dual PRI NAC 1.5 7.8 26.6 > Dual PRI NIC .5 2.6 8.9 > > > At 09:00 9/17/99 -0400, you wrote: > > > > > >Can someone tell me the current consumption for: > > > > Quad-NAC > > Dual-PRI-NIC > > Dual-PRI-NAC > > > >Jim > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: Re: (usr-tc) Rockwell HCF 56k v.90
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-21 12:37:35

At 02:03 PM 9/9/99 -0400, "Levent Cosan" <levent21@netzero.net> wrote: >Hi, I have a HP computer and the modem is a Rockwell HCF 56k v.90 speakerphone pci modem. The modem dials out but it doesn't do the "handshake". I had the modem replaced but i still run into problems with the new modem. I usually get a, "no answer" or a "modem doesn't carrier a signal". I've tried numerous ISPs but i get the same error message. Any help will be appreciated HCF modems are notoriously crappy, but they do seem to perform somewhat decently with the latest code. Check http://www.808hi.com/56k/rockhcf.htm for pointers. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) SNMP script to disconnect ports
From: Brett Murphy <me@murf.net>
Date: 1999-09-21 12:50:41

Hi All, Has anyone got a script that uses SNMP to disconnect a port on Netserver and/or HyperARC that they would be willing to share with me and/or the list? All the best, Brett Murphy Technical Manager, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: me@murf.net The contents of this email message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

Subject: RE: (usr-tc) User is disconne
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1999-09-21 13:20:03

Thanks for the reply. I haven't checked that, because it is doing the same for users authenticated on the chassis. So I was presuming something more base level than that. Though if you reckon it'll point me in the right direction as far as error codes etc? Cheers Phil -----Original Message----- Sent: Tuesday, September 21, 1999 12:59 PM What does RADIUS show as the disconnect cause ? Jeff Binkley ASA Network Computing u>Hi all, having a problem whilst setting up our DSP's and ARC's, they u>are running on TCS 3.6. u>Basically a dial in user is authenticated fine and connects ok gets u>assigned an IP etc using either chassis users or radius. The user can u>be logged in as long as they want but as soon as traffic starts going u>accross the link the call gets dropped after about 15 seconds. u>I've set session_time out and that has not helped. I can't seem to get u>any other ideas on this at the mo. u>Has anyone had similar before? u>Cheers, Phil u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u> CMPQwk 1.42 9999 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) problems with CHAP authentication
From: Theodore Cekan <ted@mho.net>
Date: 1999-09-21 13:38:48

Hi, I have a user trying to dial in with a Livingston Office Router U-AP, running software version 3.7.1 AP.5. For some reason they cannot connect to my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only allowed authentication scheme. "Any" doesnt work, chap kicks in and they get denied access. The Livingston box does have chap turned off, btw. We are stumped. Any help is much appreciated. Thanks Ted Cekan

Subject: Re: (usr-tc) problems with CHAP authentication
From: Theodore Cekan <ted@mho.net>
Date: 1999-09-21 14:08:07

Sorry, I need to use PAP. CHAP wont authenticate for some reason. Ted Cekan Mile High Online -----Original Message----- >Do you want to use CHAP or PAP? You're not clear in your message. > >Jason > > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan >Sent: Tuesday, September 21, 1999 14:39 >To: usr-tc@lists.xmission.com >Subject: (usr-tc) problems with CHAP authentication > > >Hi, > >I have a user trying to dial in with a Livingston Office Router U-AP, >running software version 3.7.1 AP.5. For some reason they cannot connect to >my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only >allowed authentication scheme. "Any" doesnt work, chap kicks in and they >get denied access. The Livingston box does have chap turned off, btw. We >are stumped. Any help is much appreciated. > >Thanks > >Ted Cekan > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

Subject: Re: (usr-tc) problems with CHAP authentication
From: Theodore Cekan <ted@mho.net>
Date: 1999-09-21 14:22:10

Thanks Matthew, that worked! Does this setting mean that all users will now be authenticated with PAP? Will it ever even try CHAP for users that can use it? Ted Cekan -----Original Message----- > >Have you tried doing "set ppp authENTICATION_PREFERENCE pap"? That should >set PAP as the first authentication protocol to be used. > >On Tuesday, September 21, 1999 4:39 PM, Theodore Cekan [SMTP:ted@mho.net] >wrote: >> Hi, >> >> I have a user trying to dial in with a Livingston Office Router U-AP, >> running software version 3.7.1 AP.5. For some reason they cannot connect >to >> my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only >> allowed authentication scheme. "Any" doesnt work, chap kicks in and they >> get denied access. The Livingston box does have chap turned off, btw. We >> are stumped. Any help is much appreciated. >> >> Thanks >> >> Ted Cekan >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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.

Subject: RE: (usr-tc) Static IPs with large dialin pools
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 14:25:03

You have to run an interior routing protocol such as RIP or OSPF or apply static routes on your gateway router. I highly suggest using an interior routing protocol... Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Christopher Arlis Hanes Sent: Thursday, September 09, 1999 9:14 AM How does one handle static IPs when the pools used by a particular dialin number span multiple class Cs? (i.e. a user dialing in has the possibility of of dialing into a box whose router card is not on the same network as the user's static IP.) Thanks, Chris Hanes - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Server Assigned DNS
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 14:26:14

set nameserver 10.0.0.1 set nameserver 2 10.0.0.2 Nothing else should be needed, the Portmasters and Netservers will correctly send the dns servers as part of a normal PPP negotiation sequence with a customer dialing in... Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ben Tyger (vh.net staff) Sent: Wednesday, September 08, 1999 5:10 PM We are running a Port Master 2e, Total Control Netserver 16 v.34, and NETServer 16 - I Modem Plus. We are running it with 3.3.3 Livingston code. I am interested in running server assigned DNS. Is this possible? If so what changes to I have to do. -- Ben Tyger Virtual Horizons, Inc. technical staff Home Page: www.vh.net Tech email: support@vh.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Server Assigned DNS
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 14:26:14

Subject: RE: (usr-tc) problems with CHAP authentication
From: Jason Cropper <jason@clearsail.net>
Date: 1999-09-21 14:50:56

Do you want to use CHAP or PAP? You're not clear in your message. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan Sent: Tuesday, September 21, 1999 14:39 Hi, I have a user trying to dial in with a Livingston Office Router U-AP, running software version 3.7.1 AP.5. For some reason they cannot connect to my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only allowed authentication scheme. "Any" doesnt work, chap kicks in and they get denied access. The Livingston box does have chap turned off, btw. We are stumped. Any help is much appreciated. Thanks Ted Cekan - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Static IPs with large dialin pools
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 15:00:50

Actually this will not work on certain equipment like Livingston Portmaster 2s even though it should. Portmaster 2s do not seem to like any dialin network outside of the class C their ethernet port lives on. The other disadvantage with trying to side-step running OSPF or RIP is the difficulty in dealing with "routed network" or "static IP" customers. It quickly becomes a pain to deal with people having to dial into specific termservers to get their network blocks correctly routed to them. I suggest taking the jump now and running OSPF or RIP, you will probably have to sooner or later and it really makes life easy when you are done configuring it. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Tuesday, September 21, 1999 2:40 PM Thus spake Mike McHenry >You have to run an interior routing protocol such as RIP or OSPF or apply >static routes on your gateway router. I highly suggest using an interior >routing protocol... Of, if you're willing to toss the concept of address classes out the window (which I strongly urge you to do), you could just use a shorter netmask on the network, and everything happily continues to work. (if you insist on thinking classfully, this would be considered a supernet) :) -- 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.

Subject: RE: (usr-tc) problems with CHAP authentication
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 15:38:18

Yes, the USR will still try CHAP if you have it enabled. This setting FORCES the USR to try PAP negotiation first which is what you really want it to do. Then if PAP fails it will proceed with other forms of authentication including CHAP. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan Sent: Tuesday, September 21, 1999 3:22 PM Thanks Matthew, that worked! Does this setting mean that all users will now be authenticated with PAP? Will it ever even try CHAP for users that can use it? Ted Cekan -----Original Message----- > >Have you tried doing "set ppp authENTICATION_PREFERENCE pap"? That should >set PAP as the first authentication protocol to be used. > >On Tuesday, September 21, 1999 4:39 PM, Theodore Cekan [SMTP:ted@mho.net] >wrote: >> Hi, >> >> I have a user trying to dial in with a Livingston Office Router U-AP, >> running software version 3.7.1 AP.5. For some reason they cannot connect >to >> my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only >> allowed authentication scheme. "Any" doesnt work, chap kicks in and they >> get denied access. The Livingston box does have chap turned off, btw. We >> are stumped. Any help is much appreciated. >> >> Thanks >> >> Ted Cekan >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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.

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-21 15:39:36

Thus spake Mike McHenry >You have to run an interior routing protocol such as RIP or OSPF or apply >static routes on your gateway router. I highly suggest using an interior >routing protocol... Of, if you're willing to toss the concept of address classes out the window (which I strongly urge you to do), you could just use a shorter netmask on the network, and everything happily continues to work. (if you insist on thinking classfully, this would be considered a supernet) :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Static IPs with large dialin pools
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 15:42:21

> Personally, if I set this up and found that a PM wouldn't handle a > "supernet." I'd be calling Livingston^WLucent and screaming bloody > murder at not supporting classless addressing correctly. :) I pulled out enough hair on this one myself that I probably should. There is nothing like equipment that does not properly work with classless addressing :) It may well work as it should now, however I think ComOS 3.7.2 exhibited the same odd behavior and that is the most recent "stable" OS for the platform. In any case I thought I would throw out a warning for others... The main benefit IMO of running an IRP (interior routing protocol) is that any of my customers can dial into any bank of equipment at any time and get the same IP address or network block that I have assigned them. Without running some sort of IRP this is impossible to do. Just thought I would clarify that for anyone who was interested in the difference between running OSPF/RIP and not running it. Mike McHenry

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-21 16:10:26

Thus spake Mike McHenry >Actually this will not work on certain equipment like Livingston Portmaster >2s even though it should. Portmaster 2s do not seem to like any dialin >network outside of the class C their ethernet port lives on. The other >disadvantage with trying to side-step running OSPF or RIP is the difficulty >in dealing with "routed network" or "static IP" customers. It quickly >becomes a pain to deal with people having to dial into specific termservers >to get their network blocks correctly routed to them. >I suggest taking the jump now and running OSPF or RIP, you will probably >have to sooner or later and it really makes life easy when you are done >configuring it. Oh...I heartily agree...practically speaking you're going to be better off going to a dynamically routed situation when you get to that point (we use RIPv2 redistributed into OSPF at the first hop cisco). Just pointed out that the old classful thinking doesn't (shouldn't) restrict you to a single "Class C". Personally, if I set this up and found that a PM wouldn't handle a "supernet." I'd be calling Livingston^WLucent and screaming bloody murder at not supporting classless addressing correctly. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) problems with CHAP authentication
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-21 16:13:10

If you're using a Radius server with a DEFAULT entry pointing to a Unix password file, rather than storing the individual user profiles in the users file with passwords in clear text, CHAP will fail. To make CHAP work, add an entry for that user in the Radius users file. At 02:08 PM 9/21/99 -0600, you wrote: >Sorry, I need to use PAP. CHAP wont authenticate for some reason. > >Ted Cekan >Mile High Online >-----Original Message----- >From: Jason Cropper <jason@clearsail.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, September 21, 1999 2:03 PM >Subject: RE: (usr-tc) problems with CHAP authentication > > >>Do you want to use CHAP or PAP? You're not clear in your message. >> >>Jason >> >> >>-----Original Message----- >>From: owner-usr-tc@lists.xmission.com >>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan >>Sent: Tuesday, September 21, 1999 14:39 >>To: usr-tc@lists.xmission.com >>Subject: (usr-tc) problems with CHAP authentication >> >> >>Hi, >> >>I have a user trying to dial in with a Livingston Office Router U-AP, >>running software version 3.7.1 AP.5. For some reason they cannot connect >to >>my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only >>allowed authentication scheme. "Any" doesnt work, chap kicks in and they >>get denied access. The Livingston box does have chap turned off, btw. We >>are stumped. Any help is much appreciated. >> >>Thanks >> >>Ted Cekan >> >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) Cisco 802
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-21 16:39:11

Can anyone post a working config for a cisco 802 router connecting to a Total Control? Thanks, Jim

Subject: RE: (usr-tc) problems with CHAP authentication
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-21 16:47:15

Have you tried doing "set ppp authENTICATION_PREFERENCE pap"? That should set PAP as the first authentication protocol to be used. On Tuesday, September 21, 1999 4:39 PM, Theodore Cekan [SMTP:ted@mho.net] wrote: > Hi, > > I have a user trying to dial in with a Livingston Office Router U-AP, > running software version 3.7.1 AP.5. For some reason they cannot connect to > my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only > allowed authentication scheme. "Any" doesnt work, chap kicks in and they > get denied access. The Livingston box does have chap turned off, btw. We > are stumped. Any help is much appreciated. > > Thanks > > Ted Cekan > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-21 17:04:38

Thus spake Mike McHenry >> Personally, if I set this up and found that a PM wouldn't handle a >> "supernet." I'd be calling Livingston^WLucent and screaming bloody >> murder at not supporting classless addressing correctly. :) >I pulled out enough hair on this one myself that I probably should. There is >nothing like equipment that does not properly work with classless addressing >:) It may well work as it should now, however I think ComOS 3.7.2 exhibited >the same odd behavior and that is the most recent "stable" OS for the >platform. In any case I thought I would throw out a warning for others... Lovely...doncha just love bug hunting supposedly non-beta software for vendors? :/ >The main benefit IMO of running an IRP (interior routing protocol) is that >any of my customers can dial into any bank of equipment at any time and get >the same IP address or network block that I have assigned them. Without >running some sort of IRP this is impossible to do. Just thought I would >clarify that for anyone who was interested in the difference between running >OSPF/RIP and not running it. Amen...and if you're careful about how you assign your dynamic IP addresses for the non-static customers, you can still do summarization on them at your first-hop (maybe even sooner!) which will cut down on the /32's being advertised around your network...big win there! :) I tend to do summarization on the first-hop cisco since they have better control over summarization and redistribution. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Cisco 802 Connecting to ARC
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-21 17:35:41

We are trying to connect a Cisco 802 to our HiperARC chassis using ISDN and not having much success. Mon Radius shows the router authenticated fine. Mon PPP shows only an Outgoing PAP AUTH packet on the link. The router shows that it was authenticated. But then there is no additional PPP traffic. Eventually, the ARC gets an incoming LCP TERM packet from the router when the router decides to close down the link. The radius entry for the router is: router Password=secret Framed-IP-Address=xxx.xxx.32.35, Framed-IP-Netmask=255.255.255.255, Framed-Route="xxx.xxx.33.8/30 xxx.xxx.32.35 1" I'm sure there is something realy simple I am missing here... Thanks, -Jim Johnson

Subject: (usr-tc) WTB: Quad Analog/Digital Modems
From: Steve Rivera <sales@wrca.net>
Date: 1999-09-21 17:46:37

Sorry for the intrusion, but I am member of this list and know there are some of you that can help me out. I am located in NJ, hit pretty good by floyd. I have several customers that are in the same situation as Eric at Delaware Online. Soaked Equipment, although the drying methods mentioned will work in some cases it doesnt in most. After several attempts in that manner we are on the look out. If you have any quad analog/digital cards that you can sell or trade out for Quad digitals, you'd be helping out some of your own. We have heard some great support stories during this crisis. I hope we can add to it :) Please email or call me at sales@wrca.net or 732-833-2111 Appraciate any offers for available modem cards. .................................................... Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA) sales@wrca.net v-732-833-2111 pgr-732-325-1092 WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card) Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More

Subject: (usr-tc) Problems with a busy channel with no connection on it.
From: John Nelson <johnn@jorsm.com>
Date: 1999-09-21 18:14:41

We have a problem with a DSP (2.0.81), where the central office sees the trunk as idle, but TC is saying the trunk is busy. CLI on the hiper list connections shows nothing being connected to the card in question. Incoming calls were not failing, they were just given a busy signal. The card was put local out of service, the PRI is being used on another card with no problems as we speak, but TC is still showing one led lit in the modem section. Session monitor is showing one connection on one port only, even without a PRI. Has anyone else seen this problem? Where did it come from? How/can we catch this when/if it happens again? I know that resetting the card will more than likely clear everything up. Its just really strange to me. -John- =========================================================| | -John Nelson | email: | | --Technical Support | johnn@jorsm.com | | ---JORSM Internet | | | ----Toll Free # 1-877-JORSM95 | | ========================================================== ========================================================== | JORSM Internet | | Regional Premium Internet Service Provider | | Serving Chicagoland and NW Indiana | | 927 Sheffield Ave Dyer, IN | | Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com | ==========================================================

Subject: (usr-tc) Sega DreamCast
From: Robert Reynolds <lists@lcii.net>
Date: 1999-09-21 19:33:21

Anyone been able to get one these to connect to a TC or is it just me? Connected fine to our Cisco.

Subject: Re: (usr-tc) Playing with OSPF
From: Michael DeMan <michael@prf.org>
Date: 1999-09-21 20:47:50

Hi, How dangerous is the move from RIP to OSPF from a service outage point of view? I've never done OSPF routing before, but have been reading about it, and want to move over as soon as I can, but I'm worried about making a mess of the TC unit and having it down for a long period of time. Any advice out there? - Mike

Subject: Re: (usr-tc) Sega DreamCast
From: Ed <ed@taylors.com>
Date: 1999-09-21 21:30:23

Yes should work no problem. Have signed up at least 30 of them already. Ed ----- Original Message ----- Sent: Tuesday, September 21, 1999 8:33 PM Anyone been able to get one these to connect to a TC or is it just me? Connected fine to our Cisco. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Playing with OSPF
From: Rick <rallan@monmouth.com>
Date: 1999-09-21 21:34:52

You have to set the arc to be an ASBR (set ospf global asbr enable). Unlike cisco and other vendors where ASBR is determined by the ospf configuration, you must explicitly tell the arc to be an ASBR. Pretty backwards if you ask me but then again... Mike McHenry wrote: > I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have > started looking at switching them from RIP to OSPF. Everything is working as > I would expect for host dialins, HOWEVER it seems that the ARC is not > advertising any Framed-Routes setup through radius. > > For example, an entry like the following in radius: > > username Auth-Type=System > Service-Type=Framed-User, > Framed-IP-Address = 192.168.0.1, > Framed-Route = "10.0.0.1/24 192.168.0.1 1", > Framed-Routing = None, > > Once username dials into the TC the host route for 192.168.0.1 is correctly > broadcast through OSPF but the 10.0.0.1/24 route is not. Am I missing a > setting here or is this the normal behavior for the ARC card? Every other > piece of equipment I have recognizes this route added in through radius and > correctly advertise the route through OSPF. > > Mike > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: Re: (usr-tc) Playing with OSPF
From: Rick <rallan@monmouth.com>
Date: 1999-09-21 21:34:52

Subject: Re: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up
From: Rick <rallan@monmouth.com>
Date: 1999-09-21 21:41:07

Mike, rather then having to add a new OSPF SENDPOLICY for each framed-route profile(when you have hundreds that option is no longer feasible) why not just enable ASBR globally. We have it working here using " set ospf global asbr enable" . It seems the arc believes the framed-routes are being learned via another AS so it then propagates the route via ospf. Mike Wronski wrote: > |-----Original Message----- > |From: owner-totalcontrol@totalservice.3com.com > |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike > |McHenry > |Sent: Monday, September 20, 1999 7:01 AM > |Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF > |broadcasts? > | > | > |Reply to user-forum-totalcontrol@totalservice.3com.com > | > | > |I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have > |started looking at switching them from RIP to OSPF. Everything is > |working as I would expect for host dialins, HOWEVER it seems that the > |ARC is not advertising any Framed-Routes setup through radius. > | > |For example, an entry like the following in radius: > | > |username Auth-Type=System > | Service-Type=Framed-User, > | Framed-IP-Address = 192.168.0.1, > | Framed-Route = "10.0.0.1/24 192.168.0.1 1", > | Framed-Routing = None, > | > |Once username dials into the TC the host route for 192.168.0.1 is > |correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I > |missing a setting here or is this the normal behavior for the ARC card? > |Every other piece of equipment I have recognizes this route added in > |through radius and correctly advertise the route through OSPF. > | > > At this time you have to add a "SEND Policy" to get the framed-routes to > advertise. This iss done by > "ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE" > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: Re: (usr-tc) Sega DreamCast
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-21 21:47:00

At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote: >Anyone been able to get one these to connect to a TC or is it just me? > >Connected fine to our Cisco. This was discussed recently, I believe the answer was to enable ppp offloading -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Playing with OSPF
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-21 22:54:40

I highly recommend playing with it late at night, major routing changes never work as expected :) Leave your RIP routing configurations intact and worse case you can bring RIP back up if you can't get OSPF to work. If you have enough extra capacity just busy out a USR TC chassis and play with it. When you are in the middle of making changes anyone dialed into the chassis will not be able to go anywhere (depending on your exact routing configuration) so it is a somewhat disruptive thing to do. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan Sent: Tuesday, September 21, 1999 10:48 PM Hi, How dangerous is the move from RIP to OSPF from a service outage point of view? I've never done OSPF routing before, but have been reading about it, and want to move over as soon as I can, but I'm worried about making a mess of the TC unit and having it down for a long period of time. Any advice out there? - Mike

Subject: Re: (usr-tc) Sega DreamCast
From: Marius Strom <marius@alpha1.net>
Date: 1999-09-21 23:15:57

Connected fine to our TC.. Had to tack an extra "," behind the phone # to delay the 56k negotiation, however. -- Marius Strom <marius@alpha1.net> Professional Geek/Unix System Administrator Alpha1 Internet <http://www.alpha1.net> http://www.marius.org/marius.pgp 0x5645C228 In theory, there is no difference between theory and practice... ...In practice, there is a big difference. On Tue, 21 Sep 1999, Robert Reynolds wrote: > Anyone been able to get one these to connect to a TC or is it just me? > > Connected fine to our Cisco. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Sega DreamCast
From: Brian M. Gordon <administrator@westelcom.com>
Date: 1999-09-22 07:49:59

Assign DNS manual. ----- Original Message ----- Sent: Tuesday, September 21, 1999 9:47 PM > At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote: > >Anyone been able to get one these to connect to a TC or is it just me? > > > >Connected fine to our Cisco. > > This was discussed recently, I believe the answer was to enable ppp offloading > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Brian <signal@shreve.net>
Date: 1999-09-22 08:16:50

On Thu, 9 Sep 1999, Christopher Arlis Hanes wrote: > How does one handle static IPs when the pools used by a particular > dialin number span multiple class Cs? (i.e. a user dialing in has the > possibility of of dialing into a box whose router card is not on the > same network as the user's static IP.) use a dynamic interior routing protocol like OSPF/RipV2 > > Thanks, > Chris Hanes > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) Sega DreamCast
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1999-09-22 08:41:03

I believe the dreamcast uses an HCF =) ----- Original Message ----- Sent: Tuesday, September 21, 1999 9:47 PM > At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote: > >Anyone been able to get one these to connect to a TC or is it just me? > > > >Connected fine to our Cisco. > > This was discussed recently, I believe the answer was to enable ppp offloading > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Static IPs with large dialin pools
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-09-22 08:42:36

> How does one handle static IPs when the pools used by a particular > dialin number span multiple class Cs? (i.e. a user dialing in has the > possibility of of dialing into a box whose router card is not on the > same network as the user's static IP.) We actually force such users to NOT be in the same network as the 'router' card's NIC. The routing is handled by redistributing the RIPv2 routes into OSPF. Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Subject: Re: (usr-tc) Sega DreamCast
From: Chris Ashcraft <chris_ashcraft@mw.3com.com>
Date: 1999-09-22 08:43:19

Hi Ben, Should we keep a list of tips and tricks per the current client modems, e.g., the Sega DreamCast modem, Rockwell, and so on? see below Thanks /Chris K Mitchell <mitch@keyconn.net> on 09/21/99 08:47:00 PM Please respond to usr-tc@lists.xmission.com Sent by: K Mitchell <mitch@keyconn.net> cc: (Chris Ashcraft/MW/US/3Com) At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote: >Anyone been able to get one these to connect to a TC or is it just me? > >Connected fine to our Cisco. This was discussed recently, I believe the answer was to enable ppp offloading -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Static IPs with large dialin pools
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 1999-09-22 08:46:31

> Actually this will not work on certain equipment like Livingston > Portmaster 2s even though it should. Portmaster 2s do not seem to like > any dialin network outside of the class C their ethernet port lives > on. Hmmm, don't tell ours that... Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Subject: Re: (usr-tc) Sega DreamCast
From: Chris Ashcraft <chris_ashcraft@mw.3com.com>
Date: 1999-09-22 08:50:20

Please disregard my last email. ============================================================================== Hi Ben, Should we keep a list of tips and tricks per the current client modems, e.g., the Sega DreamCast modem, Rockwell, and so on? see below Thanks /Chris K Mitchell <mitch@keyconn.net> on 09/21/99 08:47:00 PM Please respond to usr-tc@lists.xmission.com Sent by: K Mitchell <mitch@keyconn.net> cc: (Chris Ashcraft/MW/US/3Com) At 07:33 PM 9/21/99 -0500, Robert Reynolds <lists@lcii.net> wrote: >Anyone been able to get one these to connect to a TC or is it just me? > >Connected fine to our Cisco. This was discussed recently, I believe the answer was to enable ppp offloading -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Managing a Total Control Chassis
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-22 09:41:23

Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Fri, 10 Sep 1999, Chris Ashcraft wrote: > > > 3Com is interested in how you manage the Total Control chassis. To help us > better serve you, please complete the brief section below and reply to this > email with your response. > > ================================================================================= > > 1. Simply rate the following Total Control management tools (1=used most; 3=used > least) > > 1 MIB browser (please indicate the software package you are using: NerveCenter, > CMU SNMP, UCD-SNMP, SNMPc, HP OpenView, other:(_________) > 2 Total Control Manager/HiPer ARC Manager > 3 Terminal emulation (e.g., Telnet or HyperTerminal) > > 2. Do you manage the various Total Control cards differently? If so, please list > which of the above management tools you most often use for: > - Quad Modem:___________________ > - Trunk Cards:___________________ > - HiPer DSP:CLI > - HiPer ARC:CLI > - EdgeServer Cards:___________________ > > ================================================================================= > > Any other comments or suggestions are welcome. > PORT TCM TO LINUX! PORT TCM TO LINUX! PORT TCM TO LINUX! > Thank you for your time. > > Carrier Systems Group > 3Com Corp. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) p50 question
From: Brian <signal@shreve.net>
Date: 1999-09-22 10:15:54

A little off topic, please no flames, I figured this would be the best list to ask this on. On the p50, do you have to configure the Rem Address to the IP address of say your router, your NAS, etc, or is their a way to just say like 0.0.0.0 and have it use the next hop? How do you all go about this? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) Cisco 800 to Arc
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-22 11:21:30

I am still having trouble getting any traffic passing between the ARCs and a Cisco 800. The MON PPP for the user is below: Outgoing PPP Data on interface: slot:14/mod:3 PAP ACK ....Tracing for user "xxx"; Escape to stop... Outgoing PPP Data on interface: slot:10/mod:13 PAP ACK ....Tracing for user "xxx"; Escape to stop... Incoming PPP Data on interface: slot:10/mod:13 LCP TERM_REQ Outgoing PPP Data on interface: slot:10/mod:13 LCP TERM_ACK Anyone have a suggestion? Thanks, Jim

Subject: (usr-tc) Moving on
From: Kurtiss Johnson <kurtiss_johnson@mw.3com.com>
Date: 1999-09-22 11:35:30

As a few of you have heard, I have reached a decision to move on to other opportunites, and so today is my last day with 3Com. I have certainly enjoyed my time with USR and then 3Com, made a lot of good friends (and met my wife!), and worked with a top-notch group of people both within and outside of the company. To say that I've had a lot of fun would be an understatement. I've been with USR/3Com for 7 years (almost exactly to the day), and it's time to move on to something different. I'll be taking a position with Advanced Switching Communications (ASC, Inc. - www.asc1.com) starting 9/27/99, where I'll be The Product Management Team. (Yes, the entire team. It's no longer challenging enough for me to be a single person, so I'm going to try to be a team now. OK, I'm kidding...actually, it's a start-up company.) I'm moving to Virginia (Washington DC/Reston/Vienna-area) as part of this new position, and as such I don't have an e-mail address or phone number at the new work location yet. In the meantime, I can be reached at "kwjohn@ais.net" or "kwjohn@mindspring.net" going forward. (Yes, those of you who know me shouldn't be surprised that I have two private e-mail accounts on two different ISPs.) In the meantime, I'll be unsubscribing from the various mail-lists that I'm a part of. I may be resubscribing to some of them, depending on my available time. The networking industry is small, and I am certain that I'll cross paths with many of you again throughout our careers. I look forward to it. Best of luck to all. KJ

Subject: (usr-tc) Cisco 800 to Arc
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-22 11:56:02

If anyone out there can take a look at this config/debug trace and tell me what the problem is, I would appreciate it. I hope I am not wrong in assuming that the Cisco 800 series can connect to the USR TC chassis. Regards, Jim ARC MON PPP

Subject: (usr-tc) need iformation about hiper DSP card
From: Simicro - RAKOTOBE Tatamo <tatamo@simicro.mg>
Date: 1999-09-22 12:00:13

Hi, I'm a student from Madagascar and I'm doing now a training at an ISP. We = want to give ISDN access to our Clients that why I contact you, we use = now Total control with Quad Modem card and Edge Server card.=20 Can you give me information related in ISDN, Hiper DSp card, Dual PRI = card, their price, and other technical information. Thank you. PS: is it possible to send the answer in french because I'm francophone. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* tatamo@simicro.mg na koa trakotob@syfed.refer.mg hafa koa shiny_lotus@geocities.com MADAGASIKARA *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

Subject: (usr-tc) RE: (3Com-TotalControl) Framed routes not being picked up by OSPF broadcasts?
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-22 12:58:50

Thank you for the advice everyone, turns out you do have to have the sendpolicy in place for framed routes to get advertised. This seems to be the case even with ASBR enabled, at least in my testing. I was however able to add a blanket sendpolicy that covered all my network blocks with one policy, something like add ospf sendpolicy 10.0.0.0/19 source remote action advertise This seems to correctly broadcast any framed route built by the ARC card in the 32 class C network blocks starting at 10.0.0.0 For anyone else who is interested in working on OSPF here are the commands (in order) that I used to configure OSPF on my USR ARC card. This was using area 1 with MD5 authentication, the eth:1 interface is 10.0.0.1, possible framed routes coming from 10.0.1.0/19 set ospf default_area_id 0.0.0.1 set ip network ip routing_protocol ospf set ospf global router_id 10.0.0.1 set ospf global asbr enable enable ospf set ospf interface 10.0.0.1 router_priority 0 set ospf interface 10.0.0.1 auth_type cryptographic add ospf cryptographic_key 1 interface 10.0.0.1 shared_key "YOUR_OSPF_KEY" add ospf sendpolicy 10.0.1.0/19 source remote action advertise Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick Sent: Tuesday, September 21, 1999 8:41 PM Cc: user-forum-totalcontrol@totalservice.3com.com picked up by OSPF broadcasts? Mike, rather then having to add a new OSPF SENDPOLICY for each framed-route profile(when you have hundreds that option is no longer feasible) why not just enable ASBR globally. We have it working here using " set ospf global asbr enable" . It seems the arc believes the framed-routes are being learned via another AS so it then propagates the route via ospf. Mike Wronski wrote: > |-----Original Message----- > |From: owner-totalcontrol@totalservice.3com.com > |[mailto:owner-totalcontrol@totalservice.3com.com]On Behalf Of Mike > |McHenry > |Sent: Monday, September 20, 1999 7:01 AM > |Subject: (3Com-TotalControl) Framed routes not being picked up by OSPF > |broadcasts? > | > | > |Reply to user-forum-totalcontrol@totalservice.3com.com > | > | > |I have recently upgraded most of my HiperARC cards to 4.2.32-1 and have > |started looking at switching them from RIP to OSPF. Everything is > |working as I would expect for host dialins, HOWEVER it seems that the > |ARC is not advertising any Framed-Routes setup through radius. > | > |For example, an entry like the following in radius: > | > |username Auth-Type=System > | Service-Type=Framed-User, > | Framed-IP-Address = 192.168.0.1, > | Framed-Route = "10.0.0.1/24 192.168.0.1 1", > | Framed-Routing = None, > | > |Once username dials into the TC the host route for 192.168.0.1 is > |correctly broadcast through OSPF but the 10.0.0.1/24 route is not. Am I > |missing a setting here or is this the normal behavior for the ARC card? > |Every other piece of equipment I have recognizes this route added in > |through radius and correctly advertise the route through OSPF. > | > > At this time you have to add a "SEND Policy" to get the framed-routes to > advertise. This iss done by > "ADD OSPF SENDPOLICY 10.0.0.1/24 SOURCE REMOTE ACTION ADVERTISE" > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Channelized T1 vs PRI
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-22 13:46:25

You should be able to use the same code for either a PRI or a channelized T1 on the DSP, just go into the TCM, select the T1 portion of the DSP (top LED below the power LED), click Configure-->Programmed Settings-->Trunk Settings You will see a setting called signal mode, it should be set to robbed bit for a channelized T1 and message oriented for a PRI. Unless the telco is changing other things (ie switch type, etc) that should be the only setting you need to change when the telco changes your PRI to a channelized T1. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew Sent: Wednesday, September 22, 1999 1:29 PM Overnight tonight the telco is changing one of our T1s to channelized T1 from PRI service for testing. I seem to remember that there is different code for the dual T1/PRI cards depending on which service you have but I'm using all DSPs now and I can't seem to have any CT1 specific code for these cards on TotalService. Does the one code base now support both CT1 and PRI or am I missing something? Thanks... Matthew - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Channelized T1 vs PRI
From: Jim Riley <jriley@infinityhealthcare.com>
Date: 1999-09-22 13:54:07

This is a cryptographically signed message in MIME format. --------------ms6DDF3DF98072ECBB8D34148C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You will no longer be able to do ISDN. "Stainforth, Matthew" wrote: > > Part of the reason we're doing this is because CT1 is cheaper but I've never > used CT1 before and I'm wondering what other functionality we're going to > lose. I gather it will no longer be possible to do busy out the channels > from this end and we'll also probably lose ANI too. Are there any other > drawbacks that I might be overlooking? > > On Wednesday, September 22, 1999 3:46 PM, Mike McHenry > [SMTP:mmchen@minn.net] wrote: > > You should be able to use the same code for either a PRI or a channelized > T1 > > on the DSP, just go into the TCM, select the T1 portion of the DSP (top > LED > > below the power LED), click Configure-->Programmed Settings-->Trunk > Settings > > > > You will see a setting called signal mode, it should be set to robbed bit > > for a channelized T1 and message oriented for a PRI. Unless the telco is > > changing other things (ie switch type, etc) that should be the only > setting > > you need to change when the telco changes your PRI to a channelized T1. > > > > Mike McHenry > > Systems Administrator > > MinnNet Communications, Inc. > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > > Sent: Wednesday, September 22, 1999 1:29 PM > > To: 'usr-tc@lists.xmission.com' > > Subject: (usr-tc) Channelized T1 vs PRI > > > > > > > > Overnight tonight the telco is changing one of our T1s to channelized T1 > > from PRI service for testing. I seem to remember that there is different > > code for the dual T1/PRI cards depending on which service you have but I'm > > using all DSPs now and I can't seem to have any CT1 specific code for > these > > cards on TotalService. Does the one code base now support both CT1 and > PRI > > or am I missing something? > > > > Thanks... > > > > Matthew > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. -- Jim Riley jriley@infinityhealthcare.com Network Specialist Infinity HealthCare, Inc. voice (414) 290-6751 1251 Glen Oaks Lane fax (414) 290-6780 Mequon, WI 53092 =================================================== --------------ms6DDF3DF98072ECBB8D34148C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKUQYJKoZIhvcNAQcCoIIKQjCCCj4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B90wggSnMIIEEKADAgECAhBRgJfTBjkhitGgd/zVpHdLMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDUyNjAwMDAw MFoXDTAwMDYwODIzNTk1OVowggEZMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEjAQBgNVBAMUCUppbSBSaWxleTEsMCoGCSqGSIb3DQEJ ARYdanJpbGV5QGluZmluaXR5aGVhbHRoY2FyZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAJ1wHI4M+VobqaDFePhj9NTcjhYgsOHcmGSvFpXYClv4MsKEiZ4KrlTttkTAnbpK x6yCORhvMzDPJqausWuajtVXrZg6oliNTxLIayLJX+urAO9Cq5UJDWuMm7TpkS3XXNjv9QI3 0zp//l7xwGqhFuOEo8BMNeD2/tLbIT3tx6ItAgMBAAGjggE4MIIBNDAJBgNVHRMEAjAAMIGs BgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIB ARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5 NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEGBwQiFiAxMjBkMWE3 NzUxYzBiMTg2MjE3MTNkNWYwYTFiNjkyYTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3Js LnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GBACPb4IlP1WpnvNDd cxV0AuVhVFqLM9lFixLUSZD9CFJ+Fp2z5yZi9B54c2NjU4dGTiXTUxZKSI2Okczptzt5Uiec h8G7fErsKpRi0D6o8QNV8UWSMDXGECPnmNkq20Ptr4BWPDoYIoqHYNLG+sd4zNNZXNUwO7hw DmvlPY7W1t+7MIIDLjCCApegAwIBAgIRANJ2Lo0UDD19sqglXa/uDXUwDQYJKoZIhvcNAQEC BQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5D bGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUx MjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24u Y29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYD VQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25h IE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6 ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIO Aukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nb N2rISsgJBuSZAgMBAAGjfDB6MBEGCWCGSAGG+EIBAQQEAwIBBjBHBgNVHSAEQDA+MDwGC2CG SAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEwDwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQECBQADgYEAiLg3 O93alDcAraqf4YEBcR6Sam0v9vGd08pkONwbmAwHhluFFWoPuUmFpJXxF31ntH8tLN2aQp7D PrSOquULBt7yVir6M8e+GddTTMO9yOMXtaRJQmPswqYXD11YGkk8kFxVo2UgAP0YIOVfgqax qJLFWGrBjQM868PNBaKQrm4xggI8MIICOAIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52 ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMp OTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVy LVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQUYCX0wY5IYrRoHf81aR3SzAJBgUrDgMCGgUAoIGx MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDkyMjE4NTQw N1owIwYJKoZIhvcNAQkEMRYEFFkVYqROGzLrZ7IxVvDqtrx98EIMMFIGCSqGSIb3DQEJDzFF MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAj84915UYeLEjyeY8RyHhHiY+idb7 uN2Xv/yg9/T49ryfqL+ForXRUDqsWcAAy8594U/BvNTF9MeNNqG0r6f6nQXD6YEfDaPf3Zxj kbDPrCYcJuZAFbbV2aoHhuKBk064QRJ/1mbYkAx4ASMmuRMLFlgtFaMhX8xQfLtu/8AhkF8= --------------ms6DDF3DF98072ECBB8D34148C--

Subject: RE: (usr-tc) Channelized T1 vs PRI
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-22 14:04:46

You should be able to busy out channels just like you did before with a CT1. CT1s also support ANI if configured that way from the telco. The only functionality I figure you will lose is the ability to take incoming 64k clear channel ISDN calls on your Total Control chassis. Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew Sent: Wednesday, September 22, 1999 1:49 PM Part of the reason we're doing this is because CT1 is cheaper but I've never used CT1 before and I'm wondering what other functionality we're going to lose. I gather it will no longer be possible to do busy out the channels from this end and we'll also probably lose ANI too. Are there any other drawbacks that I might be overlooking? On Wednesday, September 22, 1999 3:46 PM, Mike McHenry [SMTP:mmchen@minn.net] wrote: > You should be able to use the same code for either a PRI or a channelized T1 > on the DSP, just go into the TCM, select the T1 portion of the DSP (top LED > below the power LED), click Configure-->Programmed Settings-->Trunk Settings > > You will see a setting called signal mode, it should be set to robbed bit > for a channelized T1 and message oriented for a PRI. Unless the telco is > changing other things (ie switch type, etc) that should be the only setting > you need to change when the telco changes your PRI to a channelized T1. > > Mike McHenry > Systems Administrator > MinnNet Communications, Inc. > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > Sent: Wednesday, September 22, 1999 1:29 PM > To: 'usr-tc@lists.xmission.com' > Subject: (usr-tc) Channelized T1 vs PRI > > > > Overnight tonight the telco is changing one of our T1s to channelized T1 > from PRI service for testing. I seem to remember that there is different > code for the dual T1/PRI cards depending on which service you have but I'm > using all DSPs now and I can't seem to have any CT1 specific code for these > cards on TotalService. Does the one code base now support both CT1 and PRI > or am I missing something? > > Thanks... > > Matthew > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

Subject: (usr-tc) An odd authentication problem
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-22 14:16:38

For the past several months people have been reporting a LONG delay in authentication after connecting to our modems. Try as I might I couldn't duplicate this until today. Seems that normal PAP authentication works fine. However, about 1/10th of the time that I dial into my USR equipment using a terminal window I experience the problem. Here is what happens, dial into USR, handshake goes well, I am prompted for my login. After entering my username and hitting enter the USR hangs for about a minute before coming back with "Login incorrect" and then prompts me again for my username. It never asks for a password. Watching things on the radius server I see about 30 lines come across my radius logs saying something like "Error: no username: [] (from nas tc-1.minn.net)" Obviously my one minute delay on login is being caused by the USR timing out on this null username request. The question is why is the USR sending a null radius request and timing out on it? It only does this about 1/10th of the time and it never seems to happen when doing straight PAP. Anyone else run into this before? Mike McHenry Systems Administrator MinnNet Communications, Inc.

Subject: Re: (usr-tc) Channelized T1 vs PRI
From: Michael DeMan <michael@prf.org>
Date: 1999-09-22 14:24:04

Doesn't PRI have some advantages for error checking, etc. Basically it's easier to trace down and correct line noise problems, signal bounces, etc. than a channelized T1? - mike

Subject: Re: (usr-tc) Channelized T1 vs PRI
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-22 14:37:09

On Wed, 22 Sep 1999, Stainforth, Matthew wrote: > > Overnight tonight the telco is changing one of our T1s to channelized T1 > from PRI service for testing. I seem to remember that there is different > code for the dual T1/PRI cards depending on which service you have but I'm > using all DSPs now and I can't seem to have any CT1 specific code for these > cards on TotalService. Does the one code base now support both CT1 and PRI yes > or am I missing something? no

Subject: Re: (usr-tc) Channelized T1 vs PRI
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-22 14:59:52

You have to set signeling type from Message Oriented to RobbedBit in TC. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 22 Sep 1999, Stainforth, Matthew wrote: > > Overnight tonight the telco is changing one of our T1s to channelized T1 > from PRI service for testing. I seem to remember that there is different > code for the dual T1/PRI cards depending on which service you have but I'm > using all DSPs now and I can't seem to have any CT1 specific code for these > cards on TotalService. Does the one code base now support both CT1 and PRI > or am I missing something? > > Thanks... > > Matthew > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Channelized T1 vs PRI
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-22 15:03:30

At 01:46 PM 9/22/99 -0500, you wrote: >You should be able to use the same code for either a PRI or a channelized T1 >on the DSP, just go into the TCM, select the T1 portion of the DSP (top LED >below the power LED), click Configure-->Programmed Settings-->Trunk Settings > >You will see a setting called signal mode, it should be set to robbed bit >for a channelized T1 and message oriented for a PRI. Unless the telco is >changing other things (ie switch type, etc) > Switch type makes no difference on a CT1 >that should be the only setting >you need to change when the telco changes your PRI to a channelized T1. > You need to reboot the DSP card, and most likely the ARC card. In our experience, the ARC still shows it as a 23 channel circuit 'till you reboot, then it goes to 24. >Mike McHenry > Systems Administrator > MinnNet Communications, Inc. > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew >Sent: Wednesday, September 22, 1999 1:29 PM >To: 'usr-tc@lists.xmission.com' >Subject: (usr-tc) Channelized T1 vs PRI > > > >Overnight tonight the telco is changing one of our T1s to channelized T1 >from PRI service for testing. I seem to remember that there is different >code for the dual T1/PRI cards depending on which service you have but I'm >using all DSPs now and I can't seem to have any CT1 specific code for these >cards on TotalService. Does the one code base now support both CT1 and PRI >or am I missing something? > >Thanks... > >Matthew > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: RE: (usr-tc) Channelized T1 vs PRI
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-22 15:07:05

At 03:48 PM 9/22/99 -0300, you wrote: > >Part of the reason we're doing this is because CT1 is cheaper but I've never >used CT1 before and I'm wondering what other functionality we're going to >lose. I gather it will no longer be possible to do busy out the channels >from this end and we'll also probably lose ANI too. You can do a soft or hard busy out with CT1. You never had ANI to begin with - you had Calling Line ID. True ANI is only on FGD MF or ISUP trunks, and yes, you will lose Calling Line ID. >Are there any other >drawbacks that I might be overlooking? > Slightly lower modem performance - your 33.6 callers will probably be limited to 31.2, and your PCM (x2/v90) callers will probably lose a couple of kbps. >On Wednesday, September 22, 1999 3:46 PM, Mike McHenry >[SMTP:mmchen@minn.net] wrote: >> You should be able to use the same code for either a PRI or a channelized >T1 >> on the DSP, just go into the TCM, select the T1 portion of the DSP (top >LED >> below the power LED), click Configure-->Programmed Settings-->Trunk >Settings >> >> You will see a setting called signal mode, it should be set to robbed bit >> for a channelized T1 and message oriented for a PRI. Unless the telco is >> changing other things (ie switch type, etc) that should be the only >setting >> you need to change when the telco changes your PRI to a channelized T1. >> >> Mike McHenry >> Systems Administrator >> MinnNet Communications, Inc. >> >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew >> Sent: Wednesday, September 22, 1999 1:29 PM >> To: 'usr-tc@lists.xmission.com' >> Subject: (usr-tc) Channelized T1 vs PRI >> >> >> >> Overnight tonight the telco is changing one of our T1s to channelized T1 >> from PRI service for testing. I seem to remember that there is different >> code for the dual T1/PRI cards depending on which service you have but I'm >> using all DSPs now and I can't seem to have any CT1 specific code for >these >> cards on TotalService. Does the one code base now support both CT1 and >PRI >> or am I missing something? >> >> Thanks... >> >> Matthew >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) Channelized T1 vs PRI
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-22 15:29:01

Overnight tonight the telco is changing one of our T1s to channelized T1 from PRI service for testing. I seem to remember that there is different code for the dual T1/PRI cards depending on which service you have but I'm using all DSPs now and I can't seem to have any CT1 specific code for these cards on TotalService. Does the one code base now support both CT1 and PRI or am I missing something? Thanks... Matthew

Subject: RE: (usr-tc) Channelized T1 vs PRI
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-22 15:48:48

Part of the reason we're doing this is because CT1 is cheaper but I've never used CT1 before and I'm wondering what other functionality we're going to lose. I gather it will no longer be possible to do busy out the channels from this end and we'll also probably lose ANI too. Are there any other drawbacks that I might be overlooking? On Wednesday, September 22, 1999 3:46 PM, Mike McHenry [SMTP:mmchen@minn.net] wrote: > You should be able to use the same code for either a PRI or a channelized T1 > on the DSP, just go into the TCM, select the T1 portion of the DSP (top LED > below the power LED), click Configure-->Programmed Settings-->Trunk Settings > > You will see a setting called signal mode, it should be set to robbed bit > for a channelized T1 and message oriented for a PRI. Unless the telco is > changing other things (ie switch type, etc) that should be the only setting > you need to change when the telco changes your PRI to a channelized T1. > > Mike McHenry > Systems Administrator > MinnNet Communications, Inc. > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > Sent: Wednesday, September 22, 1999 1:29 PM > To: 'usr-tc@lists.xmission.com' > Subject: (usr-tc) Channelized T1 vs PRI > > > > Overnight tonight the telco is changing one of our T1s to channelized T1 > from PRI service for testing. I seem to remember that there is different > code for the dual T1/PRI cards depending on which service you have but I'm > using all DSPs now and I can't seem to have any CT1 specific code for these > cards on TotalService. Does the one code base now support both CT1 and PRI > or am I missing something? > > Thanks... > > Matthew > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Channelized T1 vs PRI
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-22 15:53:53

The ability to do ISDN at 64 KBps, some say that the robbed bit signeling is "dirty-er" then out of bands messageing on the D channel. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 22 Sep 1999, Stainforth, Matthew wrote: > > Part of the reason we're doing this is because CT1 is cheaper but I've never > used CT1 before and I'm wondering what other functionality we're going to > lose. I gather it will no longer be possible to do busy out the channels > from this end and we'll also probably lose ANI too. Are there any other > drawbacks that I might be overlooking? > > On Wednesday, September 22, 1999 3:46 PM, Mike McHenry > [SMTP:mmchen@minn.net] wrote: > > You should be able to use the same code for either a PRI or a channelized > T1 > > on the DSP, just go into the TCM, select the T1 portion of the DSP (top > LED > > below the power LED), click Configure-->Programmed Settings-->Trunk > Settings > > > > You will see a setting called signal mode, it should be set to robbed bit > > for a channelized T1 and message oriented for a PRI. Unless the telco is > > changing other things (ie switch type, etc) that should be the only > setting > > you need to change when the telco changes your PRI to a channelized T1. > > > > Mike McHenry > > Systems Administrator > > MinnNet Communications, Inc. > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew > > Sent: Wednesday, September 22, 1999 1:29 PM > > To: 'usr-tc@lists.xmission.com' > > Subject: (usr-tc) Channelized T1 vs PRI > > > > > > > > Overnight tonight the telco is changing one of our T1s to channelized T1 > > from PRI service for testing. I seem to remember that there is different > > code for the dual T1/PRI cards depending on which service you have but I'm > > using all DSPs now and I can't seem to have any CT1 specific code for > these > > cards on TotalService. Does the one code base now support both CT1 and > PRI > > or am I missing something? > > > > Thanks... > > > > Matthew > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: Re: (usr-tc) Channelized T1 vs PRI
From: Clayton Zekelman <clayton@mnsi.net>
Date: 1999-09-22 18:12:57

At 02:24 PM 9/22/99 -0700, you wrote: >Doesn't PRI have some advantages for error checking, etc. Basically it's >easier to trace down and correct line noise problems, signal bounces, etc. >than a channelized T1? Shouldn't be any differences. Possibly if the CT1 is configured with SF, you might not have as much diag info, but if the CT1 is configured as B8ZS/ESF (same framing as PRI), you'd have the same link diagnostics available. > >- mike > >---------- >>From: "Mike McHenry" <mmchen@minn.net> >>To: <usr-tc@lists.xmission.com> >>Subject: RE: (usr-tc) Channelized T1 vs PRI >>Date: Wed, Sep 22, 1999, 12:04 PM >> > >>You should be able to busy out channels just like you did before with a CT1. >>CT1s also support ANI if configured that way from the telco. The only >>functionality I figure you will lose is the ability to take incoming 64k >>clear channel ISDN calls on your Total Control chassis. >> >>Mike McHenry >> Systems Administrator >> MinnNet Communications, Inc. >> >>-----Original Message----- >>From: owner-usr-tc@lists.xmission.com >>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew >>Sent: Wednesday, September 22, 1999 1:49 PM >>To: 'usr-tc@lists.xmission.com' >>Subject: RE: (usr-tc) Channelized T1 vs PRI >> >> >> >>Part of the reason we're doing this is because CT1 is cheaper but I've never >>used CT1 before and I'm wondering what other functionality we're going to >>lose. I gather it will no longer be possible to do busy out the channels >>from this end and we'll also probably lose ANI too. Are there any other >>drawbacks that I might be overlooking? >> >>On Wednesday, September 22, 1999 3:46 PM, Mike McHenry >>[SMTP:mmchen@minn.net] wrote: >>> You should be able to use the same code for either a PRI or a channelized >>T1 >>> on the DSP, just go into the TCM, select the T1 portion of the DSP (top >>LED >>> below the power LED), click Configure-->Programmed Settings-->Trunk >>Settings >>> >>> You will see a setting called signal mode, it should be set to robbed bit >>> for a channelized T1 and message oriented for a PRI. Unless the telco is >>> changing other things (ie switch type, etc) that should be the only >>setting >>> you need to change when the telco changes your PRI to a channelized T1. >>> >>> Mike McHenry >>> Systems Administrator >>> MinnNet Communications, Inc. >>> >>> -----Original Message----- >>> From: owner-usr-tc@lists.xmission.com >>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew >>> Sent: Wednesday, September 22, 1999 1:29 PM >>> To: 'usr-tc@lists.xmission.com' >>> Subject: (usr-tc) Channelized T1 vs PRI >>> >>> >>> >>> Overnight tonight the telco is changing one of our T1s to channelized T1 >>> from PRI service for testing. I seem to remember that there is different >>> code for the dual T1/PRI cards depending on which service you have but I'm >>> using all DSPs now and I can't seem to have any CT1 specific code for >>these >>> cards on TotalService. Does the one code base now support both CT1 and >>PRI >>> or am I missing something? >>> >>> Thanks... >>> >>> Matthew >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >>> >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the 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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) ISDN Problem with Netgear RH348
From: Steve Coleman <scoleman2@csolutions.net>
Date: 1999-09-22 23:31:03

Can't seem to get this unit working in any configuration. We have are using the HiperArc and HiperDSP with the latest code on both. The connection will establish and work for a few minutes, but it keeps resetting, usually after 3-5 minutes. This happens if the Netgear calls in using NAT, calls in using a routed subnet, or if the HiperARC calls the Netgear. Idle timers on both ends have been set to 0. Any ideas? Thanks, Steve Coleman Computer Solutions

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-23 00:01:56

das writes... >I'm having quite a few problems with macs connecting with FreePPP to my HARC >running 4.1.59. It will never connect on the first try, but subsequent attempts >seem to be OK. It is completely reproduceable and is happening on more than one >card. It happened here too. I haven't checked to see if V4.2.29 fixes it, the problem might have went away, nobody has mentioned it for a while. -- Aaron Nabil

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-09-23 00:16:27

Speaking of 4.2.29, which manly men among us has this up and running? Hows it look? Hows the OSPF working so far? And in addition to the original post, we are having Mac problems as well, but the code release prior to 4.1.59 seemed to make the problem much worse if I recall correctly. Aaron Nabil wrote: > > das writes... > >I'm having quite a few problems with macs connecting with FreePPP to my HARC > >running 4.1.59. It will never connect on the first try, but subsequent attempts > >seem to be OK. It is completely reproduceable and is happening on more than one > >card. > > It happened here too. I haven't checked to see if V4.2.29 fixes it, the > problem might have went away, nobody has mentioned it for a while.

Subject: Re: (usr-tc) Cisco 802 Connecting to ARC
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-23 08:27:02

Thanks for all the help, but no luck. Anyone want to buy a SLIGHTLY USED Cisco 802 router, the customer we bought it for has moved on. Regards, Jim Jim Johnson wrote: > > We are trying to connect a Cisco 802 to our HiperARC chassis using ISDN > and not having much success. > > Mon Radius shows the router authenticated fine. > > Mon PPP shows only an Outgoing PAP AUTH packet on the link. > > The router shows that it was authenticated. > > But then there is no additional PPP traffic. > > Eventually, the ARC gets an incoming LCP TERM packet from the router > when the router decides to close down the link. > > The radius entry for the router is: > > router Password=secret > Framed-IP-Address=xxx.xxx.32.35, > Framed-IP-Netmask=255.255.255.255, > Framed-Route="xxx.xxx.33.8/30 xxx.xxx.32.35 1" > > I'm sure there is something realy simple I am missing here... > > Thanks, > > -Jim Johnson > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Undocumented DSP debug commands
From: Campbell Simpson <campbell.simpson@telecom.co.nz>
Date: 1999-09-23 09:37:01

Hi Was wondering if anyone out there has had a play around with the "trc" command on the HiPer DSP cards. The docs on the trc command are very brief and was wondering if anyone had a more complete explanation. What I want to be able to do is capture modem data as a call is in progress in a way similar to the Ascend MAX4000. Frantically typing AT commands to capture call info is not my idea of fun! Any help would be much appreciated. Campbell

Subject: (usr-tc) TCBox won't make T1 Connect
From: Jerry Wright <jwright@hyperserv.com>
Date: 1999-09-23 10:10:00

We have an older TC Box with digital/analog cards, and a dual T1 setup, as well as NMC and NetServer. Okay... If you set the modem card to Nic, you can dial in on an analog line and connect. If you dial in on the T1, nothing. Now, for a bit, it was working, but I didn't have the pool set properly in the Security Server, and authentication didn't work. That's fixed. Now, call-ins on the T1 say, "Your call did not go through, would you please hang up and dial again." We're set to esf and b8zs, wink start... just what the phone co wants. They say they can't get a wink acknowledge, our NAC passes allinternal tests. Local Digital loopback works, Remote loopback fails, and it says, NO dialtone. Any suggestions??? Jerry Wright www.iaml.net mailto:jwright@iaml.net mailto:jwright@hyperserv.com Internet Access of Moses Lake Hypernet Services.

Subject: Re: (usr-tc) Server Assigned DNS
From: Michael DeMan <michael@prf.org>
Date: 1999-09-23 11:43:53

I tried this on a HiperARC card and it still does not seem to work. Is there something else I need to configure, or is it different for HiperARC? - Mike

Subject: Re: (usr-tc) Cisco 802 Connecting to ARC
From: Jim Johnson <jim@perigee.net>
Date: 1999-09-23 12:41:47

Just kidding about selling the router to see if I could get anyone to respond. I am a little surprised that there is not more Cisco expertise on this list (e.g., the ppp 'callin' flag). I guess this list is more like a self help therapy session for overworked network technicians who can't complain to anyone else but their peers. :) Oh well, at least it works. This morning, after going through the warehouse full of poor documentation at www.cisco.com for the umpteenth time, I found out what the problem was and now we are up and running with the Cisco 802. Now, in case any of you folks ever need to connect a Cisco router to a TC chassis don't forget about *** unidirectional authentication ***! To allow the Cisco to connect without having to have the TC authenticate itself, the complete Cisco command is: (config-if)# ppp authentication pap callin This command enables PAP and specifies authentication on incoming calls only. Unidirectional authentication is used because non-Cisco routers that do not support bidirectional authentication (e.g., a TC Chassis). If you ever had a situation where you could not figure out why CHAP would work and PAP wouldn't, then you also needed to know this! Cheers, -Jim Jim Johnson wrote: > > Thanks for all the help, but no luck. > > Anyone want to buy a SLIGHTLY USED Cisco 802 router, the customer we > bought it for has moved on. > > Regards, > > Jim > > Jim Johnson wrote: > > > > We are trying to connect a Cisco 802 to our HiperARC chassis using ISDN > > and not having much success. > > > > Mon Radius shows the router authenticated fine. > > > > Mon PPP shows only an Outgoing PAP AUTH packet on the link. > > > > The router shows that it was authenticated. > > > > But then there is no additional PPP traffic. > > > > Eventually, the ARC gets an incoming LCP TERM packet from the router > > when the router decides to close down the link. > > > > The radius entry for the router is: > > > > router Password=secret > > Framed-IP-Address=xxx.xxx.32.35, > > Framed-IP-Netmask=255.255.255.255, > > Framed-Route="xxx.xxx.33.8/30 xxx.xxx.32.35 1" > > > > I'm sure there is something realy simple I am missing here... > > > > Thanks, > > > > -Jim Johnson > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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.

Subject: RE: (usr-tc) Upgrading DSPs
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-23 13:23:04

HiPer>> sho nmc NMC SETTINGS Chassis Awareness: ENABLED Dynamic Slot Assignment: DISABLED DSA Idle Rebalancing: ENABLED Invariably your Chassis Awareness is DISABLED, which will mean no "DYNAMIC" enable nmc chassis_awareness Will fix it. You'll probably want to reboot the ARC. SMT -----Original Message----- Sent: Thursday, September 23, 1999 12:28 PM Finally got my new DSP problems straightened out for the most part. Original card was bad, swapped with a replacement. Everything appears to be fine except I can't get the type from STATIC to DYNAMIC, seems to be working ok though so I'm not sure what difference it makes. On to my main point, I'm currently running 1.2.60 on all cards and 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1 worth bumping up to? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Upgrading DSPs
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-23 13:26:08

I have one stinkin' site where 2.0.81 = no Rockwell modes@V90 (long screeching, no negotiation), that site I use 1.2.59, everywhere else quite happy with 2.0.81. SMT -----Original Message----- Sent: Thursday, September 23, 1999 1:20 PM I'm running 2.0.81 on most of my DSPs and I have no complaints specific to that version. I needed it so I could do NFAS which also seems to work great. On Thursday, September 23, 1999 2:28 PM, K Mitchell [SMTP:mitch@keyconn.net] wrote: > On to my main point, I'm currently running 1.2.60 on all cards and > 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to > 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1 > worth bumping up to? > > Thanks, > Kirk > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Upgrading DSPs
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-23 13:27:49

Finally got my new DSP problems straightened out for the most part. Original card was bad, swapped with a replacement. Everything appears to be fine except I can't get the type from STATIC to DYNAMIC, seems to be working ok though so I'm not sure what difference it makes. On to my main point, I'm currently running 1.2.60 on all cards and 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1 worth bumping up to? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Server Assigned DNS
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-23 13:54:40

Ahh, Netserver and ARC are not the same thing, in your first email you said Netserver I believe. For an ARC card: set dns server 10.0.0.1 preference 1 set dns server 10.0.0.2 preference 2 Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan Sent: Thursday, September 23, 1999 1:44 PM I tried this on a HiperARC card and it still does not seem to work. Is there something else I need to configure, or is it different for HiperARC? - Mike

Subject: Re: (usr-tc) modem that will
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-09-23 13:55:51

From what is written, it seems that the modem picks up the call fine but there is no packet bus data to tell hiper arc to terminate call. try reset modem slot:x/mod:x Best bet is to go to tcm, and download the parameters from another good working modem. By these steps, you eradicate the packet bus, config values, only other thing might be the packet bus interface for that particular modem. This would come under hardware issue. Ahmed On Tue, 14 Sep 1999, Stainforth, Matthew wrote: > > I'm having a problem with one modem that refuses to pick up. When I watch > the status in performance monitor, I can see the call coming in (RingIn or > RingRcvd states), DNIS and ANI information comes up, but the modem never > picks up the call. I have replaced the DSP NAC and the problem didn't go > away. The only other place I can think to look is to the ARC itself but the > modem interface is UP/UP. I've also tried a full reconfig (restore from > default, save to nvram, reboot, reconfig, save to nvram, reboot) and no > luck. When a user happens to grab that line they hear a long pause of dead > air (maybe 5 seconds or more) and then it starts ringing endlessly. Any > ideas? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Cisco 800 to Arc
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-09-23 14:03:49

This only states that after the pap authentication, the end node is sending out a terminate request. Functionality of hiper arc is to send an ack to that packet. Need to provide the LCP config requests - mon ppp - next session. The end node is sending the terminate request - you need to look into his config settings - it should not be sending out a terminate request right after a auth ack. Ahmed On Wed, 22 Sep 1999, Jim Johnson wrote: > > If anyone out there can take a look at this config/debug trace and tell > me what the problem is, I would appreciate it. I hope I am not wrong in > assuming that the Cisco 800 series can connect to the USR TC chassis. > > Regards, > > Jim > > ARC MON PPP > ---------- > On the ARC all I see is: > > Outgoing PPP Data on interface: slot:10/mod:13 > PAP ACK ....Tracing for user "xxx"; Escape to > stop... > > Incoming PPP Data on interface: slot:10/mod:13 > LCP TERM_REQ > > Outgoing PPP Data on interface: slot:10/mod:13 > LCP TERM_ACK > > > > Cisco Config > -------------------------- > > ! > version 12.0 > no service pad > service timestamps debug uptime > service timestamps log uptime > service password-encryption > service udp-small-servers > service tcp-small-servers > > ! > hostname Router > > ! > no logging console > enable secret 5 $1$3NxJ$hNMKdU72/q/0z9vJLJRkv. > > ! > ip subnet-zero > > ! > isdn switch-type basic-ni > > ! > > ! > > ! > interface Ethernet0 > ip address xxx.xxx.63.9 255.255.255.252 > no ip directed-broadcast > ! > interface BRI0 > description PPP to Internet > ip address negotiated > no ip directed-broadcast > encapsulation ppp > dialer idle-timeout 2147483 > dialer map ip xxx.xxx.60.3 5551212 > dialer hold-queue 10 > dialer load-threshold 1 outbound > dialer-group 1 > isdn switch-type basic-ni > isdn spid1 70455511110100 > isdn spid2 70455511120100 > no fair-queue > no cdp enable > no ppp lcp fast-start > ppp authentication pap > ppp pap sent-username dsi password 7 130C2111020812 > > > > Debug Session > ------------------------------------ > > 03:07:55840355292: BR0:1 PPP: Treating connection as a callout > 03:07:55834615808: BR0:1 PPP: Phase is ESTABLISHING, Active Open > 03:07:55835256358: BR0:1 LCP: O CONFREQ [Closed] id 174 len 14 > 03:07:60129542143: BR0:1 LCP: AuthProto PAP (0x0304C023) > 03:07:55834615808: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6) > 03:07:14: BR0:1 PPP: I pkt type 0xC021, datagramsize 33 > 03:07:14: BR0:1 LCP: I CONFREQ [REQsent] id 1 len 29 > 03:07:14: BR0:1 LCP: MRU 1514 (0x010405EA) > 03:07:14: BR0:1 LCP: AuthProto PAP (0x0304C023) > 03:07:14: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04) > 03:07:14: BR0:1 LCP: PFC (0x0702) > 03:07:14: BR0:1 LCP: ACFC (0x0802) > 03:07:14: BR0:1 LCP: MRRU 1514 (0x110405EA) > 03:07:14: BR0:1 LCP: EndpointDisc 0 Null (0x130300) > 03:07:15: BR0:1 LCP: O CONFREJ [REQsent] id 1 len 11 > .03:07:15: BR0:1 LCP: MRRU 1514 (0x110405EA) > 03:07:15: BR0:1 LCP: EndpointDisc 0 Null (0x130300) > 03:07:15: BR0:1 PPP: I pkt type 0xC021, datagramsize 26 > 03:07:15: BR0:1 LCP: I CONFREQ [REQsent] id 2 len 22 > 03:07:15: BR0:1 LCP: MRU 1514 (0x010405EA) > 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023) > 03:07:15: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04) > 03:07:15: BR0:1 LCP: PFC (0x0702) > 03:07:15: BR0:1 LCP: ACFC (0x0802) > 03:07:15: BR0:1 LCP: O CONFACK [REQsent] id 2 len 22 > 03:07:15: BR0:1 LCP: MRU 1514 (0x010405EA) > 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023) > 03:07:15: BR0:1 LCP: MagicNumber 0xB6EBDD04 (0x0506B6EBDD04) > 03:07:15: BR0:1 LCP: PFC (0x0702) > 03:07:15: BR0:1 LCP: ACFC (0x0802) > 03:07:15: BR0:1 LCP: TIMEout: State ACKsent > 03:07:15: BR0:1 LCP: O CONFREQ [ACKsent] id 175 len 14 > 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023) > 03:07:15: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6) > 03:07:15: BR0:1 PPP: I pkt type 0xC021, datagramsize .18 > 03:07:15: BR0:1 LCP: I CONFACK [ACKsent] id 175 len 14 > 03:07:15: BR0:1 LCP: AuthProto PAP (0x0304C023) > 03:07:15: BR0:1 LCP: MagicNumber 0xD0B16CC6 (0x0506D0B16CC6) > 03:07:15: BR0:1 LCP: State is Open > 03:07:15: BR0:1 PPP: Phase is AUTHENTICATING, by both > 03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) queued > 1/1/2 > 03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.) > queued 2/2/2 > 03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) busy/0 > started 1/2/2 > 03:07:15: BR0:1 PAP: O AUTH-REQ id 51 len 15 from "dsi" > 03:07:15: BR0:1: PAP_SENDREQUEST (0x288A500) id 0 (0s.) busy/0 done > in 0 s. 0/1/2 > 03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.) > busy/0 started 1/1/2 > 03:07:15: BR0:1: AAA_PER_USER LCP_UP (0x288A5B0) id 0 (0s.) > busy/0 done in 0 s. 0/0/2 > 03:07:16: BR0:1 PPP: I pkt type 0xC023, datagramsize 9 > 03:07:16: BR0:1 PAP: I AUTH-ACK id 51 len 5. > 03:07:19: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 9440140 > .. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Mike McHenry <mmchen@minn.net>
Date: 1999-09-23 14:04:52

Have been running 4.2.32-1 for about a week on my production chassis, everything is working very well so far. I have yet to see or hear of any customer problems. I would rank 4.2.32-1 as being one of the most stable releases yet, if there were any serious issues I am sure I would have heard about them by now :) OSPF is working very well too, the configuration was a little cryptic to me at first (see the archives for my configuration steps) but now that I think about things it really was no different than the OSPF setup on any other piece of equipment, just different :) Mike McHenry Systems Administrator MinnNet Communications, Inc. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of mmm3@cornell.edu Sent: Thursday, September 23, 1999 1:52 PM >Speaking of 4.2.29, which manly men among us has this up and running? >Hows it look? Hows the OSPF working so far? Manly men??? Hmph. 4.2.29 was removed from the downloads because of major problems with the code. The latest version is 4.2.32-1 which I have downloaded but am not *manly* enough to put on my ARCs yet. Am waiting to hear from others, first. 8-) ********************************************************* Michelle M. Mogil N&CS, Network Operations Center Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-23 14:10:20

So far so good with the very manly 4.2.32 code. I've got 4 of 'em on this rev of code for a week and no problems. I'm not using the extremely manly OSPF yet (subject of most commentary so far), using the un-manly rip->OSPF gateway of yore yet. SMT -----Original Message----- Sent: Thursday, September 23, 1999 1:52 PM >Speaking of 4.2.29, which manly men among us has this up and running? >Hows it look? Hows the OSPF working so far? Manly men??? Hmph. 4.2.29 was removed from the downloads because of major problems with the code. The latest version is 4.2.32-1 which I have downloaded but am not *manly* enough to put on my ARCs yet. Am waiting to hear from others, first. 8-) ********************************************************* Michelle M. Mogil N&CS, Network Operations Center Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu ********************************************** - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) ISDN on TC
From: Mike Wilker <mikew@ll.net>
Date: 1999-09-23 14:13:29

Is there any way to either do 56K DOV over Channelize T1 on a HiperArc, or is there a BRI product for the TC? Thanks. Mike Wilker Operations Manager Local Link, Inc.

Subject: RE: (usr-tc) Upgrading DSPs
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-23 14:41:22

At 01:23 PM 9/23/99 -0500, Scott Trautman <scottt@corp.gdinet.com> wrote: >Invariably your Chassis Awareness is DISABLED, which will mean no "DYNAMIC" > >enable nmc chassis_awareness > >Will fix it. I thought I had it enabled, apparently not :o/ >You'll probably want to reboot the ARC. If I'm gonna reboot the ARC anyway, any issues or warnings for 4.2.31-1? Thanks, Kirk -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Upgrading DSPs
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-23 14:44:00

At 03:28 PM 9/23/99 -0300, "Stainforth, Matthew" <MatthewS@staff.brunnet.net> wrote: > >Speaking of firmware problems, has anyone heard if 3Com is almost ready to >release a version that fixes that stupid "modems go freaky in pairs" >problem? I have 6 channels busied out due to this at the moment. I know >there was some bleeding edge code that helped but I'm less than enthusiastic >about running that on my production boxes. Does rebooting the DSP take care of the modems? I have a pair on one card that go freaky every few weeks. I just busy out the card to shove all my traffic off, reboot the card, restore to service, and it's good for another few weeks. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: mmm3@cornell.edu
Date: 1999-09-23 14:52:26

>Speaking of 4.2.29, which manly men among us has this up and running? >Hows it look? Hows the OSPF working so far? Manly men??? Hmph. 4.2.29 was removed from the downloads because of major problems with the code. The latest version is 4.2.32-1 which I have downloaded but am not *manly* enough to put on my ARCs yet. Am waiting to hear from others, first. 8-) ********************************************************* Michelle M. Mogil N&CS, Network Operations Center Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************

Subject: (usr-tc) Problems with macs and HiperARC 4.1.59
From: das <das@gol.com>
Date: 1999-09-23 15:06:12

I'm having quite a few problems with macs connecting with FreePPP to my HARC running 4.1.59. It will never connect on the first try, but subsequent attempts seem to be OK. It is completely reproduceable and is happening on more than one card. I am willing to re-flash the card to older code, except the last time I did this the HARC lost it's configuration. (forgot it's IP Address) Being that the problem cards are in remote pops, I would rather try a fix for the current code first. Anyone have any ideas? Sorry if this has been answered before, I was mysteriously unsubscribed from this list and missed a lot of posts. das -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________

Subject: RE: (usr-tc) Upgrading DSPs
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-23 15:20:12

I'm running 2.0.81 on most of my DSPs and I have no complaints specific to that version. I needed it so I could do NFAS which also seems to work great. On Thursday, September 23, 1999 2:28 PM, K Mitchell [SMTP:mitch@keyconn.net] wrote: > On to my main point, I'm currently running 1.2.60 on all cards and > 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to > 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1 > worth bumping up to? > > Thanks, > Kirk > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Upgrading DSPs
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-23 15:28:46

Speaking of firmware problems, has anyone heard if 3Com is almost ready to release a version that fixes that stupid "modems go freaky in pairs" problem? I have 6 channels busied out due to this at the moment. I know there was some bleeding edge code that helped but I'm less than enthusiastic about running that on my production boxes. On Thursday, September 23, 1999 3:26 PM, Scott Trautman [SMTP:scottt@corp.gdinet.com] wrote: > I have one stinkin' site where 2.0.81 = no Rockwell modes@V90 (long > screeching, no negotiation), > that site I use 1.2.59, everywhere else quite happy with 2.0.81. > > SMT > > -----Original Message----- > From: Stainforth, Matthew [mailto:MatthewS@staff.brunnet.net] > Sent: Thursday, September 23, 1999 1:20 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Upgrading DSPs > > > > I'm running 2.0.81 on most of my DSPs and I have no complaints specific to > that version. I needed it so I could do NFAS which also seems to work > great. > > On Thursday, September 23, 1999 2:28 PM, K Mitchell [SMTP:mitch@keyconn.net] > wrote: > > On to my main point, I'm currently running 1.2.60 on all cards and > > 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to > > 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1 > > worth bumping up to? > > > > Thanks, > > Kirk > > > > -- > > Kirk Mitchell-General Manager mitch@keyconn.net > > Keystone Connect Unlock Your World > > Altoona, PA 814-941-5000 http://www.keyconn.net > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Server Assigned DNS
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-23 16:02:05

There are two other places you can set this information. I don't know what the effects of each of them are, but I put all three of them in, just for good measure. I got this from a config Charles Sprickman once posted to this list (thanks Charles!) which I use as a base config when I set up a new box. add dns server x.x.x.x preference 1 set ppp pppdns_primary x.x.x.x set network user default primary_dns_server x.x.x.x secondary_dns_server y.y.y.y On Thursday, September 23, 1999 3:55 PM, Mike McHenry [SMTP:mmchen@minn.net] wrote: > Ahh, Netserver and ARC are not the same thing, in your first email you said > Netserver I believe. For an ARC card: > > set dns server 10.0.0.1 preference 1 > set dns server 10.0.0.2 preference 2 > > Mike McHenry > Systems Administrator > MinnNet Communications, Inc. > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan > Sent: Thursday, September 23, 1999 1:44 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Server Assigned DNS > > > I tried this on a HiperARC card and it still does not seem to work. Is > there something else I need to configure, or is it different for HiperARC? > > - Mike > > > ---------- > >From: "Mike McHenry" <mmchen@minn.net> > >To: <usr-tc@lists.xmission.com>, <usr-tc@xmission.com> > >Subject: RE: (usr-tc) Server Assigned DNS > >Date: Tue, Sep 21, 1999, 12:26 PM > > > > >set nameserver 10.0.0.1 > >set nameserver 2 10.0.0.2 > > > >Nothing else should be needed, the Portmasters and Netservers will > correctly > >send the dns servers as part of a normal PPP negotiation sequence with a > >customer dialing in... > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

Subject: RE: (usr-tc) Upgrading DSPs
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-23 16:08:08

Rebooting does seem to correct the DSPs for a while but the problem always creeps back. They always go in adjacent pairs because one controller controls two adjacent modems. As fate would have it, the very first two modems in my largest hunt group went freaky the other day. I haven't noticed whether the problem creeps back on the very same two modems every time or if it's random though since I always just busy out the trunks and wait until I have another reason to reboot the card, by which time I've long since forgotten which two modems they were :) On Thursday, September 23, 1999 3:44 PM, K Mitchell [SMTP:mitch@keyconn.net] wrote: > At 03:28 PM 9/23/99 -0300, "Stainforth, Matthew" > <MatthewS@staff.brunnet.net> wrote: > > > Does rebooting the DSP take care of the modems? I have a pair on one card > that go freaky every few weeks. I just busy out the card to shove all my > traffic off, reboot the card, restore to service, and it's good for another > few weeks. > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-23 16:37:17

4.2.32-1 works well for us *except* for the route aggregation bug I've mentioned a few times before. Whether it's OSPF-specific or not I'm not sure. Whether or not it's a problem in practice depends on how your subnets are laid out... Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." On Thu, 23 Sep 1999, Mike McHenry wrote: > Have been running 4.2.32-1 for about a week on my production chassis, > everything is working very well so far. I have yet to see or hear of any > customer problems. I would rank 4.2.32-1 as being one of the most stable > releases yet, if there were any serious issues I am sure I would have heard > about them by now :)

Subject: Re: (usr-tc) Upgrading DSPs
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-23 16:38:24

2.0.81 works pretty well for everything but Rockwell HCF's. Still major problems with that combo... though most of it is really on the Rockwell end, and upgrading to the newest Rockwell HCF drivers takes care of it completely 99% of the time. Mike Andrews (MA12) -=-=- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=--=- mandrews@bit0.com -=--=- http://www.bit0.com "If you're not part of the solution.... you're part of the precipitate." On Thu, 23 Sep 1999, K Mitchell wrote: > Finally got my new DSP problems straightened out for the most part. > Original card was bad, swapped with a replacement. Everything appears to be > fine except I can't get the type from STATIC to DYNAMIC, seems to be > working ok though so I'm not sure what difference it makes. > On to my main point, I'm currently running 1.2.60 on all cards and > 4.1.59-6 ARC code. On the DSPs, should I go with 1.2.37 or move up to > 2.0.81? Any problems with either? Same question on the ARC, is 4.2.31-1 > worth bumping up to?

Subject: (usr-tc) Latest Netserver code?
From: Martin Oberle <moberle@gmx.de>
Date: 1999-09-23 17:14:05

Hi, I have to update my Total Control Netserver to be Y2K. I use the Netserver to dial out. I believe someone posted in this list that the netserver code 3.8 (which I think is the newest) has bug and doesn't support dial out. Is this true? Thanks Martin

Subject: (usr-tc) ActionTec Call waiting modem?
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-23 17:48:14

Has anybody tried this call-waiting modem? Supposedly it'll allow you to answer a call and talk for up to 7 seconds without dropping the connection to the ISP. I'm a little skeptical but I'm willing to entertain the thought. There's a brief promo at http://www.actiontec.com/products/modems/cwi/index.html Matthew

Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-09-23 18:02:38

On Wed, 22 Sep 1999, Steve Coleman wrote: > Can't seem to get this unit working in any configuration. We have are using > the HiperArc and HiperDSP with the latest code on both. The connection will > establish and work for a few minutes, but it keeps resetting, usually after > 3-5 minutes. This happens if the Netgear calls in using NAT, calls in using > a routed subnet, or if the HiperARC calls the Netgear. Idle timers on both > ends have been set to 0. Any ideas? Latest code as in 4.2.32-1 on the ARC? Hmm. I know we are running 2.0.81/4.1.59 and my Netgear RT-328 at the house hasnt had any problems. I use NAT also. Your Netgear is using v1.50 frimware I hope? ___ ___ (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Ken Kirchner <kenk@shreve.net>
Date: 1999-09-23 18:10:01

On Thu, 23 Sep 1999 mmm3@cornell.edu wrote: > >Speaking of 4.2.29, which manly men among us has this up and running? > >Hows it look? Hows the OSPF working so far? > > Manly men??? Hmph. 4.2.29 was removed from the downloads because of > major problems with the code. The latest version is 4.2.32-1 which I > have downloaded but am not *manly* enough to put on my ARCs yet. Am > waiting to hear from others, first. 8-) Well I meant that in a completely gender neutral way. ;-) In the future I will use "fearless guinea pigs." heh Yes, I meant 4.2.31. Looks like a few people have tried it and it looks good *so far*. ___ ___ (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___) (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_)

Subject: Re: (usr-tc) ISDN on TC
From: Paul Farber <farber@admin.f-tech.net>
Date: 1999-09-23 19:28:45

DOV is a telco switch issue. 5Ess will do it, but the telco can simply "turn it off" and filter the tone (2100Hz??) that tells the switch to keep 56K and not shift to 64K. BA in PA at my local 5Ess turned it off... rat turds! ISDN is a big seller for small biz.. but it's a hard sell when you say "per minute charges". Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 23 Sep 1999, Mike Wilker wrote: > Is there any way to either do 56K DOV over Channelize T1 on a HiperArc, or > is there a BRI product for the TC? Thanks. > > Mike Wilker > Operations Manager > Local Link, Inc. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
From: Steve Coleman <scoleman2@csolutions.net>
Date: 1999-09-23 20:54:24

It turned out to be a CHAP problem. It would authenticate and work for about 3 minutes, then the CHAP timed out and disconnected. I switched to PAP and it's been fine. Thanks. ----- Original Message ----- Sent: Thursday, September 23, 1999 5:02 PM > On Wed, 22 Sep 1999, Steve Coleman wrote: > > > Can't seem to get this unit working in any configuration. We have are using > > the HiperArc and HiperDSP with the latest code on both. The connection will > > establish and work for a few minutes, but it keeps resetting, usually after > > 3-5 minutes. This happens if the Netgear calls in using NAT, calls in using > > a routed subnet, or if the HiperARC calls the Netgear. Idle timers on both > > ends have been set to 0. Any ideas? > > Latest code as in 4.2.32-1 on the ARC? Hmm. I know we are running > 2.0.81/4.1.59 and my Netgear RT-328 at the house hasnt had any problems. > I use NAT also. Your Netgear is using v1.50 frimware I hope? > ___ ___ > (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___) > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Multilink Question
From: Steve Coleman <scoleman2@csolutions.net>
Date: 1999-09-23 22:31:31

I have a ISDN user setup as network,dialout, continuous. It works fine when the HiperARC first calls the client. It bonds both channels just great. If for some reason a channel is dropped, the HiperARC never tries to re-establish the dropped channel. I have tried both linear and constant for the expansion algorithm. How do you make the HiperARC maintain 2 channels relentlessly?

Subject: RE: (usr-tc) Server Assigned DNS
From: vanhalen@coredcs.com
Date: 1999-09-23 23:12:01

Any chance of getting that config from Mr. Sprickman posted to the list? On Thu, 23 Sep 1999, Stainforth, Matthew wrote: > > There are two other places you can set this information. I don't know what > the effects of each of them are, but I put all three of them in, just for > good measure. I got this from a config Charles Sprickman once posted to > this list (thanks Charles!) which I use as a base config when I set up a new > box. > > add dns server x.x.x.x preference 1 > set ppp pppdns_primary x.x.x.x > set network user default primary_dns_server x.x.x.x secondary_dns_server > y.y.y.y > > On Thursday, September 23, 1999 3:55 PM, Mike McHenry [SMTP:mmchen@minn.net] > wrote: > > Ahh, Netserver and ARC are not the same thing, in your first email you > said > > Netserver I believe. For an ARC card: > > > > set dns server 10.0.0.1 preference 1 > > set dns server 10.0.0.2 preference 2 > > > > Mike McHenry > > Systems Administrator > > MinnNet Communications, Inc. > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan > > Sent: Thursday, September 23, 1999 1:44 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Server Assigned DNS > > > > > > I tried this on a HiperARC card and it still does not seem to work. Is > > there something else I need to configure, or is it different for HiperARC? > > > > - Mike > > > > > > ---------- > > >From: "Mike McHenry" <mmchen@minn.net> > > >To: <usr-tc@lists.xmission.com>, <usr-tc@xmission.com> > > >Subject: RE: (usr-tc) Server Assigned DNS > > >Date: Tue, Sep 21, 1999, 12:26 PM > > > > > > > >set nameserver 10.0.0.1 > > >set nameserver 2 10.0.0.2 > > > > > >Nothing else should be needed, the Portmasters and Netservers will > > correctly > > >send the dns servers as part of a normal PPP negotiation sequence with a > > >customer dialing in... > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: (usr-tc) Acct-Terminate-Cause values
From: ROC Services <roc@itol.com>
Date: 1999-09-24 00:19:20

Since just recently (probably since upgrading to 4.2 HiperARC code) I'm seeing a fair number of RADIUS log entries with Terminate-Cause 29 and 30 which are not in my RADIUS dictionary, nor in RFC 2139, nor revealed by a quick perusal of the HiPerARC reference guide. Can any of the TC gurus give me a quick answer as to what these are? A pointer to the correct FM to read would be fine also. Thanks...

Subject: Re: (usr-tc) ISDN on TC
From: Mike Wilker <mikew@ll.net>
Date: 1999-09-24 11:14:28

So if it is enabled on the switch, I can have an ISDN user connect with an ISDN modem on either one or two channels to my HiperDSP with a Channelized T1? Will it have a port type of Async or ISDN? ----- Original Message ----- Sent: Thursday, September 23, 1999 6:28 PM > DOV is a telco switch issue. 5Ess will do it, but the telco can simply > "turn it off" and filter the tone (2100Hz??) that tells the switch to keep > 56K and not shift to 64K. > > BA in PA at my local 5Ess turned it off... rat turds! ISDN is a big > seller for small biz.. but it's a hard sell when you say "per minute > charges". > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Thu, 23 Sep 1999, Mike Wilker wrote: > > > Is there any way to either do 56K DOV over Channelize T1 on a HiperArc, or > > is there a BRI product for the TC? Thanks. > > > > Mike Wilker > > Operations Manager > > Local Link, Inc. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) ISDN Problem with Netgear RH348
From: John Schmerold <john@katy.com>
Date: 1999-09-24 11:33:51

I don't remember why, but PAP is all we use with the Netserver+ 8I Steve Coleman wrote: > It turned out to be a CHAP problem. It would authenticate and work for > about 3 minutes, then the CHAP timed out and disconnected. I switched to > PAP and it's been fine. > > Thanks. > > ----- Original Message ----- > From: Ken Kirchner <kenk@shreve.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, September 23, 1999 5:02 PM > Subject: Re: (usr-tc) ISDN Problem with Netgear RH348 > > > On Wed, 22 Sep 1999, Steve Coleman wrote: > > > > > Can't seem to get this unit working in any configuration. We have are > using > > > the HiperArc and HiperDSP with the latest code on both. The connection > will > > > establish and work for a few minutes, but it keeps resetting, usually > after > > > 3-5 minutes. This happens if the Netgear calls in using NAT, calls in > using > > > a routed subnet, or if the HiperARC calls the Netgear. Idle timers on > both > > > ends have been set to 0. Any ideas? > > > > Latest code as in 4.2.32-1 on the ARC? Hmm. I know we are running > > 2.0.81/4.1.59 and my Netgear RT-328 at the house hasnt had any problems. > > I use NAT also. Your Netgear is using v1.50 frimware I hope? > > ___ ___ > > (___) Kenneth Kirchner .o. mailto:kenk@shreve.net (___) > > (__) Asst SysAdmin .o. Voice (318) 222-2638 Ext 108 (__) > > (_) ShreveNet, Inc. .o. Fax (318) 213-6612 (_) > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- John Schmerold Katy Computer, LLC 20 Meramec Station Rd Valley Park, MO 63088 314-316-9000 314-316-9200 fax

Subject: Re: (usr-tc) Multilink Question
From: Steve Rivera <sales@wrca.net>
Date: 1999-09-24 11:53:50

The customer may be varying the bond on his hardware. I run MultiLink PPP here and I have my office router config'd for 55%. That where the other channel will kick in. It may be possible that he is dropping the line. At 10:31 PM 09/23/1999 -0600, you wrote: >I have a ISDN user setup as network,dialout, continuous. It works fine when >the HiperARC first calls the client. It bonds both channels just great. If >for some reason a channel is dropped, the HiperARC never tries to >re-establish the dropped channel. I have tried both linear and constant >for the expansion algorithm. How do you make the HiperARC maintain 2 >channels relentlessly? > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) problems with CHAP authentication
From: Ahmed Saeed <ahmed.saeed@widener.edu>
Date: 1999-09-24 12:33:52

kindly post the ppp negotiation and the show ppp settings. Ahmed On Tue, 21 Sep 1999, Theodore Cekan wrote: > Hi, > > I have a user trying to dial in with a Livingston Office Router U-AP, > running software version 3.7.1 AP.5. For some reason they cannot connect to > my TC Hiper system, ARC verson 4.1.59, unless PAP is selected as the only > allowed authentication scheme. "Any" doesnt work, chap kicks in and they > get denied access. The Livingston box does have chap turned off, btw. We > are stumped. Any help is much appreciated. > > Thanks > > Ted Cekan > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: mmm3@cornell.edu
Date: 1999-09-24 14:49:50

>On Thu, 23 Sep 1999 mmm3@cornell.edu wrote: > >> >Speaking of 4.2.29, which manly men among us has this up and running? >> >Hows it look? Hows the OSPF working so far? >> >> Manly men??? Hmph. 4.2.29 was removed from the downloads because of >> major problems with the code. The latest version is 4.2.32-1 which I >> have downloaded but am not *manly* enough to put on my ARCs yet. Am >> waiting to hear from others, first. 8-) > >Well I meant that in a completely gender neutral way. ;-) In the future I >will use "fearless guinea pigs." heh *snort* No offense taken. Just wanted to remind you all there there is a <gasp> woman out here! I prefer the term "lemming without a conscience". Thanks. 8-) >Yes, I meant 4.2.31. Looks like a few people have tried it and it looks >good *so far*. That's 4.2.32-1, though, right? In this version-confused world, just want to be sure I'm keeping track of things...*some* things, anyway. ********************************************************* Michelle M. Mogil N&CS, Network Operations Center Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************

Subject: (usr-tc) Ascend Pipeline 50
From: vanhalen@coredcs.com
Date: 1999-09-24 14:59:35

Hello- For whatever reason, unknown to me, I cannot get an Ascend Pipeline 50 to connect correctly via ISDN. I have other users connecting 100% fine to a Netserver based box running Quads. Most of those users are ISDN. When this user with the Ascend dials in, they never get a Start record in radius accounting. I can see them come across but it never starts and it immediately disconnects them. Anyone have any ideas on what I can change on the Pipeline to get them to work? Since I have everyone running fine on this box except the Ascend, I don't think I need to change anything on the box or at the very least I'm really reluctant to do so. Here are the versions anyway. NMC 5.5.0 Netserver ?? Quad 5.10.9

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-24 15:14:56

At 02:49 PM 9/24/99 -0400, you wrote: >*snort* No offense taken. Just wanted to remind you all there there is >a <gasp> woman out here! I prefer the term "lemming without a conscience". "lemming without a conscience"...I like that :) >That's 4.2.32-1, though, right? In this version-confused world, just >want to be sure I'm keeping track of things...*some* things, anyway. Been running 4.2.32-1 for 12 hours no, so far so good :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) SNMP challenge: ARC username from IP address
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-25 22:25:30

On Mon, 20 Sep 1999, Aaron Nabil wrote: > Uh, I'm assuming they want to do this SNMP rigamarole for some specific > reason, and I'm guessing that, like us, they simply save the IP->username > association in a database when the person logs in. If it were just a > matter of finding out what user corresponds to which IP address (or > vice-versa), it's just a couple SQL queries. The specific reason is "it's portable". It works on any platform regardless of Radius server or SQL server or even operating system (NT/Unix). This is for a set of tools I give away... and if I'm giving away code, it makes sense to have as little site specific code as possible. :) The code is pretty easy to replace with faster site-specific code if you want to. I could speed it up for my own use by having Cistron log to MySQL and do queries off of that, sure... I'm not currently doing that but it'd be easy for me to do. Telnet would also work and is more or less portable, but I'd rather not have the admin password for my ARCs in plaintext in a Perl script. Cistron Radius's built-in tracking of users currently online doesn't work if you are running two parallel Radius servers for redundancy. If Radius server 1 goes down and server 2 starts authenticating people for a few minutes, your database of who's online at the time is trashed. Even with just one running, it tends to drift out of sync with reality at times. I need something that's going to always work. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Jerry Wright <jwright@iaml.net>
Date: 1999-09-26 15:32:54

Todd Keister wrote: > 3. Use Open Transport, which is built in to System 8 OS > for the Mac. Open Transport (Mac RAS client) is also available as an > add on product for systems using System 7.x OS (that won't support > 8.x). This is really the best solution. Open Transport is a much more robust PPP solution than FreePPP... --Jerry

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-09-26 15:42:49

Das: This is a known issue. According to Network Engineers on our DSP team the issue is in the Free PPP code. Apparently the later versions of our Hiper Arc code have now exposed an issue that was latent in the Free PPP code all along. Since this issue is in the FreePPP Product, we can not directly resolve this issue. Currently I have been told there are no plans for a 3Com fix for this issue. The obvious work around is to have the Mac End Users use any other program than Free PPP. Hope this helps. Todd ;-} das <das@gol.com> on 09/23/99 01:06:12 AM Please respond to usr-tc@lists.xmission.com Sent by: das <das@gol.com> cc: (Todd Keister/MW/US/3Com) I'm having quite a few problems with macs connecting with FreePPP to my HARC running 4.1.59. It will never connect on the first try, but subsequent attempts seem to be OK. It is completely reproduceable and is happening on more than one card. I am willing to re-flash the card to older code, except the last time I did this the HARC lost it's configuration. (forgot it's IP Address) Being that the problem cards are in remote pops, I would rather try a fix for the current code first. Anyone have any ideas? Sorry if this has been answered before, I was mysteriously unsubscribed from this list and missed a lot of posts. das -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 The Highest Quality Service, Bar None ____________________________________________ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-09-26 16:15:48

Jeff: If I had known the specifics of this issue, I would have posted them. Resolving this type of issue at the code level is beyond me (I'm not a programer) and this goes double for Macintosh. I will try to get a more specific answer, but I thought that Das would like confirmation of this issue. I work in tech support, and sometimes just knowing that a weird issue is real can be comforting. If you have further questions, please email me directly at: todd_keister@mw.3com.com Todd ;-} Jeff Mcadams <jeffm@iglou.com> on 09/26/99 03:44:15 PM Please respond to usr-tc@lists.xmission.com Sent by: Jeff Mcadams <jeffm@iglou.com> cc: (Todd Keister/MW/US/3Com) Thus spake Todd Keister > This is a known issue. According to Network Engineers on our DSP team the >issue is in the Free PPP code. Apparently the later versions of our Hiper Arc >code have now exposed an issue that was latent in the Free PPP code all along. >Since this issue is in the FreePPP Product, we can not directly resolve this >issue. Currently I have been told there are no plans for a 3Com fix for this >issue. The obvious work around is to have the Mac End Users use any other >program than Free PPP. Come on 3Com folks...here's where you can make an improvement to your customer service. What is the bug in FreePPP? Giving specifics is a good thing. It gives you more credibility, and helps us help our customers better. :) Who knows...one of us intelligent people out here might be able to figure out a fix that you all hadn't thought of. :) (I get annoyed when companies think that everyone intelligent works for them :) -- 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.

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Todd Keister <todd_keister@mw.3com.com>
Date: 1999-09-26 16:25:55

Jeff: Here is some more specific information regarding the Free PPP issue. This information will soon be published on the 3Com Knowledgebase website (http://knowledgebase.3com.com). I hope this helps. Todd ;-} Solution ID: 1.0.33772876.2240281 Domain:3KB01 Partition: Unassigned Type: pending-Public Status:Standards review complete Shared: Yes Incident Count: 1 Owner: tkeister_mw Author: tkeister_mw Date Created:Tue Jul 20, 1999 1:08:26 PM Last Modified By: tcwikla_mw Date Modified: Thu Aug 5, 1999 5:49:27 PM Title: Total Control Chassis - Connectivity with Macintosh Clients using Free PPP Goal: Total Control Chassis - Connectivity with Macintosh Clients using Free PPP Fact: Apple Macintosh Fact: Mac has been rebooted recently Fact: System 7 Fact: Free PPP Fact: Free PPP 2.62 Fact: Total Control HiPer ARC Fact: Total Control HiPer DSP Fact: Total Control Quad Modem Fact: Total Control Chassis Fact: PPP Symptom: Call fails on First attempt Symptom: Subsequent calls connect Symptom: Connectivity with Macintosh Clients using Free PPP Cause: This is an issue that is known to exist, and stems from a timing issue that has been exposed by the HiPerARC since it builds a call so much faster than the NetServer does. Fix: There are several fixes: 1. In Free PPP dialog box - do NOT enter the Username and Password - do NOT select direct - choose "Connect Using a Log On Script" - then choose "Wait for - Login" next line send: user name - wait for password & send password: 2. Do not enter the Username and Password (force Mac to prompt for them) - Please Note: This fix has NOT been widely tested yet. 3. Use Open Transport, which is built in to System 8 OS for the Mac. Open Transport (Mac RAS client) is also available as an add on product for systems using System 7.x OS (that won't support 8.x). 4. Have End User downgrade to Free PPP 2.53 Fact: Search Group Total Control Remote Access Concentrator Fact: Last Reviewed July 1999 Comments Jeff Mcadams <jeffm@iglou.com> on 09/26/99 03:44:15 PM Please respond to usr-tc@lists.xmission.com Sent by: Jeff Mcadams <jeffm@iglou.com> cc: (Todd Keister/MW/US/3Com) Thus spake Todd Keister > This is a known issue. According to Network Engineers on our DSP team the >issue is in the Free PPP code. Apparently the later versions of our Hiper Arc >code have now exposed an issue that was latent in the Free PPP code all along. >Since this issue is in the FreePPP Product, we can not directly resolve this >issue. Currently I have been told there are no plans for a 3Com fix for this >issue. The obvious work around is to have the Mac End Users use any other >program than Free PPP. Come on 3Com folks...here's where you can make an improvement to your customer service. What is the bug in FreePPP? Giving specifics is a good thing. It gives you more credibility, and helps us help our customers better. :) Who knows...one of us intelligent people out here might be able to figure out a fix that you all hadn't thought of. :) (I get annoyed when companies think that everyone intelligent works for them :) -- 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.

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-26 16:44:15

Thus spake Todd Keister > This is a known issue. According to Network Engineers on our DSP team the >issue is in the Free PPP code. Apparently the later versions of our Hiper Arc >code have now exposed an issue that was latent in the Free PPP code all along. >Since this issue is in the FreePPP Product, we can not directly resolve this >issue. Currently I have been told there are no plans for a 3Com fix for this >issue. The obvious work around is to have the Mac End Users use any other >program than Free PPP. Come on 3Com folks...here's where you can make an improvement to your customer service. What is the bug in FreePPP? Giving specifics is a good thing. It gives you more credibility, and helps us help our customers better. :) Who knows...one of us intelligent people out here might be able to figure out a fix that you all hadn't thought of. :) (I get annoyed when companies think that everyone intelligent works for them :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-26 17:43:22

Thus spake Todd Keister > If I had known the specifics of this issue, I would have posted them. >Resolving this type of issue at the code level is beyond me (I'm not a >programer) and this goes double for Macintosh. I will try to get a more >specific answer, but I thought that Das would like confirmation of this issue. > I work in tech support, and sometimes just knowing that a weird issue is >real can be comforting. Oh...I can understand where you're coming from. :) And the notification that the problem was real, and known, is certainly a huge benefit. :) Just trying to help 3Com be even better. My comment really wasn't directed at you per se...just your post happened to be the latest occurance of this. :) My opinion is the you can't give me too much information. :) I'll filter out what I don't need. :) Just trying to encourage 3Com to give as much information as possible, whenever possible. 3Com has had a tendancy in the past to treat customers like mushrooms. :) Its amazing what people will put up with when they're given information about it. :) Thanks for checking into it and finding out more about what's going on with it. This might actually help me with a specific problem that I'm having with my uncle's computer. :) (MacOS 7.6 with FreePPP) I'll see what I can do next time I've over at his house and give you some feedback. :) (Too bad FreePPP's logging is pretty much non-existant) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Problems with macs and HiperARC 4.1.59
From: das <das@gol.com>
Date: 1999-09-27 10:09:55

Todd, Thank you. I did appreciate this information, even if, at first, it didn't give me all of the details. It did give me a place where I could start and something that I could tell my customers. (although they didn't like it ^_^) In Japan, Mac is still very popular, and for the foreign community, FreePPP is happier with Japanese modems than OT/PPP. (at least in my experience ^_^) Thanks also goes to Jeff for prompting for more information as that is _always_ needed and welcome. Does anyone know if the makers of FreePPP (can't remember the company right now) is responding to this in any way? das Todd Keister (Todd_Keister@mw.3com.com) spake: > > > > Jeff: > > > Here is some more specific information regarding the Free PPP issue. This > information will soon be published on the 3Com Knowledgebase website > (http://knowledgebase.3com.com). > > > I hope this helps. > > > Todd ;-} > > > <snip>

Subject: RE: (usr-tc) Ascend Pipeline 50
From: Jason Cropper <jason@clearsail.net>
Date: 1999-09-27 13:34:45

The reason you're not getting a "Start" in your RADIUS is simple. The Ascend is not accepting the IP assigned to it by the Netserver/ARC. Enable "NAT" in the Ascend. All should be well then. I've had that problem many times before. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of vanhalen@coredcs.com Sent: Friday, September 24, 1999 15:00 Hello- For whatever reason, unknown to me, I cannot get an Ascend Pipeline 50 to connect correctly via ISDN. I have other users connecting 100% fine to a Netserver based box running Quads. Most of those users are ISDN. When this user with the Ascend dials in, they never get a Start record in radius accounting. I can see them come across but it never starts and it immediately disconnects them. Anyone have any ideas on what I can change on the Pipeline to get them to work? Since I have everyone running fine on this box except the Ascend, I don't think I need to change anything on the box or at the very least I'm really reluctant to do so. Here are the versions anyway. NMC 5.5.0 Netserver ?? Quad 5.10.9 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) need iformation about hiper DSP card
From: liping@netsol.net
Date: 1999-09-27 16:06:10

Get the ISDN PRI instead of trunk T-1. Sorry, No Franch. Liping -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Simicro - RAKOTOBE Tatamo Sent: Wednesday, September 22, 1999 2:00 AM Hi, I'm a student from Madagascar and I'm doing now a training at an ISP. We want to give ISDN access to our Clients that why I contact you, we use now Total control with Quad Modem card and Edge Server card. Can you give me information related in ISDN, Hiper DSp card, Dual PRI card, their price, and other technical information. Thank you. PS: is it possible to send the answer in french because I'm francophone. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* tatamo@simicro.mg na koa trakotob@syfed.refer.mg hafa koa shiny_lotus@geocities.com MADAGASIKARA *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Failure to negociate V90
From: Gustavo Ruiz Zastrow <gustavo.zastrow@conexion.com.py>
Date: 1999-09-27 17:46:46

I have a similar problem with a user that have a Compaq 420 Microcom K56/V90 PCMCIA modem, and fails to connect to our TotalControl. How can I disable the V.90 and X2 features ? Gustavo Ruiz Ray Whelan wrote: > Hi Fred, > > I have a document which I will send you offline which will enable you to further > trouble shoot this problem > > Ray W > > "Fred Williams" <fwilliams@gtnet.gov.uk> on 01/04/99 14:29:38 > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Ray Whelan/IE/3Com) > Subject: (usr-tc) Failure to negociate V90 > > We have a user with a Compaq 420 Microcom K56/V90 PCMCIA > modem. He is failing to get a connection better than 31.2K when > dialiing into our TC Racks (mix of Quads and Netserver plus Hiper > DSP and ARC). He regularly gets a 41 to 44K connection into other > ISPs. He claims to have the latest V90 code on his modem. Can > anyone offer a solution please? > > **************************************************************** > * Fred Williams email fwilliams@gtnet.gov.uk * > * CCTA voice 01603 704706 * > * Rosebery Court GTN 3040 4706 * > * St Andrews Business Park fax 01603 704817 * > * NORWICH GTN fax 3040 4817 * > * NR7 0HS UK * > **************************************************************** > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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.

Subject: Re: (usr-tc) Failure to negociate V90
From: pferraro@wna-linknet.com
Date: 1999-09-27 18:05:24

Best thing to do would be to have the client go out and get the latest "SoftPak" upgrade from Compaq... We have had a number of new users with Compaqs (All series) that had problems, but the Softpak upgrade CURED 99% of them! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Mon, 27 Sep 1999, Gustavo Ruiz Zastrow wrote: > I have a similar problem with a user that have a Compaq 420 Microcom K56/V90 PCMCIA > modem, and fails to connect to our TotalControl. > How can I disable the V.90 and X2 features ? > Gustavo Ruiz > > Ray Whelan wrote: > > > Hi Fred, > > > > I have a document which I will send you offline which will enable you to further > > trouble shoot this problem > > > > Ray W > > > > "Fred Williams" <fwilliams@gtnet.gov.uk> on 01/04/99 14:29:38 > > > > Please respond to usr-tc@lists.xmission.com > > > > To: usr-tc@lists.xmission.com > > cc: (Ray Whelan/IE/3Com) > > Subject: (usr-tc) Failure to negociate V90 > > > > We have a user with a Compaq 420 Microcom K56/V90 PCMCIA > > modem. He is failing to get a connection better than 31.2K when > > dialiing into our TC Racks (mix of Quads and Netserver plus Hiper > > DSP and ARC). He regularly gets a 41 to 44K connection into other > > ISPs. He claims to have the latest V90 code on his modem. Can > > anyone offer a solution please? > > > > **************************************************************** > > * Fred Williams email fwilliams@gtnet.gov.uk * > > * CCTA voice 01603 704706 * > > * Rosebery Court GTN 3040 4706 * > > * St Andrews Business Park fax 01603 704817 * > > * NORWICH GTN fax 3040 4817 * > > * NR7 0HS UK * > > **************************************************************** > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: (usr-tc) Netserver FC3
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1999-09-28 08:34:58

Hi, you advised me to check for chip revision on my Netserver card about the crash problem. I had a chance to do it this morning, and guess what? It's a FC3.. Since it seems to be a known problem, will 3Com do something even without contract support (as far as you know) ? Thanks, Martin

Subject: (usr-tc) Web Ramps ?
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-28 09:08:00

We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the ability of older Web Ramps to connect. We are looking to go to a newer version of HiPerArc code. Does anyone know if this problem is fixed in the newer code ? I couldn't find it in the release notes. Also does anyone know if the intermittient loss of Radius accounting records is fixed either ? Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: Re: (usr-tc) Netserver FC3
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-28 09:11:13

Thus spake Martin Lathoud >you advised me to check for chip revision on my Netserver card about the >crash problem. I had a chance to do it this morning, and guess what? It's >a FC3.. Since it seems to be a known problem, will 3Com do something even >without contract support (as far as you know) ? They have claimed they are still doing hardware support for the NETServers (which, by law, I believe they have to ;). So, if your NETServer is still under warranty, you should be able to get a hardware fix/replacement. It won't be an advanced replacement, so you'll either be down a few lines, or need a spare you can put into service for a couple of weeks while yours goes back to 3Com and is replaced. FWIW, I've found 3Com to be quite quick about warranty repair/replacement...usually a small fraction of the time they tell you to allow. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Web Ramps ?
From: Sheldon Koehler <sheldon@tenforward.com>
Date: 1999-09-28 09:58:09

We have an issue with a couple of Webramps. We are using 4.1.46 and I was going to upgrade to 4.2.32 to see if it worked. Does anyone else have input on this? Sheldon ----- Original Message ----- Sent: Tuesday, September 28, 1999 7:08 AM > > > We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the > ability of older Web Ramps to connect. We are looking to go to a newer > version of HiPerArc code. Does anyone know if this problem is fixed in > the newer code ? I couldn't find it in the release notes. Also does > anyone know if the intermittient loss of Radius accounting records is > fixed either ? > > > Thanks, > > Jeff Binkley > ASA Network Computing > > CMPQwk 1.42 9999

Subject: (usr-tc) HiperDSPs to HiperArcs
From: Mike Wilker <mikew@ll.net>
Date: 1999-09-28 12:32:43

I keep hearing 7 DSPs per Arc. Is this a set maximum or a practical max if you are running lots of services? Can I run 8 DSPs on one Arc if I'm just doing basic dial-up with no tunneling and such? Mike Wilker Operations Manager Local Link, Inc.

Subject: RE: (usr-tc) Web Ramps ?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-28 13:32:33

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley |Sent: Tuesday, September 28, 1999 9:08 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Web Ramps ? | | | | |We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the |ability of older Web Ramps to connect. We are looking to go to a newer |version of HiPerArc code. Does anyone know if this problem is fixed in |the newer code ? I couldn't find it in the release notes. Also does |anyone know if the intermittient loss of Radius accounting records is |fixed either ? | 4.1.56? What were you given that for? Does 4.1.59-6 not work for you as well? There have been no specific WebRamp issues resolved. There have been fixes to PPP strict checking on HARC and some interaction changes involving the DSP card. These fixes are available in 4.2.32-1 and shortly in a new 4.1 service release. If you do not need OSPF, wait for the 4.1 service release or open a support ticket to get it as an ER. As for the RADIUS accouting record loss. A few items have been resolved that may casue this symptom. They are available in a 4.1.x ER now (if you open a ticket). 4.2.32-1, or you can wait for the service release. Opening a ticket would be the better option. Since different factors and configurations may result in the loss of the packet, until further inestigation is done, a fix for your problem cannot be guaranteed. -M

Subject: RE: (usr-tc) HiperDSPs to HiperArcs
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1999-09-28 13:37:42

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wilker |Sent: Tuesday, September 28, 1999 12:33 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) HiperDSPs to HiperArcs | | |I keep hearing 7 DSPs per Arc. Is this a set maximum or a practical max if |you are running lots of services? Can I run 8 DSPs on one Arc if I'm just |doing basic dial-up with no tunneling and such? | The 7DSP number came about from stress testing of HiperARC 4.0.x code. from that testing a performance fall off was seen after adding the 8th span of calls. (these calls are all doing PPP and FTP downloads. ). Since then the falloff has moved out and the severity of the fall off greatly reduced to a point of little impact for a full 14 spans. The FTP test is a little more severe than the stand mix of activities/data rates/packet sizes seen in normal operation. The 7 span recommendation is still in effect if IPX or l2tp is to be run over the PPP links. So the answer to your question is 8 DSPs will not be a problem. You should be running 4.1.59-6 or newer code on your HARC and DSP 2.0.81 or newer. -M

Subject: Re: (usr-tc) HiperDSPs to HiperArcs
From: Rick <rallan@monmouth.com>
Date: 1999-09-28 20:29:33

If you are running IP only then a single Arc can support upto 14 DSP's. IPX has a limitation of 7DSP's. Mike Wilker wrote: > I keep hearing 7 DSPs per Arc. Is this a set maximum or a practical max if > you are running lots of services? Can I run 8 DSPs on one Arc if I'm just > doing basic dial-up with no tunneling and such? > > Mike Wilker > Operations Manager > Local Link, Inc. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: (usr-tc) 3Com, Please Address This
From: Greg Coffey <greg@coffey.com>
Date: 1999-09-28 21:28:07

Enclosed is some dialogue with a customer of mine. ************ Bill, thanks for the feedback. Trib uses Ascend servers for their modems. We use 3Com (merged with USR) exclusively. We've noted that some subscribers that dial in using 3Com modems connect FASTER with the Ascend than the 3Com. In fact, they never connect >33.6 with the 3Com servers but consistently with the Ascends at a v.90 rate. I pointed out the problem to 3Com about a year ago and there was not much interest on their part at the time. A couple months ago, it came up again. This time there was more interest and discussion. 3Com tells me that there is a bug in the Ascend server software that permits this anomaly. The number of subscribers that this impacts is small (I believe), though I've not really spent much time regarding it. 3Com told me earlier that if they fixed the software, it would break other modems connect rates and even connectivity. One of my techs (lives in Mills) can connect to Trib from home under the same circumstances as you. I gave him a Courier v.everything to try last week with the latest firmware. Same results as his Sportster model. We are running current software on our end too. We just spent thousands to upgrade our quad modems to the newer hiper design, no change. We added a hiperarc, again newer design and, again, thousands more invested. No change. We did dump the Sportster modem registers and send them to a 3Com engineer both a year ago and more recently. I've not heard anything about it for about a month since the last time it came up. I've looked at Ascend equipment but so far have stayed with 3Com. Baffles me too why brand-x modems work better with brand-y's servers. Why brand-x can't or won't resolve the issue baffles me too. The 3Com servers are not junk. We do have lots of subscribers that can connect to our servers and getting v.90 connection rates. I think we've dealt with maybe 6 or so people that are in your situation. Perhaps the number is higher but they aren't aware of it. I don't have an answer for you at this point but will forward this to 3Com. At 08:15 PM 9/28/99 -0600, you wrote: >I signed up today and got onto your system. > >It is only a few hours, but so far I'm not impressed with the speed over >Trib.com. > >First of all, I cannot connect at as fast a speed. > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest >drivers and firmware. > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333. > >I tried your 3 numbers: > > 234-2088 26,400 most of the time, 28,800 sometimes. > 234-6324 same > 266-4165 31,200 all the time. > >I tried several file download tests between the two systems and trib won >handily. > >I will do some more comparing over the next few days, but it isn't what I >was hoping for. > >If you have any other ideas, I would love to hear them. > >Thanks, > >Bill xxxxx > >-----Original Message----- >From: Greg Coffey <gcoffey@vcn.com> >To: Bill >Date: Friday, September 10, 1999 8:45 AM >Subject: Re: > > >>We have 3 separate T1's to the Internet and are getting a fract T3 within >>two months. You are welcome to try us and compare for yourself. Sign up >>online or come by the store. If you don't like our service, I will refund >>your fee for the month. We are in the process of a major upgrade that >>takes place on September 20th. That will make us even better than we are >now. >> >> >>At 06:48 AM 9/10/99 -0600, you wrote: >>>I am in Casper - in the Sunrise 8 area. >>> >>>I am looking for bandwidth to the net overall. >>> >>>I can connect @ 37,333 to Trib and maintain connection. >>> >>>I can connect @ around 45,000, but the connection is not stable. Thanks, Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 ===================================================================== 100 N. Center St., Casper, WY 82601 WWW.VCN.COM

Subject: Re: (usr-tc) 3Com, Please Address This
From: Ed <ed@taylors.com>
Date: 1999-09-28 23:50:03

Greg Coffey wrote: "Perhaps the number is higher but they aren't aware of it. I don't have an answer for you at this point but will forward this to 3Com" My 2 Cents: It is higher. This is the same subject I raised about a month ago on this list. We have tested this and 3com is supposed to be working on a fix for it however it seems they have now pushed it to the back burners once again. They even developed a non-public alpha code to try to resolve it. No doubt in some circumstances Ascends work better. We have tested on the same PRI line hooked into the 3com and then moved it to the Ascend. The customers are able to get V.90 more often on the Ascends than on the 3com's. This even happens with 3com client modems. We screamed about this discovery and it seemed 3com was sincerely concerned but now I am not so certain it wasn't just to appease us. If I were 3com I would be a little more concerned with this... but thats me. I can say we won't wait forever for a fix. Other technologies are going to overtake V90 before they resolve it, it seems. Ed ----- Original Message ----- Sent: Tuesday, September 28, 1999 11:28 PM Enclosed is some dialogue with a customer of mine. ************ Bill, thanks for the feedback. Trib uses Ascend servers for their modems. We use 3Com (merged with USR) exclusively. We've noted that some subscribers that dial in using 3Com modems connect FASTER with the Ascend than the 3Com. In fact, they never connect >33.6 with the 3Com servers but consistently with the Ascends at a v.90 rate. I pointed out the problem to 3Com about a year ago and there was not much interest on their part at the time. A couple months ago, it came up again. This time there was more interest and discussion. 3Com tells me that there is a bug in the Ascend server software that permits this anomaly. The number of subscribers that this impacts is small (I believe), though I've not really spent much time regarding it. 3Com told me earlier that if they fixed the software, it would break other modems connect rates and even connectivity. One of my techs (lives in Mills) can connect to Trib from home under the same circumstances as you. I gave him a Courier v.everything to try last week with the latest firmware. Same results as his Sportster model. We are running current software on our end too. We just spent thousands to upgrade our quad modems to the newer hiper design, no change. We added a hiperarc, again newer design and, again, thousands more invested. No change. We did dump the Sportster modem registers and send them to a 3Com engineer both a year ago and more recently. I've not heard anything about it for about a month since the last time it came up. I've looked at Ascend equipment but so far have stayed with 3Com. Baffles me too why brand-x modems work better with brand-y's servers. Why brand-x can't or won't resolve the issue baffles me too. The 3Com servers are not junk. We do have lots of subscribers that can connect to our servers and getting v.90 connection rates. I think we've dealt with maybe 6 or so people that are in your situation. Perhaps the number is higher but they aren't aware of it. I don't have an answer for you at this point but will forward this to 3Com. At 08:15 PM 9/28/99 -0600, you wrote: >I signed up today and got onto your system. > >It is only a few hours, but so far I'm not impressed with the speed over >Trib.com. > >First of all, I cannot connect at as fast a speed. > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest >drivers and firmware. > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333. > >I tried your 3 numbers: > > 234-2088 26,400 most of the time, 28,800 sometimes. > 234-6324 same > 266-4165 31,200 all the time. > >I tried several file download tests between the two systems and trib won >handily. > >I will do some more comparing over the next few days, but it isn't what I >was hoping for. > >If you have any other ideas, I would love to hear them. > >Thanks, > >Bill xxxxx > >-----Original Message----- >From: Greg Coffey <gcoffey@vcn.com> >To: Bill >Date: Friday, September 10, 1999 8:45 AM >Subject: Re: > > >>We have 3 separate T1's to the Internet and are getting a fract T3 within >>two months. You are welcome to try us and compare for yourself. Sign up >>online or come by the store. If you don't like our service, I will refund >>your fee for the month. We are in the process of a major upgrade that >>takes place on September 20th. That will make us even better than we are >now. >> >> >>At 06:48 AM 9/10/99 -0600, you wrote: >>>I am in Casper - in the Sunrise 8 area. >>> >>>I am looking for bandwidth to the net overall. >>> >>>I can connect @ 37,333 to Trib and maintain connection. >>> >>>I can connect @ around 45,000, but the connection is not stable. Thanks, Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 ===================================================================== 100 N. Center St., Casper, WY 82601 WWW.VCN.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.

Subject: Re: (usr-tc) Netserver to ARC using MultilinkE
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-09-29 07:32:24

Need to know your dial out script on the NETServer - You can program the dial out number on the modem and foce it to dial immediately or you could have the number of session set to 2 (max ports) - I am not sure but one of the above method does negotiate multilink and the other does not - guess it changes the mpedo. krish On Wed, 29 Sep 1999, Carl Litt wrote: > > Yes, I did clip out a bit of info... here's the complete output: > > Monitoring the next session to start up. > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > ....Tracing the current/next session; Escape to stop... > > Outgoing PPP Data on interface: slot:10/mod:12 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > MAGIC_NUM 9e 5a aa e5 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:10/mod:12 > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 > ASYNC_MAP 00 00 00 00 > MAGIC_NUM eb c4 d4 f4 > > Outgoing PPP Data on interface: slot:10/mod:12 > LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 > ASYNC_MAP 00 00 00 00 > MAGIC_NUM eb c4 d4 f4 > > > Incoming PPP Data on interface: slot:10/mod:12 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > MAGIC_NUM 9e 5a aa e5 > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > I've also tried durning off PPP offloading for the hell of it, but > no difference. > > Thanks, > Carl > > On Wed, 29 Sep 1999, Jeff Mcadams wrote: > > > Thus spake Carl Litt > > >Is it possible to get a Netserver to connect to a HiPer ARC > > >with more than one channel (by using multilink)? > > > > >We're trying to move a customer over from dialing into another > > >Netserver (not ours) into an ARC running 4.1.59. The login is set > > >in RADIUS, and does work for a single channel. We have no > > >Port-Limits set, and the ARC has the default 2 Max-Chan. > > > > >We can get the first channel up, but the second channel connects > > >then drops. Here is the "mon ppp" output: > > > > >Incoming PPP Data on interface: slot:10/mod:23 > > > LCP CFG_ACK MRU 05 ea > > > ASYNC_MAP ff ff ff ff > > > MAGIC_NUM 4c 56 1b da > > > PROTO_COMP > > > AC_COMP > > > MPP_MRRU 05 ea > > > MPP_ENDPTID 00 > > > > >Incoming PPP Data on interface: slot:10/mod:23 > > > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 > > > ASYNC_MAP ff ff ff ff > > > MAGIC_NUM 23 ea 32 19 > > > > >Outgoing PPP Data on interface: slot:10/mod:23 > > > LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 > > > ASYNC_MAP ff ff ff ff > > > MAGIC_NUM 23 ea 32 19 > > >--- [The call is then dropped] --- > > > > >From what I can see, there are no NAK's which should cause a > > >protocol termination. In the RADIUS accounting logs, the session > > >has a Term-Cause of NAS-Error. > > > > Well...you're apparently not catching all of the PPP negotiation...which > > means we might be missing some useful data, but... > > > > You'll notice that the incoming config request does *not* have the MPP_MRRU > > attribute in it. The MPP_MRRU attribute is the attribute/value that > > indicates that Multi-Link can/will be used on that link. If one side > > doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that > > link. > > -- > > 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. >

Subject: Re: (usr-tc) 3Com, Please Address This
From: Brian Gordon <brian@westelcom.com>
Date: 1999-09-29 08:00:12

This is not consistent with my finding at all. I have a courier and get 49,300 every time flawlessly to my total control dsp equip. Looks like a telco issue if you ask me. Just my two sense. Brian Gordon MCP, A+, Network + Network Administrator Westelcom Internet 518.566.6726 Voice 419.831.9137 Fax http://www.westelcom.com administrator@westelcom.com ----- Original Message ----- Sent: Tuesday, September 28, 1999 11:28 PM > Enclosed is some dialogue with a customer of mine. > > ************ > Bill, thanks for the feedback. Trib uses Ascend servers for their modems. > We use 3Com (merged with USR) exclusively. We've noted that some > subscribers that dial in using 3Com modems connect FASTER with the Ascend > than the 3Com. In fact, they never connect >33.6 with the 3Com servers but > consistently with the Ascends at a v.90 rate. I pointed out the problem to > 3Com about a year ago and there was not much interest on their part at the > time. A couple months ago, it came up again. This time there was more > interest and discussion. 3Com tells me that there is a bug in the Ascend > server software that permits this anomaly. The number of subscribers that > this impacts is small (I believe), though I've not really spent much time > regarding it. 3Com told me earlier that if they fixed the software, it > would break other modems connect rates and even connectivity. One of my > techs (lives in Mills) can connect to Trib from home under the same > circumstances as you. I gave him a Courier v.everything to try last week > with the latest firmware. Same results as his Sportster model. We are > running current software on our end too. We just spent thousands to > upgrade our quad modems to the newer hiper design, no change. We added a > hiperarc, again newer design and, again, thousands more invested. No > change. We did dump the Sportster modem registers and send them to a 3Com > engineer both a year ago and more recently. I've not heard anything about > it for about a month since the last time it came up. I've looked at Ascend > equipment but so far have stayed with 3Com. Baffles me too why brand-x > modems work better with brand-y's servers. Why brand-x can't or won't > resolve the issue baffles me too. The 3Com servers are not junk. We do > have lots of subscribers that can connect to our servers and getting v.90 > connection rates. I think we've dealt with maybe 6 or so people that are > in your situation. Perhaps the number is higher but they aren't aware of > it. I don't have an answer for you at this point but will forward this to > 3Com. > > At 08:15 PM 9/28/99 -0600, you wrote: > >I signed up today and got onto your system. > > > >It is only a few hours, but so far I'm not impressed with the speed over > >Trib.com. > > > >First of all, I cannot connect at as fast a speed. > > > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest > >drivers and firmware. > > > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333. > > > >I tried your 3 numbers: > > > > 234-2088 26,400 most of the time, 28,800 sometimes. > > 234-6324 same > > 266-4165 31,200 all the time. > > > >I tried several file download tests between the two systems and trib won > >handily. > > > >I will do some more comparing over the next few days, but it isn't what I > >was hoping for. > > > >If you have any other ideas, I would love to hear them. > > > >Thanks, > > > >Bill xxxxx > > > >-----Original Message----- > >From: Greg Coffey <gcoffey@vcn.com> > >To: Bill > >Date: Friday, September 10, 1999 8:45 AM > >Subject: Re: > > > > > >>We have 3 separate T1's to the Internet and are getting a fract T3 within > >>two months. You are welcome to try us and compare for yourself. Sign up > >>online or come by the store. If you don't like our service, I will refund > >>your fee for the month. We are in the process of a major upgrade that > >>takes place on September 20th. That will make us even better than we are > >now. > >> > >> > >>At 06:48 AM 9/10/99 -0600, you wrote: > >>>I am in Casper - in the Sunrise 8 area. > >>> > >>>I am looking for bandwidth to the net overall. > >>> > >>>I can connect @ 37,333 to Trib and maintain connection. > >>> > >>>I can connect @ around 45,000, but the connection is not stable. > > > Thanks, > > Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 > ===================================================================== > 100 N. Center St., Casper, WY 82601 WWW.VCN.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. >

Subject: RE: (usr-tc) Web Ramps ?
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-29 08:24:00

u>|-----Original Message----- u>|From: owner-usr-tc@lists.xmission.com u>|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley u>|Sent: Tuesday, September 28, 1999 9:08 AM u>|To: usr-tc@lists.xmission.com u>|Subject: (usr-tc) Web Ramps ? u>| u>| u>| u>| u>|We are still running HiPerArc code 4.1.64 due to 4.1.56 breaking the u>|ability of older Web Ramps to connect. We are looking to go to a u>newer |version of HiPerArc code. Does anyone know if this problem is u>fixed in |the newer code ? I couldn't find it in the release notes. u>Also does |anyone know if the intermittient loss of Radius accounting u>records is |fixed either ? u>| u>4.1.56? What were you given that for? Does 4.1.59-6 not work for you u>as well? u>There have been no specific WebRamp issues resolved. There have been u>fixes to PPP u>strict checking on HARC and some interaction changes involving the DSP u>card. These fixes are available in 4.2.32-1 and shortly in a new 4.1 u>service release. u>If you do not need OSPF, wait for the 4.1 service release or open a u>support ticket to get it as an ER. u>As for the RADIUS accouting record loss. A few items have been u>resolved that may u>casue this symptom. They are available in a 4.1.x ER now (if you open u>a ticket). u>4.2.32-1, or you can wait for the service release. Opening a ticket u>would be the u>better option. Since different factors and configurations may result u>in the loss u>of the packet, until further inestigation is done, a fix for your u>problem cannot u>be guaranteed. Mike, That was a typo on my part. We are running 4.1.64 instead of 4.1.59-6 because, as I understand it, you folks put a fix in 4.1.59-6 in the HiPerArc code to fix the timing problem you were having with the DSP code. When this happened, it broke the ability for certain Web Ramps to connect. Going back to 4.1.64 was the only solution. Krish was aware of this. So I am not sure, based upon your comments, whether web ramps will work again or not with the 4.2.32-1 code. As for the accounting record loss, this has been a problem for some time now. I don't know exactly what code release introduced the problem but I know we cannot turn on concurrency checking on the S/A software because after a few hours we will start getting calls about folks not being able to connect. Checking the S/A users table will show a connection but looking in the HiPerArc they aren't connected. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: (usr-tc) Ascend Pipelines
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1999-09-29 08:24:00

We have 3 Ascend Pipeline 50/75 customers connecting to our TC chassis'. In each case we give them a static IP address via Radius. In all cases we cannot ping the static address (i.e. Ascend doesn't respond) yet the users behind the pipeline work fine adn we can telnet into the Ascend if we add a static route for port 23 to the static IP address. Does anyone know how to correct this ? It makes troubleshooting more difficult when ping doesn't work. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: Re: (usr-tc) 3Com, Please Address This
From: Kevin Benton <s1kevin@tims.net>
Date: 1999-09-29 08:26:35

On Tue, 28 Sep 1999, Ed wrote: > Greg Coffey wrote: > "Perhaps the number is higher but they aren't aware of it. I don't have an > answer for you at this point but will forward this to 3Com" > > My 2 Cents: > It is higher. This is the same subject I raised about a month ago on this > list. We have tested this and 3com is supposed to be working on a fix for it > however it seems they have now pushed it to the back burners once again. > They even developed a non-public alpha code to try to resolve it. yadda yadda yadda... Rest deleted. Do you guys have cases open with 3Com about this? I would be happy to help push this issue as another 3Com customer with my NC, however, there's little I can do to help if I don't have something I can give him... I'm not interested in working on your case for you but I do want our equipment to be able to handle calls as well or better than Ascend product. Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) 3Com, Please Address This
From: Greg Coffey <greg@coffey.com>
Date: 1999-09-29 08:50:59

There are some rare instances where the customer calling in using the SAME computer, software, modem and phone line can connect to Ascend boxes at v.90 and not to 3Coms. In ALL instances that I have seen, the client was using a 3Com modem to dial. At 08:00 AM 9/29/99 -0400, you wrote: >This is not consistent with my finding at all. I have a courier and get >49,300 every time flawlessly to my total control dsp equip. Looks like a >telco issue if you ask me. > >Just my two sense. > >------------------------------------ >Brian Gordon >MCP, A+, Network + >Network Administrator >Westelcom Internet >518.566.6726 Voice >419.831.9137 Fax >http://www.westelcom.com >administrator@westelcom.com >----- Original Message ----- >From: Greg Coffey <greg@coffey.com> >To: <usr-tc@lists.xmission.com> >Sent: Tuesday, September 28, 1999 11:28 PM >Subject: (usr-tc) 3Com, Please Address This > > > > Enclosed is some dialogue with a customer of mine. > > > > ************ > > Bill, thanks for the feedback. Trib uses Ascend servers for their modems. > > We use 3Com (merged with USR) exclusively. We've noted that some > > subscribers that dial in using 3Com modems connect FASTER with the Ascend > > than the 3Com. In fact, they never connect >33.6 with the 3Com servers >but > > consistently with the Ascends at a v.90 rate. I pointed out the problem >to > > 3Com about a year ago and there was not much interest on their part at the > > time. A couple months ago, it came up again. This time there was more > > interest and discussion. 3Com tells me that there is a bug in the Ascend > > server software that permits this anomaly. The number of subscribers that > > this impacts is small (I believe), though I've not really spent much time Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center, Casper, WY 82601 www.vcn.com

Subject: (usr-tc) MRTG & Quads & Analog
From: David Swearingin <david@carolnet.com>
Date: 1999-09-29 08:53:10

Can anyone tell me the MRTG target to use for tracking modem usage on Quad modem cards connected to analog lines? Thanks. David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Subject: Re: (usr-tc) 3Com, Please Address This
From: Greg Coffey <greg@coffey.com>
Date: 1999-09-29 09:06:18

It tis not a phone line issue. 3Com has admitted there is an issue here and is aware of what the cause is. I get a message a month regarding this topic from customers. When it comes up, the subscribers are usually on the fringe of the 56k area. My biggest competitor runs Ascends and when they call it, they get a FortySomething connect just about every time. It is a true connect too, we've tested the throughput. They have NEVER obtained a v.90 connect through us at the same location using the same PC, modem and phone line. We currently have 12 CT1 spans running in Casper. Some are on quads with netservers and others are hiperarcs with hiperdsps. We get lots of v90 connects on all the chassis. At 09:41 AM 9/29/99 -0400, you wrote: >Phone lines! > >If you have customers going through SLC or line multiplexors, or long runs >or old switches or any other of number of line impairments they will not >get the 52K they *THINK* they are paying for. > >If you go from QUADS to ARC's and still have the same poor perf then it's >most likely lines. > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >On Tue, 28 Sep 1999, Greg Coffey wrote: > > > Enclosed is some dialogue with a customer of mine. > > > > ************ > > Bill, thanks for the feedback. Trib uses Ascend servers for their modems. > > We use 3Com (merged with USR) exclusively. We've noted that some > > subscribers that dial in using 3Com modems connect FASTER with the Ascend > > than the 3Com. In fact, they never connect >33.6 with the 3Com servers but > > consistently with the Ascends at a v.90 rate. I pointed out the problem to > > 3Com about a year ago and there was not much interest on their part at the > > time. A couple months ago, it came up again. This time there was more > > interest and discussion. 3Com tells me that there is a bug in the Ascend > > server software that permits this anomaly. The number of subscribers that > > this impacts is small (I believe), though I've not really spent much time > > regarding it. 3Com told me earlier that if they fixed the software, it > > would break other modems connect rates and even connectivity. One of my > > techs (lives in Mills) can connect to Trib from home under the same > > circumstances as you. I gave him a Courier v.everything to try last week > > with the latest firmware. Same results as his Sportster model. We are > > running current software on our end too. We just spent thousands to > > upgrade our quad modems to the newer hiper design, no change. We added a > > hiperarc, again newer design and, again, thousands more invested. No > > change. We did dump the Sportster modem registers and send them to a 3Com > > engineer both a year ago and more recently. I've not heard anything about > > it for about a month since the last time it came up. I've looked at Ascend > > equipment but so far have stayed with 3Com. Baffles me too why brand-x > > modems work better with brand-y's servers. Why brand-x can't or won't > > resolve the issue baffles me too. The 3Com servers are not junk. We do > > have lots of subscribers that can connect to our servers and getting v.90 > > connection rates. I think we've dealt with maybe 6 or so people that are > > in your situation. Perhaps the number is higher but they aren't aware of > > it. I don't have an answer for you at this point but will forward this to > > 3Com. > > > > At 08:15 PM 9/28/99 -0600, you wrote: > > >I signed up today and got onto your system. > > > > > >It is only a few hours, but so far I'm not impressed with the speed over > > >Trib.com. > > > > > >First of all, I cannot connect at as fast a speed. > > > > > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest > > >drivers and firmware. > > > > > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333. > > > > > >I tried your 3 numbers: > > > > > > 234-2088 26,400 most of the time, 28,800 sometimes. > > > 234-6324 same > > > 266-4165 31,200 all the time. > > > > > >I tried several file download tests between the two systems and trib won > > >handily. > > > > > >I will do some more comparing over the next few days, but it isn't what I > > >was hoping for. > > > > > >If you have any other ideas, I would love to hear them. > > > > > >Thanks, > > > > > >Bill xxxxx > > > > > >-----Original Message----- > > >From: Greg Coffey <gcoffey@vcn.com> > > >To: Bill > > >Date: Friday, September 10, 1999 8:45 AM > > >Subject: Re: > > > > > > > > >>We have 3 separate T1's to the Internet and are getting a fract T3 within > > >>two months. You are welcome to try us and compare for yourself. Sign up > > >>online or come by the store. If you don't like our service, I will > refund > > >>your fee for the month. We are in the process of a major upgrade that > > >>takes place on September 20th. That will make us even better than we are > > >now. > > >> > > >> > > >>At 06:48 AM 9/10/99 -0600, you wrote: > > >>>I am in Casper - in the Sunrise 8 area. > > >>> > > >>>I am looking for bandwidth to the net overall. > > >>> > > >>>I can connect @ 37,333 to Trib and maintain connection. > > >>> > > >>>I can connect @ around 45,000, but the connection is not stable. > > > > > > Thanks, > > > > Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 > > ===================================================================== > > 100 N. Center St., Casper, WY 82601 WWW.VCN.COM > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) 3Com, Please Address This
From: farber@admin.f-tech.net
Date: 1999-09-29 09:41:56

Phone lines! If you have customers going through SLC or line multiplexors, or long runs or old switches or any other of number of line impairments they will not get the 52K they *THINK* they are paying for. If you go from QUADS to ARC's and still have the same poor perf then it's most likely lines. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 28 Sep 1999, Greg Coffey wrote: > Enclosed is some dialogue with a customer of mine. > > ************ > Bill, thanks for the feedback. Trib uses Ascend servers for their modems. > We use 3Com (merged with USR) exclusively. We've noted that some > subscribers that dial in using 3Com modems connect FASTER with the Ascend > than the 3Com. In fact, they never connect >33.6 with the 3Com servers but > consistently with the Ascends at a v.90 rate. I pointed out the problem to > 3Com about a year ago and there was not much interest on their part at the > time. A couple months ago, it came up again. This time there was more > interest and discussion. 3Com tells me that there is a bug in the Ascend > server software that permits this anomaly. The number of subscribers that > this impacts is small (I believe), though I've not really spent much time > regarding it. 3Com told me earlier that if they fixed the software, it > would break other modems connect rates and even connectivity. One of my > techs (lives in Mills) can connect to Trib from home under the same > circumstances as you. I gave him a Courier v.everything to try last week > with the latest firmware. Same results as his Sportster model. We are > running current software on our end too. We just spent thousands to > upgrade our quad modems to the newer hiper design, no change. We added a > hiperarc, again newer design and, again, thousands more invested. No > change. We did dump the Sportster modem registers and send them to a 3Com > engineer both a year ago and more recently. I've not heard anything about > it for about a month since the last time it came up. I've looked at Ascend > equipment but so far have stayed with 3Com. Baffles me too why brand-x > modems work better with brand-y's servers. Why brand-x can't or won't > resolve the issue baffles me too. The 3Com servers are not junk. We do > have lots of subscribers that can connect to our servers and getting v.90 > connection rates. I think we've dealt with maybe 6 or so people that are > in your situation. Perhaps the number is higher but they aren't aware of > it. I don't have an answer for you at this point but will forward this to > 3Com. > > At 08:15 PM 9/28/99 -0600, you wrote: > >I signed up today and got onto your system. > > > >It is only a few hours, but so far I'm not impressed with the speed over > >Trib.com. > > > >First of all, I cannot connect at as fast a speed. > > > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest > >drivers and firmware. > > > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333. > > > >I tried your 3 numbers: > > > > 234-2088 26,400 most of the time, 28,800 sometimes. > > 234-6324 same > > 266-4165 31,200 all the time. > > > >I tried several file download tests between the two systems and trib won > >handily. > > > >I will do some more comparing over the next few days, but it isn't what I > >was hoping for. > > > >If you have any other ideas, I would love to hear them. > > > >Thanks, > > > >Bill xxxxx > > > >-----Original Message----- > >From: Greg Coffey <gcoffey@vcn.com> > >To: Bill > >Date: Friday, September 10, 1999 8:45 AM > >Subject: Re: > > > > > >>We have 3 separate T1's to the Internet and are getting a fract T3 within > >>two months. You are welcome to try us and compare for yourself. Sign up > >>online or come by the store. If you don't like our service, I will refund > >>your fee for the month. We are in the process of a major upgrade that > >>takes place on September 20th. That will make us even better than we are > >now. > >> > >> > >>At 06:48 AM 9/10/99 -0600, you wrote: > >>>I am in Casper - in the Sunrise 8 area. > >>> > >>>I am looking for bandwidth to the net overall. > >>> > >>>I can connect @ 37,333 to Trib and maintain connection. > >>> > >>>I can connect @ around 45,000, but the connection is not stable. > > > Thanks, > > Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 > ===================================================================== > 100 N. Center St., Casper, WY 82601 WWW.VCN.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. >

Subject: Re: (usr-tc) 3Com, Please Address This
From: Ed <ed@taylors.com>
Date: 1999-09-29 10:45:21

Paul Farber worte: "If you have customers going through SLC or line multiplexors, or long runs or old switches or any other of number of line impairments they will not get the 52K they *THINK* they are paying for." Response: No as stated before we know without a doubt in these scenarios it is NOT Phone Lines. Please read the letters completely before responding and confusing others. As stated before we have used the same PRI line and switched it between the Ascend box and the 3com box. Used the same client location and modem. The client is using a 3com modem and has the latest code revisions and drivers. When they connect to the Ascend they get V90 and when they connect to the 3com no V90. It's that simple... Again 3com has acknowledged the issue. Ed ----- Original Message ----- Sent: Wednesday, September 29, 1999 9:41 AM Phone lines! If you have customers going through SLC or line multiplexors, or long runs or old switches or any other of number of line impairments they will not get the 52K they *THINK* they are paying for. If you go from QUADS to ARC's and still have the same poor perf then it's most likely lines. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 28 Sep 1999, Greg Coffey wrote: > Enclosed is some dialogue with a customer of mine. > > ************ > Bill, thanks for the feedback. Trib uses Ascend servers for their modems. > We use 3Com (merged with USR) exclusively. We've noted that some > subscribers that dial in using 3Com modems connect FASTER with the Ascend > than the 3Com. In fact, they never connect >33.6 with the 3Com servers but > consistently with the Ascends at a v.90 rate. I pointed out the problem to > 3Com about a year ago and there was not much interest on their part at the > time. A couple months ago, it came up again. This time there was more > interest and discussion. 3Com tells me that there is a bug in the Ascend > server software that permits this anomaly. The number of subscribers that > this impacts is small (I believe), though I've not really spent much time > regarding it. 3Com told me earlier that if they fixed the software, it > would break other modems connect rates and even connectivity. One of my > techs (lives in Mills) can connect to Trib from home under the same > circumstances as you. I gave him a Courier v.everything to try last week > with the latest firmware. Same results as his Sportster model. We are > running current software on our end too. We just spent thousands to > upgrade our quad modems to the newer hiper design, no change. We added a > hiperarc, again newer design and, again, thousands more invested. No > change. We did dump the Sportster modem registers and send them to a 3Com > engineer both a year ago and more recently. I've not heard anything about > it for about a month since the last time it came up. I've looked at Ascend > equipment but so far have stayed with 3Com. Baffles me too why brand-x > modems work better with brand-y's servers. Why brand-x can't or won't > resolve the issue baffles me too. The 3Com servers are not junk. We do > have lots of subscribers that can connect to our servers and getting v.90 > connection rates. I think we've dealt with maybe 6 or so people that are > in your situation. Perhaps the number is higher but they aren't aware of > it. I don't have an answer for you at this point but will forward this to > 3Com. > > At 08:15 PM 9/28/99 -0600, you wrote: > >I signed up today and got onto your system. > > > >It is only a few hours, but so far I'm not impressed with the speed over > >Trib.com. > > > >First of all, I cannot connect at as fast a speed. > > > >I have a USR Sportster Voice 56k v.90 modem model 00178501 with the latest > >drivers and firmware. > > > >With trib.com, I can connect sometimes @ 45,333 and always @ 37,333. > > > >I tried your 3 numbers: > > > > 234-2088 26,400 most of the time, 28,800 sometimes. > > 234-6324 same > > 266-4165 31,200 all the time. > > > >I tried several file download tests between the two systems and trib won > >handily. > > > >I will do some more comparing over the next few days, but it isn't what I > >was hoping for. > > > >If you have any other ideas, I would love to hear them. > > > >Thanks, > > > >Bill xxxxx > > > >-----Original Message----- > >From: Greg Coffey <gcoffey@vcn.com> > >To: Bill > >Date: Friday, September 10, 1999 8:45 AM > >Subject: Re: > > > > > >>We have 3 separate T1's to the Internet and are getting a fract T3 within > >>two months. You are welcome to try us and compare for yourself. Sign up > >>online or come by the store. If you don't like our service, I will refund > >>your fee for the month. We are in the process of a major upgrade that > >>takes place on September 20th. That will make us even better than we are > >now. > >> > >> > >>At 06:48 AM 9/10/99 -0600, you wrote: > >>>I am in Casper - in the Sunrise 8 area. > >>> > >>>I am looking for bandwidth to the net overall. > >>> > >>>I can connect @ 37,333 to Trib and maintain connection. > >>> > >>>I can connect @ around 45,000, but the connection is not stable. > > > Thanks, > > Greg Coffey, Visionary Communications V 307-234-5443 F 307-234-5446 > ===================================================================== > 100 N. Center St., Casper, WY 82601 WWW.VCN.COM > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) HiPER Dsp Vs Quad Modem
From: Paul Oster <devious@minot.com>
Date: 1999-09-29 11:36:01

This is a multi-part message in MIME format. ------=_NextPart_000_0145_01BF0A6E.CE74BAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ok, I've brought this up with 3com tech support, and they have not been able to answer my questions... I run approximately 8-10% Lost-Carrier Rates on my Quad Modem based chassis. On my DSP based chassis, that number is 15-17%. I can attribute 1 in 10 calls dropping to flakey phone lines, poor client modems etc, but beyond that, I have to question what is going on. I have tested to eliminate T1's from the equation by switching the 2 spans that plugged into the Quad-Chassis with the 2 from the DSP-Chassis, and the results are exactly the same (24 hour test period in both cases) Now I've got 7 dsp cards in service (2 chassis split 5/2) and both chassis show the 15+% loss. Any suggestions as to why these dsp modems are more prone to dropping connections? DSP Code 2.0.81 ARC Code 4.1.59-6 NMC 6.2.17 Thanks Paul ------=_NextPart_000_0145_01BF0A6E.CE74BAA0 Content-Type: text/x-vcard; name="Paul M Oster.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Paul M Oster.vcf" BEGIN:VCARD VERSION:2.1 N:Oster;Paul;M;Mr FN:Paul M Oster ORG:Magic Internet Services TITLE:IT Manager TEL;WORK;VOICE:701-838-1265 TEL;WORK;FAX:701-852-4374 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;400 10th St = SE=3D0D=3D0A;Minot;ND;58701;USA LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:400 10th St = SE=3D0D=3D0A=3D0D=3D0AMinot, ND 58701=3D0D=3D0AUSA EMAIL;PREF;INTERNET:admin@minot.com REV:19990929T163601Z END:VCARD ------=_NextPart_000_0145_01BF0A6E.CE74BAA0--

Subject: RE: (usr-tc) Ascend Pipelines
From: Jason Cropper <jason@clearsail.net>
Date: 1999-09-29 11:40:30

You must disable the "firewall" in the Ascend. It is turned on by default. I'm not sure of the procedure though... it's been a while. Jason -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley Sent: Wednesday, September 29, 1999 8:24 We have 3 Ascend Pipeline 50/75 customers connecting to our TC chassis'. In each case we give them a static IP address via Radius. In all cases we cannot ping the static address (i.e. Ascend doesn't respond) yet the users behind the pipeline work fine adn we can telnet into the Ascend if we add a static route for port 23 to the static IP address. Does anyone know how to correct this ? It makes troubleshooting more difficult when ping doesn't work. Thanks, Jeff Binkley ASA Network Computing CMPQwk 1.42 9999 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 3Com, Please Address This
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1999-09-29 12:03:06

> It tis not a phone line issue. 3Com has admitted there is an issue here > and is aware of what the cause is. I get a message a month regarding this > topic from customers. When it comes up, the subscribers are usually on the > fringe of the 56k area. My biggest competitor runs Ascends and when they > call it, they get a FortySomething connect just about every time. It is a > true connect too, we've tested the throughput. They have NEVER obtained a > v.90 connect through us at the same location using the same PC, modem and > phone line. We currently have 12 CT1 spans running in Casper. Some are on > quads with netservers and others are hiperarcs with hiperdsps. We get lots > of v90 connects on all the chassis. It's a phone line issue not properly addressed by 3Com modem code. I deleted the mail where John Powell explained what exactly was wrong with the line, but he said (a year ago?) that a fix was worked on.. I don't know about Ascend, but PM3 modem code is way worse than 3Com, so stick with it and be patient :-) It seems that Cisco modem code is much better at this, too. Martin

Subject: Re: (usr-tc) HiPER Dsp Vs Quad Modem
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-29 12:52:25

At 11:36 AM 9/29/99 -0500, "Paul Oster" <devious@minot.com> wrote: > >DSP Code 2.0.81 >ARC Code 4.1.59-6 >NMC 6.2.17 Try bumping the ARC code up to 4.2.32, with that and 2.0.81 I'm seeing 8-10% failure rates. This has actually gone up from about 5% when I was running ARC 4.1.59-6/DSP 1.2.60. I'm hoping the next DSP upgrade gets the rate back down some. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) Netserver to ARC using Multilink
From: Carl Litt <carl@execulink.com>
Date: 1999-09-29 13:04:51

Is it possible to get a Netserver to connect to a HiPer ARC with more than one channel (by using multilink)? We're trying to move a customer over from dialing into another Netserver (not ours) into an ARC running 4.1.59. The login is set in RADIUS, and does work for a single channel. We have no Port-Limits set, and the ARC has the default 2 Max-Chan. We can get the first channel up, but the second channel connects then drops. Here is the "mon ppp" output: Incoming PPP Data on interface: slot:10/mod:23 LCP CFG_ACK MRU 05 ea ASYNC_MAP ff ff ff ff MAGIC_NUM 4c 56 1b da PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:10/mod:23 LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP ff ff ff ff MAGIC_NUM 23 ea 32 19 Outgoing PPP Data on interface: slot:10/mod:23 LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP ff ff ff ff MAGIC_NUM 23 ea 32 19 --- [The call is then dropped] --- From what I can see, there are no NAK's which should cause a protocol termination. In the RADIUS accounting logs, the session has a Term-Cause of NAS-Error. Any advice? Thanks, Carl

Subject: (usr-tc) Intermittent static on lines...
From: Christopher Arlis Hanes <chanes@usacars.com>
Date: 1999-09-29 13:13:48

I'm having a problem with static coming and going on my PRIs. The effect then is that users are unable to temporarily dial in - the modems aren't able to negotiate a connection. I'm fairly certain the interference is being produced on the utp cat 5 cable running about 25 feet on a ladder rack from the demarc point to my boxes. I'm planning on installing shielded cable immediately but was wondering if anyone has run into similar problems and has some advice? What is the best way to measure the noise on the line? I noticed under Performance Monitor on modems you can get s/n ratio info for each connection. What are acceptable levels? Thanks, Chris Hanes

Subject: Re: (usr-tc) Netserver to ARC using Multilink
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-29 13:14:17

Thus spake Carl Litt >Is it possible to get a Netserver to connect to a HiPer ARC >with more than one channel (by using multilink)? >We're trying to move a customer over from dialing into another >Netserver (not ours) into an ARC running 4.1.59. The login is set >in RADIUS, and does work for a single channel. We have no >Port-Limits set, and the ARC has the default 2 Max-Chan. >We can get the first channel up, but the second channel connects >then drops. Here is the "mon ppp" output: >Incoming PPP Data on interface: slot:10/mod:23 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP ff ff ff ff > MAGIC_NUM 4c 56 1b da > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 >Incoming PPP Data on interface: slot:10/mod:23 > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 > ASYNC_MAP ff ff ff ff > MAGIC_NUM 23 ea 32 19 >Outgoing PPP Data on interface: slot:10/mod:23 > LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 > ASYNC_MAP ff ff ff ff > MAGIC_NUM 23 ea 32 19 >--- [The call is then dropped] --- >From what I can see, there are no NAK's which should cause a >protocol termination. In the RADIUS accounting logs, the session >has a Term-Cause of NAS-Error. Well...you're apparently not catching all of the PPP negotiation...which means we might be missing some useful data, but... You'll notice that the incoming config request does *not* have the MPP_MRRU attribute in it. The MPP_MRRU attribute is the attribute/value that indicates that Multi-Link can/will be used on that link. If one side doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that link. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) testing csu/dsu on DSP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-29 13:22:07

Hi folks... I've got a CSU/DSU on a HiPer DSP that I *think* may be going bad...not really sure though. I'd like to be able to test it, but I'm not really sure how. I've got some equipment that can send BERT patterns at it, but I'm not sure how to set up the DSP to actually deal with that. I've gotten it into a line loopback, so I can bounce the pattern off the loopback, but that's not terribly helpful when you're trying to test the actual CSU/DSU. :/ I've found that the DSP can send, what appears to be a quasi-random signal, but I can't get it to sync up when sending it. My current setup to try to test this is the DSP card is connected via a "null-t1" cable to my other equipment (a Cisco 7507 with a multi-channel port adapter...has integrated CSU/DSU's and ability to run quite a few different BERT patterns...more capability in this area from 3Com would be *really* cool to have ;). I can get the T1's to sync up normally (non-BERT) by setting the clock source on the Cisco to internal (which is expected...*someone* has to generate clock...although it seems they'll coast for a while with both pulling it off the line without falling out of sync). I can also set up a loopback on the DSP, and run anything I want from the cisco and it works (BERT, true T1 signalling, etc.), but I can't reverse it. I have tried setting the cisco to have a loopback and run qrs from the DSP (available via the "cmd sendcode qrs" command on the console) but it never seems to want to sync up that way. I've tried all different combinations of clocking sources on the DSP and cisco with the DSP running qrs, but never can get it to be happy. Anyone have any knowledge about, or experience with, testing a DSP CSU/DSU for problems using BERT patterns and the like? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) NFAS Dilema
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-29 13:36:44

Mark Lemmert writes... > . . . >Given this situation if you were me would you spend >the extra money on the second ARC or stretch the >first ARC a bit and run 10 DSPs on it? Thanks for >the input! If I were you I wouldn't run NFAS. In my opinion, the extra hassle it causes isn't worth the money saved. -- Aaron Nabil

Subject: Re: (usr-tc) Intermittent static on lines...
From: Aaron Nabil <nabil@spiritone.com>
Date: 1999-09-29 13:41:28

Slips would be just about the worst indicator when looking for line problems, look at any other counter first. Stainforth, Matthew writes... >Have you looked at your DS1 errors under TCM? That should tell you if you >have problems with the signal. Also, your telco should be able to look and >see if you have accumulated any slips. > >On Wednesday, September 29, 1999 2:14 PM, Christopher Arlis Hanes >[SMTP:chanes@usacars.com] wrote: >> I'm having a problem with static coming and going on my PRIs. The >> effect then is that users are unable to temporarily dial in - the modems >> aren't able to negotiate a connection. I'm fairly certain the >> interference is being produced on the utp cat 5 cable running about 25 >> feet on a ladder rack from the demarc point to my boxes. I'm planning >> on installing shielded cable immediately but was wondering if anyone has >> run into similar problems and has some advice? What is the best way to >> measure the noise on the line? I noticed under Performance Monitor on >> modems you can get s/n ratio info for each connection. What are >> acceptable levels? >> >> Thanks, >> Chris Hanes >> -- Aaron Nabil

Subject: Re: (usr-tc) 2 Issues
From: Curt Shambeau <curt@execpc.com>
Date: 1999-09-29 13:56:39

> The main problem is what I refer to as "hung modem" where 2 contiguous modems > in a DSP will somehow fail in such a way that incoming calls are answered, > but never complete the carrier. (list con shows them as call type > DIALIN INVALID) The errant modems show orders of magnitude more failed calls > in performance monitor. What the user dialing in experiences is something like > this: The TC picks up and transmits the answer tone. The client modem begins > making the handshake sounds, but the TC continues with the single tone as if > the client modem had not responded. Selecting the modems in TCM and > performing a software reset on them will clear it up 99% of the time. > They always appear in pairs. > > Does anyone know what might cause this? DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in any way, it takes out 2 modems. Depending on switch type, it manifests itself to the customer in various ways. You described one. This has been a horrible bug in the DSP since it was first introduced, and they have NEVER been able to fix it. It has gotten better over the years, but it is still a major concern for us. Our solution is to watch for it - busy out the entire card, wait for customers to drop off the card, and then reboot it. | Curtis V. Shambeau | curt@execpc.com | Senior Vice President | | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |

Subject: Re: (usr-tc) Intermittent static on lines...
From: farber@admin.f-tech.net
Date: 1999-09-29 14:00:42

How can you verify that there is static on the line? Shielded cable is a considerable expense... plus having to rerun the cable. Check the span for errors. CRC and BPV's are indications of signal problems. If you can do without the span for an hour or two have the telco loop you DSP for about 30 minutes and run a bit pattern (1 of 8). Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 29 Sep 1999, Christopher Arlis Hanes wrote: > I'm having a problem with static coming and going on my PRIs. The > effect then is that users are unable to temporarily dial in - the modems > aren't able to negotiate a connection. I'm fairly certain the > interference is being produced on the utp cat 5 cable running about 25 > feet on a ladder rack from the demarc point to my boxes. I'm planning > on installing shielded cable immediately but was wondering if anyone has > run into similar problems and has some advice? What is the best way to > measure the noise on the line? I noticed under Performance Monitor on > modems you can get s/n ratio info for each connection. What are > acceptable levels? > > Thanks, > Chris Hanes > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 2 Issues
From: Curt Shambeau <curt@execpc.com>
Date: 1999-09-29 14:07:56

> This is an unacceptable alternative! If you experience these > problems and it has been noted by 3Com, then it should be addressed and > corrected!! What about all those that are running several HUNDRED TC > hubs! I agree that it is unacceptable, and I am running several hundred TC hubs. | Curtis V. Shambeau | curt@execpc.com | Senior Vice President | | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN |

Subject: Re: (usr-tc) Netserver to ARC using Multilink
From: Carl Litt <carl@execulink.com>
Date: 1999-09-29 14:11:18

Yes, I did clip out a bit of info... here's the complete output: Monitoring the next session to start up. Decode tracing started, press ESCAPE to stop; press X for hex tracing. ....Tracing the current/next session; Escape to stop... Outgoing PPP Data on interface: slot:10/mod:12 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 MAGIC_NUM 9e 5a aa e5 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:10/mod:12 LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP 00 00 00 00 MAGIC_NUM eb c4 d4 f4 Outgoing PPP Data on interface: slot:10/mod:12 LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 ASYNC_MAP 00 00 00 00 MAGIC_NUM eb c4 d4 f4 Incoming PPP Data on interface: slot:10/mod:12 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 MAGIC_NUM 9e 5a aa e5 PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 I've also tried durning off PPP offloading for the hell of it, but no difference. Thanks, Carl On Wed, 29 Sep 1999, Jeff Mcadams wrote: > Thus spake Carl Litt > >Is it possible to get a Netserver to connect to a HiPer ARC > >with more than one channel (by using multilink)? > > >We're trying to move a customer over from dialing into another > >Netserver (not ours) into an ARC running 4.1.59. The login is set > >in RADIUS, and does work for a single channel. We have no > >Port-Limits set, and the ARC has the default 2 Max-Chan. > > >We can get the first channel up, but the second channel connects > >then drops. Here is the "mon ppp" output: > > >Incoming PPP Data on interface: slot:10/mod:23 > > LCP CFG_ACK MRU 05 ea > > ASYNC_MAP ff ff ff ff > > MAGIC_NUM 4c 56 1b da > > PROTO_COMP > > AC_COMP > > MPP_MRRU 05 ea > > MPP_ENDPTID 00 > > >Incoming PPP Data on interface: slot:10/mod:23 > > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 > > ASYNC_MAP ff ff ff ff > > MAGIC_NUM 23 ea 32 19 > > >Outgoing PPP Data on interface: slot:10/mod:23 > > LCP CFG_ACK MPP_ENDPTID 04 6f f7 09 08 > > ASYNC_MAP ff ff ff ff > > MAGIC_NUM 23 ea 32 19 > >--- [The call is then dropped] --- > > >From what I can see, there are no NAK's which should cause a > >protocol termination. In the RADIUS accounting logs, the session > >has a Term-Cause of NAS-Error. > > Well...you're apparently not catching all of the PPP negotiation...which > means we might be missing some useful data, but... > > You'll notice that the incoming config request does *not* have the MPP_MRRU > attribute in it. The MPP_MRRU attribute is the attribute/value that > indicates that Multi-Link can/will be used on that link. If one side > doesn't negotiation the MPP_MRRU, then Multi-Link can't work on that > link. > -- > 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. > >

Subject: Re: (usr-tc) Netserver to ARC using Multilink
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-29 14:20:08

Thus spake Carl Litt >Incoming PPP Data on interface: slot:10/mod:12 > LCP CFG_REQ MPP_ENDPTID 04 6f f7 09 08 > ASYNC_MAP 00 00 00 00 > MAGIC_NUM eb c4 d4 f4 Here's the first incoming lcp config request.... Again...no MPP_MRRU in this, Multi-Link won't work without that attribute being negotiated during the LCP phase. If a system tries to send a multi-link encapsulated packet without negotiating the MRRU, it is considered an error. So, the other side is not negotiating MP correctly. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPER Dsp Vs Quad Modem
From: Mike Andrews <mandrews@bit0.com>
Date: 1999-09-29 14:21:25

I'll bet the difference is customers with Rockwell HCF modems. They connect more reliably to Quads. Not that they connect very reliably to *anything*... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "With sufficient thrust, pigs fly just fine." -- RFC 1925 On Wed, 29 Sep 1999, Paul Oster wrote: > Ok, I've brought this up with 3com tech support, and they have not > been able > to answer my questions... I run approximately 8-10% Lost-Carrier > Rates on > my Quad Modem based chassis. On my DSP based chassis, that number is > 15-17%.

Subject: (usr-tc) NFAS Dilema
From: Mark Lemmert <cto@athenet.net>
Date: 1999-09-29 14:24:19

I am about to switch all my PRIs at one location to NFAS. The telco I am working with only supports 5 circuits per d channel. Since only 14 DPS can fit in a chassis that maximum # of groups of 5 I can fit is 2, which is only 10 DSPs per chassis. For management/organization reasons I want to have consistent sizes for the NFAS groups only put 10 DSPs chassis. My recollection is that 7 DSPs is the maximum that you are supposed to use per HiperARC card. Given this situation if you were me would you spend the extra money on the second ARC or stretch the first ARC a bit and run 10 DSPs on it? Thanks for the input! Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700

Subject: (usr-tc) DSL
From: Mike Wilker <mikew@ll.net>
Date: 1999-09-29 14:30:13

Does anyone still run the Affinity DSL on their TotalControls? I am trying to set one up that we've had for a year now, but I can't get the command line to come up on the card. Does it use the same console cable as the HiperArcs and NMCs, and is there another way to configure it, say through the Viper DSL? Thanks. Mike Wilker Operations Manager Local Link, Inc.

Subject: Re: (usr-tc) 2 Issues
From: pferraro@wna-linknet.com
Date: 1999-09-29 15:03:35

This is an unacceptable alternative! If you experience these problems and it has been noted by 3Com, then it should be addressed and corrected!! What about all those that are running several HUNDRED TC hubs! Just my .02 worth! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Wed, 29 Sep 1999, Curt Shambeau wrote: > > The main problem is what I refer to as "hung modem" where 2 contiguous modems > > in a DSP will somehow fail in such a way that incoming calls are answered, > > but never complete the carrier. (list con shows them as call type > > DIALIN INVALID) The errant modems show orders of magnitude more failed calls > > in performance monitor. What the user dialing in experiences is something like > > this: The TC picks up and transmits the answer tone. The client modem begins > > making the handshake sounds, but the TC continues with the single tone as if > > the client modem had not responded. Selecting the modems in TCM and > > performing a software reset on them will clear it up 99% of the time. > > They always appear in pairs. > > > > Does anyone know what might cause this? > > DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in > any way, it takes out 2 modems. Depending on switch type, it manifests > itself to the customer in various ways. You described one. > > This has been a horrible bug in the DSP since it was first introduced, and > they have NEVER been able to fix it. It has gotten better over the years, > but it is still a major concern for us. > > Our solution is to watch for it - busy out the entire card, wait for > customers to drop off the card, and then reboot it. > > > --------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | Senior Vice President | > | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN | > --------------------------------------------------------------------- > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Intermittent static on lines...
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-29 15:19:56

Have you looked at your DS1 errors under TCM? That should tell you if you have problems with the signal. Also, your telco should be able to look and see if you have accumulated any slips. On Wednesday, September 29, 1999 2:14 PM, Christopher Arlis Hanes [SMTP:chanes@usacars.com] wrote: > I'm having a problem with static coming and going on my PRIs. The > effect then is that users are unable to temporarily dial in - the modems > aren't able to negotiate a connection. I'm fairly certain the > interference is being produced on the utp cat 5 cable running about 25 > feet on a ladder rack from the demarc point to my boxes. I'm planning > on installing shielded cable immediately but was wondering if anyone has > run into similar problems and has some advice? What is the best way to > measure the noise on the line? I noticed under Performance Monitor on > modems you can get s/n ratio info for each connection. What are > acceptable levels? > > Thanks, > Chris Hanes > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 2 Issues
From: Carl Litt <carl@execulink.com>
Date: 1999-09-29 15:35:51

Not only is it unacceptable to have to babysit a ~$10,000 DSP card, but we can't do it here anyways. When we soft-busy out the card, incoming callers get a switch-bitch message. (We're new to PRI, and haven't had time to debug yet). We're using round-robin modem assignment. With fixed assignment, a bad modem will always be assigned to the n'th DS0. Any time that DS0 rings, that bad modem answers. With round-robin on PRI, the bad modem will answer once, then rotate out to be the spare for a little while. I usually have several modems each day going FUBAR. Of course, you can't busy out a modem, and software resets don't do the job, so we're stuck living with it. I noticed this behaviour of the locking modem pairs months ago and pointed it out on the list, but couldn't get a discussion going. Anyone have any suggestions? On Wed, 29 Sep 1999 pferraro@wna-linknet.com wrote: > > This is an unacceptable alternative! If you experience these > problems and it has been noted by 3Com, then it should be addressed and > corrected!! What about all those that are running several HUNDRED TC > hubs! > > Just my .02 worth! > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Wed, 29 Sep 1999, Curt Shambeau wrote: > > > > The main problem is what I refer to as "hung modem" where 2 contiguous modems > > > in a DSP will somehow fail in such a way that incoming calls are answered, > > > but never complete the carrier. (list con shows them as call type > > > DIALIN INVALID) The errant modems show orders of magnitude more failed calls > > > in performance monitor. What the user dialing in experiences is something like > > > this: The TC picks up and transmits the answer tone. The client modem begins > > > making the handshake sounds, but the TC continues with the single tone as if > > > the client modem had not responded. Selecting the modems in TCM and > > > performing a software reset on them will clear it up 99% of the time. > > > They always appear in pairs. > > > > > > Does anyone know what might cause this? > > > > DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in > > any way, it takes out 2 modems. Depending on switch type, it manifests > > itself to the customer in various ways. You described one. > > > > This has been a horrible bug in the DSP since it was first introduced, and > > they have NEVER been able to fix it. It has gotten better over the years, > > but it is still a major concern for us. > > > > Our solution is to watch for it - busy out the entire card, wait for > > customers to drop off the card, and then reboot it. > > > > > > --------------------------------------------------------------------- > > | Curtis V. Shambeau | curt@execpc.com | Senior Vice President | > > | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN | > > --------------------------------------------------------------------- > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. > >

Subject: Re: (usr-tc) 2 Issues
From: farber@admin.f-tech.net
Date: 1999-09-29 15:41:36

It happened about 3 times in a year over 6 DSP's.... ANY complex equipment will have quirks. Solution? A pager and a perl script. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 29 Sep 1999 pferraro@wna-linknet.com wrote: > > This is an unacceptable alternative! If you experience these > problems and it has been noted by 3Com, then it should be addressed and > corrected!! What about all those that are running several HUNDRED TC > hubs! > > Just my .02 worth! > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Wed, 29 Sep 1999, Curt Shambeau wrote: > > > > The main problem is what I refer to as "hung modem" where 2 contiguous modems > > > in a DSP will somehow fail in such a way that incoming calls are answered, > > > but never complete the carrier. (list con shows them as call type > > > DIALIN INVALID) The errant modems show orders of magnitude more failed calls > > > in performance monitor. What the user dialing in experiences is something like > > > this: The TC picks up and transmits the answer tone. The client modem begins > > > making the handshake sounds, but the TC continues with the single tone as if > > > the client modem had not responded. Selecting the modems in TCM and > > > performing a software reset on them will clear it up 99% of the time. > > > They always appear in pairs. > > > > > > Does anyone know what might cause this? > > > > DSP Lockups. Each DSP handles 2 modems, and as such, when it locks up in > > any way, it takes out 2 modems. Depending on switch type, it manifests > > itself to the customer in various ways. You described one. > > > > This has been a horrible bug in the DSP since it was first introduced, and > > they have NEVER been able to fix it. It has gotten better over the years, > > but it is still a major concern for us. > > > > Our solution is to watch for it - busy out the entire card, wait for > > customers to drop off the card, and then reboot it. > > > > > > --------------------------------------------------------------------- > > | Curtis V. Shambeau | curt@execpc.com | Senior Vice President | > > | ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol: VOYN | > > --------------------------------------------------------------------- > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: Re: (usr-tc) Ascend Pipelines
From: Chad Scheiter <chad@amouse.net>
Date: 1999-09-29 15:44:06

Jeff Binkley wrote: > We have 3 Ascend Pipeline 50/75 customers connecting to our TC chassis'. > In each case we give them a static IP address via Radius. In all cases > we cannot ping the static address (i.e. Ascend doesn't respond) yet the > users behind the pipeline work fine adn we can telnet into the Ascend if > we add a static route for port 23 to the static IP address. Does anyone > know how to correct this ? It makes troubleshooting more difficult when > ping doesn't work. I have a Pipeline 75 connect to my TC with NAT and I cannot ping it, but my customer can connect fine. And with a default server set in the NAT config I can pass SMTP traffic through it, but still cannot ping. And I have a Pipeline 130 connected to a Max 4000, with no NAT and it is bridged not routed and my Max 4000 responds to ANY ping sent from the Pipeline or any computer on that side of the link. Basically the only thing I have seen that Ascends can do well is V.90, I've had to send 4 Max4048 back because of hardware failures in the past 2 years. Can you guess why I'll put up the worse V.90 connect rates in a TC?

Subject: Re: (usr-tc) 2 Issues
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-29 15:47:39

Thus spake Carl Litt >Not only is it unacceptable to have to babysit a ~$10,000 DSP card, >but we can't do it here anyways. When we soft-busy out the card, >incoming callers get a switch-bitch message. (We're new to PRI, >and haven't had time to debug yet). Get off of NI-2 and go to a custom translation. NI-2 doesn't have any concept of "service messages" meaning that if you soft-busy out a ds0, it has no way of informing the switch of that, so the switch will still try to send calls down that ds0. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Pipe 75 + Static IP + NAT
From: Marius Strom <marius@alpha1.net>
Date: 1999-09-29 16:29:48

I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I enable it, it won't connect.. The pipe has been dialing into a Livingston PM2e up until now, and when I modify the remote address and the phone number to have it dial to our TC equipment, it won't do it. I've gone and disabled things such as STAC and all other compressions.. I did set the Pipe to MP with BACP=Yes. Please let me know if you guys have had any success, and if you've got success, let me know how I can have it too *chuckle* Thanks in advance! -- Marius Strom <marius@alpha1.net> Professional Geek/Unix System Administrator Alpha1 Internet <http://www.alpha1.net> http://www.marius.org/marius.pgp 0x5645C228 In theory, there is no difference between theory and practice... ...In practice, there is a big difference.

Subject: RE: (usr-tc) NFAS Dilema
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-29 16:38:16

If you're not running IPX, you can safely do 10 DSPs per ARC. I'm using a single ARC on 10 DSPs but I'm only doing PPP, no IPX, all static routing. Also, your power supplies will be a limiting factor - I believe the maximum for a 70A chassis is 10 DSPs but I'm running dual 130's so I can't testify to that. On Wednesday, September 29, 1999 4:24 PM, Mark Lemmert [SMTP:cto@athenet.net] wrote: > I am about to switch all my PRIs at one location to NFAS. > The telco I am working with only supports 5 circuits per > d channel. > > Since only 14 DPS can fit in a chassis that > maximum # of groups of 5 I can fit is 2, which is only > 10 DSPs per chassis. For management/organization reasons > I want to have consistent sizes for the NFAS groups > only put 10 DSPs chassis. > > My recollection is that 7 DSPs is the maximum that you > are supposed to use per HiperARC card. > > Given this situation if you were me would you spend > the extra money on the second ARC or stretch the > first ARC a bit and run 10 DSPs on it? Thanks for > the input! > > > > > > > > > > > > > > > ----------------------------------------------------------------------- > Mark Lemmert AthEnet Data Exchange > Chief Technical Officer 888-919-8700 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) 2 Issues
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 1999-09-29 16:56:18

On Wednesday, September 29, 1999 4:36 PM, Carl Litt [SMTP:carl@execulink.com] wrote: > I noticed this behaviour of the locking modem pairs months ago and > pointed it out on the list, but couldn't get a discussion going. > > Anyone have any suggestions? > There was some ER code floating around that addressed this but I wasn't too keen on running this on my production systems. I'm just waiting for them to hopefully merge the fix into the next 2.0.x DSP code release. Maybe someone from 3Com can confirm whether the next release will have this fixed. Matthew

Subject: (usr-tc) Disconnecting Connections
From: Interests <interests@linkfast.net>
Date: 1999-09-29 17:59:37

I am trying to find the command to disconnect a particular connection on a TC. Anyone know off the top of your heads? Jason A. Nunnelley President of Linkfast Inc. "I always respond to E-mail" PO BOX 202 Cullman AL 35056 256-739-2008 Voice 770-234-5702 Fax Billing and Office Hours: 9am - 9pm Monday through Friday Tech Support Hours: 9am - 9pm Monday through Friday 9am - 5pm Saturday Support Online: http://linkfast.net/support.html

Subject: Re: (usr-tc) Disconnecting Connections
From: Interests <interests@linkfast.net>
Date: 1999-09-29 18:13:54

I realized this post was not very specific. When you have a particular dialup or ISDN connection (as you would view in a telnet session), say on slot:3/mod:20 for EX. How can you terminate that particular connection and not impact any other connected users. I can't find the command. In a Livingston box, you could type in "reset s20" for example. Jason A. Nunnelley President of Linkfast Inc. "I always respond to E-mail" PO BOX 202 Cullman AL 35056 256-739-2008 Voice 770-234-5702 Fax Billing and Office Hours: 9am - 9pm Monday through Friday Tech Support Hours: 9am - 9pm Monday through Friday 9am - 5pm Saturday Support Online: http://linkfast.net/support.html ----- Original Message ----- Sent: Wednesday, September 29, 1999 5:59 PM > I am trying to find the command to disconnect a particular > connection on a TC. Anyone know off the top of your heads? > > Jason A. Nunnelley > President of Linkfast Inc. > "I always respond to E-mail" > > PO BOX 202 > Cullman AL 35056 > > 256-739-2008 Voice > 770-234-5702 Fax > > Billing and Office Hours: > 9am - 9pm Monday through Friday > > Tech Support Hours: > 9am - 9pm Monday through Friday > 9am - 5pm Saturday > > Support Online: > http://linkfast.net/support.html > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Disconnecting Connections
From: Marius Strom <marius@alpha1.net>
Date: 1999-09-29 18:19:39

hangup interface slot:#/mod:# -- Marius Strom <marius@alpha1.net> Professional Geek/Unix System Administrator Alpha1 Internet <http://www.alpha1.net> http://www.marius.org/marius.pgp 0x5645C228 In theory, there is no difference between theory and practice... ...In practice, there is a big difference. On Wed, 29 Sep 1999, Interests wrote: > I realized this post was not very specific. When you have > a particular dialup or ISDN connection (as you would view > in a telnet session), say on slot:3/mod:20 for EX. How can > you terminate that particular connection and not impact > any other connected users. I can't find the command. In a > Livingston box, you could type in "reset s20" for example. > > Jason A. Nunnelley > President of Linkfast Inc. > "I always respond to E-mail" > > PO BOX 202 > Cullman AL 35056 > > 256-739-2008 Voice > 770-234-5702 Fax > > Billing and Office Hours: > 9am - 9pm Monday through Friday > > Tech Support Hours: > 9am - 9pm Monday through Friday > 9am - 5pm Saturday > > Support Online: > http://linkfast.net/support.html > ----- Original Message ----- > From: Interests <interests@linkfast.net> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, September 29, 1999 5:59 PM > Subject: (usr-tc) Disconnecting Connections > > > > I am trying to find the command to disconnect a particular > > connection on a TC. Anyone know off the top of your heads? > > > > Jason A. Nunnelley > > President of Linkfast Inc. > > "I always respond to E-mail" > > > > PO BOX 202 > > Cullman AL 35056 > > > > 256-739-2008 Voice > > 770-234-5702 Fax > > > > Billing and Office Hours: > > 9am - 9pm Monday through Friday > > > > Tech Support Hours: > > 9am - 9pm Monday through Friday > > 9am - 5pm Saturday > > > > Support Online: > > http://linkfast.net/support.html > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Subject: Re: (usr-tc) Pipe 75 + Static IP + NAT
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1999-09-29 18:25:43

If you're running older versions of the TC software (as I am), BACP won't work (or at least, I can't make it work). Early on, one of my customers asked for a recommendation and I told 'em to buy the Ascend PL75 and then found that out. The choice is to 1) upgrade TC software [I think], 2) turn off BACP on the Ascend and tell it to either use just one channel or both of 'em with MP. For reference, I'm running Harc 4.0.30 and Hdsp 1.2.5. I'm going to upgrade after the upgrade is such that it fixes things and doesn't just trade my current problems for a new batch of problems. This software load I'm running only seems to have problems with older Rockwell stuff, and most of those are fixed by upgrading the client modems' code (or telling the customer they've been duped into buying a crap modem). ...other than that, everything's stable...no webtv problems, incredibly infrequent hung-modem problems, or any of the other issues that seem to be terrorizing others on the list here. Even current 3com Sportsters are speedy (to include a current thread *grin*). Telling a new customer that they need to upgrade their modem's software or maybe consider a decent modem is hard, but easier than explaining to an existing customer that they can't connect anymore or get a good speed because I "upgraded". [/rant] As for ISDN lan stuff, nowadays I recommend the smaller offices to use the 3com LANmodem or bigger places to use the Cisco 800-series. LANmodem blazingly easy to set up, and although I'd never claim a Cisco was easy to set up, after they're configured they run like, umm, a Cisco. Turn out the lights and shut the closet for a couple years. Lon On Wed, 29 Sep 1999, Marius Strom wrote: > I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a > HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I > enable it, it won't connect.. The pipe has been dialing into a Livingston > PM2e up until now, and when I modify the remote address and the phone > number to have it dial to our TC equipment, it won't do it. I've gone and > disabled things such as STAC and all other compressions.. I did set the > Pipe to MP with BACP=Yes. > > Please let me know if you guys have had any success, and if you've got > success, let me know how I can have it too *chuckle* > > Thanks in advance! > > -- > Marius Strom <marius@alpha1.net> > Professional Geek/Unix System Administrator > Alpha1 Internet <http://www.alpha1.net> > http://www.marius.org/marius.pgp 0x5645C228 > > In theory, there is no difference between theory and practice... > ...In practice, there is a big difference. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Disconnecting Connections
From: Interests <interests@linkfast.net>
Date: 1999-09-29 18:41:57

Subject: Re: (usr-tc) Going nowhere fast...
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1999-09-29 19:12:53

On Wed, 29 Sep 1999, Jerry Wright wrote: > We had a USR TC box with 48 modems and 2 T1s. It worked... > Well, we got our third T1 and a used TC box. Now, about a third of our > customers log on, get authenticated, and sit there (ping and traceroute > work, web browsing doesn't). Or else, they get an error 750 or 765 or > other type error. Could our new T1 NIC card be bad? It passes the > various tests? Help!!! When you say you got a third box - I understand that you got a USR Chassis, with a T1 card, modems, nmc and a router card (either Hiper arc or NETSERVER). From what you say is that the users dial in and they get authenticated but cannot browse etc, then the problem is on the router card or on your network. May be you are running out of IP address, or maybe the ip address are overlapping, or you have a problem with arp cache - So in short looks like our t1 card is fine and you need to take a look at the routing part of the connection. > Other info, the T1 performance test tells me 3865 bipolar whatever > errors in the last 24 hours. Bad card??? US West says the line tests > out good. > If you have line problems the calls will drop/ not connect etc. You need to take a look at your hiper/netserver and see what is happeing from that end. krish > Jerry Wright > Internet Access of Moses Lake > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Disconnecting Connections
From: Ronald Kushner <ron@glis.net>
Date: 1999-09-29 19:43:19

Interests wrote: > > I am trying to find the command to disconnect a particular > connection on a TC. Anyone know off the top of your heads? I've found DISCONNECT USER username works fine, or you can use hangup slot:X/mod:Y where X and Y are replaced with slot and modem. -Ron GLISnet, Inc. +1 810/939.9885

Subject: RE: (usr-tc) Disconnecting Connections
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-29 19:50:51

DISC USER kills the connection (I think it drops DTR) and modem resets for next call automatically. Problem is that if you want to kill one channel of a MP call, it will knock off both channels since the username is the same for both. I never knew about the HANGUP INTERFACE command -- that would seems to take care of that since you can specifiy the exact channel and leave the other one alone. -Scot -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Interests Sent: Wednesday, September 29, 1999 7:42 PM does this disconnect the user and re-open the line on both commands? or does the hangup hang the line until you reset the line? Jason A. Nunnelley President of Linkfast Inc. "I always respond to E-mail" PO BOX 202 Cullman AL 35056 256-739-2008 Voice 770-234-5702 Fax Billing and Office Hours: 9am - 9pm Monday through Friday Tech Support Hours: 9am - 9pm Monday through Friday 9am - 5pm Saturday Support Online: http://linkfast.net/support.html ----- Original Message ----- Sent: Wednesday, September 29, 1999 6:19 PM > > You can use: > > Harc> haNGUP inTERFACE slot:x/mod:y > > or > > Harc> discoNNECT usER username > > - Marcelo > > On Wed, 29 Sep 1999, Interests wrote: > > |I realized this post was not very specific. When you have > |a particular dialup or ISDN connection (as you would view > |in a telnet session), say on slot:3/mod:20 for EX. How can > |you terminate that particular connection and not impact > |any other connected users. I can't find the command. In a > |Livingston box, you could type in "reset s20" for example. > | > |Jason A. Nunnelley > |President of Linkfast Inc. > |"I always respond to E-mail" > | > |PO BOX 202 > |Cullman AL 35056 > | > |256-739-2008 Voice > |770-234-5702 Fax > | > |Billing and Office Hours: > |9am - 9pm Monday through Friday > | > |Tech Support Hours: > |9am - 9pm Monday through Friday > |9am - 5pm Saturday > | > |Support Online: > |http://linkfast.net/support.html > |----- Original Message ----- > |From: Interests <interests@linkfast.net> > |To: <usr-tc@lists.xmission.com> > |Sent: Wednesday, September 29, 1999 5:59 PM > |Subject: (usr-tc) Disconnecting Connections > | > | > |> I am trying to find the command to disconnect a particular > |> connection on a TC. Anyone know off the top of your heads? > |> > |> Jason A. Nunnelley > |> President of Linkfast Inc. > |> "I always respond to E-mail" > |> > |> PO BOX 202 > |> Cullman AL 35056 > |> > |> 256-739-2008 Voice > |> 770-234-5702 Fax > |> > |> Billing and Office Hours: > |> 9am - 9pm Monday through Friday > |> > |> Tech Support Hours: > |> 9am - 9pm Monday through Friday > |> 9am - 5pm Saturday > |> > |> Support Online: > |> http://linkfast.net/support.html > |> > |> > |> - > |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > |> with "unsubscribe usr-tc" in the body of the 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. > | > > - 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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Disconnecting Connections
From: Scot Desort <scot@njaccess.net>
Date: 1999-09-29 19:50:51

Subject: Re: (usr-tc) Disconnecting Connections
From: K Mitchell <mitch@keyconn.net>
Date: 1999-09-29 20:07:54

At 06:41 PM 9/29/99 -0500, you wrote: >does this disconnect the user and re-open the line on both >commands? or does the hangup hang the line until you reset >the line? Either command will reset the line also. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Disconnecting Connections
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1999-09-29 20:19:09

Subject: Re: (usr-tc) Pipe 75 + Static IP + NAT
From: Chad Scheiter <chad@amouse.net>
Date: 1999-09-29 21:13:05

Marius Strom wrote: > I'm trying to hook up a Pipe 75 with a Static IP and NAT enabled to a > HiPerARC chassis.. When I disable the NAT on the Pipe, it connects, when I > enable it, it won't connect.. The pipe has been dialing into a Livingston > PM2e up until now, and when I modify the remote address and the phone > number to have it dial to our TC equipment, it won't do it. I've gone and > disabled things such as STAC and all other compressions.. I did set the > Pipe to MP with BACP=Yes. > > Please let me know if you guys have had any success, and if you've got > success, let me know how I can have it too *chuckle* Do you have the LAN Adrs, WAN Alias, or IF Adrs defined? I left those blank and assign the static IP from radius. Otherwise you have to set reported IP on the TC to correspond with the LAN Adrs. You should be able to just define the WAN Alias but I couldn't even get that to work between two ascends. What is mon ppp outputting?

Subject: (usr-tc) Going nowhere fast...
From: Jerry Wright <jwright@hyperserv.com>
Date: 1999-09-29 22:42:28

We had a USR TC box with 48 modems and 2 T1s. It worked... Well, we got our third T1 and a used TC box. Now, about a third of our customers log on, get authenticated, and sit there (ping and traceroute work, web browsing doesn't). Or else, they get an error 750 or 765 or other type error. Could our new T1 NIC card be bad? It passes the various tests? Help!!! Other info, the T1 performance test tells me 3865 bipolar whatever errors in the last 24 hours. Bad card??? US West says the line tests out good. Jerry Wright Internet Access of Moses Lake

Subject: (usr-tc) 2 Issues
From: Barry Yost <barry@zebra.net>
Date: 1999-09-30 01:45:17

We have recently consolidated all of our nodes to use the TC HiPerARC + DSP chasses, and in doing so, have come across 2 issues: The main problem is what I refer to as "hung modem" where 2 contiguous modems in a DSP will somehow fail in such a way that incoming calls are answered, but never complete the carrier. (list con shows them as call type DIALIN INVALID) The errant modems show orders of magnitude more failed calls in performance monitor. What the user dialing in experiences is something like this: The TC picks up and transmits the answer tone. The client modem begins making the handshake sounds, but the TC continues with the single tone as if the client modem had not responded. Selecting the modems in TCM and performing a software reset on them will clear it up 99% of the time. They always appear in pairs. Does anyone know what might cause this? The chases have 130A dual power supplies, and the following code rev's: DSP: 2.0.81 ARC: 4.2.32 NMC: 6.2.17 (This happens in different POPs as well.) Also, we had bad experiences turning on BACP in earlier code rev's of the ARC cards, and at 3Com's advise, left the feature disabled. We have many users of Ascend Pipeline routers that apparently insist on using bacp for dynamic bandwidth if they can't have their proprietary Ascend protocol. One user in particular has spent extensive hours with Ascend trying unsuccessfully to make a P130 do dynamic channel allocation with our HiPerARC servers. Does anyone have a workaround for this, or has BACP been stabalized enough to warrant activating the feature?

Subject: Re: (usr-tc) Going nowhere fast...
From: Brian Hitchcock <brianh@kcweb.net>
Date: 1999-09-30 07:10:06

Are they getting the right DNS server information? Brian Hitchcock ----- Original Message ----- Sent: Thursday, September 30, 1999 12:42 AM > We had a USR TC box with 48 modems and 2 T1s. It worked... > Well, we got our third T1 and a used TC box. Now, about a third of our > customers log on, get authenticated, and sit there (ping and traceroute > work, web browsing doesn't). Or else, they get an error 750 or 765 or > other type error. Could our new T1 NIC card be bad? It passes the > various tests? Help!!! > Other info, the T1 performance test tells me 3865 bipolar whatever > errors in the last 24 hours. Bad card??? US West says the line tests > out good. > > Jerry Wright > Internet Access of Moses Lake > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Netserver problem
From: Marty Elliott <marty@2assetrecovery.com>
Date: 1999-09-30 08:57:46

Corrupt flash -- reflash it via the serial port Aaron -- same problem we've got with all of our stock cards (drat). Marty At 01:49 AM 10/01/1999 +1000, you wrote: >Well I'm just full of problems arent I :-D > >I have a Netserver card that once powered up the rn/fl led flashes green on >and off 13 times, then flashes quickly for a few seconds, then goes solid green >for a while, then repeast the process. >Anyone know whats going on? > >Thanks, >Aaron > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Going nowhere fast...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1999-09-30 09:17:24

Thus spake Tatai SV Krishnan >On Wed, 29 Sep 1999, Jerry Wright wrote: >> Other info, the T1 performance test tells me 3865 bipolar whatever >> errors in the last 24 hours. Bad card??? US West says the line tests >> out good. >If you have line problems the calls will drop/ not connect etc. >You need to take a look at your hiper/netserver and see what is happeing >from that end. To expand a bit...if you're getting bipolar variation errors, that is cause for concern, but from your description of your problem, this isn't related. Put the BPV errors on the back burner for now...get your routing problem solved, and come back to the BPV's...it is definitely something you need to look at eventually. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Modems
From: Startup Suppliers Ltd. <startnet@arcc.or.ke>
Date: 1999-09-30 10:31:44

Hi All! I need modems in racks for use with PM2E 30 portmasters. I need 100 units 33.6 in racks or something similar. Please respond with best prices. Okeyo

Subject: RE: (usr-tc) Netserver problem
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 1999-09-30 10:56:45

Anything on the console port? Bootup messages? (actually don't think you would see those if I recall correctly, just a login prompt when it is up...) Get out the pcsdl, source and re-upload it via serial cable. Hint: set your serial port to at least 57600 w/dip switches. Sounds like your flash got corrupted. Or send it back to 3Com and they'll do probably the same thing. SMT > -----Original Message----- > From: Dataheart [mailto:lists@dataheart.net] > Sent: Thursday, September 30, 1999 10:49 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Netserver problem > > > Well I'm just full of problems arent I :-D > > I have a Netserver card that once powered up the rn/fl led > flashes green on > and off 13 times, then flashes quickly for a few seconds, > then goes solid green > for a while, then repeast the process. > Anyone know whats going on? > > Thanks, > Aaron > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Modems
From: Startup Suppliers Ltd. <startnet@arcc.or.ke>
Date: 1999-09-30 12:03:45

Hi All! Can someone advise me how Netserver 16 I works. Do I need a portmaster to go with it? Is it an obsolete technology? What are it's problems and disadvantages? Okeyo.

Subject: (usr-tc) E1 Configuration
From: Dataheart <lists@dataheart.net>
Date: 1999-09-30 14:07:26

Hi, I am new to this list and wondering if anyone would be able to give me a tutorial on how to configure a dual PRI NAC with dual E1 NIC for analog(56k) connections in Australia. I have been running straight analog(33.6k) racks for about 3 years now but now the telco has installed the PRI Trunks and I am stuffed with the conversion. Any help is greatly appreciated. Thanks, Aaron P.S. I am sure that this question would have been asked before so if anyone could point me in the direction of the archives I would appreciate that as well.

Subject: (usr-tc) Quad Digital Modems
From: Steve Rivera <sales@wrca.net>
Date: 1999-09-30 15:23:40

Are the quad digital modems able to handle analog application, as long as nic cards are installed on the chassis. I have customer who is setting up a ISP across seas. He is currently only able to get POT connections, but that is only for now. If he buys the quad digital cards will he ba able to suuport the analog connections now and the digital later. .................................................... Steve Rivera - VP-WR Consultant Associates, Inc. (WRCA) sales@wrca.net v-732-833-2111 pgr-732-325-1092 WAN ACCESS SPECIALIST---http://www.wrca.net (CompleteLine Card) Cisco, Ascend,USR,Adtran, Kentrox,Livingston, Microcom,Computone,Verilink IBM,Motorola,UDS,Codex,ATT/Paradyne,Hayes,Racal Datacom,GDC,Telebit MultiTech,Sync/Tylink,Wellfleet,BayNetworks(5399),Black Box,Micom & More

Subject: Re: (usr-tc) Quad Digital Modems
From: Jerry Wright <jwright@hyperserv.com>
Date: 1999-09-30 18:00:55

As far as I know, you need the quad Analog/Digital modems to do that. They should be as easy to come by, used, as the straight Digital ones. --Jerry Steve Rivera wrote: > > Are the quad digital modems able to handle analog application, > as long as nic cards are installed on the chassis.

Subject: Re: (usr-tc) Going nowhere fast...
From: Jerry Wright <jwright@hyperserv.com>
Date: 1999-09-30 18:07:58

Yes, it MUST be a routing problem. I have a Netserver card and NMC, with a pool of x.x.x.10 thru x.x.x.65 for the first box. In the second box I have the NMC set to x.x.x.66, the Netserver set to x.x.x.67 and the pool set to x.x.x.68 thru x.x.x.128. The I.P. Gateway is set to x.x.x.1 Here... Command> sho global System Name: tcbox2 IP Gateway: 207.178.26.1 Gateway Metric: 1 IPX Gateway: 00000000:000000000000 Gateway Metric: 0 Default Route: Broadcast, Listen (On) Domain: iaml.net Name Service: DNS Name Servers: 207.178.26.2 0.0.0.0 0.0.0.0 Sys Loghosts: 207.178.26.150 0.0.0.0 RADIUS Server: 207.178.26.3 Port: 1645 Version: 1 Alt. RADIUS Server: 0.0.0.0 Port: 1645 Version: 1 Accounting Server: 207.178.26.3 Port: 1646 Version: 1 Alt. Acct. Server: 0.0.0.0 Port: 1646 Version: 1 NTP Time Server: 0.0.0.0 Alt. Time Server: 0.0.0.0 MPIP Server: 0.0.0.0 Port: 5912 MPIP Server: 0.0.0.0 Port: 5912 MPIP Server: 0.0.0.0 Port: 5912 MPIP Server: 0.0.0.0 Port: 5912 PPTP IP Address: 0.0.0.0 Telnet Access Port: 23 TCP Maximal Segment Size: 0 Assigned Address: 207.178.26.68 Reported Address: 207.178.26.67 Assigned Pool Size: 61 Periodic CHAP timeout: 5 -- Press Return for More -- PPP in modem: ON SLIP in modem: OFF Packet bus clock: MASTER ICMP error logging: OFF Connect message: OFF Dial !root access: ON Random hosts list: OFF SNMP: ON Proxy Arp: ON Response message: OFF PPP message: ON Lan/Wan Routing: ON RIP V2 Authen: OFF VPN Local Routing: OFF MPIP Server: OFF Hint assigned: OFF Tap Login: OFF Syslog facility: auth Extd. IPXCP Opts: OFF Acct AuthChk: OFF/OFF Send DNS info: ON DNS cache reset timeout: 0 days 0 hours 30 minutes (30 min) Configured Ethernet media: Autodetect Command> That's what it says.... --Help!!!! --Jerry Jeff Mcadams wrote: > > Thus spake Tatai SV Krishnan > >On Wed, 29 Sep 1999, Jerry Wright wrote: > >> Other info, the T1 performance test tells me 3865 bipolar whatever > >> errors in the last 24 hours. Bad card??? US West says the line tests > >> out good. > > >If you have line problems the calls will drop/ not connect etc. > >You need to take a look at your hiper/netserver and see what is happeing > >from that end. > > To expand a bit...if you're getting bipolar variation errors, that is > cause for concern, but from your description of your problem, this isn't > related. Put the BPV errors on the back burner for now...get your > routing problem solved, and come back to the BPV's...it is definitely > something you need to look at eventually. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Going nowhere fast...
From: Jerry Wright <jwright@hyperserv.com>
Date: 1999-09-30 18:25:32

Yes they are... In fact, last night I got logged into the new box, and I could ping and tracert out of windows, but couldn't go anywhere. It could be what IP address I was assigned, maybe... --Jerry Brian Hitchcock wrote: > Are they getting the right DNS server information? > > Brian Hitchcock > ----- Original Message ----- > From: Jerry Wright <jwright@hyperserv.com> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, September 30, 1999 12:42 AM > Subject: (usr-tc) Going nowhere fast... > > > We had a USR TC box with 48 modems and 2 T1s. It worked... > > Well, we got our third T1 and a used TC box. Now, about a third of our > > customers log on, get authenticated, and sit there (ping and traceroute > > work, web browsing doesn't). Or else, they get an error 750 or 765 or > > other type error. Could our new T1 NIC card be bad? It passes the > > various tests? Help!!! > > Other info, the T1 performance test tells me 3865 bipolar whatever > > errors in the last 24 hours. Bad card??? US West says the line tests > > out good. > > > > Jerry Wright > > Internet Access of Moses Lake > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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.

Subject: RE: (usr-tc) Netserver problem
From: Blake Fithen <fithen@networksplus.com>
Date: 1999-09-30 19:57:04

Had the same problem once. Try reflashing it using PCSDL.EXE. blake > -----Original Message----- > From: Dataheart [mailto:lists@dataheart.net] > Sent: Thursday, September 30, 1999 10:49 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Netserver problem > > > Well I'm just full of problems arent I :-D > > I have a Netserver card that once powered up the rn/fl led > flashes green on > and off 13 times, then flashes quickly for a few seconds, > then goes solid green > for a while, then repeast the process. > Anyone know whats going on? > > Thanks, > Aaron > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Going nowhere fast...
From: eric@dol.net
Date: 1999-09-30 20:07:59

>When you say you got a third box - I understand that you got a USR >Chassis, with a T1 card, modems, nmc and a router card (either Hiper arc >or NETSERVER). From what you say is that the users dial in and they get >authenticated but cannot browse etc, then the problem is on the router >card or on your network. > >May be you are running out of IP address, or maybe the ip address are >overlapping, or you have a problem with arp cache - >So in short looks like our t1 card is fine and you need to take a look at >the routing part of the connection. > I just had the same problem and my ip addresses were over lapping. Check to make sure you did not assign the ips anywhere else in your network. You may have a static route to a customer that you forgot about and the pools is falling into that area. You may have used some of the ips on a web server somewhwere. Start digging in this direction. eric >Delaware Online!.........The SMART Choice! With 56K V.90 & X2 & Flex Modems Phone : 302-762-0375 Fax: 302-762-3462 Failure is NOT an option...

Subject: (usr-tc) using mp/16 at a POP...
From: albert <emmanuel@mwt.net>
Date: 1999-09-30 21:36:04

I have a client that is setting a POP and wants to use a MP/16.. HE has a leased line from point A to point B, the mp/16 is at point B. Can the calls be sent to point A without using a portmaster.?? al.

Subject: (usr-tc) RADIUS Authentication & Accounting
From: Dataheart <lists@dataheart.net>
Date: 1999-09-30 23:54:36

Howdy, I am looking for a good RADIUS server for use with both HiPer and Analog Total Control Chassis under linux. I need to have the users file as a table in a PostgreSQL server that contains all the radius attributes that would normally be specified in the users file(this feature is necessary to interact with our accounting system). all users need to be able to be authenticated off the system password e.g. /etc/passwd, and there needs to be an accurate accessible list of the currently logged in users. Similar to the Total Control Security & Accounting Server from 3Com which I am fairly familiar with, but on a Linux platform. I have had a look at Cistron Radius and its PAM, but from the docs it seems to be not quite what I am after. is there something out there or am I living in a dream world. Oh yeah and would like realm support but it is not absolutely essential. Thanks heaps people, Aaron

Subject: (usr-tc) TCHub and routing
From: Robb Bryn <rbryn@cape-fear.net>
Date: 1999-10-01 00:24:31

This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BF0BA2.6EE25F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I'm configuring my first routed subnet on the TCHub and can't quite figure out what I'm doing wrong. I have a Ascend P50 dialing in via ISDN with radius attributes of: Framed-Address = 208.150.95.241 Framed-Route = 208.150.95.240/29 208.150.95.241 1 After connecting, I can ping the ether address of the TCHub (208.133.28.51) from any of the subnet hosts can't ping anything past it. I can't ping any host on the subnet from the TCHub. Below is the output from the show ip network command. HiPer>> show ip network test-ip-I4586 SHOW IP NETWORK test-ip-I4586 SETTINGS: Interface: slot:14/mod:2 Network Address: 208.150.95.241/H Frame Type: PPP Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.255 Station: 0.0.0.0 Broadcast Algorithm: IETF Max Reassembly Size: 3464 IP Routing Protocol: NONE IP Routing Metric: 1 RIP Interface Export Metric: 0 IP RIP Routing Policies: IP RIP Authentication Key: HiPer>> I'm pulling my hair out trying to figure out what I've done wrong. A kick in the right direction would be greatly appreciated. Thanks, Robb Bryn ------=_NextPart_000_000A_01BF0BA2.6EE25F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>I'm = configuring my=20 first routed subnet on the TCHub and can't quite figure out what I'm = doing=20 wrong.  </SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D010154603-01101999></SPAN></FONT><FONT=20 face=3DArial size=3D2><SPAN = class=3D010154603-01101999></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>I have = a Ascend P50=20 dialing in via ISDN with radius attributes of:</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D010154603-01101999>   =20 Framed-Address =3D 208.150.95.241</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D010154603-01101999>   =20 Framed-Route =3D 208.150.95.240/29 208.150.95.241 1</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999>After connecting, I can ping the ether = address of the=20 TCHub (208.133.28.51) from any of the subnet hosts can't ping anything = past=20 it.   I can't ping any host on the subnet from the = TCHub.  Below=20 is the output from the show ip network = command.</SPAN></FONT></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN = class=3D010154603-01101999>HiPer>> show=20 ip network test-ip-I4586</SPAN></FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>SHOW = IP =20 NETWORK test-ip-I4586=20 SETTINGS:<BR>Interface:        &n= bsp;           &nb= sp;           =20 slot:14/mod:2<BR>Network=20 Address:          &nbsp= ;            =    =20 208.150.95.241/H<BR>Frame=20 Type:           &n= bsp;           &nb= sp;       =20 PPP<BR>Status:         &nbsp= ;            =             &= nbsp;=20 ENABLED<BR>Reconfigure=20 Needed:           =              = FALSE<BR>Mask:         &nbsp= ;            =             &= nbsp;  =20 255.255.255.255<BR>Station:       &nbs= p;           &nbsp= ;            =   =20 0.0.0.0<BR>Broadcast=20 Algorithm:          &nb= sp;           =20 IETF<BR>Max Reassembly=20 Size:           &n= bsp;          =20 3464<BR>IP Routing=20 Protocol:          &nbs= p;           =20 NONE<BR>IP Routing=20 Metric:           =             &= nbsp;=20 1<BR>RIP Interface Export=20 Metric:           =    =20 0<BR>IP RIP Routing Policies:<BR>IP RIP Authentication=20 Key:<BR>HiPer>></SPAN></FONT></DIV> <DIV><SPAN class=3D010154603-01101999> <P><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999></SPAN></FONT> </P> <P><FONT face=3DArial size=3D2><SPAN = class=3D010154603-01101999>I'</SPAN></FONT><FONT=20 face=3DArial size=3D2><SPAN class=3D010154603-01101999>m pulling my hair = out trying to=20 figure out what I've done wrong.  A kick in the right direction = would be=20 greatly appreciated.</SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999></SPAN></FONT> </P> <P><FONT face=3DArial size=3D2><SPAN=20 class=3D010154603-01101999>Thanks,</SPAN></FONT></P> <P><FONT face=3DArial size=3D2><SPAN class=3D010154603-01101999>Robb=20 Bryn</SPAN></FONT></P></SPAN></DIV></BODY></HTML> ------=_NextPart_000_000A_01BF0BA2.6EE25F40--

Messages