- USR-TC - mailman.xmission.com

(usr-tc) SNMP went away...
by Charles Sprickman 17 Feb '00

17 Feb '00

Ever since I upgraded my HiPer ARC, snmp didn't work, so I started poking around... The last release I had seemed to have it on by default, whereas this one (4.2.32-1) seems to not; although it did allow me to script my additions of communities and whatnot without any complaints. So I did a "add netWORK seRVICE snmp serVER_TYPE snmpd enABLED yes". But was still unable to get any data. Looked at it, and it showed this status: HiPer-1>> list network SERVICES CONFIGURED NETWORK SERVICES Server Admin Name Type Socket Close Status snmp SNMPD 161 FALSE DISABLED tftpd TFTPD 69 FALSE ENABLED telnetd TELNETD FALSE ENABLED Issued "enabLE netWORK serVICE snmp", and it still says "disabled". What am I missing here? The manual makes no mention of doing anything beyond adding the service and even states it should be enabled by default when added... Any clues? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork(a)inch.com access(a)inch.com | = =----------------= - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

10 22

(Fwd) (usr-tc) l2tp tunnel authentication secret
by Kalev Nurklik 17 Feb '00

17 Feb '00

Hi. Can anybody help me with this? To clarify - 1. When I define the tunnel user on HARC the "system transmit authentication name" will be used as the l2tp tunnel authentication secret. 2. When I configure an l2tp tunnel user on a radius server then the "system transmit authentication name" won't be used. The HARC gets all the attributes but won't use the secret opposed to what is written in the "Hiper ARC product reference" subsection "Configuring an L2TP Tunnel on a RADIUS Server". Any ideas what I'm doing wrong? Regards, ------- Forwarded message follows ------- From: "Kalev Nurklik" <kalev(a)mail.lbi.ee> Organization: Delfi Online To: usr-tc(a)lists.xmission.com Date sent: Wed, 9 Feb 2000 16:10:57 +0200 Subject: (usr-tc) l2tp tunnel authentication secret Send reply to: usr-tc(a)lists.xmission.com Hi. What's the radius attribute for l2tp tunnel authentication secret? Tunnel-Hostname (from HARC product reference) or Tunnel-Auth-Hostname in USR dictionary does not seem to work. Neither does Tunnel-Password or other similar attributes. I have tried different attributes but with no success whatsoever. All the time I get "Could not get password from radius" from l2tp debug output. Maybe I got wrong attribute numbers but I doubt that because I checked all of them with "mon radius". On the other hand "mon radius" is not be very reliable as I found out - inconsistencies with USR dictionary names (similar but not exact) and not reporting right values for at least one attribute - Tunnel-Security. When I define a local HARC user with "set tunnel user ... password etc." then the l2tp tunnel secret is equivalent to the "system transmit authentication name" and authenticating works. For the radius equivalent HARC product reference just states dryly - "You can also set this from RADIUS by using a VSA"(page 180). So what's the VSA? Or am I missing something else? One thing that I noticed is that when I use radius defined tunnel account then there is no challenge AVP present in SCCRQ from LAC(HARC) and if I turn off the tunnel authentication on the LNS then l2tp tunneling works. I guess I need to turn off authentication on LNS because HARC has no clue about what the secret might be and just drops the connection attempt with l2tp debug message "Unauthenticated message from remotehost" when the LNS presents the challenge AVP in SCCRP. With local HARC user there's always an challenge AVP in SCCRQ from LAC and as I stated before authenticating works... This (I guess again) is probably due to HARC knowing what the tunnel secret is for that user e.g. the "system transmit authentication name". So obviously there something missing or wrong with the radius defined user. Anyone have any ideas what that something might be? Regards, __________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik(a)online.ee http://online.delfi.ee - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. ------- End of forwarded message ------- __________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik(a)online.ee http://online.delfi.ee - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) strange MPIP problem
by Mark Thornton 16 Feb '00

16 Feb '00

I ran into a strange MPIP problem and wanted to see if anyone else has experienced this. Yesterday I decided to move the mpip server from my primarily ISDN chassis to one of my dialup chassis with less traffic. The modem MPIP clients were fine, but ISDN clients using the NetGear router began having trouble authenticating. A PPP monitor of the connection showed that it stalled for 10-15 seconds after receiving the username/password packet, then requested a disconnect. Other ISDN clients were working just fine. The problem continued through the night as more clients using the NetGear called to complain. I went back and reversed out the only change I had made in the dialup system and they were immediately able to log in. What impact could MPIP have during the login process? It was the initial channel that was failing, not the bundle. Mark Thornton San Marcos Internet, Inc. 512-393-5300 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) RIP problem after renumbering
by Mark Thornton 16 Feb '00

16 Feb '00

We are moving to a new ip address block and this is causing problems with my cisco router. Specifically, when I specify "network 63.90.208.0" in the router rip configuration it creates the entry as "network 63.0.0.0" and does not pick up any of the rip routes from the chassis's I have moved. The chassis's themselves see the rip routes from the other chassis's in the same class C, but not the those in the old class C block. I'm sure I'm doing something wrong, but it eludes me at the moment. Can anyone help? Mark Thornton San Marcos Internet, Inc. 512-393-5300 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

3 3

Re: (usr-tc) TC on Merit radius
by Campbell Simpson 15 Feb '00

15 Feb '00

We're using merit and TCHs. It's quite easy to get it going straight off. I can't remember having any real drama to get it to work. I suppose all you would really want is an up to date dictionary file of TCH attributes to minimise head aches Campbell - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) FS: Hiper Bundles, DSP's
by Steve Rivera 14 Feb '00

14 Feb '00

All equipment guaranteed. 2- USR Hiper Bundles Complete in High Density Chassis $8500 4- USR Hiper DSP's $3400/set NAC/NIC 4- USR NMC V90 $800 2- USR Hiper ARC's $2000 7- Dual T1/E1 $600 10- NMC non v90 $600 More inventory than listed...just being polite. If interested in pieces, parts, powers supplies, Complete working units...I have them. "Your USR Robotics Source" Quality Pre-Owned Equipment Steve Rivera 732-433-5890 24Hotline 732-833-2111 Office .................................................... Worldwide Provider of Network Hardware Since 1981. Steve Rivera - sales(a)wrca.net v-732-833-2111 Office I'm always available for your call...732-433-5890 24Hr http://www.ISP-NetworkHardware.com or http://www.wrca.net Cisco, Ascend, Livingston, USR, Microcom, Motorola Computone, Kentrox, Adtran...and more - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

RE: (usr-tc) Man are ARC's FAST! Another bug?
by Blake Fithen 13 Feb '00

13 Feb '00

Do a "save all" then check the CPU. This is on a fully loaded chassis (15 DSP's, 1 ARC - 2.0.51 / 4.1.59 - 6) with 233 active users: CPU Utilization: Instantaneous : 0% Last Minute : 0% Last Hour : 0% Last Day : 0% tpk-32.7> save all Saving ........SAVE ALL Complete tpk-32.7> sh cpu ut CPU Utilization: Instantaneous : 100% Last Minute : 28% Last Hour : 0% Last Day : 0% tpk-32.7> tpk-32.7> sh cpu ut CPU Utilization: Instantaneous : 100% Last Minute : 28% Last Hour : 0% Last Day : 0% tpk-32.7> tpk-32.7> sh cpu ut sh cpu ut CPU Utilization: Instantaneous : 81% Last Minute : 52% Last Hour : 0% Last Day : 0% tpk-32.7> tpk-32.7> sh cpu ut etc... blake > -----Original Message----- > From: Paul Farber [SMTP:farber@admin.f-tech.net] > Sent: Thursday, February 10, 2000 10:01 PM > To: usr-tc(a)lists.xmission.com > Subject: (usr-tc) Man are ARC's FAST! Another bug? > > Check this out: > > CPU Utilization: > Instantaneous : 0% > Last Minute : 0% > Last Hour : 0% > Last Day : 0% > > > System Date ( Time in GMT ) 29-JAN-1997 23:00:38 > System UpTime: 30d 10:41:37 > > This is on a 205 port chassis running 2.0.51, 4.1.29. > > Go 3Com! > > Paul Farber > Farber Technology > farber(a)admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

RE: (usr-tc) CT1 problem / Line Coding Errors
by Richard Gamberg 12 Feb '00

12 Feb '00

-> -----Original Message----- -> From: owner-usr-tc(a)lists.xmission.com -> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ronald Kushner -> Sent: Saturday, February 12, 2000 3:21 PM -> To: usr-tc(a)lists.xmission.com -> Subject: Re: (usr-tc) CT1 problem / Line Coding Errors -> -> -> Charles Sprickman wrote: -> > -> > On Sat, 12 Feb 2000, Terry Kennedy wrote: -> > -> > > Is this really true? That CT1's are more prone to problems -> > > than PRI? -> > -> > What was very confusing about the statement (and not true) is -> there was an -> > implication that CT1s performed worse when there were line coding -> > mismatches somewhere in the chain. It wasn't my intention to imply that CT1s will perform worse when there are line coding mismatches somewhere in the chain.... However, I didn't explain why I said that CT1 is the first ingredient in a recipe for 56k trouble: and, the answer is: RBS. CT1 means you've got an RBS link between your equipment and the telco. If there is any other RBS link in the call path to the customer (ie, SLC, remote office trunks, etc.) decent 56k connections may be impossible unless the RBS links align - a 1-in-6 chance. 56k client modems are supposed to be handle multiple RBS links, but they often do not. Aloha, Richard http://808hi.com/56k/ 56k=v.Unreliable - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

RE: (usr-tc) CT1 problem / Line Coding Errors
by Richard Gamberg 12 Feb '00

12 Feb '00

[My earlier attempt to post regarding this subject didn't make it due to using different smtp server] -> -----Original Message----- -> From: owner-usr-tc(a)lists.xmission.com -> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mark Thornton -> Sent: Friday, February 04, 2000 12:19 PM -> I am having a problem on three incoming CT1's that are -> terminated by the T1 -> card to quad modems. We are seeing "bipolar violations", "code violation -> errors", and "bursty errored seconds". The telco has looked into the hdsl -> carrier and it shows no errors. Neither does the central switch. > I began looking for problems when the number of people -> complaining about not -> being able to stay online jumped significantly today. They report the -> problem has been going on for the past two days. -> -> Does anyone have any thoughts on what these errors point to? Line coding errors? Check out the new updates to my "Line Coding Errors" page at http://808hi.com/56k/coding.htm Line coding errors may be much bigger issue than some think - can also occur in telco/clec facilities between subscriber and your switch - something you have little control over! CT1 = beginning of recipe for 56k trouble get PRI if at all possible. Aloha, Richard http://808hi.com/ 56k=v.Unreliable - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

5 4

(usr-tc) Man are ARC's FAST! Another bug?
by Paul Farber 12 Feb '00

12 Feb '00

Check this out: CPU Utilization: Instantaneous : 0% Last Minute : 0% Last Hour : 0% Last Day : 0% System Date ( Time in GMT ) 29-JAN-1997 23:00:38 System UpTime: 30d 10:41:37 This is on a 205 port chassis running 2.0.51, 4.1.29. Go 3Com! Paul Farber Farber Technology farber(a)admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1