November 1998

588 messages

« October 1998December 1998 »

Messages

Subject: (usr-tc) HiperARC / Netserver Conversion Utility
From: Dominic Ciresi <dominic_ciresi@mw.3com.com>
Date: 1998-10-06 11:02:04
Greetings, I would like to announce the following beta program offered by 3Com. We are presently developing a utility which will aide in the conversion of Netserver chasses to HiperARC. If any of you are interested, please browse to http://totalservice.usr.com and apply online for the beta program. Description of utility: This utility will automatically configure a HiPer ARC 4.1 card based on a configuration derived from an existing (running) NetServer 3.7 card. While it is known that the functionality of these two platforms do not completely overlap, it is believed that an automated process can relieve 90% of the burden of migration. The basic approach will be a 3-step process: 1.Extractor: Extract the NetServer configuration from a series of show screens. The configuration will be stored in a binary file on the application client machine. 2.Translator: Derive a set of HiPer ARC CLI configuration commands from the extracted NetServer configuration. The mapping between the NetServer configuration parameters and the HiPer ARC CLI command set 3.Configurator: Configure the target HiPer ARC network parameters (through the NMC) and apply the derived configuration commands. Available on Solaris 2.5.1, Windows 95/NT. The ArcSwitcher gets the configuration data from the NETServer by establishing a telnet session to the card (using the !root user) and issuing a series of CLI show commands and capturing/parsing the returned data. This information is translated into a series of HARC CLI commands which are "pushed" to the HARC card over another telnet session (using the adm user), i.e.: 1.ARC Switcher strips data from the NETServer Card 2.Remove card and places a HARC into the chassis 3.HiPer ARC is "primed" by autoconfigure routine 4.ARC Switcher dumps NETServer data to HARC The HARC is autoconfigured (step 3 above) with a network address using the following procedure: 1.Set autoconfiguration parameters for the HARC via the NMC 2.Turn on autoconfiguration on the NMC 3.H/W reset the HARC 4.Turn off autoconfiguration on the NMC Feedback we are looking for: At this point we are mostly interested in hearing feedback on: 1.Installation problems 2.Fatal execution problems 3.Translation mistakes or omissions The intent of the ArcSwitcher is that we automate transition between the NETServer and HiPer ARC as much as possible, while at the same time pointing out areas which cannot be converted or handled automatically. It would be good to keep an eye out for any failed commands during the HiPer ARC configuration step of the transition process. These errors show up in the log file and are noted as having occurred by the top level arcswitch or arcswitch.pl script. Ideally these errors should not occur at all. Warnings regarding the translation phase are detailed in the translator.log log file. It is probably prudent for the user to read through this log to take note of any limitations related to the translation.
Subject: (usr-tc) Accounting and Radius problem...
From: Rick Payne <rickp@ops.netcom.net.uk>
Date: 1998-10-06 17:22:27
Dragan D. Vecerina writes: > Hi, > Is there any workaround or suggestions for loss of accounting records > from HiperArc Card (4.1.11). > Problem is that it doesn't send (sometimes) ACCT OFF information > to radius server when user disconnect. Indeed, and does this explain why the ARC loses track of how many IP's its assigned from the pool? On one of ours today, we had no-one connected, but it still reckoned 2 IP's from the pool were in use. *sigh*. Rick
Subject: Re: (usr-tc) Pt to Pt Test Link
From: Mark Lemmert <techmgr@athenet.net>
Date: 1998-10-07 16:14:00
>I'd like to setup a in-house 56k line that would be just to test some >compression ideas. I'm trying to avoid installation fees if I can help it >just to test. Can I set up something using 2 56k CSU's and routers? If >not, is there a cheap box that I can buy that I can set this up with to >test? >______________________________________________________ >Thanks, >Greg Coffey 307-234-5443 Fax 307-234-5446 >CoffeyNet v.90 56k Access for Casper & Douglas >142 S. Center St. >Casper, WY 82601 http://www.coffey.com If you made an cat5 cable /w RJ45 ends with a special wiring scheme you can simulate make the two CSUs talk as though you had a telco circuit between them. See your CSU manual to find out which pins are for transmit/receive and tip/ring. You will want to have the transmit/tip matched with the receive/tip on the other end and the transmit/ring matched with the receive/ring on the other end. Hope this helps. Mark Lemmert techmgr@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net
Subject: (usr-tc) DS0 <-> Modem Config?
From: Staff Andrew Champion <champs@prairie.lakes.com>
Date: 1998-10-08 17:09:36
A Cisco AS5100 unit (more or less a 3CTC Chassis with Cisco cards) has been dropped on my lap, and I have a somewhat confusing problem: When connected dialling an analog line, the modem responds, authenticates, and (could presumably) enter PPP mode. When dialling the T1 number (these are x2/V.90 modems), there is no response -- only a brief pause, then a fast busy signal. The telco providing the T1 has never done such a circuit before -- could the problem be there? When going to Programmed Settings (for T1 card) > DS0 <-> Modem Configuration, I cannot assign a modem to the slots -- Get returns nothing, the modem cells are white, indicating that they are unavailable, but the DS1 channels are aqua, indicating available. How do I make these modems available? Have I missed a setting? This is what I need to associate each modem to its own timeslice, correct? BTW, I'm using TCM 5.5.1 ________________________________________________ Following the help file given, I'm supposed to select a cell for the modem and a trunk on the T1, then press Connect. It does nothing. Of course, according to the help file legend, *gray* indicates unavailable, which disagrees with the visual legend... _-~=_-~=_-~=_-~=_-~=_-~=_-~=_-~=_-~=_-~= Andrew Champion andrew@lakes.com 507.386.0408 Lakes Internet 888.386.0444 :-_=:-_=:-_=:-_=:-_=:-_=:-_=:-_=:-_=:-_=
Subject: (usr-tc) Excessive data transferred / DNS resolution
From: david.perrin@mnco.com
Date: 1998-10-13 14:20:32
Working with the TCS 3.5 release using the Hiper ARC version 4.1.11 , I'm running into a couple of significant issues. We are currently using a NetServer card in production and are planning to move to the Hiper ARC card in a new chassis, but I'm having the following problems: 1. There's an excessive amount of data transferred during a session with the Hiper ARC card versus the Netserver card connection. It's on order of 5 times the data transferred with a Hiper ARC connection versus the Netserver connection. 2. DNS connectivity is acting strangely. DNS seems to be active and working OK when telnetted into the Hiper ARC console itself. The problem occurs when attempting to use DNS via a Windows 95 session connected remotely via PPP. For example I can ping a DNS host name successfully, when using the hostname along with the domain name (ie. abcdef.corp.mnco.com), but receive a Bad IP address response when trying to use the the hostname (ie. abcdef) . The DNS domain name is set properly on the server and as I said earlier I can sucessfully use DNS with just a hostname when telnetted into the Hiper ARC card. Any ideas or suggestions would be helpful...
Subject: (usr-tc) using round robin & fixed assignment
From: Taino d Johnston <usr-list@accesscom.com>
Date: 1998-10-14 16:23:22
We recently switched telcos, which then switched us from channelized T1 lines to PRI lines. The telco switch was from PacBell to ICG. Upon switching we found ourselves facing a lot of problems, however, it was this last problem that we felt was quite strange and worth noting. In order to do some tests with the new service, we changed the configuration of our equipment from 'round robin' to 'fixed assignment'. After we thought the experienced problems were corrected we started getting reports of busy signals -- during time periods when there were modems available. The problem turned out to be that the PRI lines were resetting faster than our modems were. Essentially, this meant calls would be routed back down to a newly opened line on the PRI but would hit a modem that had not been reset. Our testing found that we were giving busy signals out about 20% of the time. Switching back to 'round robin' seems to have since corrected the problem and we have not given out any more busy signals. What I am trying to find out is why when configured for 'fixed assignment' we were giving out busy signals? The problems went away once we switched to 'round robin'. We are running a few TC chassis containing Quad Digital & Digital/Analog modem cards with PRI lines. All our Quad modem cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the current versions of the software. Taino Johnston Manager, Technical Support Access Internet Communications +----------------------------------------------------------------+ | Taino d Johnston | Phone: (408) 777-8190 | | Manager, Technical Support | Tech Support: (408) 342-0551 | | | Fax: (408) 777-8191 | | Access Internet Communications | http://www.accesscom.com/ | | tdj@accesscom.com | support@accesscom.com | +----------------------------------------------------------------+
Subject: (usr-tc) V.90 is it safe to put on non-hyper dsp Total Control
From: Mike Hamrich <mhamrich@drfast.net>
Date: 1998-10-14 23:25:13
It's been a while since I have seen a V.90 post. Any advice for taking a X2 enabled year and a half old 2.5.X release Total Control unit up to V.90 successfully? The one thing I did hear was to reset modem to factory default. Have not read if you need to upgrade in steps with new then what in the unit but older then what current. If you need to put interim release on. How do you get them? If this has been covered. Please point me to an archive. Thanks Dave Winston Support DrFast.Net, Inc.
Subject: (usr-tc) ISDN: Netserver vs. Modems
From: Mark Lemmert <cto@athenet.net>
Date: 1998-10-15 15:58:33
Currently I am terminating the ISDN calls on the Netserver (I-ports) and am having problems with routes getting 'jammed' in the system for ISDN callers with static addresses. Essentially what happens is sometimes the caller will disconnect from a Netserver and the route for their static IP won't be flushed out, so they won't be connected but the route will remain. The client will then connect to a difference Netserver and a new route will be created on that server. I am broadcasting the routes via RIP so the border routers end up with two routes for the clients static IP when this happens and the client has problems. 3com has suggested that I terminate the ISDN calls on the quad modems instead of on the Netserver to solve this problem. Has any body else had this problem? Can anybody give an opinion on whether 3coms suggested fix is likely to have an affect on this? Thanks! Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net
Subject: (usr-tc) Filters for local users on HARC
From: Alex Substanley <das@gol.com>
Date: 1998-10-19 18:08:19
Hi, I'm trying to setup filters for local users rather than interfaces on a HipeARC running version 4.1.11. I've looked through the previous messages in this list, but couldn't find the information. Could just be me :) I've set up two filters test.in and test.out on the HARC, I've added them and they verified without any problems. I've turned filter_access to on to use with user specific filters (according to the documentation) I've also assigned the filter to the user, but it doesn't seem to be binding the filter to the user so far as I can tell. When I changed the filter to interface instead of user, it seemed to work fine. I'm sure that this has been addressed in previous messages, but if anyone can shed some light on this... The filter I am using for the incoming filter is a simplified filter I am using for testing. I expect that this filter will block everything, but it appears that the user retains full access. #filter IP: 005 REJECT src-addr=<ip address>; 010 DENY; and when I display the user info. I get this: INFORMATION FOR USER: <userid> Status: INACTIVE Type: NETWORK Expiration: NONE Message: (D) Phone Number: (D) Alternate Phone Number: (D) Input Filter: test.in Output Filter: test.out Modem Group: all (D) Session Timeout in seconds: 0 (D) Idle Timeout in seconds: 0 (D) Tap Status: DISABLED Tap Format: ASCII Tap Output: SYSLOG Tap Facility: INVALID Tap Loglevel: CRITICAL Tap Address: 0.0.0.0 (D) Chat Script Name: -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ____________________________________________
Subject: (usr-tc) Filters for local users on the HARC
From: Alex Substanley <das@gol.com>
Date: 1998-10-20 20:59:30
Hi, I'm trying to setup filters for local users rather than interfaces on a HipeARC running version 4.1.11. I've looked through the previous messages in this list, but couldn't find the information. Could just be me :) I've set up two filters test.in and test.out on the HARC, I've added them and they verified without any problems. I've turned filter_access to on to use with user specific filters (according to the documentation) I've also assigned the filter to the user, but it doesn't seem to be binding the filter to the user so far as I can tell. When I changed the filter to interface instead of user, it seemed to work fine. I'm sure that this has been addressed in previous messages, but if anyone can shed some light on this... The filter I am using for the incoming filter is a simplified filter I am using for testing. I expect that this filter will block everything, but it appears that the user retains full access. #filter IP: 005 REJECT src-addr=<ip address>; 010 DENY; and when I display the user info. I get this: INFORMATION FOR USER: <userid> Status: INACTIVE Type: NETWORK Expiration: NONE Message: (D) Phone Number: (D) Alternate Phone Number: (D) Input Filter: test.in Output Filter: test.out Modem Group: all (D) Session Timeout in seconds: 0 (D) Idle Timeout in seconds: 0 (D) Tap Status: DISABLED Tap Format: ASCII Tap Output: SYSLOG Tap Facility: INVALID Tap Loglevel: CRITICAL Tap Address: 0.0.0.0 (D) Chat Script Name: -- ____________________________________________ Alex Substanley Global OnLine Japan Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ____________________________________________
Subject: (usr-tc) PRI vs T1 ?
From: Robb Bryn <robb@cape-fear.net>
Date: 1998-10-21 09:04:21
This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BDFCD1.CA8ACB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are looking at expanding our current line count (which is using H-DSP = cards with PRI lines) and are faced with a small dilema. We have always = used PRI lines in the past for our incoming lines and are now pricing = PRI vs T1. In our area T1's are priced about $600/month cheaper than a = PRI. Aside from PRI's being easier to setup, I've caught rumors that = T1's are not as fast as PRI (when considering a v.90 call & all other = factors are equal). I have only one question... are these rumors true? Thanks Robb Bryn ------=_NextPart_000_0004_01BDFCD1.CA8ACB60 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.3510.1400"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2> <P>We are looking at expanding our current line count (which is using = H-DSP=20 cards with PRI lines) and are faced with a small dilema. We have always = used PRI=20 lines in the past for our incoming lines and are now pricing PRI vs T1. = In our=20 area T1's are priced about $600/month cheaper than a PRI. Aside from = PRI's being=20 easier to setup, I've caught rumors that T1's are not as fast as PRI = (when=20 considering a v.90 call &amp; all other factors are equal). I have only = one=20 question... are these rumors true?</P> <P>Thanks</P> <P>Robb Bryn</P></FONT></DIV></BODY></HTML> ------=_NextPart_000_0004_01BDFCD1.CA8ACB60--
Subject: (usr-tc) Interested in Linux on the Netserver?
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-21 21:52:47
I'd like to get a show of hands, so to speak, for everyone interested in Linux on the Netserver. If you are interested, please send the message `subscribe' to lon-request@datasys.net I see this as a relatively important venture that's good for every Netserver user. And this venture is good for 3Com, too -- it will provide an extended lifetime to those of us who plan to stick with our Netservers, and will make 3Com the first vendor I know of with an open-source high-density telecom system. That, friends, is a radical step forward. We're talking about a fresh start for the TC Netserver. --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607x200, Fax: 912.241.0190 (US)
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-22 00:09:40
At 12:09 AM 10/22/98 -0400, Mark R. Lindsey wrote: >I'd like to get a show of hands, so to speak, for everyone interested in >Linux on the Netserver. If you are interested, please send the message >`subscribe' to > LON-request@datasys.net a list? so soon? ok, I'll subscribe to see what's up. But here is my .02 on the subject.. Lets say you get USR to cooperate (1st feat). Then you get linux up on the netserver (2nd feat). What if Quake still lags? I mean Quake Lag is a symptom of a much bigger problem. And it might be hardware related and that has been hinted at. So if someone was able to pull off both these feats and our customers still bitched, it would not do us much good and we would still use 100% arcs, albeit more regretfully.. Of course if there are any real hardware limits, they could be minimized and dealt with so udp performance would be as good or better than it is now, which is good enough for many.. just not us I suppose.. We house alot of Quake players.. How about getting 3COM to give us specs and info on HiperARC's too while you're at it.. ;-> Allen
Subject: (usr-tc) Radius Accounting Problems
From: rbryn@cape-fear.net
Date: 1998-10-22 11:23:30
I have a problem with Radius Accounting packets reporting the wrong NAS port. When the Radius server recieves a packet for authentication it will report the correct NAS port but when it sends the Accounting start/stop packet it always reports NASPort=1. This problem only seemed to occur after upgrading TCS 3.3 Config is: Total Control Chassis w/ NMC v5.5.5 HARC v.4.1.11 Hiper DSP v.1.2.5 Radius = IEA Software's RadiusNT v2.5 Thanks Robb Bryn
Subject: Re: (usr-tc) Problems with brackets in session_start_message
From: Rick Payne <rickp@ops.netcom.net.uk>
Date: 1998-10-26 15:45:44
Mike Wronski writes: > Have you tried escaping the '(' with back slashes?? Yes. > set slip session_start_message "SL/IP session from \(%server_ip\) to > %client_ip beginning..." I entered it as above. Same thing: SL/IP session from ( 194.42.231.28 to 255.96.0.0 beginning.. (assuming I don't need to relaod after setting the parameter). Code is 4.1.78 on the HiperARC. Rick
Subject: (usr-tc) HELP: need to route IP addresses to a customer over TC Hub
From: C Thompson <cthompson@wingnet.net>
Date: 1998-10-30 17:22:56
We have not had to do this before, but I need to route a Class C address across an ISDN connection on a USR/3com Total Control hub to one of our customers. Also, for future reference, it would be helpful to know what to do for a subnet as well. Can anyone provide helpful pointers on what I need to do 1) in RADIUS 2) in the TC Hub (if anything) 3) in my router 4) anything else? Thanks for any help you can offer. If you reply to the list, please also e- mail me privately, too, as it's the weekend. Thanks, Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Thought for the day: Concerto (n): a fight between a piano and a pianist.
Subject: (usr-tc) Ascend version 7 contains anti-spoofing code, 3com?
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-01 07:25:47
Ascend now has both a global switch you can throw to check incoming packets source addresses against the assigned address and a radius RADIUS attribute to do it on a per-session basis. How hard can this be? Why isn't it in 3com products? -- Aaron Nabil
Subject: Re: (usr-tc) Ascend version 7 contains anti-spoofing code, 3com?
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-01 10:41:20
|o| Ascend now has both a global switch you can throw to check incoming |o| packets source addresses against the assigned address and a radius |o| RADIUS attribute to do it on a per-session basis. |o| |o| How hard can this be? Why isn't it in 3com products? no kidding ... one solution is to use the super cool radiator radius server from http://www.open.com.au and use it to dynamically build filters for a hiperarc-based system ... failing that, i don't think you have any other options ;( this is definetly something that people should demand from nas vendors |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: Re: (usr-tc) Ascend version 7 contains anti-spoofing code, 3com?
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-01 13:04:05
: |o| Ascend now has both a global switch you can throw to check incoming : |o| packets source addresses against the assigned address and a radius : |o| RADIUS attribute to do it on a per-session basis. : : no kidding ... one solution is to use the super cool radiator : radius server [...] : this is definetly something that people should demand from nas : vendors A knob is nice, but don't forget that we *can* solve the problems without their help. I would prefer that they let us solve such problems in higher layers (e.g., with Radiator); the alternative is for them to complicate their code. In general, problems should be solved at as high a layer as possible. I want high-quality bolts from 3Com: leave the bridge-building to me.
Subject: Re: (usr-tc) Ascend version 7 contains anti-spoofing code, 3com?
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-01 13:19:52
|o| A knob is nice, but don't forget that we *can* solve the problems |o| without their help. I would prefer that they let us solve such problems |o| in higher layers (e.g., with Radiator); the alternative is for them to |o| complicate their code. |o| |o| In general, problems should be solved at as high a layer as possible. |o| I want high-quality bolts from 3Com: leave the bridge-building to me. this is a very interesting way of looking at things, i hadn't considered it this way, and i like it. thanks! |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: (usr-tc) DS1 MIB support for HDMs
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-01 20:34:05
Howdy, Has anyone read if the HDMs (HiPer DSPs) will support the DS1 MIB? They don't seem to now, or, at least, one of my NMCs doesn't think so. Is there something else I should be using to monitor for alarms and line conditions? Thanks. --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC
Subject: Re: (usr-tc) Ascend version 7 contains anti-spoofing code, 3com?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-01 21:16:26
bryan s. blank was heard to say: > >|o| A knob is nice, but don't forget that we *can* solve the problems >|o| without their help. I would prefer that they let us solve such problems >|o| in higher layers (e.g., with Radiator); the alternative is for them to >|o| complicate their code. >|o| >|o| In general, problems should be solved at as high a layer as possible. >|o| I want high-quality bolts from 3Com: leave the bridge-building to me. > > this is a very interesting way of looking at things, i hadn't > considered it this way, and i like it. thanks! That's why I like 3Com's RADIUS server so well... I have complete control over how each radius packet is handled. --Ricky
Subject: Re: (usr-tc) DS1 MIB support for HDMs
From: Charles Sprickman <spork@inch.com>
Date: 1998-11-02 01:32:48
On Sun, 1 Nov 1998, Mark R. Lindsey wrote: > Has anyone read if the HDMs (HiPer DSPs) will support the DS1 MIB? > I'm a little foggy on how I found this, but David Bolen pointed me in the right direction. In a little test program I was futzing with I polled this entry to get line status on the HDMs: $oid=".iso.org.dod.internet.private.enterprises.usr.nas.rds1.usrds1StatT able.usrds1StatEntry.usrds1StatE1PhysicalState" This is from one of the usr mib files... Charles > They don't seem to now, or, at least, one of my NMCs doesn't think so. > Is there something else I should be using to monitor for alarms and > line conditions? > > Thanks. > > --- > Mark R. Lindsey, mark@datasys.net > Internet Engineering, DSS Online LLC > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
Subject: (usr-tc) HELP: need to route IP addresses to a customer over TC
From: C Thompson <cthompson@wingnet.net>
Date: 1998-11-02 08:31:10
We have not had to do this before, but I need to route a Class C address across an ISDN connection on a USR/3com Total Control hub to one of our customers. Also, for future reference, it would be helpful to know what to do for a subnet as well. Can anyone provide helpful pointers on what I need to do 1) in RADIUS 2) in the TC Hub (if anything) 3) in my router 4) anything else? Thanks for any help you can offer. If you reply to the list, please also e- mail me privately, too. Thanks, Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Thought for the day: O, give thanks unto the Lord for He is good, for His mercy endureth forever.
Subject: (usr-tc) NetServer/16 I-Modem Plus for sale
From: TieUs System Administrator <admin@tieus.com>
Date: 1998-11-02 12:40:16
This is a multi-part message in MIME format. ------=_NextPart_000_00AC_01BE065D.F1B097C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Friends: We have a NetServer/16 I-Modem Plus for sale. We have this machine = in about March, so this machine is about 7 month old. We only used it = for about 2 month for testing our VPN usage. Since now we are using = HyperArc as our enterprise solution, We want to get rid of the = NetServer/16 I modem. It is X2 enabled and V.90 code will release on = January, 1999 (according to 3com site) I will try to sell it at about US$5000 obo. (please dont flame me = for the price, I did not get any idea with what is a reasonable price = for that now, we bought it at around US$9000., the list price is $9999.) = If you are interested or having any question about it please give me = an e-mail.
Subject: (usr-tc) Y2K Patches
From: Budi Wiyono <budiw@idola.net.id>
Date: 1998-11-02 14:05:16
Dear All, I have problem with my Netserver Card and NMC Card. Those device did not pass minimum requirement for Y2K Compliant. Is this following correct minimum requirement for Y2K version ? 1. QuadModem minimum code: 5.5.x atau 5.6.x 2. NMC minimum code: 5.0.x (mine: 4.2.2) 3. Netserver Card minimum code: 3.4.x (mine 3.1.7) Are there patches for those card ? -TOTAL CONTROL NETSERVER PRI CARD SET (ETHERNET) -NETSERVER CARD What another action should we do, if our USR device didn't pass minimum requirement for Y2K version ? Thanks, Budiw
Subject: Re: (usr-tc) Ascend version 7 contains anti-spoofing code, 3com?
From: Kurtiss Johnson <kurtiss_johnson@mw.3com.com>
Date: 1998-11-02 14:19:34
Keep your eyes open for HiPer ARC v4.2, which has similar functionality in a feature called Source Address Assurance. It also operates either via global config or via a per-user RADIUS profile setting. Kurtiss Johnson Product Manager - Access Routers 3Com Corporation - Carrier Business Unit 847-222-2279 Aaron Nabil <nabil@spiritone.com> on 11/01/98 09:25:47 AM Please respond to usr-tc@lists.xmission.com cc: (Kurtiss Johnson/MW/US/3Com) Note: Some recipients have been dropped due to syntax errors. Please refer to the "$AdditionalHeaders" item for the complete headers. Ascend now has both a global switch you can throw to check incoming packets source addresses against the assigned address and a radius RADIUS attribute to do it on a per-session basis. How hard can this be? Why isn't it in 3com products? -- 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: (usr-tc) Low Connections/Disconnects
From: Chad J. LaFrenz <clafrenz@rof.net>
Date: 1998-11-02 15:38:47
Hello All-- We have 5 Total Controls (NetServer and Quads) running these code versions: T1: 3.5.0 SS Quads: 5.10.9 NetServer: 3.8.1 NMC: 5.4.95 Settings are default except for the following: Carrier Loss Delay: 20 Transmit Level: 13 DTE Rate Mode: fixed Transmit Flow Control: hardware Hardware Flow Control: dataOnRtsHigh Default DTE Data Rate: bps57k Packet Bus Answer Only: enable All Results codes enabled. All the hubs have E&MTypeII T1's pulled into them. Problem: Users complaining of low connection rates and disconnects. What I have experienced: Normally I connect from my home with a Sportster Voice Internal at 49K. When I have problems it is when I hear the normal connection tones and then right before it would normally connect I hear a double "bong" sound. It then connects and shows me my DTE rate and not the actual connection rate (which means to me it is a non-listed connection speed in my windows inf file). Checking the chassis and port that I am on and it shows that I am connected at 24k-16.8K. I can disconnect hit another port and I am back at 49K. This is all on the same hub and happens on all our hubs. I am starting to watch specific ports to see if they consistently connect at lower baud rates; however, I just started doing this and don't have enough data to post any results at this point. On this point though, has anyone created an MRTG script (or similar) that would log connection speed results on specified hubs or ports? Thus, creating almost a database of connection logs for a specific modem? Is this even possible? Could then be used to see if a specific modem is always connecting at a lower rate when average over time. What other users have said: Disconnects happen frequently and randomly although more frequent when they are downloading a file or email attachment. Connect speeds vary from normal nice 40K+ to 9600 through 24K. Performance Manager shows zero errors when viewing the 24 Hour Total Group information. When watching the modems through P.M. the disconnect reasons are DS0 Teardown or v.42 disconnect. I have verified that all the modems on all the hubs are set to the same exact settings. When looking at connection speeds through P.M. it ranges from 9600 to 50K through out all the hubs. Guess I am at a loss and since this group has solved my last problem before 3Com even called me back I figured I would start here this time. 8^) Any suggestions would be greatly appreciated. Regards, Chad J. LaFrenz Senior System Administrator RoFIntUG V: 970-945-4920 F: 970-947-1923 Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. http://www.rof.net
Subject: (usr-tc) HiperDSP v1.2.68 fixed mysterious T1 problem
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-02 16:06:19
Our CLEC was reporting errors on spans we had attached to HiperDSP cards. These errors didn't show up with a test set watching the span, but the switch saw a constant stream of them. It seemed to be directly dependant on the incoming call rate on the span. I'm guessing it was some margin problem the T-BERD was immune to but the switch wasn't. I was just about to try and get some fancy test gear to look at the T1 stream itself, but the CLEC said the problem went away. The only changes we made recently were swapping out some cards in our M31 muxes, and the HiperDSP upgrade. So I downgraded one of the cards to 1.0.8. The error stream returned (with a vengance) on that span. So 3COM, whatever you did in 1.2.68, please don't undo it! It works! -- Aaron Nabil
Subject: Re: (usr-tc) DS1 MIB support for HDMs
From: David Bolen <db3l@ans.net>
Date: 1998-11-02 16:40:27
mark@vielle.datasys.net (Mark R. Lindsey) writes: > Has anyone read if the HDMs (HiPer DSPs) will support the DS1 MIB? They do - RFC1406. It's not the same MIB as that supported by the dual cards (which use the original - since deprecated - RFC 1232) but serves the same purpose, and it's time 3Com updated to a current version. RFC1406 superceded RFC1232 in '93 :-) There is also a replacement for the USR-specific additions to 1232. For the dual span cards, they use UDS1.MIB, whereas the HDM uses RDS1.MIB. At the DS0 level, replace DS0.MIB (dual cards) with RDS0.MIB. I'll enclose an excerpt below from some internal docs I worked up when we were adapting to the introduction of HDMs into our system that might help correlate MIBs to components. Note that you need to be running an HDM aware (16MB) version of NMC code (5.5.x) to be able to query HDM tables - the 4MB version (5.4.x) can identify the card but not support any of its tables. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - - - - - - - - - - - - - - - - - - - - - - - - -
Subject: (usr-tc) Lan to Lan routing, manual dial out works, on_demand does not route
From: Martin Oberle <moberle@gmx.de>
Date: 1998-11-02 17:41:43
Hi. I have the problem that I can dial manually to a location but dial on demand does not work proberly. Please see details below. I use an netserver card with only one PRI connected. That gives me 30 ports. There are 32 modems on 8 Quadmodem cards in the chassis. ***************************** This is the netserver: Command> ver U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.5.34 Build date: Jun 19 1997 Build time: 14:02:28 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced Licensed for 60 ports. ***************************** This is a location I want do dial to: Command> sh loc goethe Location: goethe Type: Manual Destination: 195.x.x.129 Netmask: 255.255.255.224 Protocol: PPP Options: Quiet Group: 0 Max Ports: 1 Idle Timeout: 2 minutes High Mark: 0 bytes Mtu: 1500 Async Map: 00000000 Dial Script: Send Command Wait for Reply ------------------------------ ---------------------------- -- at&f1*v2=5e1v1q0&w\r atdt09192352\r CONNECT ***************************** When I dial manually to the location, everything works ok. Modem S5 dials to the remote network. The connection is established and I can ping every machine on the remote network. Command> sh ro Destination Gateway Flag Met Interface VPN -------------------- ---------------- ---- --- --------- --- 0.0.0.0 /0 195.xx.xxx.1 NS 1 net0 0 195.xx.xxx.128 /27 195.xx.xxx.129 NLC 1 ptp5 0 195.xx.xxx.0 /25 195.xx.xxx.2 NL 1 net0 0 Command> Command> if net0: flags=8016<IP_UP,IPX_DOWN,BROADCAST> inet 195.xx.xxx.2 netmask ffffff80 broadcast 195.xx.xxx.127 mtu 1500 ptp5: flags=8125<IP_UP,IPX_DOWN,POINT_TO_POINT,PRIVATE> dest 195.xx.xxx.129 netmask ffffffe0 mtu 1500 Command> ******************************* Now I set the location to on_demand. I can see the route and the interface ptp129 in the configuration before an connection is estabished. For my understanding this in normal. But is ptp129 a valid interface when I have anly 32 Modems and 30 ISDN-cannels? ********* Command> if net0: flags=8016<IP_UP,IPX_DOWN,BROADCAST> inet 195.xx.xxx.2 netmask ffffff80 broadcast 195.xx.xxx.127 mtu 1500 ptp129: flags=8165<IP_UP,IPX_DOWN,POINT_TO_POINT,PRIVATE,SUSPENDED> dest 195.xx.xxx.129 netmask ffffffe0 mtu 1500 ************ When I ping the remote network, Modem S5 dials to the remote network and makes a connection. But as you can see below the routing table is not correct. There is only a route to the remote router, not to the network. The netserver thinks the remote network network is still on interface ptp129 an I can't ping machines on the remote network. But when you look at the interface ptp5 it shows an other netmask than it is in the routing table. So what can be wrong? Is there any other configuration necessary? (For example proxy_arp, enhanced_routing, netmasks or something like this). Or is this a known issue and a software update will fix this? Thanks. Command> sh ro Destination Gateway Flag Met Interface VPN -------------------- ---------------- ---- --- --------- --- 0.0.0.0 /0 195.xx.xxx.1 NS 1 net0 0 195.xx.xxx.129 /32 195.xx.xxx.129 HLC 1 ptp5 0 195.xx.xxx.128 /27 195.xx.xxx.129 NL 1 ptp129 0 195.xx.xxx.0 /25 195.xx.xxx.2 NL 1 net0 0 Command> if net0: flags=8016<IP_UP,IPX_DOWN,BROADCAST> inet 195.xx.xxx.2 netmask ffffff80 broadcast 195.xx.xxx.127 mtu 1500 ptp129: flags=8165<IP_UP,IPX_DOWN,POINT_TO_POINT,PRIVATE,SUSPENDED> dest 195.xx.xxx.129 netmask ffffffe0 mtu 1500 ptp5: flags=8125<IP_UP,IPX_DOWN,POINT_TO_POINT,PRIVATE> dest 195.xx.xxx.129 netmask ffffffe0 mtu 1500
Subject: (usr-tc) timeslot mapping oddity on HDSP
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1998-11-02 20:05:54
Has anyone seen this before? After several months of perfect operation, one of our HDSPs started handing out busy signals while it had plenty of modems available. Upon investigation, it turns out that timeslot #7 had been reassigned to channel #24 (instead of channel 7). Timeslot #24 was still assigned to channel #24. I'm using PRIs, so TS24 is my d-channel...and using fixed assignment, so channel #24 is never used. The question is...does anyone have any idea how this configuration bit could have been changed? *Something* caused TS7 to be reassigned to C24 from C7 after several months of trouble free operation...I'm just wondering what could have happened. Relevant notes: *chassis only allows one workstation to connect for management; At the time of the incident, the workstation was powered on, not running TCM, and the operator was asleep. (: *HDSPs are running 1.2.5 code. *chassis contains 2xHDSP, HARC, NMC, and 2xPS_70w.
Subject: (usr-tc) de-encrypting USRadius.mdb
From: Ken Hodges <ken@rabun.net>
Date: 1998-11-02 22:24:02
Pardon this if this question is already covered by the list, but I have been unable to find it if the answer is available in the database. (I'm new to this mailing list) I would like to move away from the Total Control Security and Accounting Program (RADIUS) and give Livingston's RADIUS a try. The problem is: The USRadius.mdb password list is encrypted, and with over 1000 customers this would be a major task to re-program each one. Does anyone know of a utility that would de-encrypt the passwords so that I can use them with another RADIUS program ? Thanks in advance, Ken _______________________________________ Ken Hodges, President and CEO ACME BrainWorks Internet Services, Inc. Clayton Computers, Inc. Rabun County, Georgia "Where Spring Spends the Summer" http://www.acme-brain.com or http://www.rabun.net ken@rabun.net 1-706-782-9239
Subject: RE: (usr-tc) v.90 connect problems
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-11-03 00:10:42
When we upgraded our 2059 to V.90 I had the same problem when testing with my own Sportster x2 modem. (They were early editions I purchased in bulk at a Home Shopping Liquidation center right after X2 came out.) I tried adding pauses but it didn't work. When I upgraded the Sportster firmware to V.90, the problem went away. We put a BIG banner link on our home page pointing users to the 3Com V.90 upgrade page. Many of our Sporster users took advantage of it. I also upped the "Carrier loss detect delay" from 7 to 14 which really helped the problem of disconnects immediately following connecting. We upgraded a few weeks ago. We only had one customer whose modem just would not connect well. He could only connect every 4th or 5th try at any decent speed. It was a used flex winmodem type that he had found a V.90 upgrade for. I'm convinced that modem was just not capable of V.90. After working with him for a while he ended up dumping it and buying a new Sportster. From the same Computer and phone line he is now getting 49k to 53k connects. It was kinda cool when we upgraded. We had busy signals every night for a week while users played with their new found speed. And the compliments poured in. We received numerous calls the first few days, but we just preached upgrade upgrade upgrade to the customers. We lost zero customers and gained 20+ last week alone from referrals from existing customers. As for users connecting but not able to surf, make sure they're not NT users that still have Software compression enabled. They will show as running MS compression, with plenty of CRC errors after authenticating and no bytes transfered. If you ping them you will see a few bytes output but nothing in return. Also the DNS IP addresses on the hub disapeared when I upgraded the Firmware. You might want to check that too. And the Netserver was acting flakey after the upgrade until I power cycled the whole rack. I left one Quad running x2. We've received about a dozen "You must have a bad modem" emails from people getting used to V.90. So you might find going back to X2 will generate even more calls from customers. Steve >We are having the same problems and we are finding a number of >complaints coming from customers with USR Sportsters. > >We have 4 Total Control boxes (3 with net servers and 1 Hiper >ARC) and we have postponed our plans for buying another Hiper ARC >because of these problems. The Quad modems with Net Servers are >less problematic than the Hiper DSP's with Hiper ARC. > >Some customers get very slow connections or connect fast but >can't surf. Many claim they have to dial in many times before >they get a good connection, but eventually they do. > >We are running 4.1.11 and 1.2.5, basically TCS 3.3 for all >components. Are some older versions better? Is there some Beta >code we should be trying? > >The problem is so bad we are considering going back to just X2. >We are also looking into other equipment, which would kill us >since we had become so comfortable with Total Control... > >______________________________________________ > >Mario M. Bustamante, President >AccessPro Communications Inc. >Miami, Florida > > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell >> Sent: Friday, October 30, 1998 3:40 PM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) v.90 connect problems >> >> >> Since upgrading my DSP's to 1.2.5 I've been having a >> number of customers >> with problems connecting, from plain no-connects to x2 >> or x2/v90 modems >> connecting at a slower rate than before. Otherwise on my HiPer; >> ARC 4.0.30 >> NMC 5.5.5 >> >> Some of the no-connects were LT Winmodems and the >> -v90=0 string helped, the >> others I'm waiting to hear back on modem type. >> Does DSP 1.2.6x or ARC 4.1.x seem to be helping these >> problems for anybody >> else that's been experiencing them? >> >> >> Kirk >> >> >> >> >> Kirk Mitchell-General Manager sysadmin@keyconn.net >> Keystone Connect http://www.keyconn.net >> Altoona, PA 814-941-5000 We Unlock the World >>
Subject: Re: (usr-tc) HiperDSP v1.2.68 fixed mysterious T1 problem
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-03 00:26:06
Maybe this is related to the "stuck channel" problem...? 1.2.68 DID seem to fix that for us, even though it didn't fix the v.90 connection problems everyone's reporting. It's a start. :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Mon, 2 Nov 1998, Aaron Nabil wrote: > > Our CLEC was reporting errors on spans we had attached to HiperDSP cards. > > These errors didn't show up with a test set watching the span, but the > switch saw a constant stream of them. It seemed to be directly dependant > on the incoming call rate on the span. I'm guessing it was some margin problem > the T-BERD was immune to but the switch wasn't. > > I was just about to try and get some fancy test gear to look at the > T1 stream itself, but the CLEC said the problem went away. The only > changes we made recently were swapping out some cards in our M31 > muxes, and the HiperDSP upgrade. > > So I downgraded one of the cards to 1.0.8. The error stream returned > (with a vengance) on that span. > > So 3COM, whatever you did in 1.2.68, please don't undo it! It works!
Subject: RE: (usr-tc) v.90 connect problems
From: Al Thiel <sysadmin@specdata.com>
Date: 1998-11-03 10:44:27
I have problems with USR ISDN modems on my Hipers. When they bond two channels the second channel goes up and down 3 times before finally connecting, then to add to the humiliation the bonding causes a 1 to 3 minute delay in passing data. I assume it is a RIP related issue, but then again a Falleron router works fine. I have no answers and soon will go with Lucent or Cisco as originally intended. I don't have hours to play tech support tag so I'll go with old faithful which works from the get-go. Even though I never dealt with Krish I hear he is the only reason people stay with 3com at all. Kudos to him for his ability to deal with all this nonsense. I cannot myself. At 06:41 PM 10/31/98 -0500, you wrote: >Oh good, it's not just me. :) This has been driving me absolutely crazy >for weeks now! > >We're running ARC 4.1.78 and DSP 1.2.68. As far as I can tell: > >* It only affects v.90 calls -- x2 and v.34 work fine. > >* It only affects our DSP/ARC rack, not our Quad/NETserver racks. > >* It's not specific to LT Winmodems, as I first thought. We have several >Sportster owners complaining. I haven't yet tried it with a Courier -- >that's next week's project. :) > >Anyone have ANY hints here? We've lost a customer or two over this now. > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org >VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net >Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ ># view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep > >On Sat, 31 Oct 1998, Mario M. Bustamante wrote: > >> We are having the same problems and we are finding a number of >> complaints coming from customers with USR Sportsters. >> >> We have 4 Total Control boxes (3 with net servers and 1 Hiper >> ARC) and we have postponed our plans for buying another Hiper ARC >> because of these problems. The Quad modems with Net Servers are >> less problematic than the Hiper DSP's with Hiper ARC. >> >> Some customers get very slow connections or connect fast but >> can't surf. Many claim they have to dial in many times before >> they get a good connection, but eventually they do. >> >> We are running 4.1.11 and 1.2.5, basically TCS 3.3 for all >> components. Are some older versions better? Is there some Beta >> code we should be trying? >> >> The problem is so bad we are considering going back to just X2. >> We are also looking into other equipment, which would kill us >> since we had become so comfortable with Total Control... >> >> ______________________________________________ >> >> Mario M. Bustamante, President >> AccessPro Communications Inc. >> Miami, Florida >> >> >> > -----Original Message----- >> > From: owner-usr-tc@lists.xmission.com >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell >> > Sent: Friday, October 30, 1998 3:40 PM >> > To: usr-tc@lists.xmission.com >> > Subject: (usr-tc) v.90 connect problems >> > >> > >> > Since upgrading my DSP's to 1.2.5 I've been having a >> > number of customers >> > with problems connecting, from plain no-connects to x2 >> > or x2/v90 modems >> > connecting at a slower rate than before. Otherwise on my HiPer; >> > ARC 4.0.30 >> > NMC 5.5.5 >> > >> > Some of the no-connects were LT Winmodems and the >> > -v90=0 string helped, the >> > others I'm waiting to hear back on modem type. >> > Does DSP 1.2.6x or ARC 4.1.x seem to be helping these >> > problems for anybody >> > else that's been experiencing them? >> > >> > >> > Kirk >> > >> > >> > >> > >> > Kirk Mitchell-General Manager sysadmin@keyconn.net >> > Keystone Connect http://www.keyconn.net >> > Altoona, PA 814-941-5000 We Unlock the World >> > >> > >> > - >> > To unsubscribe to usr-tc, send an email to >> > "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the 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. > > Al Thiel, MIS Spec.Net Internet Services of New York http://www.spec.net "I'm workin' on it!"
Subject: (usr-tc) Re: netserver quad / as5100
From: Aaron Leonard <aaron@cisco.com>
Date: 1998-11-03 14:22:39
> man, it's hard to figure out what list to post to. it's > off-topic no matter where you post. is it a cisco? is it a > 3com? is there a good place for as5100 questions? I guess splitting the difference is the way to go ... > anyrate, i'm trying to bring one up, CT1 that's already working > with a pm3, moved it over, seeing tons of garbage when trying to > dial in with a terminal emulator, connecting at 9600 bps. OK, I'll let the 3COM side deal with this one :-) As I understand it, the only cisco-supported TC hookup for the 5100 chassis is POTS lines, not T1, so I'll try to dodge this ... however, if you say "tons of garbage" - does this mean some good chars and some bad? Or are you just getting PPP data coming in? If some good chars and some bad, then it just sounds like your modems aren't negotiating EC - so what happens if you configure them to do LAP-M like they should be doing. > relevant parts of config are below, if anyone could send me > something sanitied, i'd greatly appreciate it. > afaik, async-bootp dns-server xxx.xxx.xxx.xxx will send a > nameserver out like everyone else does? Yep, it will send the DNS address(es) via PPP IPCP to a dialup client such as Windows DUN. > i remember reading somewhere that a command is needed to prevent > users from "demanding" an ip address instead of letting the as51 > card specify it? Um, this depends on the niceties of the AAA authorization config & whether Radius is assigning addresses or what have you. No simple answer. > thanks for your time, any suggestions, configs, or clues are > appreciated I'll make comments as I go thru ... > line 1 16 > session-timeout 30 output > location DNI Stamford POP > autoselect during-login > autoselect ppp > absolute-timeout 720 > login authentication ppplogin > modem Dialin > transport input all > stopbits 1 > speed 115200 > flowcontrol hardware Looks just fine to me. > interface Group-Async1 > ip unnumbered Ethernet0 > no ip directed-broadcast > ip tcp header-compression passive You may get better peformance removing the above. > encapsulation ppp > async mode dedicated whoah. No wonder you got "garbage" when dialing in from a terminal - you were seeing PPP packets. Change this to "async mode interactive". > no snmp trap link-status > peer default ip address pool dni-as1-1 > no fair-queue > no cdp enable > ppp authentication pap chap > ppp multilink do you really want to use multilink PPP over async? If so you'll want to have 11.3 and configure a virtual-template. > group-range 1 16 Can't tell from the above enough to tell whether you will or won't allow a client to dial in w/ their own IP address (all the AAA stuff will also be relevant.) (Not that I'm familiar enough with the ins and outs of AAA to figure it out anyway, but I know enough to know that AAA *is* relevant.) Cheers, Aaron
Subject: Re: (usr-tc) as5100 - am i crazy?
From: System Administrator <jamie-tc@atconnex.net>
Date: 1998-11-03 14:48:04
At 11:33 AM 10/31/98 +1100, Bob Purdon wrote: > >> * its a serious bitch to setup (Im no idiot, and it took me 2 weeks) > >Hmmm, we had one a while back and it took me around 30 minutes to get all >3 AS51 cards humming. Then again, we already used 2511's for dialup >access at that time, so we had the basic configuration. It wasn't the cisco gear that gave me the headache (I learned what I needed of IOS in the first couple of days) it was the amazing forgetting NVRAM on the Quad's.... hehehe... seems that if you don't tell them as many times as it usually takes to get a 4 year old to follow instructions, they won't listen. Now I know better, if I am changing the Quad settings, I change them a bunch of times to make sure they stick. I ended up learning a lot more Cisco along the way and now await the day when Livingston can't make a router to serve me well and I have to pay $$$$ for a Cisco ;) J ========================================== James Arlen SysAdmin At Connex Internet www.atconnex.net 519-836-8777
Subject: (usr-tc) netserver quad / as5100
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-03 14:48:55
man, it's hard to figure out what list to post to. it's off-topic no matter where you post. is it a cisco? is it a 3com? is there a good place for as5100 questions? anyrate, i'm trying to bring one up, CT1 that's already working with a pm3, moved it over, seeing tons of garbage when trying to dial in with a terminal emulator, connecting at 9600 bps. relevant parts of config are below, if anyone could send me something sanitied, i'd greatly appreciate it. afaik, async-bootp dns-server xxx.xxx.xxx.xxx will send a nameserver out like everyone else does? i remember reading somewhere that a command is needed to prevent users from "demanding" an ip address instead of letting the as51 card specify it? thanks for your time, any suggestions, configs, or clues are appreciated line 1 16 session-timeout 30 output location DNI Stamford POP autoselect during-login autoselect ppp absolute-timeout 720 login authentication ppplogin modem Dialin transport input all stopbits 1 speed 115200 flowcontrol hardware interface Group-Async1 ip unnumbered Ethernet0 no ip directed-broadcast ip tcp header-compression passive encapsulation ppp async mode dedicated no snmp trap link-status peer default ip address pool dni-as1-1 no fair-queue no cdp enable ppp authentication pap chap ppp multilink group-range 1 16 |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: (usr-tc) Re: netserver quad / as5100
From: Aaron Leonard <aaron@cisco.com>
Date: 1998-11-03 15:36:33
I have to admit that I posted the following nugget w/out knowing what I was talking about ... Aaron --- > I have to take exception to this. My stack of AS5100s is all CT1 > connected. I take the lines and float them among AS5100s and AS5300s > freely. > > OK, I'll let the 3COM side deal with this one :-) As I understand > > it, the only cisco-supported TC hookup for the 5100 chassis is > > POTS lines, not T1, so I'll try to dodge this ...
Subject: Re: (usr-tc) netserver quad / as5100
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-03 17:26:02
bryan s. blank was heard to say: > man, it's hard to figure out what list to post to. it's > off-topic no matter where you post. is it a cisco? is it a > 3com? is there a good place for as5100 questions? heh, it's both... but neither really own up to it. --Ricky
Subject: (usr-tc) Re: netserver quad / as5100
From: Alexander Latzko <latzko@hardees.rutgers.edu>
Date: 1998-11-03 18:11:55
I have to take exception to this. My stack of AS5100s is all CT1 connected. I take the lines and float them among AS5100s and AS5300s freely. On Tue, 3 Nov 1998, Aaron Leonard wrote: > From: Aaron Leonard <Aaron@Cisco.COM> > To: bryan s. blank <bryan@supernet.net> > Date: Tue, 03 Nov 1998 14:22:39 -0700 (PDT) > Subject: Re: netserver quad / as5100 > > > man, it's hard to figure out what list to post to. it's > > off-topic no matter where you post. is it a cisco? is it a > > 3com? is there a good place for as5100 questions? > > I guess splitting the difference is the way to go ... > > > anyrate, i'm trying to bring one up, CT1 that's already working > > with a pm3, moved it over, seeing tons of garbage when trying to > > dial in with a terminal emulator, connecting at 9600 bps. > > OK, I'll let the 3COM side deal with this one :-) As I understand > it, the only cisco-supported TC hookup for the 5100 chassis is > POTS lines, not T1, so I'll try to dodge this ... > > however, if you say "tons of garbage" - does this mean some > good chars and some bad? Or are you just getting PPP data coming > in? If some good chars and some bad, then it just sounds like > your modems aren't negotiating EC - so what happens if you > configure them to do LAP-M like they should be doing. > > > relevant parts of config are below, if anyone could send me > > something sanitied, i'd greatly appreciate it. > > > afaik, async-bootp dns-server xxx.xxx.xxx.xxx will send a > > nameserver out like everyone else does? > > Yep, it will send the DNS address(es) via PPP IPCP to a dialup > client such as Windows DUN. > > > i remember reading somewhere that a command is needed to prevent > > users from "demanding" an ip address instead of letting the as51 > > card specify it? > > Um, this depends on the niceties of the AAA authorization config > & whether Radius is assigning addresses or what have you. No simple > answer. > > > thanks for your time, any suggestions, configs, or clues are > > appreciated > > I'll make comments as I go thru ... > > > line 1 16 > > session-timeout 30 output > > location DNI Stamford POP > > autoselect during-login > > autoselect ppp > > absolute-timeout 720 > > login authentication ppplogin > > modem Dialin > > transport input all > > stopbits 1 > > speed 115200 > > flowcontrol hardware > > Looks just fine to me. > > > interface Group-Async1 > > ip unnumbered Ethernet0 > > no ip directed-broadcast > > ip tcp header-compression passive > > You may get better peformance removing the above. > > > encapsulation ppp > > async mode dedicated > > whoah. No wonder you got "garbage" when dialing in from > a terminal - you were seeing PPP packets. Change this to > "async mode interactive". > > > no snmp trap link-status > > peer default ip address pool dni-as1-1 > > no fair-queue > > no cdp enable > > ppp authentication pap chap > > ppp multilink > > do you really want to use multilink PPP over async? If so > you'll want to have 11.3 and configure a virtual-template. > > > group-range 1 16 > > Can't tell from the above enough to tell whether you will or won't > allow a client to dial in w/ their own IP address (all the AAA stuff > will also be relevant.) (Not that I'm familiar enough with the > ins and outs of AAA to figure it out anyway, but I know enough to > know that AAA *is* relevant.) > > Cheers, > > Aaron > -- latzko@noc.rutgers.edu n2mlq Alex Latzko +1-732-445-5021 (voice) +1-732-445-2968 (fax) Rutgers University Computing Services TD:NOG Backbone Operations 110 Frelinghuysen Road, Piscataway, NJ 08855-8089
Subject: (usr-tc) Re: netserver quad / as5100
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-03 18:18:16
|o| however, if you say "tons of garbage" - does this mean some |o| good chars and some bad? Or are you just getting PPP data coming |o| in? If some good chars and some bad, then it just sounds like |o| your modems aren't negotiating EC - so what happens if you |o| configure them to do LAP-M like they should be doing. i know what ppp looks like, and this ain't it. connects don't happen past 9600 baud, and now i don't get garbage anymore, it just hangs ... i blame 3com ;) anyrate, are there any docs on this thing, as said, nobody wants to claim it ... the stuff on CCO really doesn't touch on the integration of the two products as far as i can tell, and 3com doesn't seem to know what it is. thanks again! |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: Re: (usr-tc) Terminating ISDN on digital quads
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-03 22:38:55
On Wed, 4 Nov 1998, Peter D. Mayer wrote: > Jack, > > There are 2 ways to terminate ISDN calls on a TC box. One is to have the > NETServer act as an ISDN gateway, the other is to have the calls be answered > directly by the Digital Quad modems. The first works decently for us, but > I've heard from various folks on this list that the second method may be > better overall. That is what I'm asking about. I appreciate the response, > but I'm looking a little deeper than simply connecting with ISDN. > You are right - terminating the isdn calls on the modems is better - Now when you set the pri you can set up the quad modems as quad modems or quad I modems. For the most part the pri does use the nmc chassiawarness and configures them as quad-I-modems. At this time if you set the default gateway slot of the pri card as 0 then the isdn calls will be terminated on the modems. In your setup either you have the pri card set to a gateway slot other than 0 or the card has not taken the setup or you have the modems set as quad-modems. Check this you need not reboot the pri card. krish > Thanks, > Peter D. Mayer > NetWalk System Administrator > dmayer@netwalk.com > > -----Original Message----- > From: Jack Singer <jsinger@usacars.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, November 04, 1998 10:04 AM > Subject: Re: (usr-tc) Terminating ISDN on digital quads > > > If you have PRI-T1's then all the customer has to do is connect to you. You > do > not have to do anything since a PRI is already digital. We have many > customers > that connect via ISDN by doing nothing other than connecting to our regular > dial > up line. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: netserver quad / as5100
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-04 00:41:19
On Tue, 3 Nov 1998, bryan s. blank wrote: > |o| however, if you say "tons of garbage" - does this mean some > |o| good chars and some bad? Or are you just getting PPP data coming > |o| in? If some good chars and some bad, then it just sounds like > |o| your modems aren't negotiating EC - so what happens if you > |o| configure them to do LAP-M like they should be doing. > > i know what ppp looks like, and this ain't it. > > connects don't happen past 9600 baud, and now i don't get > garbage anymore, it just hangs ... > How is the modem setup - Disconnect the cisco attach a pc behind the modem and then dial into it to see how you are connecting. May be you are sending a init string from the cisco to the modem. You do not need a init string but some do send it. The modems should be set to flow control. You may be forcing the modem to connect at 9600. So check you config on the cisco. I would suggest do not send any init string and if you must then send at&f1. > i blame 3com ;) :-) Really? Why for your config? \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > anyrate, are there any docs on this thing, as said, nobody wants > to claim it ... the stuff on CCO really doesn't touch on the > integration of the two products as far as i can tell, and 3com > doesn't seem to know what it is. > > thanks again! > > |o|----------------------------------------------------------------------|o| > |o| bryan s. blank (203)-351-1178 voice |o| > |o| senior systems analyst (203)-351-1186 fax |o| > |o| discovernet, incorporated (203)-979-5126 emerg |o| > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Hub status goes red
From: Jack Singer <jsinger@usacars.com>
Date: 1998-11-04 09:08:49
We have quad total control boxes that are v.90 upgraded and the hub status light on some of the Network Management Cards turn red. We reboot them and they are fine. Can anyone tell us what is wrong or needs to be changed. Jack Singer jsinger@i-c.net
Subject: (usr-tc) Terminating ISDN on digital quads
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-11-04 09:36:33
I finally got around to trying the termination of ISDN calls on the digital quad modems. I set the GW-Slot on the PRI card to 0, and I thought that was the only thing necessary. No luck. ISDN calls just bounce off. Do I need to reset the PRI card? The NETServer? The whole chassis? Do I need to set something differently in the quads or the NETServer? I have the latest version of all code (no ER code though). Hardware revision 4 of the PRI card, 3 of the digital quads, and 7 of the NETServer. I appreciate any advice that you guys who have it working could give me. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com
Subject: Re: (usr-tc) Terminating ISDN on digital quads
From: Jack Singer <jsinger@usacars.com>
Date: 1998-11-04 10:03:43
If you have PRI-T1's then all the customer has to do is connect to you. You do not have to do anything since a PRI is already digital. We have many customers that connect via ISDN by doing nothing other than connecting to our regular dial up line. Jack Singer jsinger@i-c.net Peter D. Mayer wrote: > I finally got around to trying the termination of ISDN calls on the digital > quad modems. I set the GW-Slot on the PRI card to 0, and I thought that was > the only thing necessary. No luck. ISDN calls just bounce off. Do I need > to reset the PRI card? The NETServer? The whole chassis? Do I need to set > something differently in the quads or the NETServer? I have the latest > version of all code (no ER code though). Hardware revision 4 of the PRI > card, 3 of the digital quads, and 7 of the NETServer. I appreciate any > advice that you guys who have it working could give me. > > Thanks, > Peter D. Mayer > NetWalk System Administrator > dmayer@netwalk.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) Terminating ISDN on digital quads
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-11-04 10:33:17
Jack, There are 2 ways to terminate ISDN calls on a TC box. One is to have the NETServer act as an ISDN gateway, the other is to have the calls be answered directly by the Digital Quad modems. The first works decently for us, but I've heard from various folks on this list that the second method may be better overall. That is what I'm asking about. I appreciate the response, but I'm looking a little deeper than simply connecting with ISDN. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- If you have PRI-T1's then all the customer has to do is connect to you. You do not have to do anything since a PRI is already digital. We have many customers that connect via ISDN by doing nothing other than connecting to our regular dial up line.
Subject: Re: (usr-tc) Hub status goes red
From: Ken Hodges <ken@rabun.net>
Date: 1998-11-04 10:40:50
I have had the same experience.... When you reset the NMC, it may stay green for a few minutes or a few days before going red again... doesn't seem to affect any performance of the machne, though... 3Com has been unable to fix this... I even had them replace the card with the same results. Ken At 09:08 AM 11/4/98 -0500, you wrote: >We have quad total control boxes that are v.90 upgraded and the hub status >light on some of the Network Management Cards turn red. We reboot them and >they are fine. Can anyone tell us what is wrong or needs to be changed. > >Jack Singer >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. > > _______________________________________ Ken Hodges, President and CEO ACME BrainWorks Internet Services, Inc. Clayton Computers, Inc. Rabun County, Georgia "Where Spring Spends the Summer" http://www.acme-brain.com or http://www.rabun.net ken@rabun.net 1-706-782-9239
Subject: Re: (usr-tc) Hub status goes red
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1998-11-04 10:52:04
We have the same problem and it is caused by a bad fan in the fan tray. Ken Hodges wrote: > > I have had the same experience.... > When you reset the NMC, it may stay green for a few minutes or a few days > before going red again... doesn't seem to affect any performance of the > machne, though... 3Com has been unable to fix this... I even had them > replace the card with the same results. > > Ken > > At 09:08 AM 11/4/98 -0500, you wrote: > >We have quad total control boxes that are v.90 upgraded and the hub status > >light on some of the Network Management Cards turn red. We reboot them and > >they are fine. Can anyone tell us what is wrong or needs to be changed. > > > >Jack Singer > >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. > > > > > _______________________________________ > Ken Hodges, President and CEO > ACME BrainWorks Internet Services, Inc. > Clayton Computers, Inc. > Rabun County, Georgia > "Where Spring Spends the Summer" > http://www.acme-brain.com or http://www.rabun.net > ken@rabun.net 1-706-782-9239 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================
Subject: (usr-tc) Netserver16
From: Greg Coffey <greg@coffey.com>
Date: 1998-11-04 12:02:28
Whats the most current code we can run on a netserver 16? This one is a plain netserver 16, not the plus unit. Is there a version 4 that will run on one? If so, is it stable or does it have problems? ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com
Subject: Re: (usr-tc) Re: netserver quad / as5100
From: Charles Hill <chill@ionet.net>
Date: 1998-11-04 12:04:35
If you can reverse telnet to the modem and do an at&f1 for hardware flow control defaults and then an at&b0w to lock the port rate to the speed of the connected port. . . be sure the port is not set to 9600. Change your init string to atz or include &b0. That prevents the garbage caused by a port speed mismatch. -CH On Wed, 4 Nov 1998, Tatai SV Krishnan wrote: > On Tue, 3 Nov 1998, bryan s. blank wrote: > > > |o| however, if you say "tons of garbage" - does this mean some > > |o| good chars and some bad? Or are you just getting PPP data coming > > |o| in? If some good chars and some bad, then it just sounds like > > |o| your modems aren't negotiating EC - so what happens if you > > |o| configure them to do LAP-M like they should be doing. > > > > i know what ppp looks like, and this ain't it. > > > > connects don't happen past 9600 baud, and now i don't get > > garbage anymore, it just hangs ... > > > How is the modem setup - Disconnect the cisco attach a pc behind the > modem and then dial into it to see how you are connecting. May be you > are sending a init string from the cisco to the modem. You do not need a > init string but some do send it. > > The modems should be set to flow control. You may be forcing the modem > to connect at 9600. So check you config on the cisco. I would suggest > do not send any init string and if you must then send at&f1. > > > > > i blame 3com ;) > > :-) Really? Why for your config? > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > > > > > anyrate, are there any docs on this thing, as said, nobody wants > > to claim it ... the stuff on CCO really doesn't touch on the > > integration of the two products as far as i can tell, and 3com > > doesn't seem to know what it is. > > > > thanks again! > > > > |o|----------------------------------------------------------------------|o| > > |o| bryan s. blank (203)-351-1178 voice |o| > > |o| senior systems analyst (203)-351-1186 fax |o| > > |o| discovernet, incorporated (203)-979-5126 emerg |o| > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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: netserver quad / as5100
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-04 13:05:42
|o| If you can reverse telnet to the modem and do an at&f1 for hardware flow |o| control defaults and then an at&b0w to lock the port rate to the speed of |o| the connected port. . . be sure the port is not set to 9600. Change your |o| init string to atz or include &b0. That prevents the garbage caused by a |o| port speed mismatch. -CH thanks so much, i think i've got it halfway working - just gotta keep messing w3ith aaa ;) thanks! |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: Re: (usr-tc) Hub status goes red
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-04 16:01:38
Ken Hodges was heard to say: >I have had the same experience.... >When you reset the NMC, it may stay green for a few minutes or a few days >before going red again... doesn't seem to affect any performance of the >machne, though... 3Com has been unable to fix this... I even had them >replace the card with the same results. That LED is red for a reason... TCM ain't gonna tell you jack. The only thing that will tell you what is wrong is the RADIUS data the NMC will generate when it detects a problem. I'm guessing there is a problem with a fan somewhere. I've had several TCs do this as well. All of them did have something wrong. 3Com is just a little too happy to replace cards instead of actually trying to find out what's wrong. --Ricky
Subject: (usr-tc) NETServer Trade-Up PLUS program
From: Kurtiss Johnson <kurtiss_johnson@mw.3com.com>
Date: 1998-11-04 16:28:38
Hi all, I thought you'd like to see the details of the new NETServer Trade-Up program with the new ARC/DSP bundle. This announcement went out to our resellers last Friday, and should go out to the general public later this week or early next week. Kurtiss Johnson Product Manager - Access Routers 3Com Carrier Business Unit 847-222-2279 ******************************************** NETServer Trade Up Plus Promotion Program Details! Upgrade your NETServer based Total Control chassis to HiPer ARC and gain additional revenue generating multiservice access features, 24 additional ports to support more customers and generate more revenue and experience better performance over your existing NETServer card. Introducing an exciting new promotion for existing Total Control NETServer customers. This trade up program offers current Total Control NETServer customers with the opportunity to migrate to the latest in State-of-the-Art Multiservice Access Technology. Now, for less than the price of a single HiPer DSP card, when you purchase the NETServer Trade Up bundle (SKU 003465-0), it's like receiving a HiPer ARC at no additional cost. This exceptional offer provides the increased performance and additional features of HiPer ARC technology with an additional 24 ports. Estimated street price is $169 per port. List Price Trade Up Bundle SKU includes: Component Bundle 002106-0 HiPer Access Router Card $ 9,995 002092-0 HiPer DSP Card $ 11,500 002453-0 NMC Memory Upgrade $ 298 Total $ 21,793 $10,500 less rebate New Service Features! With the recent release of TCS v3.3, HiPer ARC is currently at feature parity with NETServer. In addition, HiPer ARC now delivers numerous significant enhancements including: MPIP - allows Multi-Link PPP across multiple chassis IPX - supports Novell NetWare IP Multicast - enables multicast services VPNs via L2TP - simulates private connections over a public network Enhanced SNMP management support - provides better polling features These feature enhancements enable service providers to offer more revenue generating services to their customers. End-User Rebate! The Trade Up program is only valid for purchases of a HiPer ARC router card (002106-0) or the new Trade Up SKU (003465-0) through December 31, 1998. In order to receive the $3,200 end-user rebate, you must return your Total Control NETServer Card prior to February 26th, 1999. More Information! Learn all about the NETServer Trade Up Plus promotion by visiting our web site at http://www.3com.com/promotions/hipertrade/ The site includes: - FAQ to answer consumers' burning questions. - Enhanced Feature-by-feature Comparison Document - Instructional "How To" Document that walks you through all of the steps necessary to replace a NETServer with a HiPer ARC, including both physical installation as well as configuration transition. - Lease option available for less that $8 per port per month. Better Support! Dedicated Toll-Free CSO Call Center for the sole use of HiPer ARC Trade Up customers. Their brand-new ARCSwitcher Configuration Translation Utility can translate 90% of the NETServer configuration to the HiPer ARC (The ARCSwitcher requires NETServer release v3.7 or later. Upgrades to v3.8 must be downloaded by December 31, 1998). For information call the Help desk at 888-373-7367. On-site Field Service Replacement Option available for those customers who would like 3Com field services personnel to perform their card exchange.
Subject: Re: (usr-tc) Hub status goes red
From: David Bolen <db3l@ans.net>
Date: 1998-11-04 16:38:19
Ken Hodges <ken@rabun.net> writes: > I have had the same experience.... > When you reset the NMC, it may stay green for a few minutes or a few days > before going red again... doesn't seem to affect any performance of the > machne, though... 3Com has been unable to fix this... I even had them > replace the card with the same results. The red LED indicates some sort of failure in the chassis. In general, this will be one of a few things (I'm not positive this list is exhaustive but I think it covers the cases I've run into): * An NMC self-test failure * An environmental sensor failure (temperature, power supply, or in the integrated fan tray chassis, rotational speed of one of the larger fans) * A management communication failure with a card in the chassis. * In the newer clocked chassis, multiple failures of the chassis clock. I suppose it's possible to be in error, but I've never had that myself in the past. Normally it's something other than the NMC, but NMC self test failures might require a replacement (for example, I've had specific management bus UARTs fail on an NMC). Normally, the management communication path will be obvious since a component will be in a failed operational state (I believe TCM shows such cards in yellow, if I recall correctly). The other cases can all be queried via SNMP. I'm not sure just where in TCM each query might be, but expect that each table should be available via some route. I'll show dumps below from our own tool just for information. The NMC self test and chassis temperature is part of the NMC status table (nmcStat) - I've marked (**) entries that might cause the led: NMC: CompSwVer:"5.5.0", DramInstalled:16384(0x4000), EventId:547(0x223), NVRAMInstalled:8192(0x2000), **NmcPktBusClk:available, **PktBusClkSrc:backplaneActive, PowerUpTstFailBMap:0, **PowerUpTstFailures:0, **Status:ok, **Temperature:22(0x16), TestResult:0 You can run a non-disruptive self test of most NMC items as well as an NMC command. The nmcStatTestResult object will have the same bitmapped result as that stored in nmcStatPowerUpTstFailBMap from the power up tests. The power supply information is in the chassis power supply tree (uchasPowerSupply) and gives both current status of the supplies as well as a count of warnings/failures since the NMC last rebooted: Power Supply Status Information: Supply Status Failures Description 1 good 0 USR Chassis PowerSupply 70 Amp AC #1 2 good 0 USR Chassis PowerSupply 70 Amp AC #2 Output Status Nominal Offered Warnings 1 good 5.00 5.21 0 2 good -5.00 -5.01 0 3 good 12.00 12.38 0 4 good -12.00 -12.10 0 The environmental information can be gathered from the chassis environmental table (uchasEnviron) and includes fan and temperature sensors as well as counts of warnings/failures since the NMC last rebooted. For the older chassis, the fan is for the fan behind the power supply - for the integrated fan tray chassis it includes the larger fans in the fan tray (the smaller ones aren't instrumented): Environmental Sensor Information: Sensor Status Warnings Failures Fans good 2 1 Temperature good 0 0 -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) Hub status goes red
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-04 16:43:45
Thus spake David Bolen > * An environmental sensor failure (temperature, power supply, or > in the integrated fan tray chassis, rotational speed of one of > the larger fans) >The other cases can all be queried via SNMP. I'm not sure just where >in TCM each query might be, but expect that each table should be >available via some route. I'll show dumps below from our own tool >just for information. I recently had a fan die in one of mine...I could *not* seem to find where this was shown in TCM anywhere...I'd be interested in finding out where (if at all) TCM can grab this info. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Dead Air...
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-04 16:52:29
I know this was covered just recently, but refresh my mind, which by the way is not working well anymore, as to what I need to set. I think it was stated that the lines wre freeing up before modems reset and were ready to take calls. The solution was round robin instead of fixed assignment. Was this done at the Phone co level or in the DSP's at the card level- routing method? If it is indeed done at the card level should I see modems from from 1-24 or will they still show modem 1, then modem 2, and so on? These are DSP's running 1.2.5 with channelized T1's, no PRI. Any help here or just the key search on interproc sure would help. If this is something the CO has to set, what do I need to ask for? Thanks---- TErry Kennedy
Subject: Re: (usr-tc) Hub status goes red
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-04 17:14:32
Jeff Mcadams was heard to say: >I recently had a fan die in one of mine...I could *not* seem to find >where this was shown in TCM anywhere...I'd be interested in finding out >where (if at all) TCM can grab this info. TCM doesn't "show" you fan failures or temperature alarms. --Ricky
Subject: Re: (usr-tc) Hub status goes red
From: David Bolen <db3l@ans.net>
Date: 1998-11-04 17:45:33
Ricky Beam <jfbeam@Interpath.net> writes: > TCM doesn't "show" you fan failures or temperature alarms. Hmm - well, the temperature you could determine by just checking it. Spec is no higher than 40C, but the alarm triggers a few degrees above that. I've got an older TCM copy, and it seems the NMC status (including temperature) is in the "NMC Identification" section of the configured parameters. That would be equivalent to my nmcStat table from my last note. However, it does appear (at least as of the TCM "dat" files up to NMC 4 - I haven't loaded v5 files) that nothing in any of those files references the uchasEnviron table, so I guess it can't display the environmental stuff. Unfortunate. Definitely a TCM issue though and not with the NMC or management MIBs directly, so if you've got a standalone SNMP query tool you could use that. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Brian <signal@shreve.net>
Date: 1998-11-04 20:11:38
> > List Price > Trade Up Bundle SKU includes: Component Bundle > 002106-0 HiPer Access Router Card $ 9,995 > 002092-0 HiPer DSP Card $ 11,500 > 002453-0 NMC Memory Upgrade $ 298 > > Total $ 21,793 $10,500 less rebate > First, let me say, I am very happy with the way 3com pricing is going, its been going down for quite some time, every bundle seems better than the last, very competitive pricing. However, I find the trade in program a bit misleading. What this boils down to, correct me if I am wrong is: out of pocket of around $11k 1 ARC 1 HDM 1 NMC upgrade When we are used to more like: out of pocket $10k 1 chassis 2 HDM's 1 ARC 1 NMC (already upgraded) 1 power supply 1 cables, software, etc. My last quote for the above bundle, form Solunet, was around <$9500. I don't see where the trade-in program makes sense. Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: (usr-tc) Line Quality Logging in RADIUS ?
From: Carl Litt <carl@snel.execulink.com>
Date: 1998-11-04 22:12:20
We are running both Netserver/Quad Modem and HiPerARC/DSP hubs and are plagued by disconnects (well, it isn't _too_ bad, but tell that to the users). Is there any way to get the Performance Monitor stats logged back to RADIUS? There's lots of space in those Vendor-Specific attributes which I never see used. I'm looking for Reason for Termination, Link Block Errors, Retrains Requested/Granted, and whatever other stats are useful. Reason for Termination and the RADIUS attribute Acct-Terminate-Cause are not the same thing... the first has way better information than the second. Some of those "Analog Stats" look helpful too. It would be extremely useful to have this stuff logged somewhere so that we can go back for any connection and have a good look at what caused the disconnect. On this topic, I was configuring a Quad/NS hub last night. I was dialed in and sitting close enough to kick it when it hung up on me after only 5 minutes. I checked the RADIUS logs and they said the Cause was a Lost-Carrier. However, the modem I was dialed into reported "Retransmit Limit". What's that about? The modem I dialed in with was a 3Com/Mhz LAN+Modem PCMCIA card (which never gets higher than 45,333). Carl Litt Network Administrator Execulink Internet Services Corporation
Subject: RE: (usr-tc) Terminating ISDN on digital quads
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-04 23:43:34
I didn't see anyone mention this so I will. You may want to verify the settings under ISDN Call Control Options on the modems. They should be correct, but no since in assuming that. check it. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan Sent: Tuesday, November 03, 1998 10:39 PM Cc: usr-tc@lists.xmission.com On Wed, 4 Nov 1998, Peter D. Mayer wrote: > Jack, > > There are 2 ways to terminate ISDN calls on a TC box. One is to have the > NETServer act as an ISDN gateway, the other is to have the calls be answered > directly by the Digital Quad modems. The first works decently for us, but > I've heard from various folks on this list that the second method may be > better overall. That is what I'm asking about. I appreciate the response, > but I'm looking a little deeper than simply connecting with ISDN. > You are right - terminating the isdn calls on the modems is better - Now when you set the pri you can set up the quad modems as quad modems or quad I modems. For the most part the pri does use the nmc chassiawarness and configures them as quad-I-modems. At this time if you set the default gateway slot of the pri card as 0 then the isdn calls will be terminated on the modems. In your setup either you have the pri card set to a gateway slot other than 0 or the card has not taken the setup or you have the modems set as quad-modems. Check this you need not reboot the pri card. krish > Thanks, > Peter D. Mayer > NetWalk System Administrator > dmayer@netwalk.com > > -----Original Message----- > From: Jack Singer <jsinger@usacars.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, November 04, 1998 10:04 AM > Subject: Re: (usr-tc) Terminating ISDN on digital quads > > > If you have PRI-T1's then all the customer has to do is connect to you. You > do > not have to do anything since a PRI is already digital. We have many > customers > that connect via ISDN by doing nothing other than connecting to our regular > dial > up line. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Hub status goes red
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-11-04 23:55:07
> I have had the same experience.... > When you reset the NMC, it may stay green for a few minutes or a few days > before going red again... doesn't seem to affect any performance of the > machne, though... 3Com has been unable to fix this... I even had them > replace the card with the same results. Run the Alarm Manager and configure the NMC to send traps to it - that way it'll tell you why the hub status LED is red. In our case, it thought the power supply fan was broken (it's not). Regards, Bob Purdon, Technical Manager, Southern Internet Services.
Subject: Re: (usr-tc) Terminating ISDN on digital quads
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-11-05 01:59:34
Which settings should I verify for this? Everything in there looks fairly normal. What do you have for the settings? Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- I didn't see anyone mention this so I will. You may want to verify the settings under ISDN Call Control Options on the modems. They should be correct, but no since in assuming that. check it. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan Sent: Tuesday, November 03, 1998 10:39 PM Cc: usr-tc@lists.xmission.com On Wed, 4 Nov 1998, Peter D. Mayer wrote: > Jack, > > There are 2 ways to terminate ISDN calls on a TC box. One is to have the > NETServer act as an ISDN gateway, the other is to have the calls be answered > directly by the Digital Quad modems. The first works decently for us, but > I've heard from various folks on this list that the second method may be > better overall. That is what I'm asking about. I appreciate the response, > but I'm looking a little deeper than simply connecting with ISDN. > You are right - terminating the isdn calls on the modems is better - Now when you set the pri you can set up the quad modems as quad modems or quad I modems. For the most part the pri does use the nmc chassiawarness and configures them as quad-I-modems. At this time if you set the default gateway slot of the pri card as 0 then the isdn calls will be terminated on the modems. In your setup either you have the pri card set to a gateway slot other than 0 or the card has not taken the setup or you have the modems set as quad-modems. Check this you need not reboot the pri card. krish
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: RJ Hwang <rj_hwang@mw.3com.com>
Date: 1998-11-05 03:03:53
-
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-05 08:28:49
On Wed, 4 Nov 1998, Brian wrote: > > > > List Price > > Trade Up Bundle SKU includes: Component Bundle > > 002106-0 HiPer Access Router Card $ 9,995 > > 002092-0 HiPer DSP Card $ 11,500 > > 002453-0 NMC Memory Upgrade $ 298 > > > > Total $ 21,793 $10,500 less rebate > > > > First, let me say, I am very happy with the way 3com pricing is going, its > been going down for quite some time, every bundle seems better than the > last, very competitive pricing. > > > However, I find the trade in program a bit misleading. What this boils > down to, correct me if I am wrong is: > > out of pocket of around $11k > 1 ARC > 1 HDM > 1 NMC upgrade The street price on this bundle is somewhere around $6400. With the $3200 rebate, you're basically getting the Hiper ARC for free. Brian
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-05 08:38:17
On Thu, 5 Nov 1998, Jeff Mcadams wrote: > Again, I'll throw out that I (and many others) *really* would like to > see a low-density low-cost alternative to the HiPer equipment. I still > haven't seen an even halfway credible response to why 3Com isn't doing > this. The NETServer hardware is there, it should be trivial to port the > Pilgrim code to it, and there it is. Why would lower density equipment cost less? HiPer bundles with 48 ports cost around $10,000. Do you really think that the older bundles like the 2059 or the 1706 could be sold for less if still available? I'll bet it actually costs more to manufacture a 2059 or 1706 bundle because there are a lot more circuit boards involved. Brian
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-05 09:00:56
Thus spake Kurtiss Johnson >With the recent release of TCS v3.3, HiPer ARC is currently >at feature parity with NETServer. Gotta throw out a nit-pick here. From the netserver "set radius_options prompt delay x" There's no equivalent feature command set for the HARC from what I can tell....its a pretty minor feature, but its the only thing that stands between us and using the HiPer Arc instead of the NETServers. At this point I have to keep coniving ways to get new NETServers since the HARC doesn't support this. :/ Again, I'll throw out that I (and many others) *really* would like to see a low-density low-cost alternative to the HiPer equipment. I still haven't seen an even halfway credible response to why 3Com isn't doing this. The NETServer hardware is there, it should be trivial to port the Pilgrim code to it, and there it is. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Curt Shambeau <curt@execpc.com>
Date: 1998-11-05 09:37:07
> > List Price > > Trade Up Bundle SKU includes: Component Bundle > > 002106-0 HiPer Access Router Card $ 9,995 > > 002092-0 HiPer DSP Card $ 11,500 > > 002453-0 NMC Memory Upgrade $ 298 > > > > Total $ 21,793 $10,500 less rebate > > > > First, let me say, I am very happy with the way 3com pricing is going, its > been going down for quite some time, every bundle seems better than the > last, very competitive pricing. > > > However, I find the trade in program a bit misleading. What this boils > down to, correct me if I am wrong is: > > out of pocket of around $11k > 1 ARC > 1 HDM > 1 NMC upgrade > > > When we are used to more like: > > out of pocket $10k > 1 chassis > 2 HDM's > 1 ARC > 1 NMC (already upgraded) > 1 power supply > 1 cables, software, etc. > > My last quote for the above bundle, form Solunet, was around <$9500. I > don't see where the trade-in program makes sense. Those chassis bundles were great, weren't they? However, your math is flawed because you didn't find the street price of the new bundle, which should be under $6500. So, you buy the bundle at $6500, subtract the netserver trade in ($3200), and end up with a HDM and ARC for around $3300. That's $137.50/port for the HDM, and the ARC is then FREE! Still sounds like a deal to me! Even though the chassis deal was great, and gave you more, it was still at $200/port or so. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Kurtiss Johnson <kurtiss_johnson@mw.3com.com>
Date: 1998-11-05 09:48:07
Hi Brian, I'm not trying to be misleading, but maybe the statement needs clarification. The price I posted is LIST price. So take the list ($10,500) and get to your typical street price from resellers, at whatever discounts you can. Let's say your street price is about $6600US (I think this won't upset any of our resellers with insinuated precedence :-) ). Now, send in the NETServer and the proof of purchase for the bundle, and we'll cut you a check for $3200 back (the term "less rebate" means subtract any eligible rebates from the purchase price). This brings your pricing to about $3400 for the bundle. That's about $141 per port, and includes the router card and the NMC memory upgrade. Compare that to the bundle you mentioned, at about $197 per port (granted, you get all the surrounding equipment as well, but many of you have "surplus" chassis stacked up in corners already, right?) Does this make a little more sense? Kurtiss Johnson Product Manager - Access Routers 3Com Corporation - Carrier Business Unit 847-222-2279 Brian <signal@shreve.net> on 11/04/98 08:11:38 PM Please respond to usr-tc@lists.xmission.com cc: (Kurtiss Johnson/MW/US/3Com) Note: Some recipients have been dropped due to syntax errors. Please refer to the "$AdditionalHeaders" item for the complete headers. > > List Price > Trade Up Bundle SKU includes: Component Bundle > 002106-0 HiPer Access Router Card $ 9,995 > 002092-0 HiPer DSP Card $ 11,500 > 002453-0 NMC Memory Upgrade $ 298 > > Total $ 21,793 $10,500 less rebate > First, let me say, I am very happy with the way 3com pricing is going, its been going down for quite some time, every bundle seems better than the last, very competitive pricing. However, I find the trade in program a bit misleading. What this boils down to, correct me if I am wrong is: out of pocket of around $11k 1 ARC 1 HDM 1 NMC upgrade When we are used to more like: out of pocket $10k 1 chassis 2 HDM's 1 ARC 1 NMC (already upgraded) 1 power supply 1 cables, software, etc. My last quote for the above bundle, form Solunet, was around <$9500. I don't see where the trade-in program makes sense. Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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 Trade-Up PLUS program
From: Christina Raeber <christina_raeber@mw.3com.com>
Date: 1998-11-05 09:58:42
If you have any questions regarding the NETServer Trade Up Program you can call: 888-373-7367 or email HiperARCUpgrade@3com.com Curt Shambeau <curt@execpc.com> on 11/05/98 09:37:07 AM Please respond to usr-tc@lists.xmission.com cc: (Christina Raeber/MW/US/3Com) > > List Price > > Trade Up Bundle SKU includes: Component Bundle > > 002106-0 HiPer Access Router Card $ 9,995 > > 002092-0 HiPer DSP Card $ 11,500 > > 002453-0 NMC Memory Upgrade $ 298 > > > > Total $ 21,793 $10,500 less rebate > > > > First, let me say, I am very happy with the way 3com pricing is going, its > been going down for quite some time, every bundle seems better than the > last, very competitive pricing. > > > However, I find the trade in program a bit misleading. What this boils > down to, correct me if I am wrong is: > > out of pocket of around $11k > 1 ARC > 1 HDM > 1 NMC upgrade > > > When we are used to more like: > > out of pocket $10k > 1 chassis > 2 HDM's > 1 ARC > 1 NMC (already upgraded) > 1 power supply > 1 cables, software, etc. > > My last quote for the above bundle, form Solunet, was around <$9500. I > don't see where the trade-in program makes sense. Those chassis bundles were great, weren't they? However, your math is flawed because you didn't find the street price of the new bundle, which should be under $6500. So, you buy the bundle at $6500, subtract the netserver trade in ($3200), and end up with a HDM and ARC for around $3300. That's $137.50/port for the HDM, and the ARC is then FREE! Still sounds like a deal to me! Even though the chassis deal was great, and gave you more, it was still at $200/port or so. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, 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) NETServer Trade-Up PLUS program
From: Kurtiss Johnson <kurtiss_johnson@mw.3com.com>
Date: 1998-11-05 10:14:43
OK, Jeff, I'll grant you that the "TCS v3.3" statement is a general blanket, and that there may be a few things that aren't there yet (though I thought the RAD_OPT functionality was not one of them...hmmm....). I'm going to -kinda- object to your concerns for a lower density product, though. The determination of "density" is not handled by the router card, except that the NETServer doesn't scale UP as much as the HiPer ARC. The "density" is determined by the modem cards, by whether you're using HiPer DSP or Quads and Dual Trunk cards. Agree so far? So what prevents you from using a HiPer ARC in combination with Quads, rather than the NETServer? OK, so if there's feature that's missing (we really ARE trying to get everything in ARC, but something might have fallen through the cracks) then let me know about it! One of the things that WON'T be done, however, is porting the Pilgrim software to NETServer, for both technical and business issues. Kurtiss Johnson Product Manager - Access Routers 3Com Corporation - Carrier Business Unit 847-222-2279 Jeff Mcadams <jeffm@iglou.com> on 11/05/98 08:00:56 AM Please respond to usr-tc@lists.xmission.com cc: (Kurtiss Johnson/MW/US/3Com) Note: Some recipients have been dropped due to syntax errors. Please refer to the "$AdditionalHeaders" item for the complete headers. Thus spake Kurtiss Johnson >With the recent release of TCS v3.3, HiPer ARC is currently >at feature parity with NETServer. Gotta throw out a nit-pick here. From the netserver "set radius_options prompt delay x" There's no equivalent feature command set for the HARC from what I can tell....its a pretty minor feature, but its the only thing that stands between us and using the HiPer Arc instead of the NETServers. At this point I have to keep coniving ways to get new NETServers since the HARC doesn't support this. :/ Again, I'll throw out that I (and many others) *really* would like to see a low-density low-cost alternative to the HiPer equipment. I still haven't seen an even halfway credible response to why 3Com isn't doing this. The NETServer hardware is there, it should be trivial to port the Pilgrim code to it, and there it is. -- 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 Trade-Up PLUS program
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-05 10:22:49
Thus spake Brian Elfert >Why would lower density equipment cost less? You think a 486 chip costs as much as a PPC603? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Result code group
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-05 11:12:22
What should "Result code group" be set on a quad talking to a HiperArc? The default is 0, should it be 1? -- Aaron Nabil
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-11-05 11:48:33
On Thu, 5 Nov 1998, Kurtiss Johnson wrote: > One of the things that WON'T be done, however, is porting the Pilgrim > software to NETServer, for both technical and business issues. Care to expound on that? Technical issues? Are you talking the ability to implement things in software because of a lack of appropriate hardware or what? What is your team trying to implement in software that the ARC can do which the NetServer is physically incapable of? Kevin Benton Network Engineer SOTA Technologies 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) NETServer Trade-Up PLUS program
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-05 12:42:19
Thus spake Kurtiss Johnson >OK, Jeff, I'll grant you that the "TCS v3.3" statement is a general >blanket, and that there may be a few things that aren't there yet (though I >thought the RAD_OPT functionality was not one of them...hmmm....). Hey, if its there, and I just missed it, wonderful! :) I certainly couldn't find it though. :) >I'm going to -kinda- object to your concerns for a lower density product, >though. The determination of "density" is not handled by the router card, >except that the NETServer doesn't scale UP as much as the HiPer ARC. Eh, yeah, we're getting into semantics here, but since you can slap a NETServer in there for each two DSP's and conceivably have that work the same way, the NETServer can, at least *somewhat*, determine density. That, of course, is a rather oddball config, but one that we're considering (or course if you can find that rad_opt functionality then away we can go with ARC's). >The >"density" is determined by the modem cards, by whether you're using HiPer >DSP or Quads and Dual Trunk cards. Agree so far? Not completely, see above. :) >So what prevents you >from using a HiPer ARC in combination with Quads, rather than the >NETServer? Well...I'm not really looking for a low-density solution explicitly...although it can be nice to have your hunt group spread across multiple chassis to prevent single-points of failure, and that is indeed addressed by your thoughts here...but if I'm only going to be putting 48-96 ports in a chassis, and NETServers are (or could be at least...*should* be I would think) cheaper, then its gonna cost me less to use the NETServer hardware in that chassis, and I'm not sacrificing much of anything (assuming they're running Pilgrim code, which shouldn't be too terribly difficult a challenge) and saving a chunk of change. :) >OK, so if there's feature that's missing (we really ARE trying >to get everything in ARC, but something might have fallen through the >cracks) then let me know about it! That rad_opt thingy is the only thing that I noticed...but then we don't use all the features of the NETServer code, so there might be more missing, but they won't affect us. Again, the rad_opt thing is pretty minor, and I can't really blame you for missing it, but unfortunately, its a minor thing that our setup kind of depends on. :) >One of the things that WON'T be done, however, is porting the Pilgrim >software to NETServer, for both technical and business issues. Gack...another strike for 3Com then, IMHO. I just can't seem to come up with *any* really good reason not to do this. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Latest ER code for HiPer
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1998-11-05 13:09:50
What's the latest ER code for the HiPer ARC and DSP's? We've had a rash of problems with disconnects and "no answer" lately from customers with both the cheapo modems as well as the USR v.90 modems. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================
Subject: Re: (usr-tc) NETServer Trade-Up PLUS program
From: Brian <signal@shreve.net>
Date: 1998-11-05 13:24:54
ok, I get this now :) On Thu, 5 Nov 1998, Kurtiss Johnson wrote: > Hi Brian, > > I'm not trying to be misleading, but maybe the statement needs > clarification. > > The price I posted is LIST price. So take the list ($10,500) and get to > your typical street price from resellers, at whatever discounts you can. > Let's say your street price is about $6600US (I think this won't upset any > of our resellers with insinuated precedence :-) ). > > Now, send in the NETServer and the proof of purchase for the bundle, and > we'll cut you a check for $3200 back (the term "less rebate" means subtract > any eligible rebates from the purchase price). This brings your pricing to > about $3400 for the bundle. That's about $141 per port, and includes the > router card and the NMC memory upgrade. Compare that to the bundle you > mentioned, at about $197 per port (granted, you get all the surrounding > equipment as well, but many of you have "surplus" chassis stacked up in > corners already, right?) > > Does this make a little more sense? > > Kurtiss Johnson > Product Manager - Access Routers > 3Com Corporation - Carrier Business Unit > 847-222-2279 > > > > > > Brian <signal@shreve.net> on 11/04/98 08:11:38 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (Kurtiss Johnson/MW/US/3Com) > Subject: Re: (usr-tc) NETServer Trade-Up PLUS program > > > > > Note: Some recipients have been dropped due to syntax errors. > Please refer to the "$AdditionalHeaders" item for the complete headers. > > > > > > > List Price > > Trade Up Bundle SKU includes: Component Bundle > > 002106-0 HiPer Access Router Card $ 9,995 > > 002092-0 HiPer DSP Card $ 11,500 > > 002453-0 NMC Memory Upgrade $ 298 > > > > Total $ 21,793 $10,500 less rebate > > > > First, let me say, I am very happy with the way 3com pricing is going, its > been going down for quite some time, every bundle seems better than the > last, very competitive pricing. > > > However, I find the trade in program a bit misleading. What this boils > down to, correct me if I am wrong is: > > out of pocket of around $11k > 1 ARC > 1 HDM > 1 NMC upgrade > > > When we are used to more like: > > out of pocket $10k > 1 chassis > 2 HDM's > 1 ARC > 1 NMC (already upgraded) > 1 power supply > 1 cables, software, etc. > > My last quote for the above bundle, form Solunet, was around <$9500. I > don't see where the trade-in program makes sense. > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) BAD date on HiperARC
From: sagarwal@crash.ae.usr.com
Date: 1998-11-05 14:09:26
Type in the following command at Hiper Prompt. Hiper> set date <date> The format is dd-mmm-yyyy Sanjay On Thu, 5 Nov 1998, pferraro wrote: > > Could someone please tell us how to correct the date on our > HiperARC??? Currently it say 21 Oct 2079. THe GMT looks fine. We enable > the NTP several weeks back... The system has been REBOOTED several times > and we still have the 2079 date!!! > > I want to resolves this... If anyone has the answer, please let me know > > ============================================================================== > 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 > ============================================================================== > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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's twiddling modem settings
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-05 14:26:35
Here's what a hiperarc does when you do a "reset modem". The amazing this is how the modem decodes ATS0=0 (try "list init") into all of these commands! I'm thinking a reasonable strategy for settings modem NVRAM is to do a restore from default, a "reset modem_group all" on the hiperarc, and then a save to nvram. hiperarc hiperdsp sets to default DTE Interface Settings Modem Escape Char (S2) 255 43 Call Control Options Verbal/Numeric Result Codes numeric verbal Result Code Groups 0 1 ARQ Result Codes arqResultsDisabled arqResultsEnabled Rings for Auto Answer 0 1 ATZ Handling over Packet Bus atZPbIgnore normalAtz hiperarc quad modem sets to default DTE Interface Settings Modem Escape Char (S2) 255 43 Call Control Options Result Codes (Qn) displayResult noResult Verbal/Numeric Result Codes numeric verbal Result Code Groups 0 1 ARQ Result Codes arqResultsDisabled arqResultsEnabled Response to +++ ignoreEscCode enterCommmandMode Packet Bus Answer Only (S47.5) enable disable -- Aaron Nabil
Subject: RE: (usr-tc) Dead Air...
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-05 14:35:07
Thanks on that one. One more, please... Have the 1.2.68 code. Is this as simple as the quads for upgrading. ie.. tftp-reboot ? will all settings remain or will they get lost like the quads use to do? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Doran > Sent: Thursday, November 05, 1998 1:05 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Dead Air... > > > I have set the HiPerDSP cards to round-robin and it seems to have cleared > up a lot of the operator intercept error messages we were getting > prior. I > don't think it matters whether it is done on the card or at the CO, the > results should be the same. It is just easier to to it in the > card because > then you will have control over it. > > Randy Doran > Circuit Engineer \ Dialup Network Administrator > > e.spire Communication's CyberGate Internet Services > > Phone: 954-429-8069 FAX: 954-429-8001 > > At 04:52 PM 11/4/98 -0800, you wrote: > >I know this was covered just recently, but refresh my mind, > >which by the way is not working well anymore, as to what I need > >to set. I think it was stated that the lines wre freeing up before > >modems reset and were ready to take calls. The solution was round robin > >instead of fixed assignment. Was this done at the Phone co level > or in the > >DSP's at the card level- routing method? If it is indeed done at the > >card level should I see modems from from 1-24 or will they still show > >modem 1, then modem 2, and so on? These are DSP's running 1.2.5 with > >channelized T1's, no PRI. Any help here or just the key search > on interproc > >sure would help. > > > >If this is something the CO has to set, what do I need to ask for? > > > >Thanks---- > > > >TErry Kennedy > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) BAD date on HiperARC
From: pferraro <pferraro@wna-linknet.com>
Date: 1998-11-05 14:56:39
Could someone please tell us how to correct the date on our HiperARC??? Currently it say 21 Oct 2079. THe GMT looks fine. We enable the NTP several weeks back... The system has been REBOOTED several times and we still have the 2079 date!!! I want to resolves this... If anyone has the answer, please let me know ============================================================================== 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 on HiperARC's
From: Rick Payne <rickp@ops.netcom.net.uk>
Date: 1998-11-05 16:03:48
Using standard snmp tools, I can snmpwalk many of the tables in the HiperARC's mibs, but I cannot get individual elements. eg. lucan:(rickp)~> snmpwalk hiper usrMPIPLinkBundleOwner usRobotics.common.usrMPIP.usrMPIPBase.usrMPIPLinkTable.usrMPIPLinkEntry.usrMPIPLinkBundleOwner.0 : IpAddress: 10.0.0.1 usRobotics.common.usrMPIP.usrMPIPBase.usrMPIPLinkTable.usrMPIPLinkEntry.usrMPIPLinkBundleOwner.1 : IpAddress: 10.0.0.2 etc. yet: lucan:(rickp)~> snmpget hiper usrMPIPLinkBundleOwner.0 snmpget: Agent reported an error. snmpget: SNMP: Variable does not exist or access is denied. Am I missing something, or is it that the HiperARC's just don't like "get" and prefer "getnext". This occurs in 4.1.78. Cheers, Rick
Subject: Re: (usr-tc) Dead Air...
From: Randy Doran <randydoran@usa.net>
Date: 1998-11-05 16:04:36
I have set the HiPerDSP cards to round-robin and it seems to have cleared up a lot of the operator intercept error messages we were getting prior. I don't think it matters whether it is done on the card or at the CO, the results should be the same. It is just easier to to it in the card because then you will have control over it. Randy Doran Circuit Engineer \ Dialup Network Administrator e.spire Communication's CyberGate Internet Services Phone: 954-429-8069 FAX: 954-429-8001 At 04:52 PM 11/4/98 -0800, you wrote: >I know this was covered just recently, but refresh my mind, >which by the way is not working well anymore, as to what I need >to set. I think it was stated that the lines wre freeing up before >modems reset and were ready to take calls. The solution was round robin >instead of fixed assignment. Was this done at the Phone co level or in the >DSP's at the card level- routing method? If it is indeed done at the >card level should I see modems from from 1-24 or will they still show >modem 1, then modem 2, and so on? These are DSP's running 1.2.5 with >channelized T1's, no PRI. Any help here or just the key search on interproc >sure would help. > >If this is something the CO has to set, what do I need to ask for? > >Thanks---- > >TErry Kennedy > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) BAD date on HiperARC
From: sagarwal@crash.ae.usr.com
Date: 1998-11-05 16:53:39
Brian, Which NTP issue are you refering to? Sanjay On Thu, 5 Nov 1998, Brian K McIntire wrote: > The information Sanjay gave you will set the date correctly but does not > address your issues with NTP. Sanjay, are there any current issues with > using NTP on these HiPer ARC's. I experienced the same problems he's > reporting. Maybe it's my version of software. Don't know. > > ======================================================================= > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = = > = Experts in Remote Access and all areas of NetWork Design, = > = Security, and Implementation. Offering both installation and = > = support, along with remote management and monitoring packages for = > = dedicated clients (specializing in ISP's). = > = Firm partnerships established with all the key players. = > = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = > = = > = Serving North America and parts of Canada. Reselling to the world. = > ======================================================================= > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > sagarwal@crash.ae.usr.com > Sent: Thursday, November 05, 1998 2:09 PM > To: pferraro > Cc: Brian; usr-tc@lists.xmission.com > Subject: Re: (usr-tc) BAD date on HiperARC > > > Type in the following command at Hiper Prompt. > Hiper> set date <date> > > The format is dd-mmm-yyyy > > Sanjay > > On Thu, 5 Nov 1998, pferraro wrote: > > > > > Could someone please tell us how to correct the date on our > > HiperARC??? Currently it say 21 Oct 2079. THe GMT looks fine. We enable > > the NTP several weeks back... The system has been REBOOTED several times > > and we still have the 2079 date!!! > > > > I want to resolves this... If anyone has the answer, please let me know > > > > > ============================================================================ > == > > 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 > > > ============================================================================ > == > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) Latest ER code for HiPer
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-05 17:07:39
The latest release code is 4.1.11 on the HiPer ARC and 1.2.5 on the DSP The latest ER code i have received from 3COM is 1.2.68 on the HiPer DSP (fixes dead random dead air, ring no answer, and strange tone problems) and 4.1.78 (fixes web-TV) on the HiPer ARC There are always additions and/or changes to code so I'm sure there is something more current out there but these seem to work great for us. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andrew Aken Sent: Thursday, November 05, 1998 1:10 PM What's the latest ER code for the HiPer ARC and DSP's? We've had a rash of problems with disconnects and "no answer" lately from customers with both the cheapo modems as well as the USR v.90 modems. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.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) BAD date on HiperARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-05 17:07:40
The information Sanjay gave you will set the date correctly but does not address your issues with NTP. Sanjay, are there any current issues with using NTP on these HiPer ARC's. I experienced the same problems he's reporting. Maybe it's my version of software. Don't know. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of sagarwal@crash.ae.usr.com Sent: Thursday, November 05, 1998 2:09 PM Cc: Brian; usr-tc@lists.xmission.com Type in the following command at Hiper Prompt. Hiper> set date <date> The format is dd-mmm-yyyy Sanjay On Thu, 5 Nov 1998, pferraro wrote: > > Could someone please tell us how to correct the date on our > HiperARC??? Currently it say 21 Oct 2079. THe GMT looks fine. We enable > the NTP several weeks back... The system has been REBOOTED several times > and we still have the 2079 date!!! > > I want to resolves this... If anyone has the answer, please let me know > > ============================================================================ == > 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 > ============================================================================ == > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Dead Air...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-05 18:02:17
Make sure you have 5.5.5 on your NMC (This is very important. Restore from default does not seem to work properly on HiPer DSP's with earlier revisions of NMC code.) The settings should remain, however, never assume that. Once you have downloaded the new code do the following: Click on the HiPer DSP card itself and go to configure action/commands and go to configure/action commands and perform a Hardware reset. When the card comes back up.... Click on the modem utilization bar and go to configure/action commands and select all modems and hit OK. restore from default and save to nvram Now click on the whole card again and return to Configure/action commands and choose Software settings for the command to execute. restore template 1 config from default and execute. Save template 1 config to NVRAM and execute. Change the command to execute back to Hardware and perform one last hardware reset. Some of the above may not be completely necessary, but this seems to be the desired approach whenever upgrading HiPer DSP's. Hope this helps. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Thursday, November 05, 1998 4:35 PM Thanks on that one. One more, please... Have the 1.2.68 code. Is this as simple as the quads for upgrading. ie.. tftp-reboot ? will all settings remain or will they get lost like the quads use to do? > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Doran > Sent: Thursday, November 05, 1998 1:05 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Dead Air... > > > I have set the HiPerDSP cards to round-robin and it seems to have cleared > up a lot of the operator intercept error messages we were getting > prior. I > don't think it matters whether it is done on the card or at the CO, the > results should be the same. It is just easier to to it in the > card because > then you will have control over it. > > Randy Doran > Circuit Engineer \ Dialup Network Administrator > > e.spire Communication's CyberGate Internet Services > > Phone: 954-429-8069 FAX: 954-429-8001 > > At 04:52 PM 11/4/98 -0800, you wrote: > >I know this was covered just recently, but refresh my mind, > >which by the way is not working well anymore, as to what I need > >to set. I think it was stated that the lines wre freeing up before > >modems reset and were ready to take calls. The solution was round robin > >instead of fixed assignment. Was this done at the Phone co level > or in the > >DSP's at the card level- routing method? If it is indeed done at the > >card level should I see modems from from 1-24 or will they still show > >modem 1, then modem 2, and so on? These are DSP's running 1.2.5 with > >channelized T1's, no PRI. Any help here or just the key search > on interproc > >sure would help. > > > >If this is something the CO has to set, what do I need to ask for? > > > >Thanks---- > > > >TErry Kennedy > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) BAD date on HiPerARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-05 18:37:03
please read the message you responded to. Your answer is there. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of sagarwal@crash.ae.usr.com Sent: Thursday, November 05, 1998 4:54 PM Brian, Which NTP issue are you refering to? Sanjay On Thu, 5 Nov 1998, Brian K McIntire wrote: > The information Sanjay gave you will set the date correctly but does not > address your issues with NTP. Sanjay, are there any current issues with > using NTP on these HiPer ARC's. I experienced the same problems he's > reporting. Maybe it's my version of software. Don't know. > > ======================================================================= > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = = > = Experts in Remote Access and all areas of NetWork Design, = > = Security, and Implementation. Offering both installation and = > = support, along with remote management and monitoring packages for = > = dedicated clients (specializing in ISP's). = > = Firm partnerships established with all the key players. = > = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = > = = > = Serving North America and parts of Canada. Reselling to the world. = > ======================================================================= > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > sagarwal@crash.ae.usr.com > Sent: Thursday, November 05, 1998 2:09 PM > To: pferraro > Cc: Brian; usr-tc@lists.xmission.com > Subject: Re: (usr-tc) BAD date on HiperARC > > > Type in the following command at Hiper Prompt. > Hiper> set date <date> > > The format is dd-mmm-yyyy > > Sanjay > > On Thu, 5 Nov 1998, pferraro wrote: > > > > > Could someone please tell us how to correct the date on our > > HiperARC??? Currently it say 21 Oct 2079. THe GMT looks fine. We enable > > the NTP several weeks back... The system has been REBOOTED several times > > and we still have the 2079 date!!! > > > > I want to resolves this... If anyone has the answer, please let me know > > > > > ============================================================================ > == > > 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 > > > ============================================================================ > == > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) v.90 connect problems
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-05 19:57:27
On Fri, 30 Oct 1998, K Mitchell wrote: > Since upgrading my DSP's to 1.2.5 I've been having a number of customers > with problems connecting, from plain no-connects to x2 or x2/v90 modems > connecting at a slower rate than before. Otherwise on my HiPer; > ARC 4.0.30 > NMC 5.5.5 > > Some of the no-connects were LT Winmodems and the -v90=0 string helped, the > others I'm waiting to hear back on modem type. > Does DSP 1.2.6x or ARC 4.1.x seem to be helping these problems for anybody > else that's been experiencing them? OK, quite a few people, me included, have reported this problem, and DSP rev 1.2.68 doesn't fix it. (It does fix other problems.) ARC 4.1.11 or 4.1.78 doesn't fix it either. I've seen no real fixes that have worked so far. (Adding commas to the end of the number hasn't helped anyone here.) If this is a real bug, CAN SOMEONE (preferably at 3com) PLEASE AT LEAST SAY SO, so I have SOMETHING to tell my users? Or if nothing else, so I know what code to downgrade to? This is really becoming a major problem for us... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep
Subject: Re: (usr-tc) v.90 connect problems
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-05 22:44:14
At 07:57 PM 11/5/98 -0500, Mike Andrews wrote: >On Fri, 30 Oct 1998, K Mitchell wrote: > >> Since upgrading my DSP's to 1.2.5 I've been having a number of customers >> with problems connecting, from plain no-connects to x2 or x2/v90 modems >> connecting at a slower rate than before. Otherwise on my HiPer; >> ARC 4.0.30 >> NMC 5.5.5 >> >> Some of the no-connects were LT Winmodems and the -v90=0 string helped, the >> others I'm waiting to hear back on modem type. >> Does DSP 1.2.6x or ARC 4.1.x seem to be helping these problems for anybody >> else that's been experiencing them? > >OK, quite a few people, me included, have reported this problem, and DSP >rev 1.2.68 doesn't fix it. (It does fix other problems.) ARC 4.1.11 or >4.1.78 doesn't fix it either. > >I've seen no real fixes that have worked so far. (Adding commas to the >end of the number hasn't helped anyone here.) > >If this is a real bug, CAN SOMEONE (preferably at 3com) PLEASE AT LEAST >SAY SO, so I have SOMETHING to tell my users? Or if nothing else, so I >know what code to downgrade to? This is really becoming a major problem >for us... I've gone back to the 1.0.8 DSP code, and that seems to be working much better, albeit without v.90. I left one DSP at 1.2.5 for those few Flex users that actually connected better on it. I'm still waiting for a workable answer also......... Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) v.90 connect problems
From: John Powell <john_powell@mw.3com.com>
Date: 1998-11-05 22:59:25
>OK, quite a few people, me included, have reported this problem, and DSP >rev 1.2.68 doesn't fix it. (It does fix other problems.) ARC 4.1.11 or >4.1.78 doesn't fix it either. >I've seen no real fixes that have worked so far. (Adding commas to the >end of the number hasn't helped anyone here.) >If this is a real bug, CAN SOMEONE (preferably at 3com) PLEASE AT LEAST >SAY SO, so I have SOMETHING to tell my users? Or if nothing else, so I >know what code to downgrade to? This is really becoming a major problem >for us... It is a real bug (actually bugS, quite a few of them). Most are on the client side, as that is the most difficult piece to code. Most have been resolved in later releases from the client chipset vendors, though not all of the end-producers have released that to their end-users. Incrementally, they are nailing most of them pretty good. As a case in point, the latest LT Winmodem code is working well for many people from what I hear. I highly recommend continuing to recommend that your customers keep up to date on their client code. We also found some things on our side we could do better that will either accomodate some of the earlier code in the field and/or increase performance as a whole. And, yup, there are a few bug fixes in there too (including everything in 1.2.68). We are testing some of those V.90 improvements now, and hope to get a build out to limited field testing within the next week or so. 1.2.68 actually did have some fixes in there for these problems, but they were not significant. which is why I did not bill that ER as such. I thought I was pretty clear on that, sorry if there was any misconception there. I am glad to hear that it fixed some of your operational problems, as that was its' primary intent. Keep your eyes on this list, as I will definitely make a special point of posting the availability of any maintenance code. I do appreciate the patience, I understand the frustration you are experiencing. JP
Subject: Re: (usr-tc) v.90 connect problems
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-06 00:57:56
At 10:59 PM 11/5/98 -0600, John Powell wrote: >It is a real bug (actually bugS, quite a few of them). Most are on the >client side, as that is the most difficult piece to code. Most have been >resolved in later releases from the client chipset vendors, though not all >of the end-producers have released that to their end-users. Incrementally, >they are nailing most of them pretty good. As a case in point, the latest >LT Winmodem code is working well for many people from what I hear. I >highly recommend continuing to recommend that your customers keep up to >date on their client code. > >We also found some things on our side we could do better that will either >accomodate some of the earlier code in the field and/or increase >performance as a whole. And, yup, there are a few bug fixes in there too >(including everything in 1.2.68). We are testing some of those V.90 >improvements now, and hope to get a build out to limited field testing >within the next week or so. > >1.2.68 actually did have some fixes in there for these problems, but they >were not significant. which is why I did not bill that ER as such. I >thought I was pretty clear on that, sorry if there was any misconception >there. I am glad to hear that it fixed some of your operational problems, >as that was its' primary intent. > >Keep your eyes on this list, as I will definitely make a special point of >posting the availability of any maintenance code. I do appreciate the >patience, I understand the frustration you are experiencing. Thanks for the update. As a side note, I saw a lot of complaints on the 4.1.11 ARC code, so haven't upgraded from 4.0.30 yet. Has 4.1.78 resolved those issues for those that experienced them, or am I better sticking with 4.0.30 for now? Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: (usr-tc) Moving from Netserver to HiperARC problems
From: Randy Cosby <dcosby@infowest.com>
Date: 1998-11-06 10:52:59
Last night we had had what appeared to be a netserver death, so we replaced it with a spare hiperarc we had here. All seems to be configured right, but now we only get the first 3 lines on the first T1 answering. I'm sure I won't get help with this on the tech support line. Are there any extra steps that need to be taken when making this conversion? Yes, I'm running the 16 meg NMC. thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com
Subject: (usr-tc) Preventing the answering of a 128K ISDN call
From: Eric J. Lorenzo <lorenzo@ispchannel.com>
Date: 1998-11-06 11:05:21
How do you block in both a NETServer and a HARC the answering of a 128K ISDN calls? We don't want two modems being taken up by one user. Thanks, Eric
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-06 11:20:45
For what it's worth... We have the dead air problem and seems to have gotten much worst lately. We were running 2 seperate racks with 4 DSP's each and all seemed OK. When I put the 5th Dsp into each rack the problem worsened. They were all running 1.2.5 through channelized T1, not PRI. I have since upgraded to 1.2.68, no help. Since I have 3 racks running now with 5,5, and 2 DSp's in them, I am considering moving 1 DSP out of each of the first 2 racks so I would have 4,4 and 4 Dsp's in each rack. I don't even know if this will help. The dead air problem can't be client side, can it? I can beleive connection problems could be either, but not the dead air. > -----Original Message----- > The latest ER code i have received from 3COM is 1.2.68 on the HiPer DSP > (fixes dead random dead air, ring no answer, and strange tone > problems) and
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Eric Forcey <eric@psnw.com>
Date: 1998-11-06 12:04:37
This is the same problem that we were seeing, but in our case it was on T1 cards. Are you showing that the modems are getting hit when the user calls in? What we were showing was nothing hitting the chassis after about 5-6 calls came in. Ended up being fixed in an ER release for the CT1 card, however the Tech that finally came up with the solution of the ER release said that an interim fix (and he did this until he got the ER code to me) was to change attenJitterOnTxmtr to attenJitterOnRcvr, accept the settings, then go back and change the setting back to TX. Again, don't know if it is a possible related problem or not since the platforms are different. On Fri, 6 Nov 1998, John Powell wrote: > >The dead air problem can't be client side, can it? I can beleive > >connection problems could be either, but not the dead air. > > If you are talking about dead-air when the call is answered (ie, you call > it and there is no answer tone), you are correct, that would NOT be a > client problem (unless it's speaker is broken <grin>). > > Could be telco, but I doubt it. Have you been able to trap it in action, > seen the call come via mgmt or otherwise appearing on the HDM? > > JP > > > > > > "Terry Kennedy" <terry@olypen.com> on 11/06/98 01:20:45 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (John Powell/MW/US/3Com) > Subject: RE: (usr-tc) Latest ER code for HiPer > > > > > For what it's worth... We have the dead air problem and seems to have > gotten > much worst lately. We were running 2 seperate racks with 4 DSP's each and > all seemed OK. When I put the 5th Dsp into each rack the problem worsened. > They were all running 1.2.5 through channelized T1, not PRI. I have since > upgraded to 1.2.68, no help. Since I have 3 racks running now with 5,5, and > 2 DSp's in them, I am considering moving 1 DSP out of each of the first 2 > racks > so I would have 4,4 and 4 Dsp's in each rack. I don't even know if this > will > help. The dead air problem can't be client side, can it? I can beleive > connection > problems could be either, but not the dead air. > > > > -----Original Message----- > > > The latest ER code i have received from 3COM is 1.2.68 on the HiPer DSP > > (fixes dead random dead air, ring no answer, and strange tone > > problems) and > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-06 12:19:31
> Try setting the dsp's for round robin. Been there - done that > Did you restore from default on the > modems and the templates, save both to nvram and reboot? Been there - done that > What do you have for the number of dtmftones Can't find the setting, for one template 1 sets up mftones, not dtmftones, used to know that on the quads, used to set it to 4. Anis incoming and dnis incoming are set to zero - is that the same thing? > Could be telco, but I doubt it. Have you been able to trap it in action, > been the call come via mgmt or otherwise appearing on the HDM? >Are you showing that the modems are getting hit when the user calls in? On both these I can never catch it. If i pick up a hand or modem it will happen sometimes and the customers keep complaining, but Everytime I look for it it's not there. Modems answer fine the next call.
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-06 12:32:06
> What do you have for the number of dtmftones Can't find the setting, for one template 1 sets up mftones, not dtmftones, used to know that on the quads, used to set it to 4. Anis incoming and dnis incoming are set to zero - is that the same thing? Please ignore that last idiocy of mine. Was looking in the wrong place. T1 settings dtmf tones = 4. Should it be set to something else?
Subject: Re: (usr-tc) Latest ER code for HiPer
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-06 13:22:40
Eric Forcey writes... >What we were showing was nothing hitting the chassis after about 5-6 >calls came in. Ended up being fixed in an ER release for the CT1 card, >however the Tech that finally came up with the solution of the ER release >said that an interim fix (and he did this until he got the ER code to me) >was to change attenJitterOnTxmtr to attenJitterOnRcvr, accept the >settings, then go back and change the setting back to TX. This sounds like a good candidate for my mysterious alarm problem coming from HiPerDSPs that got fixed with the latest release. It's significant that the old help file lists transmitter attenuation as both the default and the suggested value for internally clocked (instead of loop timed) spans. I can almost guarantee every span in the know universe is looped timed, so why isn't "attenuate jitter on receiver" the default? -a
Subject: RE: (usr-tc) Moving from Netserver to HiperARC problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-06 13:40:41
What version of NMC code? What version of HiPer ARC? when you type list int what do you see? When you type list chassis what do you see? When you click on the modems and go to Configure/program settings/Line Interface Options what do you see for a line interface source. When you list IP pool what do you see? please be as detailed as possible when contacting this list. Other wise you are just wasting e-mails and time. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Cosby Sent: Friday, November 06, 1998 11:53 AM Last night we had had what appeared to be a netserver death, so we replaced it with a spare hiperarc we had here. All seems to be configured right, but now we only get the first 3 lines on the first T1 answering. I'm sure I won't get help with this on the tech support line. Are there any extra steps that need to be taken when making this conversion? Yes, I'm running the 16 meg NMC. thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.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) Latest ER code for HiPer
From: John Powell <john_powell@mw.3com.com>
Date: 1998-11-06 13:50:11
>The dead air problem can't be client side, can it? I can beleive >connection problems could be either, but not the dead air. If you are talking about dead-air when the call is answered (ie, you call it and there is no answer tone), you are correct, that would NOT be a client problem (unless it's speaker is broken <grin>). Could be telco, but I doubt it. Have you been able to trap it in action, seen the call come via mgmt or otherwise appearing on the HDM? JP "Terry Kennedy" <terry@olypen.com> on 11/06/98 01:20:45 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) For what it's worth... We have the dead air problem and seems to have gotten much worst lately. We were running 2 seperate racks with 4 DSP's each and all seemed OK. When I put the 5th Dsp into each rack the problem worsened. They were all running 1.2.5 through channelized T1, not PRI. I have since upgraded to 1.2.68, no help. Since I have 3 racks running now with 5,5, and 2 DSp's in them, I am considering moving 1 DSP out of each of the first 2 racks so I would have 4,4 and 4 Dsp's in each rack. I don't even know if this will help. The dead air problem can't be client side, can it? I can beleive connection problems could be either, but not the dead air. > -----Original Message----- > The latest ER code i have received from 3COM is 1.2.68 on the HiPer DSP > (fixes dead random dead air, ring no answer, and strange tone > problems) and - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-06 14:02:46
Yeah, figured that out, thanks. It is set to 4. The dtmftone setting I'm talking about is under the t1 trunk settings. Not on the modems themselves.
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-06 14:54:11
try setting the dsp's for round robin. Did you restore from default on the modems and the templates, save both to nvram and reboot? What do you have for the number of dtmftones ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Friday, November 06, 1998 1:21 PM For what it's worth... We have the dead air problem and seems to have gotten much worst lately. We were running 2 seperate racks with 4 DSP's each and all seemed OK. When I put the 5th Dsp into each rack the problem worsened. They were all running 1.2.5 through channelized T1, not PRI. I have since upgraded to 1.2.68, no help. Since I have 3 racks running now with 5,5, and 2 DSp's in them, I am considering moving 1 DSP out of each of the first 2 racks so I would have 4,4 and 4 Dsp's in each rack. I don't even know if this will help. The dead air problem can't be client side, can it? I can beleive connection problems could be either, but not the dead air. > -----Original Message----- > The latest ER code i have received from 3COM is 1.2.68 on the HiPer DSP > (fixes dead random dead air, ring no answer, and strange tone > problems) and - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) Latest ER code for HiPer
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-06 16:54:42
The dtmftone setting I'm talking about is under the t1 trunk settings. Not on the modems themselves. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Friday, November 06, 1998 2:20 PM > Try setting the dsp's for round robin. Been there - done that > Did you restore from default on the > modems and the templates, save both to nvram and reboot? Been there - done that > What do you have for the number of dtmftones Can't find the setting, for one template 1 sets up mftones, not dtmftones, used to know that on the quads, used to set it to 4. Anis incoming and dnis incoming are set to zero - is that the same thing? > Could be telco, but I doubt it. Have you been able to trap it in action, > been the call come via mgmt or otherwise appearing on the HDM? >Are you showing that the modems are getting hit when the user calls in? On both these I can never catch it. If i pick up a hand or modem it will happen sometimes and the customers keep complaining, but Everytime I look for it it's not there. Modems answer fine the next call. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) (TCS 3.3) MPIP between Netserver and HyperARC
From: Mark Lemmert <cto@athenet.net>
Date: 1998-11-06 17:20:27
A word to the wise for anybody upgrading to TCS 3.3: TCS 3.3 is supposed to have MPIP capability between HyperARCs and Netservers right out of the box. This is not the case. If anybody is trying to get this to work here is what you need to do: 1) The HyperARC must be the mpip server, 3com support staff has been saying the netserver will work as well. That is not accurate. 2) You will need to get a patch from support, 4.1.72 -7 to be put on the HyperARC. That fixes some problems with the hyperarc supporting some additional mpip extensions on the netserver. 3) Use the command 'set ppp rec pap' if you haven't already to restrict the ppp authentication protocol on the HyperARC to pap, otherwise it will try chap first and the mpip sessions will fail as the netserver uses pap and apparently you must have a common authentication protocol for mpip. Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net
Subject: Re: (usr-tc) v.90 connect problems
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-06 18:23:15
On Thu, 5 Nov 1998, John Powell wrote: > >If this is a real bug, CAN SOMEONE (preferably at 3com) PLEASE AT LEAST > >SAY SO, so I have SOMETHING to tell my users? Or if nothing else, so I > >know what code to downgrade to? This is really becoming a major problem > >for us... > > It is a real bug (actually bugS, quite a few of them). Most are on the > client side, as that is the most difficult piece to code. Most have been > resolved in later releases from the client chipset vendors, though not all > of the end-producers have released that to their end-users. Incrementally, > they are nailing most of them pretty good. As a case in point, the latest > LT Winmodem code is working well for many people from what I hear. I > highly recommend continuing to recommend that your customers keep up to > date on their client code. OK, but a fair number of the people having problems have Sportsters. (Some Winmodems, some not.) I wasn't aware there was any new Sportster code out... if there is, where's it hidden? If there isn't, is this one of the server-side problems? > We also found some things on our side we could do better that will either > accomodate some of the earlier code in the field and/or increase > performance as a whole. And, yup, there are a few bug fixes in there too > (including everything in 1.2.68). We are testing some of those V.90 > improvements now, and hope to get a build out to limited field testing > within the next week or so. OK... > 1.2.68 actually did have some fixes in there for these problems, but they > were not significant. which is why I did not bill that ER as such. I > thought I was pretty clear on that, sorry if there was any misconception > there. I am glad to hear that it fixed some of your operational problems, > as that was its' primary intent. Actually, you did make it clear. :) I wasn't expecting 1.2.68 to fix the v.90 problems, I was expecting it to fix the dead air problems... and it seems to have. I'm just trying to get a handle on how much of this is client-side and how much of this is server-side -- especially when the user has a 3com modem, which not surprisingly have been the most trouble free (until now).
Subject: Re: (usr-tc) (TCS 3.3) MPIP between Netserver and HyperARC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-06 20:30:03
On Fri, 6 Nov 1998, Mark Lemmert wrote: > A word to the wise for anybody upgrading to TCS 3.3: > > TCS 3.3 is supposed to have MPIP capability between > HyperARCs and Netservers right out of the box. This > is not the case. > > If anybody is trying to get this to work here is what > you need to do: > > > 1) The HyperARC must be the mpip server, 3com support > staff has been saying the netserver will work as well. > That is not accurate. The HiPer arc must be the Server and no one deny's this. It was always said and documented that the hiper arc should be server. > > > 2) You will need to get a patch from support, 4.1.72 -7 > to be put on the HyperARC. That fixes some problems > with the hyperarc supporting some additional mpip extensions > on the netserver. > > This is not correct. This is two early to say. You received this code perhaps 2 or three days ago. We have 3 instances of problems with MPIP, two problems with same symptoms and one different. You and one other customer had this problem. Hiper arc does work with MPIP with NETServer on 4.1.11 code - the only problem is with volume of calls and with time and code that the NETServer is using results in a list of non-disconnected MPIP links between the server and the client. If this code does fix the problem - then good we can say atleast in your case this code does fix the NETServer/Hiper arc issues. I would wait to get info from the other two customers before declaring this. > 3) Use the command 'set ppp rec pap' if you haven't already > to restrict the ppp authentication protocol on the HyperARC > to pap, otherwise it will try chap first and the mpip sessions > will fail as the netserver uses pap and apparently > you must have a common authentication protocol for mpip. > > Bundles and authentication. By default the NETServer starts pap first and hiper arc starts chap first, the second link depending upon the first link should use the same protocol to autheticate else the bundle owner will discard and disconnect ( prop. MPIP ) that is what you are seeing. You are right - you have to use the same auth protocol between the NETServer and the HiPer arc. krish > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.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) (TCS 3.3) MPIP between Netserver and HyperARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-06 20:56:44
Thus spake Mark Lemmert >If anybody is trying to get this to work here is what >you need to do: >1) The HyperARC must be the mpip server, 3com support > staff has been saying the netserver will work as well. > That is not accurate. Hrmm...they were pretty up front about that in the documentation...I'm surprised tech support is telling you that as it is clearly wrong. Another strike for tech support. :/ >3) Use the command 'set ppp rec pap' if you haven't already > to restrict the ppp authentication protocol on the HyperARC > to pap, otherwise it will try chap first and the mpip sessions > will fail as the netserver uses pap and apparently > you must have a common authentication protocol for mpip. Eh? That's funky. There's nothing in there that I saw that would require the same userid authentication. It will require that the userid be the same across the links in the bundle, as that's a requirement for MP to bundle the links together, but it shouldn't need the same authentication protocol that I'm aware of. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) HiPer MRTG
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-07 01:15:33
Can anyone point me at some help in setting up MRTG to monitor modem useage? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) HiPer MRTG
From: David OBrien <growler@ac.net>
Date: 1998-11-07 01:34:07
http://www.ac.net/modemuse not snmp but i like it. -Dave At 01:15 AM 11/7/98 -0500, you wrote: >Can anyone point me at some help in setting up MRTG to monitor modem useage? > >Thanks, >Kirk > > > >Kirk Mitchell-General Manager sysadmin@keyconn.net >Keystone Connect http://www.keyconn.net >Altoona, PA 814-941-5000 We Unlock the World > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) (TCS 3.3) MPIP between Netserver and HyperARC
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-11-07 08:27:52
> Another strike for tech support. :/ ...and here in Oz we're just about to start experiencing 3COM US tech support is seems. Our maintenance contract requires us to make an *international* call to the USA in order to get anything done :-( Regards, Bob Purdon, Technical Manager, Southern Internet Services.
Subject: Re: (usr-tc) HiPer MRTG
From: Richard Stuplich <dick@dwave.net>
Date: 1998-11-07 09:51:14
With pmwho (available at livingston's site) and hawho (from "http://home.dwave.net/arctools/") you can gather a list of users on ports and create a nice web page every 5 minutes, very useful. Take that file and do a grep "ESTABLISHED" | wc -l to get the number of connected users. With a small shell script you can make the mrtg file needed to graph this. The file looks like this, I think. (total connected users is 121 in this example) 0 121 0 0 Check the mrtg docs to be sure about the file structure. At 01:34 AM 11/7/98 -0500, you wrote: >http://www.ac.net/modemuse not snmp but i like it. >-Dave > >At 01:15 AM 11/7/98 -0500, you wrote: >>Can anyone point me at some help in setting up MRTG to monitor modem useage? >> >>Thanks, >>Kirk >> >> >> >>Kirk Mitchell-General Manager sysadmin@keyconn.net >>Keystone Connect http://www.keyconn.net >>Altoona, PA 814-941-5000 We Unlock the World >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. > > Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 17 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to have redundant T1 NAP connections, All modem compatibility and a staff dedicated exclusively to providing Internet Service to this area. This E-Mail Copyright 1998 Richard Stuplich, see http://dw.net/cr/
Subject: Re: (usr-tc) HiPer MRTG
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-07 10:24:27
http://www.dcr.net/~mandrews/usrtoys, at the very bottom of the page, has some NETserver and ARC configs for MRTG... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 7 Nov 1998, David OBrien wrote: > http://www.ac.net/modemuse not snmp but i like it. > -Dave > > At 01:15 AM 11/7/98 -0500, you wrote: > >Can anyone point me at some help in setting up MRTG to monitor modem useage? > > > >Thanks, > >Kirk > > > > > > > >Kirk Mitchell-General Manager sysadmin@keyconn.net > >Keystone Connect http://www.keyconn.net > >Altoona, PA 814-941-5000 We Unlock the World > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-07 11:03:37
Jeff, I have them set to round robin on the DSP's and still have the problem. I understand what you are saying but then if that's so shouldn't the problem be gone. > > Guys...this *isn't* a bug. The ds0 is reset'ing, the modem is > reset'ing...just the ds0 is faster at it is all. If you use > fixed-assignment on the DSP's with first-available from the telco, this > is the risk you take and what you're going to run into. Either don't > use first-available with the telco, or don't use fixed-assignment on the > DSP's, that's all there is to it. > -- > Jeff McAdams Email: jeffm@iglou.com
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-07 11:03:37
Jeff, I have them set to round robin on the DSP's and still have the problem. I understand what you are saying but then if that's so shouldn't the problem be gone. > > Guys...this *isn't* a bug. The ds0 is reset'ing, the modem is > reset'ing...just the ds0 is faster at it is all. If you use > fixed-assignment on the DSP's with first-available from the telco, this > is the risk you take and what you're going to run into. Either don't > use first-available with the telco, or don't use fixed-assignment on the > DSP's, that's all there is to it. > -- > Jeff McAdams Email: jeffm@iglou.com
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Brian <signal@shreve.net>
Date: 1998-11-07 11:44:10
On Fri, 6 Nov 1998, Brian K McIntire wrote: > try setting the dsp's for round robin. Did you restore from default on the > modems and the templates, save both to nvram and reboot? > What do you have for the number of dtmftones > I have seen dead-air on answer on our racks from time to time. I run fixed assignment right now on the HDM's and may try Round-Robin to see if this clears things up. Has 3Com acknowledged that their is an issue with fixed assignment on the HDM's? > ======================================================================= > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = = > = Experts in Remote Access and all areas of NetWork Design, = > = Security, and Implementation. Offering both installation and = > = support, along with remote management and monitoring packages for = > = dedicated clients (specializing in ISP's). = > = Firm partnerships established with all the key players. = > = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = > = = > = Serving North America and parts of Canada. Reselling to the world. = > ======================================================================= > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy > Sent: Friday, November 06, 1998 1:21 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Latest ER code for HiPer > > > For what it's worth... We have the dead air problem and seems to have gotten > much worst lately. We were running 2 seperate racks with 4 DSP's each and > all seemed OK. When I put the 5th Dsp into each rack the problem worsened. > They were all running 1.2.5 through channelized T1, not PRI. I have since > upgraded to 1.2.68, no help. Since I have 3 racks running now with 5,5, and > 2 DSp's in them, I am considering moving 1 DSP out of each of the first 2 > racks > so I would have 4,4 and 4 Dsp's in each rack. I don't even know if this will > help. The dead air problem can't be client side, can it? I can beleive > connection > problems could be either, but not the dead air. > > > > -----Original Message----- > > > The latest ER code i have received from 3COM is 1.2.68 on the HiPer DSP > > (fixes dead random dead air, ring no answer, and strange tone > > problems) and > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-07 12:01:01
Are you certain all your trunks are configured for 4 from the telco. In other words, are they sending and DNIS digits ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Friday, November 06, 1998 4:03 PM Yeah, figured that out, thanks. It is set to 4. The dtmftone setting I'm talking about is under the t1 trunk settings. Not on the modems themselves. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) Latest ER code for HiPer
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-07 13:55:03
Thus spake Brian >On Fri, 6 Nov 1998, Brian K McIntire wrote: >> try setting the dsp's for round robin. Did you restore from default on the >> modems and the templates, save both to nvram and reboot? >> What do you have for the number of dtmftones >I have seen dead-air on answer on our racks from time to time. I run >fixed assignment right now on the HDM's and may try Round-Robin to see if >this clears things up. Has 3Com acknowledged that their is an issue with >fixed assignment on the HDM's? Guys...this *isn't* a bug. The ds0 is reset'ing, the modem is reset'ing...just the ds0 is faster at it is all. If you use fixed-assignment on the DSP's with first-available from the telco, this is the risk you take and what you're going to run into. Either don't use first-available with the telco, or don't use fixed-assignment on the DSP's, that's all there is to it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Latest ER code for HiPer
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-07 14:44:30
Thus spake Terry Kennedy >Jeff, I have them set to round robin on the DSP's and still >have the problem. I understand what you are saying but then >if that's so shouldn't the problem be gone. Not necessarily...it could happen if there's only the one ds0 free on the span...if it drops, it will almost immediately be filled again with the next call...at this point (particularly with chan-t1's don't know how the DSP's deal with pri's) there's only the one modem available, and the one ds0, so you're in the same situation ultimately. The only *real* solutions that could be come up with would be to speed up modem resets (or skip them altogether? is that possible?), slow down ds0 reset's...someone mentioned getting the telco to do this, or possibly putting the ds0 in localoutofservice after a call hangs up for a brief period of time giving the modem time to reset and then putting the ds0 back inservice. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) HiPer MRTG
From: Andre Gustavo de Carvalho Albuquerque <gustavo@anita.visualnet.com.br>
Date: 1998-11-07 15:06:09
Richard Stuplich wrote: :) With pmwho (available at livingston's site) and hawho (from :) "http://home.dwave.net/arctools/") you can gather a list of users on ports :) and create a nice web page every 5 minutes, very useful. :) :) Take that file and do a grep "ESTABLISHED" | wc -l to get the number of :) connected users. With a small shell script you can make the mrtg file :) needed to graph this. The file looks like this, I think. (total connected :) users is 121 in this example) :) :) 0 :) 121 :) 0 :) 0 :) :) Check the mrtg docs to be sure about the file structure. :) What about: Target[hiper]: 1.3.6.1.4.1.429.4.2.1.10.0&1.3.6.1.4.1.429.4.2.1.10.0:community@host It would be much more simple, isn't it? Regards, Gustavo -- ____________________________________________________________________ Andre Gustavo de C. Albuquerque gustavo@visualnet.com.br PGP Public Key: http://www.visualnet.com.br/~gustavo/pgpkey.asc
Subject: Re: (usr-tc) v.90 connect problems
From: John Powell <john_powell@mw.3com.com>
Date: 1998-11-07 21:15:26
>OK, but a fair number of the people having problems have Sportsters. >(Some Winmodems, some not.) I wasn't aware there was any new Sportster >code out... if there is, where's it hidden? If there isn't, is this one >of the server-side problems? I was responding to your comments on LT Winmodems, you did not mention Sportsters. I know of no significant issues with interop with Sportsters (Winmodem or controller based) and Total Control modems. There will likely be improvements with the client side (all vendors) for quite some time. There are quite a few tweeks to enhance performance and coverage in the labs already. Heck, we are still improving V.34 4 years later. If you can provide details on problems with Sportsters, I will gladly take this off-line and put you in contact with my peers on the PCD (home of the Sportster) side of the house. JP PS. No, there are no recent releases of Sportster code related to V.90 fixes. Overall, they are working quite well.
Subject: RE: (usr-tc) Latest ER code for HiPer
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-08 04:05:35
-----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Saturday, November 07, 1998 1:45 PM Thus spake Terry Kennedy >Jeff, I have them set to round robin on the DSP's and still >have the problem. I understand what you are saying but then >if that's so shouldn't the problem be gone. Not necessarily...it could happen if there's only the one ds0 free on the span...if it drops, it will almost immediately be filled again with the next call...at this point (particularly with chan-t1's don't know how the DSP's deal with pri's) there's only the one modem available, and the one ds0, so you're in the same situation ultimately. The only *real* solutions that could be come up with would be to speed up modem resets (or skip them altogether? is that possible?), slow down ds0 reset's...someone mentioned getting the telco to do this I haven't verified it but the person that mentioned it said the telco sets their DS0 reset to 10ms by default and indicated the reset could be anything all the way up to 2500ms. I suppose adjusting this may help , or possibly putting the ds0 in localoutofservice after a call hangs up for a brief period of time giving the modem time to reset and then putting the ds0 back inservice. -- 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) Latest ER code for HiPer
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-08 10:01:18
Is there a way to busy out the dso for a coupleof secounds? I do this with my analog gear. It seems that 3com would have put this in the code somewhere -----Original Message----- >Thus spake Terry Kennedy >>Jeff, I have them set to round robin on the DSP's and still >>have the problem. I understand what you are saying but then >>if that's so shouldn't the problem be gone. > >Not necessarily...it could happen if there's only the one ds0 free on >the span...if it drops, it will almost immediately be filled again with >the next call...at this point (particularly with chan-t1's don't know >how the DSP's deal with pri's) there's only the one modem available, and >the one ds0, so you're in the same situation ultimately. The only >*real* solutions that could be come up with would be to speed up modem >resets (or skip them altogether? is that possible?), slow down ds0 >reset's...someone mentioned getting the telco to do this, or possibly >putting the ds0 in localoutofservice after a call hangs up for a brief >period of time giving the modem time to reset and then putting the ds0 >back inservice. >-- >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) Latest ER code for HiPer
From: Brian <signal@shreve.net>
Date: 1998-11-08 15:27:30
On Sat, 7 Nov 1998, Jeff Mcadams wrote: > Thus spake Brian > >On Fri, 6 Nov 1998, Brian K McIntire wrote: > >> try setting the dsp's for round robin. Did you restore from default on the > >> modems and the templates, save both to nvram and reboot? > >> What do you have for the number of dtmftones > > >I have seen dead-air on answer on our racks from time to time. I run > >fixed assignment right now on the HDM's and may try Round-Robin to see if > >this clears things up. Has 3Com acknowledged that their is an issue with > >fixed assignment on the HDM's? > > Guys...this *isn't* a bug. The ds0 is reset'ing, the modem is > reset'ing...just the ds0 is faster at it is all. If you use > fixed-assignment on the DSP's with first-available from the telco, this > is the risk you take and what you're going to run into. Either don't > use first-available with the telco, or don't use fixed-assignment on the > DSP's, that's all there is to it. makes sense. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: (usr-tc) De-encrypting
From: Ken Hodges <ken@rabun.net>
Date: 1998-11-08 16:15:15
Does anybody know of a way to de-encrypt the passwords in the TC$A database ? Any help would be MOST appreciated. Thanks, Ken _______________________________________ Ken Hodges, President and CEO ACME BrainWorks Internet Services, Inc. Clayton Computers, Inc. Rabun County, Georgia "Where Spring Spends the Summer" http://www.acme-brain.com or http://www.rabun.net ken@rabun.net 1-706-782-9239
Subject: (usr-tc) HiperARC for sale
From: G. Owens <gowens@seark.net>
Date: 1998-11-08 17:00:19
We currently have a HiperARC chassis with NMC card, Hiper access router card, and 70A power supply for sale...... $3,700.00 Also anyone know a source for used DSP cards? Greg Owens Magnolia InterNet Services gowens@magnolia-net.com
Subject: (usr-tc) HiPerDSP - SNMP Get: No such name (help needed)
From: Andy <beezer@xmission.com>
Date: 1998-11-09 00:14:08
USR-TC archive didn't seem to have anything on this, so I'll try here. In short, I preconfigured a HiPerDSP on a HiPerDSP/ARC chassis then shipped it to a remote POP for installation on a Quad/NETServer chassis (something I was told could be done with the right NMC flash update). I can hardware-reset the card, but receive "SNMP Get: No such name" when I try to control it's Programmed Settings, Performance Monitor, etc; although I can ping it. Reseating the HiPerDSP and resetting the NMC doesn't help. Pete Ashdown that knows this stuff forwards and back is unavailable this week and I know only enough to be dangerous. This leaves me clueless and with our POP saturated. Any timely help would be much appreciated. Some details on the remote POP are: Slot H/W version S/W version ------ ------------------------------ -------------- -------------- 1 DUAL T1 NIC/NAC 3.0.0 3.5.0 2-13 Quad V.34 NIC/NAC 2.0.0 5.10.9 14 High-Density NIC/NAC 0.49.0 1.0.7 15 {empty} 16 3COM ISDN NETServer NAC 0.10.0 3.8.1 17 3COM NMC w/clock 3.0 5.4.95 18 {active supply #1} 19 {active supply #2} Using TCM/UNIX 05.05.01 As a side note, 5 of the Quad modems (s2c2, s5c2, s10c2, s11c4, s12c4) are not answering calls. I've compared their settings with functioning modems, reflashed, reseated and reset them (hard/soft), but still they do not answer. The telco says the trunks are in least-used distributed hunt order, and I get slow busy with all but those 5 filled, so I'm unclear what is causing this secondary problem and if it was a result of flashing up to 5.4.95 on the NMC. Andy Dalrymple XMission Technical Support ---
Subject: Re: (usr-tc) Latest ER code for HiPer
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-09 08:08:09
Thus spake Terry Kennedy >Is there a way to busy out the dso for >a coupleof secounds? I do this with my analog gear. >It seems that 3com would have put this in the code somewhere Depends on the signaling code you use. If you're on chan-t1, there should be a soft busyout that you can use. On PRI, you can set the channels local out of service...that is unless you're using NI-2 which doesn't support service messages. With fixed-assignment on the modems, I suspect you can autoresponse this behavior into the DSP's...assuming the DSP's support auto-response. Again, we don't have any HiPer stuff here at all (one ARC demo to play with actually, but that's it) so I don't know the config on these things at all. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) 10 DSP, 1 NMC, 2 ARC configuration
From: Mailing List Reader <mlist@strato.net>
Date: 1998-11-09 09:16:35
We have a TC chassis with 10 DSP cards, 1 NMC and 1 ARC card. We would like to add a second ARC card. The manual implies that there is a way to load balance automatically the DSP cards between the 2 ARC cards. Note the reference to DSA and the last sentence from this excerpt from the manual: In order to properly configure more than one HiPer ARC on the Hub, statically configure your installed modem cards by setting their card type ownership or dynamically configure the cards using Dynamic Slot Assignment (DSA). A third method employs DSA rebalancing which periodically reassigns slot ownership by the Network Management Card (NMC). (end manual excerpt) We understand how to assign ownership manually however it seems that that the cards should be able to do this themselves. Can the ARC cards be set so that they share the load and automatically compensate for the removal/insertion of one of the ARC cards? If this is possible how are the ippools set on each of the ARC cards? Does each card have : a. 1/2(120) the pool? b. the whole(240) pool? c. total(240) yet different pools? Anyone have experience with this configuration?
Subject: RE: (usr-tc) HiPer MRTG
From: Eric Billeter <ebilleter@cableone.net>
Date: 1998-11-09 09:27:30
I have some scripts that do a snmpwalk of the chassis to check the state of the DS0. I have them for the hiper chassis and also for the dual PRI and T1. The zip includes 4 files TCH-PRI.pl for dual PRI config TCH-T1.pl for dual T1 config hiperdsp.pl for hiperdsp config mrtg.cfg a snippet of the config for mrtg. Copy and paste this into your mrtg.cfg file. Of course you will need to put in the correct community and ip addresses. http://mrtg.cableone.net Active graphs http://mrtg.cableone.net/tch-mrtg.zip Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell Sent: Friday, November 06, 1998 11:16 PM Can anyone point me at some help in setting up MRTG to monitor modem useage? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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: (no subject)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-09 10:17:57
Does anyone know how to get a copy of the Cistron RADIUS. I've heard a lot of people talking about it but did not see if anyone said where to find it. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = =======================================================================
Subject: RE: (usr-tc) RADIUS Cistron
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-09 11:13:20
My thanks to you and Bogdan Pelinescu. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Cedric MARSOT Sent: Monday, November 09, 1998 10:05 AM Sorry ... this is the good link: ftp://ftp.cistron.nl/pub/people/miquels/radius/ Cedric MARSOT - INTERVALLE Tel : +33 (0)1 49 72 58 58 Chef Produits d'Acces Distants Fax : +33 (0)1 49 72 58 59 Email: mailto:Cedric.Marsot@intervalle.fr Pager : +33 (0)6 06 49 14 43 Web: http://www.intervalle.fr Mobile: +33 (0)6 60 21 76 79 Pager: mailto:0606491443@kobby.worldnet.net MCT NT WKS/SRV, Win95, Tcpip, Exchange, IIS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire > Sent: Monday, November 09, 1998 5:18 PM > To: usr tc > Subject: > > > Does anyone know how to get a copy of the Cistron RADIUS. > I've heard a lot > of people talking about it but did not see if anyone said > where to find it. > > ============================================================== > ========= > = Brian K. McIntire > bmcintire@commnet.com = > = Systems Engineer III > 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) NT user and bundling MP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-09 11:47:08
OK...I know I've seen the answer to this somewhere, but can't find it (even after looking through the archives). Have a customer using NT dialing in with 2 channels...The problem being that NT (at least with the Sportster modem he's using) dials both channels at the same time, and then tries to bundle them together. Just about every other piece of dial-up equipment/software I've seen with dial the first channel, establish the bundle, then dial the second channel. My understanding is that there is a way to make NT do this (ie, not dial both channels at once), but I don't know NT enough to tell my customer where to go to set this. Anyone have any ideas on this? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) RE:
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-11-09 12:32:50
On Monday, November 09, 1998 12:18 PM, Brian K McIntire [SMTP:bmcintire@commnet.com] wrote: > Does anyone know how to get a copy of the Cistron RADIUS. I've heard a lot > of people talking about it but did not see if anyone said where to find it. > http://miquels.www.cistron.nl/radius/ Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 A quart of wheat for a day's wages, and three quarts of barley for a day's wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject: Re: (usr-tc) HiPerDSP - SNMP Get: No such name (help needed)
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-09 13:29:10
You have the wrong NMC code version. 5.4.95 is for 4 meg cards. If the middle number of the release is even, it's a 4 meg release that can't manage HiPer cards. If the middle number is odd, it's a 16 meg release that can. You need release 5.5.5, and you will also need 16 meg of RAM and 8 meg of flash on your NMC to run it. If your NMC only has 4 meg, you either need to upgrade it, swap in another NMC that has more memory, or remove the DSP. The only thing I can suggest on the Quads is to busy out the DS0's on the T1's and then unbusy them again. Sometimes this helps, at least on our PRI-from-DMS100 setup... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Mon, 9 Nov 1998, Andy wrote: > > USR-TC archive didn't seem to have anything on this, so I'll try here. > > > In short, I preconfigured a HiPerDSP on a HiPerDSP/ARC chassis then > shipped it to a remote POP for installation on a Quad/NETServer chassis > (something I was told could be done with the right NMC flash update). I > can hardware-reset the card, but receive "SNMP Get: No such name" when I > try to control it's Programmed Settings, Performance Monitor, etc; > although I can ping it. Reseating the HiPerDSP and resetting the NMC > doesn't help. > > Pete Ashdown that knows this stuff forwards and back is unavailable this > week and I know only enough to be dangerous. This leaves me clueless and > with our POP saturated. Any timely help would be much appreciated. > > > Some details on the remote POP are: > > Slot H/W version S/W version > ------ ------------------------------ -------------- -------------- > 1 DUAL T1 NIC/NAC 3.0.0 3.5.0 > 2-13 Quad V.34 NIC/NAC 2.0.0 5.10.9 > 14 High-Density NIC/NAC 0.49.0 1.0.7 > 15 {empty} > 16 3COM ISDN NETServer NAC 0.10.0 3.8.1 > 17 3COM NMC w/clock 3.0 5.4.95 > 18 {active supply #1} > 19 {active supply #2} > > Using TCM/UNIX 05.05.01 > > As a side note, 5 of the Quad modems (s2c2, s5c2, s10c2, s11c4, s12c4) are > not answering calls. I've compared their settings with functioning > modems, reflashed, reseated and reset them (hard/soft), but still they do > not answer. The telco says the trunks are in least-used distributed hunt > order, and I get slow busy with all but those 5 filled, so I'm unclear > what is causing this secondary problem and if it was a result of flashing > up to 5.4.95 on the NMC. > > > Andy Dalrymple > XMission Technical Support
Subject: Re: (usr-tc) Latest ER code for HiPer
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-09 13:31:39
On Sat, 7 Nov 1998, Jeff Mcadams wrote: > Thus spake Brian > >On Fri, 6 Nov 1998, Brian K McIntire wrote: > >> try setting the dsp's for round robin. Did you restore from default on the > >> modems and the templates, save both to nvram and reboot? > >> What do you have for the number of dtmftones > > >I have seen dead-air on answer on our racks from time to time. I run > >fixed assignment right now on the HDM's and may try Round-Robin to see if > >this clears things up. Has 3Com acknowledged that their is an issue with > >fixed assignment on the HDM's? > > Guys...this *isn't* a bug. The ds0 is reset'ing, the modem is > reset'ing...just the ds0 is faster at it is all. If you use > fixed-assignment on the DSP's with first-available from the telco, this > is the risk you take and what you're going to run into. Either don't > use first-available with the telco, or don't use fixed-assignment on the > DSP's, that's all there is to it. ...except that several people said that round-robin assignment was broken on DSP's and only fixed-assignment worked correctly. This was probably fixed in 1.2.68... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep
Subject: (usr-tc) T1 parameters
From: Richard Lorbieski <richard@mail.alpha1.net>
Date: 1998-11-09 14:28:53
We plan to install a T1 (not PRI) in one of our pops. What are the recomended settings for the DSP/Hiper ARC chassis (line coding, start signal, etc...)? I lost the paper 3com sent me a few months ago. Richard Lorbieski
Subject: Re: (usr-tc) T1 parameters
From: Curt Shambeau <curt@execpc.com>
Date: 1998-11-09 14:50:51
> We plan to install a T1 (not PRI) in one of our pops. What are the > recomended settings for the DSP/Hiper ARC chassis (line coding, start > signal, etc...)? I lost the paper 3com sent me a few months ago. ESF/B8ZS on the T1. Make sure it is Trunk Side, not Line side if you get stuck with D4/AMI. We use wink start. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |
Subject: (usr-tc) Netserver 16 and VSA - URGENT HELP NEEDED
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-11-09 15:53:20
Can anyone tell me why a Netserver 16, running 3.3.0 software doesn't send radius VSA ? Do I have to set something extra ? I REALLY need VSA support. I used Mike Wronski's radddebug to see the radius packets and I was a little bit shocked by the result. Below it's a sample of a start and stop packets: Code :Accounting-Request(4) Identifier :223 Length :88 Acct-Session-Id( 44) Len: 10 Value: 0400287D User-Name( 1) Len: 10 Value: xxxx Client-Id( 4) Len: 6 Value: xx.xx.xx.xx Client-Port-Id( 5) Len: 6 Value: 7 Acct-Status-Type( 40) Len: 6 Value: Start(1) Acct-Authentic( 45) Len: 6 Value: RADIUS(1) User-Service-Type( 6) Len: 6 Value: Framed-User(2) Framed-Protocol( 7) Len: 6 Value: PPP(1) Framed-Address( 8) Len: 6 Value: xx.xx.xx.xx Acct-Delay-Time( 41) Len: 6 Value: 0 Code :Accounting-Request(4) Identifier :221 Length :100 Acct-Session-Id( 44) Len: 10 Value: 0400287C User-Name( 1) Len: 10 Value: xxxx Client-Id( 4) Len: 6 Value: xx.xx.xx.xx Client-Port-Id( 5) Len: 6 Value: 7 Acct-Status-Type( 40) Len: 6 Value: Stop(2) Acct-Session-Time( 46) Len: 6 Value: 73 Acct-Terminate-Cause( 49) Len: 6 Value: 0 Acct-Authentic( 45) Len: 6 Value: RADIUS(1) User-Service-Type( 6) Len: 6 Value: Framed-User(2) Framed-Protocol( 7) Len: 6 Value: PPP(1) Framed-Address( 8) Len: 6 Value: xx.xx.xx.xx Acct-Delay-Time( 41) Len: 6 Value: 0 Thanks, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |
Subject: Re: (usr-tc) Latest ER code for HiPer
From: Brian Uechi <brianu@lava.net>
Date: 1998-11-09 16:45:56
On Sat, 7 Nov 1998, Jeff Mcadams wrote: > Thus spake Terry Kennedy > >Jeff, I have them set to round robin on the DSP's and still > >have the problem. I understand what you are saying but then > >if that's so shouldn't the problem be gone. > > Not necessarily...it could happen if there's only the one ds0 free on > the span...if it drops, it will almost immediately be filled again with > the next call...at this point (particularly with chan-t1's don't know > how the DSP's deal with pri's) there's only the one modem available, and > the one ds0, so you're in the same situation ultimately. Since PRI only have 23 lines but the DSP has 24 modems you'd think this wouldn't happen on PRI. But the the last time I looked only 23 modems are used in DSP PRI configurations. I think this problem is not present in the quads/dual PRI because all 48 modems are used. A partial solution (for PRI users only) is for 3Com to include all 24 DSP modems in the pool.
Subject: (usr-tc) RE:
From: Cedric MARSOT <cedric.marsot@intervalle.fr>
Date: 1998-11-09 16:50:46
I don't remember where I have download it, but I can send you by email. Cedric MARSOT - INTERVALLE Tel : +33 (0)1 49 72 58 58 Chef Produits d'Acces Distants Fax : +33 (0)1 49 72 58 59 Email: mailto:Cedric.Marsot@intervalle.fr Pager : +33 (0)6 06 49 14 43 Web: http://www.intervalle.fr Mobile: +33 (0)6 60 21 76 79 Pager: mailto:0606491443@kobby.worldnet.net MCT NT WKS/SRV, Win95, Tcpip, Exchange, IIS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire > Sent: Monday, November 09, 1998 5:18 PM > To: usr tc > Subject: > > > Does anyone know how to get a copy of the Cistron RADIUS. > I've heard a lot > of people talking about it but did not see if anyone said > where to find it. > > ============================================================== > ========= > = Brian K. McIntire > bmcintire@commnet.com = > = Systems Engineer III > 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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:
From: Cedric MARSOT <cedric.marsot@intervalle.fr>
Date: 1998-11-09 16:52:18
I have just found it ... Just check this ... ftp://ftp.cistron.nl/pub/cistron/ Cedric MARSOT - INTERVALLE Tel : +33 (0)1 49 72 58 58 Chef Produits d'Acces Distants Fax : +33 (0)1 49 72 58 59 Email: mailto:Cedric.Marsot@intervalle.fr Pager : +33 (0)6 06 49 14 43 Web: http://www.intervalle.fr Mobile: +33 (0)6 60 21 76 79 Pager: mailto:0606491443@kobby.worldnet.net MCT NT WKS/SRV, Win95, Tcpip, Exchange, IIS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire > Sent: Monday, November 09, 1998 5:18 PM > To: usr tc > Subject: > > > Does anyone know how to get a copy of the Cistron RADIUS. > I've heard a lot > of people talking about it but did not see if anyone said > where to find it. > > ============================================================== > ========= > = Brian K. McIntire > bmcintire@commnet.com = > = Systems Engineer III > 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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 Cistron
From: Cedric MARSOT <cedric.marsot@intervalle.fr>
Date: 1998-11-09 17:04:47
Sorry ... this is the good link: ftp://ftp.cistron.nl/pub/people/miquels/radius/ Cedric MARSOT - INTERVALLE Tel : +33 (0)1 49 72 58 58 Chef Produits d'Acces Distants Fax : +33 (0)1 49 72 58 59 Email: mailto:Cedric.Marsot@intervalle.fr Pager : +33 (0)6 06 49 14 43 Web: http://www.intervalle.fr Mobile: +33 (0)6 60 21 76 79 Pager: mailto:0606491443@kobby.worldnet.net MCT NT WKS/SRV, Win95, Tcpip, Exchange, IIS > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire > Sent: Monday, November 09, 1998 5:18 PM > To: usr tc > Subject: > > > Does anyone know how to get a copy of the Cistron RADIUS. > I've heard a lot > of people talking about it but did not see if anyone said > where to find it. > > ============================================================== > ========= > = Brian K. McIntire > bmcintire@commnet.com = > = Systems Engineer III > 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) 70 amp nic
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-09 17:17:44
Anyone have one for sell. We have the power supply. Just need the back
Subject: (usr-tc) Re:
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-11-09 17:49:11
Date sent: Mon, 9 Nov 1998 10:17:57 -0600 Send reply to: usr-tc@lists.xmission.com > Does anyone know how to get a copy of the Cistron RADIUS. I've heard a lot > of people talking about it but did not see if anyone said where to find it. > Try http://www.mdi.ca/sysadmin/cistron/ or http://miquels.www.cistron.nl/radius/ You'll not regret it :-) Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |
Subject: (usr-tc) Re:
From: michel@gamepoint.net
Date: 1998-11-10 00:34:54
At 10:17 9-11-98 -0600, you wrote: >Does anyone know how to get a copy of the Cistron RADIUS. I've heard a lot >of people talking about it but did not see if anyone said where to find it. > Try an email to iljitsch@pine.nl He has worked with the cistron radius (dont know if its available to others)
Subject: RE: (usr-tc) HiperARC
From: Marshall Morgan <marshall@netdoor.com>
Date: 1998-11-10 06:17:52
On Tuesday, November 10, 1998 5:11 AM, Phil Le Clercq [SMTP:phil.le.clercq@cinergy.net] wrote: > Hi all, > I am after some basic config. ideas. Currently we are just a netserver and > digital quad modem site. > We are contracted to upgrade to HiperARC, the question is do all isdn calls > terminate on the arc, like on the netserver or do they have to end up on a > modem whether it be quad or DSP? all ISDN calls are terminated on Quad I Modems or HiperDSP modems Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com 601.969.1434 x28 | 800.952.1570 x28 | 601.969.3629 x28 | Fax 601.969.3838
Subject: Re: (usr-tc) Latest ER code for HiPer
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-10 08:11:32
Thus spake Brian Uechi >On Sat, 7 Nov 1998, Jeff Mcadams wrote: >> Not necessarily...it could happen if there's only the one ds0 free on >> the span...if it drops, it will almost immediately be filled again with >> the next call...at this point (particularly with chan-t1's don't know >> how the DSP's deal with pri's) there's only the one modem available, and >> the one ds0, so you're in the same situation ultimately. >Since PRI only have 23 lines but the DSP has 24 modems you'd think >this wouldn't happen on PRI. But the the last time I looked only 23 >modems are used in DSP PRI configurations. I think this problem is >not present in the quads/dual PRI because all 48 modems are used. A >partial solution (for PRI users only) is for 3Com to include all 24 >DSP modems in the pool. I *thought* I had heard that behavior for PRI's on DSP's, but wasn't sure. It is kinda goofy. Also, would be nice to have a first-available settings for the modem assignment such as with the dual-pri cards and quad's. This is what we use and we almost never run into problems with this. Its *very* rare that it skips a resetting modem and gets into the last two modems in the rack though, too. I'll go through and do a visual check of our racks and if any have one or both of the last two modems used, I go on a "wigged out modem hunt" on that chassis. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) HiperARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-10 08:13:46
Thus spake Phil Le Clercq >We are contracted to upgrade to HiperARC, the question is do all isdn calls >terminate on the arc, like on the netserver or do they have to end up on a >modem whether it be quad or DSP? You *should* be terminating your ISDN calls on quads anyway...in general, it works much better. The Arc's will not terminate ISDN calls themselves at all, they *must* be handled by the modem cards (be it quad's or DSP's). There really is little to no downside to this. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) CONNECTION PROBLEM
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-11-10 08:56:00
We have a customer who has Brother NB-80C Geobook trying to connect with us on a HiperArc running 4.1.78 code. The call continually fails in the LCP negotiation stage and we never see the userid and password get sent. The Geobook is a replacement because he had so many problems with the old one. With the old one he was able to connect with us but since then we have done a couple of HiPerArc release upgrades. Below is a copy of a MONITOR PPP trace from the HiPerArc. I am concerned this may be a HiPerArc problem but I want to be sure. We have sent the trace on to Brother too. They do include a diskette from Earthlink and it does work with them. Does anyone have a document for decoding these traces and figuring out what is going on ? We spoke to Brother and they were no help. Basically mumbling things like if you are trying to connect to an NT server it won't work and we only support dialing into Unix machines. They said send them to Earthlink. I don't think we want to start eliminating groups of users from our collective ISps based upon the equipment the end user has. That doesn't seem to be good business practice. Jeff Binkley ASA Network Computing Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 QUAL_PROTO c0 25 00 00 03 e8 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REJ QUAL_PROTO c0 25 00 00 03 e8 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP MPP_MRRU 05 ea LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 43 de 5f 5d PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:3/mod:1 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 cd df 13 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:3/mod:1 LCP CFG_REJ MRU 05 ea MPP_MRRU 05 ea MPP_ENDPTID 00 Brother hangs up at this point...
Subject: (usr-tc) Netserver 16 doesn't send VSA ?
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-11-10 09:48:57
Can anyone tell me why a Netserver 16, running 3.3.0 software doesn't send radius VSA ? Do I have to set something extra ? I REALLY need VSA support. I used Mike Wronski's radddebug to see the radius packets and I was a little bit shocked by the result. Below it's a sample of a start and stop packets: Code :Accounting-Request(4) Identifier :223 Length :88 Acct-Session-Id( 44) Len: 10 Value: 0400287D User-Name( 1) Len: 10 Value: xxxx Client-Id( 4) Len: 6 Value: xx.xx.xx.xx Client-Port-Id( 5) Len: 6 Value: 7 Acct-Status-Type( 40) Len: 6 Value: Start(1) Acct-Authentic( 45) Len: 6 Value: RADIUS(1) User-Service-Type( 6) Len: 6 Value: Framed-User(2) Framed-Protocol( 7) Len: 6 Value: PPP(1) Framed-Address( 8) Len: 6 Value: xx.xx.xx.xx Acct-Delay-Time( 41) Len: 6 Value: 0 Code :Accounting-Request(4) Identifier :221 Length :100 Acct-Session-Id( 44) Len: 10 Value: 0400287C User-Name( 1) Len: 10 Value: xxxx Client-Id( 4) Len: 6 Value: xx.xx.xx.xx Client-Port-Id( 5) Len: 6 Value: 7 Acct-Status-Type( 40) Len: 6 Value: Stop(2) Acct-Session-Time( 46) Len: 6 Value: 73 Acct-Terminate-Cause( 49) Len: 6 Value: 0 Acct-Authentic( 45) Len: 6 Value: RADIUS(1) User-Service-Type( 6) Len: 6 Value: Framed-User(2) Framed-Protocol( 7) Len: 6 Value: PPP(1) Framed-Address( 8) Len: 6 Value: xx.xx.xx.xx Acct-Delay-Time( 41) Len: 6 Value: 0 Thanks, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |
Subject: (usr-tc) Filtering Keep Alives
From: Davey Walbeck <davey@vii.com>
Date: 1998-11-10 10:01:45
This is a multi-part message in MIME format. ------=_NextPart_000_0131_01BE0C91.1FAEE760 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know of an implementation for the Hyper Chassis that is = authenticating through a remote server running Livingston Radius, to = filter icmp or other keep alive signals on connections for dial-up = users? There must be something simpler than the information that I have = researched that I'm overlooking. Any help or push in the right = direction would be greatly appreciated. -Davey ------=_NextPart_000_0131_01BE0C91.1FAEE760 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>Does anyone know of an = implementation for the=20 Hyper Chassis that is authenticating through a remote server running = Livingston=20 Radius, to filter icmp or other keep alive signals on connections for = dial-up=20 users?&nbsp; There must be something simpler than the information that I = have=20 researched that I'm overlooking.&nbsp; Any help or push in the right = direction=20 would be greatly appreciated.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>-Davey</FONT></DIV></BODY></HTML> ------=_NextPart_000_0131_01BE0C91.1FAEE760--
Subject: (usr-tc) HiperARC
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1998-11-10 11:10:41
Hi all, I am after some basic config. ideas. Currently we are just a netserver and digital quad modem site. We are contracted to upgrade to HiperARC, the question is do all isdn calls terminate on the arc, like on the netserver or do they have to end up on a modem whether it be quad or DSP? I was going to pull the quads out of a chassis that will handle only ISDN, but setting this up could scupper things up when we get the new gear.... Cheers for any help Phil Cinergy Communications
Subject: (usr-tc) Login Perfomance with TotalControl NetServer/Quadmodems and ISDN
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-11-10 11:18:23
Hi We have TotalControl Equipment and Ascend Max 4000 Equipment. Customers dialing with ISDN into the TotalControl have around 7 seconds until the connection is established, customers dialing into Ascend about 3 seconds. What is your experienc with customers dialing in with ISDN? What connection times do you have? (connection time = time from the moment the Terminal adaptor starts dialing until the Dial Up Networking window disapears on the Windows desktop). Configuration PRI 3.02, Quad 5.9.9, NetServer 3.7.24 ISDN Calls are routed to the NetServer. ISDN Protocol set to auto recognition. Any input is very appreciated. Ralph
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Davey Walbeck <davey@vii.com>
Date: 1998-11-10 12:04:58
The easist solution for idle timeouts is to set the default user idletime on the Hyper Chassis. -Davey -----Original Message----- >Does anybody have a good solution in place for enforcing idle times and >multiple logins? > >I am currently using PMMON and I get no end of complaints from people >that pmmon disconnects them at inappropriate times among other things. > >If anybody has a different/better way of doing this I'de love to hear about it. > > > >Mark Lemmert cto@athenet.net >Chief Technical Officer (920)954-9799 >AthEnet Data Exchange http://www.athenet.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) Solution for idle time limits and dual logins
From: Davey Walbeck <davey@vii.com>
Date: 1998-11-10 12:40:34
The problem is that we do not have just 3Com equipment. The PM3 and other equipment that we have must be able to interact with radius, which is why we have radius running on a separate server under Livingston Radius. Any other ideas that wouldn't involve conpletely converting Radius? -Davey >Use 3com's radius server, it can handle idle timeouts, multiple logins, >but beware, it has its drawbacks :-). > >Mark Lemmert wrote: >> >> Does anybody have a good solution in place for enforcing idle times and >> multiple logins? >> >> I am currently using PMMON and I get no end of complaints from people >> that pmmon disconnects them at inappropriate times among other things. >> >> If anybody has a different/better way of doing this I'de love to hear about it. >> >> Mark Lemmert cto@athenet.net >> Chief Technical Officer (920)954-9799 >> AthEnet Data Exchange http://www.athenet.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) MPIP thoughput issues
From: Mark Lemmert <cto@athenet.net>
Date: 1998-11-10 12:51:18
I am currently running 3.8.1 on my Netservers and 4.1.72 -7 on my HyperARC. Ever since I upgraded from 4.1.11 (arc) and 3.7.72 (Netserver) I have seen major through put problems with any MPIP ISDN connection. Typically I get around 100kbps throughput via ISDN and it is down around 20-35kbps if the session is MPIP. Has anybody else experienced this? Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net
Subject: (usr-tc) Solution for idle time limits and dual logins
From: Mark Lemmert <cto@athenet.net>
Date: 1998-11-10 12:54:52
Does anybody have a good solution in place for enforcing idle times and multiple logins? I am currently using PMMON and I get no end of complaints from people that pmmon disconnects them at inappropriate times among other things. If anybody has a different/better way of doing this I'de love to hear about it. Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: MegaZone <megazone@megazone.org>
Date: 1998-11-10 12:57:10
Once upon a time Davey Walbeck shaped the electrons to say... >The problem is that we do not have just 3Com equipment. The PM3 and other >equipment that we have must be able to interact with radius, which is why we >have radius running on a separate server under Livingston Radius. Any other >ideas that wouldn't involve conpletely converting Radius? No - but try Cistron RADIUS. It started out based on Livingston 1.16 (as did most servers) but it has grown quite a bit. It basically has all of the features of Lucent 2.0.1 save for SecurID and Menu support. It talks to all of the major NAS boxes, and handles VSAs - including 3Com VSAs in the latest build. It hs proven simultaneous login prevention support, hands proxy, RADIUS based huntgroups, and lots of other keen stuff. Cistron even handles iPass now and there are patches for SQL on the backend. And it is free. <URL:http://miquels.www.cistron.nl/radius/> <URL:http://www.mdi.ca/sysadmin/cistron/> I belive you'd be able to just drop your existing RADIUS users file in and be off and running. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Richard Lorbieski <richard@mail.alpha1.net>
Date: 1998-11-10 13:18:04
Use 3com's radius server, it can handle idle timeouts, multiple logins, but beware, it has its drawbacks :-). Mark Lemmert wrote: > > Does anybody have a good solution in place for enforcing idle times and > multiple logins? > > I am currently using PMMON and I get no end of complaints from people > that pmmon disconnects them at inappropriate times among other things. > > If anybody has a different/better way of doing this I'de love to hear about it. > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.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: netserver quad / as5100
From: Chris Wedgwood <chris@cybernet.co.nz>
Date: 1998-11-10 13:20:14
On Tue, Nov 03, 1998 at 02:22:39PM -0700, Aaron Leonard wrote: > > no fair-queue > > no cdp enable > > ppp authentication pap chap > > ppp multilink > > do you really want to use multilink PPP over async? If so > you'll want to have 11.3 and configure a virtual-template. Can't speak for the 5100s, but I'll swear blind that 11.2.something (greater that 9 I think) on a 5200 works fine with multilink PPP and even multi-chassis, tested with both NT4 and Windahs95+DUN1.2 clients. OK, when I say fine, I mean, it works... beyond three lines is seems to be a bit of a loss... -cw
Subject: Re: (usr-tc) MPIP thoughput issues
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-10 13:57:27
Thus spake Mark Lemmert >I am currently running 3.8.1 on my Netservers and 4.1.72 -7 on >my HyperARC. Ever since I upgraded from 4.1.11 (arc) and 3.7.72 (Netserver) >I have seen major through put problems with any MPIP ISDN connection. >Typically I get around 100kbps throughput via ISDN and it is down >around 20-35kbps if the session is MPIP. Just to clarify what's going on there...MPIP isn't the culprit here. MPIP is purely a coordination protocol. It lets the NETServers and Arc's coordinate where a bundle is hosted...it isn't actually responsible for getting the data from one NETServer to another to actually be bundled. The protocol responsible for that is VTP. To answer your other question...no...I haven't experienced any of this, but I'm also using different versions of code. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-10 14:36:18
Richard Lorbieski was heard to say: >Use 3com's radius server, it can handle idle timeouts, multiple logins, >but beware, it has its drawbacks :-). > >Mark Lemmert wrote: >> >> Does anybody have a good solution in place for enforcing idle times and >> multiple logins? To be fair, any radius server can handle idle timeouts (well, as long as it can handle sending a USR VSA.) As for multiple login tracking... radius is a stateless protocol and as such, it's very difficult to maintain any stated data. Most systems that do tracking "correctly" have a task outside the radius server polling the NASes to keep state information correct. Of all the RADIUS servers, I like the USR server best... it provides one of the most powerful and configurable systems. Yes, it is abit slower than all the others, but what it lets you do fair outways the speed. (And it's generally "fast enough".) [I especially like being able to rewrite it's database schema without having to touch it's source code.] --Ricky
Subject: (no subject)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-10 15:55:13
I have a zoom modem (Model # 2948) I can connect to one ISP running 1.2.5 and 4.0.30 but not to another ISP running 1.2.68 and 4.1.78 - 4. Any Ideas? What is the latest code available? I don't know if this is the right way to find the version but ati6 shows: RCV56DPF L8570A Rev 47.20/47.20 I'm on site trying to find out what specifically may be causing the bulk of our problems. I would appreciate input from anyone who may be able to put in their 2 cents ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = =======================================================================
Subject: (usr-tc) HiperARC..
From: System Administrator <sysadmin@evcom.net>
Date: 1998-11-10 16:16:24
Config'ing first HiperARC (btw, must say that CLI is MUCH better than netserver), couple of questions: 1. Is there still a known problem with chassis awareness (w/ latest non-ER code). Only one HARC, so should I do chassis slot assignments manually? 2. Am I to understand that the Idle-Timeout RADIUS attribute does not work correctly with the HARC, and that I must use a VA (we have a highly customized radius daemon, which supports loads of goodies, but not VA)? Many thanks, -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger sysadmin@evcom.net for my PGP Public Key * PS. Extra-special-thanks to the fine folks at interpath for providing http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup ;=)
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: MegaZone <megazone@megazone.org>
Date: 1998-11-10 16:23:23
Once upon a time K Mitchell shaped the electrons to say... >limiting multiple logins has caused problems. It seems that S&A doesn't >always get notification when a user logs out, therefore when a user logs >back in, it gets interpreted as a 2nd concurrent login and is denied. Which is one big reason why Cistron is better. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: (usr-tc) Re:
From: John Powell <john_powell@mw.3com.com>
Date: 1998-11-10 17:05:48
ATI3 is the code rev usually. I6 only shows a chip rev or something (doesn't seem to change with a flash). Try S202=32 and see if that works. It will (on some Rockwell's) turn off their flakey A/D detection. I highly doubt this is a 1.2.68 vs 1.2.5 issue. Arc code would not be related at all. JP "Brian K McIntire" <bmcintire@commnet.com> on 11/10/98 03:55:13 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) I have a zoom modem (Model # 2948) I can connect to one ISP running 1.2.5 and 4.0.30 but not to another ISP running 1.2.68 and 4.1.78 - 4. Any Ideas? What is the latest code available? I don't know if this is the right way to find the version but ati6 shows: RCV56DPF L8570A Rev 47.20/47.20 I'm on site trying to find out what specifically may be causing the bulk of our problems. I would appreciate input from anyone who may be able to put in their 2 cents ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: Randy Cosby <dcosby@infowest.com>
Date: 1998-11-10 17:35:36
I'll put in my two cents for Radiator (http://www.open.com.au/radiator). It does checking two ways. First, it checks the database to see if a user is logged on. The database is user-definable. We log it to mysql, and can then output neat web pages in PHP to see who's online. If it does find the user in the DB too many times, it does a double-check using a pmmon type program. You can use different "checker" programs for different boxes. I'd like it better if I always got a STOP, but this is livable. Randy > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of MegaZone > Sent: Tuesday, November 10, 1998 5:23 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Solution for idle time limits and dual logins > > > Once upon a time K Mitchell shaped the electrons to say... > >limiting multiple logins has caused problems. It seems that S&A doesn't > >always get notification when a user logs out, therefore when a user logs > >back in, it gets interpreted as a 2nd concurrent login and is denied. > > Which is one big reason why Cistron is better. > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, > Engineer, me.. > Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail > Discordia! > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-10 17:51:08
At 01:18 PM 11/10/98 -0600, you wrote: >Use 3com's radius server, it can handle idle timeouts, multiple logins, >but beware, it has its drawbacks :-). I've not had any problems with idle timeouts in 3Com's S&A server, but limiting multiple logins has caused problems. It seems that S&A doesn't always get notification when a user logs out, therefore when a user logs back in, it gets interpreted as a 2nd concurrent login and is denied. YMMV, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Rev. Jim <packrat@aus-etc.com>
Date: 1998-11-10 19:31:47
>>Does anybody have a good solution in place for enforcing idle times and >>multiple logins? one thing that i noticed in all the replys is that there is no mention about those that get around the idle timeout by keeping the mail reader checking the mail every x minutes - i have had to place a Session-Timeout of four hours to help - or am i just missing how to set a thresh-hold that ignores so many bits per/time on the Idle-Timeout - as implemented now, it is one useless command "The avalanche has already started; it is too late for the pebbles to vote." -- Kosh packrat
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-10 20:55:56
On Tue, 10 Nov 1998, Rev. Jim wrote: > >>Does anybody have a good solution in place for enforcing idle times and > >>multiple logins? > > > one thing that i noticed in all the replys is that there is no mention > about those that get around the idle timeout by keeping the mail reader > checking the mail every x minutes - i have had to place a Session-Timeout > of four hours to help - or am i just missing how to set a thresh-hold that > ignores so many bits per/time on the Idle-Timeout - as implemented now, it > is one useless command ...and I think this is what the original post was REALLY asking. :) There's no easy fix for this. You can write a program to check number of octets sent/received on each port, and kick people off that are below a threshold. TSMON (www.tsmon.com) supposedly does this. (We don't use it, though.) I'd prefer something a little more exact... like a filter you could use in conjunction with the idle timeout. i.e. ignore POP3 traffic (110/tcp), ICQ traffic (it sends a packet on port 4000/udp every 2 minutes!), all ICMP, and a few others when considering what "idle time" is. This idea, and the pros and cons of it, have been discussed to death several times on several mailing lists (not this one)... I don't remember what the conensus was, but, well, I don't think ANY vendor has implemented such a beast yet. 3com definitely hasn't. I doubt Cisco, Livingston, or Ascend have either. I was going to work on one using tcpdump, but I figured out really fast that it was going to eat a LOT of bpf devices and probably CPU time too, and more important things came up... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: William Behrens <wbehrens@feist.com>
Date: 1998-11-10 21:12:08
We are working on a program (runs on NT/SQL) that will poll the TC's and kick multipule logins off. With user definable boot parameters like kicking by idle time or newest login and validation before the actual kicking proceedure takes place. We are losing almost 100 ports to multipule logins and don't want to modify or delpoy a new radius version (12K users on BSDI). Right now we are polling 22 TC boxes in 45 secs and kicking the multipule logins 15 secs later. Granted its not lighting fast but will work much better when we get it deployed on the local network with the TC boxes instead of over a T1. William Behrens Director of Network Operations ParaCom Technologies Inc. wbehrens@paracom.com -----Original Message----- >Once upon a time K Mitchell shaped the electrons to say... >>limiting multiple logins has caused problems. It seems that S&A doesn't >>always get notification when a user logs out, therefore when a user logs >>back in, it gets interpreted as a 2nd concurrent login and is denied. > >Which is one big reason why Cistron is better. > >-MZ >-- ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. >Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> >"A little nonsense now and then, is relished by the wisest men" 781-788-0130 ><URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-10 21:24:51
Thus spake Rev. Jim >>>Does anybody have a good solution in place for enforcing idle times and >>>multiple logins? >one thing that i noticed in all the replys is that there is no mention >about those that get around the idle timeout by keeping the mail reader >checking the mail every x minutes - i have had to place a Session-Timeout >of four hours to help - or am i just missing how to set a thresh-hold that >ignores so many bits per/time on the Idle-Timeout - as implemented now, it >is one useless command I've been asking for *years* for a filter or ability to define an access-list or something to specify the types of traffic that reset the idle-timer....and I don't exaggerate when I say years...I've asked this of various vendors...and have just recently found the possibility that one has implemented this. I've heard recently that Cisco might have done this...but haven't played with it personally, so don't know for sure if they have. What about it 3Com? Can we *finally* have this feature? Please? The code to look into packets is already there, you already filter based on ports and protocols...how hard could it be to have the idle-timer check a filter for it? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Problem with encrypted passwords
From: Eric <elorenzo@mediacity.com>
Date: 1998-11-10 21:25:52
Did you use the set ppp receive_authentication command pap? The HARC might default to chap which I know does not work with our RADIUS server. Eric --- Eric J. Lorenzo Field Service Engineer v:650.237.1465 Lorenzo@ISPchannel.com http://www.ISPchannel.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Theodore Cekan > Sent: 10 November, 1998 21:01 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Problem with encrypted passwords > > > I have a new Hiper system that wont authenticate users using > Radius. The > password seems to be sent encrypted and my Radius server cant decrypt it > correctly. What could cause this? > > Ted > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) v.90 connect problems
From: Mario M. Bustamante <mario@accesspro.net>
Date: 1998-11-10 21:33:35
I posted a message earlier describing connection problems with Sportster modems. Up until recently, we assumed that our customers were complaining because they were using the cheap V90 modems, and the problem was on their end. As the complaints started to add up, I had out support people fill out a form to gather information from problem users. The process included asking the end user to run "winipcfg.exe" on their Windows 95 or 98 systems and keep a log of good and bad connections. Since we have mostly Net Server / Quad modem equipment and only one Hiper ARC / DSP, we wanted to know what equipment was causing the most problems and with what kind of modem (on the customer end). We have somewhat over 2,200 users, and we have always recommended that they buy USR/3Com modems, so we were shocked at the number of Sportster users having problems (and they were mad at us for making them spend extra money to buy more problems). We were also shocked to find that a lot of them were connecting to BellSouth with a much better V90 connection (they use Ascend equipment). I do not want to post results publicly, but after compiling the results of almost 200 complaints, I can tell you that most of the problems were related to the Hiper ARC / DSP, and that the percentage of complaints from Sportster users was alarming. I would love to get someone that knows Sportsters on a conference call with someone that knows Hiper ARCs so we can see where the problems lie. I know that there are a lot of bad phone lines and a lot of people who set up their modems with the wrong settings, but somebody has to help us give them tech support. Any ideas? Thanks, _______________________________________________ Mario M. Bustamante, President AccessPro Communications Inc. Miami, Florida Internet Service Providers, Web Hosting & Design Microsoft Certified Web Presence Providers Wide Area Networks, Security, Intranets. http://www.AccessPro.net mario@accesspro.net _______________________________________________ > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > John Powell > Sent: Saturday, November 07, 1998 10:15 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) v.90 connect problems > > > >OK, but a fair number of the people having problems > have Sportsters. > >(Some Winmodems, some not.) I wasn't aware there was > any new Sportster > >code out... if there is, where's it hidden? If > there isn't, is this one > >of the server-side problems? > > I was responding to your comments on LT Winmodems, you > did not mention > Sportsters. I know of no significant issues with > interop with Sportsters > (Winmodem or controller based) and Total Control modems. > > There will likely be improvements with the client side > (all vendors) for > quite some time. There are quite a few tweeks to > enhance performance and > coverage in the labs already. Heck, we are still > improving V.34 4 years > later. > > If you can provide details on problems with > Sportsters, I will gladly take > this off-line and put you in contact with my peers on > the PCD (home of the > Sportster) side of the house. > > JP > > PS. No, there are no recent releases of Sportster > code related to V.90 > fixes. Overall, they are working quite well. > > > > - > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Problem with encrypted passwords
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-10 22:00:52
I have a new Hiper system that wont authenticate users using Radius. The password seems to be sent encrypted and my Radius server cant decrypt it correctly. What could cause this? Ted
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Richard Stuplich <dick@dwave.net>
Date: 1998-11-10 22:04:09
We use a program I wrote called portman. It uses a config file that looks like this: (this is wider than a mail message, it will look a bit odd with the comments) # Global configuration section, # Must be first section, may be mix of upper and lower case # Section must end with an "$end" line. # NOTE: Config pairs and "$end" tags can be seperated by any of the following: # SPACE, TAB, COMMA, SEMICOLON or RETURN. PortMaster squid.dwave.net # PM2 30 ports (Not a user variable) #PortMaster octopus.dwave.net # PM2 29 ports (Not a user variable) #PortMaster starfish.dwave.net # PM2 10 ports (Not a user variable) PortMaster draco.dwave.net # PM3 48 ports (Not a user variable) PortMaster abyss.dwave.net # PM3 48 ports (Not a user variable) PortMaster digimon.dwave.net # PM3 48 ports (Not a user variable) PortMaster bathory.dwave.net # PM3 48 ports (Not a user variable) PortMaster monster.dwave.net # TCH 48 ports (Not a user variable) +1 PortMaster tc2.dwave.net # PM3 48 ports (Not a user variable) TotalPorts 319 # The total number of ports we have to watch (Not a user variable) # Note: TotalPorts will see all ports that are returned by # a pmwho on the device, so on PM3's you will get C0 if you use it # or not. If it alwaus sits in "USERNAME" then it will always be # counted as a port in use so you have to take that into account # on TotalPorts. This is true for a TCH too. # These are the default values to set for all users FreeLow 30 # TotalPorts-FreeLow is considered Low load FreeHig 7 # FreeLow-FreeHig is considered Med load # above FreeHig is considered Hig IdleLimitLow 20 # Minutes idle time if in Low load IdleLimitMed 20 # Minutes idle time if in Med load IdleLimitHig 15 # Minutes idle time if in Hig load # Note: 0 = no limit, -1 means always match MaxTimeLow 0 # Max time per connect Low MaxTimeMed 480 # Max time per connect Med MaxTimeHig 360 # Max time per connect Hig Sessions 1 # Max number of concurent sessions $end # End the global config section (MUST HAVE THIS) # This is the users config area below, users configs fall through. # Much like a 'case' in a 'switch' statement in C # Use this area to deviate from the above globals for individual users, # or groups of users by omiting the '$end' in a group. # allow these to be idle forever but # throw off as as soon as we go into high load user beth user stomper user alk user koskelin user dwkris user kozz user bart user bkniess user brad user vwluvbug user chadwick user chad user shark user dick user jeff user brennan user kat IdleLimitLow 0 MaxTimeHig -1 $end # Group to allow 4 simul logins user ruder Sessions 4 $end # Group to allow 3 simu logins user wifc user wdez user wofm Sessions 3 $end # Group to allow 2 simul logins user waow user signpro user wausaucc user wfl Sessions 2 $end # Dedicated dial up accounts user cclink user lsmail user mp IdleLimitLow 0 IdleLimitMed 0 IdleLimitHig 0 MaxTimeLow 0 MaxTimeMed 0 MaxTimeHig 0 $end # E-Mail only Accounts user bcrb user wexzo # Telnet Only Accounts user nzate user smaxker # DW Employee Forwards user ds user jp user kl user kk user bk user jb user ch user bal user js IdleLimitLow -1 IdleLimitMed -1 IdleLimitHig -1 MaxTimeLow -1 MaxTimeMed -1 MaxTimeHig -1 $end This file is very cut down from our production portman.conf file but you get the idea. As you can see you can group multiple users together and set overrides for the defaults at the top. If a user is not in the lower part then they get the defaults set at the top. It also uses 3 different settings for HIGH, MEDIUM and LOW load. We like this so our free accounts can get thrown off when we hit high load. We have been using portman for over a year and it not only does all this but creates logs for terminations and sends email to multiple offenders. We have this program working with PM2, PM3, USR Netserver and 3COM HiperArc units. It is a unix program. If anyone is willing to help with the finishing of the docs and other polishing I would love to get this ready for free distribution. All I need is some competent ISPs that use UNIX and want to use this. I would help set it all up in exchange for some documentation help. At 10:30 PM 11/10/98 -0500, you wrote: >At 09:12 PM 11/10/98 -0600, you wrote: >> We are working on a program (runs on NT/SQL) that will poll the TC's and >>kick multipule logins off. With user definable boot parameters like kicking >>by idle time or newest login and validation before the actual kicking >>proceedure takes place. We are losing almost 100 ports to multipule logins >>and don't want to modify or delpoy a new radius version (12K users on BSDI). >>Right now we are polling 22 TC boxes in 45 secs and kicking the multipule >>logins 15 secs later. Granted its not lighting fast but will work much >>better when we get it deployed on the local network with the TC boxes >>instead of over a T1. >> >>William Behrens >>Director of Network Operations >>ParaCom Technologies Inc. >>wbehrens@paracom.com >> >-------------------------------------- >Hey William ! >If you can add to this the ability to also set a max session time, I'd be >interested in purchasing this program from you ! > >Keep me posted ? > >Ken >_______________________________________ > Ken Hodges, President and CEO > ACME BrainWorks Internet Services, Inc. > Clayton Computers, Inc. > Rabun County, Georgia > "Where Spring Spends the Summer" > http://www.acme-brain.com or http://www.rabun.net > ken@rabun.net 1-706-782-9239 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 17 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to have redundant T1 NAP connections, All modem compatibility and a staff dedicated exclusively to providing Internet Service to this area. This E-Mail Copyright 1998 Richard Stuplich, see http://dw.net/cr/
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-10 22:05:13
On Tue, 10 Nov 1998, Jeff Mcadams wrote: > I've been asking for *years* for a filter or ability to define an > access-list or something to specify the types of traffic that reset the > idle-timer....and I don't exaggerate when I say years...I've asked this > of various vendors...and have just recently found the possibility that > one has implemented this. I've heard recently that Cisco might have > done this...but haven't played with it personally, so don't know for > sure if they have. So, you filter out one thing. Anyone who really wants to get around idle timeouts will just switch to something. This would really only help if customers are accidently leaving an email check running. Brian
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Ken Hodges <ken@rabun.net>
Date: 1998-11-10 22:30:54
At 09:12 PM 11/10/98 -0600, you wrote: > We are working on a program (runs on NT/SQL) that will poll the TC's and >kick multipule logins off. With user definable boot parameters like kicking >by idle time or newest login and validation before the actual kicking >proceedure takes place. We are losing almost 100 ports to multipule logins >and don't want to modify or delpoy a new radius version (12K users on BSDI). >Right now we are polling 22 TC boxes in 45 secs and kicking the multipule >logins 15 secs later. Granted its not lighting fast but will work much >better when we get it deployed on the local network with the TC boxes >instead of over a T1. > >William Behrens >Director of Network Operations >ParaCom Technologies Inc. >wbehrens@paracom.com > Hey William ! If you can add to this the ability to also set a max session time, I'd be interested in purchasing this program from you ! Keep me posted ? Ken _______________________________________ Ken Hodges, President and CEO ACME BrainWorks Internet Services, Inc. Clayton Computers, Inc. Rabun County, Georgia "Where Spring Spends the Summer" http://www.acme-brain.com or http://www.rabun.net ken@rabun.net 1-706-782-9239
Subject: Re: (usr-tc) Problem with encrypted passwords
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-10 22:43:38
Yes, it is set to pap. -----Original Message----- >Did you use the set ppp receive_authentication command pap? The HARC >might default to chap which I know does not work with our RADIUS server. > >Eric >--- >Eric J. Lorenzo >Field Service Engineer >v:650.237.1465 >Lorenzo@ISPchannel.com >http://www.ISPchannel.com
Subject: Re: (usr-tc) Problem with encrypted passwords
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-10 23:43:16
The secret is correct. I can trace Radius, and it compares the valid password from the database with garbled string it thinks it just decrypted, and send back a reject. -----Original Message----- >Theodore Cekan was heard to say: >>I have a new Hiper system that wont authenticate users using Radius. The >>password seems to be sent encrypted and my Radius server cant decrypt it >>correctly. What could cause this? > >Invalid shared secret. > >--Ricky
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-11 00:45:59
Jeff Mcadams was heard to say: >I've been asking for *years* for a filter or ability to define an >access-list or something to specify the types of traffic that reset the >idle-timer....and I don't exaggerate when I say years...I've asked this >of various vendors...and have just recently found the possibility that >one has implemented this. I've heard recently that Cisco might have >done this...but haven't played with it personally, so don't know for >sure if they have. I know the fealing... FWIW, MorningStar PPP (software) has this functionality. (I had to devise odd ways around it in school :-)) >What about it 3Com? Can we *finally* have this feature? Please? The >code to look into packets is already there, you already filter based on >ports and protocols...how hard could it be to have the idle-timer check >a filter for it? You've obviously never tried to get 3Com to do the logical thing, have you? RADIUS server crypt() password support has taken over a year to get, and I had to write it myself -- that's right ~7 lines of code that would have taken an engineer minutes to create, took over a year and someone else giving them the code to get it done. I, for one, was moving to RADIUS from a system that already had crypt()ed passwords -- that is not reversible. I also want truely encrypted passwords in the database. (FYI, the encrypt()/decrypt() script functions only set/clear the sign bit (0x80) on each character. It doesn't take a rocket scientist to see that or undo it -- 'less' will already strip the sign bit for you!) --Ricky
Subject: Re: (usr-tc) Problem with encrypted passwords
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-11 00:48:43
Theodore Cekan was heard to say: >I have a new Hiper system that wont authenticate users using Radius. The >password seems to be sent encrypted and my Radius server cant decrypt it >correctly. What could cause this? Invalid shared secret. --Ricky
Subject: Re: (usr-tc) De-encrypting
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-11 01:14:37
Ken Hodges was heard to say: >Does anybody know of a way to de-encrypt the passwords in the TC$A database ? Yes. --Ricky PS: This is the modified thing I used a year ago... --- #!/usr/bin/perl ## INPUT: insert into USERS (USER_NAME,...) values ('foo',...); ## ## Eg: pg_dump -d [database] -t USERS -da | ./[this thing].pl $output = "users.sql"; printf "Output: %s\n", $output; open(OUTPUT, ">$output") || die "Foo! [$?/$|]\n"; while (<STDIN>) { chop($_); @INSERT = split(" ", $_, 6); if (($INSERT[0] eq "insert") && ($INSERT[2] eq "USERS")) { $INSERT[3] =~ s/(\()(.*)(\)(.*))/$2/; $INSERT[5] =~ s/(\()(.*)(\)(.*))/$2/; @KEYS = split(",", $INSERT[3]); @VALUES = split(",", $INSERT[5], $#KEYS + 1); for($i=0;$i<=$#KEYS;$i++) { if($KEYS[$i] =~ /PASSWORD/io) { ### Remove the stupid encryption @THING = unpack("c*", $VALUES[$i]); for($c=1;$c<$#THING;$c++) { $THING[$c] &= ~0x80; } $VALUES[$i] = pack("c*", @THING); } } printf OUTPUT "insert into %s (%s) values (", $INSERT[2], $INSERT[3]; for($i=0;$i<$#KEYS;$i++) { printf OUTPUT "%s,", $VALUES[$i]; } printf OUTPUT "%s);\n", $VALUES[$i]; } } close(OUTPUT);
Subject: Re: (usr-tc) Problem with encrypted passwords
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-11 02:55:04
Theodore Cekan was heard to say: >The secret is correct. I can trace Radius, and it compares the valid >password from the database with garbled string it thinks it just decrypted, >and send back a reject. In the trace, the inbound packet off the wire will have the password md5 hashed. If the secrets are not identical, then when the RADIUS server undoes the hash, it will still have "trash". It just takes a few seconds to make sure all the secrets are set correctly everywhere -- the RADIUS server may have to be restarted to load the secret if it's been changed. --Ricky
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-11 07:47:22
Thus spake Brian Elfert >On Tue, 10 Nov 1998, Jeff Mcadams wrote: >> I've been asking for *years* for a filter or ability to define an >> access-list or something to specify the types of traffic that reset the >> idle-timer....and I don't exaggerate when I say years...I've asked this >> of various vendors...and have just recently found the possibility that >> one has implemented this. I've heard recently that Cisco might have >> done this...but haven't played with it personally, so don't know for >> sure if they have. >So, you filter out one thing. Anyone who really wants to get around idle >timeouts will just switch to something. >This would really only help if customers are accidently leaving an email >check running. Actually, we used to do this...on a UNIX based pppd that supported it, and it worked *quite* well, particularly since you could specify whether the packets were incoming or outgoing as well on the filter rules. No, it wasn't perfect, but it was a far sight better than what we've got on access server equipment. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-11 07:50:54
Thus spake Ricky Beam >Jeff Mcadams was heard to say: >>I've been asking for *years* for a filter or ability to define an >>access-list or something to specify the types of traffic that reset the >>idle-timer....and I don't exaggerate when I say years...I've asked this >>of various vendors...and have just recently found the possibility that >>one has implemented this. I've heard recently that Cisco might have >>done this...but haven't played with it personally, so don't know for >>sure if they have. >I know the fealing... FWIW, MorningStar PPP (software) has this functionality. >(I had to devise odd ways around it in school :-)) Yup, we used to use MorningStar and used that....was *quite* nice. That's where I got the idea for this feature. I remember asking Livingston about the possibility of this back in the 3.1.4 ComOS days (MZ might remember me hollering about it back then :) Also asked Xyplex for it (and for an active routing protocol which then never came up with at all...not even RIP)...that was *before* we had the Livingston stuff. >RADIUS server crypt() password support has taken over a year to get, and I >had to write it myself Heh...my MPIP bug (ticket number 58316) is just now being really worked on and its been 7 1/2 months or more since I first opened the ticket. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-11 07:55:02
Thus spake Ken Hodges >If you can add to this the ability to also set a max session time, I'd be >interested in purchasing this program from you ! Max session times are easily set in RADIUS...and work...at least from our experience with them. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Problem with encrypted passwords
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-11 08:57:31
set your ppp authentication prefrence to pap set ppp auth pap Your default setting on the Hiper arc has ppp authentication as follows PPP AUTHENTICATION DIAL_IN Users Authenticate: ANY PPP Authentication Preference: DEFAULT System Transmit Authentication Name: HiPer This will try chap first and this should be your problem. type the above command set ppp auth pap and your ppp set up will look like PPP AUTHENTICATION DIAL_IN Users Authenticate: ANY PPP Authentication Preference: PAP Sy krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 10 Nov 1998, Theodore Cekan wrote: > I have a new Hiper system that wont authenticate users using Radius. The > password seems to be sent encrypted and my Radius server cant decrypt it > correctly. What could cause this? > > Ted > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Per-User Filtering using Bess or XStop
From: Randy Cosby <dcosby@infowest.com>
Date: 1998-11-11 11:45:13
We are looking at running a filtering system like Xstop or N2H2 Bess. If you are running such a box, and are filtering on a per-user-basis, I've got some questions. I'm running both Netserver and HiperARC-based boxes. I've seen some posts about using "VPN Neighbors", to route traffic on a per-user basis to the box, but the docs say that is unsupported. Does it work? Any example implementations you'd care to share? I'm using Radiator, so I can do just about anything I need to on the Radius side. Thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com
Subject: Re: (usr-tc) Problem with encrypted passwords
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-11 12:10:31
Im not sure what the problem was. I reinstalled version 4.1.11 and now it works. Go figure. -----Original Message----- >Theodore Cekan was heard to say: >>The secret is correct. I can trace Radius, and it compares the valid >>password from the database with garbled string it thinks it just decrypted, >>and send back a reject. > >In the trace, the inbound packet off the wire will have the password md5 hashed. >If the secrets are not identical, then when the RADIUS server undoes the hash, >it will still have "trash". It just takes a few seconds to make sure all the >secrets are set correctly everywhere -- the RADIUS server may have to be >restarted to load the secret if it's been changed. > >--Ricky > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) Radius attributes 51, 50
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-11 12:18:02
What are radius attributes 51 and 50? Thanks, Ted
Subject: (usr-tc) wrong nas port
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-11 12:19:49
My hiper is always sending nasPort = 1 to radius no matter what port the user logs in on. Anyone see this before? Thanks, Ted
Subject: Re: (usr-tc) v.90 connect problems
From: FreeBSD4Me <fbsd@typhoon.co.jp>
Date: 1998-11-11 12:42:23
Mario M. Bustamante wrote: .skipped. > We have somewhat over 2,200 users, and we have always recommended > that they buy USR/3Com modems, so we were shocked at the number > of Sportster users having problems (and they were mad at us for > making them spend extra money to buy more problems). We were also > shocked to find that a lot of them were connecting to BellSouth > with a much better V90 connection (they use Ascend equipment). We use NETServer and Qmodems. Since our introduction of V.90 in September, at least 2 Sportsters users complained that their couldn't connect at all or their connections were dropped soon after being connected. In the end, they had to DISABLE V.90 on their Sportsters and got stable and 50-ish K X2 connections. One the other hand, there was one happy Sportsters user who was constantly getting 53k with V.90. But that was the ONLY happy Sportsters user! Looks like there is work to be done on the V.90 codes? fbsd
Subject: (usr-tc) HiperARC.. [resend, first one never hit the list?]
From: System Administrator <sysadmin@evcom.net>
Date: 1998-11-11 14:17:07
Config'ing first HiperARC (btw, must say that CLI is MUCH better than netserver), couple of questions: 1. Is there still a known problem with chassis awareness (w/ latest non-ER code). Only one HARC, so should I do chassis slot assignments manually? 2. Am I to understand that the Idle-Timeout RADIUS attribute does not work correctly with the HARC, and that I must use a VA (we have a highly customized radius daemon, which supports loads of goodies, but not VA)? Many thanks, -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger sysadmin@evcom.net for my PGP Public Key * PS. Extra-special-thanks to the fine folks at interpath for providing http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup ;=)
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: MegaZone <megazone@megazone.org>
Date: 1998-11-12 02:44:28
Once upon a time Jeff Mcadams shaped the electrons to say... >What about it 3Com? Can we *finally* have this feature? Please? The >code to look into packets is already there, you already filter based on >ports and protocols...how hard could it be to have the idle-timer check >a filter for it? Lucent doesn't do it because they determined that this could be a performance hit. It would be yet *another* comparison to be done on every packet, on top of any real filtering that is being done. And: 1. Because of the risk of a performance hit (You know users would overdue it - then blame the vendor.) and 2. There is only a vocal minority asking for this, not a lot of users. It was decided against for the time being. I've only really seen the same handful of users asking for something like this for a few years now - not many overall. Nice idea in general, but it could be sticky in particulars. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: MegaZone <megazone@megazone.org>
Date: 1998-11-12 02:46:10
Once upon a time William Behrens shaped the electrons to say... > We are working on a program (runs on NT/SQL) that will poll the TC's and >kick multipule logins off. With user definable boot parameters like kicking >by idle time or newest login and validation before the actual kicking It sounds like you're largely recreating TSMON... What are the main differences between your program and TSMON? -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Radius attributes 51, 50
From: MegaZone <megazone@megazone.org>
Date: 1998-11-12 02:52:00
Once upon a time Theodore Cekan shaped the electrons to say... >What are radius attributes 51 and 50? When in doubt RTFRFC: 5.11. Acct-Multi-Session-Id Description This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-Id but the same Acct-Multi-Session-Id. It is strongly recommended that the Acct- Multi-Session-Id be a printable ASCII string. A summary of the Acct-Session-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rigney Informational [Page 20] RFC 2139 RADIUS Accounting April 1997 Type 50 for Acct-Multi-Session-Id. Length >= 3 String The String field SHOULD be a string of printable ASCII characters. 5.12. Acct-Link-Count Description This attribute gives the count of links which are known to have been in a given multilink session at the time the accounting record is generated. The NAS MAY include the Acct-Link-Count attribute in any Accounting-Request which might have multiple links. A summary of the Acct-Link-Count attribute format is show 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 | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 51 for Acct-Link-Count. Length 6 Value The Value field is four octets, and contains the number of links seen so far in this Multilink Session. Rigney Informational [Page 21] RFC 2139 RADIUS Accounting April 1997 It may be used to make it easier for an accounting server to know when it has all the records for a given Multilink session. When the number of Accounting-Requests received with Acct-Status-Type = Stop and the same Acct-Multi-Session-Id and unique Acct-Session- Id's equals the largest value of Acct-Link-Count seen in those Accounting-Requests, all Stop Accounting-Requests for that Multilink Session have been received. An example showing 8 Accounting-Requests should make things clearer. For clarity only the relevant attributes are shown, but additional attributes containing accounting information will also be present in the Accounting-Request. Multi-Session-Id Session-Id Status-Type Link-Count "10" "10" Start 1 "10" "11" Start 2 "10" "11" Stop 2 "10" "12" Start 3 "10" "13" Start 4 "10" "12" Stop 4 "10" "13" Stop 4 "10" "10" Stop 4 -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: MegaZone <megazone@megazone.org>
Date: 1998-11-12 02:54:26
Once upon a time Randy Cosby shaped the electrons to say... >I'll put in my two cents for Radiator (http://www.open.com.au/radiator). It >does checking two ways. First, it checks the database to see if a user is >logged on. The database is user-definable. We log it to mysql, and can >then output neat web pages in PHP to see who's online. If it does find the >user in the DB too many times, it does a double-check using a pmmon type >program. You can use different "checker" programs for different boxes. Same as Cistron really. It keeps a DB - opens records for a START, closes them for a STOP. It does SNMP checking for units from Lucent, Cisco, and the 3Com HiPer, finger for units like Ascend, and a telnet command line parser for units like the 3Com NetServer. Radiator and Cistron have many of the same features - only Cistron is free. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) sr0netserv xxx- assigned IP pool out of addresses!
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-12 06:24:15
Ralph Helfenberger was heard to say: >We have a problem, that after some time the Netserver runs out of IP >adresses.There are enough addresses assigned. It looks like the the IP >adresses are not released after a connection. > >Configuration: > Netserver 3.8.1 > RADIUS >The setup is a bit special because users, who are not in the RADIUS >database are given to an NT Server as PPTP users. They will be >authenticated there. This means that we have PPP users and PPTP users on >the same chassis. > >Has anybody seen similar problems? Yes, I have... there appears to be two bugs. First, there is some sort of error with those netservers with "standard" packetbus hardware where it never realizes the session is closed and thus leases the IP. Or so that's what I've heard. I never got a straight answer about it. The second is an error with handling multi-link PPP sessions. I have an ER release that doesn't seem to be affected by it (3.8.95.) It would appear the netserver is allocating too many addresses for MLPPP sessions and then forgetting it handed them out. NetS> ver U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.95 Build date: Sep 10 1998 Build time: 12:43:51 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced NetS> show uptime System has been up for 35900 seconds (0 days 9 hrs 58 min 20 sec) NetS> show ippool ... pool 192.168.38.193 62 1 ... NetS> show ses ... S45 Ptemp02 192.168.38.195 Netwrk In ESTABLISHED 9:53 5 S46 < MPlink: S45 > 192.168.38.195 Netwrk In ESTABLISHED 9:52 - ... I switched to 3.8.95 only because of leaking addresses... there may be other problems I haven't seen yet. One problem all the 3.8 code has had is errors in handling dialout. 3.8.95 seems to always say "NO DIAL TONE" -- but at least I'm seeing the modem's messages. I'm not sure what 3.8.95 was supposed to fix for me -- Mike Wronski mailed me the code shortly after 3.8.1 was moved to "released". --Ricky
Subject: Re: (usr-tc) sr0netserv xxx- assigned IP pool out of addresses!
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-12 07:43:24
In your setup who has the IP pools? The reason I am asking this question is because of your setup. You have both the PPP and PPTP user setup. In PPTP all the Pools etc are maintained by NT. IN PPP you can have the NETServer or the RAdius server assing the IP address. Depending on your case - if you are using a private pool and if radius is asking ip address for PPTP users - it may never be released. Need to know more about your setup in terms of PPTP users and PPP users. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 12 Nov 1998, Ralph Helfenberger wrote: > We have a problem, that after some time the Netserver runs out of IP > adresses.There are enough addresses assigned. It looks like the the IP > adresses are not released after a connection. > > Configuration: > Netserver 3.8.1 > RADIUS > The setup is a bit special because users, who are not in the RADIUS > database are given to an NT Server as PPTP users. They will be > authenticated there. This means that we have PPP users and PPTP users on > the same chassis. > > > Has anybody seen similar problems? > > Ralph > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) sr0netserv xxx- assigned IP pool out of addresses!
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-12 07:47:19
On Thu, 12 Nov 1998, Ricky Beam wrote: > Ralph Helfenberger was heard to say: > >We have a problem, that after some time the Netserver runs out of IP > >adresses.There are enough addresses assigned. It looks like the the IP > >adresses are not released after a connection. > > > >Configuration: > > Netserver 3.8.1 > > RADIUS > >The setup is a bit special because users, who are not in the RADIUS > >database are given to an NT Server as PPTP users. They will be > >authenticated there. This means that we have PPP users and PPTP users on > >the same chassis. > > > >Has anybody seen similar problems? > > Yes, I have... there appears to be two bugs. First, there is some sort of > error with those netservers with "standard" packetbus hardware where it > never realizes the session is closed and thus leases the IP. Or so that's > what I've heard. I never got a straight answer about it. Hmm... Hardware - causing a Software problem? Enhanced packet bus and standard packet bus have nothing do with IP pools. You have other problems with standard packet bus but loosing ip address is not one of them. In the above setup one of the possible reasons the customer is loosing IP address may be because of his way of assining IP addresses - meaning he may be giving out ip address for PPTP users which may be lost and never be released. > > The second is an error with handling multi-link PPP sessions. I have an ER > release that doesn't seem to be affected by it (3.8.95.) It would appear the > netserver is allocating too many addresses for MLPPP sessions and then > forgetting it handed them out. > Totally different issue. A lot of customer are using 3.8.1 and this is the first instance I have heard about loosing IP address. krish > NetS> ver > U.S. Robotics > Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.95 > Build date: Sep 10 1998 > Build time: 12:43:51 > > Network Interface Card: Ethernet & Frame Relay Combination (26) > ISDN Interface Card : MUNICH32 (4) > Packet Bus Circuit : Enhanced > > NetS> show uptime > System has been up for 35900 seconds (0 days 9 hrs 58 min 20 sec) > NetS> show ippool > ... > pool 192.168.38.193 62 1 > ... > NetS> show ses > ... > S45 Ptemp02 192.168.38.195 Netwrk In ESTABLISHED 9:53 5 > S46 < MPlink: S45 > 192.168.38.195 Netwrk In ESTABLISHED 9:52 - > ... > > I switched to 3.8.95 only because of leaking addresses... there may be other > problems I haven't seen yet. One problem all the 3.8 code has had is errors > in handling dialout. 3.8.95 seems to always say "NO DIAL TONE" -- but at least > I'm seeing the modem's messages. I'm not sure what 3.8.95 was supposed to > fix for me -- Mike Wronski mailed me the code shortly after 3.8.1 was moved > to "released". > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-12 08:18:26
Thus spake MegaZone >Once upon a time Jeff Mcadams shaped the electrons to say... >>What about it 3Com? Can we *finally* have this feature? Please? The >>code to look into packets is already there, you already filter based on >>ports and protocols...how hard could it be to have the idle-timer check >>a filter for it? >Lucent doesn't do it because they determined that this could be a performance >hit. It would be yet *another* comparison to be done on every packet, on >top of any real filtering that is being done. How much of a performance hit would there be? You only actually have to look into the packet and get the values once, yes, its another comparison, but that shouldn't be that hard of a hit at all. Especially if your filtering code is up to snuff. Like, for example, we don't assign or define any filters on our NETServers (nor did we on our PM's when we used them), *please* don't tell me that the code still goes through the process of looking into the packet and checking filters if they're non-existant in that case. >1. Because of the risk of a performance hit (You know users would overdue >it - then blame the vendor.) Its called a feature, *any* feature has the possibility of doing this. Cisco has had policy routing in their routers for quite some time *knowing* that its a *big* performance hit because it had to be process switched...they just recently got it to be fast-switched...and even then not completely...but the feature was there anyway because some people could really use it. >2. There is only a vocal minority asking for this, not a lot of users. >It was decided against for the time being. OK, let's here it folks...how many people think this would be very useful? Maybe you hadn't though of it previously, but it could be useful to you. Again, the feature being requested is a filter to define what packets reset the idle timer on a connection, so you could say for example deny tcp port 109 deny tcp port 110 deny icmp or something along those lines, and even if your user were checking mail every 2 minutes or pinging a system out on the 'net, your system could still disconnect them with an idle timeout. Let's hear from you if you think this is a good idea since NAS vendors obviously can't be trusted to figure out a good idea on their own. >I've only really seen the same handful of users asking for something like >this for a few years now - not many overall. Nice idea in general, but >it could be sticky in particulars. Oh, how hard can it be? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Connection problems into DSP
From: Eric <elorenzo@ispchannel.com>
Date: 1998-11-12 08:19:50
We just replaced two NETServers in the field with HARCs loaded with TCS 3.3 software. The HiPer DSPs they're owners of are still running TCS 3.1. We're getting reports of users getting disconnected during the authorization process. They say they have to attempt a connection 3 or 4 times before they can get logged in. Could this be an issue with different TCS levels on the cards or does something just need rebooting? Eric
Subject: (usr-tc) Follow up after ISPcon San Jose.
From: Tim Patterson <tim@harborside.com>
Date: 1998-11-12 08:45:13
3com reps at the ISPcon in San Jose promised a call back regarding the failed TC tech support situation at 3com. So far I have not heard anything, did anyone at the show get a call? Tim Patterson Harborside Internet 541-469-8844 800-680-8855 FAX 541-469-9163
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Behrens, William <wbehrens@paracom.com>
Date: 1998-11-12 08:59:30
> > It sounds like you're largely recreating TSMON... > > What are the main differences between your program and TSMON? > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, > Engineer, me.. > Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest > men" 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> > Hail Discordia! > Well its a long story. First the person who wrote PMMON and variants used to work at our company (when it was Future Net). That code was taken with him (source included) when he left (his name is not important and doesn't need to be mentioned here in this forum). This application runs on Unix and uses port 23 telnet sessions to retrieve information from the NAS. We are writing this application using the protocol that PMconsole / Netserver Manager uses to communicate with the NAS. This has considerable advantages as it decreases the polling time and puts less load on the NAS. We are also using SQL server as the database to store the users and information that is associated with them. We then have access to this data for other purposes. Customer service managers can run reports on availability vs. time of day etc. without programming (link to data from access or some other evil Microsoft product). We can keep long term stats, baselining the NAS usage to pre-order equipment and circuits. Once the data is collected there is a whole host of things we can do with it. I know that TSMON is very powerful. The developer is a well know person here in Wichita and is very good at what he does. There are a lot of people who would like a NT option though. This program is not intended to be marketed or sold. We are just replacing what we (as a company) believe should be ours to begin with, where we have control of the source code and can do with it what we will. The current developer has signed a Proprietary Rights Agreement so we shouldn't have future ownership issues. We have never had any intentions of legal action against the developer of PMMON/TSMON (even though he now makes money with it). We (ParaCom) just feel that its silly to purchase something you feel you already own (its a moral issue with the executives of the company). William Behrens Director of Network Operations ParaCom Technologies Inc. (formerly Feist Internet / Future Net) www.feist.com www.paracom.com wbehrens@paracom.com
Subject: Re: (usr-tc) sr0netserv xxx- assigned IP pool out of addresses!
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-12 10:05:02
Tatai SV Krishnan was heard to say: >> Yes, I have... there appears to be two bugs. First, there is some sort of >> error with those netservers with "standard" packetbus hardware where it >> never realizes the session is closed and thus leases the IP. Or so that's >> what I've heard. I never got a straight answer about it. >Hmm... Hardware - causing a Software problem? Enhanced packet bus and >standard packet bus have nothing do with IP pools. You have other >problems with standard packet bus but loosing ip address is not one of them. >In the above setup one of the possible reasons the customer is loosing IP >address may be because of his way of assining IP addresses - meaning he >may be giving out ip address for PPTP users which may be lost and never >be released. As I said, I never got a straight answer, but the ER code I was given for the "standard" netservers stopped it from losing every address it had -- named or otherwise. And it's not the hardware perse, but more the code being written for newer hardware not working correctly on the older hardware. As I was lead to believe, 3.7.24 on "standard" netservers would sometimes not close the packet bus session correctly which means it never released an address assigned to that session. It also means it would eventually run out of packet bus sessions. I'm not saying that's what was happening; it's just what I was lead to believe -- the helpdesk filter applies. >> The second is an error with handling multi-link PPP sessions. I have an ER >> release that doesn't seem to be affected by it (3.8.95.) It would appear the >> netserver is allocating too many addresses for MLPPP sessions and then >> forgetting it handed them out. > >Totally different issue. A lot of customer are using 3.8.1 and this is >the first instance I have heard about loosing IP address. I never used 3.8.1 code in production. It's buggy. I pointed out the bugs TWICE while it was BETA. It makes me think no one is bothering to pay any attention at all to the beta mail lists setup for feedback. It's either that or 3Com really doesn't give a damn about the netservers. (Or both.) And I and several others have complained about netservers gradually losing IP addresses before. I spent over an hour teaching the tech support toady that the last number in 'show ippool' is the number of addresses from that pool the netserver thinks is in use. [I hate tech support toady's. But, it's not their fault nobody ever teaches them about these things -- altho', I'd much rather hear "I don't know" than be feed a line of BS.] --Ricky
Subject: Re: (usr-tc) sr0netserv xxx- assigned IP pool out of addresses!
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-12 10:08:27
On Thu, 12 Nov 1998, Ralph Helfenberger wrote: > As far as I can see the IP Pools are maintained in the Netserver. But > this is where the problem could come from. I use the 3Com Security and > Accounting server. If a user connects wich is not in the RADIUS database > then this user will be authenicated as the default user in RADIUS. Now > the default User has the protocol setup as PPTP. He will be forwarded to > the configured NT Machine... The question is whether an IP Adress will > be used for this connection (although it shouldn't, because NT is giving > this user an adress) and if yes, what happens when the user disconnects? > The problem here is that the Radius server is asking for an IP address during setup for the a PPTP user. This is wrong, It should not ask for one. Ofcourse this is a bug The general setup for pptp should be user Password = password, user-service-type = framed-user framed-protocol = pptp login-host = ip address of nt pptp but with the 3com radius it is asking for an IP address, if you do not assign it will ask the netserver to assign which is wrong. The workaround: Either give the default user an ip address such as 10.10.10.10 - the ip address is never used so it does not make a difference or set a private pool and specify the user to that pool krish > Ralph > > > > Tatai SV Krishnan wrote: > > > > In your setup who has the IP pools? The reason I am asking this question > > is because of your setup. You have both the PPP and PPTP user setup. In > > PPTP all the Pools etc are maintained by NT. IN PPP you can have the > > NETServer or the RAdius server assing the IP address. > > > > Depending on your case - if you are using a private pool and if radius is > > asking ip address for PPTP users - it may never be released. Need to > > know more about your setup in terms of PPTP users and PPP users. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Thu, 12 Nov 1998, Ralph Helfenberger wrote: > > > > > We have a problem, that after some time the Netserver runs out of IP > > > adresses.There are enough addresses assigned. It looks like the the IP > > > adresses are not released after a connection. > > > > > > Configuration: > > > Netserver 3.8.1 > > > RADIUS > > > The setup is a bit special because users, who are not in the RADIUS > > > database are given to an NT Server as PPTP users. They will be > > > authenticated there. This means that we have PPP users and PPTP users on > > > the same chassis. > > > > > > > > > Has anybody seen similar problems? > > > > > > Ralph > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1998-11-12 11:00:40
On Thu, 12 Nov 1998, Jeff Mcadams wrote: > or something along those lines, and even if your user were checking mail > every 2 minutes or pinging a system out on the 'net, your system could > still disconnect them with an idle timeout. I love the idea...if my competitors did such things, I could really eat them alive in the marketing arena. And I'm sure that the customers I couldn't steal from them at that point would gladly switch to using RealAudio streams to keep their connection up, sapping both the port and the bandwidth. So count me as a yes vote. I wouldn't use the feature myself of course, but I could hope my competition would be short-sighted enough to do so.
Subject: (usr-tc) sr0netserv xxx- assigned IP pool out of addresses!
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-11-12 11:45:08
We have a problem, that after some time the Netserver runs out of IP adresses.There are enough addresses assigned. It looks like the the IP adresses are not released after a connection. Configuration: Netserver 3.8.1 RADIUS The setup is a bit special because users, who are not in the RADIUS database are given to an NT Server as PPTP users. They will be authenticated there. This means that we have PPP users and PPTP users on the same chassis. Has anybody seen similar problems? Ralph
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-12 12:02:06
Thus spake Lon R. Stockton, Jr. >On Thu, 12 Nov 1998, Jeff Mcadams wrote: >> or something along those lines, and even if your user were checking mail >> every 2 minutes or pinging a system out on the 'net, your system could >> still disconnect them with an idle timeout. >I love the idea...if my competitors did such things, I could really >eat them alive in the marketing arena. And I'm sure that the customers >I couldn't steal from them at that point would gladly switch to using >RealAudio streams to keep their connection up, sapping both the port >and the bandwidth. If you pick up my abusive users that are pulling stuff like that...more power to you...they can eat up your ports without giving any extra revenue stream. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Richard Stuplich <dick@dwave.net>
Date: 1998-11-12 12:19:53
At 01:02 PM 11/12/98 -0500, you wrote: > >On Thu, 12 Nov 1998, Jeff Mcadams wrote: > >> If you pick up my abusive users that are pulling stuff like that...more >> power to you...they can eat up your ports without giving any extra >> revenue stream. > >Ah, but they do provide extra revenue, since I don't participate in the >lie commonly called 'unlimited service'. After 150 hours, they pay >extra. Not only do I get to sidestep the idle_timer issue, I can sidestep >the max_session_length and max_sessions issues as well. > We offer unlimited access and mean it. If you think an ISP can't offer unlimited, and mean, it you are sorely mistaken. Unfortunately most ISPs oversell bandwidth and offer non-unlimited unlimited. This reflects poorly on all ISPs. I do admire an ISP that will not offer unlimited if they are not willing to deliver it, as you. To say that an ISP can't offer unlimited and mean it is wrong. Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 17 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to have redundant T1 NAP connections, All modem compatibility and a staff dedicated exclusively to providing Internet Service to this area. This E-Mail Copyright 1998 Richard Stuplich, see http://dw.net/cr/
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-12 12:46:21
On Thu, 12 Nov 1998, Lon R. Stockton, Jr. wrote: > > On Thu, 12 Nov 1998, Jeff Mcadams wrote: > > > or something along those lines, and even if your user were checking mail > > every 2 minutes or pinging a system out on the 'net, your system could > > still disconnect them with an idle timeout. > > I love the idea...if my competitors did such things, I could really > eat them alive in the marketing arena. And I'm sure that the customers > I couldn't steal from them at that point would gladly switch to using > RealAudio streams to keep their connection up, sapping both the port > and the bandwidth. So, you want all the customers that stay online all day, but do nothing while online except check mail every few minutes?
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1998-11-12 13:02:24
On Thu, 12 Nov 1998, Jeff Mcadams wrote: > If you pick up my abusive users that are pulling stuff like that...more > power to you...they can eat up your ports without giving any extra > revenue stream. Ah, but they do provide extra revenue, since I don't participate in the lie commonly called 'unlimited service'. After 150 hours, they pay extra. Not only do I get to sidestep the idle_timer issue, I can sidestep the max_session_length and max_sessions issues as well.
Subject: Re: (usr-tc) v.90 connect problems
From: Carl Jagerski <carll@forcomm.net>
Date: 1998-11-12 13:30:24
I know of hundreds of people that have called or email USR/3COM about the sportster v.90 issue. If you are denying the problem, then someone at your company is throwing away all the messages before anyone can see them. Or you are hiding the truth. Which is it??? At 09:15 PM 11/7/98 -0600, you wrote: >>OK, but a fair number of the people having problems have Sportsters. >>(Some Winmodems, some not.) I wasn't aware there was any new Sportster >>code out... if there is, where's it hidden? If there isn't, is this one >>of the server-side problems? > >I was responding to your comments on LT Winmodems, you did not mention >Sportsters. I know of no significant issues with interop with Sportsters >(Winmodem or controller based) and Total Control modems. > >There will likely be improvements with the client side (all vendors) for >quite some time. There are quite a few tweeks to enhance performance and >coverage in the labs already. Heck, we are still improving V.34 4 years >later. > >If you can provide details on problems with Sportsters, I will gladly take >this off-line and put you in contact with my peers on the PCD (home of the >Sportster) side of the house. > >JP > >PS. No, there are no recent releases of Sportster code related to V.90 >fixes. Overall, they are working quite well. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Carl Jagerski Network Administrator, Forward Communications carll@forcomm.net 412-378-4490 Fax: 412-375-0156
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-12 13:35:27
On Thu, 12 Nov 1998, Richard Stuplich wrote: > We offer unlimited access and mean it. If you think an ISP can't offer > unlimited, and mean, it you are sorely mistaken. Unfortunately most ISPs You are NOT offering truly unlimited service Here is a quote from your web page: "Unlinited active usage per month included" (mispellings included). Unlimited is defined as "without limits". Requiring someone to be active is a limit. Just because you may not have a session limit or an idle timeout doesn't mean you offer a truly unlimited service. > Richard B. Stuplich DataWave, Not just faster, Better. > President, DataWave Technologies 17 T1 circuits and growing strong. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Your whole web page is a bunch of marketing crapola. You're trying to decieve people into thinking you have 17 T1s to the Internet, and you don't. Your own web page has a press release announcing the second T1 to the Internet in Sept '98. I'll bet that 15 of those T1s are really for dialin or some purpose besides connecting to the Internet. Your web page also says that you will have enough bandwidth to deliver 1.5Mbps to each customer who buys a T1 from you. You better not have more than 1 T1 customer then, because you aren't providing enough bandwidth so that each T1 customer could use a full 1.5Mbps. If you really have a T1's worth of bandwidth sitting around for each T1 customer, how could you sell for any less than your Internet backbones? Until you are buying bandwidth at the DS3 level, you're not going to get 1.5Mbps of bandwidth to an Internet backbone any cheaper than any of your T1 customers could buy it direct from a backbone for. Brian
Subject: (usr-tc) Unlimited can mean unlimited.
From: Richard Stuplich <dick@dwave.net>
Date: 1998-11-12 14:21:40
>> We offer unlimited access and mean it. If you think an ISP can't offer >> unlimited, and mean, it you are sorely mistaken. Unfortunately most ISPs > >You are NOT offering truly unlimited service Here is a quote from your >web page: "Unlinited active usage per month included" (mispellings >included). > >Unlimited is defined as "without limits". Requiring someone to be active >is a limit. Just because you may not have a session limit or an idle >timeout doesn't mean you offer a truly unlimited service. When we say U-N-L-I-M-I-T-E-D we mean it. You can misinterpret a "Cover your ass" statement any way you like. Doesn't change the facts that some ISPs offer unlimited and mean it. Like us. Do you have a contract with your users? In that contract do you state that you make no warranties for the usefulness of your product? In that case you must not provide a very good service, right? There is a difference between converging your ass and policy. I'd post our usage report showing 26+ days of usage for $19.95 unlimited accounts that we allow access month after month if it wouldn't violate our non-disclosure contract with our customer. This is not the place to fight about this. Reply to me privately and I'll prove we mean it. Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 17 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to have redundant T1 NAP connections, All modem compatibility and a staff dedicated exclusively to providing Internet Service to this area. This E-Mail Copyright 1998 Richard Stuplich, see http://dw.net/cr/
Subject: (usr-tc) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-12 14:46:54
I configured a HiPer ARC running 4.1.11 with an IPX network going out Eth:2. I configured a user on the HiPer ARC with the IPX network # fffffffc. It worked like a charm. Then the customer reported trouble with web-TV. We upgraded to 4.1.78 - 4. Once upgraded the network # fffffffc was not working. The only way we could get ipx to work at all was to assign a specific ipx # or to configure an ipx pool. I have two questions: Is this a bug or did I miss something? Are there plans to include IPX pools in RADIUS since the HiPer ARC seems to support that attribute. I already spoke to someone at 3COM. They told me they would get back to me yesterday, but didn't. Now it's Thursday and they don't work today. Any comments?
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-12 15:06:04
Thus spake Lon R. Stockton, Jr. >On Thu, 12 Nov 1998, Jeff Mcadams wrote: >> If you pick up my abusive users that are pulling stuff like that...more >> power to you...they can eat up your ports without giving any extra >> revenue stream. >Ah, but they do provide extra revenue, since I don't participate in the >lie commonly called 'unlimited service'. Neither do we...if you find any place on our pages that says "unlimited service", please let me know as it definitely shouldn't be there. We *do* have "flat-rate" but that still allows us to put idle-timers, max-session timers, and filters on dial-ups. Since you don't have a true flat-rate, perhaps its me that would eat your lunch in marketing. We do have abusive users...and we have measures in place to deal with them...this however, would be one such measure that would *help* (not absoluately cure) us deal with them. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-12 15:08:27
Thus spake Brian K McIntire >I already spoke to someone at 3COM. They told me they would get back to me >yesterday, but didn't. Now it's Thursday and they don't work today. >Any comments? Heh...yeah...welcome to the user's side. :D -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Unlimited can mean unlimited.
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-12 15:38:41
Can I ask a favor? Can we dispense with the "unlimited" religious war? It's been beat to death on the inet-access list several dozen times and we really don't need to read it here... ;-) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep
Subject: RE: (usr-tc) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-12 15:42:25
:( Thanks Jeff. Thus spake Brian K McIntire >I already spoke to someone at 3COM. They told me they would get back to me >yesterday, but didn't. Now it's Thursday and they don't work today. >Any comments? Heh...yeah...welcome to the user's side. :D -- 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) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-12 15:42:25
:( Thanks Jeff. Thus spake Brian K McIntire >I already spoke to someone at 3COM. They told me they would get back to me >yesterday, but didn't. Now it's Thursday and they don't work today. >Any comments? Heh...yeah...welcome to the user's side. :D -- 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) Unlimited can mean unlimited.
From: Frank Basso <frank@got.net>
Date: 1998-11-12 16:03:49
Take it offline boys. -----Original Message----- >>> We offer unlimited access and mean it. If you think an ISP can't offer >>> unlimited, and mean, it you are sorely mistaken. Unfortunately most ISPs >> >>You are NOT offering truly unlimited service Here is a quote from your >>web page: "Unlinited active usage per month included" (mispellings >>included). >> >>Unlimited is defined as "without limits". Requiring someone to be active >>is a limit. Just because you may not have a session limit or an idle >>timeout doesn't mean you offer a truly unlimited service. > >When we say U-N-L-I-M-I-T-E-D we mean it. You can misinterpret a "Cover >your ass" statement any way you like. Doesn't change the facts that some >ISPs offer unlimited and mean it. Like us. > >Do you have a contract with your users? In that contract do you state that >you make no warranties for the usefulness of your product? In that case >you must not provide a very good service, right? > >There is a difference between converging your ass and policy. > >I'd post our usage report showing 26+ days of usage for $19.95 unlimited >accounts that we allow access month after month if it wouldn't violate our >non-disclosure contract with our customer. > >This is not the place to fight about this. Reply to me privately and I'll >prove we mean it. > > Richard B. Stuplich DataWave, Not just faster, Better. > President, DataWave Technologies 17 T1 circuits and growing strong. >--------------------------------------------------------------------------- - >DataWave, Wausau's first local ISP to have a direct connection to the >midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to >have redundant T1 NAP connections, All modem compatibility and a staff >dedicated exclusively to providing Internet Service to this area. >--------------------------------------------------------------------------- - >This E-Mail Copyright 1998 Richard Stuplich, see http://dw.net/cr/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) sr0netserv xxx- assigned IP pool out of addresses!
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-11-12 16:08:46
As far as I can see the IP Pools are maintained in the Netserver. But this is where the problem could come from. I use the 3Com Security and Accounting server. If a user connects wich is not in the RADIUS database then this user will be authenicated as the default user in RADIUS. Now the default User has the protocol setup as PPTP. He will be forwarded to the configured NT Machine... The question is whether an IP Adress will be used for this connection (although it shouldn't, because NT is giving this user an adress) and if yes, what happens when the user disconnects? Ralph Tatai SV Krishnan wrote: > > In your setup who has the IP pools? The reason I am asking this question > is because of your setup. You have both the PPP and PPTP user setup. In > PPTP all the Pools etc are maintained by NT. IN PPP you can have the > NETServer or the RAdius server assing the IP address. > > Depending on your case - if you are using a private pool and if radius is > asking ip address for PPTP users - it may never be released. Need to > know more about your setup in terms of PPTP users and PPP users. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Thu, 12 Nov 1998, Ralph Helfenberger wrote: > > > We have a problem, that after some time the Netserver runs out of IP > > adresses.There are enough addresses assigned. It looks like the the IP > > adresses are not released after a connection. > > > > Configuration: > > Netserver 3.8.1 > > RADIUS > > The setup is a bit special because users, who are not in the RADIUS > > database are given to an NT Server as PPTP users. They will be > > authenticated there. This means that we have PPP users and PPTP users on > > the same chassis. > > > > > > Has anybody seen similar problems? > > > > Ralph > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) filtering service (fwd)
From: Angela A. Burford <aratis@erie.net>
Date: 1998-11-12 17:37:23
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------C9164EDBAC9612E3D30DD268 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: <Pine.LNX.3.95.981112171319.6081C@moose.erie.net> Hi, I have some filtering features that work with my livingston pm3's and i would like to implement them in my usr chassis as well. The feature is the following: When my users can access a webpage and customize the setup of their filters. That information is used to build a filter for that specific user. The user can change the settings of his filter anytime he connects. When he calls in, radius passes the name of the filter for that user to the pm3 and the filter itself is loaded into the portmaster through choicenet, so that it will be used in that connection. So a different filter for each user is stored in one of my central radius serer (a bsdi box running customized livingston radius), and loaded into the right pm3 each time the user establishes a connection. I'd like to make this work with my usr's too (i have chassis with netservers, quad modems nmc and dual pri cards and other with hiperDSP's hiperARC and nmc cards). I understand that I can pass the names of the filters to be used at the time the user connects, but is it possible to load the actual filter that is stored in my radius server into the hiperARC / netserver so that it will applied to the connection? If so, how can that be done? I'd appreciate any information you can give me about the topic. Thank you very much in advance Angela ---------- Forwarded message ---------- Reply-To: usr-tc@lists.xmission.com Packet filters. I've written many. Read up on the packet filters for your netserver. Jason Cropper Craig Thompson wrote: > Has anyone set up their TC to allow some customers to be sent through a > filtering service? > > A company we are looking at for this says that the PortMaster has a > config option that says "ChoiceNet Server." > > I was wondering if there is a workaround for doing this on the TC? > > Please help if you can. > > Craig Thompson > ---------------------------------------------------------------------- > WingNET Internet Services, > P.O. Box 3000 // Cleveland, TN 37320-3000 > 423-559-LINK (v) 423-559-5444 (f) > http://www.wingnet.net > ---------------------------------------------------------------------- > > Always be sincere, even if you don't mean it. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --------------C9164EDBAC9612E3D30DD268--
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-12 18:04:17
Jeff Mcadams was heard to say: >Thus spake Lon R. Stockton, Jr. >>On Thu, 12 Nov 1998, Jeff Mcadams wrote: >>> or something along those lines, and even if your user were checking mail >>> every 2 minutes or pinging a system out on the 'net, your system could >>> still disconnect them with an idle timeout. > >>I love the idea...if my competitors did such things, I could really >>eat them alive in the marketing arena. And I'm sure that the customers >>I couldn't steal from them at that point would gladly switch to using >>RealAudio streams to keep their connection up, sapping both the port >>and the bandwidth. > >If you pick up my abusive users that are pulling stuff like that...more >power to you...they can eat up your ports without giving any extra >revenue stream. While I happen to agree that an idleness filter would be a Godd Thing(tm), I'm afraid it's just a waste of time to code, process, and maintain. No matter what you assign as "idle traffic", there are 64k or ports to choose from and hundreds of programs already written to get around the idle timer. I would help with the casual web browsing user. You could filter out a fair amount of junk that really should not be considered active traffic (ICMP in particular.) But it's trivial to get around idle timers. Use a session timer and maybe a "logged out time" threshold -- but that really is a mess. I would vote in favor of the feature (on HARC) even if .1% of the user base would use it. --Ricky
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-12 18:04:39
On Thu, 12 Nov 1998, Behrens, William wrote: > We are writing this application using the protocol that PMconsole / > Netserver Manager uses to communicate with the NAS. This has considerable > advantages as it decreases the polling time and puts less load on the NAS. Where is this protocol documented? Anywhere? (Or did you reverse engineer it?) If this can do the equivalent of "pmwho" faster, I'd be interested in hacking up some Perl code to do this for my own utilities... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep
Subject: Re: (usr-tc) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-12 18:12:39
Brian K McIntire was heard to say: >Are there plans to include IPX pools in >RADIUS since the HiPer ARC seems to support that attribute. I thought SA6 already had that in that mess of a database. If not, it's trival enough to add -- getting the java widget to manage it is another story. --Ricky
Subject: Re: (usr-tc) filtering service (fwd)
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-12 18:20:54
Angela A. Burford was heard to say: >I'd like to make this work with my usr's too (i have chassis with >netservers, quad modems nmc and dual pri cards and other with hiperDSP's >hiperARC and nmc cards). I understand that I can >pass the names of the filters to be used at the time the user connects, >but is it possible to load the actual filter that is stored in my >radius server into the hiperARC / netserver so that it will applied to the >connection? If so, how can that be done? Well, you can certainly tftp the filter into the HARC, but the netserver is gonna be a real bitch to do this. Umm, would it be too much to ask to replace the netservers with ARCs??? (I know the ARC has a bunch of bugs, but at least 3Com _can_ fix those. The netserver is hopeless.) --Ricky
Subject: Re: (usr-tc) filtering service (fwd)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-12 19:49:51
Thus spake Angela A. Burford >the portmaster through choicenet, so that it will be used in that >I'd like to make this work with my usr's too (i have chassis with >netservers, quad modems nmc and dual pri cards and other with hiperDSP's >hiperARC and nmc cards). I understand that I can >pass the names of the filters to be used at the time the user connects, >but is it possible to load the actual filter that is stored in my >radius server into the hiperARC / netserver so that it will applied to the >connection? If so, how can that be done? Can't reasonably be done on NETServers...the HARC's have the ability to handle "dynamic filters" given a RADIUS server that supports it. Not having HARC's to really play with extensively, I don't know how to do this. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: andy <smitha@mach3ww.com>
Date: 1998-11-12 20:06:58
While we are talking about timeouts... How can I set: #1 an idletimeout and session timeout in the netserver card (3.7.24) #2 an idletimeout and session timeout in the hiperarc card (4.0.30) #3 do they work? - andrew
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-12 22:21:40
Thus spake andy >While we are talking about timeouts... >How can I set: >#1 an idletimeout and session timeout in the netserver card (3.7.24) Idle-Timeout = 720 Session-Timeout = 42516 These are in seconds, using Merit RADIUS...your dictionary may be slightly different. >#2 an idletimeout and session timeout in the hiperarc card (4.0.30) I would assume similar, but don't know. >#3 do they work? On the NETServers, yes. Keep in mind (and I'm sure its hard to forget with all the discussion going on) that its quite easy to defeat idle-timeouts as they stand...a single packet of *any* type will reset the idle timer. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Charles Sprickman <spork@inch.com>
Date: 1998-11-12 22:48:28
Does anyone have a complete list of 3com addresses that are receptive to complaints? Things get better, things get worse, but a carefully worded "status report" to 3com by anyone that feels some issues are still unresolved can really only help the situation. Squeaky wheel and all that... Charles On Thu, 12 Nov 1998, Brian K McIntire wrote: > :( Thanks Jeff. > > > Thus spake Brian K McIntire > >I already spoke to someone at 3COM. They told me they would get back to me > >yesterday, but didn't. Now it's Thursday and they don't work today. > >Any comments? > > Heh...yeah...welcome to the user's side. :D > -- > 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-13 00:21:16
First of all, Jeff, go to sleep. :) Second..... Just in case you meant how do you set the idle times directly on the NetServer or Hiper ARC: The NetServer does not support session timeout without RADIUS for idletimeout set all idletime 15 (Where 15 is in minutes) For the HiPer ARC just apply the values you want to the default user. All users created after that will have the correct settings. This is very sloppy in my opinion. Better to use the RADIUS. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, = = Security, and Implementation. Offering both installation and = = support, along with remote management and monitoring packages for = = dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Thursday, November 12, 1998 9:22 PM Thus spake andy >While we are talking about timeouts... >How can I set: >#1 an idletimeout and session timeout in the netserver card (3.7.24) Idle-Timeout = 720 Session-Timeout = 42516 These are in seconds, using Merit RADIUS...your dictionary may be slightly different. >#2 an idletimeout and session timeout in the hiperarc card (4.0.30) I would assume similar, but don't know. >#3 do they work? On the NETServers, yes. Keep in mind (and I'm sure its hard to forget with all the discussion going on) that its quite easy to defeat idle-timeouts as they stand...a single packet of *any* type will reset the idle timer. -- 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) How much sleep do I need?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-13 08:15:06
Thus spake Brian K McIntire >First of all, Jeff, go to sleep. :) Go to sleep? I just got up this morning :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) DUN1.3 and MPP
From: MegaZone <megazone@megazone.org>
Date: 1998-11-13 08:50:44
Once upon a time Brian K McIntire shaped the electrons to say... >======================================================================== >= Brian K. McIntire bmcintire@commnet.com = >= Systems Engineer III 317-558-5050 x113 = >= CommNetPlus, Indianapolis, IN http://www.commnet.com = >= Your Remote Access and Security Experts! = >= = >= Our experienced technicians can design and install your high speed = >= network for you. From Operating Systems and servers to routers and = >= firewalls nobody does it better than CommNetPlus. Our Technical = >= Support staff is available to you 24 hours a day to meet your needs.= >= Offering remote management and monitoring packages for dedicated = >= clients. (Specializing in ISP's). "Let us do the work for you!" = >= = >= Firm partnerships est. with current and emerging leaders of today's = >= technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = >= Serving North America and parts of Canada. Reselling to the world. = >======================================================================== A 17 line .sig... Could you perhaps STOP THAT?! You do NOT need to place an ad this size on every post. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Dynamic IPX on HiPer ARC 4.1.78 -4 and with RADIUS 6.0.8
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-13 09:16:16
Depends on what the IPX system setup was. All you say here is that you set the ipx for unnumberd initially and then after your upgrade you could not use unnumbred. Well is there some equipment on the network that is not using split-horizon? Did anyone poison the route? Get me some debug or open a ticket and we will have it working. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 12 Nov 1998, Brian K McIntire wrote: > > I configured a HiPer ARC running 4.1.11 with an IPX network going out Eth:2. > I configured a user on the HiPer ARC with the IPX network # fffffffc. It > worked like a charm. Then the customer reported trouble with web-TV. We > upgraded to 4.1.78 - 4. Once upgraded the network # fffffffc was not > working. The only way we could get ipx to work at all was to assign a > specific ipx # or to configure an ipx pool. I have two questions: Is this > a bug or did I miss something? Are there plans to include IPX pools in > RADIUS since the HiPer ARC seems to support that attribute. > I already spoke to someone at 3COM. They told me they would get back to me > yesterday, but didn't. Now it's Thursday and they don't work today. > Any comments? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) filtering service (fwd)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-13 09:55:34
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Thursday, November 12, 1998 6:50 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) filtering service (fwd) | | |Thus spake Angela A. Burford |>the portmaster through choicenet, so that it will be used in that | |>I'd like to make this work with my usr's too (i have chassis with |>netservers, quad modems nmc and dual pri cards and other with hiperDSP's |>hiperARC and nmc cards). I understand that I can |>pass the names of the filters to be used at the time the user connects, |>but is it possible to load the actual filter that is stored in my |>radius server into the hiperARC / netserver so that it will applied to the |>connection? If so, how can that be done? | |Can't reasonably be done on NETServers...the HARC's have the ability to |handle "dynamic filters" given a RADIUS server that supports it. Not |having HARC's to really play with extensively, I don't know how to do |this. :) |-- The VSA's for building filters in a RADIUS access accept packet work for both HARC and NETSERVER. Thus TFTP is not required. If you wanted to change the filter rules mid-call, your out of luck with your netserver. -M
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-13 10:00:43
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire |Sent: Friday, November 13, 1998 12:21 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Solution for idle time limits and dual logins | |The NetServer does not support session timeout without RADIUS |for idletimeout set all idletime 15 (Where 15 is in minutes) | |For the HiPer ARC just apply the values you want to the default user. All |users created after that will have the correct settings. | |This is very sloppy in my opinion. Better to use the RADIUS. Sloppy? Default user applies to all dial-in users. Not just locally created ones. This is not sloppy. It's quite convenient. If you set the same Idle timeout or session timeout for all/most of your users. Just set that on the default user and remove the attributes from your default user in the RADIUS users file. If a particular user or set of users gets different values then include them in RADIUS. RADIUS attributes always take precedence over default user settings. -M |======================================================================= |= Brian K. McIntire bmcintire@commnet.com = |= Systems Engineer III 317-558-5050 x113 = |= CommNetPlus, Indianapolis, IN http://www.commnet.com = |= = |= Experts in Remote Access and all areas of NetWork Design, = |= Security, and Implementation. Offering both installation and = |= support, along with remote management and monitoring packages for = |= dedicated clients (specializing in ISP's). = |= Firm partnerships established with all the key players. = |= Sales 800-845-2981 x117 (Aggressive Pricing strategies) = |= = |= Serving North America and parts of Canada. Reselling to the world. = |======================================================================= | Isn't this signature a little long?? :) (4/5 lines max in netiquette)
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Brian <signal@shreve.net>
Date: 1998-11-13 10:06:44
On Tue, 10 Nov 1998, Mark Lemmert wrote: > Does anybody have a good solution in place for enforcing idle times and > multiple logins? > > I am currently using PMMON and I get no end of complaints from people > that pmmon disconnects them at inappropriate times among other things. > > If anybody has a different/better way of doing this I'de love to hear about it. PMMON. PMMON doesn't disconnect at inappropriate times, users lie. It only disconnects after a set amount of inactivity. Unless you're talking about a hard limit you have set (which we do, and set at 24hours). Brian > > > > Mark Lemmert cto@athenet.net > Chief Technical Officer (920)954-9799 > AthEnet Data Exchange http://www.athenet.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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) DUN1.3 and MPP
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-13 10:07:53
Ours doesn't work unless it hits the same rack. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Friday, November 13, 1998 8:28 AM > To: USRobotics TC Mailing List > Subject: (usr-tc) DUN1.3 and MPP > > > I have a user trying to connect using DUN1.3 and Win98. He is trying to > do MPP using 2 USR 56k external sportsters. > > Should this work? Both modems connect but then the 2nd one disconnects. > I have him setup for dual channel, so i am not sure what is going on > exactly and wasn't sure if their are some known issues here. > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) DUN1.3 and MPP
From: Eric Forcey <eric@psnw.com>
Date: 1998-11-13 10:20:25
We have/had this same problem as well. According to support @ 3com, they were aware of issues with DUN 1.3 and MPP saying that it wouldn't work. Haven't heard if there has been a work around yet -Eric On Fri, 13 Nov 1998, Terry Kennedy wrote: > Ours doesn't work unless it hits the same rack. > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > Sent: Friday, November 13, 1998 8:28 AM > > To: USRobotics TC Mailing List > > Subject: (usr-tc) DUN1.3 and MPP > > > > > > I have a user trying to connect using DUN1.3 and Win98. He is trying to > > do MPP using 2 USR 56k external sportsters. > > > > Should this work? Both modems connect but then the 2nd one disconnects. > > I have him setup for dual channel, so i am not sure what is going on > > exactly and wasn't sure if their are some known issues here. > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) DUN1.3 and MPP
From: Brian <signal@shreve.net>
Date: 1998-11-13 10:27:55
I have a user trying to connect using DUN1.3 and Win98. He is trying to do MPP using 2 USR 56k external sportsters. Should this work? Both modems connect but then the 2nd one disconnects. I have him setup for dual channel, so i am not sure what is going on exactly and wasn't sure if their are some known issues here. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) filtering service (fwd)
From: Brian <signal@shreve.net>
Date: 1998-11-13 10:37:43
On Thu, 12 Nov 1998, Jeff Mcadams wrote: > Thus spake Angela A. Burford > >the portmaster through choicenet, so that it will be used in that > > >I'd like to make this work with my usr's too (i have chassis with > >netservers, quad modems nmc and dual pri cards and other with hiperDSP's > >hiperARC and nmc cards). I understand that I can > >pass the names of the filters to be used at the time the user connects, > >but is it possible to load the actual filter that is stored in my > >radius server into the hiperARC / netserver so that it will applied to the > >connection? If so, how can that be done? > > Can't reasonably be done on NETServers...the HARC's have the ability to > handle "dynamic filters" given a RADIUS server that supports it. Not > having HARC's to really play with extensively, I don't know how to do > this. :) Isn't "hint assigned" on the netserver enough for it to support dynamic filters? it should be......... > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) DUN1.3 and MPP
From: Brian <signal@shreve.net>
Date: 1998-11-13 10:39:00
On Fri, 13 Nov 1998, Jeff Mcadams wrote: > Thus spake Brian > >I have a user trying to connect using DUN1.3 and Win98. He is trying to > >do MPP using 2 USR 56k external sportsters. > > <nit>Should be just MP, MPP is an Ascend proprietary thing</nit> > > >Should this work? Both modems connect but then the 2nd one disconnects. > >I have him setup for dual channel, so i am not sure what is going on > >exactly and wasn't sure if their are some known issues here. > > Check to see if the Windows machine is dialing both modems at the same > time. I know NT does this, and it can give the NAS fits. I believe > turning off LCP extensions in NT turns off this behavior, but am not > sure. The dialilng is about 30 seconds spaced. They authenticate, but right after that the 2nd channel drops. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-13 10:41:18
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire |Sent: Friday, November 13, 1998 11:28 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Solution for idle time limits and dual logins | | |I have seen the default user on the HiPer ARC settings not apply to RADIUS |users. Maybe it was broke in one of the versions of code I had then. I'll |take another look | It could have been.. But I havent seen it.. The only time default user settings would not apply is if there was a conflicting RADIUS attribute. Then RADIUS wins the tie. For example. Default user has idle time set to 600 and the Radius attribute "Idle-Timeout=1200" is in the access accept. The idle timeout will be 1200 for that user. -M
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-13 11:28:25
I have seen the default user on the HiPer ARC settings not apply to RADIUS users. Maybe it was broke in one of the versions of code I had then. I'll take another look ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = = = Our experienced technicians can design and install your high speed = = network for you. From Operating Systems and servers to routers and = = firewalls nobody does it better than CommNetPlus. Our Technical = = Support staff is available to you 24 hours a day to meet your needs.= = Offering remote management and monitoring packages for dedicated = = clients. (Specializing in ISP's). "Let us do the work for you!" = = = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski Sent: Friday, November 13, 1998 10:01 AM |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire |Sent: Friday, November 13, 1998 12:21 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Solution for idle time limits and dual logins | |The NetServer does not support session timeout without RADIUS |for idletimeout set all idletime 15 (Where 15 is in minutes) | |For the HiPer ARC just apply the values you want to the default user. All |users created after that will have the correct settings. | |This is very sloppy in my opinion. Better to use the RADIUS. Sloppy? Default user applies to all dial-in users. Not just locally created ones. This is not sloppy. It's quite convenient. If you set the same Idle timeout or session timeout for all/most of your users. Just set that on the default user and remove the attributes from your default user in the RADIUS users file. If a particular user or set of users gets different values then include them in RADIUS. RADIUS attributes always take precedence over default user settings. -M |======================================================================= |= Brian K. McIntire bmcintire@commnet.com = |= Systems Engineer III 317-558-5050 x113 = |= CommNetPlus, Indianapolis, IN http://www.commnet.com = |= = |= Experts in Remote Access and all areas of NetWork Design, = |= Security, and Implementation. Offering both installation and = |= support, along with remote management and monitoring packages for = |= dedicated clients (specializing in ISP's). = |= Firm partnerships established with all the key players. = |= Sales 800-845-2981 x117 (Aggressive Pricing strategies) = |= = |= Serving North America and parts of Canada. Reselling to the world. = |======================================================================= | Isn't this signature a little long?? :) (4/5 lines max in netiquette) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) DUN1.3 and MPP
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-13 11:31:01
Yes you can bundle channels together from 2 external sportsters. I do not know if it works with DUN 1.3. Haven't tried it ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = = = Our experienced technicians can design and install your high speed = = network for you. From Operating Systems and servers to routers and = = firewalls nobody does it better than CommNetPlus. Our Technical = = Support staff is available to you 24 hours a day to meet your needs.= = Offering remote management and monitoring packages for dedicated = = clients. (Specializing in ISP's). "Let us do the work for you!" = = = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Sent: Friday, November 13, 1998 10:28 AM I have a user trying to connect using DUN1.3 and Win98. He is trying to do MPP using 2 USR 56k external sportsters. Should this work? Both modems connect but then the 2nd one disconnects. I have him setup for dual channel, so i am not sure what is going on exactly and wasn't sure if their are some known issues here. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) DUN1.3 and MPP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-13 11:32:54
Thus spake Brian >I have a user trying to connect using DUN1.3 and Win98. He is trying to >do MPP using 2 USR 56k external sportsters. <nit>Should be just MP, MPP is an Ascend proprietary thing</nit> >Should this work? Both modems connect but then the 2nd one disconnects. >I have him setup for dual channel, so i am not sure what is going on >exactly and wasn't sure if their are some known issues here. Check to see if the Windows machine is dialing both modems at the same time. I know NT does this, and it can give the NAS fits. I believe turning off LCP extensions in NT turns off this behavior, but am not sure. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Total Controll for Sale
From: Tony Loosle <tony@tcsourceone.com>
Date: 1998-11-13 13:22:23
For Sale: USR Total Control 6 Quad Digital Modems, 33.6 and isdn. will do x2 with upgrade. Dual PRI card Net management card Net server card New, never in service. Make an offer on parts or the entire box!! Tony
Subject: Re: (usr-tc) DUN1.3 and MPP
From: Jason W <jwatkins@iland.net>
Date: 1998-11-13 13:46:18
Make sure that you have for the port type 'diail in' only. If you try to use dial in & dial out, or two way, it will not work properly. Also you need to make sure and set up MPIP so bundles can be established across multiple chassis'. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins jwatkins@iland.net I-Land NOC Tech http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- :Do you have MPIP configured properly. Otherwise it won't work unless you :hit the same rack : :======================================================================== := Brian K. McIntire bmcintire@commnet.com = := Systems Engineer III 317-558-5050 x113 = := CommNetPlus, Indianapolis, IN http://www.commnet.com = := Your Remote Access and Security Experts! = := = := Our experienced technicians can design and install your high speed = := network for you. From Operating Systems and servers to routers and = := firewalls nobody does it better than CommNetPlus. Our Technical = := Support staff is available to you 24 hours a day to meet your needs.= := Offering remote management and monitoring packages for dedicated = := clients. (Specializing in ISP's). "Let us do the work for you!" = := = := Firm partnerships est. with current and emerging leaders of today's = := technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = := Serving North America and parts of Canada. Reselling to the world. = :======================================================================== : : :-----Original Message----- :From: owner-usr-tc@lists.xmission.com :[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy :Sent: Friday, November 13, 1998 12:08 PM :To: usr-tc@lists.xmission.com :Subject: RE: (usr-tc) DUN1.3 and MPP : : :Ours doesn't work unless it hits the same rack. : :> -----Original Message----- :> From: owner-usr-tc@lists.xmission.com :> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian :> Sent: Friday, November 13, 1998 8:28 AM :> To: USRobotics TC Mailing List :> Subject: (usr-tc) DUN1.3 and MPP :> :> :> I have a user trying to connect using DUN1.3 and Win98. He is trying to :> do MPP using 2 USR 56k external sportsters. :> :> Should this work? Both modems connect but then the 2nd one disconnects. :> I have him setup for dual channel, so i am not sure what is going on :> exactly and wasn't sure if their are some known issues here. :> :> Brian :> :> :> ------------------------------------------------------------------------- - :> Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service :> Provider :> Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ :> signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, :> (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 :> :> :> - :> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" :> with "unsubscribe usr-tc" in the body of the 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) DUN1.3 and MPP
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-13 14:04:32
Do you have MPIP configured properly. Otherwise it won't work unless you hit the same rack ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = = = Our experienced technicians can design and install your high speed = = network for you. From Operating Systems and servers to routers and = = firewalls nobody does it better than CommNetPlus. Our Technical = = Support staff is available to you 24 hours a day to meet your needs.= = Offering remote management and monitoring packages for dedicated = = clients. (Specializing in ISP's). "Let us do the work for you!" = = = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy Sent: Friday, November 13, 1998 12:08 PM Ours doesn't work unless it hits the same rack. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > Sent: Friday, November 13, 1998 8:28 AM > To: USRobotics TC Mailing List > Subject: (usr-tc) DUN1.3 and MPP > > > I have a user trying to connect using DUN1.3 and Win98. He is trying to > do MPP using 2 USR 56k external sportsters. > > Should this work? Both modems connect but then the 2nd one disconnects. > I have him setup for dual channel, so i am not sure what is going on > exactly and wasn't sure if their are some known issues here. > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) front face plates, model numbers
From: Laszlo Vecsey <laszlo@internexus.net>
Date: 1998-11-13 18:20:21
Does anyone have the model numbers for the front face plates on the usr-tc chasis, both one and two wide in particular -- does the most recent netserver to hyper upgrade bundle include one? (minor point, but it'll keep the dust out.. the most recent bundle in question includes just one hyperdsp, leaving one slot free) -L
Subject: RE: (usr-tc) DUN1.3 and MPP
From: Brian <signal@shreve.net>
Date: 1998-11-13 20:26:16
On Fri, 13 Nov 1998, Terry Kennedy wrote: > Ours doesn't work unless it hits the same rack. so mpip of win98 mp doesnt work? > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > > Sent: Friday, November 13, 1998 8:28 AM > > To: USRobotics TC Mailing List > > Subject: (usr-tc) DUN1.3 and MPP > > > > > > I have a user trying to connect using DUN1.3 and Win98. He is trying to > > do MPP using 2 USR 56k external sportsters. > > > > Should this work? Both modems connect but then the 2nd one disconnects. > > I have him setup for dual channel, so i am not sure what is going on > > exactly and wasn't sure if their are some known issues here. > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > > Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) DUN1.3 and MPP
From: Brian <signal@shreve.net>
Date: 1998-11-13 20:27:29
On Fri, 13 Nov 1998, Jason W wrote: > Make sure that you have for the port type 'diail in' > only. If you try to use dial in & dial out, or two way, > it will not work properly. Also you need to make sure > and set up MPIP so bundles can be established > across multiple chassis'. mpip works fine here, with isdn et al. But its just this w98 user having problems, and someone posted to the list that their is in fact known 3com issues with w98 mp. > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Jason Watkins jwatkins@iland.net > I-Land NOC Tech http://www.iland.net > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -----Original Message----- > From: Brian K McIntire <bmcintire@commnet.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, November 13, 1998 1:09 PM > Subject: RE: (usr-tc) DUN1.3 and MPP > > > :Do you have MPIP configured properly. Otherwise it won't work unless you > :hit the same rack > : > :======================================================================== > := Brian K. McIntire bmcintire@commnet.com = > := Systems Engineer III 317-558-5050 x113 = > := CommNetPlus, Indianapolis, IN http://www.commnet.com = > := Your Remote Access and Security Experts! = > := = > := Our experienced technicians can design and install your high speed = > := network for you. From Operating Systems and servers to routers and = > := firewalls nobody does it better than CommNetPlus. Our Technical = > := Support staff is available to you 24 hours a day to meet your needs.= > := Offering remote management and monitoring packages for dedicated = > := clients. (Specializing in ISP's). "Let us do the work for you!" = > := = > := Firm partnerships est. with current and emerging leaders of today's = > := technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = > := Serving North America and parts of Canada. Reselling to the world. = > :======================================================================== > : > : > :-----Original Message----- > :From: owner-usr-tc@lists.xmission.com > :[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Terry Kennedy > :Sent: Friday, November 13, 1998 12:08 PM > :To: usr-tc@lists.xmission.com > :Subject: RE: (usr-tc) DUN1.3 and MPP > : > : > :Ours doesn't work unless it hits the same rack. > : > :> -----Original Message----- > :> From: owner-usr-tc@lists.xmission.com > :> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > :> Sent: Friday, November 13, 1998 8:28 AM > :> To: USRobotics TC Mailing List > :> Subject: (usr-tc) DUN1.3 and MPP > :> > :> > :> I have a user trying to connect using DUN1.3 and Win98. He is trying to > :> do MPP using 2 USR 56k external sportsters. > :> > :> Should this work? Both modems connect but then the 2nd one disconnects. > :> I have him setup for dual channel, so i am not sure what is going on > :> exactly and wasn't sure if their are some known issues here. > :> > :> Brian > :> > :> > :> ------------------------------------------------------------------------- > - > :> Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > :> Provider > :> Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > :> signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > :> (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > :> > :> > :> - > :> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > :> with "unsubscribe usr-tc" in the body of the 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) Total Controll for Sale
From: Jim Logan <jim@top.net>
Date: 1998-11-13 21:24:25
For which Piece :) (Ok, so it's Friday the 13th, I guess) At 10:17 PM 11/13/98 -0500, you wrote: >Will offer $2K >John > >On Friday, November 13, 1998 3:22 PM, Tony Loosle [SMTP:tony@tcsourceone.com] wrote: >> For Sale: >> USR Total Control >> >> 6 Quad Digital Modems, 33.6 and isdn. will do x2 with upgrade. >> Dual PRI card >> Net management card >> Net server card >> >> New, never in service. >> >> Make an offer on parts or the entire box!! >> >> Tony >> >> >> >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. > > ***** Top Net InterNet Services ***** Omaha, Nebraska Husker Heaven www.top.net (402) 291-1542 Visit Our BBS at: www.hawgwild.com
Subject: RE: (usr-tc) Total Controll for Sale
From: John Verreault <verreaul@aei.ca>
Date: 1998-11-13 22:17:04
Will offer $2K John On Friday, November 13, 1998 3:22 PM, Tony Loosle [SMTP:tony@tcsourceone.com] wrote: > For Sale: > USR Total Control > > 6 Quad Digital Modems, 33.6 and isdn. will do x2 with upgrade. > Dual PRI card > Net management card > Net server card > > New, never in service. > > Make an offer on parts or the entire box!! > > Tony > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) rip strangeness
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-14 08:40:37
have a netserver advertising 1.2.3.0/32 into RIP. strange, strange. 1.2.3.0 /32 1.2.3.3 HD 2 net0 0 (1.2.3.0 is the network, 1.2.3.4 is ether0 of the netserver) when my cisco sees it it quits speaking rip with it. can't find out why it's there (no deubg tools afaik), no netmasks or static routes anywhere except for the default. really strange stuff. anyone ever seen this? thanks! |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: Re: (usr-tc) rip strangeness
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-14 15:24:48
On Sat, 14 Nov 1998, bryan s. blank wrote: > have a netserver advertising 1.2.3.0/32 into RIP. strange, > strange. > > 1.2.3.0 /32 1.2.3.3 HD 2 net0 0 > This is a host dynamic route learnt by the Netserver from the ethernet. Either you have a workstation or a router doing this or someone in your network is giving this route. Check your netmask on your netserver and on the other devices on your network. krish > (1.2.3.0 is the network, 1.2.3.4 is ether0 of the netserver) > > when my cisco sees it it quits speaking rip with it. can't find > out why it's there (no deubg tools afaik), no netmasks or static > routes anywhere except for the default. really strange stuff. > > anyone ever seen this? > > thanks! > > |o|----------------------------------------------------------------------|o| > |o| bryan s. blank (203)-351-1178 voice |o| > |o| senior systems analyst (203)-351-1186 fax |o| > |o| discovernet, incorporated (203)-979-5126 emerg |o| > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) rip strangeness
From: Brian <signal@shreve.net>
Date: 1998-11-14 18:30:35
On Sat, 14 Nov 1998, bryan s. blank wrote: > have a netserver advertising 1.2.3.0/32 into RIP. strange, > strange. > > 1.2.3.0 /32 1.2.3.3 HD 2 net0 0 > > (1.2.3.0 is the network, 1.2.3.4 is ether0 of the netserver) > > when my cisco sees it it quits speaking rip with it. can't find > out why it's there (no deubg tools afaik), no netmasks or static > routes anywhere except for the default. really strange stuff. the cisco can show you where it is coming from and you can run a debug rip on it. > > anyone ever seen this? > > thanks! > > |o|----------------------------------------------------------------------|o| > |o| bryan s. blank (203)-351-1178 voice |o| > |o| senior systems analyst (203)-351-1186 fax |o| > |o| discovernet, incorporated (203)-979-5126 emerg |o| > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) rip strangeness
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-14 19:15:50
|o| This is a host dynamic route learnt by the Netserver from the ethernet. |o| Either you have a workstation or a router doing this or someone in your |o| network is giving this route. Check your netmask on your netserver and |o| on the other devices on your network. extremely strange. 3 netservers going in to one switch, interface ethernet 1/1 on a cisco 7206. netserver is 1.2.3.3 router rip version 2 timers basic 30 90 5 120 passive-interface ... (everything but ethernet 1/1) .... network 1.2.3.0 no auto-summary the switch it's on doesn't know how to speak rip. crisco says: 6d03h: RIP: received v2 update from 1.2.3.3 on Ethernet1/1 6d03h: 1.2.4.192/27 -> 0.0.0.0 in 1 hops 6d03h: 1.2.3.0/32 (illegal address) 6d03h: RIP: Update contains 1 routes nobody else is broadcasting 1.2.3.0/32 ... i'm quite stumped. thanks so much for your help, as always. |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: Re: (usr-tc) Total Controll for Sale
From: Dale Levendoski <dale-lev@mwt.net>
Date: 1998-11-14 21:32:39
--Cyberdog-MixedBoundary-0023658F X-Fontfamily: Courier X-Fontsize: 12 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <FIXED>Tony, Why are you selling this? Is it sold yet? Dale-Lev@MWT.Net On Fri, Nov 13, 1998 2:22 PM, </FIXED> --Cyberdog-MixedBoundary-0023658F Content-Type: application/X-url Content-Transfer-Encoding: base64 Content-Description: Tony Loosle bWFpbHRvOnRvbnlAdGNzb3VyY2VvbmUuY29t --Cyberdog-MixedBoundary-0023658F X-Fontfamily: Courier X-Fontsize: 12 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <FIXED> wrote:</FIXED><FIXED> </FIXED><FIXED>For Sale: USR Total Control 6 Quad Digital Modems, 33.6 and isdn. will do x2 with upgrade. Dual PRI card Net management card Net server card New, never in service. Make an offer on parts or the entire box!!</FIXED> --Cyberdog-MixedBoundary-0023658F--
Subject: (usr-tc) Confirmation
From: Terry Kennedy <terry@olypen.com>
Date: 1998-11-16 11:52:56
In the process of trying to turn of mlppp ( god I hope that's what I'm talking about - the ability for people to call into our system and bond channels ) off, I've got what I think I need. If someone could confirm this, I would appreciate it. On the netserver it was "set mp off" On the ARC is it " set network user default ppp max_channels 1 " ? Or am I way off here.. Terry Kennedy
Subject: (usr-tc) fs; Netserver 16, Netserver 8I, Netserver 16I
From: DataComm Specialist <sales@wrca.net>
Date: 1998-11-16 13:05:12
I have the following equipment available for sale. 7- Netserver 16 1- Netserver 16I 1- Netserver 8I 2- MP8 4- MP16 All sold guaranteed working. Steve Rivera WRCA, Inc. http://www.wrca.net 4 Kinney Rd mailto:sales@wrca.net Manalapan, NJ 07726 Online Orders Accepted p: 732-462-0062 f: 732-462-8455 "Everything DataCom, Nothing but Net"
Subject: (usr-tc) disconnect reason code 62
From: allen_lai@3com.com
Date: 1998-11-16 13:29:44
Hello, Who can give me detail meaning of the disconnect reason code 62--received disconnect command from gateway? An explanation that we already know is that the dialin user was disconnected by the netserver/HiperArc card for the incorrect password or incompatible network protocol. But we found several recorder indicating the disconnect happened after the call established for several minutes. Does it mean that the netserver/hiper Arc card raise the disconnect for unknow reason? Allen
Subject: (usr-tc) accounting problem through NMC
From: allen_lai@3com.com
Date: 1998-11-16 13:44:22
Hello,all We have installed a USR S/A server in a NT workstation(Intel pro233) to collect the accounting informaiton from NMC. We created about 60 NMC/chassis---raduis accounting client in one S/A server. At first, everything works OK.We got accounting information from all created clients. But gradually, some clients will disappered.We can't got any accounting information of these disappered client now from S/A now. When ping the NMC, it's ok.We can also managned these chassis through TCM. Any hints? Allen
Subject: Re: (usr-tc) Confirmation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-16 14:59:57
Thus spake Terry Kennedy >In the process of trying to turn of mlppp ( god I hope that's what >I'm talking about - the ability for people to call into our system >and bond channels ) off, I've got what I think I need. If someone could >confirm this, I would appreciate it. MP (commonly called MLPPP...multi-link PPP being the full name and meaning the ability to bundle multiple channels together to effectively aggregate the bandwidth of all the channels) is what you're refer'ing to. >On the netserver it was "set mp off" This will actually turn off MP option negotiation...this might break things. >On the ARC is it " set network user default ppp max_channels 1 " ? This doesn't turn off MP option negotiation, but limits the client side to only connecting one channel in a bundle. This is probably more along the lines of what you want, and the same thing can be done on the NETServer, either through RADIUS or through the local users table I believe. The RADIUS attribute to limit this to one channel is: Port-Limit = 1 -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Confirmation
From: Postmaster <postmaster@keyconn.net>
Date: 1998-11-16 15:16:00
At 02:59 PM 11/16/98 -0500, Jeff McAdams wrote: >>On the ARC is it " set network user default ppp max_channels 1 " ? > >This doesn't turn off MP option negotiation, but limits the client side >to only connecting one channel in a bundle. This is probably more along >the lines of what you want, and the same thing can be done on the >NETServer, either through RADIUS or through the local users table I >believe. Will this work to prohibit simultaneous logins, or just multiple logins using 'bonded' channels? I'd like to have some way of preventing multiple logins since S&A Server can't be counted on to do so properly. Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Confirmation
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-16 15:21:32
On Mon, 16 Nov 1998, Jeff Mcadams wrote: > The RADIUS attribute to limit this to one channel is: > Port-Limit = 1 This seems to be broken on current ARC releases up to and including at least 4.1.78; you have to also use "Max_Channels = 1" (which is a VSA) to do the right thing there. On the NETserver, it's fine. Go back through the archives a month or two and you can see me whining away about this :) We actually have both Port-Limit AND Max_Channels in the Radius users file. That seems to take care of things. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep
Subject: RE: (usr-tc) accounting problem through NMC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-16 16:21:01
Hello,all We have installed a USR S/A server in a NT workstation(Intel pro233) to collect the accounting informaiton from NMC. We created about 60 NMC/chassis---raduis accounting client in one S/A server. At first, everything works OK.We got accounting information from all created clients. But gradually, some clients will disappered. ********* What do you mean by this? Have you used TCM to open the NMC Logging Group info and make sure you see the Primary Logging Server listed? We can't got any accounting information of these disappered client now from S/A now. When ping the NMC, it's ok.We can also managned these chassis through TCM. Any hints? 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) PRI settings blown away by NMC
From: Chris Hanes <chris@internetcreations.com>
Date: 1998-11-16 16:36:58
Hey all, I'm trying to map modems to slots under chassis slot device configuration on a dual pri nac. The settings take so long as my NMC is not plugged in. Once plugged in the NMC obscures these settings and prevents me from reentering the settings on the pri card (i.e. the settings won't take when the NMC is plugged in). I've been through a couple pri cards and figure I must be doing something stupid. I'm running tcs 3.3 (3.02 on the PRI nac and 5.5.5 on the NMC) Any help would be IMMENSELY appreciated. Thanks, Chris Hanes Internet Creations
Subject: RE: (usr-tc) PRI settings blown away by NMC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-16 16:53:54
Sounds like you have "Auto config upon card initialization" enabled on your NMC. 1. Load TCM 2. Bring up your chassis 3. Click on the NMC 4. Click on Configure/program settings/configuration group 5. Make sure auto config is disabled. 6. If it was enabled set it and click ok. 7. go to configure/action commands and save chassis to nvram (don't really need this one but do it anyway) 8. Save UI to eeprom 9. Reboot 10. If the setting was disabled then restore your NMC (not chassis) from default by clicking on the NMC and going to configure/action commands and choosing restore NMC from default 11. then perform steps 7 & 8 and then 9 from above This should solve your problem. Remember you will need to reconfigure the Logging group on the NMC if you have restored it from default and wish to do accounting ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = = = Our experienced technicians can design and install your high speed = = network for you. From Operating Systems and servers to routers and = = firewalls nobody does it better than CommNetPlus. Our Technical = = Support staff is available to you 24 hours a day to meet your needs.= = Offering remote management and monitoring packages for dedicated = = clients. (Specializing in ISP's). "Let us do the work for you!" = = = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Chris Hanes Sent: Monday, November 16, 1998 3:37 PM Hey all, I'm trying to map modems to slots under chassis slot device configuration on a dual pri nac. The settings take so long as my NMC is not plugged in. Once plugged in the NMC obscures these settings and prevents me from reentering the settings on the pri card (i.e. the settings won't take when the NMC is plugged in). I've been through a couple pri cards and figure I must be doing something stupid. I'm running tcs 3.3 (3.02 on the PRI nac and 5.5.5 on the NMC) Any help would be IMMENSELY appreciated. Thanks, Chris Hanes Internet Creations - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) PRI settings blown away by NMC
From: Chris Hanes <chris@internetcreations.com>
Date: 1998-11-16 18:05:16
Hey Brian, Thanks for the reponse. Auto config was disabled. I've tried restoring NMC from factory default several times to no avail. When I boot the box, I've been watching the pri cards chassis slot settings. The pri card seems to boot quickly and I'm able to see the settings briefly before they are wiped out, leaving the pri card seeing only itself in slot 1 and the netserver card in slot 16. Any other ideas? Thanks, Chris Hanes Brian K McIntire wrote: > > Sounds like you have "Auto config upon card initialization" enabled on your > NMC. > > 1. Load TCM > 2. Bring up your chassis > 3. Click on the NMC > 4. Click on Configure/program settings/configuration group > 5. Make sure auto config is disabled. > 6. If it was enabled set it and click ok. > 7. go to configure/action commands and save chassis to nvram (don't really > need this one but do it anyway) > 8. Save UI to eeprom > 9. Reboot > 10. If the setting was disabled then restore your NMC (not chassis) from > default by clicking on the NMC and going to configure/action commands and > choosing restore NMC from default > 11. then perform steps 7 & 8 and then 9 from above > This should solve your problem. Remember you will need to reconfigure the > Logging group on the NMC if you have restored it from default and wish to do > accounting > > ======================================================================== > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = Your Remote Access and Security Experts! = > = = > = Our experienced technicians can design and install your high speed = > = network for you. From Operating Systems and servers to routers and = > = firewalls nobody does it better than CommNetPlus. Our Technical = > = Support staff is available to you 24 hours a day to meet your needs.= > = Offering remote management and monitoring packages for dedicated = > = clients. (Specializing in ISP's). "Let us do the work for you!" = > = = > = Firm partnerships est. with current and emerging leaders of today's = > = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = > = Serving North America and parts of Canada. Reselling to the world. = > ========================================================================
Subject: Re: (usr-tc) PRI settings blown away by NMC
From: Jamie Orzechowski <mhz@recorder.ca>
Date: 1998-11-16 18:17:25
have you tried the setting the config via the CONSOLE port?? ... I had the same problem that I could get to the config via TCM but settings would never "take" ... I did it via console (restore from default, config, save to nvram, reset) ... and worked fine ... -----Original Message----- >Hey Brian, > >Thanks for the reponse. Auto config was disabled. I've tried restoring >NMC from factory default several times to no avail. When I boot the >box, >I've been watching the pri cards chassis slot settings. The pri card >seems >to boot quickly and I'm able to see the settings briefly before they are >wiped out, leaving the pri card seeing only itself in slot 1 and the >netserver >card in slot 16. Any other ideas? > >Thanks, >Chris Hanes > >Brian K McIntire wrote: >> >> Sounds like you have "Auto config upon card initialization" enabled on your >> NMC. >> >> 1. Load TCM >> 2. Bring up your chassis >> 3. Click on the NMC >> 4. Click on Configure/program settings/configuration group >> 5. Make sure auto config is disabled. >> 6. If it was enabled set it and click ok. >> 7. go to configure/action commands and save chassis to nvram (don't really >> need this one but do it anyway) >> 8. Save UI to eeprom >> 9. Reboot >> 10. If the setting was disabled then restore your NMC (not chassis) from >> default by clicking on the NMC and going to configure/action commands and >> choosing restore NMC from default >> 11. then perform steps 7 & 8 and then 9 from above >> This should solve your problem. Remember you will need to reconfigure the >> Logging group on the NMC if you have restored it from default and wish to do >> accounting >> >> ======================================================================== >> = Brian K. McIntire bmcintire@commnet.com = >> = Systems Engineer III 317-558-5050 x113 = >> = CommNetPlus, Indianapolis, IN http://www.commnet.com = >> = Your Remote Access and Security Experts! = >> = = >> = Our experienced technicians can design and install your high speed = >> = network for you. From Operating Systems and servers to routers and = >> = firewalls nobody does it better than CommNetPlus. Our Technical = >> = Support staff is available to you 24 hours a day to meet your needs.= >> = Offering remote management and monitoring packages for dedicated = >> = clients. (Specializing in ISP's). "Let us do the work for you!" = >> = = >> = Firm partnerships est. with current and emerging leaders of today's = >> = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = >> = Serving North America and parts of Canada. Reselling to the world. = >> ======================================================================== > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Confirmation
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-16 18:26:14
At 02:59 PM 11/16/98 -0500, Jeff McAdams wrote: >>On the ARC is it " set network user default ppp max_channels 1 " ? > >This doesn't turn off MP option negotiation, but limits the client side >to only connecting one channel in a bundle. This is probably more along >the lines of what you want, and the same thing can be done on the >NETServer, either through RADIUS or through the local users table I >believe. Will this work to prohibit simultaneous logins, or just multiple logins using 'bonded' channels? I'd like to have some way of preventing multiple logins since S&A Server can't be counted on to do so properly. Thanks, Kirk PS If this post comes again, I apologize, I had sent it with a different return address and wasn't sure if it got rejected or not. Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) Confirmation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-16 19:00:20
Thus spake K Mitchell >At 02:59 PM 11/16/98 -0500, Jeff McAdams wrote: >>This doesn't turn off MP option negotiation, but limits the client side >>to only connecting one channel in a bundle. This is probably more along >>the lines of what you want, and the same thing can be done on the >>NETServer, either through RADIUS or through the local users table I >>believe. >Will this work to prohibit simultaneous logins, or just multiple logins >using 'bonded' channels? Just multiple MP channels in a bundle. This will not prevent multiple logins. There is no clean way to prevent multiple logins cross-chassis at this point. Perhaps some NAS vendor would like to come up with a login-limiting protocol that will really make their NAS boxen act as one unit? Noone has done this yet to my knowledge. >I'd like to have some way of preventing multiple >logins since S&A Server can't be counted on to do so properly. There is no way to do this easily. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) NMC rebooting
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-16 19:16:14
I picked up a used 1866 bundle. The NMC card keeps rebooting. It gets far enough to display the menu on the console, but it reboots before anything can be entered. It appears to be running 5.4.95 on the NMC. Any ideas to fix this? Brian
Subject: Re: (usr-tc) NMC rebooting
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-16 20:13:52
This could be because 1. you have programmed a 0.0.0.0 as ip address of the NMC 2. You have a bad flash Try this. Download 4.3.9 nmc code ( or any 4.x code ) use a program called pcsdl ( comes with the code ) and download that code to the NMC and then program the proper ip address save it and then upgrade it to 5.x code If this does not help then your flash may be corrupted. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 16 Nov 1998, Brian Elfert wrote: > I picked up a used 1866 bundle. > > The NMC card keeps rebooting. It gets far enough to display the menu on > the console, but it reboots before anything can be entered. > > It appears to be running 5.4.95 on the NMC. > > Any ideas to fix this? > > 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. >
Subject: (usr-tc) PRI or not?
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-11-16 20:34:32
What must I do to change my dual E1/CAS cards to use with PRI (ISDN)? And the DSPs ? Should I make some change in the modems also? Can I have in the same chassis some DSP with PRI and others not? - Marcelo
Subject: Re: (usr-tc) NMC rebooting
From: Alan D. Criado <acriado@elink.net>
Date: 1998-11-16 20:41:23
Hi Brian. The same thing happened to me on my NMC once, when I was first setting it up. I had placed 0.0.0.0 for one of the IP addresses and it causes the NMC to perpetually boot. The fix was to load an older version of the software on the NMC (can't remember the version), reconfigure the IP Address so that it wasn't zeros and then it would boot up normally. At this point, I was able to upload the latest version of the software back on the NMC. I don't if this is the same problem you are having, but is sounds similar. Take care. Alan D. Criado At 07:16 PM 11/16/98 -0600, you wrote: >I picked up a used 1866 bundle. > >The NMC card keeps rebooting. It gets far enough to display the menu on >the console, but it reboots before anything can be entered. > >It appears to be running 5.4.95 on the NMC. > >Any ideas to fix this? > >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. >
Subject: (usr-tc) Two subnets on one hiperARC
From: Laurie J Collinsworth <ljc1@cornell.edu>
Date: 1998-11-16 21:04:05
Hello, I have added a second subnet to an existing hiperARC setup to the eth:2 port. I would like to have two ip pools one for each subnet routed out the appropriate port. Currently all I have done is configured the second ethernet port eth:2. I cannot connect to the hiperARC using the new ip address on eth:2 interface. If I do a traceroute, it finds the eth:1 interface and continues looking but never finds the new ip address. Some sort for rip announcement is occuring for the gateway to send the request to the eth:1 interface instead of the eth:2 interface. Perhaps what I want is not possible or could be done with filters. Or perhaps the hiperARC will only answer to the "LAN Host address" but will pass data on to modems connected with the new ip subnet properly. In case people are curious, we have a chassis with 11 hiperDSP cards, 2 hiperARCS, and not enough ip addresses on a 24 bit subnet. We could just split the two subnets and have one on each hiperARC but we would like the redundancy of letting one hiperARC take over all the traffic if the other should fail. Ain't life fun. -Laurie
Subject: RE: (usr-tc) v.90 connect problems
From: Mario M. Bustamante <mario@accesspro.net>
Date: 1998-11-17 02:50:41
I posted the messages below at a time when we were having an unacceptable number of customer complaints. At present we consider the problems to be resolved. The biggest change came when we removed the Hiper ARC from our network and co located it with a CLEC we are working with. When we had it in our main POP (Miami), we had channelized T-1's and when we moved it and used PRI's the problems disappeared. I am convinced that we must have had some setting wrong, because the performance increase was dramatic and nothing else changed. We found that almost all connection problems dealing with Sportster modems disappeared. We contacted every single customer that reported a connection problem with USR modems, and asked them to call the new access number, and without exception, they connected without a problem (to the same equipment!). We were also able to take care of most of the other customers by helping them upgrade their modems to the latest drivers. Almost all complaints were from LT Winmodems, and their latest code works fine. The performance of the Hiper Arc is great. We are slowly moving more customers to the new POP, and we are getting a lot of positive comments. If this keeps up we will upgrade all our Net Servers to Hiper Arc's win the coming months. The latest trade up program looks very appealing... Thanks, _______________________________________________ Mario M. Bustamante, President AccessPro Communications Inc. Miami, Florida http://www.AccessPro.net mario@accesspro.net _______________________________________________ > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > Mario M. Bustamante > Sent: Tuesday, November 10, 1998 9:34 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) v.90 connect problems > > > I posted a message earlier describing connection problems with > Sportster modems. Up until recently, we assumed that our > customers were complaining because they were using the > cheap V90 > modems, and the problem was on their end. > > As the complaints started to add up, I had out support people > fill out a form to gather information from problem users. The > process included asking the end user to run "winipcfg.exe" on > their Windows 95 or 98 systems and keep a log of good and bad > connections. Since we have mostly Net Server / Quad modem > equipment and only one Hiper ARC / DSP, we wanted to know what > equipment was causing the most problems and with what kind of > modem (on the customer end). > > We have somewhat over 2,200 users, and we have always > recommended > that they buy USR/3Com modems, so we were shocked at the number > of Sportster users having problems (and they were mad at us for > making them spend extra money to buy more problems). > We were also > shocked to find that a lot of them were connecting to BellSouth > with a much better V90 connection (they use Ascend equipment). > > I do not want to post results publicly, but after compiling the > results of almost 200 complaints, I can tell you that > most of the > problems were related to the Hiper ARC / DSP, and that the > percentage of complaints from Sportster users was alarming. > > I would love to get someone that knows Sportsters on a > conference > call with someone that knows Hiper ARCs so we can see where the > problems lie. I know that there are a lot of bad phone > lines and > a lot of people who set up their modems with the wrong > settings, > but somebody has to help us give them tech support. > > Any ideas? > > Thanks, > _______________________________________________ > > Mario M. Bustamante, President > AccessPro Communications Inc. > Miami, Florida > > Internet Service Providers, Web Hosting & Design > Microsoft Certified Web Presence Providers > Wide Area Networks, Security, Intranets. > http://www.AccessPro.net mario@accesspro.net > _______________________________________________ > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > > John Powell > > Sent: Saturday, November 07, 1998 10:15 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) v.90 connect problems > > > > > > >OK, but a fair number of the people having problems > > have Sportsters. > > >(Some Winmodems, some not.) I wasn't aware there was > > any new Sportster > > >code out... if there is, where's it hidden? If > > there isn't, is this one > > >of the server-side problems? > > > > I was responding to your comments on LT Winmodems, you > > did not mention > > Sportsters. I know of no significant issues with > > interop with Sportsters > > (Winmodem or controller based) and Total Control modems. > > > > There will likely be improvements with the client side > > (all vendors) for > > quite some time. There are quite a few tweeks to > > enhance performance and > > coverage in the labs already. Heck, we are still > > improving V.34 4 years > > later. > > > > If you can provide details on problems with > > Sportsters, I will gladly take > > this off-line and put you in contact with my peers on > > the PCD (home of the > > Sportster) side of the house. > > > > JP > > > > PS. No, there are no recent releases of Sportster > > code related to V.90 > > fixes. Overall, they are working quite well. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) PRI settings blown away by NMC
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-11-17 08:21:27
Did you check the AutoResponse settings? I had a similar problem. AutoResponse was responsible. Ralph Chris Hanes wrote: > > Hey Brian, > > Thanks for the reponse. Auto config was disabled. I've tried restoring > NMC from factory default several times to no avail. When I boot the > box, > I've been watching the pri cards chassis slot settings. The pri card > seems > to boot quickly and I'm able to see the settings briefly before they are > wiped out, leaving the pri card seeing only itself in slot 1 and the > netserver > card in slot 16. Any other ideas? > > Thanks, > Chris Hanes > > Brian K McIntire wrote: > > > > Sounds like you have "Auto config upon card initialization" enabled on your > > NMC. > > > > 1. Load TCM > > 2. Bring up your chassis > > 3. Click on the NMC > > 4. Click on Configure/program settings/configuration group > > 5. Make sure auto config is disabled. > > 6. If it was enabled set it and click ok. > > 7. go to configure/action commands and save chassis to nvram (don't really > > need this one but do it anyway) > > 8. Save UI to eeprom > > 9. Reboot > > 10. If the setting was disabled then restore your NMC (not chassis) from > > default by clicking on the NMC and going to configure/action commands and > > choosing restore NMC from default > > 11. then perform steps 7 & 8 and then 9 from above > > This should solve your problem. Remember you will need to reconfigure the > > Logging group on the NMC if you have restored it from default and wish to do > > accounting > > > > ======================================================================== > > = Brian K. McIntire bmcintire@commnet.com = > > = Systems Engineer III 317-558-5050 x113 = > > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > > = Your Remote Access and Security Experts! = > > = = > > = Our experienced technicians can design and install your high speed = > > = network for you. From Operating Systems and servers to routers and = > > = firewalls nobody does it better than CommNetPlus. Our Technical = > > = Support staff is available to you 24 hours a day to meet your needs.= > > = Offering remote management and monitoring packages for dedicated = > > = clients. (Specializing in ISP's). "Let us do the work for you!" = > > = = > > = Firm partnerships est. with current and emerging leaders of today's = > > = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = > > = Serving North America and parts of Canada. Reselling to the world. = > > ======================================================================== > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Two subnets on one HiPerARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-17 09:15:03
>Hello, >I have added a second subnet to an existing hiperARC setup to >the eth:2 port. I would like to have two ip pools one for each >subnet routed out the appropriate port. Easy enough. Create an additional pool on the HiPer ARC and specify that pool name under the user setting in RADIUS for the users you wish to have it. Make the pool private or specify pool names for everyone. >Currently all I have done is configured the second ethernet port >eth:2. I cannot connect to the hiperARC using the new ip address >on eth:2 interface. If I do a traceroute, it finds the eth:1 >interface and continues looking but never finds the new ip address. Some sort for rip announcement is occuring for the gateway to send the request to the eth:1 interface instead of the eth:2 interface. Perhaps what I want is not possible or could be done with filters. Or perhaps the hiperARC will only answer to the "LAN Host address" but will pass data on to modems connected with the new ip subnet properly. In case people are curious, we have a chassis with 11 hiperDSP cards, 2 hiperARCS, and not enough ip addresses on a 24 bit subnet. We could just split the two subnets and have one on each hiperARC but we would like the redundancy of letting one hiperARC take over all the traffic if the other should fail. Ain't life fun. -Laurie - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) NMC rebooting
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-17 09:15:04
You may also want to flip dips 5 & 6 on and reseat before you flash it with PCSDL. It shouldn't make a difference but I have seen it make one over a hundred times -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan Sent: Monday, November 16, 1998 8:14 PM Cc: usr-tc@xmission.com This could be because 1. you have programmed a 0.0.0.0 as ip address of the NMC 2. You have a bad flash Try this. Download 4.3.9 nmc code ( or any 4.x code ) use a program called pcsdl comes with the code ) and download that code to the NMC and then program the proper ip address save it and then upgrade it to 5.x code If this does not help then your flash may be corrupted. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 16 Nov 1998, Brian Elfert wrote: > I picked up a used 1866 bundle. > > The NMC card keeps rebooting. It gets far enough to display the menu on > the console, but it reboots before anything can be entered. > > It appears to be running 5.4.95 on the NMC. > > Any ideas to fix this? > > Brian > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: RE: (usr-tc) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-17 09:17:26
PRI's and T1's are two different animals. Who knows how your T1 was configured. Your Telco could have been padding it. The Receiver gain could have been wrong. The provisioning may have been wrong. Don't believe this is related to some setting your chassis. I've seen this a thousand times on a thousand different AOL chassis. PRI's, by design, are superior to T1's and have significantly less things that could go wrong (assuming your provisioned has any notion of what he is doing) It was probably your T1. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mario M. Bustamante Sent: Tuesday, November 17, 1998 1:51 AM I posted the messages below at a time when we were having an unacceptable number of customer complaints. At present we consider the problems to be resolved. The biggest change came when we removed the Hiper ARC from our network and co located it with a CLEC we are working with. When we had it in our main POP (Miami), we had channelized T-1's and when we moved it and used PRI's the problems disappeared. I am convinced that we must have had some setting wrong, because the performance increase was dramatic and nothing else changed. We found that almost all connection problems dealing with Sportster modems disappeared. We contacted every single customer that reported a connection problem with USR modems, and asked them to call the new access number, and without exception, they connected without a problem (to the same equipment!). We were also able to take care of most of the other customers by helping them upgrade their modems to the latest drivers. Almost all complaints were from LT Winmodems, and their latest code works fine. The performance of the Hiper Arc is great. We are slowly moving more customers to the new POP, and we are getting a lot of positive comments. If this keeps up we will upgrade all our Net Servers to Hiper Arc's win the coming months. The latest trade up program looks very appealing... Thanks, _______________________________________________ Mario M. Bustamante, President AccessPro Communications Inc. Miami, Florida http://www.AccessPro.net mario@accesspro.net _______________________________________________ > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > Mario M. Bustamante > Sent: Tuesday, November 10, 1998 9:34 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) v.90 connect problems > > > I posted a message earlier describing connection problems with > Sportster modems. Up until recently, we assumed that our > customers were complaining because they were using the > cheap V90 > modems, and the problem was on their end. > > As the complaints started to add up, I had out support people > fill out a form to gather information from problem users. The > process included asking the end user to run "winipcfg.exe" on > their Windows 95 or 98 systems and keep a log of good and bad > connections. Since we have mostly Net Server / Quad modem > equipment and only one Hiper ARC / DSP, we wanted to know what > equipment was causing the most problems and with what kind of > modem (on the customer end). > > We have somewhat over 2,200 users, and we have always > recommended > that they buy USR/3Com modems, so we were shocked at the number > of Sportster users having problems (and they were mad at us for > making them spend extra money to buy more problems). > We were also > shocked to find that a lot of them were connecting to BellSouth > with a much better V90 connection (they use Ascend equipment). > > I do not want to post results publicly, but after compiling the > results of almost 200 complaints, I can tell you that > most of the > problems were related to the Hiper ARC / DSP, and that the > percentage of complaints from Sportster users was alarming. > > I would love to get someone that knows Sportsters on a > conference > call with someone that knows Hiper ARCs so we can see where the > problems lie. I know that there are a lot of bad phone > lines and > a lot of people who set up their modems with the wrong > settings, > but somebody has to help us give them tech support. > > Any ideas? > > Thanks, > _______________________________________________ > > Mario M. Bustamante, President > AccessPro Communications Inc. > Miami, Florida > > Internet Service Providers, Web Hosting & Design > Microsoft Certified Web Presence Providers > Wide Area Networks, Security, Intranets. > http://www.AccessPro.net mario@accesspro.net > _______________________________________________ > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of > > John Powell > > Sent: Saturday, November 07, 1998 10:15 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) v.90 connect problems > > > > > > >OK, but a fair number of the people having problems > > have Sportsters. > > >(Some Winmodems, some not.) I wasn't aware there was > > any new Sportster > > >code out... if there is, where's it hidden? If > > there isn't, is this one > > >of the server-side problems? > > > > I was responding to your comments on LT Winmodems, you > > did not mention > > Sportsters. I know of no significant issues with > > interop with Sportsters > > (Winmodem or controller based) and Total Control modems. > > > > There will likely be improvements with the client side > > (all vendors) for > > quite some time. There are quite a few tweeks to > > enhance performance and > > coverage in the labs already. Heck, we are still > > improving V.34 4 years > > later. > > > > If you can provide details on problems with > > Sportsters, I will gladly take > > this off-line and put you in contact with my peers on > > the PCD (home of the > > Sportster) side of the house. > > > > JP > > > > PS. No, there are no recent releases of Sportster > > code related to V.90 > > fixes. Overall, they are working quite well. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) New Features
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-17 09:23:28
Does anyone know if 3COM posts information on features that will be supported in the next full featured release. I'm fairly sure they didn't in the past, but then it didn't matter. I had the inside scoop. Now, where do I go for the answers. I have a lot of customer's with questions. I can answer most of them because I'm already fairly well versed in what will be included in TCS 3.5. I would love to see an "Expected to be released" paper or something. If there is no such thing then my question is, Why not? You don't have to guarantee the release of the feature. Just put a list out there stating what will be included should the feature be completed and tested on time. If the customer's get upset when a feature is delayed that is their problem.
Subject: Re: (usr-tc) NMC rebooting
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-17 09:25:44
On Mon, 16 Nov 1998, Tatai SV Krishnan wrote: > Download 4.3.9 nmc code ( or any 4.x code ) use a program called pcsdl ( > comes with the code ) and download that code to the NMC and then program > the proper ip address save it and then upgrade it to 5.x code How exactly can I load the code if the thing never boots up fully? Brian
Subject: (usr-tc) MultiLink PPP and ISDN
From: Taino d Johnston <usr-list@accesscom.com>
Date: 1998-11-17 09:41:30
A few quick questions: What needs to be done to enable MultiLink PPP and dual channel ISDN? Does 'set mp on' do it and that is it? Will there be any problems if one call comes say into chassis #1 and the second call comes into chassis #2? We are running a three TC chassis containing Quad Digital & Digital/Analog modem cards with PRI lines. All our Quad modem cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the current versions of the software. Taino Johnston Manager, Technical Support Access Internet Communications +----------------------------------------------------------------+ | Taino d Johnston | Phone: (408) 777-8190 | | Manager, Technical Support | Tech Support: (408) 342-0551 | | | Fax: (408) 777-8191 | | Access Internet Communications | http://www.accesscom.com/ | | tdj@accesscom.com | support@accesscom.com | +----------------------------------------------------------------+
Subject: RE: (usr-tc) NMC rebooting
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-17 09:52:07
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Elfert |Sent: Tuesday, November 17, 1998 9:26 AM |To: Tatai SV Krishnan |Cc: usr-tc@xmission.com |Subject: Re: (usr-tc) NMC rebooting | | | | |On Mon, 16 Nov 1998, Tatai SV Krishnan wrote: | |> Download 4.3.9 nmc code ( or any 4.x code ) use a program called pcsdl ( |> comes with the code ) and download that code to the NMC and then program |> the proper ip address save it and then upgrade it to 5.x code | |How exactly can I load the code if the thing never boots up fully? | PCSDL.
Subject: RE: (usr-tc) accounting problem through NMC
From: allen_lai@3com.com
Date: 1998-11-17 09:58:23
Brian Thanks for your response. Fro your questions,the answer is yes! I'm sure the NT server IP address is in the logging server list. My question is why the S/A in NT server lost their clients. Allen "Brian K McIntire" <bmcintire@commnet.com> on 11/17/98 06:21:01 AM Please respond to usr-tc@lists.xmission.com cc: (Allen Lai/CN/3Com) Note: Some recipients have been dropped due to syntax errors. Please refer to the "$AdditionalHeaders" item for the complete headers. Hello,all We have installed a USR S/A server in a NT workstation(Intel pro233) to collect the accounting informaiton from NMC. We created about 60 NMC/chassis---raduis accounting client in one S/A server. At first, everything works OK.We got accounting information from all created clients. But gradually, some clients will disappered. ********* What do you mean by this? Have you used TCM to open the NMC Logging Group info and make sure you see the Primary Logging Server listed? We can't got any accounting information of these disappered client now from S/A now. When ping the NMC, it's ok.We can also managned these chassis through TCM. Any hints? 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. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) NMC rebooting
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-17 09:59:42
That is where you use pcsdl - This program will run on a pc and as soon as you start will force the download of the code to the card. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 17 Nov 1998, Brian Elfert wrote: > > > On Mon, 16 Nov 1998, Tatai SV Krishnan wrote: > > > Download 4.3.9 nmc code ( or any 4.x code ) use a program called pcsdl ( > > comes with the code ) and download that code to the NMC and then program > > the proper ip address save it and then upgrade it to 5.x code > > How exactly can I load the code if the thing never boots up fully? > > Brian >
Subject: Re: (usr-tc) ARC reboot
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-17 10:00:55
Open a ticket and send the crash dump ( sho board crash ) to a tech. They can analyze the crash and tell you what the problem is. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 17 Nov 1998, Marcelo Souza wrote: > > Yesterday I had a very curious problem. > I discovered that some ports om my TCS had no filter set up, so I > used the command: > > set interface slot:1/mod:[1-30] input_filter dial.in > > And I could see that some modems had a wrong value in the input > filter field: @mailbo (don't ask me why) > Then I send the commend again, and send it two times for each > slot, when I was configuring the last slot (#6) the TC hang and rebooted. > > I'm using HARC 4.0.29. > > Have any one seem some thing like this? > > - 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. >
Subject: Re: (usr-tc) MultiLink PPP and ISDN
From: Taino d Johnston <usr-list@accesscom.com>
Date: 1998-11-17 10:07:06
You say I need to enable a MPIP server and configure MPIP functionality on all your NETServers. What exactly does that mean? Is a MPIP server something extra that needs to be purchased? What configuration needs to be done on the NETServers? Taino Johnston Manager, Technical Support Access Internet Communications >Thus spake Taino d Johnston >>What needs to be done to enable MultiLink PPP and dual channel ISDN? Does >>'set mp on' do it and that is it? Will there be any problems if one call >>comes say into chassis #1 and the second call comes into chassis #2? > >You need to enable an MPIP server and configure MPIP functionality on >all your NETServers. MPIP is the protocol that controls cross-platform >channel bundling like you're wanting to do. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. +----------------------------------------------------------------+ | Taino d Johnston | Phone: (408) 777-8190 | | Manager, Technical Support | Tech Support: (408) 342-0551 | | | Fax: (408) 777-8191 | | Access Internet Communications | http://www.accesscom.com/ | | tdj@accesscom.com | support@accesscom.com | +----------------------------------------------------------------+
Subject: Re: (usr-tc) PRI settings blown away by NMC
From: Chris Hanes <chris@internetcreations.com>
Date: 1998-11-17 11:27:14
I'm still having no luck preventing the NMC card from blowing away my PRI slot device configuration. Autoconfig on the NMC is disabled and I'm configuring the PRI from the console. Any further suggestions? Thanks, Chris Chris Hanes wrote: > > Hey all, > > I'm trying to map modems to slots under chassis slot device > configuration on a dual pri nac. The settings take so long > as my NMC is not plugged in. Once plugged in the NMC obscures these > settings and prevents me from reentering the settings on the pri card > (i.e. the settings won't take when the NMC is plugged in). I've been > through a couple pri cards and figure I must be doing something stupid. > I'm running tcs 3.3 (3.02 on the PRI nac and 5.5.5 on the NMC) > Any help would be IMMENSELY appreciated. > > Thanks, > Chris Hanes > Internet Creations
Subject: (usr-tc) odd ping response
From: Casey Cook <caseyc@gate.net>
Date: 1998-11-17 11:43:19
We use a ping monitor program to check that interfaces are alive, and have been seeing one Netserver keep going up and down in the monitor. We can reach it via telnet, but when we ping it we see the following- (caseyc@inca):/etc/raddb>ping tsbrn2 PING tsbrn2.gate.net: (207.36.0.99): 56 data bytes 64 bytes from 207.36.0.99: icmp_seq=1 ttl=244 time=65 ms 64 bytes from 207.36.0.99: icmp_seq=2 ttl=244 time=79 ms 64 bytes from 207.36.0.99: icmp_seq=3 ttl=244 time=72 ms 64 bytes from 207.36.0.99: icmp_seq=4 ttl=244 time=1955 ms wrong data byte #24 should be 0x18 but was 0x4a 36 51 a6 76 0 b 7e 4 8 9 a b c d e f 10 11 12 13 14 15 16 17 4a 45 1a 1b 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 64 bytes from 207.36.0.99: icmp_seq=6 ttl=244 time=68 ms 64 bytes from 207.36.0.99: icmp_seq=7 ttl=244 time=77 ms 64 bytes from 207.36.0.99: icmp_seq=8 ttl=244 time=81 ms 64 bytes from 207.36.0.99: icmp_seq=10 ttl=244 time=79 ms wrong data byte #24 should be 0x18 but was 0x30 36 51 a6 7c 0 b 8d 38 8 9 a b c d e f 10 11 12 13 14 15 16 17 30 30 31 3 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 64 bytes from 207.36.0.99: icmp_seq=13 ttl=244 time=73 ms wrong data byte #42 should be 0x2a but was 0x41 36 51 a6 7f 0 b 98 f5 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1 20 21 22 23 24 25 26 27 28 29 41 43 2c 2d 2e 2f 64 bytes from 207.36.0.99: icmp_seq=14 ttl=244 time=65 ms 64 bytes from 207.36.0.99: icmp_seq=6 ttl=243 time=8645 ms (DUP!) 64 bytes from 207.36.0.99: icmp_seq=16 ttl=244 time=69 ms 64 bytes from 207.36.0.99: icmp_seq=8 ttl=243 time=9067 ms (DUP!) 64 bytes from 207.36.0.99: icmp_seq=18 ttl=244 time=146 ms wrong data byte #26 should be 0x1a but was 0xb3 36 51 a6 84 0 b a7 96 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 b3 c 20 21 22 23 0 0 0 0 0 0 0 0 0 0 2e 2f 64 bytes from 207.36.0.99: icmp_seq=19 ttl=244 time=55 ms ^C ----tsbrn2.gate.net PING Statistics---- 21 packets transmitted, 13 packets received, +2 duplicates, 38% packet loss round-trip min/avg/max = 55/1373/9067 ms
Subject: (usr-tc) Stuck in ringRcvd
From: Brian <signal@shreve.net>
Date: 1998-11-17 11:46:36
We had a modem that when people dialed our number, it would just be dead silence. I narrowed it down to a card, and did a Program Settings on it, and saw that the operational status for one of the modems was stuck in ringRcvd. I tried to software reset this modem, and it stayed in ringRcvd. The only fix was to hardware reset the card. This happens quite a bit. Has anyone else seen this? I am running Release hdm/arc code (1.2.5/4.1.11). What is the cause? The fix? brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) NMC rebooting
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-17 12:11:58
FYI, Actually, what happens is as the NMC boots up it will initialize hardware (factory settings on a chip) and then software. Your card is probably rebooting because of a software problem. Before it initializes completely, runs into problems, and begins rebooting (NMC's usually only reboot when the final initialization failed) it will be in a state (thanks to the factory chip) where it will respond to PCSDL and take a software download. Your PCSDL program will continue attempting communication until the NMC boots up to the point where the factory chip has told it how to respond to PCSDL. Therefore, this works whether you have software on your NMC or not. For those of you that have tried to access the console while your NMC is doing something like this you were not able to because the NMC needs to be past the point of initializing the software in order to respond to commands on the console. >That is where you use pcsdl - This program will run on a pc and as soon >as you start will force the download of the code to the card. > >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html >-------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec >-------------------------------------------------------------------------/ On Tue, 17 Nov 1998, Brian Elfert wrote: > > > On Mon, 16 Nov 1998, Tatai SV Krishnan wrote: > > > Download 4.3.9 nmc code ( or any 4.x code ) use a program called pcsdl > > comes with the code ) and download that code to the NMC and then program > > the proper ip address save it and then upgrade it to 5.x code > > How exactly can I load the code if the thing never boots up fully? > > 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.
Subject: Re: (usr-tc) Stuck in ringRcvd
From: sagarwal@crash.ae.usr.com
Date: 1998-11-17 12:37:09
What does "List Interfaces " command on Hiper ARC show. Does it show that the int is down in oper status? Sanjay On Tue, 17 Nov 1998, Brian wrote: > We had a modem that when people dialed our number, it would just be dead > silence. I narrowed it down to a card, and did a Program Settings on it, > and saw that the operational status for one of the modems was stuck in > ringRcvd. I tried to software reset this modem, and it stayed in > ringRcvd. The only fix was to hardware reset the card. > > This happens quite a bit. > > Has anyone else seen this? I am running Release hdm/arc code > (1.2.5/4.1.11). > > What is the cause? The fix? > > brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Stuck in ringRcvd
From: sagarwal@crash.ae.usr.com
Date: 1998-11-17 12:37:09
What does "List Interfaces " command on Hiper ARC show. Does it show that the int is down in oper status? Sanjay On Tue, 17 Nov 1998, Brian wrote: > We had a modem that when people dialed our number, it would just be dead > silence. I narrowed it down to a card, and did a Program Settings on it, > and saw that the operational status for one of the modems was stuck in > ringRcvd. I tried to software reset this modem, and it stayed in > ringRcvd. The only fix was to hardware reset the card. > > This happens quite a bit. > > Has anyone else seen this? I am running Release hdm/arc code > (1.2.5/4.1.11). > > What is the cause? The fix? > > brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Stuck in ringRcvd
From: Brian <signal@shreve.net>
Date: 1998-11-17 12:38:32
On Tue, 17 Nov 1998 sagarwal@crash.ae.usr.com wrote: > > What does "List Interfaces " command on Hiper ARC show. Does it show that > the int is down in oper status? > > Sanjay I have already reset the card. In the past usually the first thing I check for when we get fast busies or problems from the modems is a list int. I do not recall ever seeing the interface down when this condition arises, usually it is up. Brian > > > On Tue, 17 Nov 1998, Brian wrote: > > > We had a modem that when people dialed our number, it would just be dead > > silence. I narrowed it down to a card, and did a Program Settings on it, > > and saw that the operational status for one of the modems was stuck in > > ringRcvd. I tried to software reset this modem, and it stayed in > > ringRcvd. The only fix was to hardware reset the card. > > > > This happens quite a bit. > > > > Has anyone else seen this? I am running Release hdm/arc code > > (1.2.5/4.1.11). > > > > What is the cause? The fix? > > > > brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) Stuck in ringRcvd
From: Brian <signal@shreve.net>
Date: 1998-11-17 12:38:32
On Tue, 17 Nov 1998 sagarwal@crash.ae.usr.com wrote: > > What does "List Interfaces " command on Hiper ARC show. Does it show that > the int is down in oper status? > > Sanjay I have already reset the card. In the past usually the first thing I check for when we get fast busies or problems from the modems is a list int. I do not recall ever seeing the interface down when this condition arises, usually it is up. Brian > > > On Tue, 17 Nov 1998, Brian wrote: > > > We had a modem that when people dialed our number, it would just be dead > > silence. I narrowed it down to a card, and did a Program Settings on it, > > and saw that the operational status for one of the modems was stuck in > > ringRcvd. I tried to software reset this modem, and it stayed in > > ringRcvd. The only fix was to hardware reset the card. > > > > This happens quite a bit. > > > > Has anyone else seen this? I am running Release hdm/arc code > > (1.2.5/4.1.11). > > > > What is the cause? The fix? > > > > brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) MultiLink PPP and ISDN
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-17 12:54:06
Thus spake Taino d Johnston >What needs to be done to enable MultiLink PPP and dual channel ISDN? Does >'set mp on' do it and that is it? Will there be any problems if one call >comes say into chassis #1 and the second call comes into chassis #2? You need to enable an MPIP server and configure MPIP functionality on all your NETServers. MPIP is the protocol that controls cross-platform channel bundling like you're wanting to do. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) MultiLink PPP and ISDN
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-17 13:13:29
Thus spake Taino d Johnston >You say I need to enable a MPIP server and configure MPIP functionality on >all your NETServers. What exactly does that mean? Is a MPIP server >something extra that needs to be purchased? What configuration needs to be >done on the NETServers? MPIP is built into the NETServers, you should be able to check out the documentation to find the commands to enable it. One NETServer will need to be designated as an MPIP server and requires some special configuration. It should all be in the docs...unfortunately, I don't have the information in front of me at the moment. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Double Pings ans Slow Downloads
From: Carl Jagerski <carll@forcomm.net>
Date: 1998-11-17 13:15:11
Hello Everyone, I currently have pop sites setup with both T.C. HiperDSPs and regular analog lines to 33,600 modems. These problems are at all pop sites. When you dial into the analog lines, download speeds range from 1 to 3kbsp But, when you dial into the TC boxes, download speeds start at around 1 and slowly drop to almost nothing. This is very consistent and well test by us with different modems (ie. 33,600, X2, V.90 on a few different brands). We also noticed that the pings are different through the digital than the analog. This is a typical ping through the analog modems: PING coos.dartmouth.edu (129.170.16.50): 56 data bytes 64 bytes from 129.170.16.50: icmp_seq=0 ttl=235 time=463.6 ms 64 bytes from 129.170.16.50: icmp_seq=1 ttl=235 time=310.8 ms 64 bytes from 129.170.16.50: icmp_seq=2 ttl=235 time=600.8 ms 64 bytes from 129.170.16.50: icmp_seq=3 ttl=235 time=370.7 ms This is the same ping dialed into the TC Boxes from the same modem: PING coos.dartmouth.edu (129.170.16.50): 56 data bytes 64 bytes from 129.170.16.50: icmp_seq=0 ttl=235 time=196.9 ms 64 bytes from 129.170.16.50: icmp_seq=0 ttl=234 time=206.1 ms (DUP!) 64 bytes from 129.170.16.50: icmp_seq=1 ttl=235 time=310.8 ms 64 bytes from 129.170.16.50: icmp_seq=1 ttl=234 time=320.0 ms (DUP!) 64 bytes from 129.170.16.50: icmp_seq=2 ttl=235 time=250.8 ms 64 bytes from 129.170.16.50: icmp_seq=2 ttl=234 time=262.7 ms (DUP!) 64 bytes from 129.170.16.50: icmp_seq=3 ttl=235 time=190.9 ms 64 bytes from 129.170.16.50: icmp_seq=3 ttl=234 time=200.0 ms (DUP!) What is causing the double pings? Could this be related to the slowing of the download? We are totally confused here. Any ideas would help at this point. 3COM has already been through our boxes and said the setting all looked good to them. (but what do they know?) Carl Jagerski Network Administrator, Forward Communications carll@forcomm.net 412-378-4490 Fax: 412-375-0156
Subject: Re: (usr-tc) MultiLink PPP and ISDN
From: Jason W <jwatkins@iland.net>
Date: 1998-11-17 13:19:07
Below I have pasted an email that a 3com support tech sent me on how to properly configure MPIP on Netserver cards. You can also find this information on the release notes for Netserver version 3.4 Hope this helps. Solution ID: 112.0.3158865.1615069 Type: published-Public Status: Stds & tech reviews complete Shared: Yes Title: How to set up MPIP on a Total Control NETServer PRI Goal: How to set up MPIP on a Total Control NETServer PRI Facts: Total Control NETServer PRI Total Control Dual PRI MPIP Unix Control Server MPIP Symptoms: Problems with setting up MPIP Cannot do MPIP with 2 Total Control NETServer PRI's Setting up MPIP with a Unix control server Fixes: How to set up MPIP with 2 Total Control NETServer PRI, and a MPIP Control Server MPIP - Multilink PPP Interspan Protocol (MPIP) 1) Configure both Total Control NETServer PRI 1 and Total Control Netserver PRI 2 for use with MPIP Control Server 1 by entering the following command at both netserver's: set mpipserver 1.1.1.1/1030 mpipsecret 2) Add both Total Control NETServer PRI 1 and Total Control NETServer PRI 2 as clients of MPIP Control Server 1 by entering the commands below at the Total Control NETServer PRI 1:add mpipclient 1.1.1.1 mpipsecret ------------> adds the Total Control NETServer 1 as its own client add mpipclient 1.1.1.2 mpipsecret -------------> add the Total Control NETServer 2 as a client 3)Set the NTP time server across the network by entering the following command at the MPIP Control Server's command prompt: set time 1.1.1.3 Then you can reset the time by entering this command: reset time 4) Turn the MPIP Control Server on, at the command prompt of the Total Control NETServer PRI 1, by entering the following command: set mpipserver on MPIP is now up and running with the Total Control NETServer PRI 1 serving as the MPIP Control Server and both NETServer 1 and NETServer 2 acting as clients. Setting the Total Control NETServer PRI as a MPIP server: 1) Setup the chosen Total Control NETServer PRI as the MPIP server and configure the MPIP clients. The ip addresses do the work here. 2) The chosen MPIP server has to be its own client, Hence, the MPIP client list on the MPIP server will also include its own ip address. 3) Synchronize the clocks on the server and the clients by pointing them to one NTP time server (and not 2 time servers). 4) The times on the 2 Total Control NETServer PRI's can be synchronized by either rebooting them at the same time, or by doing reset time. 5) Once the environment is figured out, then make sure that you can test each NETServer for mlppp connections. 6) Once step 5 is preformed, then start up your DUN (dial-up networking) and upon configuring the basic parameters, the number dialing process should be followed as below. a. if the numbers are different, then dial 8475882300&8475882301 b. if there is only one number, then dial that number after making sure that one channel will land on one chassis and the next will land on the other chassis. 7) Follow the above steps 2,3,&4 on the command syntax for setting up MPIP server and client. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins jwatkins@iland.net I-Land NOC Tech http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- :Thus spake Taino d Johnston :>You say I need to enable a MPIP server and configure MPIP functionality on :>all your NETServers. What exactly does that mean? Is a MPIP server :>something extra that needs to be purchased? What configuration needs to be :>done on the NETServers? : :MPIP is built into the NETServers, you should be able to check out the :documentation to find the commands to enable it. One NETServer will :need to be designated as an MPIP server and requires some special :configuration. It should all be in the docs...unfortunately, I don't :have the information in front of me at the moment. :-- :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) ARC reboot
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-11-17 13:24:18
Yesterday I had a very curious problem. I discovered that some ports om my TCS had no filter set up, so I used the command: set interface slot:1/mod:[1-30] input_filter dial.in And I could see that some modems had a wrong value in the input filter field: @mailbo (don't ask me why) Then I send the commend again, and send it two times for each slot, when I was configuring the last slot (#6) the TC hang and rebooted. I'm using HARC 4.0.29. Have any one seem some thing like this? - Marcelo
Subject: (usr-tc) New Hiper ARC service release
From: sagarwal@crash.ae.usr.com
Date: 1998-11-17 13:50:42
All, Check out a new Hiper ARC service release code version 4.1.72 at http://totalservice.usr.com Thanks Sanjay Agarwal
Subject: RE: (usr-tc) odd ping response
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-11-17 14:39:06
On Tuesday, November 17, 1998 12:43 PM, Casey Cook [SMTP:caseyc@gate.net] wrote: > 20 21 22 23 0 0 0 0 0 0 0 0 0 0 2e 2f > 64 bytes from 207.36.0.99: icmp_seq=19 ttl=244 time=55 ms > > > Any thoughts on those 'wrong data byte' lines? > I've never seen this with a TC box but I have seen it on an NT box. It turned out to be a bad PCI bus. My guess is that you have a bad card or something else... Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 A quart of wheat for a day's wages, and three quarts of barley for a day's wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject: RE: (usr-tc) New Hiper ARC service release
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-17 15:20:36
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews |Sent: Tuesday, November 17, 1998 2:52 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) New Hiper ARC service release | | |Is there a list of what's changed between 4.1.78 and 4.1.72? | All changes are noted in the PDF's on totalservice. The list shows the delta from 4.1.11 All fixes in 4.1.78 are in there. -M
Subject: RE: (usr-tc) v.90 connect problems
From: David Bolen <db3l@ans.net>
Date: 1998-11-17 15:30:13
"Brian K McIntire" <bmcintire@commnet.com> writes: > is related to some setting your chassis. I've seen this a thousand times on > a thousand different AOL chassis. Just for a minor counterpoint, on most of our chassis using channelized T1 spans, we don't really see all that much of a difference. In fact, since telcos often rob bits even within short call distances, the fact that the channelized T1 implies a robbed bit doesn't necessarily hurt all that much - often the PRIs don't even bring an advantage to the 56K protocols like x2 or V.90. (For example, calling to a local T1 in my office gets me the same connections as calling a PRI located only about 10 miles west of me, and both connected to the same telco). Of course, it is important how you configure your T1s - specifically the signaling. If you opt for ground or loop start (we've only ever used ground), you're much more likely to have issues and I'm more likely to agree with your point, but not because of the digital T1 span itself. It's because in virtually all cases, the telco is going to provision that at the concentrator end with a series of analog copper pair circuits feeding from their switch into a channel bank that handles the T1 framing. In such a configuration you really have an extra analog hop, individual pairs that can go bad, etc, and what you're hurt by is the central office configuration. But an E&M configuration is almost always the opposite - digital straight into the switch - and in my experience behaves just as nicely as a PRI circuit and very closely even to the call rates achieved. > PRI's, by design, are superior to T1's Pedantic point - unless you are at an international site using E1s, a "PRI" _is_ a "T1" fundamentally. Same framing. It's the signaling that is different, so you need to qualify the T1 as, for example, channelized with E&M signaling. > and have significantly less things that could go wrong (assuming your > provisioned has any notion of what he is doing) It was probably your T1. Heh - try to tell that to someone trying to troubleshoot D channel signaling or getting the non-standard "service message" support to work everywhere. PRIs aren't automatically better in all circumstances ;-) Don't get me wrong - I love PRIs as much as the next guy, and we're certainly using them as the standard configuration for all new equipment, but it wasn't all that long ago when they were too expensive in various regions and we still have a whole lot of channelized T1 (far preferring E&M but we've still got the occasional ground start - economic reasons again) working in the network, and in general behaving just as nicely as the PRI circuits. So I wouldn't automatically assume that a channelized T1 configuration has to be inferior. It can be configured wrong (but so can a PRI) and it can have different types of failures than a PRI, but it can also work just as well. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) New Hiper ARC service release
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-17 15:52:22
Is there a list of what's changed between 4.1.78 and 4.1.72? Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Tue, 17 Nov 1998 sagarwal@crash.ae.usr.com wrote: > All, > > Check out a new Hiper ARC service release code version 4.1.72 at > > http://totalservice.usr.com > > Thanks > > Sanjay Agarwal
Subject: RE: (usr-tc) New Hiper ARC service release
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-17 16:22:53
Duh, sorry... hand me the big pointy dunce hat for today. Thanks... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Tue, 17 Nov 1998, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews > |Sent: Tuesday, November 17, 1998 2:52 PM > |To: usr-tc@lists.xmission.com > |Subject: Re: (usr-tc) New Hiper ARC service release > | > | > |Is there a list of what's changed between 4.1.78 and 4.1.72? > | > > All changes are noted in the PDF's on totalservice. The list shows the delta from > 4.1.11 > All fixes in 4.1.78 are in there. > > -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: (usr-tc) RADIUS 6.0.8: Authentication into NT Domain creates errors
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-11-17 18:52:54
Hi all I try to setup 3COM RADIUS Server to authenticate all users, wich are not found in the RADIUS database, in the NT Domain. For that reason I'm working with the template NTUSER. The problem I encounter: There are script errors in the logfile. Has anyone done something similar? RADIUS 6.0.8 Script Section: CHECK-PASSWORD nLine: 534 bIgnore: 0 Script Section: VALIDATE-LOCALPASSWD nLine: 3345 bIgnore: 0 Trace: Attempting User: Tinu-H, Domain: LEO-DOMAIN [11 17 18:44:40] Script Section: CHECK-EXPIRATION nLine: 535 bIgnore: 0 Script Section: CHECK-CALL-SOURCE nLine: 542 bIgnore: 0 Script Section: CHECK-TUNNEL-NAME nLine: 547 bIgnore: 0 Script error on line 1781 :Variable (THISGROUP) not found Line is : if(length(thisGroup)>0) Script error on line 1781 :Parameter has a bad value Line is : if(length(thisGroup)>0) Script Section: COLLECT-USER-RESPONSE nLine: 549 bIgnore: 0 Script Section: GET-STANDARD-ATTRIBUTES nLine: 671 bIgnore: 0 Script Section: GET-USER-SERVICE-TYPE nLine: 7257 bIgnore: 0 Script Section: GET-STANDARD-FRAMED-ATTRIBUTES nLine: 7276 bIgnore: 0 Script Section: GET-FRAMED-PROTOCOL nLine: 7319 bIgnore: 0 Script error on line 2696 :Variable (THISGROUP) not found Line is : if(length(thisGroup)>0) Script error on line 2696 :Parameter has a bad value Line is : if(length(thisGroup)>0) Script Section: GET-FRAMED-ADDRESS nLine: 7320 bIgnore: 0 Script error on line 2753 :Variable (THISGROUP) not found Line is : if(length(thisGroup)>0) Script error on line 2753 :Parameter has a bad value Line is : if(length(thisGroup)>0) Script error on line 2769 :Variable (THISGROUP) not found Line is : if(length(thisGroup)>0) Script error on line 2769 :Parameter has a bad value Line is : if(length(thisGroup)>0) Script Section: GET-FRAMED-NETMASK nLine: 7321 bIgnore: 0 Script error on line 2785 :Variable (THISGROUP) not found Line is : if(length(thisGroup)>0) and so on....
Subject: Re: (usr-tc) New Hiper ARC service release
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-17 19:11:35
sagarwal@crash.ae.usr.com was heard to say: >Check out a new Hiper ARC service release code version 4.1.72 at > >http://totalservice.usr.com I love the version number... ne041727.zip :-) I also like the way I don't need a service contract to grab it (or do I?) --Ricky
Subject: (usr-tc) Will Trade ISP Billing Software for Dual T1 PRI card, etc.
From: Dwight G. Jones <djones@imagen.net>
Date: 1998-11-17 19:21:44
We are developers of strong ISP billing software, and we need 2 Dual T1 PRI cards as well as V.90 code for some used USR-TC racks that we use to keep in touch with the family.. :^D djones@imagen.net www.imagen.net
Subject: (usr-tc) rear chassis fan, nmc hub status critical
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-11-17 19:33:17
I just noticed the small fan at the rear of my chassis stopped spinning. Does anyone know if these are standard sized fans that can be readily found, or if replacement of it requires a custom (costly) part swap from 3com.. pointers appreciated. -L.
Subject: Re: (usr-tc) ARC reboot
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-11-17 19:42:33
On Tue, 17 Nov 1998, Tatai SV Krishnan wrote: |Open a ticket and send the crash dump ( sho board crash ) to a tech. |They can analyze the crash and tell you what the problem is. I don't have a support contract with 3com. - Marcelo | |krish | |----------------------------------------- | \ T.S.V. Krishnan \ | \ Network System Engineer \ ( : - : ) | \ 3Com ............ \ | ----------------------------------------------/ |tkrishna@bubba.ae.usr.com |----------------------------/ http://interproc.ae.usr.com ----/ |The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html |-------------------------------------------------------------------------\ | Any Sufficiently advanced bug is indistinguishable for a feature. | - Rick Kulawiec |-------------------------------------------------------------------------/ | |On Tue, 17 Nov 1998, Marcelo Souza wrote: | |> |> Yesterday I had a very curious problem. |> I discovered that some ports om my TCS had no filter set up, so I |> used the command: |> |> set interface slot:1/mod:[1-30] input_filter dial.in |> |> And I could see that some modems had a wrong value in the input |> filter field: @mailbo (don't ask me why) |> Then I send the commend again, and send it two times for each |> slot, when I was configuring the last slot (#6) the TC hang and rebooted. |> |> I'm using HARC 4.0.29. |> |> Have any one seem some thing like this? |> |> - 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. |> | - Marcelo
Subject: (usr-tc) ppp start message
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-11-17 20:45:44
Is there a toggle to have the ppp start message display on the hiperarc? 'show ppp' lists the following, running on 4.1.11 and 4.1.72 DIAL_IN Users Authenticate: ANY PPP Authentication Preference: PAP PPP session start message: PPP session from %server_ip to %client beginning... but when i log in manually with a terminal over dialup and log in for ppp, it doesnt display it at all. also, does this default start message match the netserver one.. i'd like to keep it the same. -L
Subject: Re: (usr-tc) ppp start message
From: Carl Litt <carl@snel.execulink.com>
Date: 1998-11-17 20:52:37
enable authen hint_assigned On Tue, 17 Nov 1998, Laszlo Vecsey wrote: > Is there a toggle to have the ppp start message display on the hiperarc? > 'show ppp' lists the following, running on 4.1.11 and 4.1.72 > > DIAL_IN Users Authenticate: ANY > PPP Authentication Preference: PAP > > PPP session start message: PPP session from %server_ip to %client beginning... > > but when i log in manually with a terminal over dialup and log in for ppp, > it doesnt display it at all. also, does this default start message match > the netserver one.. i'd like to keep it the same. > > -L > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) upgrade for Netserver card available?
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-17 21:19:43
I have a Netserver Card hardware version 4.0.0 running software 3.3.3. Is it possible to upgrade the software? It tries to load le*.nac software and 3.3.3 is the latest 3Com has on their site. It has a really annoying habit of dropping all the connections and not telling my radius server. Thanks, Ted
Subject: Re: (usr-tc) Stuck in ringRcvd
From: Brian <signal@shreve.net>
Date: 1998-11-17 22:26:50
On Tue, 17 Nov 1998 sagarwal@crash.ae.usr.com wrote: > > What does "List Interfaces " command on Hiper ARC show. Does it show that > the int is down in oper status? > It shows its "UP UP" I just had this happen again........... > Sanjay > > > On Tue, 17 Nov 1998, Brian wrote: > > > We had a modem that when people dialed our number, it would just be dead > > silence. I narrowed it down to a card, and did a Program Settings on it, > > and saw that the operational status for one of the modems was stuck in > > ringRcvd. I tried to software reset this modem, and it stayed in > > ringRcvd. The only fix was to hardware reset the card. > > > > This happens quite a bit. > > > > Has anyone else seen this? I am running Release hdm/arc code > > (1.2.5/4.1.11). > > > > What is the cause? The fix? > > > > brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) Stuck in ringRcvd
From: Brian <signal@shreve.net>
Date: 1998-11-17 22:26:50
On Tue, 17 Nov 1998 sagarwal@crash.ae.usr.com wrote: > > What does "List Interfaces " command on Hiper ARC show. Does it show that > the int is down in oper status? > It shows its "UP UP" I just had this happen again........... > Sanjay > > > On Tue, 17 Nov 1998, Brian wrote: > > > We had a modem that when people dialed our number, it would just be dead > > silence. I narrowed it down to a card, and did a Program Settings on it, > > and saw that the operational status for one of the modems was stuck in > > ringRcvd. I tried to software reset this modem, and it stayed in > > ringRcvd. The only fix was to hardware reset the card. > > > > This happens quite a bit. > > > > Has anyone else seen this? I am running Release hdm/arc code > > (1.2.5/4.1.11). > > > > What is the cause? The fix? > > > > brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) Stuck in ringRcvd
From: Charles Sprickman <spork@inch.com>
Date: 1998-11-18 00:09:48
On Tue, 17 Nov 1998, Brian wrote: > > What does "List Interfaces " command on Hiper ARC show. Does it show that > > the int is down in oper status? > > It shows its "UP UP" In a similar vein... Besides 'list int' and 'list con', what else can give me more info on how hosed a port may be? 'show all' on the netserver is handy for finding renegade modems, what's the closest equivalent in HARC-land? Thanks, Charles > > I just had this happen again........... > > > > Sanjay > > > > > > On Tue, 17 Nov 1998, Brian wrote: > > > > > We had a modem that when people dialed our number, it would just be dead > > > silence. I narrowed it down to a card, and did a Program Settings on it, > > > and saw that the operational status for one of the modems was stuck in > > > ringRcvd. I tried to software reset this modem, and it stayed in > > > ringRcvd. The only fix was to hardware reset the card. > > > > > > This happens quite a bit. > > > > > > Has anyone else seen this? I am running Release hdm/arc code > > > (1.2.5/4.1.11). > > > > > > What is the cause? The fix? > > > > > > brian > > > > > > > > > -------------------------------------------------------------------------- > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
Subject: Re: (usr-tc) Stuck in ringRcvd
From: Richard Lorbieski <richard@alpha1.net>
Date: 1998-11-18 02:48:42
If you have syslog enabled, does it say something like this? Nov 13 14:14:47 bry409 At 14:13:50, Facility "GWC Modem Driver", Level "CRITICAL":: GWCMDMDRV FSM illegal event interface slot:2/mod:18, state Disconnecting, event CallArrivedReq Charles Sprickman wrote: > > On Tue, 17 Nov 1998, Brian wrote: > > > > What does "List Interfaces " command on Hiper ARC show. Does it show that > > > the int is down in oper status? > > > > It shows its "UP UP" > > In a similar vein... >
Subject: Re: (usr-tc) New Hiper ARC service release
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 08:01:24
Thus spake Russ Miescke >Is this a newer code than the ER 4.1.78? Does 4.1.78 contain all of the >fixes from 4.1.72? I guess I am hesitant to change something that is sort >of working. Anybody load this yet? Nope, just the opposite, 4.1.72 has all the fixes from 4.1.78. ER code is number from 99 down, so 72 is newer than 78. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) New Hiper ARC service release
From: sagarwal@crash.ae.usr.com
Date: 1998-11-18 09:03:43
4.1.72 is newer code than 4.1.78. It has all the fixes from 4.1.78 and some additional fixes. Thanks Sanjay On Thu, 19 Nov 1998, Russ Miescke wrote: > Is this a newer code than the ER 4.1.78? Does 4.1.78 contain all of the > fixes from 4.1.72? I guess I am hesitant to change something that is sort > of working. Anybody load this yet? > > > Russ Miescke > Power Web Connect > russm@powerweb.net > http://www.powerweb.net > > ----- Original Message ----- > From: Ricky Beam <jfbeam@Interpath.net> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, November 17, 1998 6:11 PM > Subject: Re: (usr-tc) New Hiper ARC service release > > > sagarwal@crash.ae.usr.com was heard to say: > >Check out a new Hiper ARC service release code version 4.1.72 at > > > >http://totalservice.usr.com > > I love the version number... ne041727.zip :-) I also like the way I don't > need a service contract to grab it (or do I?) > > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) New Hiper ARC service release
From: Dale Hege <fhege@sover.net>
Date: 1998-11-18 10:50:31
How is the ER for the DSP comming? Does anyone know? -Dale On Wed, 18 Nov 1998 sagarwal@crash.ae.usr.com wrote: > Date: Wed, 18 Nov 1998 09:03:43 -0600 (CST) > From: sagarwal@crash.ae.usr.com > Reply-To: usr-tc@lists.xmission.com > To: Russ Miescke <russm@powerweb.net> > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) New Hiper ARC service release > > > 4.1.72 is newer code than 4.1.78. It has all the fixes from 4.1.78 and > some additional fixes. > > Thanks > > Sanjay > > On Thu, 19 Nov 1998, Russ Miescke wrote: > > > Is this a newer code than the ER 4.1.78? Does 4.1.78 contain all of the > > fixes from 4.1.72? I guess I am hesitant to change something that is sort > > of working. Anybody load this yet? > > > > > > Russ Miescke > > Power Web Connect > > russm@powerweb.net > > http://www.powerweb.net > > > > ----- Original Message ----- > > From: Ricky Beam <jfbeam@Interpath.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Tuesday, November 17, 1998 6:11 PM > > Subject: Re: (usr-tc) New Hiper ARC service release > > > > > > sagarwal@crash.ae.usr.com was heard to say: > > >Check out a new Hiper ARC service release code version 4.1.72 at > > > > > >http://totalservice.usr.com > > > > I love the version number... ne041727.zip :-) I also like the way I don't > > need a service contract to grab it (or do I?) > > > > --Ricky > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) upgrade for Netserver card available?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 11:56:54
Theodore Cekan said once upon a time: > >I have a Netserver Card hardware version 4.0.0 running software 3.3.3. Is >it possible to upgrade the software? It tries to load le*.nac software and >3.3.3 is the latest 3Com has on their site. It has a really annoying habit >of dropping all the connections and not telling my radius server. You might need a memory upgrade. Check to see if your card has 16 megs or more, if not, you will need to replace the 4 meg SIMM inside with a 16 meg one.
Subject: Re: (usr-tc) ppp start message
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 12:00:18
Laszlo Vecsey said once upon a time: > PPP session start message: PPP session from %server_ip to %client beginning... > >but when i log in manually with a terminal over dialup and log in for ppp, >it doesnt display it at all. also, does this default start message match >the netserver one.. i'd like to keep it the same. For the most part, except that %server_ip on the Netserver is bracketted by parenthesis. As stated in your other message Laszlo, I haven't been able to get the parenthesis to go in either, so I just bagged them.
Subject: Re: (usr-tc) Confirmation
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 12:06:32
Mike Andrews said once upon a time: >This seems to be broken on current ARC releases up to and including at >least 4.1.78; you have to also use "Max_Channels = 1" (which is a VSA) to >do the right thing there. On the NETserver, it's fine. Go back through >the archives a month or two and you can see me whining away about this :) >We actually have both Port-Limit AND Max_Channels in the Radius users >file. That seems to take care of things. According to the fix documentation, 4.1.72 follows the RFC on this. Does anyone know if that returns things to normal? ;-)
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 12:11:28
Mike Wronski said once upon a time: >It could have been.. But I havent seen it.. The only time default user settings >would not apply is if there was a conflicting RADIUS attribute. Then RADIUS wins >the tie. For example. Default user has idle time set to 600 and the Radius >attribute "Idle-Timeout=1200" is in the access accept. The idle timeout will be >1200 for that user. But Mike, what good is a time-limit when just about anything can reset it? ICQ, RIP, ping, all manner of useless broadcasts, in fact any traffic at all, no matter how mundane resets the timeout. We need to be able to configure what counts as activity on the ARC.
Subject: Re: (usr-tc) Filter settings
From: MegaZone <megazone@megazone.org>
Date: 1998-11-18 12:54:16
Once upon a time Marcelo Souza shaped the electrons to say... > How can I set ARC to log the packets dropped from a filter? I'm not sure if they kept this the same from the NS - but if so you just add the word 'log' on the end of the filter rule and any packet that hits that rule causes a syslog entry. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) RADIUS & user limitations
From: MegaZone <megazone@megazone.org>
Date: 1998-11-18 12:55:41
Once upon a time GTI x2 Tech shaped the electrons to say... > We have several TC's, and are looking to implement a way to > keep users from connecting more than once at a time (using RADIUS). You need a RADIUS server that has this intelligence built in. I highly recommend Cistron RADIUS for this - it works very well. Others include Lucent RADIUS ABM, Radiator, and IEA's RadiusNT. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) upgrade for Netserver card available?
From: Theodore Cekan <ted@mho.net>
Date: 1998-11-18 13:03:50
Thanks Pete, It has 4 meg. Will an upgrade allow me to install later software or will it just help performance? Ted -----Original Message----- >Theodore Cekan said once upon a time: >> >>I have a Netserver Card hardware version 4.0.0 running software 3.3.3. Is >>it possible to upgrade the software? It tries to load le*.nac software and >>3.3.3 is the latest 3Com has on their site. It has a really annoying habit >>of dropping all the connections and not telling my radius server. > >You might need a memory upgrade. Check to see if your card has 16 megs or >more, if not, you will need to replace the 4 meg SIMM inside with a 16 meg >one. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 13:05:08
Mike Wronski said once upon a time: >I think the configurable idle timeout filter sounds like a good idea until you >really look at its implementation and wheather it will even do what you want. It >would work for a short time and then the users will figure out a way around it. I >think there are many other features that time & resources could be spent >developing that would benefit the ISP more than this. I'm not talking about the savvy abuser though. I'm talking about my DAD who leaves his connection open by accident just because he's running ICQ. We go after the savvy abusers by looking at total time used. However, I would still say that we have a large problem with non-technical users accidentally leaving their computers connected. I don't know the internals of your code Mike, but wouldn't it be as simple as a boolean operation on existing filter code with a specified name? I think if 3com did a poll (the horror!) of ISPs feature demands, this would rate rather highly. Its #1 with me.
Subject: Re: (usr-tc) upgrade for Netserver card available?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 13:05:52
Theodore Cekan said once upon a time: > >Thanks Pete, > >It has 4 meg. Will an upgrade allow me to install later software or will it >just help performance? Both, if you install the later software. 3.3.3 will not take advantage of the extra memory.
Subject: Re: (usr-tc) HELP: need to route IP addresses to a customer over TC
From: MegaZone <megazone@megazone.org>
Date: 1998-11-18 13:06:01
Once upon a time C Thompson shaped the electrons to say... >We have not had to do this before, but I need to route a Class C address >across an ISDN connection on a USR/3com Total Control hub to one of >our customers. Also, for future reference, it would be helpful to know >what to do for a subnet as well. > >Can anyone provide helpful pointers on what I need to do >1) in RADIUS See below. >2) in the TC Hub (if anything) I'm not sure what needs to be done to get it to recognize the netmask as sent by RADIUS. For example a PM has 'set user-netmask on' for this. >3) in my router Well, if you are running an active routing protocol that can handle this then it should propigate ok. Now, as to radius. I speak primarily Lucent RADIUS or Cistron RDIUS, so translate as need be. eris Auth-Type = System Service-Type = Framed-User, Framed-Protocol = PPP Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP, Framed-IP-Address = 192.168.1.1, Framed-IP-Netmask = 255.255.255.0 With a NAS that recognizes netmasks, that should route the user the 192.168.1.0/24 network, with their end of the line being the .1 address. Now, if your NAS doesn't listen to RADIUS netmasks (unfortunate) you can try this kludge. eris Auth-Type = System Service-Type = Framed-User, Framed-Protocol = PPP Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP, Framed-IP-Address = 192.168.1.1, Framed-IP-Netmask = 255.255.255.0 Framed-Route = "192.168.1.0/24 192.168.1.1 1" That should 'manually' install the network route for you. For a subnet, just change the netmask(s) in the entry. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) RADIUS & user limitations
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-11-18 13:07:10
On Wed, 18 Nov 1998, MegaZone wrote: > Once upon a time GTI x2 Tech shaped the electrons to say... > > We have several TC's, and are looking to implement a way to > > keep users from connecting more than once at a time (using RADIUS). > You need a RADIUS server that has this intelligence built in. I highly > recommend Cistron RADIUS for this - it works very well. > Others include Lucent RADIUS ABM, Radiator, and IEA's RadiusNT. I heard Livingston wasnt too keen on the free radius server clones (eg merit, etc) which is why they made the Radius2.0 license so restrictive. How does Lucent view cistron, especially since its based off old Livingston code? -Dan
Subject: (usr-tc) I'm back (administrative message)
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 13:07:20
I'm back from a month-long honeymoon. This is why you are seeing an influx of old messages that required approval to the list. I'll also be cleaning up any bad addresses and adding all the new subscription requests that weren't automatically processed.
Subject: Re: (usr-tc) ppp start message
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-11-18 13:19:03
Ok, just a follow up on the problem I was having and the solution, for those that are interested. There are certain mac dialers (configppp in particular i think) that check for the existence of "beginning...." in the script. Now by default the hiperarc puts out a ppp session start string that includes that text, but apparently the PPP protocol (garbled) binary text that follows includes a backspace character of some sort, perhaps someone familiar with the protocol could confirm this, so that what the client ends up seeing is one less dot. The solution was to add a carriage return to the start string set ppp session_start "PPP session from %server_ip to %client_ip beginning....\n" I wonder, does the Netserver send a carriage return, and exactly what does its PPP string look like anyway? I'd like to match up the hiperarc string exactly the way my former netserver was running, less there be other quirks I overlooked.. Now sometime back on the list there was some discussion of putting paranthesis around the server_ip and client_ip, and quirks with respect to that. Maybe I didnt archive all the messages or deleted them by accident, but I found that you need a space character after either %server_ip or %client_ip for it to match and be parsed out, you cant follow it directly with a ')' character. Also when it does get parsed out, theres a space inserted before the IP automatically.. so I dont see a way to get the paranthesis to line up right to the IP's. Not that I even need this, but just curious. On Tue, 17 Nov 1998, Carl Litt wrote: > > enable authen hint_assigned > > On Tue, 17 Nov 1998, Laszlo Vecsey wrote: > > > Is there a toggle to have the ppp start message display on the hiperarc? > > 'show ppp' lists the following, running on 4.1.11 and 4.1.72 > > > > DIAL_IN Users Authenticate: ANY > > PPP Authentication Preference: PAP > > > > PPP session start message: PPP session from %server_ip to %client beginning... > > > > but when i log in manually with a terminal over dialup and log in for ppp, > > it doesnt display it at all. also, does this default start message match > > the netserver one.. i'd like to keep it the same. > > > > -L > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) Confirmation
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 13:24:46
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Wednesday, November 18, 1998 1:07 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Confirmation | | |Mike Andrews said once upon a time: | |>This seems to be broken on current ARC releases up to and including at |>least 4.1.78; you have to also use "Max_Channels = 1" (which is a VSA) to |>do the right thing there. On the NETserver, it's fine. Go back through |>the archives a month or two and you can see me whining away about this :) |>We actually have both Port-Limit AND Max_Channels in the Radius users |>file. That seems to take care of things. | |According to the fix documentation, 4.1.72 follows the RFC on this. Does |anyone know if that returns things to normal? ;-) Yes.. Port-Limit & Max_Channels now function the same. They only apply to MLPPP bundles and not to concurrent session limiting.. HARC & NS work the same now. You can remove your double entries or workarounds. -M
Subject: RE: (usr-tc) HiperARC.. [resend, first one never hit the list?]
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 13:39:59
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of System |Administrator |Sent: Wednesday, November 11, 1998 1:17 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) HiperARC.. [resend, first one never hit the list?] | | |Config'ing first HiperARC (btw, must say that CLI is MUCH better than |netserver), couple of questions: | |1. Is there still a known problem with chassis awareness (w/ latest non-ER |code). Only one HARC, so should I do chassis slot assignments manually? This is not an issue with one HARC. It works fine automatically. |2. Am I to understand that the Idle-Timeout RADIUS attribute does not work |correctly with the HARC, and that I must use a VA (we have a highly customized |radius daemon, which supports loads of goodies, but not VA)? No.. Idle-Timeout works fine and there is no VSA for it anyway. NOTE: These statements reflect the latest code available 4.1.72-7. I don't wish to list does/does not in previous versions. -M
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 13:40:00
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Wednesday, November 18, 1998 1:11 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Solution for idle time limits and dual logins | | |Mike Wronski said once upon a time: | |>It could have been.. But I havent seen it.. The only time default user settings |>would not apply is if there was a conflicting RADIUS attribute. Then |RADIUS wins |>the tie. For example. Default user has idle time set to 600 and the Radius |>attribute "Idle-Timeout=1200" is in the access accept. The idle timeout will be |>1200 for that user. | |But Mike, what good is a time-limit when just about anything can reset it? |ICQ, RIP, ping, all manner of useless broadcasts, in fact any traffic at |all, no matter how mundane resets the timeout. We need to be able to |configure what counts as activity on the ARC. | I don't have a good answer for that. Idle-timeouts are only usefull against the non-savy user and those are getting fewer by the day. So what do you count as activity that should reset the idle timer? No matter what you define as idle, someone will come up with a way to use data you don't check to keep the channel open.. I can think a simple way to use HTTP gets to keep the line open.. I think you are fighting a battle that cant be won.. The user who wants to, will nail their connection up.. A resonable session limit may be your only hope. I think the configurable idle timeout filter sounds like a good idea until you really look at its implementation and wheather it will even do what you want. It would work for a short time and then the users will figure out a way around it. I think there are many other features that time & resources could be spent developing that would benefit the ISP more than this. -M
Subject: RE: (usr-tc) CONNECTION PROBLEM
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 13:45:06
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley |Sent: Tuesday, November 10, 1998 7:56 AM |To: USR-TC@lists.xmission.com |Subject: (usr-tc) CONNECTION PROBLEM | | | | |We have a customer who has Brother NB-80C Geobook trying to connect with us |on a HiperArc running 4.1.78 code. The call continually fails in the LCP |negotiation stage and we never see the userid and password get sent. The |Geobook is a replacement because he had so many problems with the old one. |With the old one he was able to connect with us but since then we have done |a couple of HiPerArc release upgrades. Below is a copy of a MONITOR PPP |trace from the HiPerArc. I am concerned this may be a HiPerArc problem |but I want to be sure. We have sent the trace on to Brother too. They do |include a diskette from Earthlink and it does work with them. Does anyone |have a document for decoding these traces and figuring out what is going |on ? | |We spoke to Brother and they were no help. Basically mumbling things like if |you are trying to connect to an NT server it won't work and we only support |dialing into Unix machines. They said send them to Earthlink. I don't think |we want to start eliminating groups of users from our collective ISps based |upon the equipment the end user has. That doesn't seem to be good business |practice. | This looks like a problem we had with ASYNC_MAP of all 0's.. This is resolved in the 4.1.72-7 code. -M
Subject: Re: (usr-tc) PRI vs T1 ?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-18 13:46:01
Once upon a time Robb Bryn shaped the electrons to say... > are now pricing PRI vs T1. In our area T1's are priced about > $600/month cheaper than a PRI. Aside from PRI's being easier to > setup, I've caught rumors that T1's are not as fast as PRI (when > considering a v.90 call & all other factors are equal). I have only > one question... are these rumors true? Yes - and no. Some users have shown that CT1 lines *for them* get about a notch lower connect speeds than PRI. A good many users have reported this with 3Com, Lucent, Ascend, etc. However, not ALL users see this - and there hae been a couple of cases where users reported their CT1 lines were giving better connections. But based on what I've seen you do have a good chance of seeing *slightly* lower speeds on a CT1. There is also the fact you can't do ISDN DATA over a CT1, only ISDN DOSBS. And I don't think the TC does DOSBS yet, does it? (If so, can it do ISDN DOSBS *and* modems over the same CT1 at the same time?) -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: (usr-tc) Corresponding modem is unavailable
From: Curt Shambeau <curt@execpc.com>
Date: 1998-11-18 13:46:02
Quad modem chassis running 4.2.1 on T1 card (running channelized T1's) modem cards running 5.10.9, HiPer ARC 4.0.29, NMC running 5.5.5 When doing a DS0 performance monitor, the DS0 channels show idle, but the modem connected to the DS0 status is "corresponding modem is unavailable." I've tried restoring the chassis from defaults, and resetting everything, to no avail. Has anyone seen this before?? | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |
Subject: RE: (usr-tc) Preventing the answering of a 128K ISDN call
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 14:05:23
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric J. Lorenzo |Sent: Friday, November 06, 1998 1:05 PM |To: TC List |Subject: (usr-tc) Preventing the answering of a 128K ISDN call | | |How do you block in both a NETServer and a HARC the answering of a 128K |ISDN calls? We don't want two modems being taken up by one user. | Set Port-Limit=1 in your RADIUS default user. Or without RADIUS: Netserver: set mp off HARC: set net user default ppp max_chan 1 (4.1.x) set net user default max_chan 1 (4.0.x) -M
Subject: Re: (usr-tc) RADIUS & user limitations
From: MegaZone <megazone@megazone.org>
Date: 1998-11-18 14:06:30
Once upon a time Dan Hollis shaped the electrons to say... >I heard Livingston wasnt too keen on the free radius server clones (eg >merit, etc) which is why they made the Radius2.0 license so restrictive. Not quite. Most of the issue was other vendors selling HW without a RADIUS server - and telling customers to just go download it from Livingston. This happened a LOT. Then they'd get calls from people wanting Livingston to support their free RADIUS with a Computone, etc. Since RADIUS was well into the RFC process, there were a number of free servers out, a number of vendors had started produciing their own, AND there were a growing number of commercial servers - when they produced 2.0 they decided it was time to tighten control a bit. They added things like menuing, SecurID support, Group check - and now proxy, VSAs, ActivCard, etc to the 2.x revisions. It didn't make sense to keep helping the competition sell product, or let them produce a RADIUS server after Livingston, now Lucent RABU, had invested quite a bit of resources in doing the ground work for the new features. >How does Lucent view cistron, especially since its based off old >Livingston code? Quite favorably actually. You'll see a number of Lucent RABU folks referring people to Cistron if they need special features, or are looking for a free server with wider support for a mixed vendor community - for example, the latest Cistron supports 3Com VSAs. It still has some Livingston 1.16 code in its guts, but there is an ongoing effort to switch to libradius to create a truly public sourced RADIUS, which would likely be GPL'd. Free servers like Cistron don't detract in any way from the Lucent servers. Cistron doesn't quite do everything - SecurID, ActivCard, and menuing are major features not in the free server. And while Cistron, and some commercial products liek Radiator, do simultaneous login control they don't have the large scalability, nor the myriad of advanced features, in a product like RADIUS ABM. Actually, a free server like Cistron spares Lucent from having to implement features not widely desired, or that could have scalability issues. The server they release has to address a very wide array of users, and it has their name on it. With Cistron you have a number of interesting features - like fall through profiles, IP pools, etc - which a few users like. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 14:08:52
Mike Wronski said once upon a time: >I would propose that using SNMP, the %utilization over a time interval on a >per-interface basis could be obtained. Then you can drop users if they have less >than some % use for last time interval.. This is easy with HARC and possible with >Netserver. Its also not *perfect* but it would work. That would be very cool. Can we get it implemented into ARC code via RADIUS? ;-)
Subject: Re: (usr-tc) 10 DSP's & 1 ARC
From: Frank Basso <frank@got.net>
Date: 1998-11-18 14:28:15
Us to... We run this combo with no issues. -----Original Message----- >Jamie Orzechowski said once upon a time: >> >>Wondering if anyone has had any experience running 10 DSP's and 1 ARC card >>in one chassis? ... any recommendations? ... any problems? >> >>I will be using the lastest ARC beta code .... > >I'm running 11. Overall, things seem to work fine. We have a bit of >funkiness with slot 6 on a couple chassis, which may just be >telco-coincidence, but other that, everything is great. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 14:56:08
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Wednesday, November 18, 1998 2:05 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Solution for idle time limits and dual logins | | |Mike Wronski said once upon a time: | |>I think the configurable idle timeout filter sounds like a good idea until you |>really look at its implementation and wheather it will even do what |you want. It |>would work for a short time and then the users will figure out a way |around it. I |>think there are many other features that time & resources could be spent |>developing that would benefit the ISP more than this. | |I'm not talking about the savvy abuser though. I'm talking about my DAD |who leaves his connection open by accident just because he's running ICQ. |We go after the savvy abusers by looking at total time used. However, I |would still say that we have a large problem with non-technical users |accidentally leaving their computers connected. |I don't know the internals of your code Mike, but wouldn't it be as simple |as a boolean operation on existing filter code with a specified name? Its actually not that simple. The architecture has filters associated with IP data and idle-timout with PPP data. By the time the filter gets the packet the timer has already been reset. This implementation would require some reorganization of the levels and thus not be a simple boolean check. I would propose that using SNMP, the %utilization over a time interval on a per-interface basis could be obtained. Then you can drop users if they have less than some % use for last time interval.. This is easy with HARC and possible with Netserver. Its also not *perfect* but it would work. -M
Subject: RE: (usr-tc) upgrade for Netserver card available?
From: Wayne Barber <barberw@tidewater.net>
Date: 1998-11-18 15:00:21
You also need the Frame Relay NIC behind your Netserver. Without it, the memory upgrade will cause your Netserver to randomly reboot every few minutes. We finally bought a used Netserver PRI and FR NIC and have been troublefree since. Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown > Sent: Wednesday, November 18, 1998 1:57 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) upgrade for Netserver card available? > > > Theodore Cekan said once upon a time: > > > >I have a Netserver Card hardware version 4.0.0 running software > 3.3.3. Is > >it possible to upgrade the software? It tries to load le*.nac > software and > >3.3.3 is the latest 3Com has on their site. It has a really > annoying habit > >of dropping all the connections and not telling my radius server. > > You might need a memory upgrade. Check to see if your card has 16 megs or > more, if not, you will need to replace the 4 meg SIMM inside with a 16 meg > one. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 brackets in session_start_message
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 15:01:14
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rick Payne |Sent: Monday, October 26, 1998 9:46 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Problems with brackets in session_start_message | | |Mike Wronski writes: | | > Have you tried escaping the '(' with back slashes?? | |Yes. | | > set slip session_start_message "SL/IP session from \(%server_ip\) to | > %client_ip beginning..." | |I entered it as above. Same thing: | |SL/IP session from ( 194.42.231.28 to 255.96.0.0 beginning.. | |(assuming I don't need to relaod after setting the parameter). | |Code is 4.1.78 on the HiperARC. | Just place a space between '%server_ip' and the ')'. The result will be SL/IP session from ( 194.42.231.28 ) to 255.96.0.0 beginning.. -M
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 15:05:22
Thus spake Mike Wronski >I don't have a good answer for that. Idle-timeouts are only usefull >against the >non-savy user and those are getting fewer by the day. >So what do you count as activity that should reset the idle timer? Ideally, this should be administrator configurable...a filter list would be perfect. >No matter what you define as idle, someone will come up with a way to use data >you don't check to keep the channel open.. I can think a simple way to use HTTP >gets to keep the line open.. I think you are fighting a battle that cant be >won.. >The user who wants to, will nail their connection up.. A resonable >session limit >may be your only hope. Oh, so if you can't provide a *perfect* tool, then you won't give us *any* tools to work with at all. Thanks a lot there! You've obviously never run as ISP. Using the current filter rule setup to define what traffic resets the idle timeout, I could define a filter of about 5 to 10 lines that would eliminate 99.9% of our problems with people camping on lines. Yes, there will be users that will work around it, its not a perfect solution, but then again, RADIUS isn't a perfect solution for authenticating users the way everyone needs either, so why do you support RADIUS? >I think the configurable idle timeout filter sounds like a good idea until you >really look at its implementation and wheather it will even do what >you want. I *KNOW* it'll do what I want because I've used a pppd in the past that supported this sort of thing and it worked like a charm! >It >would work for a short time and then the users will figure out a way >around it. I >think there are many other features that time & resources could be spent >developing that would benefit the ISP more than this. There are plenty of features that you could develop that would benefit us greatly...let's come up with a list and I'll rank them how I feel they would be most useful to us. I guarentee you that idle-timer filter list would be *very* high up there. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) RADIUS & user limitations
From: GTI x2 Tech <x2@apollo.gti.net>
Date: 1998-11-18 15:12:18
Hi, We have several TC's, and are looking to implement a way to keep users from connecting more than once at a time (using RADIUS). If anyone knows of any documentation on doing this or has experience with it, any references/help would be appreciated. Thanks. (x2@gti.net)
Subject: RE: (usr-tc) Filter settings
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 15:15:56
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza |Sent: Wednesday, November 18, 1998 2:40 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Filter settings | | | | How can I set ARC to log the packets dropped from a filter? set packet_loggin logging <option> packet_size <0-493> This will send packet_size bytes of the dropped packet to the syslog. -M
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 15:15:57
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Wednesday, November 18, 1998 2:05 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Solution for idle time limits and dual logins |>So what do you count as activity that should reset the idle timer? | |Ideally, this should be administrator configurable...a filter list would |be perfect. |>No matter what you define as idle, someone will come up with a way to use data |>you don't check to keep the channel open.. I can think a simple way to use HTTP |>gets to keep the line open.. I think you are fighting a battle that cant be |>won.. |>The user who wants to, will nail their connection up.. A resonable |>session limit |>may be your only hope. | |Oh, so if you can't provide a *perfect* tool, then you won't give us |*any* tools to work with at all. Thanks a lot there! I don't provide anything but support for the product. People at higher levels have to wade through all the possible features and some fall out in favor of others. Its just not possible to make a product everyone is in love with.. I don't know for certain, but do any other vendors have this feature? I don't think we are unique here. |Yes, there will be users that will work around |it, its not a perfect solution, but then again, RADIUS isn't a perfect |solution for authenticating users the way everyone needs either, so why |do you support RADIUS? Agreed, but what is the alternative to RADIUS? TACACS? Is MS Anything perfect? nope. What do most people use?? With that logic: I think LINUX is better than MS. Should I not support MS even though its the defacto standard. I don't think its fair to compare the justification for a new feature with the use of the standard. I now expect a jump off the bridge reply from someone.. And "No I wouldn't do it just because all my friends did! :)" |There are plenty of features that you could develop that would benefit |us greatly...let's come up with a list and I'll rank them how I feel |they would be most useful to us. I guarantee you that idle-timer filter |list would be *very* high up there. You should do that. Put don't post it here. It is far more effective when submitted formally as a Feature Request/CRA and submitted by many people. Like most things, if enough people ask for it and it makes financial sense to have a feature it tends to get more consideration. (OSPF flame expected here.. Don't bother! I know its been a long time coming...But.. its coming...Really....No fooling...Its not vaporware...) I don't want to start a rant or flame war on this issue. I think that was is desired is understood by those on this list. I do my best to respond to issues on this list and have no desire to fight with anyone over feature sets.. -M
Subject: Re: (usr-tc) 10 DSP's & 1 ARC
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-11-18 15:22:49
Jamie Orzechowski said once upon a time: > >Wondering if anyone has had any experience running 10 DSP's and 1 ARC card >in one chassis? ... any recommendations? ... any problems? > >I will be using the lastest ARC beta code .... I'm running 11. Overall, things seem to work fine. We have a bit of funkiness with slot 6 on a couple chassis, which may just be telco-coincidence, but other that, everything is great.
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 15:24:11
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Wednesday, November 18, 1998 3:09 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Solution for idle time limits and dual logins | | |Mike Wronski said once upon a time: | |>I would propose that using SNMP, the %utilization over a time interval on a |>per-interface basis could be obtained. Then you can drop users if they |have less |>than some % use for last time interval.. This is easy with HARC and |possible with |>Netserver. Its also not *perfect* but it would work. | |That would be very cool. Can we get it implemented into ARC code via |RADIUS? ;-) | Sure.. The new harc is also a Soda Machine and Cotton candy maker. Gets the ISP into the lucrative Remote Carnival Access business.. But seriously.. This should not be very difficult to program in PERL and run on UNIX or (CHOKE!) NT.. -m
Subject: RE: (usr-tc) Radius Accounting Problems
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 15:24:12
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of rbryn@cape-fear.net |Sent: Thursday, October 22, 1998 10:24 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Radius Accounting Problems | | |I have a problem with Radius Accounting packets reporting the wrong NAS |port. When the Radius server recieves a packet for authentication it will |report the correct NAS port but when it sends the Accounting start/stop |packet it always reports NASPort=1. | |This problem only seemed to occur after upgrading TCS 3.3 | |Config is: |Total Control Chassis w/ |NMC v5.5.5 |HARC v.4.1.11 |Hiper DSP v.1.2.5 | Known issue with 4.1.11. Get the service relase. -M
Subject: Re: (usr-tc) Radius Accounting Problems
From: sagarwal@crash.ae.usr.com
Date: 1998-11-18 15:28:13
This was a bug in 4.1.11 code of Hiper ARC . Get the latest code 4.1.72 code from http://totalservice.usr.com The latest code fixes this issue of NAS port. Sanjay On Thu, 22 Oct 1998 rbryn@cape-fear.net wrote: > I have a problem with Radius Accounting packets reporting the wrong NAS > port. When the Radius server recieves a packet for authentication it will > report the correct NAS port but when it sends the Accounting start/stop > packet it always reports NASPort=1. > > This problem only seemed to occur after upgrading TCS 3.3 > > Config is: > Total Control Chassis w/ > NMC v5.5.5 > HARC v.4.1.11 > Hiper DSP v.1.2.5 > > Radius = IEA Software's RadiusNT v2.5 > > > Thanks > Robb Bryn > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Interested in Linux on the Netserver?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 16:01:52
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Wednesday, November 18, 1998 3:41 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Interested in Linux on the Netserver? | | |Thus spake Allen Marsalis |>Of course if there are any real hardware limits, they could be |>minimized and dealt with so udp performance would be as good or better |>than it is now, which is good enough for many.. just not us I |>suppose.. We house alot of Quake players.. | |OK, this is a rather random thought that your message here |triggered...pardon my rambling. | |A NETServer running PPP (ignoring for the moment filters...I'll get back |to this) passing an IP packet between a dial-up line and the |ethernet...has no reason to know if a packet is UDP, TCP, GRE, or |whatever. Obviously, to do filtering, that would require looking |farther into the packet to determine if its UDP, and even farther to |port numbers and the like. In the absense of filters though (we don't |use filters on our NETServers at all) conceivably, the code might not |even know if a packet was a UDP packet or not. Correct..PPP packet data is reassembled into the protcol that is encapsulated. This packet is pushed out onto the wire. (wire could be frame or ethernet). |So...is the problem really with *UDP* packets? Or is the problem more |one of handling a rapid stream of small packets (like Quake produces). |Conceivably, a similar stream of small IP packets could be generated in |a TCP connection...though its less likely...I wonder if that is affected |as well? Most traffic through the NS does not follow the same model as quake traffic. Quake is a high rate of very small packets. Each packet reguardless of size has a specific overhead associated with it. And then there is the overhead of the size. So when a large number of small packets, reguardless of protocol, pass through the Netserver, there is latency. It is for this reason that other usage does not appear to experience the problem. Most of your dialup traffic is bursty (asyncronous) larger packets. Quake is ...($10 word) almost isochronous. Its sending packets on a clock tic. So what we have discovered is that Quake is best played across pure ATM(not LANE) and not ethernet. :).. -M
Subject: RE: (usr-tc) Archives?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 16:04:44
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski |Sent: Wednesday, November 18, 1998 3:51 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Archives? | | |Just wondering where archives of this list are stored ... I thought they |were on interpric.ae.usr.com but that's down ... I think interpric is an adult site..;) interproc.ae.usr.com does not contain archives of this list. -M
Subject: RE: (usr-tc) Excessive data transferred / DNS resolution
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-18 16:27:21
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of |David.Perrin@mnco.com |Sent: Tuesday, October 13, 1998 1:21 PM |To: usr-tc@xmission.com |Subject: (usr-tc) Excessive data transferred / DNS resolution | | | |Working with the TCS 3.5 release using the Hiper ARC version 4.1.11 , |I'm running into a couple of significant |issues. | |We are currently using a NetServer card in production and are planning |to move to the Hiper ARC card in a new |chassis, but I'm having the following problems: | |1. There's an excessive amount of data transferred during a session |with the Hiper ARC card versus the | Netserver card connection. It's on order of 5 times the data |transferred with a Hiper ARC connection versus | the Netserver connection. How are you quantifing this? What kind of traffic are you putting on the line and do you have traces?? |2. DNS connectivity is acting strangely. DNS seems to be active and |working OK when telnetted into the | Hiper ARC console itself. The problem occurs when attempting to |use DNS via a Windows 95 session | connected remotely via PPP. For example I can ping a DNS host |name successfully, when using the | hostname along with the domain name (ie. abcdef.corp.mnco.com), |but receive a Bad IP address response | when trying to use the the hostname (ie. abcdef) . The DNS |domain name is set properly on the server | and as I said earlier I can sucessfully use DNS with just a |hostname when telnetted into the Hiper ARC | card. | So hostname lookup does not work from the 95 client? Did you configure the HARC to send its DNS information to the user? this is done with 'SET PPP DNS_USAGE SYSTEM'. Or you can configure separate DNS servers for PPP from the one configured for the HARC. 'SET PPP PPPDNS_PRIMARY ...' and then 'SET PPP DNS_USAGE PPP'. When you type 'winipcfg' on the client, do you see the correct DNS server address? -M
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 16:34:07
Thus spake Mike Wronski >I would propose that using SNMP, the %utilization over a time interval on a >per-interface basis could be obtained. Then you can drop users if they >have less >than some % use for last time interval.. This is easy with HARC and >possible with >Netserver. Its also not *perfect* but it would work. And also potentially bump off customers that are slow typists logged in via telnet to a shell server or something... Unforutunately, I think that solution is considerably *more* fraught with peril than not reset'ing the idle timeout based on filters that aren't going to catch everything. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 16:41:22
Thus spake Allen Marsalis >Of course if there are any real hardware limits, they could be >minimized and dealt with so udp performance would be as good or better >than it is now, which is good enough for many.. just not us I >suppose.. We house alot of Quake players.. OK, this is a rather random thought that your message here triggered...pardon my rambling. A NETServer running PPP (ignoring for the moment filters...I'll get back to this) passing an IP packet between a dial-up line and the ethernet...has no reason to know if a packet is UDP, TCP, GRE, or whatever. Obviously, to do filtering, that would require looking farther into the packet to determine if its UDP, and even farther to port numbers and the like. In the absense of filters though (we don't use filters on our NETServers at all) conceivably, the code might not even know if a packet was a UDP packet or not. So...is the problem really with *UDP* packets? Or is the problem more one of handling a rapid stream of small packets (like Quake produces). Conceivably, a similar stream of small IP packets could be generated in a TCP connection...though its less likely...I wonder if that is affected as well? Like I said...this is a very random thought, but thought I would throw it out for all to see. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) Archives?
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 1998-11-18 16:50:56
Just wondering where archives of this list are stored ... I thought they were on interpric.ae.usr.com but that's down ... ----- Original Message ----- Sent: Wednesday, November 18, 1998 4:34 PM >Thus spake Mike Wronski >>I would propose that using SNMP, the %utilization over a time interval on a >>per-interface basis could be obtained. Then you can drop users if they >>have less >>than some % use for last time interval.. This is easy with HARC and >>possible with >>Netserver. Its also not *perfect* but it would work. > >And also potentially bump off customers that are slow typists logged in >via telnet to a shell server or something... > >Unforutunately, I think that solution is considerably *more* fraught >with peril than not reset'ing the idle timeout based on filters that >aren't going to catch everything. :/ >-- >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) Accounting and Radius problem...
From: sagarwal@crash.ae.usr.com
Date: 1998-11-18 17:04:59
This is a bug in 4.1.11 code. Fixed in service release 4.1.72 Sanjay On Tue, 6 Oct 1998, Rick Payne wrote: > Dragan D. Vecerina writes: > > > Hi, > > Is there any workaround or suggestions for loss of accounting records > > from HiperArc Card (4.1.11). > > Problem is that it doesn't send (sometimes) ACCT OFF information > > to radius server when user disconnect. > > Indeed, and does this explain why the ARC loses track of how many IP's its > assigned from the pool? > > On one of ours today, we had no-one connected, but it still reckoned 2 > IP's from the pool were in use. *sigh*. > > Rick > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) CONNECTION PROBLEM
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-11-18 17:10:00
-> | -> |We spoke to Brother and they were no help. Basically mumbling things like -> if |you are trying to connect to an NT server it won't work and we only -> support |dialing into Unix machines. They said send them to Earthlink. I -> don't think |we want to start eliminating groups of users from our -> collective ISps based |upon the equipment the end user has. That doesn't -> seem to be good business |practice. -> | -> -> This looks like a problem we had with ASYNC_MAP of all 0's.. This is -> resolved in -> the 4.1.72-7 code. Actually since this message Krish has taken numerous debug traces and is investigating. Just watch out for these Brother Geobooks until we hear back with a resolution. Brother's technical support hasn't been helpful so far. Jeff Binkley ASA Network Computing
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 17:25:29
Thus spake Mike Wronski >Most traffic through the NS does not follow the same model as quake traffic. >Quake is a high rate of very small packets. Each packet reguardless of >size has a >specific overhead associated with it. And then there is the overhead >of the size. >So when a large number of small packets, reguardless of protocol, pass through >the Netserver, there is latency. It is for this reason that other >usage does not >appear to experience the problem. Most of your dialup traffic is bursty >(asyncronous) larger packets. Quake is ...($10 word) almost isochronous. Its >sending packets on a clock tic. So what we have discovered is that >Quake is best >played across pure ATM(not LANE) and not ethernet. :).. Heh...ok...so I was right in my thinking that its not strictly Quake, or even UDP that causes it...but is just lots of small packets that cause problems...understandable. Just wanted to get clarification of what really the crux of the problem was. Obviously, very few applications are going to create lot's of small packets like Quake does...and this could have largely been avoided by good coding in Quake to avoid large numbers of small packets...but...that's water under the bridge. Thanks for the info Mike. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 17:27:41
Thus spake Mark Lemmert >3com has suggested that I terminate the ISDN calls on the quad modems >instead of on the Netserver to solve this problem. Has any body else >had this problem? Can anybody give an opinion on whether 3coms suggested >fix is likely to have an affect on this? Thanks! I think I remember this happening, and, yes, terminating to Quad's did fix the problem (maybe just avoided it?) Anyway...you want to terminate on Quad's anyway...it's an all around better solution. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-18 17:43:56
At 02:56 PM 11/18/98 -0600, Mike Wronski wrote: > >Its actually not that simple. The architecture has filters associated with IP >data and idle-timout with PPP data. By the time the filter gets the packet the >timer has already been reset. This implementation would require some >reorganization of the levels and thus not be a simple boolean check. > > >I would propose that using SNMP, the %utilization over a time interval on a >per-interface basis could be obtained. Then you can drop users if they have less >than some % use for last time interval.. This is easy with HARC and possible with >Netserver. Its also not *perfect* but it would work. This may be a really stupid question, but I'll stick my neck out anyhow. <nomex=on> Instead of trying to figure out ways to determine the type of traffic being passed in order to determine if the only process running is an automated one, wouldn't it be easier to poll events for consistancy? For example; Event Time Traffic 1 01:03.28 24305 octets 2 01:08.22 24298 octets If event 3 occurs in same time frame(in 5 mins +/-30 seconds), and traffic remains +/-5% of previous counts, it is determined to be automated and punted. This should readily detect ICQ or other keep-alives that send a signal on a regular basis. Ok gentlemen(and ladies), you may now commence to start blowing my theory out of the water :) Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: Re: (usr-tc) PRI vs T1 ?
From: David Bolen <db3l@ans.net>
Date: 1998-11-18 18:04:37
MegaZone <megazone@megazone.org> writes: > Yes - and no. Some users have shown that CT1 lines *for them* get about a > notch lower connect speeds than PRI. A good many users have reported this > with 3Com, Lucent, Ascend, etc. However, not ALL users see this - and there > hae been a couple of cases where users reported their CT1 lines were giving > better connections. > > But based on what I've seen you do have a good chance of seeing *slightly* > lower speeds on a CT1. I'd pretty much agree with this. Using a CT1 circuit guarantees you at least one robbed bit path - that of the final CT1 circuit to your equipment. If everything else (the phone network, the user's call path, the user's line, etc..) were exactly the same and ideal, your CT1 path should probably result in a 'tick' or two less connection rates (say up to around 2400 baud difference). However, in real life, often the limiting factor of connections is not your final circuit. So if, for example, your local telco is robbing bits anyway along the path for analog calls that's probably going to limit things as much if not more so than your own circuit. And you'd be surprised how little a phone call (even a local call) has to travel through some telco networks before it traverses a robbed bit path. Additionally, if the user's own line is putting more limitation on the connection than the phone network, they'd never see the difference between CT1 and PRI anyway. Averaged around our network, there isn't much noticeable difference (statistically speaking) between our CT1 and PRI circuits. This of course, assumes you are going with CT1 configured for E&M signaling (don't touch ground or loop start). As for ease of setup, there's really not much more to CT1 - just define the signaling and that's about it - don't even have to worry about the remote switch type or anything like you do with PRI. If you can afford the effort and cost, I suppose you could initially get one of each in a test area, let them process user calls for some period, and then look at the results to see how they compare for your user base. If not though, as a data point from our perspective, we currently prefer PRI ourselves, but used to primarily use CT1 due to cost factors, and still do so without any problems in areas where the delta in cost is significant. > There is also the fact you can't do ISDN DATA over a CT1, only ISDN DOSBS. Definitely a good point if ISDN data termination needs to be offered. > And I don't think the TC does DOSBS yet, does it? (If so, can it do ISDN > DOSBS *and* modems over the same CT1 at the same time?) Don't believe so. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) V.90 is it safe to put on non-hyper dsp Total Control
From: David Bolen <db3l@ans.net>
Date: 1998-11-18 18:11:52
"Mike Hamrich" <mhamrich@drfast.net> writes: > Any advice for taking a X2 enabled year and a half old 2.5.X release Total > Control unit up to V.90 successfully? Just upgrade the code to the V.90 system release (at least TCS 3.1). Your x2 key in the NMC will also enable V.90 automatically. > The one thing I did hear was to reset modem to factory default. Have not > read if you need to upgrade in steps with new then what in the unit but > older then what current. If you need to put interim release on. How do you > get them? You can jump right from your 2.5.x release to 3.1 - that's the same upgrade path we took (2.5.1->3.1). For modems, I do recommend upgrading, then issuing a command to each one to restore to factory defaults, then issuing any settings you customize, and then saving to NVRAM. That's for any upgrade, not just this one. In terms of order, we do the NMC first (so it can support any newer objects we like to customize), and then just sort of work left to right in a chassis (circuit card, modems, and NETServer). The order isn't really that critical, but if you do the NETServer before the modems, remember to check your ports after doing the modems to ensure they are all live on the packet bus. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) using round robin & fixed assignment
From: David Bolen <db3l@ans.net>
Date: 1998-11-18 18:24:58
Taino d Johnston <usr-list@accesscom.com> writes: > What I am trying to find out is why when configured for 'fixed assignment' > we were giving out busy signals? The problems went away once we switched > to 'round robin'. It's a software bug - well, I consider it as such. What happens is that when the call release message comes down the PRI D channel, the PRI card informs the modem which tears down the call. However, the PRI immediately acknowledges the release message without waiting for the modem to indicate it has finished resetting. The problem is that the modem takes time to completely reset and be prepared for a new call (in some releases up to perhaps 250ms or more). During that time the telco thinks that the B channel is idle and may immediately send down a new call - especially if this is a busy hunt group and the channel is low in the group and the telco is itself using ascending hunting within the group. The PRI gets the call, tries to signal the modem over the packet bus and one of two things happens: * The modem isn't ready at all, and the PRI times out in the configuration step for a new call trying to talk to the modem. the configuration step for the new call. The result is a delay to the user followed by a busy when the PRI finally gives up. If enabled, the PRI should generate a callTermFailedEvent trap for this call. * The modem is sort of ready but not fully - it acknowledges the PRI indication, but when it gets ahold of the call can't properly process it and the user perceives dead air. If enabled, the modem should generate a DteRingNoAns trap for this call. You can also see the counts of these sorts of failures on some of the PRI debug summary screens for modem errors. Why this tends to happen more on PRI than CT1 is probably a combination of the faster and out-of-band signaling for call setup and teardown, and the way in which the PRI communicates to modems OOB over the packet bus for call setup as opposed to using TDM bus patterns for the CT1 code, both of which affect the general setup and teardown timing sequence during call processing. The reason that changing to round-robin allocation "fixes" this problem (in many cases) is that the newer call is not going to try to hit the same modem, but one of the two "idle" modems (on a T1). So instead of a limiting factor of the reset time of a single modem for your call cycle time, you have divided that time by 3 (worst case). Normally unless you lose several calls simultaneously, this is enough to avoid the problem. Having the telco distribute calls over your entire hunt group in a statistical fashion (or even round-robin) can help too, but not once the hunt group gets full or very busy since it's still likely to pick the B channel just released for the next call. The round robin selection also isn't a possibility in typical E1 configurations since in that case you don't have the automatic buffer modems. We had terrible problems with this at our E1 sites, and actually had to remove 4 B channels from service to give ourselves enough of a "buffer" to handle the call load. The "fix" (which doesn't require round-robin) is to both have the modem reset more quickly (at least to the point where it can start accepting new call information) as well as have the PRI wait for the modem to say it is done before acknowledging the release message from the telco. True, the PRI does have some hard timing limits within which it must acknowledge the message according to the D channel protocol, but there's room in there to wait for the modem in most cases. I can't speak to the general availability of such a fix or not, but it is possible. Of course, switching to round robin (for most T1 configurations) is generally pretty effective too. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) using round robin & fixed assignment
From: David Bolen <db3l@ans.net>
Date: 1998-11-18 18:34:29
In a prior note, I wrote: > (...) > the user followed by a busy when the PRI finally gives up. If > enabled, the PRI should generate a callTermFailedEvent trap for > this call. BTW, these call event traps that the PRI can generate can be used in general to track call delivery problems that occur between the PRI card and other components. At a minimum the callTermFailedEvent trap will give you an indication of every call that arrived at the PRI (from the telco) but for some reason was not properly serviced by the target device (either modem or ISDN gateway). Enabling callArriveEvent permits you to count all call arrivals seen by the PRI card, so you can get a failure percentage. The others (callConnectEvent, callTermNormalEvent, and callEvent) can also be used to build a better picture of just how calls are flowing from the PRI card to other chassis components. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: (usr-tc) Filter settings
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-11-18 18:40:20
How can I set ARC to log the packets dropped from a filter? - Marcelo
Subject: Re: (usr-tc) Solution for idle time limits and dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 20:07:27
Thus spake Mike Wronski >|Oh, so if you can't provide a *perfect* tool, then you won't give us >|*any* tools to work with at all. Thanks a lot there! >I don't provide anything but support for the product. People at higher levels >have to wade through all the possible features and some fall out in favor of >others. Oh, believe me, I understand that...but please understand that we've gotten the run-around on features before. :) >Its just not possible to make a product everyone is in love with.. I >don't know for certain, but do any other vendors have this feature? I >don't think >we are unique here. I've not seen any NAS vendors that do, but as I mentioned previously, I've used a pppd (Morningstar) that had this feature and it was a *wonderful* feature to have. >Agreed, but what is the alternative to RADIUS? TACACS? Is MS Anything perfect? >nope. What do most people use?? >With that logic: I think LINUX is better than MS. Should I not support MS even >though its the defacto standard. You, of course, have a point...RADIUS is the best thing out there for doing this... However, you see my point as well, right? We, the customers need tools to be able to make our networks work the best we can, and we're getting you (and I don't mean this to be a slam on you personally...I'm *glad* you're responding to these postings) telling us that our desires for features that we want are wrong. :) You can see how that would be a little bit grating. :) As I said...I've used this feature before, on a UNIX based pppd and it was wonderful to have...I'd like to be able to do this on a NAS too. :) >I now expect a jump off the bridge reply from someone.. And >"No I wouldn't do it just because all my friends did! :)" Blah...I've always thought that was a stupid argument. :) >|There are plenty of features that you could develop that would benefit >|us greatly...let's come up with a list and I'll rank them how I feel >|they would be most useful to us. I guarantee you that idle-timer filter >|list would be *very* high up there. >You should do that. Put don't post it here. It is far more effective when >submitted formally as a Feature Request/CRA and submitted by many people. Hey, I'm more than happy to submit it through formal channels...but let's also consider this as a possible discussion ground for what those features that we request might be. Perhaps we could all work on a list together and could use that as a base for features that we'd all like to see put in, and possibly augment that with our own individual requests. :) >(OSPF flame expected here.. Don't >bother! I know its been a long time coming...But.. its coming...Really....No >fooling...Its not vaporware...) Heh...wasn't gonna be a flame, but it *was* gonna get mentioned. :) I know its coming...is it 4.1.72 perchance? I thought I had heard some talk of it being available in ER's/SR's, but perhaps I'm just imagining things. >I do my best to respond to issues on this list and have no desire to fight with >anyone over feature sets.. Please, your input is greatly appreciated...and you pointed out a very real limitation on why this would be a difficult thing to implement (idle-timer is reset before the IP header is even parsed)...that's very understandable. At least when I go talk to Tom Goodman I'll understand if it doesn't show up in the very next release. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Pt to Pt Test Link
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-18 20:09:37
Thus spake Mark Lemmert >If you made an cat5 cable /w RJ45 ends with >a special wiring scheme you can simulate make >the two CSUs talk as though you had a telco circuit >between them. Well...it's not *quite* that simple as you have issues of clocking and stuff to deal with...one of the systems would have to generate clock for the other to see on the T1...so the config is slightly different than if you had a telco simulator or something to do it. >See your CSU manual to find out which pins are >for transmit/receive and tip/ring. You'll want 1 <-> 4, and 2 <-> 5, other pins aren't needed. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) upgrade for Netserver card available?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-18 21:22:25
Pete Ashdown was heard to say: >You might need a memory upgrade. Check to see if your card has 16 megs or >more, if not, you will need to replace the 4 meg SIMM inside with a 16 meg >one. I've never seen a netserver with less than 4M on the board itself. That's why alot of our netservers have 20M (and a few 32M) --Ricky
Subject: Re: (usr-tc) Confirmation
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-18 21:25:01
Pete Ashdown was heard to say: >>This seems to be broken on current ARC releases up to and including at >>least 4.1.78; you have to also use "Max_Channels = 1" (which is a VSA) to >>do the right thing there. On the NETserver, it's fine. Go back through >>the archives a month or two and you can see me whining away about this :) >>We actually have both Port-Limit AND Max_Channels in the Radius users >>file. That seems to take care of things. > >According to the fix documentation, 4.1.72 follows the RFC on this. Does >anyone know if that returns things to normal? ;-) What fix docs? There wasn't anything in the zip file. --Ricky
Subject: Re: (usr-tc) upgrade for Netserver card available?
From: David Bolen <db3l@ans.net>
Date: 1998-11-18 21:33:45
Ricky Beam <jfbeam@Interpath.net> writes: > Pete Ashdown was heard to say: > >You might need a memory upgrade. Check to see if your card has 16 megs or > >more, if not, you will need to replace the 4 meg SIMM inside with a 16 meg > >one. > > I've never seen a netserver with less than 4M on the board itself. That's > why alot of our netservers have 20M (and a few 32M) True, but it sounds like Pete is talking about an 8MB configuration (4MB on the board itself and a 4MB SIMM) or else there wouldn't be a 4MB SIMM to remove. 8MB was the format used for a while when they first introduced the ISDN capable NETServers (with the Munich daughtercard) and even for non-ISDN NETServers. I'm not sure how long they actually shipped NETServers with only the 4MB on the board, although we sure had a lot of them to deal with later :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-18 21:48:36
Allen Marsalis was heard to say: >Lets say you get USR to cooperate (1st feat). Then you get linux up >on the netserver (2nd feat). What if Quake still lags? I mean Quake >Lag is a symptom of a much bigger problem. And it might be hardware >related and that has been hinted at. A packet is a packet. I don't buy the "but it's the hardware" excuse. --Ricky
Subject: RE: (usr-tc) Radius Accounting Problems
From: Chris Peltier <cpeltier@iectech.com>
Date: 1998-11-18 22:04:57
Saw the same thing... Several things. Make sure if you are using ODBC and SQL for backend to have the SESSIONIDENTIFIER in your SQL table to at least 14 characters in length -- it jumped from 12 to 14 in this release (under radius NT). Also look at the radius config on the Hyper ARC. We have set the radius attributes to Ascend style and re-ported the SQL table to handle ports 0-23 in slot 1 1024 to 1024+23 in slot 2, 2048 to 2048+23 in slot 3, etc.. (for PRIs). Some of this requires SQL by hand. It works fine now after all this.. The biggest problem is that you have to drop the Calls table under IEAs Radius NT and recreate it with the increased column width for session identifier. -Chris >-----Original Message----- >From: rbryn@cape-fear.net >Sent: Thursday, October 22, 1998 11:24 AM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Radius Accounting Problems > > >I have a problem with Radius Accounting packets reporting the wrong NAS >port. When the Radius server recieves a packet for authentication it >will >report the correct NAS port but when it sends the Accounting start/stop >packet it always reports NASPort=1. > >This problem only seemed to occur after upgrading TCS 3.3 > >Config is: >Total Control Chassis w/ >NMC v5.5.5 >HARC v.4.1.11 >Hiper DSP v.1.2.5 > >Radius = IEA Software's RadiusNT v2.5 > > >Thanks >Robb Bryn > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Interested in Linux on the Netserver?
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-18 22:35:53
: Allen Marsalis was heard to say: : >Lets say you get USR to cooperate (1st feat). Then you get linux up : >on the netserver (2nd feat). What if Quake still lags? I mean Quake : >Lag is a symptom of a much bigger problem. And it might be hardware : >related and that has been hinted at. : : A packet is a packet. I don't buy the "but it's the hardware" excuse. Of Allen's original feats, the first has already started to happen, and the second is much closer to done than you might imagine. I'd bet a small sum of money that there's nothing in the hardware specifically related to UDP. The Netserver is a general-purpose computer with some nifty interfaces.
Subject: RE: (usr-tc) Solution for idle time limits and dual logins
From: Charles Sprickman <spork@inch.com>
Date: 1998-11-18 22:53:04
On Wed, 18 Nov 1998, Mike Wronski wrote: > You should do that. Put don't post it here. It is far more effective when > submitted formally as a Feature Request/CRA and submitted by many people. Like > most things, if enough people ask for it and it makes financial sense to have a > feature it tends to get more consideration. (OSPF flame expected here.. Don't > bother! I know its been a long time coming...But.. its coming...Really....No > fooling...Its not vaporware...) How exactly does one make a feature request? I'll request my brains out, just show me the way... I hope I don't need a support contract to do that.. Thanks, Charles > > I don't want to start a rant or flame war on this issue. I think that was is > desired is understood by those on this list. > I do my best to respond to issues on this list and have no desire to fight with > anyone over feature sets.. > > -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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
Subject: RE: (usr-tc) Archives?
From: Charles Sprickman <spork@inch.com>
Date: 1998-11-18 22:57:32
> |Just wondering where archives of this list are stored ... I thought they > |were on interpric.ae.usr.com but that's down ... They were at http://usr-tc.datasys.net, but it looks like it hasn't been updated and the search and index features have gone away... Charles > > I think interpric is an adult site..;) interproc.ae.usr.com does not contain > archives of this list. ehhh... > > > -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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
Subject: Re: (usr-tc) New Hiper ARC service release
From: Russ Miescke <russm@powerweb.net>
Date: 1998-11-19 01:31:45
Is this a newer code than the ER 4.1.78? Does 4.1.78 contain all of the fixes from 4.1.72? I guess I am hesitant to change something that is sort of working. Anybody load this yet? Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net ----- Original Message ----- Sent: Tuesday, November 17, 1998 6:11 PM sagarwal@crash.ae.usr.com was heard to say: >Check out a new Hiper ARC service release code version 4.1.72 at > >http://totalservice.usr.com I love the version number... ne041727.zip :-) I also like the way I don't need a service contract to grab it (or do I?) --Ricky - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
Subject: (usr-tc) my modem configuration
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-19 05:52:59
This is my current procedure for setting modems, for both hiperdsp and quad modems hooked up to hiperarcs. Comments welcomed. restore modems from default save modems to nvram on hiperarc: reset modem_group all make following modem (not template) changes Line interface options - carrier loss detect delay = 14 signal converter settings - v.42 selective reject = enable Call control options - response to +++ = ignore esc code save modems to nvram hardware reset verify settings if desired... DTE Interface Settings Modem Escape Char (S2) 255 Call Control Options Result Codes (Qn) displayResult Verbal/Numeric Result Codes numeric Result Code Groups 0 ARQ Result Codes arqResultsDisabled Response to +++ ignoreEscCode Rings for Auto Answer 0 ATZ Handling over Packet Bus atZPbIgnore Packet Bus Answer Only (S47.5) enable Signal converter settings v.42 selective reject enable Line interface options carrier loss detect delay 14 -- Aaron Nabil
Subject: Re: (usr-tc) Pt to Pt Test Link
From: Greg Coffey <greg@coffey.com>
Date: 1998-11-19 07:21:40
Thanks for the reply and info. BTW, we did get it to work using two motorola CSU's. The compression worked pretty well too, now if we can just get USWest to get the line changed correctly someday before the turn of the century.............., we'll see how it works in the real world. At 08:09 PM 11/18/98 -0500, you wrote: >Thus spake Mark Lemmert >>If you made an cat5 cable /w RJ45 ends with >>a special wiring scheme you can simulate make >>the two CSUs talk as though you had a telco circuit >>between them. > >Well...it's not *quite* that simple as you have issues of clocking and >stuff to deal with...one of the systems would have to generate clock for >the other to see on the T1...so the config is slightly different than if >you had a telco simulator or something to do it. > >>See your CSU manual to find out which pins are >>for transmit/receive and tip/ring. > >You'll want 1 <-> 4, and 2 <-> 5, other pins aren't needed. >-- >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. > > ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-19 08:31:37
Thus spake Ricky Beam >Allen Marsalis was heard to say: >>Lets say you get USR to cooperate (1st feat). Then you get linux up >>on the netserver (2nd feat). What if Quake still lags? I mean Quake >>Lag is a symptom of a much bigger problem. And it might be hardware >>related and that has been hinted at. >A packet is a packet. I don't buy the "but it's the hardware" excuse. See my other thread with Mike Wronski about the specifics of the problem...a packet is not just a packet...there are other issues to deal with...most significant in this situation is that its a lot of small packets. That is very difficult for a router to deal with. Yes, a 486/100 *should* be able to handle 48 ports of this if the code were decent (check out the cisco 2500's...they easily handle this much traffic with a much less powerful cpu), but it may be so insideous that its easier just to scrap the whole ComOS code base and do their own...as they've done with Pilgrim. That, however, doesn't explain the collosally stupid decision *not* to support Pilgrim on the NETServer...that is, unless the Pilgrim code is as inefficient in packet handling, so it would run into the same problems that the NETServer does in this case. I doubt that's the case though since the ARC's seem to be handling many DSP's without problem from reports that I've heard. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 09:03:13
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bolen >Sent: Tuesday, November 17, 1998 2:30 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) v.90 connect problems > > >"Brian K McIntire" <bmcintire@commnet.com> writes: > >> is related to some setting your chassis. I've seen this a >thousand times on >> a thousand different AOL chassis. > >Just for a minor counterpoint, on most of our chassis using >Channelized T1 spans, we don't really see all that much of a >difference. The difference I'm referring to is not just in performance but reliability and sometimes, on ease of turn up. On PRI's you do run this risk of losing an entire span whenever a d-cannel goes down. Just another argument for Backup D. One advantage, however insignificant to someone as experienced as you, is normal customer's who do not understand the intricacies of T1's and PRI do not have to fight the Telco's as much. Telco's all across the United States are notorious for screwing up. Especially on initial turn up. This may not be an issue for you since you give each telco a detailed spec of exactly what you want and know how to work with them if it doesn't happen. What about these other guys on this list? The one who have one or two chassis who are just getting started. There are some very intelligent people on this list but many have no idea what a T1 or a PRI is much less how to troubleshoot problems. (Hence, the need for the list) Fact is, in my experience, there are considerably more things the telco could screw up on a T1 than on a PRI. By nature of setup there should be no padding on a PRI. I've seen Telco's do it, but there should be none. All over the US Telco's usually through padding on without thinking twice. On T1's, no matter how many times you tell a telco you need Channelized T1, I've seen them turn it up with all the provisioning wrong. Or the damn thing is going through an additional analog to digital conversion. You won't see a channel bank on a PRI! Even a complete moron wouldn't put a T1 through a channel bank and call it a PRI. >In fact, since telcos often rob bits even within short >call distances, the fact that the Channelized T1 implies a robbed bit >doesn't necessarily hurt all that much - often the PRI's don't even >bring an advantage to the 56K protocols like x2 or V.90. (For >example, calling to a local T1 in my office gets me the same >connections as calling a PRI located only about 10 miles west of me, >and both connected to the same telco). > >Of course, it is important how you configure your T1's - specifically >the signaling. If you opt for ground or loop start (we've only ever >used ground), you're much more likely to have issues and I'm more >likely to agree with your point, but not because of the digital T1 >span itself. It's because in virtually all cases, the telco is going >to provision that at the concentrator end with a series of analog >copper pair circuits feeding from their switch into a channel bank >that handles the T1 framing. In such a configuration you really have >an extra analog hop, individual pairs that can go bad, etc, and what >you're hurt by is the central office configuration. Definitely > >But an E&M configuration is almost always the opposite - digital >straight into the switch Again, assuming your telco knows what the hell they are doing. > - and in my experience behaves just as nicely >as a PRI circuit and very closely even to the call rates achieved. > >> PRI's, by design, are superior to T1's > >Pedantic point - unless you are at an international site using E1's, a >"PRI" _is_ a "T1" fundamentally. Same framing. It's the signaling that >is different, so you need to qualify the T1 as, for example, >Channelized with E&M signaling. > See above notes. Again, you are assuming I'm discussing nothing but throughput or connect speeds. >> and have significantly less things that could go wrong (assuming your >> provisioned has any notion of what he is doing) It was probably your T1. > >Heh - try to tell that to someone trying to troubleshoot D channel >signaling or getting the non-standard "service message" support to >work everywhere. PRI's aren't automatically better in all >circumstances ;-) How often do you have to troubleshoot d-channel signaling? What percentage of chassis on your network require you to troubleshot d-channel signaling each month? I had several thousand chassis I was responsible for working on. Over a period of several months I believe I may have had one or two that required real troubleshooting. The rest of the PRI problems we had were telco screw ups or problems after brown outs. As far as the non standard message goes I definitely know what you are talking about. It's a pain in the ass! > >Don't get me wrong - I love PRI's as much as the next guy, and we're >certainly using them as the standard configuration for all new >equipment, but it wasn't all that long ago when they were too >expensive in various regions and we still have a whole lot of >Channelized T1 (far preferring E&M but we've still got the occasional >ground start - economic reasons again) working in the network, and in >general behaving just as nicely as the PRI circuits. > >So I wouldn't automatically assume that a Channelized T1 configuration >has to be inferior. It can be configured wrong (but so can a PRI) and >it can have different types of failures than a PRI, but it can also >work just as well. See above. David, I appreciate your enthusiasm. In fact, I love it. Your experience with this equipment is unique and everything but uninformed. However, you must remember, when you are posting to this list you are talking to a tremendous number of people no where near as informed as you. They experience different kinds of problems from sheer lack of experience and understanding. Again, I say, stop assuming your situation applies to everyone else. It doesn't! Brian > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) New Hiper ARC service release
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 09:05:15
Is there a way to get a list of what hasn't been fixed yet? >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski >Sent: Tuesday, November 17, 1998 3:21 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) New Hiper ARC service release > > > > >|-----Original Message----- >|From: owner-usr-tc@lists.xmission.com >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Andrews >|Sent: Tuesday, November 17, 1998 2:52 PM >|To: usr-tc@lists.xmission.com >|Subject: Re: (usr-tc) New Hiper ARC service release >| >| >|Is there a list of what's changed between 4.1.78 and 4.1.72? >| > >All changes are noted in the PDF's on totalservice. The list shows >the delta from >4.1.11 >All fixes in 4.1.78 are in there. > >-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) Corresponding modem is unavailable
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 09:31:57
Not sure if someone answered this for you yet. I have seen this many times. Are you running PRI or T1? Check the Line Interface Options/Line Interface source. Make sure it is set to T1tdm or PRItdm depending on what kind of circuit you have. Save it to NVRAM and reboot the quads ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau >Sent: Wednesday, November 18, 1998 1:46 PM >To: USR Total Control Mailing list >Subject: (usr-tc) Corresponding modem is unavailable > > > >Quad modem chassis running 4.2.1 on T1 card (running channelized T1's) >modem cards running 5.10.9, HiPer ARC 4.0.29, NMC running 5.5.5 > >When doing a DS0 performance monitor, the DS0 channels show idle, but the >modem connected to the DS0 status is "corresponding modem is unavailable." > >I've tried restoring the chassis from defaults, and resetting everything, >to no avail. Has anyone seen this before?? > >-------------------------------------------------------------------------- >| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | >| Executive Vice President - Exec-PC, 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) Corresponding modem is unavailable
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 09:31:57
Not sure if someone answered this for you yet. I have seen this many times. Are you running PRI or T1? Check the Line Interface Options/Line Interface source. Make sure it is set to T1tdm or PRItdm depending on what kind of circuit you have. Save it to NVRAM and reboot the quads ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau >Sent: Wednesday, November 18, 1998 1:46 PM >To: USR Total Control Mailing list >Subject: (usr-tc) Corresponding modem is unavailable > > > >Quad modem chassis running 4.2.1 on T1 card (running channelized T1's) >modem cards running 5.10.9, HiPer ARC 4.0.29, NMC running 5.5.5 > >When doing a DS0 performance monitor, the DS0 channels show idle, but the >modem connected to the DS0 status is "corresponding modem is unavailable." > >I've tried restoring the chassis from defaults, and resetting everything, >to no avail. Has anyone seen this before?? > >-------------------------------------------------------------------------- >| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | >| Executive Vice President - Exec-PC, 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) Solution for idle time limits and dual logins
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 09:35:35
It's not a matter of can't be done. It's a matter of Can we make it better? The answer is yes. So lets do it. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Wednesday, November 18, 1998 2:05 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Solution for idle time limits and dual logins > > >Thus spake Mike Wronski >>I don't have a good answer for that. Idle-timeouts are only usefull >>against the >>non-savy user and those are getting fewer by the day. > >>So what do you count as activity that should reset the idle timer? > >Ideally, this should be administrator configurable...a filter list would >be perfect. > >>No matter what you define as idle, someone will come up with a >way to use data >>you don't check to keep the channel open.. I can think a simple >way to use HTTP >>gets to keep the line open.. I think you are fighting a battle >that cant be >>won.. >>The user who wants to, will nail their connection up.. A resonable >>session limit >>may be your only hope. > >Oh, so if you can't provide a *perfect* tool, then you won't give us >*any* tools to work with at all. Thanks a lot there! > >You've obviously never run as ISP. Using the current filter rule setup >to define what traffic resets the idle timeout, I could define a filter >of about 5 to 10 lines that would eliminate 99.9% of our problems with >people camping on lines. Yes, there will be users that will work around >it, its not a perfect solution, but then again, RADIUS isn't a perfect >solution for authenticating users the way everyone needs either, so why >do you support RADIUS? > >>I think the configurable idle timeout filter sounds like a good >idea until you >>really look at its implementation and wheather it will even do what >>you want. > >I *KNOW* it'll do what I want because I've used a pppd in the past that >supported this sort of thing and it worked like a charm! > >>It >>would work for a short time and then the users will figure out a way >>around it. I >>think there are many other features that time & resources could be spent >>developing that would benefit the ISP more than this. > >There are plenty of features that you could develop that would benefit >us greatly...let's come up with a list and I'll rank them how I feel >they would be most useful to us. I guarentee you that idle-timer filter >list would be *very* high up there. >-- >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) Confirmation
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-19 09:37:07
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam |Sent: Wednesday, November 18, 1998 8:25 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Confirmation | | |Pete Ashdown was heard to say: |>>This seems to be broken on current ARC releases up to and including at |>>least 4.1.78; you have to also use "Max_Channels = 1" (which is a VSA) to |>>do the right thing there. On the NETserver, it's fine. Go back through |>>the archives a month or two and you can see me whining away about this :) |>>We actually have both Port-Limit AND Max_Channels in the Radius users |>>file. That seems to take care of things. |> |>According to the fix documentation, 4.1.72 follows the RFC on this. Does |>anyone know if that returns things to normal? ;-) | |What fix docs? There wasn't anything in the zip file. | There on the web site.. Next to the link for the code.. -M
Subject: (usr-tc) Re: your mail
From: Dominic Ciresi <dciresi@defunct.ae.usr.com>
Date: 1998-11-19 09:47:08
Brian, This is a known bug. There is a fix in SAS 6.0.92.(Solaris) or SAS 6.0.91 (HP). Open a ticket and I will deliver code to you. Dominic On Thu, 19 Nov 1998, Brian K McIntire wrote: > This is directed to anyone out there who may be using Secure-ID with TC S/A > for Unix. We have installed S/A 5.5.4 and secure-id works fine. With the > same config on 6.0.7 it doesn't. The debug is useless. All it says is > invalid pass code. We down grade back to 5.5.4 it works again. Any ideas? > Is this a known bug? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) using round robin & fixed assignment
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 09:58:00
The time to reset a b-channel at Telco by default is probably close to 20 ms. This time can be changed. The key is knowing precisely how long is the perfect time. This would be easy to find out with experimentation and statistics. Talk to your telco about it. I would be very interested to find out what your research uncovers. ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Taino d Johnston >Sent: Wednesday, October 14, 1998 5:23 PM >To: usr-tc@lists.xmission.com >Subject: (usr-tc) using round robin & fixed assignment > > >We recently switched telcos, which then switched us from channelized T1 >lines to PRI lines. The telco switch was from PacBell to ICG. Upon >switching we found ourselves facing a lot of problems, however, it was this >last problem that we felt was quite strange and worth noting. > >In order to do some tests with the new service, we changed the >configuration of our equipment from 'round robin' to 'fixed assignment'. >After we thought the experienced problems were corrected we started getting >reports of busy signals -- during time periods when there were modems >available. The problem turned out to be that the PRI lines were resetting >faster than our modems were. Essentially, this meant calls would be routed >back down to a newly opened line on the PRI but would hit a modem that had >not been reset. Our testing found that we were giving busy signals out >about 20% of the time. Switching back to 'round robin' seems to have since >corrected the problem and we have not given out any more busy signals. > >What I am trying to find out is why when configured for 'fixed assignment' >we were giving out busy signals? The problems went away once we switched >to 'round robin'. > >We are running a few TC chassis containing Quad Digital & Digital/Analog >modem cards with PRI lines. All our Quad modem cards, NETserver PRI cards, >Dual PRI cards and NMC cards are running the current versions of the >software. > >Taino Johnston >Manager, Technical Support >Access Internet Communications > >+----------------------------------------------------------------+ >| Taino d Johnston | Phone: (408) 777-8190 | >| Manager, Technical Support | Tech Support: (408) 342-0551 | >| | Fax: (408) 777-8191 | >| Access Internet Communications | http://www.accesscom.com/ | >| tdj@accesscom.com | support@accesscom.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) Corresponding modem is unavailable
From: Curt Shambeau <curt@execpc.com>
Date: 1998-11-19 10:12:30
Already checked. I'm running Ch.T1's, and it's set to the T1tdm bus.
Subject: (no subject)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 10:14:59
This is directed to anyone out there who may be using Secure-ID with TC S/A for Unix. We have installed S/A 5.5.4 and secure-id works fine. With the same config on 6.0.7 it doesn't. The debug is useless. All it says is invalid pass code. We down grade back to 5.5.4 it works again. Any ideas? Is this a known bug?
Subject: RE: (usr-tc) Corresponding modem is unavailable
From: Curt Shambeau <curt@execpc.com>
Date: 1998-11-19 10:30:19
> What slot is your T1 card in? You may have some troubleshooting ahead. Try > pulling every card out of the chassis except 1 quad and the t1 and try it > again. If it maps correctly put one card at a time back into the chassis > until it stops working. Once it stops working you have probably found a bad > card Hadn't thought of that... Thanks, I'll give it a try. The T1 card is in the first slot of the chassis. It was actually a brand new Quad chassis that I put an ARC into (trying to get all the netserver's out of the network). | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |
Subject: RE: (usr-tc) Corresponding modem is unavailable
From: Curt Shambeau <curt@execpc.com>
Date: 1998-11-19 10:30:19
> What slot is your T1 card in? You may have some troubleshooting ahead. Try > pulling every card out of the chassis except 1 quad and the t1 and try it > again. If it maps correctly put one card at a time back into the chassis > until it stops working. Once it stops working you have probably found a bad > card Hadn't thought of that... Thanks, I'll give it a try. The T1 card is in the first slot of the chassis. It was actually a brand new Quad chassis that I put an ARC into (trying to get all the netserver's out of the network). | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |
Subject: RE: (usr-tc) Archives?
From: blann_firestone@3com.com
Date: 1998-11-19 10:40:21
>They were at http://usr-tc.datasys.net, but it looks like it hasn't been >updated and the search and index features have gone away... > >Charles The archives are available at: http://www.xmission.com/pub/lists/usr-tc/archive/ Latest posts are at the bottom of the page. Blann - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) using round robin & fixed assignment
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 10:59:15
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bolen >Sent: Wednesday, November 18, 1998 5:25 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) using round robin & fixed assignment > > >Taino d Johnston <usr-list@accesscom.com> writes: > >> What I am trying to find out is why when configured for 'fixed >assignment' >> we were giving out busy signals? The problems went away once we switched >> to 'round robin'. > >It's a software bug - well, I consider it as such. > >What happens is that when the call release message comes down the PRI >D channel, the PRI card informs the modem which tears down the call. >However, the PRI immediately acknowledges the release message without >waiting for the modem to indicate it has finished resetting. The >problem is that the modem takes time to completely reset and be >prepared for a new call (in some releases up to perhaps 250ms or >more). During that time the telco thinks that the B channel is idle >and may immediately send down a new call - especially if this is a >busy hunt group and the channel is low in the group and the telco is >itself using ascending hunting within the group. > >The PRI gets the call, tries to signal the modem over the packet bus >and one of two things happens: > > * The modem isn't ready at all, and the PRI times out in the > configuration step for a new call trying to talk to the modem. > the configuration step for the new call. The result is a delay to > the user followed by a busy when the PRI finally gives up. If > enabled, the PRI should generate a callTermFailedEvent trap for > this call. > > * The modem is sort of ready but not fully - it acknowledges the PRI > indication, but when it gets ahold of the call can't properly > process it and the user perceives dead air. If enabled, the modem > should generate a DteRingNoAns trap for this call. > >You can also see the counts of these sorts of failures on some of the >PRI debug summary screens for modem errors. > >Why this tends to happen more on PRI than CT1 is probably a >combination of the faster and out-of-band signaling for call setup and >teardown, and the way in which the PRI communicates to modems OOB over >the packet bus for call setup as opposed to using TDM bus patterns for >the CT1 code, both of which affect the general setup and teardown >timing sequence during call processing. > >The reason that changing to round-robin allocation "fixes" this >problem (in many cases) is that the newer call is not going to try to >hit the same modem, but one of the two "idle" modems (on a T1). So >instead of a limiting factor of the reset time of a single modem for >your call cycle time, you have divided that time by 3 (worst case). >Normally unless you lose several calls simultaneously, this is enough >to avoid the problem. > >Having the telco distribute calls over your entire hunt group in a >statistical fashion (or even round-robin) can help too, but not once >the hunt group gets full or very busy since it's still likely to pick >the B channel just released for the next call. > >The round robin selection also isn't a possibility in typical E1 >configurations since in that case you don't have the automatic buffer >modems. > >We had terrible problems with this at our E1 sites, and actually had >to remove 4 B channels from service to give ourselves enough of a >"buffer" to handle the call load. > >The "fix" (which doesn't require round-robin) is to both have the >modem reset more quickly (at least to the point where it can start >accepting new call information) as well as have the PRI wait for the >modem to say it is done before acknowledging the release message from >the telco. True, the PRI does have some hard timing limits within >which it must acknowledge the message according to the D channel >protocol, but there's room in there to wait for the modem in most >cases. The "fix" may not be to wait for software features. Although the suggestion you mention above sounds like it would work better than what I'm going to suggest. The amount of time it takes to the telco to reset their side can be tailored to your specifications depending on the equipment the telco uses. Try experimenting with it by having the time to reset changed to 250ms. I believe the telco can adjust up to 1200ms. I may be wrong. > >I can't speak to the general availability of such a fix or not, but it >is possible. Of course, switching to round robin (for most T1 >configurations) is generally pretty effective too. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Solution for idle time limits and dual logins
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 11:03:09
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Wednesday, November 18, 1998 7:07 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Solution for idle time limits and dual logins > > >Thus spake Mike Wronski >>|Oh, so if you can't provide a *perfect* tool, then you won't give us >>|*any* tools to work with at all. Thanks a lot there! > >>I don't provide anything but support for the product. People at >higher levels >>have to wade through all the possible features and some fall out >in favor of >>others. > >Oh, believe me, I understand that...but please understand that we've >gotten the run-around on features before. :) > >>Its just not possible to make a product everyone is in love with.. I >>don't know for certain, but do any other vendors have this feature? I >>don't think >>we are unique here. > >I've not seen any NAS vendors that do, but as I mentioned previously, >I've used a pppd (Morningstar) that had this feature and it was a >*wonderful* feature to have. > >>Agreed, but what is the alternative to RADIUS? TACACS? Is MS >Anything perfect? >>nope. What do most people use?? >>With that logic: I think LINUX is better than MS. Should I not >support MS even >>though its the defacto standard. > >You, of course, have a point...RADIUS is the best thing out there for >doing this... However, you see my point as well, right? We, the >customers need tools to be able to make our networks work the best we >can, and we're getting you (and I don't mean this to be a slam on you >personally...I'm *glad* you're responding to these postings) telling us >that our desires for features that we want are wrong. :) You can see >how that would be a little bit grating. :) > >As I said...I've used this feature before, on a UNIX based pppd and it >was wonderful to have...I'd like to be able to do this on a NAS too. :) > >>I now expect a jump off the bridge reply from someone.. And >>"No I wouldn't do it just because all my friends did! :)" > >Blah...I've always thought that was a stupid argument. :) > >>|There are plenty of features that you could develop that would benefit >>|us greatly...let's come up with a list and I'll rank them how I feel >>|they would be most useful to us. I guarantee you that idle-timer filter >>|list would be *very* high up there. > >>You should do that. Put don't post it here. It is far more effective when >>submitted formally as a Feature Request/CRA and submitted by many >people. > >Hey, I'm more than happy to submit it through formal channels...but >let's also consider this as a possible discussion ground for what those >features that we request might be. Perhaps we could all work on a list Absolutely. Lets get a list going on features we would like to see and get it into the hands of someone who can make a decision. If it's a money issue, I'm sure most customer's would pay a "little" more for a feature rich RADIUS. >together and could use that as a base for features that we'd all like to >see put in, and possibly augment that with our own individual requests. >:) > >>(OSPF flame expected here.. Don't >>bother! I know its been a long time coming...But.. its >coming...Really....No >>fooling...Its not vaporware...) > >Heh...wasn't gonna be a flame, but it *was* gonna get mentioned. :) I >know its coming...is it 4.1.72 perchance? I thought I had heard some >talk of it being available in ER's/SR's, but perhaps I'm just imagining >things. > >>I do my best to respond to issues on this list and have no desire >to fight with >>anyone over feature sets.. > >Please, your input is greatly appreciated...and you pointed out a very >real limitation on why this would be a difficult thing to implement >(idle-timer is reset before the IP header is even parsed)...that's very >understandable. At least when I go talk to Tom Goodman I'll understand >if it doesn't show up in the very next release. :) >-- >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) Corresponding modem is unavailable
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 11:17:28
What slot is your T1 card in? You may have some troubleshooting ahead. Try pulling every card out of the chassis except 1 quad and the t1 and try it again. If it maps correctly put one card at a time back into the chassis until it stops working. Once it stops working you have probably found a bad card ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau >Sent: Thursday, November 19, 1998 10:13 AM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) Corresponding modem is unavailable > > >Already checked. I'm running Ch.T1's, and it's set to the T1tdm bus. > >-------------- > >> Not sure if someone answered this for you yet. >> I have seen this many times. Are you running PRI or T1? Check the Line >> Interface Options/Line Interface source. Make sure it is set to T1tdm or >> PRItdm depending on what kind of circuit you have. Save it to NVRAM and >> reboot the quads >> >> ======================================================================== >> = Brian K. McIntire bmcintire@commnet.com = >> = Systems Engineer III 317-558-5050 x113 = >> = CommNetPlus, Indianapolis, IN http://www.commnet.com = >> = Your Remote Access and Security Experts! = >> = Firm partnerships est. with current and emerging leaders of today's = >> = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = >> = Serving North America and parts of Canada. Reselling to the world. = >> ======================================================================== >> >> >> >-----Original Message----- >> >From: owner-usr-tc@lists.xmission.com >> >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau >> >Sent: Wednesday, November 18, 1998 1:46 PM >> >To: USR Total Control Mailing list >> >Subject: (usr-tc) Corresponding modem is unavailable >> > >> > >> > >> >Quad modem chassis running 4.2.1 on T1 card (running channelized T1's) >> >modem cards running 5.10.9, HiPer ARC 4.0.29, NMC running 5.5.5 >> > >> >When doing a DS0 performance monitor, the DS0 channels show >idle, but the >> >modem connected to the DS0 status is "corresponding modem is >unavailable." >> > >> >I've tried restoring the chassis from defaults, and resetting >everything, >> >to no avail. Has anyone seen this before?? >> > >> >>-------------------------------------------------------------------------- >> >| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > >| Executive Vice President - Exec-PC, 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. > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, 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) Interested in Linux on the Netserver?
From: Matthew Opoka <phantom@magnolia.net>
Date: 1998-11-19 11:17:50
I tell you what. I get better quake on a livingston portmaster 2e and an anolog modem attach than I do on a netserver 486 with pri lines. The portmaster has an AMD 386 DX40. Jeff Mcadams wrote: > > Thus spake Ricky Beam > >Allen Marsalis was heard to say: > >>Lets say you get USR to cooperate (1st feat). Then you get linux up > >>on the netserver (2nd feat). What if Quake still lags? I mean Quake > >>Lag is a symptom of a much bigger problem. And it might be hardware > >>related and that has been hinted at. > > >A packet is a packet. I don't buy the "but it's the hardware" excuse. > > See my other thread with Mike Wronski about the specifics of the > problem...a packet is not just a packet...there are other issues to deal > with...most significant in this situation is that its a lot of small > packets. That is very difficult for a router to deal with. Yes, a > 486/100 *should* be able to handle 48 ports of this if the code were > decent (check out the cisco 2500's...they easily handle this much > traffic with a much less powerful cpu), but it may be so insideous that > its easier just to scrap the whole ComOS code base and do their own...as > they've done with Pilgrim. That, however, doesn't explain the > collosally stupid decision *not* to support Pilgrim on the > NETServer...that is, unless the Pilgrim code is as inefficient in packet > handling, so it would run into the same problems that the NETServer does > in this case. I doubt that's the case though since the ARC's seem to be > handling many DSP's without problem from reports that I've heard. > -- > 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) hiperarc NAS-Port-Id
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-19 11:23:26
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Laszlo Vecsey |Sent: Thursday, November 19, 1998 11:08 AM |To: usr-tc@xmission.com |Subject: (usr-tc) hiperarc NAS-Port-Id | | |With 4.1.72 on the hiperarc, theres an improvement with the NAS-Port-Id |output (used to all be set to 1), but I think theres still a glitch: | | NAS-Port-Id = 1539 | NAS-Port-Id = 1028 | NAS-Port-Id = 1793 | NAS-Port-Id = 1026 | NAS-Port-Id = 514 | NAS-Port-Id = 1793 | NAS-Port-Id = 1794 | NAS-Port-Id = 912469510 | NAS-Port-Id = 1795 | NAS-Port-Id = 1796 | NAS-Port-Id = 258 | NAS-Port-Id = 2049 | Can you show the entire record the Odd entry came from?? GNU GREP with -A 3 -B 3 ??? -M
Subject: RE: (usr-tc) Interested in Linux on the Netserver?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-19 11:24:08
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Matthew Opoka |Sent: Thursday, November 19, 1998 11:18 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Interested in Linux on the Netserver? | | |I tell you what. |I get better quake on a livingston portmaster 2e and an anolog modem |attach than I do on a netserver 486 with pri lines. The portmaster has |an AMD 386 DX40. How many ports?? -M
Subject: (usr-tc) hiperarc NAS-Port-Id
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-11-19 12:08:16
With 4.1.72 on the hiperarc, theres an improvement with the NAS-Port-Id output (used to all be set to 1), but I think theres still a glitch: NAS-Port-Id = 1539 NAS-Port-Id = 1028 NAS-Port-Id = 1793 NAS-Port-Id = 1026 NAS-Port-Id = 514 NAS-Port-Id = 1793 NAS-Port-Id = 1794 NAS-Port-Id = 912469510 NAS-Port-Id = 1795 NAS-Port-Id = 1796 NAS-Port-Id = 258 NAS-Port-Id = 2049 That was a sample grep from my detail file. Every now and then theres an oddball entry.. ?
Subject: Re: (usr-tc) RADIUS 6.0.8: Authentication into NT Domain creates errors
From: Dominic Ciresi <dciresi@defunct.ae.usr.com>
Date: 1998-11-19 13:49:57
Ralph, There is as yet no way to uncheck the script debugging feature in SAS 6.0.8. The workaround is to edit your \<windows>\radius.ini, and change the value for "ScriptLog" to 0. Unfortunately, you will have to do this every time before restarting the server. Dominic On Tue, 17 Nov 1998, Ralph Helfenberger wrote: > Hi all > > I try to setup 3COM RADIUS Server to authenticate all users, wich are > not found in the RADIUS database, in the NT Domain. For that reason I'm > working with the template NTUSER. The problem I encounter: There are > script errors in the logfile. Has anyone done something similar? > > RADIUS 6.0.8 > > Script Section: CHECK-PASSWORD nLine: 534 bIgnore: 0 > Script Section: VALIDATE-LOCALPASSWD nLine: 3345 bIgnore: 0 > Trace: Attempting User: Tinu-H, Domain: LEO-DOMAIN [11 17 18:44:40] > Script Section: CHECK-EXPIRATION nLine: 535 bIgnore: 0 > Script Section: CHECK-CALL-SOURCE nLine: 542 bIgnore: 0 > Script Section: CHECK-TUNNEL-NAME nLine: 547 bIgnore: 0 > Script error on line 1781 :Variable (THISGROUP) not found > Line is : if(length(thisGroup)>0) > > Script error on line 1781 :Parameter has a bad value > Line is : if(length(thisGroup)>0) > > Script Section: COLLECT-USER-RESPONSE nLine: 549 bIgnore: 0 > Script Section: GET-STANDARD-ATTRIBUTES nLine: 671 bIgnore: 0 > Script Section: GET-USER-SERVICE-TYPE nLine: 7257 bIgnore: 0 > Script Section: GET-STANDARD-FRAMED-ATTRIBUTES nLine: 7276 bIgnore: 0 > Script Section: GET-FRAMED-PROTOCOL nLine: 7319 bIgnore: 0 > Script error on line 2696 :Variable (THISGROUP) not found > Line is : if(length(thisGroup)>0) > > Script error on line 2696 :Parameter has a bad value > Line is : if(length(thisGroup)>0) > > Script Section: GET-FRAMED-ADDRESS nLine: 7320 bIgnore: 0 > Script error on line 2753 :Variable (THISGROUP) not found > Line is : if(length(thisGroup)>0) > > Script error on line 2753 :Parameter has a bad value > Line is : if(length(thisGroup)>0) > > Script error on line 2769 :Variable (THISGROUP) not found > Line is : if(length(thisGroup)>0) > > Script error on line 2769 :Parameter has a bad value > Line is : if(length(thisGroup)>0) > > Script Section: GET-FRAMED-NETMASK nLine: 7321 bIgnore: 0 > Script error on line 2785 :Variable (THISGROUP) not found > Line is : if(length(thisGroup)>0) > > and so on.... > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) 1.2.68 Warning! Please read.
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-11-19 13:54:31
We are looking into issues with 1.2.68 (and .67, .66, .65, and .64) causing problems on some T3 muxes. There is not an issue on 1.2.5 or engineering releases numbered above 1.2.68. It also does not appear to be an issue in E1 codebases. The issue seems contained to certain muxes, but is serious enough when it does happen, that I highly recommend not using those releases on any chassis that don't already have it until we completely nail this issue and issue a patch. If you are already using one of them, and are not experiencing problems, there is no need to back them off, this is not a problem that creeps up. Your spans either have a problem with it, or they don't. So, if you have 1.2.68 (that one is out there in large quantities), please use great care and I do not suggest you expand its' use at all. Regards, JP
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-19 14:07:48
Thus spake Mike Wronski >|I tell you what. >|I get better quake on a livingston portmaster 2e and an anolog modem >|attach than I do on a netserver 486 with pri lines. The portmaster has >|an AMD 386 DX40. >How many ports?? A 2e has 30. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) padding on trunk groups
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 16:09:13
Please forgive the following "book" I'm faced with a problem. I'm working for a customer in an Ameritech region. When ever I place a call with my courier to a PRI I see a 6db pad being applied to my receive. (The PRI's transmit) I've been told there has to be a 6db pad applied because Ameritech has not installed echo cancellation in their telephone network. Makes some sense. I have further been told echo cancellation is not currently accepted as a standard but where ever it has been installed telephone companies remove the 6db pad my client modem see's on the receive. I understand there needs to be echo cancellation to go from a 4 to 2 wire. (PRI to analog) If not there needs to be a pad. Does anyone have a different opinion or know something different. Is there a way around this? (Probably not) If not does anyone know if using echo cancellation will become a standard? The bottom line is, I have some customer's that connect at higher speeds than others because of who their local telephone company is. The PRI I'm working on is set up to be a local # for several cities with different switches. One of the cities that dial this PRI applies no padding. The others do. The problem is my customer's main competition is centrally located in the local loop of the telco that does not pad. His customer's are being called by his competition and given a chance to call a non-padded PRI for free to prove their connect speeds will be better and steal customers. Of course, connect speeds are always better when you compare padded against non-padded. Any positive ideas? By the way, here's an interesting quirk. When I dial the PRI that goes to our internal lab chassis from a trunk off a non-padded T1 being provided by the same telco I see no pad and connect at 50666. When I dial AOL's local # (PRI's being provided by the same telco) I see 6db padding and connect at 49333 or 48000. When I dial either from home (from a different phone company "Ameritheft") I connect at 45333 or lower. Sometimes I don't even connect at v.90. I see 37333 quite often. David, do you have any comments on this. The AOL chassis here are yours. ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = = = Our experienced technicians can design and install your high speed = = network for you. From Operating Systems and servers to routers and = = firewalls nobody does it better than CommNetPlus. Our Technical = = Support staff is available to you 24 hours a day to meet your needs.= = Offering remote management and monitoring packages for dedicated = = clients. (Specializing in ISP's). "Let us do the work for you!" = = = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ========================================================================
Subject: (usr-tc) FYI: 1.2.66 & PRI errors
From: Jerry Kalligonis <jerryk@blazenet.net>
Date: 1998-11-19 16:59:10
I just wanted to share a fun <grin> day I had with my DSP cards yesterday. At one particular location I have a good many PRI's. I was running the 1.2.5 code, but had heard good things about the newer patch from other posts on this list. I upgraded 1 of my chassis' and tested @12am and everything seemed to be OK. After finishing the rest of the chassis' I did some testing and everything seemed fine. About 1 half hour later ALL of my PRI's appeared to drop. I immediately called the telco and they reported to me that the T3 that feeds us our PRI's had dropped and they were looking into it. I pulled 5 of my PRI's out of a chassis and the T3 came back up. I put them back in and it took the T3 down. Anyway, after hours of trouble shooting and no help from 3com, we found that the new code puts out a certain level of errors onto the PRI line. When enough of these PRIs are combined the error level is enough to bring down a T3. Of course later that afternoon I got a call back from 3com saying, sorry I couldn't get back to you this morning, but engineering says there may be a problem with this code that puts out enough errors to take down a T3. Call back to get DSP code 1.2.64 I haven't gotten the code yet, but I'll pass on the info when I try it.... Jerry Kalligonis
Subject: Re: (usr-tc) v.90 connect problems
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-19 17:24:39
Brian K McIntire writes... >The difference I'm referring to is not just in performance but reliability >and sometimes, on ease of turn up. On PRI's you do run this risk of losing >an entire span whenever a d-cannel goes down. Just another argument for >Backup D. This is stupid. The probability of losing a D channel is miniscule compared to losing the span to something like a looped repeater. When this happens having a backup D channel will make you very, very sorry as your calls dissapear down a black hole. -a
Subject: Re: (usr-tc) FYI: 1.2.66 & PRI errors
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-19 17:31:39
Jerry Kalligonis writes... >At one particular location I have a good many PRI's. I was running the >1.2.5 code, but had heard good things about the newer patch from other >posts on this list. > > . . . > >Anyway, after hours of trouble shooting and no help from 3com, we found >that the new code puts out a certain level of errors onto the PRI line. >When enough of these PRIs are combined the error level is enough to bring >down a T3. > >Of course later that afternoon I got a call back from 3com saying, sorry I >couldn't get back to you this morning, but engineering says there may be a >problem with this code that puts out enough errors to take down a T3. Call >back to get DSP code 1.2.64 You didn't mention what version the "newer patch" was that cause these problems for you. I was having trouble with false alarms coming from my DSP cards which version 1.2.68 fixed. -- Aaron Nabil
Subject: RE: (usr-tc) Interested in Line on the Netserver?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 17:52:20
The fact that the 2e supports only 30 may partially explain how it can handle things a little better. It doesn't have to do the work the USR NetServer does >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Thursday, November 19, 1998 1:08 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Interested in Linux on the Netserver? > > >Thus spake Mike Wronski >>|I tell you what. >>|I get better quake on a livingston portmaster 2e and an anolog modem >>|attach than I do on a netserver 486 with pri lines. The portmaster has >>|an AMD 386 DX40. > >>How many ports?? > >A 2e has 30. >-- >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) Re: your mail
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 17:56:35
Thanks for the info Dominic. I upgraded to the code you specified. This time it doesn't work at all. Instead of seeing the error message incorrect passcode the RADIUS isn't even communicating with Secure ID. Any other Ideas. Debug was useless. All it showed was requests going out that were un- answered. Again, when I down graded back to 5.5.4 it worked like a charm. ======================================================================== = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Your Remote Access and Security Experts! = = Firm partnerships est. with current and emerging leaders of today's = = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================== >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dominic Ciresi >Sent: Thursday, November 19, 1998 9:47 AM >To: usr tc >Subject: (usr-tc) Re: your mail > > >Brian, >This is a known bug. There is a fix in SAS 6.0.92.(Solaris) or SAS 6.0.91 >(HP). Open a ticket and I will deliver code to you. > >Dominic > >On Thu, 19 Nov 1998, Brian K McIntire wrote: > >> This is directed to anyone out there who may be using Secure-ID >with TC S/A >> for Unix. We have installed S/A 5.5.4 and secure-id works fine. > With the >> same config on 6.0.7 it doesn't. The debug is useless. All it says is >> invalid pass code. We down grade back to 5.5.4 it works again. >Any ideas? >> Is this a known bug? >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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) PPTP on HiPer ARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 18:02:22
I'm trying to set up PPTP on a HiPer ARC. The Tunnel will be going to an NT SERVER that is used for PPTP from several NETServers. The NETServers work fine. I followed the instructions outlined in the HiPer ARC manual. When I list PPTP tunnels I don't see anything. I'm sure many of you have done this. Can you tell me precisely what steps I need to take to configure this properly? thanks
Subject: Re: (usr-tc) Re: your mail
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-19 18:07:09
Brian K McIntire was heard to say: >Thanks for the info Dominic. I upgraded to the code you specified. This >time it doesn't work at all. Instead of seeing the error message incorrect >passcode the RADIUS isn't even communicating with Secure ID. Any other >Ideas. Debug was useless. All it showed was requests going out that were >un- answered. Again, when I down graded back to 5.5.4 it worked like a >charm. Ok, so try this... copy the bin/session from 5.5.4 to bin/saworker for 6.0.whatever and see if that makes any difference at all. That's what the server runs to handle authenticating with ACE. As far as I'm aware, other than the name change, there is no difference between the two? --Ricky
Subject: RE: (usr-tc) v.90 connect problems
From: David Bolen <db3l@ans.net>
Date: 1998-11-19 18:23:55
"Brian K McIntire" <bmcintire@commnet.com> writes: > The difference I'm referring to is not just in performance but reliability > and sometimes, on ease of turn up. Oh, I thought the topic was "V.90 connect problems", but the points are pretty much the same for reliability too. > Fact is, in > my experience, there are considerably more things the telco could screw up > on a T1 than on a PRI. All I've offered is some counterpoints from my own experience (with tens of thousands of circuits all over the world of all types). It may not agree with your experience, and that's fine, but would you disagree that it should be just as valid a set of experience for the purposes of discussion? I agree that telcos can and do foul things up and it's generally more likely to occur during initial setup than any other stage of the process. With that said, I can't honestly say that we get more foul ups with CT1 configurations than with PRI - ignoring for the moment ground/loop start CT1, which I don't recommend people order (and I don't consider such a caveat beyond the average ISP engineer). BTW, it's fairly common for misconfigurations during initial PRI setups when it comes to configuring the switch type. This is primarily because we require custom configuration for service message to work (not NI-2), but I have to believe that most providers want service messages on PRI spans - how many know they must not get the "national infrastructure" standard configuration if they want to be able to take individual B channels out of service? > >But an E&M configuration is almost always the opposite - digital > >straight into the switch > > Again, assuming your telco knows what the hell they are doing. Off the top of my head, I can't recall _ever_ getting an E&M configuration with a channel bank and copper pairs. Interestingly enough, we have occasionally seen a ground start going straight into a switch (no channel bank), but not the reverse. This is with telcos (LECs, and CAPs) all over the country. > >Pedantic point - unless you are at an international site using E1's, a > >"PRI" _is_ a "T1" fundamentally. Same framing. (...) > > > See above notes. Again, you are assuming I'm discussing nothing but > throughput or connect speeds. No, you missed my point. A PRI (domestically) _is_ a T1. Simple as that. Now, you may be meaning "channelized T1 with xxx signaling" when you write "T1", but I don't expect everyone to infer that. A PRI circuit is simply a channelized T1 (or I suppose more accurately, DS1) circuit that will have full 64Kbps clear channels and use one of those channels as a D channel for OOB signaling. But the physical circuit is still a T1 (and that's all the "term" T1 stands for - an overall capacity of a digital span using a standard framing mechanism). As I said - pedantic - but I believe in being thorough in such discussions. > How often do you have to troubleshoot d-channel signaling? If you include service messages (which are part of D channel signaling, and which I've never had a problem with their equivalent on E&M T1 circuits), then probably with a similar frequenty as we troubleshoot signaling problems on our channelized T1 E&M circuits. That is, not very much at all. > However, you must remember, when you are posting to this list you are > talking to a tremendous number of people no where near as informed as you. Strange, and here I thought I was just offering a balanced opinion, specifically in that vein :-) > They experience different kinds of problems from sheer lack of experience > and understanding. Again, I say, stop assuming your situation applies to > everyone else. It doesn't! Where did I? It seems that you offered some information based on your experience, and I offered some based on mine. Just a balanced discussion, which can only help readers of this list, no? Or are you saying that your experience/situation is more applicable to everyone else than mine? -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: RE: (usr-tc) using round robin & fixed assignment
From: David Bolen <db3l@ans.net>
Date: 1998-11-19 18:26:06
"Brian K McIntire" <bmcintire@commnet.com> writes: > The "fix" may not be to wait for software features. Well, the "fix" is definitely to fix the bug. But as you note there are other "workarounds" that may be applicable. > Although the suggestion > you mention above sounds like it would work better than what I'm going to > suggest. The amount of time it takes to the telco to reset their side can > be tailored to your specifications depending on the equipment the telco > uses. Try experimenting with it by having the time to reset changed to > 250ms. I believe the telco can adjust up to 1200ms. I may be wrong. It depends on the switch and software configuration. For our UK problem, the maximum available by the telco was 250ms and we still needed a 4-modem buffer to keep up adequately. But I agree that it is something worth trying if you are on the margin in terms of timing. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) padding on trunk groups
From: David Bolen <db3l@ans.net>
Date: 1998-11-19 18:30:40
"Brian K McIntire" <bmcintire@commnet.com> writes: > Of course, connect speeds are always better when you compare > padded against non-padded. In general, only if it's analog padding. Digital padding is automatically detected and accounted for in the 3Com x2/V.90 implementation, and I believe I've been told that holds true for V.90 for Rockwell/Lucent as well. If it's analog though, then you're out of luck since the modem has to treat it as equivalent to loss on the final leg. I don't know if you could convince Ameritech to move from one type to the other or not. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: RE: (usr-tc) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 18:44:25
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bolen >Sent: Thursday, November 19, 1998 5:24 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) v.90 connect problems > > >"Brian K McIntire" <bmcintire@commnet.com> writes: > >> The difference I'm referring to is not just in performance but >reliability >> and sometimes, on ease of turn up. > >Oh, I thought the topic was "V.90 connect problems", but the points >are pretty much the same for reliability too. > >> >Fact is, in >> my experience, there are considerably more things the telco >could screw up >> on a T1 than on a PRI. > >All I've offered is some counterpoints from my own experience (with >tens of thousands of circuits all over the world of all types). It >may not agree with your experience, and that's fine, but would you >disagree that it should be just as valid a set of experience for the >purposes of discussion? I agree > >I agree that telcos can and do foul things up and it's generally more >likely to occur during initial setup than any other stage of the >process. With that said, I can't honestly say that we get more foul >ups with CT1 configurations than with PRI - ignoring for the moment >ground/loop start CT1, which I don't recommend people order (and I >don't consider such a caveat beyond the average ISP engineer). > >BTW, it's fairly common for misconfigurations during initial PRI >setups when it comes to configuring the switch type. This is >primarily because we require custom configuration for service message >to work (not NI-2), but I have to believe that most providers want >service messages on PRI spans - how many know they must not get the >"national infrastructure" standard configuration if they want to be >able to take individual B channels out of service? Most do not > >> >But an E&M configuration is almost always the opposite - digital >> >straight into the switch >> >> Again, assuming your telco knows what the hell they are doing. > >Off the top of my head, I can't recall _ever_ getting an E&M >configuration with a channel bank and copper pairs. Interestingly >enough, we have occasionally seen a ground start going straight into a >switch (no channel bank), but not the reverse. This is with telcos >(LECs, and CAPs) all over the country. > >> >Pedantic point - unless you are at an international site using E1's, a >> >"PRI" _is_ a "T1" fundamentally. Same framing. (...) >> > >> See above notes. Again, you are assuming I'm discussing nothing but >> throughput or connect speeds. > >No, you missed my point. A PRI (domestically) _is_ a T1. Simple as >that. Now, you may be meaning "channelized T1 with xxx signaling" >when you write "T1", but I don't expect everyone to infer that. > >A PRI circuit is simply a channelized T1 (or I suppose more >accurately, DS1) circuit that will have full 64Kbps clear channels and >use one of those channels as a D channel for OOB signaling. But the >physical circuit is still a T1 (and that's all the "term" T1 stands >for - an overall capacity of a digital span using a standard framing >mechanism). > >As I said - pedantic - but I believe in being thorough in such >discussions. > >> How often do you have to troubleshoot d-channel signaling? > >If you include service messages (which are part of D channel >signaling, and which I've never had a problem with their equivalent on >E&M T1 circuits), then probably with a similar frequenty as we >troubleshoot signaling problems on our channelized T1 E&M circuits. >That is, not very much at all. > >> However, you must remember, when you are posting to this list you are >> talking to a tremendous number of people no where near as >informed as you. > >Strange, and here I thought I was just offering a balanced opinion, >specifically in that vein :-) ;) > >> They experience different kinds of problems from sheer lack of experience >> and understanding. Again, I say, stop assuming your situation applies to >> everyone else. It doesn't! > >Where did I? It seems that you offered some information based on your >experience, and I offered some based on mine. Just a balanced >discussion, which can only help readers of this list, no? Or are you >saying that your experience/situation is more applicable to everyone >else than mine? Definitely not. In fact, based on what I know of you and have seen from you on this list I think the people on this list have more to learn from you than me. I do agree, all things being equal, a T1 should be able to perform almost or as well as a PRI. I also agree, PRI's are a little more involved when it comes to making sure it is configured the way you need it configured. ie. signaling. In my experience PRI's are easier to work with telco's to resolve problems on. Just because you request E&M type II doesn't mean the guy at the telco who set up your line is running the damn thing through a channel bank. I can't tell you how many times I had to work with a telco to resolve problems with multiple codecs in the line. Never had to do that with a PRI. I respect your opinion very much. My experience has proven "to me" my original opinion is sound. thanks again > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) using round robin & fixed assignment
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-19 18:48:40
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bolen >Sent: Thursday, November 19, 1998 5:26 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) using round robin & fixed assignment > > >"Brian K McIntire" <bmcintire@commnet.com> writes: > >> The "fix" may not be to wait for software features. > >Well, the "fix" is definitely to fix the bug. But as you note there >are other "workarounds" that may be applicable. > Unless the software was originally designed to do what you asked it can not be a bug. It can only be a feature to be added later. >> Although >the suggestion >> you mention above sounds like it would work better than what I'm going to >> suggest. The amount of time it takes to the telco to reset >their side can >> be tailored to your specifications depending on the equipment the telco >> uses. Try experimenting with it by having the time to reset changed to >> 250ms. I believe the telco can adjust up to 1200ms. I may be wrong. > >It depends on the switch and software configuration. For our UK >problem, the maximum available by the telco was 250ms and we still >needed a 4-modem buffer to keep up adequately. But I agree that it is >something worth trying if you are on the margin in terms of timing. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) 1.2.68 Warning! Please read.
From: Brian <signal@shreve.net>
Date: 1998-11-19 18:59:44
I am assuming hd102682.zip is effected as well? (must have been a .68 variant) On Mon, 19 Nov 2018, John Powell wrote: > We are looking into issues with 1.2.68 (and .67, .66, .65, and .64) > causing problems on some T3 muxes. There is not an issue on 1.2.5 or > engineering releases numbered above 1.2.68. It also does not appear to be > an issue in E1 codebases. > > The issue seems contained to certain muxes, but is serious enough when it > does happen, that I highly recommend not using those releases on any > chassis that don't already have it until we completely nail this issue and > issue a patch. > > If you are already using one of them, and are not experiencing > problems, there is > no need to back them off, this is not a problem that creeps up. Your > spans either have a problem with it, or they don't. > > So, if you have 1.2.68 (that one is out there in large quantities), please > use great care and I do not suggest you expand its' use at all. > > Regards, > > JP > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) using round robin & fixed assignment
From: David Bolen <db3l@ans.net>
Date: 1998-11-19 19:00:11
"Brian K McIntire" <bmcintire@commnet.com> writes: > Unless the software was originally designed to do what you asked it can not > be a bug. It can only be a feature to be added later. Yeah, but that's a real reach in this case - it implies that the original design of the software was intended to fail to accept calls in what would be considered a normal operating mode. It's hard to look at that as a sane design by any standard. It's a bug. Me customer, it bug. I don't buy the "it's not a bug, it's a feature" line. :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: RE: (usr-tc) hiperarc NAS-Port-Id
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-11-19 19:11:14
On Thu, 19 Nov 1998, Mike Wronski wrote: > |With 4.1.72 on the hiperarc, theres an improvement with the NAS-Port-Id > |output (used to all be set to 1), but I think theres still a glitch: > | > | NAS-Port-Id = 1539 > | NAS-Port-Id = 1028 > | NAS-Port-Id = 1793 > | NAS-Port-Id = 1026 > | NAS-Port-Id = 514 > | NAS-Port-Id = 1793 > | NAS-Port-Id = 1794 > | NAS-Port-Id = 912469510 > | NAS-Port-Id = 1795 > | NAS-Port-Id = 1796 > | NAS-Port-Id = 258 > | NAS-Port-Id = 2049 > > Can you show the entire record the Odd entry came from?? > GNU GREP with -A 3 -B 3 ??? > I did some more greps and found that the oddball entries always have Acct-Multi-Session-Id entries, as the following full example shows, its complete except for the IP and username etc info that I've stripped out. -- Thu Nov 19 18:18:18 1998 Acct-Status-Type = Start Acct-Session-Id = "3967" Acct-Delay-Time = 0 Acct-Authentic = RADIUS Service-Type = Framed-User NAS-Port-Type = Async NAS-Port-Id = 1537 USR-Modem-Training-Time = 23 USR-Interface-Index = 2793 USR-Chassis-Call-Slot = 7 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 1 USR-Unauthenticated-Time = 9 USR-Modulation-Type = v34 USR-Simplified-MNP-Levels = 13 USR-Simplified-V42bis-Usage = ccittV42bis USR-Connect-Speed = 26400_BPS Framed-Protocol = PPP USR-MP-MRRU = 0 Acct-Link-Count = 1 Acct-Multi-Session-Id = 875639045 NAS-Port-Id = 825242721 Timestamp = 911517498 Request-Authenticator = Unverified -- Notice the NAS-Port-Id is listed twice! Up near the top it looks correct, down at the bottom it seems to contain an Acct-Multi-Session-Id number by mistake. This is affecting cistron radius in particular, the radwho program.. which I suppose could be recoded to use the first NAS-Port-Id, but shouldn't there only be one anyway? -L
Subject: Re: (usr-tc) 1.2.68 Warning! Please read.
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-19 19:29:53
John Powell writes... >We are looking into issues with 1.2.68 (and .67, .66, .65, and .64) >causing problems on some T3 muxes. There is not an issue on 1.2.5 or >engineering releases numbered above 1.2.68. It also does not appear to be >an issue in E1 codebases. > >The issue seems contained to certain muxes, but is serious enough when it >does happen, that I highly recommend not using those releases on any >chassis that don't already have it until we completely nail this issue and >issue a patch. Certain muxes as in particular muxes at certain customer sites, or certain muxes as in Telco Systems, Nortel, AT&T, CAC, etc? I'd like to reiterate that 1.2.68 was the first release to solve some intractible T1 error problems for me. I hope these two aren't related. -a
Subject: Re: (usr-tc) v.90 connect problems
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-19 19:32:31
David Bolen writes... >Aaron Nabil <nabil@spiritone.com> writes: > >> The probability of losing a D channel is miniscule compared to losing the >> span to something like a looped repeater. When this happens having a backup >> D channel will make you very, very sorry as your calls dissapear down >> a black hole. > >I think it depends on the number of spans you are discussing. > >When concerned with a single span, your odds tend to be greater of >losing the entire span (D channel included) than just the D channel. >Very little point to having a backup. > >However, once you start involving multiple spans sharing a D channel >with NFAS, then it's very important to have at least one backup D >channel since even if the odds favor losing the entire span containing >your D channel, you don't want to affect all of the other spans >depending on it. If you are running NFAS, by all means use a backup D channel. A much, much better solution is never to use NFAS. Fate sharing good. NFAS bad. -a
Subject: RE: (usr-tc) I'm about to pull my hair out
From: David OBrien <growler@ac.net>
Date: 1998-11-19 20:00:47
Okay i have set up ummm lets say 24 modems (6 quad digital cards 2059 chassis) got all the settings just like they should be to accept calls from the CT1 saved it to NVRAM saved it again for the heck of it reset the modems call is accepted when call is done the modem reverts back to the settings before i saved to nvram (partiuclarly nic instead of t1 and mf tones instead of dtmf tone) and the modem will not accept another call. so I have been sitting here switching them back after each call. How can I make it stick. I also have the reset method via the atNVram thingy. can maybe someone help me? -Dave
Subject: (usr-tc) I'm about to pull my hair out
From: David OBrien <growler@ac.net>
Date: 1998-11-19 20:25:52
sheesh where'd the RE: come from anyways Okay i have set up ummm lets say 24 modems (6 quad digital cards 2059 chassis) got all the settings just like they should be to accept calls from the CT1 saved it to NVRAM saved it again for the heck of it reset the modems call is accepted when call is done the modem reverts back to the settings before i saved to nvram (partiuclarly nic instead of t1 and mf tones instead of dtmf tone) and the modem will not accept another call. so I have been sitting here switching them back after each call. How can I make it stick. I also have the reset method via the atNVram thingy. can maybe someone help me? -Dave - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) v.90 connect problems
From: David Bolen <db3l@ans.net>
Date: 1998-11-19 20:34:43
Aaron Nabil <nabil@spiritone.com> writes: > The probability of losing a D channel is miniscule compared to losing the > span to something like a looped repeater. When this happens having a backup > D channel will make you very, very sorry as your calls dissapear down > a black hole. I think it depends on the number of spans you are discussing. When concerned with a single span, your odds tend to be greater of losing the entire span (D channel included) than just the D channel. Very little point to having a backup. However, once you start involving multiple spans sharing a D channel with NFAS, then it's very important to have at least one backup D channel since even if the odds favor losing the entire span containing your D channel, you don't want to affect all of the other spans depending on it. It's probably not worth it at 2 spans (where doing so negates the benefit of NFAS in the first place of getting you back an extra channel for a user), but I'd say it's clearly necessary as part of a good design at higher numbers of spans. Yes, there is some risk that the failure mode of the span containing your primary D channel will be such that the telco still perceives it as viable for calls (although if service messages are active you should be able to proactively request it be taken out of service, even if with some delay after the failure), there are other failure modes where that will not be the case. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) I'm about to pull my hair out
From: David Bolen <db3l@ans.net>
Date: 1998-11-19 20:41:27
David OBrien <growler@ac.net> writes: > Okay i have set up ummm lets say 24 modems (6 quad digital cards 2059 > chassis) got all the settings just like they should be to accept calls from > the CT1 saved it to NVRAM saved it again for the heck of it reset the You say saved "it", but in this configuration there are 24 "its" (the modems) so is this just a grammar burp, or are you not actually saving the modems themselves? > I have been sitting here switching them back after each call. How can I > make it stick. I also have the reset method via the atNVram thingy. > can maybe someone help me? The modem normally performs a reset at call completion, so the reversion of the settings would seem to imply that they really aren't being properly saved. It sounds like what you're doing should be ok though. You might try resetting all your modems to factory defaults just to be on the safe side (perhaps they accidentally are set to reference a different NVRAM profile than the default which is being saved to?), then sending your changes, and then saving each modem to NVRAM. If you are changing the line source settings, you normally have to reset the modem (or card) as well to have it take effect. You might also also check that the NMC isn't configured to auto-configure equipment in the chassis. Although it should track your changes to the modem settings (unless you're doing it through the console rather than the NMC), if that gets out of whack, it might reconfigure your modem on each reset to it's perception of the setting values. In terms of testing things, rather than waiting for a call, just reset the modem yourself and ensure that the setting sticks. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) 1.2.68 Warning! Please read.
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-19 20:47:50
John Powell writes... >We are looking into issues with 1.2.68 (and .67, .66, .65, and .64) >causing problems on some T3 muxes. There is not an issue on 1.2.5 or >engineering releases numbered above 1.2.68. It also does not appear to be >an issue in E1 codebases. > >The issue seems contained to certain muxes, but is serious enough when it >does happen, that I highly recommend not using those releases on any >chassis that don't already have it until we completely nail this issue and >issue a patch. I bet it's a timing problem, you should have your customer check that he's set for loop timing (on the hiperdsp, not the mux). I haven't run a pulse mask test on the output of a hiperdsp, but it's also possible that the mux sees it as too hot. You could try increasing the transmitter attenuation. On the Hiperdsp, the nic seems configuarble on the fly (unlike the dual T1 card) for short haul, you could set it to short if it's plugged directly into a mux. Also note that the default "Jitter Attenuation" setting for the hiperdsp is wrong, for loop-timed applications you want the jitter attenuation in the receive path, not that transmit path. -a
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-19 22:01:39
Thus spake Brian K McIntire >The fact that the 2e supports only 30 may partially explain how it can >handle things a little better. It doesn't have to do the work the USR >NetServer does Oh, come now... A 386 with 30 ports, or a 486 with 48? You're saying a 486 is less than double the power of a 386? shyeah right...and I've got some swampland in florida to sell you. A 486 with 48 ports should *clobber* a 386 with 30 ports in performance...*particularly* when you consider the offloading of ppp framing into the quad cards! This shouldn't even be *close*! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) v.90 connect problems
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-20 04:34:21
David Bolen writes... >Aaron Nabil <nabil@spiritone.com> writes: > >> If you are running NFAS, by all means use a backup D channel. A much, >> much better solution is never to use NFAS. > >Depends - NFAS can be helpful if you're exceeding telco capacities for >hunt groups (too many D channels for the switch to handle - we run >into that at around 64 spans on some switches and software releases), >or if you just don't want to give up so many channels to D channel >signaling on large hunt groups. For example, a fully populated HDM >rack might have 56 spans in 4 chassis - using a D+backup setup per >chassis would get back 48 channels, or two full spans worth, which can >be worth a lot of money. I'm just going to take a stab at an estimate of what a 56 span system costs, say $250,000. You are talking about wasting, say, $10,000 of that on the d-channels? That's miniscule compared to the trouble NFAS causes in troubleshooting, provisioning, and black-hole problems I've already mentioned when you lose the span in a way that doesn't alarm at the CO. One factor that often gets missed is that the CO often provisions the backup D channel on the same switchmod. The single NFAS installation I've worked with was this way. If that switchmod fails, you've just idled your $250,000 investment. -- Aaron Nabil
Subject: Re: (usr-tc) 1.2.68 Warning! Please read.
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-11-20 05:56:54
You are correct, that is 1.2.68. I don't want to create any panic, as this has only been seen in two sites. The problem is serious enough though that I would be negligent to not post a warning a recommend not installing it. JP On Thu, 19 Nov 1998, Brian wrote: > > I am assuming hd102682.zip is effected as well? (must have been a .68 > variant) > > > On Mon, 19 Nov 2018, John Powell wrote: > > > We are looking into issues with 1.2.68 (and .67, .66, .65, and .64) > > causing problems on some T3 muxes. There is not an issue on 1.2.5 or > > engineering releases numbered above 1.2.68. It also does not appear to be > > an issue in E1 codebases. > > > > The issue seems contained to certain muxes, but is serious enough when it > > does happen, that I highly recommend not using those releases on any > > chassis that don't already have it until we completely nail this issue and > > issue a patch. > > > > If you are already using one of them, and are not experiencing > > problems, there is > > no need to back them off, this is not a problem that creeps up. Your > > spans either have a problem with it, or they don't. > > > > So, if you have 1.2.68 (that one is out there in large quantities), please > > use great care and I do not suggest you expand its' use at all. > > > > Regards, > > > > JP > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) v.90 connect problems
From: David Bolen <db3l@ans.net>
Date: 1998-11-20 06:28:31
Aaron Nabil <nabil@spiritone.com> writes: > If you are running NFAS, by all means use a backup D channel. A much, > much better solution is never to use NFAS. Depends - NFAS can be helpful if you're exceeding telco capacities for hunt groups (too many D channels for the switch to handle - we run into that at around 64 spans on some switches and software releases), or if you just don't want to give up so many channels to D channel signaling on large hunt groups. For example, a fully populated HDM rack might have 56 spans in 4 chassis - using a D+backup setup per chassis would get back 48 channels, or two full spans worth, which can be worth a lot of money. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) padding on trunk groups
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-11-20 06:33:20
Brian, Your note exemplifies why we don't publish the info on pads. That leads to driving the telcos nuts on a subject most users, and certainly most telco people, do not fully understand. A very important note, is that the modems do not detect analog pads, they look like loop loss and are not discernable. The modems can only detect digital pads, and those are really the only ones they are concerned about anyway (as they need to be mathematically compensated for). So, with that in mind, all the analog lines have pads, you just don't see the ones applied to one of the lines as it is an analog pad (done on the analog side of the codec). Also, in common practice, the pads are not applied to the PRIs xmit direction, they are applied to the codecs xmit direction (analog modem's receive). This may seem like a semantics argument, but it is critical to understand as that means it is not a configurable item in the PRIs translations. You asked David to comment on this, but I don't see why he would know or care, the pad is inserted by the CO serving the analog user. It is possible to have pads provisioned on the PRI side in its' xmit direction. That is not often done, and is bad practice. In that case you would see two pads in the V.90 direction, the one that belongs there on the CO serving the analog user, and the one that does not belong there on the PRI side. I have seen this, but it is very rare. On your "quirk", it is probably not a quirk at all. I assume you are dialing your T1 from an analog line on the same CO. The specs recommend that no pad be inserted on intra-CO calls. Sometimes you will see a 3db pad, and that is OK, but often no pad at all. You see the 6db pad on the AOL call, as it is in a different CO, quite likely on a CLEC span which is treated like an LD call. Pads are related to echo cancellation, they aid in reducing echo so the EC has less to do. There is not a direct relationship though, as the "triggers" are quite a bit different. Pads are triggered based on dial plans and where you are calling/called from. ECs are generally not installed on local networks, but are only on LD/IXC networks. Even then, they are generally triggered and converged based on Round trip delay. Bottom line is I am not sure you are on the right track looking at the pads. They may be related to a speed click or so change, as digital pads do affect "bit integrity" a hair. You will not be able to get them changed and they are not affected by the provisioning of the T1/PRI in most cases (and it does not appear your examples are one of the exceptions). Also, there are plenty of conditions where digital pads are actually a good thing for V.90 modems. Your single data point may show it is the opposite...oh well. I think you need to look more at analog line quality and let the big boys handle the pads and stuff. I don't see anything in your notes that suggest pads are causing you any issues beyond a speedclick or so. JP On Thu, 19 Nov 1998, Brian K McIntire wrote: > Please forgive the following "book" > > I'm faced with a problem. I'm working for a customer in an Ameritech > region. When ever I place a call with my courier to a PRI I see a 6db pad > being applied to my receive. (The PRI's transmit) I've been told there has > to be a 6db pad applied because Ameritech has not installed echo > cancellation in their telephone network. Makes some sense. I have further > been told echo cancellation is not currently accepted as a standard but > where ever it has been installed telephone companies remove the 6db pad my > client modem see's on the receive. > > I understand there needs to be echo cancellation to go from a 4 to 2 wire. > (PRI to analog) If not there needs to be a pad. Does anyone have a > different opinion or know something different. Is there a way around this? > (Probably not) If not does anyone know if using echo cancellation will > become a standard? > > The bottom line is, I have some customer's that connect at higher speeds > than others because of who their local telephone company is. The PRI I'm > working on is set up to be a local # for several cities with different > switches. One of the cities that dial this PRI applies no padding. The > others do. The problem is my customer's main competition is centrally > located in the local loop of the telco that does not pad. His customer's > are being called by his competition and given a chance to call a non-padded > PRI for free to prove their connect speeds will be better and steal > customers. Of course, connect speeds are always better when you compare > padded against non-padded. > > Any positive ideas? > > > > > By the way, here's an interesting quirk. When I dial the PRI that goes to > our internal lab chassis from a trunk off a non-padded T1 being provided by > the same telco I see no pad and connect at 50666. When I dial AOL's local # > (PRI's being provided by the same telco) I see 6db padding and connect at > 49333 or 48000. > > When I dial either from home (from a different phone company "Ameritheft") I > connect at 45333 or lower. Sometimes I don't even connect at v.90. I see > 37333 quite often. > > David, do you have any comments on this. The AOL chassis here are yours. > > ======================================================================== > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = Your Remote Access and Security Experts! = > = = > = Our experienced technicians can design and install your high speed = > = network for you. From Operating Systems and servers to routers and = > = firewalls nobody does it better than CommNetPlus. Our Technical = > = Support staff is available to you 24 hours a day to meet your needs.= > = Offering remote management and monitoring packages for dedicated = > = clients. (Specializing in ISP's). "Let us do the work for you!" = > = = > = Firm partnerships est. with current and emerging leaders of today's = > = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = > = Serving North America and parts of Canada. Reselling to the world. = > ======================================================================== > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 08:37:10
Not sure where you get your info from but it doesn't sound informed. I too have seen trouble on a span due to a looped repeater. However, we have seen more problems with d-channels going down. To the tune of over a hundred a month. I still love PRI's, and I think they are better and easier to troubleshoot with telco, but I also believe having a backup d is very important. It would have saved our customers allot of trouble. Anyway, your ignorant "stupid" remark is noted. Hope you enjoy your minute in the sun. Have a nice day >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil >Sent: Thursday, November 19, 1998 7:25 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) v.90 connect problems > > >Brian K McIntire writes... >>The difference I'm referring to is not just in performance but reliability >>and sometimes, on ease of turn up. On PRI's you do run this risk >of losing >>an entire span whenever a d-cannel goes down. Just another argument for >>Backup D. > >This is stupid. > >The probability of losing a D channel is miniscule compared to losing the >span to something like a looped repeater. When this happens >having a backup >D channel will make you very, very sorry as your calls dissapear down >a black hole. > > >-a > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) FYI: 1.2.66 & PRI errors
From: Jerry Kalligonis <jerryk@blazenet.net>
Date: 1998-11-20 08:40:35
It was patch 1.2.66 (see subject) as see John Powell's warning post.... Jerry At 05:31 PM 11/19/98 -0800, you wrote: >Jerry Kalligonis writes... >>At one particular location I have a good many PRI's. I was running the >>1.2.5 code, but had heard good things about the newer patch from other >>posts on this list. >> >> . . . >> >>Anyway, after hours of trouble shooting and no help from 3com, we found >>that the new code puts out a certain level of errors onto the PRI line. >>When enough of these PRIs are combined the error level is enough to bring >>down a T3. >> >>Of course later that afternoon I got a call back from 3com saying, sorry I >>couldn't get back to you this morning, but engineering says there may be a >>problem with this code that puts out enough errors to take down a T3. Call >>back to get DSP code 1.2.64 > >You didn't mention what version the "newer patch" was that cause these >problems for you. > >I was having trouble with false alarms coming from my DSP cards which >version 1.2.68 fixed. > > >-- >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) Interested in Line on the NetServer?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 08:44:47
Not everyone is using a NetServer for 48 ports. Many are using it for 96. If many of these 96 calls are passing massive streams of small packets then the 386 will perform better. makes sense. ;\ >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Thursday, November 19, 1998 9:02 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Interested in Line on the Netserver? > > >Thus spake Brian K McIntire >>The fact that the 2e supports only 30 may partially explain how it can >>handle things a little better. It doesn't have to do the work the USR >>NetServer does > >Oh, come now... > >A 386 with 30 ports, or a 486 with 48? You're saying a 486 is less than >double the power of a 386? shyeah right...and I've got some swampland >in florida to sell you. > >A 486 with 48 ports should *clobber* a 386 with 30 ports in >performance...*particularly* when you consider the offloading of ppp >framing into the quad cards! This shouldn't even be *close*! >-- >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) Interested in Line on the NetServer?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-20 08:57:49
Thus spake Brian K McIntire >Not everyone is using a NetServer for 48 ports. Many are using it for 96. >If many of these 96 calls are passing massive streams of small packets then >the 386 will perform better. makes sense. ;\ A NETServer handling 96 ports isn't the issue though....I'm not gonna argue about that, because it is getting to the limit of what a 486 could handle (it should be able to handle it, but its getting close)... But "Quake Lag" has been a problem for a *long* time...long before the HiPer equipment was available, meaning that its a problem even with only 48 ports in the box, so your argument that its a problem with 96 ports and that its reasonable for 96 ports to bog down like that on a 486 is moot. We're still talking 48 ports here where its bogging down. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 08:57:50
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Aaron Nabil >Sent: Friday, November 20, 1998 6:34 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) v.90 connect problems > > >David Bolen writes... >>Aaron Nabil <nabil@spiritone.com> writes: >> >>> If you are running NFAS, by all means use a backup D channel. A much, >>> much better solution is never to use NFAS. >> >>Depends - NFAS can be helpful if you're exceeding telco capacities for >>hunt groups (too many D channels for the switch to handle - we run >>into that at around 64 spans on some switches and software releases), >>or if you just don't want to give up so many channels to D channel >>signaling on large hunt groups. For example, a fully populated HDM >>rack might have 56 spans in 4 chassis - using a D+backup setup per >>chassis would get back 48 channels, or two full spans worth, which can >>be worth a lot of money. > >I'm just going to take a stab at an estimate of what a 56 span >system costs, say $250,000. You are talking about wasting, say, >$10,000 of that on the d-channels? That's miniscule compared to >the trouble NFAS causes in troubleshooting, provisioning, and >black-hole problems I've already mentioned when you lose the span >in a way that doesn't alarm at the CO. > >One factor that often gets missed is that the CO often provisions >the backup D channel on the same switchmod. The single NFAS >installation I've worked with was this way. If that switchmod >fails, you've just idled your $250,000 investment. > > >-- >Aaron Nabil This arguement is getting way off topic but i would have to agree it is better to not use NFAS to beging with. However, most of my customer's like it. They still like it even after I warn them about the possibilities of what may happen. So, we use it. All in all, it can be riskier, but I can't say I have had more trouble with it than not using it. Your experience may be otherwise, but your lack of good experience with it does not negate mine. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) v.90 connect problems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-20 09:01:19
Thus spake David Bolen >Aaron Nabil <nabil@spiritone.com> writes: >> If you are running NFAS, by all means use a backup D channel. A much, >> much better solution is never to use NFAS. >For example, a fully populated HDM >rack might have 56 spans in 4 chassis - using a D+backup setup per >chassis would get back 48 channels, or two full spans worth, which can >be worth a lot of money. That, of course, is implying that the HDM's support NFAS, which they don't to my knowledge, unless you're running a special build, but I don't think that's likely. Agreed though, NFAS *can* save you a bundle of channels, and it'd be a nice feature to have on the HDM's. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) v.90 connect problems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-20 09:03:15
Thus spake Brian K McIntire >Not sure where you get your info from but it doesn't sound informed. I too >have seen trouble on a span due to a looped repeater. However, we have seen >more problems with d-channels going down. Lucky you...I've only had a d channel go down independantly of the span once....I've had span's go down for other reasons myriads of times. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Interested in Line on the NetServer?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 09:07:23
I understand. Honestly, I haven't seen too many issues with 48 ports on the 486 NetServer but I have seen some >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Friday, November 20, 1998 7:58 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Interested in Line on the NetServer? > > >Thus spake Brian K McIntire >>Not everyone is using a NetServer for 48 ports. Many are using it for 96. >>If many of these 96 calls are passing massive streams of small >packets then >>the 386 will perform better. makes sense. ;\ > >A NETServer handling 96 ports isn't the issue though....I'm not gonna >argue about that, because it is getting to the limit of what a 486 could >handle (it should be able to handle it, but its getting close)... > >But "Quake Lag" has been a problem for a *long* time...long before the >HiPer equipment was available, meaning that its a problem even with only >48 ports in the box, so your argument that its a problem with 96 ports >and that its reasonable for 96 ports to bog down like that on a 486 is >moot. We're still talking 48 ports here where its bogging down. >-- >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) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 09:07:24
HDM's will support NFAS soon. I got the work from one of the Engineer's who desogns the code. If it doesn't make TCS 3.5 it will make TCS 4.0 >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Friday, November 20, 1998 8:01 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) v.90 connect problems > > >Thus spake David Bolen >>Aaron Nabil <nabil@spiritone.com> writes: >>> If you are running NFAS, by all means use a backup D channel. A much, >>> much better solution is never to use NFAS. > >>For example, a fully populated HDM >>rack might have 56 spans in 4 chassis - using a D+backup setup per >>chassis would get back 48 channels, or two full spans worth, which can >>be worth a lot of money. > >That, of course, is implying that the HDM's support NFAS, which they >don't to my knowledge, unless you're running a special build, but I >don't think that's likely. Agreed though, NFAS *can* save you a bundle >of channels, and it'd be a nice feature to have on the HDM's. >-- >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) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 09:10:11
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Friday, November 20, 1998 8:03 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) v.90 connect problems > > >Thus spake Brian K McIntire >>Not sure where you get your info from but it doesn't sound >informed. I too >>have seen trouble on a span due to a looped repeater. However, >we have seen >>more problems with d-channels going down. > >Lucky you...I've only had a d channel go down independantly of the span >once....I've had span's go down for other reasons myriads of times. Out of curiosity, what problems have you experienced with PRI's going down. Auto-busy outs at the switch; fibr cuts; loss of timing; etc.. >-- >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) v.90 connect problems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-20 09:22:11
Thus spake Brian K McIntire >HDM's will support NFAS soon. I got the work from one of the Engineer's who >desogns the code. If it doesn't make TCS 3.5 it will make TCS 4.0 Cool! That's good to know. We might switch back to NFAS then if that's the case...hadn't done it to this point because the benefit of gaining one channel per every other span wasn't big enough to be significant with the dual-pri cards. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) v.90 connect problems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-20 09:24:54
Thus spake Brian K McIntire >>Thus spake Brian K McIntire >>>Not sure where you get your info from but it doesn't sound >>informed. I too >>>have seen trouble on a span due to a looped repeater. However, >>we have seen >>>more problems with d-channels going down. >>Lucky you...I've only had a d channel go down independantly of the span >>once....I've had span's go down for other reasons myriads of times. >Out of curiosity, what problems have you experienced with PRI's going down. >Auto-busy outs at the switch; fibr cuts; loss of timing; etc.. Oh man...I don't think we've ever had the same problem twice... :) These are just ones that I happen to remember... fuse blowing on the DSX, wire at a punch-down block coming loose (both 66 blocks and 110 blocks), having an rj-45 come out of its connector, dual-pri card loosing its config, probably others that I'm forgetting about here, but that's a good start. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) Re: your mail
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 09:26:27
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam >Sent: Thursday, November 19, 1998 5:07 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Re: your mail > > >Brian K McIntire was heard to say: >>Thanks for the info Dominic. I upgraded to the code you specified. This >>time it doesn't work at all. Instead of seeing the error message >incorrect >>passcode the RADIUS isn't even communicating with Secure ID. Any other >>Ideas. Debug was useless. All it showed was requests going out that were >>un- answered. Again, when I down graded back to 5.5.4 it worked like a >>charm. > >Ok, so try this... > >copy the bin/session from 5.5.4 to bin/saworker for 6.0.whatever and see >if that makes any difference at all. That's what the server runs to handle >authenticating with ACE. As far as I'm aware, other than the name change, >there is no difference between the two? Thanks for the response. Unfortunately, that didn't make a difference either. As I said before, with the same config, 5.5.4 works just fine. Dominic, has that ER code 6.0.92 been thoroughly tested? I'm working with another Engineer here who has installed with TCM S/A for Unix and Ace a few dozen times. He indicates he configured 6.0.92 the same as he configured 5.5.4. Any ideas. > >--Ricky > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) hiperarc NAS-Port-Id
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-20 09:51:18
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Laszlo Vecsey |Sent: Thursday, November 19, 1998 6:11 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) hiperarc NAS-Port-Id | | |On Thu, 19 Nov 1998, Mike Wronski wrote: | |> |With 4.1.72 on the hiperarc, theres an improvement with the NAS-Port-Id |> |output (used to all be set to 1), but I think theres still a glitch: |> | |> | NAS-Port-Id = 1539 |> | NAS-Port-Id = 1028 |> | NAS-Port-Id = 1793 |> | NAS-Port-Id = 1026 |> | NAS-Port-Id = 514 |> | NAS-Port-Id = 1793 |> | NAS-Port-Id = 1794 |> | NAS-Port-Id = 912469510 |> | NAS-Port-Id = 1795 |> | NAS-Port-Id = 1796 |> | NAS-Port-Id = 258 |> | NAS-Port-Id = 2049 |> |> Can you show the entire record the Odd entry came from?? |> GNU GREP with -A 3 -B 3 ??? |> | |I did some more greps and found that the oddball entries always have |Acct-Multi-Session-Id entries, as the following full example shows, its |complete except for the IP and username etc info that I've stripped out. | |-- |Thu Nov 19 18:18:18 1998 | Acct-Status-Type = Start | Acct-Session-Id = "3967" | Acct-Delay-Time = 0 | Acct-Authentic = RADIUS | Service-Type = Framed-User | NAS-Port-Type = Async | NAS-Port-Id = 1537 | USR-Modem-Training-Time = 23 | USR-Interface-Index = 2793 | USR-Chassis-Call-Slot = 7 | USR-Chassis-Call-Span = 1 | USR-Chassis-Call-Channel = 1 | USR-Unauthenticated-Time = 9 | USR-Modulation-Type = v34 | USR-Simplified-MNP-Levels = 13 | USR-Simplified-V42bis-Usage = ccittV42bis | USR-Connect-Speed = 26400_BPS | Framed-Protocol = PPP | USR-MP-MRRU = 0 | Acct-Link-Count = 1 | Acct-Multi-Session-Id = 875639045 | NAS-Port-Id = 825242721 | Timestamp = 911517498 | Request-Authenticator = Unverified |-- | |Notice the NAS-Port-Id is listed twice! Up near the top it looks correct, |down at the bottom it seems to contain an Acct-Multi-Session-Id number by |mistake. | |This is affecting cistron radius in particular, the radwho program.. which |I suppose could be recoded to use the first NAS-Port-Id, but shouldn't |there only be one anyway? The dupe is strange.. Would it be possible to get a snoop/tcpdump trace of one of these strange packets? Binary version is required.. (ie snoop -x 0 -o acct.packets ).. Also is anyone else seeing this?? -M
Subject: RE: (usr-tc) Interested in Line on the Netserver?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-20 09:56:32
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams |Sent: Thursday, November 19, 1998 9:02 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Interested in Line on the Netserver? | | |Thus spake Brian K McIntire |>The fact that the 2e supports only 30 may partially explain how it can |>handle things a little better. It doesn't have to do the work the USR |>NetServer does | |Oh, come now... | |A 386 with 30 ports, or a 486 with 48? You're saying a 486 is less than |double the power of a 386? shyeah right...and I've got some swampland |in florida to sell you. | |A 486 with 48 ports should *clobber* a 386 with 30 ports in |performance...*particularly* when you consider the offloading of ppp |framing into the quad cards! This shouldn't even be *close*! Of course this 486 doesnt have an external cache. Take a look at the board. -M
Subject: RE: (usr-tc) Interested in Line on the NetServer?
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-11-20 10:00:42
From what I've seen, quakelag would start kicking in when around 30+ports are in use (on a 48port chasis). Probably less than 20 and its lag free, I think thats also about the approximate figure for the number of ccp/stac sessions the netserver can handle. On Fri, 20 Nov 1998, Brian K McIntire wrote: > I understand. Honestly, I haven't seen too many issues with 48 ports on the > 486 NetServer but I have seen some > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams > >Sent: Friday, November 20, 1998 7:58 AM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) Interested in Line on the NetServer? > > > > > >Thus spake Brian K McIntire > >>Not everyone is using a NetServer for 48 ports. Many are using it for 96. > >>If many of these 96 calls are passing massive streams of small > >packets then > >>the 386 will perform better. makes sense. ;\ > > > >A NETServer handling 96 ports isn't the issue though....I'm not gonna > >argue about that, because it is getting to the limit of what a 486 could > >handle (it should be able to handle it, but its getting close)... > > > >But "Quake Lag" has been a problem for a *long* time...long before the > >HiPer equipment was available, meaning that its a problem even with only > >48 ports in the box, so your argument that its a problem with 96 ports > >and that its reasonable for 96 ports to bog down like that on a 486 is > >moot. We're still talking 48 ports here where its bogging down. > >-- > >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) v.90 connect problems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 10:04:03
Allot of the thing you mention sound like they would affect both T1 and PRI. Been there done that How about looped smartjacks? >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams >Sent: Friday, November 20, 1998 8:25 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) v.90 connect problems > > >Thus spake Brian K McIntire >>>Thus spake Brian K McIntire >>>>Not sure where you get your info from but it doesn't sound >>>informed. I too >>>>have seen trouble on a span due to a looped repeater. However, >>>we have seen >>>>more problems with d-channels going down. > >>>Lucky you...I've only had a d channel go down independantly of the span >>>once....I've had span's go down for other reasons myriads of times. > >>Out of curiosity, what problems have you experienced with PRI's >going down. >>Auto-busy outs at the switch; fibr cuts; loss of timing; etc.. > >Oh man...I don't think we've ever had the same problem twice... :) > >These are just ones that I happen to remember... >fuse blowing on the DSX, wire at a punch-down block coming loose (both >66 blocks and 110 blocks), having an rj-45 come out of its connector, >dual-pri card loosing its config, probably others that I'm forgetting >about here, but that's a good start. >-- >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) Interested in Line on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-20 11:25:39
Thus spake Mike Wronski >Of course this 486 doesnt have an external cache. Take a look at the board. OK, just for yucks, I went downstairs and found a PM-25 that we had on a shelf here (only 25 ports, but same architecture as the 2E from what I understand)....guess what...it doesn't have an external cache either. Can anyone confirm or deny if the 2E has an external cache? I don't believe it does, but a confirmation would be nice. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: RE: (usr-tc) padding on trunk groups
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 13:09:04
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Powell >Sent: Tuesday, November 20, 2018 6:33 AM >To: usr tc >Subject: Re: (usr-tc) padding on trunk groups > > >Brian, > >Your note exemplifies why we don't publish the info on pads. I have a line analyzer that reports the pads to me as well. Either way I see pads. >That leads >to driving the telcos nuts on a subject most users, and certainly most >telco people, do not fully understand. A very important note, is that the >modems do not detect analog pads, they look like loop loss and are not >discernable. I know this >The modems can only detect digital pads, and those are >really the only ones they are concerned about anyway (as they need to be >mathematically compensated for). We've covered this > >So, with that in mind, all the analog lines have pads, you just don't see >the ones applied to one of the lines as it is an analog pad (done on the >analog side of the codec). Again, we have covered this. > >Also, in common practice, the pads are not applied to the PRIs xmit >direction, they are applied to the codecs xmit direction (analog modem's >receive). This may seem like a semantics argument, but it is critical to >understand as that means it is not a configurable item in the PRIs >translations. I know it isn't >You asked David to comment on this, but I don't see why he >would know or care, the pad is inserted by the CO serving the analog user. > It's not a matter of would he card, but more a matter of me asking him if he has seen this before. Jeez, why is everyone getting excited over simple questions! me customer you support >It is possible to have pads provisioned on the PRI side in its' xmit >direction. That is not often done, and is bad practice. In that case you >would see two pads in the V.90 direction, the one that belongs there on >the CO serving the analog user, and the one that does not belong there on >the PRI side. I have seen this, but it is very rare. > >On your "quirk", it is probably not a quirk at all. I assume you are >dialing your T1 from an analog line on the same CO. The specs recommend >that no pad be inserted on intra-CO calls. Sometimes you will see a 3db >pad, and that is OK, but often no pad at all. You see the 6db pad on the >AOL call, as it is in a different CO, quite likely on a CLEC span which is >treated like an LD call. Incorrect. It is the same CO. The exact same co server my PRI and the T1 my analog test calls were made from. > >Pads are related to echo cancellation, they aid in reducing echo so the EC >has less to do. There is not a direct relationship though, as the >"triggers" are quite a bit different. Pads are triggered based on dial >plans and where you are calling/called from. ECs are generally not >installed on local networks, but are only on LD/IXC networks. Even then, >they are generally triggered and converged based on Round trip delay. > >Bottom line is I am not sure you are on the right track looking at the >pads. They may be related to a speed click or so change, as digital pads >do affect "bit integrity" a hair. You will not be able to get them >changed and they are not affected by the provisioning of the T1/PRI in >most cases (and it does not appear your examples are one of the >exceptions). Also, there are plenty of conditions where digital pads are >actually a good thing for V.90 modems. Your single data point may show it >is the opposite...oh well. > >I think you need to look more at analog line quality and let the big boys >handle the pads and stuff. I >don't see anything in your notes that >suggest pads are causing you any issues beyond a speedclick or so. > John, you apparently do not remember anything we have talked about. I appreciate your help, but if you are going to try to slam me at least know what you are talking about. This is a continuation of the same problem we have had here for quite awhile. I sent you copies of ati4i6i7i11y11 screens as you requested. You never responded. I have made call after call after call and my line tester shows no discernable differences other than padding and/or connect speed. From several homes in the area we see connect speeds range from 28800 to 49333. Each home capable of getting all speeds in between. Honestly, I don't know what the next step is. I contacted this list looking for a new direction and some information to expand my own knowledge. By the way, in your response you spent most of your time going over things you and I have already gone over. (Very good stuff though) It would have been more helpful if you actually tried answering the actual questions I was asking. Please do not respond to me again lecturing me about how padding works. We have already been down this road. (I'm sure you know a great deal more about it than I but that is besides the point) I have forgotten very little of what you told me already. One last thing. This list is present for people like me to be able to communicate with people like yourself, get issues resolved and to answer questions. (To find a means to an end) Re-read my original e-mail. I think you will find you answered very little of what I asked (I was curious. Never said I was on Man Chu trail of padding) and further; offered no way to get me where I need to go. Not very helpful. Again, this is not malice. I know you are a very smart man. You really know your stuff, but if you need to vent your knowledge on someone in a negative way please vent it somewhere else. I do not want to open a ticket with 3COM on this. I'm sure it is telco related. If anyone has more constructive criticism to offer then let me here it. Thank you >JP > >On Thu, 19 Nov 1998, Brian K McIntire wrote: > >> Please forgive the following "book" >> >> I'm faced with a problem. I'm working for a customer in an Ameritech >> region. When ever I place a call with my courier to a PRI I see >a 6db pad >> being applied to my receive. (The PRI's transmit) I've been >told there has >> to be a 6db pad applied because Ameritech has not installed echo >> cancellation in their telephone network. Makes some sense. I >have further >> been told echo cancellation is not currently accepted as a standard but >> where ever it has been installed telephone companies remove the >6db pad my >> client modem see's on the receive. >> >> I understand there needs to be echo cancellation to go from a 4 >to 2 wire. >> (PRI to analog) If not there needs to be a pad. Does anyone have a >> different opinion or know something different. Is there a way >around this? >> (Probably not) If not does anyone know if using echo cancellation will >> become a standard? >> >> The bottom line is, I have some customer's that connect at higher speeds >> than others because of who their local telephone company is. The PRI I'm >> working on is set up to be a local # for several cities with different >> switches. One of the cities that dial this PRI applies no padding. The >> others do. The problem is my customer's main competition is centrally >> located in the local loop of the telco that does not pad. His customer's >> are being called by his competition and given a chance to call a >non-padded >> PRI for free to prove their connect speeds will be better and steal >> customers. Of course, connect speeds are always better when you compare >> padded against non-padded. >> >> Any positive ideas? >> >> >> >> >> By the way, here's an interesting quirk. When I dial the PRI >that goes to >> our internal lab chassis from a trunk off a non-padded T1 being >provided by >> the same telco I see no pad and connect at 50666. When I dial >AOL's local # >> (PRI's being provided by the same telco) I see 6db padding and connect at >> 49333 or 48000. >> >> When I dial either from home (from a different phone company >"Ameritheft") I >> connect at 45333 or lower. Sometimes I don't even connect at >v.90. I see >> 37333 quite often. >> >> David, do you have any comments on this. The AOL chassis here are yours. >> >> ======================================================================== >> = Brian K. McIntire bmcintire@commnet.com = >> = Systems Engineer III 317-558-5050 x113 = >> = CommNetPlus, Indianapolis, IN http://www.commnet.com = >> = Your Remote Access and Security Experts! = >> = = >> = Our experienced technicians can design and install your high speed = >> = network for you. From Operating Systems and servers to routers and = >> = firewalls nobody does it better than CommNetPlus. Our Technical = >> = Support staff is available to you 24 hours a day to meet your needs.= >> = Offering remote management and monitoring packages for dedicated = >> = clients. (Specializing in ISP's). "Let us do the work for you!" = >> = = >> = Firm partnerships est. with current and emerging leaders of today's = >> = technologies. Sales 800-845-2981 x117 (Aggressive Pricing) = >> = Serving North America and parts of Canada. Reselling to the world. = >> ======================================================================== >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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) padding on trunk groups
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-20 14:14:19
The only good information I have seen or heard of is in the form of very expensive books. An acquaintance of mine at a nearby telco said he spent 378,000 last year alone on books for his systems. I wish I knew of a book that breaks things down into layman's terms too. I'm sure there's one out there.
Subject: RE: (usr-tc) padding on trunk groups
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-11-20 14:26:18
On Tuesday, November 20, 2018 8:33 AM, John Powell [SMTP:jp@packet.ae.usr.com] wrote: > Your note exemplifies why we don't publish the info on pads. That leads > to driving the telcos nuts on a subject most users, and certainly most > telco people, do not fully understand. A very important note, is that the > modems do not detect analog pads, they look like loop loss and are not > discernable. The modems can only detect digital pads, and those are > really the only ones they are concerned about anyway (as they need to be > mathematically compensated for). Kind of off topic, but does anybody know of any on-line resources for getting to know the line provisioning/telco side of things better? I've looked for some time and I can't seem to find anything beyond a few promotional articles on RBOC web sites and very few white papers. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject: (usr-tc) Scripting the config of a HARC
From: Eric <elorenzo@mediacity.com>
Date: 1998-11-20 14:49:07
How can you script the configuration of a HARC? I was told that you can TFTP the file onto the HARC and then type "do filename" I'd like to be able to easily batch setup a HARC. With easy prompts, like: -What is my IP address? -What is my netmask? -What is my gateway? etc. Can someone send me some instructions on how to do this and maybe a sample script? Eric --- Eric J. Lorenzo Sr. Field Engineer lorenzo@ispchannel.com v:650.237.1465 http://www.ISPchannel.com
Subject: RE: (usr-tc) padding on trunk groups
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-11-20 17:33:52
It is not online, actually far from it, but there is a fine book that actually covers much of this. It is called "Bellcore's Notes on the Network". Can be purchased from www.bellcore.com. Last I checked it was "on-sale" for $596. Believe it or not, it is actually worth the money. Outside of the LSSGR (~$13K), it is the best, most thorough, reference that I have ever seen. It is very US/Canada centric though. There is very little else written on the topic. JP On Fri, 20 Nov 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > On Tuesday, November 20, 2018 8:33 AM, John Powell > [SMTP:jp@packet.ae.usr.com] wrote: > > Your note exemplifies why we don't publish the info on pads. That leads > > to driving the telcos nuts on a subject most users, and certainly most > > telco people, do not fully understand. A very important note, is that the > > modems do not detect analog pads, they look like loop loss and are not > > discernable. The modems can only detect digital pads, and those are > > really the only ones they are concerned about anyway (as they need to be > > mathematically compensated for). > > Kind of off topic, but does anybody know of any on-line resources for > getting to know the line provisioning/telco side of things better? I've > looked for some time and I can't seem to find anything beyond a few > promotional articles on RBOC web sites and very few white papers. > > Be Seeing You... > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 > Don't rush me, sonny. You rush a miracle maker and you get rotten miracles. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)Y2K Problem in USR Chassis
From: Syed Amiruddin <amir@cyber.net.pk>
Date: 1998-11-20 18:44:02
Hi Everybody, Can anyone confirm me, is Year 2000 problem can effect on USR Access Servers or not? Regards, -- Syed Amiruddin Sr.Systems Engineer Network Operations Cyber Internet Services (Pvt) Ltd. E-mail: amir@cyber.net.pk Phone : (92-21)111445566 Ext.232/201 Fax : (92-21)5686745
Subject: Re: (usr-tc) padding on trunk groups
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-11-20 20:54:09
John Powell writes... >It is not online, actually far from it, but there is a fine book that >actually covers much of this. It is called "Bellcore's Notes on the >Network". Can be purchased from www.bellcore.com. Last I checked it was >"on-sale" for $596. Believe it or not, it is actually worth the money. > >Outside of the LSSGR (~$13K), it is the best, most thorough, reference >that I have ever seen. It is very US/Canada centric though. In my opinion, the Notes chapter on loss plans is better than the LSSGR "transmission" coverage of the topic. Really the only coherent explanation of EML and TLP's I've ever seen, nice charts too. >There is very little else written on the topic. There is very little "practical" discussion in other texts, although _any_ modern telecom/communication theory book has a chapter on loss planning. It's one of those fundemental, building-block things. -- Aaron Nabil
Subject: Re: (usr-tc)Y2K Problem in USR Chassis
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-11-21 09:44:11
On Fri, 20 Nov 1998, Syed Amiruddin wrote: > Hi Everybody, > Can anyone confirm me, is Year 2000 problem can effect on USR Access > Servers or not? Syed, 3Com has a comprehensive Y2K site. http://www.3com.com/products/yr2000.html There is specific info on each TCH component, as well as just about every 3Com product, there. Hope that helps. JP
Subject: Re: (usr-tc) New Chassis/HiperARC installation success story! (well, almost)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-21 11:03:43
Do a show radius and send me the info. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 21 Nov 1998, System Administrator wrote: > I have what pretty much amounts to a production installation success story > that I wanted to share with the list. Note that there are still a couple of > small problems that I am curious about (see the end of the message), but > nothing major. One reason for this "success story", is simply to inject some > positive feedback into the mailing list, and let 3com know that while there > are definitely "imperfections" (both technical and otherwise) with the Total > Control systems, they also do seem to have a good core engineering team and > have done many things _right_ (from my perspective) that no other vendor has > been able to accomplish. > > Yesterday, at one of our remote POPs, a couple older Netserver based chassis > were replaced with a brand new chassis, including six HDSP cards and one HARC. > To 3com's benefit, the HARC interface is SIGNIFICANTLY better than the old > pm-based Netserver one. Things went very smoothly, this was our first rollout > of v.90 at this POP (we waited until we had the new chassis before rolling it > out). We've put v.90 in on other POPs, and are quite experienced with the > sort of trouble to expect (in terms of client modem issues). Everything went > just about flawlessly. ;) We did have one problem with the second HDSP, > serving the second PRI in this hunt group. For some reason, the majority of > callers hitting the card were unable to connect (saw reason: 2 in the syslog), > we never saw more than 50% of the card actually full. The card was pulled, > swapped with one at the end of the hunt group, and almost immediately filled. > I'm not sure what the problem with this card was, I have (1) reloaded template > 1 from default, (2) reconfig'd, (3) saved to nvram, and (4) reloaded template > 1 config channels. It's a bit hard to tell if it's still flakey, because now > it is at the end of the hunt group and only takes calls at peak periods; never > to full capacity (which is normal based on it's location in the hunt group). > > After some minor (non-HARC related) routing issues, everything seems to be > running perfectly. Our level 3 techs, who have all had _significant_ > experience with PM3s and v.90, expressed the following to me this morning: > "Boy, those usr racks are MUCH more forgiving with v.90 problems than the > pm3s". > > At this time, my only remaining problem is with authentication (radius). For > some reason, when I set BOTH the primary and secondary authentication server, > the HARC begins using the secondary instead of the primary after approximately > 30 minutes or so. Our secondary radius server is for emergency backup ONLY, > it does not have all the features that the primary does (however, it does let > users authenticate), and is only to be used in the event of a critical > failure on the primary. > > a "show authentication" reveals the following (true ips removed to protect the > innocent): > > RADIUS AUTHENTICATION SETTINGS > Local Authentication is: ENABLED > Remote Authentication is: ENABLED > Hint Assigned is: DISABLED > Primary Server is: aaa.bbb.ccc.ddd > 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: DISABLED > Active Authentication Server: aaa.bbb.ccc.ddd > > (note that I have disabled the secondary server for the time being, to avoid > this problem) > > Anyone have any ideas on this? > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * Finger sysadmin@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) New Chassis/HiperARC installation success story! (well, almost)
From: System Administrator <sysadmin@evcom.net>
Date: 1998-11-21 11:12:50
I have what pretty much amounts to a production installation success story that I wanted to share with the list. Note that there are still a couple of small problems that I am curious about (see the end of the message), but nothing major. One reason for this "success story", is simply to inject some positive feedback into the mailing list, and let 3com know that while there are definitely "imperfections" (both technical and otherwise) with the Total Control systems, they also do seem to have a good core engineering team and have done many things _right_ (from my perspective) that no other vendor has been able to accomplish. Yesterday, at one of our remote POPs, a couple older Netserver based chassis were replaced with a brand new chassis, including six HDSP cards and one HARC. To 3com's benefit, the HARC interface is SIGNIFICANTLY better than the old pm-based Netserver one. Things went very smoothly, this was our first rollout of v.90 at this POP (we waited until we had the new chassis before rolling it out). We've put v.90 in on other POPs, and are quite experienced with the sort of trouble to expect (in terms of client modem issues). Everything went just about flawlessly. ;) We did have one problem with the second HDSP, serving the second PRI in this hunt group. For some reason, the majority of callers hitting the card were unable to connect (saw reason: 2 in the syslog), we never saw more than 50% of the card actually full. The card was pulled, swapped with one at the end of the hunt group, and almost immediately filled. I'm not sure what the problem with this card was, I have (1) reloaded template 1 from default, (2) reconfig'd, (3) saved to nvram, and (4) reloaded template 1 config channels. It's a bit hard to tell if it's still flakey, because now it is at the end of the hunt group and only takes calls at peak periods; never to full capacity (which is normal based on it's location in the hunt group). After some minor (non-HARC related) routing issues, everything seems to be running perfectly. Our level 3 techs, who have all had _significant_ experience with PM3s and v.90, expressed the following to me this morning: "Boy, those usr racks are MUCH more forgiving with v.90 problems than the pm3s". At this time, my only remaining problem is with authentication (radius). For some reason, when I set BOTH the primary and secondary authentication server, the HARC begins using the secondary instead of the primary after approximately 30 minutes or so. Our secondary radius server is for emergency backup ONLY, it does not have all the features that the primary does (however, it does let users authenticate), and is only to be used in the event of a critical failure on the primary. a "show authentication" reveals the following (true ips removed to protect the innocent): RADIUS AUTHENTICATION SETTINGS Local Authentication is: ENABLED Remote Authentication is: ENABLED Hint Assigned is: DISABLED Primary Server is: aaa.bbb.ccc.ddd 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: DISABLED Active Authentication Server: aaa.bbb.ccc.ddd (note that I have disabled the secondary server for the time being, to avoid this problem) Anyone have any ideas on this? Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger sysadmin@evcom.net for my PGP Public Key *
Subject: RE: (usr-tc) padding on trunk groups
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-21 14:27:02
I re-read my response to your e-mail. I realized it was much harsher than it should have been. Thanks John. I appreciate your help. I apologize for my chaffing response earlier. Your e-mail to me was less than cordial and I'm afraid my return was no better. Your knowledge and help has been tremendous in the past. The problem I have been troubleshooting here is a tough one. I never professed to be a telco or v.90 expert as I think you thought I was trying to indicate. If I was I would have never used this list for the problem. Also, I never expected the padding to be doing anything more than take down the connect speed a couple clicks. My questions about echo cancellation were curiosity questions only. I never thought I was on the right track with that either. I hope you will forgive my ignorance with this kind of a problem. It is definitely way above my head. I firmly believe the problem is definitely with the local telco and not the PRI. I simply do not know where to take it from here. The telco needs guidance I can't give them. I hope you will see your way to forgive my rash response. This entire thing has been very frustrating. Getting nothing but negative remarks about my questions instead of answers to anything I asked just kind of added to it. I'm sorry. :( >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of John Powell >Sent: Tuesday, November 20, 2018 5:34 PM >To: 'usr-tc@lists.xmission.com' >Subject: RE: (usr-tc) padding on trunk groups > > > >It is not online, actually far from it, but there is a fine book that >actually covers much of this. It is called "Bellcore's Notes on the >Network". Can be purchased from www.bellcore.com. Last I checked it was >"on-sale" for $596. Believe it or not, it is actually worth the money. > >Outside of the LSSGR (~$13K), it is the best, most thorough, reference >that I have ever seen. It is very US/Canada centric though. > >There is very little else written on the topic. > >JP > >On Fri, 20 Nov 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > >> On Tuesday, November 20, 2018 8:33 AM, John Powell >> [SMTP:jp@packet.ae.usr.com] wrote: >> > Your note exemplifies why we don't publish the info on pads. >That leads >> > to driving the telcos nuts on a subject most users, and certainly most >> > telco people, do not fully understand. A very important note, >is that the >> > modems do not detect analog pads, they look like loop loss and are not >> > discernable. The modems can only detect digital pads, and those are >> > really the only ones they are concerned about anyway (as they >need to be >> > mathematically compensated for). >> >> Kind of off topic, but does anybody know of any on-line resources for >> getting to know the line provisioning/telco side of things better? I've >> looked for some time and I can't seem to find anything beyond a few >> promotional articles on RBOC web sites and very few white papers. >> >> Be Seeing You... >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Matthew Stainforth<>Technical Services Manager<>BrunNet >Inc.<>(506)450-4562 >> Don't rush me, sonny. You rush a miracle maker and you get >rotten miracles. >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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) ospf
From: Brian <signal@shreve.net>
Date: 1998-11-22 03:07:08
Does anyone know if OSPF is slated for ARC v4.2? Just trying to get a handle on the timeline. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) ospf
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-22 06:02:35
It's slated for the next full featured release of HiPer ARC. Don't know the timeline. Within the next 2 months i would think, but don't quote me. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian >Sent: Sunday, November 22, 1998 3:07 AM >To: USRobotics TC Mailing List >Subject: (usr-tc) ospf > > >Does anyone know if OSPF is slated for ARC v4.2? Just trying to get a >handle on the timeline. > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 ARC 4.1.72 - 7
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-22 06:10:20
I just installed 4.1.72 - 7 on one of our chassis. The HiPer DSP's have 1.2.5. We have had NMC's crash before so we had NMC chassis awareness disabled and statically configured the HiPer ARC for the DSP's we want it to manage. Here's what happened. Once the HiPer ARC rebooted with the new code all of our HiPer DSP's went into a continual reboot. They rebooted several times before I pulled the HiPer ARC and they stopped. I waited several minutes, put the HiPer ARC back in, and they all started rebooting again. I connected to the console of the HiPer ARC and typed delete config. As the HiPer ARC rebooted the DSP's stopped rebooting. I ran through quick setup and kept all defaults. I kept NMC chassis awareness enabled this time. The HiPer DSP's did not reboot this time. Calls started flowing in. Just for the hell of it I disabled NMC chassis awareness and configured things statically again. I saved all and rebooted. When the HiPer ARC came up the HiPer DSP's went into a perpetual reboot state. I, of course, am using NMC chassis awareness now. At least until we figure out what is causing this. Has anyone else seen this problem?
Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 10:38:21
Once upon a time Jeff Mcadams shaped the electrons to say... >>|I tell you what. >>|I get better quake on a livingston portmaster 2e and an anolog modem >>|attach than I do on a netserver 486 with pri lines. The portmaster has >>|an AMD 386 DX40. >>How many ports?? >A 2e has 30. The PortMaster-2 family, the PM-25, the IRX family, and the ORs all run AMD 386 CPUs. The fastest they are clocked is 33MHz, some older units are 25MHz. The high port density would be a PM-2e-30 with 30 async serial ports at 115.2Kbps (officially - 230.4Kbps works but is unofficial). Or a PM-2ei with 2 5BRI cards for 15BRI ports, or 30 B channels. The IRX-114 router has 2 T1/W1 ports, 2 64K sync ports, 1 async serial port, an 1 Ethernet. However, you really can't use all sync ports at once. It generally will handle the 2 T1/E1 ports as they are DMA. The 64K ports are interrupt driven so they chew up CPU when used along with the faster ports. The PM-3 has an AMD 486-66 as its CPU. With that it easily handles the two T1/E1/PRI WAN ports. Which can be dial or leased lines. Additionally there is a T1 WAN card which can be added to provide for a T1 leased line for a POP-in-a-box approach. The rough estimate from Lucent is that the CPU in the PM-3 is 6x that as the PM-2 - being a 486 and faster, AND having less to do. In the PM-3 many of the tasks the CPU used to do are offloaded to the HDLC controllers, DSPs, modem controllers, etc. PPP for example is performed on the modem cards (for modem calls). For ISDN I think it is done in the HDLC controller. Of course, the PM-3 also does OSPF and BGP, and in the latest betas NAT, NFAS, L2TP, IPIP, etc. Stac compression and IPSec encryption (the latter is in beta) are handled by daughter cards. The PM-4 is a much more distributed system. Each card has a K5 or K6 I believe, and there are many more CPUs dedicated to tasks. The main ethernet daughter card has 2 DEC RISC processors dedicated just to driving the Ethernet - one is inbound the other is outbound. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 10:40:55
Once upon a time Jeff Mcadams shaped the electrons to say... >OK, just for yucks, I went downstairs and found a PM-25 that we had on a >shelf here (only 25 ports, but same architecture as the 2E from what I Yes, it is pretty much just like the PM-2 with different serial port HW. >Can anyone confirm or deny if the 2E has an external cache? I don't >believe it does, but a confirmation would be nice. I'm not 100% sure, but AFAIK it does not. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 10:42:38
Once upon a time Brian K McIntire shaped the electrons to say... >The fact that the 2e supports only 30 may partially explain how it can >handle things a little better. It doesn't have to do the work the USR >NetServer does A PM-3 has an AMD 486-66 and it supports 2 T1/E1/PRI ports *AND* a T1 WAN card. Oh - while doing OSPF and BGP. Just to compare similar hardware. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 10:50:45
Once upon a time Jeff Mcadams shaped the electrons to say... >A 486 with 48 ports should *clobber* a 386 with 30 ports in >performance...*particularly* when you consider the offloading of ppp >framing into the quad cards! This shouldn't even be *close*! Especially when you consider that this is a 386-33 (sometimes -25) with 30 ports vers a 486-100 with 48. A 486 that is 3 (or 4) times as fast with 1.6x the number of ports. I'm following this Linux-on-Netserver effort, it is intriguing to say the least. If a HW engineer got involved perhaps they could logic-probe the interfaces to get around not having a published spec. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) v.90 connect problems
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 10:54:52
Once upon a time Aaron Nabil shaped the electrons to say... >If you are running NFAS, by all means use a backup D channel. A much, >much better solution is never to use NFAS. > >Fate sharing good. NFAS bad. This is myopic at best. NFAS is just fine - it just depends on where you use it. NFAS with 2 lines? Stupid. NFAS with 20 lines? NOT so stupid. With a primary D and backup D you just gained *18* ports. Ok, if they got NFAS working on a HiPer ARC chassis you could gain 12 ports across the chassis. If multichassis NFAS enters the picture, as Lucent is testing, then you could have more ports involved. The maximum varies by the switch being used. 20-24 is the number I see most often. And on a chassis like a PM-4 or CVX-1800 you can have enough lines in one chassis to have *multiple* NFAS groups. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-22 17:00:13
Thus spake MegaZone >Once upon a time Jeff Mcadams shaped the electrons to say... >>Can anyone confirm or deny if the 2E has an external cache? I don't >>believe it does, but a confirmation would be nice. >I'm not 100% sure, but AFAIK it does not. Which pretty much blows the theory out of the water of not having an external cache being the problem with "Quake Lag." -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) v.90 connect problems
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-11-22 17:51:47
On Sun, 22 Nov 1998, MegaZone wrote: > And on a chassis like a PM-4 or CVX-1800 you can have enough lines in > one chassis to have *multiple* NFAS groups. How does the CVX-1800 compare to the PM-4? Ive never heard of Aptis. -Dan
Subject: Re: (usr-tc) HiperDSP possible almost DOA
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-22 18:32:56
On Sun, 22 Nov 1998, Douglas Palmer wrote: > I just went through the installation and configuration of our new HiperDSP > and HiperARC cards. The HiperARC seems to work fine (though I cannot get it > to display the connection banner file) and the HiperDSP seemed ok for the > first 10 hours. There are two banners files - The first one which says Welcome to 3com .... That you will always see - you can also have a banner on connection - and that is something like PPP starting from etc - Which one are you talking about. The first one is default which should always be displyed - unless you removed/changed it. The second one is something that you must setup - You must enable auth hint assigned and set the banner you want. > > After 10 hours, the HiperDSP started rebooting (dropping users and busying > out all lines on the PRI for about 30 seconds) every two hours or so. After > 10 hours of this, it stopped working all together. The NAC no longer > responds to any stimulation beyond a red RUN light. It will not take a > reflash or any other input at all (it shows up as a red question mark on > the TCM diagram). > First check the code on the DSP - If you cannot then try reloading the code throught the console. you can use zmodem to download the code. For the most part you should see some type of error message on the cosole - for all you may know it chould be a config problem in terms of ownership. Check the code - if its 1.2.5 - then its a good stable code if it is anything other then you are better of loading 1.2.5 Check the hiper arc and make sure that you either have static or nmc chassis awarness enabled. This should solve your problem regards krish > I'll be calling in tomorrow for an RMA to get a replacement -- unless > someone here has an idea what might be done. It seemed fine for the first > 10 hours. Better connect rates for my v.90 users and good throughput. For > now, I am back on the Digital Quads. > > Thanks in advance for any pointers. > > DCP > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Interested in Line on the Netserver?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-11-22 18:58:29
On Sun, 22 Nov 1998, MegaZone wrote: > I'm following this Linux-on-Netserver effort, it is intriguing to say > the least. If a HW engineer got involved perhaps they could logic-probe > the interfaces to get around not having a published spec. How would Lucent feel about Linux-on-PM2 or Linux-on-PM3? -Dan
Subject: (usr-tc) HiperDSP possible almost DOA
From: Douglas Palmer <palmer@usdc-edny.com>
Date: 1998-11-22 19:01:21
I just went through the installation and configuration of our new HiperDSP and HiperARC cards. The HiperARC seems to work fine (though I cannot get it to display the connection banner file) and the HiperDSP seemed ok for the first 10 hours. After 10 hours, the HiperDSP started rebooting (dropping users and busying out all lines on the PRI for about 30 seconds) every two hours or so. After 10 hours of this, it stopped working all together. The NAC no longer responds to any stimulation beyond a red RUN light. It will not take a reflash or any other input at all (it shows up as a red question mark on the TCM diagram). I'll be calling in tomorrow for an RMA to get a replacement -- unless someone here has an idea what might be done. It seemed fine for the first 10 hours. Better connect rates for my v.90 users and good throughput. For now, I am back on the Digital Quads. Thanks in advance for any pointers. DCP
Subject: Re: (usr-tc) v.90 connect problems
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 20:20:42
Once upon a time Dan Hollis shaped the electrons to say... >On Sun, 22 Nov 1998, MegaZone wrote: >> And on a chassis like a PM-4 or CVX-1800 you can have enough lines in >> one chassis to have *multiple* NFAS groups. >How does the CVX-1800 compare to the PM-4? Ive never heard of Aptis. Have you heard of Nortel? ;-) Aptis was a start-up, the CVX-1800 was their first product. Nortel bought them before it shipped, it is a Nortel product now. Overall it is similar. It is a midplane, the PM-4 is a backplane. To generalize I'd say the Pm-4 was designed more for ISPs and the CVX more for telcos. The Pm-4 has internal slots for AC power supplies if needed, or it can run on native DC. The CVX is DC only, with a seperate AC-DC converter chassis available if needed. That gives it a few more slots. Both have similar bandwith per slot. And since the CVX is a bit taller they have similar rack densities. Now, at Interop I was told by the Nortel Networks folks that since they now have Bay as part of thier group that the CVX-1800 will ONLY be supporting dial access needs. And all of the router needs will be based on the Bay Versalar routing platforms. Whereas Lucent has indicated they intend to exploit the flexibility of the PM-4 to handle xDSL, ATM, SONET, etc - with OC3 and OC12 capabilities that are designed into the chassis. So it looks like the PM-4 will be a more versatile unit. Right now it is a large access box, but that's what is out now just at first customer ship. More interface types will be added in time. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 20:22:49
Once upon a time Dan Hollis shaped the electrons to say... >On Sun, 22 Nov 1998, MegaZone wrote: >> I'm following this Linux-on-Netserver effort, it is intriguing to say >> the least. If a HW engineer got involved perhaps they could logic-probe >> the interfaces to get around not having a published spec. >How would Lucent feel about Linux-on-PM2 or Linux-on-PM3? I doubt they'd release the hardware specs for them (maybe the PM-2 when it end of lifes, but then that's a pretty basic unit) but I don't think they'd try to stop it. Getting Linux to handle the proprietary systems like the backplane and modem cards in the PM-3 would be the hard part. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) v.90 connect problems
From: MegaZone <megazone@megazone.org>
Date: 1998-11-22 21:46:21
Once upon a time Mark R. Lindsey shaped the electrons to say... >`Dial-up servers' are routers had darned better act like it. They route, but it is useful not to call them routers. It is generally accepted that a 'router' is something that has at least on sync interface and that is what it primarily is designed to drive. Normally T1/E1 or faster, but it can be fractional thereof. The only exceptions really are "ISDN routers" and the general "SOHO router" catagory. I understood what they meant - if you're looking for T1/E1, DS-3c, OC-3, or OC-12 for leased lines then you don't look at the CVX-1800. If you want ATM, SONET, etc - same deal. You want to look at their other 'router' platforms. If you are looking for ISDN or modem access, and likely VOIP/FOIP in the future, then the CVX is the high end platform. I suspect the CVX won't be doing BGP either because of this - while the PM-4 does because leased line routing is something it was designed to do. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: Re: (usr-tc) v.90 connect problems
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-23 00:02:47
Quoth MZ: : Now, at Interop I was told by the Nortel Networks folks that since they : now have Bay as part of thier group that the CVX-1800 will ONLY be supporting : dial access needs. And all of the router needs will be based on the Bay : Versalar routing platforms. <rant> It still disappoints me to hear of manufacturers' spokesmen making this broad, sweeping distinctions between routers and network-access equipment. Router NAS ~~~~~~ ~~~ * Forwards packets * Forwards packets * Has lots of interfaces * Has lots of interfaces * Requires significant * Requires excruciating diagnostics diagnostics Somehow, the radically-different bit rates common on router interfaces (e.g., 100 mbit) versus NAS interfaces (e.g., 64 kbit) turns some into babbling dullards. `Dial-up servers' are routers had darned better act like it. </rant>
Subject: Re: (usr-tc) Interested in Line on the Netserver?
From: Brian Elfert <brian@citilink.com>
Date: 1998-11-23 09:10:14
On Sun, 22 Nov 1998, Dan Hollis wrote: > On Sun, 22 Nov 1998, MegaZone wrote: > > I'm following this Linux-on-Netserver effort, it is intriguing to say > > the least. If a HW engineer got involved perhaps they could logic-probe > > the interfaces to get around not having a published spec. > > How would Lucent feel about Linux-on-PM2 or Linux-on-PM3? I'm sure Lucent wouldn't like it at all. I think the PM2/3 and the Netserver card are quite different. The Netserver is pretty much a PC on a card. The PM2/3 do use x86 chips, but I don't think they are really a full PC. I think it'd be a lot harder to load something besides ComOS on the PM2/3 whereas the Netserver has the PCSDL thing. People aren't clamoring for a new OS on the PM2/3. ComOS already has OSPF, and it doesn't seem to have the Quake lag problems like the Netserver. Lucent is still developing code for the PM2/3 while the Netserver is dead after Dec 31st. (There are rumors of PM2 software development ceasing after ComOS 3.9.) Brian
Subject: RE: (usr-tc) New Chassis/HiperARC installation success story! (well, almost)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-23 09:51:49
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of System |Administrator |Sent: Saturday, November 21, 1998 10:13 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) New Chassis/HiperARC installation success story! |(well, almost) | |At this time, my only remaining problem is with authentication (radius). For |some reason, when I set BOTH the primary and secondary authentication server, |the HARC begins using the secondary instead of the primary after approximately |30 minutes or so. Our secondary radius server is for emergency backup ONLY, |it does not have all the features that the primary does (however, it does let |users authenticate), and is only to be used in the event of a critical |failure on the primary. | This is due to your "AUTHENTICATION_ALGORITHM". If you do a 'show radius' it is probably set to "ROUND_ROBIN". In this setting: If contact is lost with the primary, it will swap primary and secondary, making the secondary the first attempt. Only when the secondary goes down will the swap take place again.. For your requirements set it to "FALL_THROUGH". This way the primary is tried every time and only tries the others if no response comes from the primary. -M
Subject: Re: (usr-tc) [isp-services] FS:USR TOTAL CONTROL UNITS (fwd)
From: Frank Basso <frank@got.net>
Date: 1998-11-23 12:23:09
Yeah if you use ANALOG CO Trunks and NOT PRI's and you like Token ring :) -----Original Message----- >wow, 2400 dollars. > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > >---------- Forwarded message ---------- >Date: Mon, 23 Nov 1998 13:06:30 -0500 >From: "Andrew:PC Global, Inc." <pcglobal@gate.net> >To: isp-equipment@isp-equipment.com >Cc: isp-services@ispc.org >Subject: [isp-services] FS:USR TOTAL CONTROL UNITS > >Had to drop the price due to remain competitive. Please note that the >prices on these will go back up. Now selling for $2500 for a limited time >only!! > >>I Just received 10 more chassis. These may be the last ones I get for a >>while. Hope they can save/make you all some $$$!! >> >> >>60 PORT ANALOG/DIGITAL >> >>WE HAVE COMPLETE CHASSIS UNITS EACH INCLUDING: >> >>(1)CHASSIS >> >>(1)FAN TRAY >>(1) NET SERVER CARD REV.5 486DX/4 16MB USR#001369-00 >>(1) NETWORK MANAGEMENT CARD REV.3 USR#000978-00 >>(15) QUAD V.34 ANALOG/DIGITAL MODEM REV.2 USR#000793-04 (60 Analog Ports) >>(15) NIC ANALOG ADAPTERS USR#000385-00 >>(2) AC PSU 45A CARD >> >>USR BUILD DATE 10/28/96 >> >>MORE INFO: >> >>-THESE UNITS ARE TOKEN RING >> >>-MODEMS ARE UPGRADABLE TO V.90 56K VIA USR/3COM >>-UNITS ARE ANALOG/DIGITAL, A PRI-T1 CARD IS NEEDED FOR DIGITAL >> >>-UNITS GUARANTEED WORKING/JUST TAKEN OUT OF SERVICE. NATIONWIDE ISP WENT >OUT >>OF BUSINESS. >>-EQUIPMENT IS FREE AND CLEAR OF ANY LEINS OR INCUMBRANCES >> >> >>WE HAVE SOME INDIVIDUAL PARTS AVAILABLE. >>-NET SERVER CARDS >>-NET MGMT CARDS >>-ANALOG/DIGITAL MODEM CARDS >>-POWER SUPPLIES >>-FAN TRAYS >>----NO PRI/T1 CARDS LEFT >> >>PRICE: >>>>>$2,400 EACH >>QUANTITY PRICING AVAILABLE (3 OR MORE) >> >>PAYMENT: CREDIT CARD (VS/MC/AMX/DISC), COD cert funds >> >>Thank you for your time and have a great day! >> >> Andrew Shlensky >> **************************** >> PC Global, Incorporated >> (305) 667-2111 TEL >> (305) 667-3636 FAX >> URL: http://www.pcglobal.net >> E-MAIL: andrew@pcglobal.net >> >> >> >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org >For additional commands, e-mail: isp-services-help@ispc.org > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Interested in Line on the Netserver?
From: MegaZone <megazone@megazone.org>
Date: 1998-11-23 14:05:07
Once upon a time Brian Elfert shaped the electrons to say... >Netserver is dead after Dec 31st. (There are rumors of PM2 software >development ceasing after ComOS 3.9.) That wouldn't surprise me. ComOS 3.9 has lots of nifty things like NAT and L2TP. Really, the only things not in 3.9 I can think of off hand that might be wanted on an old async unit like the PM-2 would be mulitcast support and extended SNMP support (they seem to notch SNMP up quite a bit in each new release, but I don't think 3.9 will be quite 'complete'). If they can work out the few applicable bugs the current code - the oddball BRI issues that a handful of people can't seem to shake, trouble with the new OSPF on demand links some have reported, etc - it looks like it would be a nice high note to end on. And the PM-2 family has been around a LONG time - the last new HW in that line were the ISDN BRI pieces which came out in late 1995 and early 1996. The basic design itself is rather older than that. Still works though. I think they might freeze software (save for bug fixes and security patches, if any) but keep the HW line alive since it does what it was designed to do well enough. I will say that ComOS 3.9b and PMVision 1.3b are lots of fun to play with together. :-) -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: (usr-tc) [isp-services] FS:USR TOTAL CONTROL UNITS (fwd)
From: Brian <signal@shreve.net>
Date: 1998-11-23 14:06:16
wow, 2400 dollars. Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 ---------- Forwarded message ---------- Cc: isp-services@ispc.org Had to drop the price due to remain competitive. Please note that the prices on these will go back up. Now selling for $2500 for a limited time only!! >I Just received 10 more chassis. These may be the last ones I get for a >while. Hope they can save/make you all some $$$!! > > >60 PORT ANALOG/DIGITAL > >WE HAVE COMPLETE CHASSIS UNITS EACH INCLUDING: > >(1)CHASSIS > >(1)FAN TRAY >(1) NET SERVER CARD REV.5 486DX/4 16MB USR#001369-00 >(1) NETWORK MANAGEMENT CARD REV.3 USR#000978-00 >(15) QUAD V.34 ANALOG/DIGITAL MODEM REV.2 USR#000793-04 (60 Analog Ports) >(15) NIC ANALOG ADAPTERS USR#000385-00 >(2) AC PSU 45A CARD > >USR BUILD DATE 10/28/96 > >MORE INFO: > >-THESE UNITS ARE TOKEN RING > >-MODEMS ARE UPGRADABLE TO V.90 56K VIA USR/3COM >-UNITS ARE ANALOG/DIGITAL, A PRI-T1 CARD IS NEEDED FOR DIGITAL > >-UNITS GUARANTEED WORKING/JUST TAKEN OUT OF SERVICE. NATIONWIDE ISP WENT OUT >OF BUSINESS. >-EQUIPMENT IS FREE AND CLEAR OF ANY LEINS OR INCUMBRANCES > > >WE HAVE SOME INDIVIDUAL PARTS AVAILABLE. >-NET SERVER CARDS >-NET MGMT CARDS >-ANALOG/DIGITAL MODEM CARDS >-POWER SUPPLIES >-FAN TRAYS >----NO PRI/T1 CARDS LEFT > >PRICE: >>>>$2,400 EACH >QUANTITY PRICING AVAILABLE (3 OR MORE) > >PAYMENT: CREDIT CARD (VS/MC/AMX/DISC), COD cert funds > >Thank you for your time and have a great day! > > Andrew Shlensky > **************************** > PC Global, Incorporated > (305) 667-2111 TEL > (305) 667-3636 FAX > URL: http://www.pcglobal.net > E-MAIL: andrew@pcglobal.net > > > > To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org For additional commands, e-mail: isp-services-help@ispc.org
Subject: (usr-tc) connecting a cisco router to total control ISDN
From: Steve Lalonde <steve@enta.net>
Date: 1998-11-23 17:41:48
Hi All I have a strange one Cisco 1603 router trying to connect to a totalcontrol chassis we can get the cisco to connect and authenticate using pap but we never see any accounting data in the radius logs so the cisco just hangs up is there anything strange about a cisco connecting to usr kit? there are 2 netserver based and 1 hyper based racks here and all do the same thing. TIA Steve Lalonde Systems Manager ENTANET International Ltd
Subject: Re: (usr-tc) HiperDSP possible almost DOA
From: Douglas Palmer <palmer@usdc-edny.com>
Date: 1998-11-23 17:43:11
At 06:32 PM 11/22/1998 -0600, you wrote: >> After 10 hours, the HiperDSP started rebooting (dropping users and busying >> out all lines on the PRI for about 30 seconds) every two hours or so. After >> 10 hours of this, it stopped working all together. The NAC no longer >> responds to any stimulation beyond a red RUN light. It will not take a >> reflash or any other input at all (it shows up as a red question mark on >> the TCM diagram). >> > >First check the code on the DSP - If you cannot then try reloading the >code throught the console. you can use zmodem to download the code. For >the most part you should see some type of error message on the cosole - >for all you may know it chould be a config problem in terms of ownership. The code is 1.2.5 -- it came with a slightly older rev and I updated it when the board arrived. It will no longer take a flash reload from the console. >Check the hiper arc and make sure that you either have static or nmc >chassis awarness enabled. Chassis awareness is enabled and the ownership is good. Like I said -- it worked fine for 10 hours, then started to go down hill. Now, it will not even go through the boot sequence when the rack is powered on. I'll try reflashing again tomorrow. DCP
Subject: RE: (usr-tc) v.90 connect problems
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-11-23 18:15:58
For what it's worth, here's the worst and the trickiest that happened at our site(s) - Cable impendance not right (ethernet cable is no good, you need 120ohm STP) - DSP hangs (dreaded sight : yellow board in TCM, one solution : hardware reset) - Switch sends fluctuating signals down the PRI lines... this does weird things to the boards - Wrong Fibermux plugged in (channelized E1 instead of E1 PRI, funny thing it's the same box the telco gives us, it's just a dip switch to set...) That's all for the DSP's - Too many SNMPget on the NMC will reboot the board (version 5.5.5) (is this a registered bug/feature ?) That's all for the NMC's No weird stuff on the ARC Hope this helps, Robert > -----Original Message----- > From: Jeff Mcadams [SMTP:jeffm@iglou.com] > Sent: vendredi, 20. novembre 1998 15:25 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) v.90 connect problems > > Thus spake Brian K McIntire > >>Thus spake Brian K McIntire > >>>Not sure where you get your info from but it doesn't sound > >>informed. I too > >>>have seen trouble on a span due to a looped repeater. However, > >>we have seen > >>>more problems with d-channels going down. > > >>Lucky you...I've only had a d channel go down independantly of the > span > >>once....I've had span's go down for other reasons myriads of times. > > >Out of curiosity, what problems have you experienced with PRI's going > down. > >Auto-busy outs at the switch; fibr cuts; loss of timing; etc.. > > Oh man...I don't think we've ever had the same problem twice... :) > > These are just ones that I happen to remember... > fuse blowing on the DSX, wire at a punch-down block coming loose (both > 66 blocks and 110 blocks), having an rj-45 come out of its connector, > dual-pri card loosing its config, probably others that I'm forgetting > about here, but that's a good start. > -- > 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) multiple default routes
From: Brian <signal@shreve.net>
Date: 1998-11-24 15:26:54
Is their a way on the ARC to declare multiple default routes for redundancy? something like, so that it uses the first default route, but if that fails it tries the second? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-24 16:38:58
On Tue, 24 Nov 1998, T.J. Weber wrote: > Okee, last night I posted this to one of 3com's internal newsgroups: > > ---- begin ---- > > This must seem a little odd, but I would like to know if there is a way > I can hide users from showing up in the "list connections". I use > RADIUS authentication, and I am wondering if there is a configuration > value I can set for the specific users in my RADIUS 'users' file that > will be sent back to my TC telling the HiPer not to list that user in > *ANY* records (specifically the "list connections" output). NO. There is no such options to hide users. If you want however you can set ppp passthrough meaning you can disable authentication for users and use the default user for all calls for say ppp. This way the only user who will be seen in the hIper arc is always the default user krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec > > Using RADIUS would be my best guess in this case, unless there is a way > I can specify users to "hide" set directly via the HiPer config prompt. > > ---- end ---- > > No responce from 3com quite yet on this matter, three cents to the dollar > odds that they won't respond with anything at all. > > I setup a Total Control box for my client in Chicago. They are a fairly > big law firm that is providing internet access to their employees. I am > not the only one with access to the total control box, there is someone > from their IS department that monitors connections on the box itself. > However, some of the partners in the firm don't want to be known that they > are online at a specific time (strange request if you ask me, i think they > don't want the guys in the IS dept. to know they are online). > > I also have another question regarding the TC boxes. In my configuration > for the total control box, i set aside a pool of 24 IP addresses for > dynamic assignment (we only have one operational DSP card). However, > there are about 10 other users that I would like to assign a DYNAMIC IP > from another pool (NOT the pool assigned to the total control). Once > again, I think that this is something I have to setup in RADIUS, but I'm > not sure how to do it. Please advise! > > So if anyone knows a simple solution to these problems that would be > great! > > Thanks in advance, > --t.j. > > > \|||/ > (o o) > ooO-(_)-Ooo---------------------------------------------------------- > T.J. Weber | Oxymoron: Microsoft Works > Interplanetary Media |------------------------------------ > phone: 847.205.5200 | WARNING: objects in mirror are > fax: 847.205.5201 | dumber than they appear. > e-mail: admin@ipmedia.net |------------------------------------ > web: http://www.ipmedia.net | Out of my mind. Back in 5 minutes. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Two things are infinite: the universe and human stupidity; > and I'm not so sure about the universe. (Albert Einstein) > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) new user log in problem with v.90
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-24 16:45:18
I saw this happen when the time on my server was set incorrectly and then set correctly. All users that had been added before the correction had different info in them. It wouldn't hurt to check time on everything >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Gorkem Yuksel >Sent: Tuesday, November 24, 1998 3:45 PM >To: 'usr-tc@lists.xmission.com' >Subject: (usr-tc) new user log in problem with v.90 > > >Hi! >Everybody. > >I am a new guy on the block.(small ISP) > >I am having some problems with new user's logging in. > >It does not allow to logging in right away when it comes to new users. > >Sometimes it started working 7 hours later, 1.5 hours later depending on >the Hiper DSP's mood, I guess. > >But all the old users connecting OK. All the new users you key in today >will be ok by tommorrow. > >I have TCM, Hiper DSP cards, NMC card, Hiper ARC card, about 6 month old. >We upgraded to v.90 a month ago, it worked fine I guess. >(or I did not have customers who wanted an instant setup???) > >I have system release 3.3. >Hiper ARC 1.1.11 >Hiper DSP T1/PRI 1.2.5 >NMC 16Meg 486 5.5.5 >TCM Windows 5.5.1 > >I e-mailed for help to 3Com but no answer for 3 days... > >I do not have tech support contract...too much money.. > >It started happening last Sat and Sun...Mon and Tue.. which is today. >I had one new customer yesterday.. it did not rscognize his username and >password right away, but started working about one and half hour later. > >I have another new one keyed in 14:33 pm today, it is not working yet >(16:37). >I just keep typing in his user name and password by using dial up every 15 >to 30 mins to see if it is working. I did not call this customer >to set up >his internet account yet. I may have to wait till tomorrow. > >Anybody have any good sugestions, please write me, I will appreciate it >very much. > >Please write all the detailed instructions, since I am not that good.. > > >Ken. 905-826-0737 ken@gncom.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: (usr-tc) new user log in problem with v.90
From: Gorkem Yuksel <gorkem@gncom.com>
Date: 1998-11-24 16:45:21
Hi! Everybody. I am a new guy on the block.(small ISP) I am having some problems with new user's logging in. It does not allow to logging in right away when it comes to new users. Sometimes it started working 7 hours later, 1.5 hours later depending on the Hiper DSP's mood, I guess. But all the old users connecting OK. All the new users you key in today will be ok by tommorrow. I have TCM, Hiper DSP cards, NMC card, Hiper ARC card, about 6 month old. We upgraded to v.90 a month ago, it worked fine I guess. (or I did not have customers who wanted an instant setup???) I have system release 3.3. Hiper ARC 1.1.11 Hiper DSP T1/PRI 1.2.5 NMC 16Meg 486 5.5.5 TCM Windows 5.5.1 I e-mailed for help to 3Com but no answer for 3 days... I do not have tech support contract...too much money.. It started happening last Sat and Sun...Mon and Tue.. which is today. I had one new customer yesterday.. it did not rscognize his username and password right away, but started working about one and half hour later. I have another new one keyed in 14:33 pm today, it is not working yet (16:37). I just keep typing in his user name and password by using dial up every 15 to 30 mins to see if it is working. I did not call this customer to set up his internet account yet. I may have to wait till tomorrow. Anybody have any good sugestions, please write me, I will appreciate it very much. Please write all the detailed instructions, since I am not that good.. Ken. 905-826-0737 ken@gncom.com
Subject: RE: (usr-tc) multiple default routes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-24 16:47:58
You may be able to add additional default routes by specifying a metric of 2 for the second and 3 for the 3rd. I set this up on one of ours. Although I could not verify the setting took place I was able to see one of my backup default routes take over when I deleted the original one. Try it Maybe you could even set up a second eth and make the default route entry a metric of 2 for it and unplug eth 1 to see if the default route for eth 2 shows up and takes over. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian >Sent: Tuesday, November 24, 1998 3:27 PM >To: USRobotics TC Mailing List >Subject: (usr-tc) multiple default routes > > >Is their a way on the ARC to declare multiple default routes for >redundancy? something like, so that it uses the first default route, but >if that fails it tries the second? > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) new user log in problem with v.90
From: K Mitchell <mitch@keyconn.net>
Date: 1998-11-24 16:52:25
At 04:45 PM 11/24/98 -0500, Gorkem Yuksel <gorkem@gncom.com> wrote: >I am having some problems with new user's logging in. > >It does not allow to logging in right away when it comes to new users. > >Sometimes it started working 7 hours later, 1.5 hours later depending on >the Hiper DSP's mood, I guess. > >But all the old users connecting OK. All the new users you key in today >will be ok by tommorrow. Without more detailed information, it's hard to diagnose what might be going on. >I have system release 3.3. >Hiper ARC 1.1.11 >Hiper DSP T1/PRI 1.2.5 >NMC 16Meg 486 5.5.5 >TCM Windows 5.5.1 Current v90 ARC code is 4.1.72, I believe 4.0.30 is the current x2 ARC code >It started happening last Sat and Sun...Mon and Tue.. which is today. >I had one new customer yesterday.. it did not rscognize his username and >password right away, but started working about one and half hour later. > >I have another new one keyed in 14:33 pm today, it is not working yet >(16:37). >I just keep typing in his user name and password by using dial up every 15 >to 30 mins to see if it is working. I did not call this customer to set up >his internet account yet. I may have to wait till tomorrow. What are you using for radius(authentication) and how are you entering the users? Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World
Subject: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: T.J. Weber <lists@ipmedia.net>
Date: 1998-11-24 17:02:13
Okee, last night I posted this to one of 3com's internal newsgroups: ---- begin ---- This must seem a little odd, but I would like to know if there is a way I can hide users from showing up in the "list connections". I use RADIUS authentication, and I am wondering if there is a configuration value I can set for the specific users in my RADIUS 'users' file that will be sent back to my TC telling the HiPer not to list that user in *ANY* records (specifically the "list connections" output). Using RADIUS would be my best guess in this case, unless there is a way I can specify users to "hide" set directly via the HiPer config prompt. ---- end ---- No responce from 3com quite yet on this matter, three cents to the dollar odds that they won't respond with anything at all. I setup a Total Control box for my client in Chicago. They are a fairly big law firm that is providing internet access to their employees. I am not the only one with access to the total control box, there is someone from their IS department that monitors connections on the box itself. However, some of the partners in the firm don't want to be known that they are online at a specific time (strange request if you ask me, i think they don't want the guys in the IS dept. to know they are online). I also have another question regarding the TC boxes. In my configuration for the total control box, i set aside a pool of 24 IP addresses for dynamic assignment (we only have one operational DSP card). However, there are about 10 other users that I would like to assign a DYNAMIC IP from another pool (NOT the pool assigned to the total control). Once again, I think that this is something I have to setup in RADIUS, but I'm not sure how to do it. Please advise! So if anyone knows a simple solution to these problems that would be great! Thanks in advance, --t.j. \|||/ (o o) ooO-(_)-Ooo---------------------------------------------------------- T.J. Weber | Oxymoron: Microsoft Works Interplanetary Media |------------------------------------ phone: 847.205.5200 | WARNING: objects in mirror are fax: 847.205.5201 | dumber than they appear. e-mail: admin@ipmedia.net |------------------------------------ web: http://www.ipmedia.net | Out of my mind. Back in 5 minutes. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Two things are infinite: the universe and human stupidity; and I'm not so sure about the universe. (Albert Einstein) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subject: (usr-tc) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-24 17:16:49
How do you view the default routes on an arc that are set? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) default routes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-24 17:32:09
list rtab pre will show you the route table and the routes that is stored in flash krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 24 Nov 1998, Brian wrote: > > How do you view the default routes on an arc that are set? > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-24 18:33:05
So does anyone know if this will work? add ip defaultroute gateway 208.206.76.1 metric 1 add ip defaultroute gateway 208.206.76.2 metric 2 I want it so that if 208.206.76.1 is down, or fails, it will use the second route. Will that work? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-24 18:59:36
It doesnt show you all of them, only the one it is using. Watch, I start off with 208.206.76.1 as my default route. Then add 208.206.76.44, which then becomes the preffered route, then I drop 208.206.76.44 and it goes back to 208.206.76.1. Where in the arc can I get a list of all the currently added defaultroutes? Brian HiPer>> list rtab pre ROUTING TABLE PREFERRED ROUTES Destination Prot Age NextHop Metric Interface 0.0.0.0/0 REMOTE 25 208.206.76.1 1 eth:1 . . . HiPer>> add ip deFAULTROUTE gatEWAY 208.206.76.44 metric 1 HiPer>> list rtab pre ROUTING TABLE PREFERRED ROUTES Destination Prot Age NextHop Metric Interface 0.0.0.0/0 REMOTE 25 208.206.76.44 1 eth:1 . . . HiPer>> del ip deFAULTROUTE gatEWAY 208.206.76.44 HiPer>> list rtab pre ROUTING TABLE PREFERRED ROUTES Destination Prot Age NextHop Metric Interface 0.0.0.0/0 REMOTE 25 208.206.76.1 1 eth:1 . . . On Tue, 24 Nov 1998, Tatai SV Krishnan wrote: > list rtab pre > > will show you the route table and the routes that is stored in flash > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Tue, 24 Nov 1998, Brian wrote: > > > > > How do you view the default routes on an arc that are set? > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) default routes
From: John Rockwell <jrockwel@clarityconnect.com>
Date: 1998-11-24 19:40:01
'list ip defaultroute' should do the trick. At 05:16 PM 11/24/98 -0600, you wrote: > >How do you view the default routes on an arc that are set? > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Rockwell e-mail: jrockwel@clarityconnect.com Network Engineer Clarityconnect, Inc. Ithaca Area: (607)257-8268 Outside Ithaca Area: (888)322-4900 Try us: http://www.clarityconnect.com
Subject: Re: (usr-tc) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-24 20:42:57
how do you redistribute the default route? I mean the default route of my border router is different than what I would want the arc to hold.........I mean where does the redistributing start with? On my router I do: router rip version 2 timers basic 30 30 2 60 300 passive-interface Ethernet0/0 passive-interface Serial0/0.1 passive-interface Ethernet1/0 passive-interface Serial1/0.1 passive-interface FastEthernet3/0 network 208.206.76.0 no auto-summary how would I tell it to distribute 208.206.76.1 as the default gw for my arcs? > Depends...how is 208.206.76.1 connected? If its connected via ethernet, > how does the ARC *know* that it's down? Periodic ICMP echo packets to > it? Otherwise I don't know of any way of detecting that gateway is down > on an ethernet network (if its off a serial port, that's obviously > easily determined). Cisco has this same setup...if you're default > gateway is across an ethernet, the cisco has no way of knowing if the > gateway is down to switch to a floating default. The "solution" here is > to distribute your default route in your routing protocol. I know > that's not the *best* solution, but its about the only way to handle > this on an ethernet network that I'm aware of. If you distribute > default in your routing protocol, that's also one less config option > that you have to set on your new boxes when you set them up. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) default routes
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-24 21:28:19
Thus spake Brian >So does anyone know if this will work? >add ip defaultroute gateway 208.206.76.1 metric 1 >add ip defaultroute gateway 208.206.76.2 metric 2 >I want it so that if 208.206.76.1 is down, or fails, it will use the >second route. Will that work? Depends...how is 208.206.76.1 connected? If its connected via ethernet, how does the ARC *know* that it's down? Periodic ICMP echo packets to it? Otherwise I don't know of any way of detecting that gateway is down on an ethernet network (if its off a serial port, that's obviously easily determined). Cisco has this same setup...if you're default gateway is across an ethernet, the cisco has no way of knowing if the gateway is down to switch to a floating default. The "solution" here is to distribute your default route in your routing protocol. I know that's not the *best* solution, but its about the only way to handle this on an ethernet network that I'm aware of. If you distribute default in your routing protocol, that's also one less config option that you have to set on your new boxes when you set them up. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: (usr-tc) For Sale New NMC Card
From: Brian Gordon <brian@westelcom.com>
Date: 1998-11-24 22:44:59
One NMC full memory configuration (came with a trade up bundle) Still in sealed static bag - 999.99 or best offer. Please email Brian - flash@highlogic.com
Subject: Re: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-25 07:24:51
Tatai SV Krishnan was heard to say: >> This must seem a little odd, but I would like to know if there is a way >> I can hide users from showing up in the "list connections". I use >> RADIUS authentication, and I am wondering if there is a configuration >> value I can set for the specific users in my RADIUS 'users' file that >> will be sent back to my TC telling the HiPer not to list that user in >> *ANY* records (specifically the "list connections" output). ... >If you want however you can set ppp passthrough meaning you can disable >authentication for users and use the default user for all calls for say >ppp. This way the only user who will be seen in the hIper arc is always >the default user Hmm, this makes me wonder what happens if the RADIUS server rewrites the username in the access-accept. --Ricky
Subject: Re: (usr-tc) default routes
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-25 07:47:56
Thus spake Brian >how do you redistribute the default route? I mean the default route of my >border router is different than what I would want the arc to >hold.........I mean where does the redistributing start with? Check out "default-information originate" or something along those lines, I think that will tell your routing protocol (RIP in this case) to announce the 0.0.0.0 route, which it typically doesn't do. You can check on CCO for the specifics of this announcement. You can do all sorts of cool stuff with it, like only announce it if a route-map is satisfied and stuff...I use a variation of this a bit within my OSPF domain to provide redundancy for Internet connectivity. T3 comes into one router, our T1's into another, one of the routers on that network isn't beefy enough to handle full BGP routes, so I gave it a static default route with a high administrative distance (above the admin distance of OSPF), then my cisco which has the T1's has default-information originate with a route-map on it in OSPF. The route-map specifies that if it *doesn't* see the /30 for the IP addresses on the T3 that it *should* advertise the default out in OSPF. This means that the wimpy router that can't do OSPF will switch over its default to the T1 router if the T3 or the T3 router dies. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) default routes
From: bryan s. blank <bryan@supernet.net>
Date: 1998-11-25 08:02:34
|o| how do you redistribute the default route? I mean the default route of my |o| border router is different than what I would want the arc to |o| hold.........I mean where does the redistributing start with? default-information originate in the router process with a route map attached should do it take care |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|
Subject: Re: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-25 09:24:52
On Wed, 25 Nov 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >> This must seem a little odd, but I would like to know if there is a way > >> I can hide users from showing up in the "list connections". I use > >> RADIUS authentication, and I am wondering if there is a configuration > >> value I can set for the specific users in my RADIUS 'users' file that > >> will be sent back to my TC telling the HiPer not to list that user in > >> *ANY* records (specifically the "list connections" output). > ... > >If you want however you can set ppp passthrough meaning you can disable > >authentication for users and use the default user for all calls for say > >ppp. This way the only user who will be seen in the hIper arc is always > >the default user > > Hmm, this makes me wonder what happens if the RADIUS server rewrites the > username in the access-accept. > Radius does not get a access-request here - Just the accounting packet is sent. krish > --Ricky > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: RE: (usr-tc) default routes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-25 09:25:36
_list rtab en krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 25 Nov 1998, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > >Sent: Tuesday, November 24, 1998 5:32 PM > >To: Brian > >Cc: USRobotics TC Mailing List > >Subject: Re: (usr-tc) default routes > > > > > >list rtab pre > > > >will show you the route table and the routes that is stored in flash > > I tried this. list rtab preferred did not show me the second default route > i added. However, if i delete the primary default route the one I had > enetered before with a metric of 2 showed up under list rtab preferred and > list ip routes. > > > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Tue, 24 Nov 1998, Brian wrote: > > > > > How do you view the default routes on an arc that are set? > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) default routes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 09:37:54
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan >Sent: Tuesday, November 24, 1998 5:32 PM >To: Brian >Cc: USRobotics TC Mailing List >Subject: Re: (usr-tc) default routes > > >list rtab pre > >will show you the route table and the routes that is stored in flash I tried this. list rtab preferred did not show me the second default route i added. However, if i delete the primary default route the one I had enetered before with a metric of 2 showed up under list rtab preferred and list ip routes. > >krish > >----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 24 Nov 1998, Brian wrote: > > How do you view the default routes on an arc that are set? > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) default routes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 09:40:29
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian >Sent: Tuesday, November 24, 1998 6:33 PM >To: USRobotics TC Mailing List >Subject: (usr-tc) default routes > > > >So does anyone know if this will work? > >add ip defaultroute gateway 208.206.76.1 metric 1 >add ip defaultroute gateway 208.206.76.2 metric 2 > >I want it so that if 208.206.76.1 is down, or fails, it will use the >second route. Will that work? I tried this here. I did get it to work, but there seemed to be a little lag on how fast the second route took over when I made the first one un-available. Seemed to be roughly 60 seconds. > >Brian > > >-------------------------------------------------------------------------- >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) default routes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 09:40:30
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian >Sent: Tuesday, November 24, 1998 7:00 PM >To: Tatai SV Krishnan >Cc: USRobotics TC Mailing List >Subject: Re: (usr-tc) default routes > > > >It doesnt show you all of them, only the one it is using. Watch, I start >off with 208.206.76.1 as my default route. Then add 208.206.76.44, which >then becomes the preffered route, then I drop 208.206.76.44 and it goes >back to 208.206.76.1. Did you specify a metric of 2 for the second entry? When i did it did not over ride the primary until the primary went down Where in the arc can I get a list of all the >currently added defaultroutes? > >Brian > > >HiPer>> list rtab pre >ROUTING TABLE PREFERRED ROUTES >Destination Prot Age NextHop Metric Interface > 0.0.0.0/0 REMOTE 25 208.206.76.1 1 eth:1 >. >. >. > >HiPer>> add ip deFAULTROUTE gatEWAY 208.206.76.44 metric 1 >HiPer>> list rtab pre >ROUTING TABLE PREFERRED ROUTES >Destination Prot Age NextHop Metric Interface > 0.0.0.0/0 REMOTE 25 208.206.76.44 1 eth:1 >. >. >. >HiPer>> del ip deFAULTROUTE gatEWAY 208.206.76.44 >HiPer>> list rtab pre >ROUTING TABLE PREFERRED ROUTES >Destination Prot Age NextHop Metric Interface > 0.0.0.0/0 REMOTE 25 208.206.76.1 1 eth:1 >. >. >. > > > > > > >On Tue, 24 Nov 1998, Tatai SV Krishnan wrote: > >> list rtab pre >> >> will show you the route table and the routes that is stored in flash >> >> krish >> >> ----------------------------------------- >> \ T.S.V. Krishnan \ >> \ Network System Engineer \ ( : - : ) >> \ 3Com ............ \ >> ----------------------------------------------/ >> tkrishna@bubba.ae.usr.com >> ----------------------------/ http://interproc.ae.usr.com ----/ >> The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Tue, 24 Nov 1998, Brian wrote: > > > > > How do you view the default routes on an arc that are set? > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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) multiple default routes
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-11-25 09:44:56
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire |Sent: Tuesday, November 24, 1998 4:48 PM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) multiple default routes | | |You may be able to add additional default routes by specifying a metric of 2 |for the second and 3 for the 3rd. I set this up on one of ours. Although I |could not verify the setting took place I was able to see one of my backup |default routes take over when I deleted the original one. Try it Maybe you |could even set up a second eth and make the default route entry a metric of |2 for it and unplug eth 1 to see if the default route for eth 2 shows up and |takes over. | This is the correct way to do it.. You can see the routes by typing "_li rt en" It will not show up in your routing table untill your default route becomes unreachable. A request has already been make to make this show in the table without a special command. -M
Subject: Re: (usr-tc) default routes
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-11-25 10:39:53
I think "list ip routes" will list all the routes regardless of preference. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> _list rtab en krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 25 Nov 1998, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > >Sent: Tuesday, November 24, 1998 5:32 PM > >To: Brian > >Cc: USRobotics TC Mailing List > >Subject: Re: (usr-tc) default routes > > > > > >list rtab pre > > > >will show you the route table and the routes that is stored in flash > > I tried this. list rtab preferred did not show me the second default route > i added. However, if i delete the primary default route the one I had > enetered before with a metric of 2 showed up under list rtab preferred and > list ip routes. > > > >krish
Subject: RE: (usr-tc) default routes
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 10:46:12
No, it won't >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Peter D. Mayer >Sent: Wednesday, November 25, 1998 9:40 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) default routes > > >I think "list ip routes" will list all the routes regardless of preference. > >Peter D. Mayer >NetWalk System Administrator >dmayer@netwalk.com > >-----Original Message----- >From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> >To: Brian K McIntire <bmcintire@commnet.com> >Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Wednesday, November 25, 1998 10:20 AM >Subject: RE: (usr-tc) default routes > > >_list rtab en > >krish > >----------------------------------------- >\ T.S.V. Krishnan \ >\ Network System Engineer \ ( : - : ) > \ 3Com ............ \ >----------------------------------------------/ >tkrishna@bubba.ae.usr.com >----------------------------/ http://interproc.ae.usr.com ----/ >The Yadda Yadda Search - for simple anwers - >http://interproc.ae.usr.com/tkb.html >-------------------------------------------------------------------------\ >Any Sufficiently advanced bug is indistinguishable for a feature. >- Rick Kulawiec >-------------------------------------------------------------------------/ > >On Wed, 25 Nov 1998, Brian K McIntire wrote: > >> >-----Original Message----- >> >From: owner-usr-tc@lists.xmission.com >> >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan >> >Sent: Tuesday, November 24, 1998 5:32 PM >> >To: Brian >> >Cc: USRobotics TC Mailing List >> >Subject: Re: (usr-tc) default routes >> > >> > >> >list rtab pre >> > >> >will show you the route table and the routes that is stored in flash >> >> I tried this. list rtab preferred did not show me the second default >route >> i added. However, if i delete the primary default route the one I had >> enetered before with a metric of 2 showed up under list rtab >preferred and >> list ip routes. >> > >> >krish > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >
Subject: (usr-tc) Global Villiage Modems?
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-11-25 10:52:25
Whats the Deal with Global Villiage modems and the Hiper DSP, we are running the latest code and it seems like people are getting really crappy connections speeds etc. Help Needed here. Brian Gordon, MCP Network Administrator Westelcom Internet / Westelcom Computer 518-566-8376 Voice 518-566-8348 Fax administrator@westelcom.com http://home.westelcom.com
Subject: (usr-tc) Telepath modem running 1.41.017
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 10:56:16
Does anyone know of issues with this particular modem. I'm working with a customer running 1.2.5 on his DSP's and 4.1.72 - 7 on his HiPer ARC. With the same user account I can connect 20 times out of 20 with my courier. The client that has a Telepath connects 1 out of every 3-7 times.
Subject: Re: (usr-tc) connecting a cisco router to total control ISDN
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-25 11:07:58
> Hi All > > I have a strange one > > Cisco 1603 router trying to connect to a totalcontrol chassis > > we can get the cisco to connect and authenticate using pap > but we never see any accounting data in the radius logs so the cisco just > hangs up Why would the cisco care about accounting data in radius? > > is there anything strange about a cisco connecting to usr kit? > Check yadda yadda http://interproc.ae.usr.com/tkb.html search for lan-to-lan you will the config for hiper/netserver/cisco krish > there are 2 netserver based and 1 hyper based racks here and all do > the same thing. > > TIA > > Steve Lalonde > Systems Manager > ENTANET International Ltd > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) A rather nasty problem with NMCs
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-11-25 12:04:20
Here's a fun one: NMC code 5.5.5: I started adding authorized hosts (via TCM) to one of my chassis. I came to add two IPs: 192.168.1.1 255.255.255.255 description1 192.168.1.2 255.255.255.255 description2 as soon as I put in the second one, boom, I lost the NMC. 'lo and behold, the two community strings on the card reset themselves to public/private. Wtf? It happened on two different chassis' (hiper boxes), where I put in two consecutive IPs from the same /24 (as above). If put IPs in a different order (Ie: mix what /24 each host is in), it works fine. This behavior is still rather alarming. If someone @ 3Com can test this out a little more thoroughly.. It's probably not critical, though. You can't set authorized hosts w/o having the original/good read/write strings to begin with, but the fact that they were reset to public/private w/o actually being set manually.. *shrug* -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 There isn't any reason why Linux can't be implemented as an enterprise computing solution. Find out what you've been missing while you've been rebooting Windows NT. -- Eric Hammond
Subject: RE: (usr-tc) #2 new user log in problem with v.90
From: Gorkem Yuksel <gorkem@gncom.com>
Date: 1998-11-25 12:58:57
Thank you for responding my help call. It happened several times last few days, but for example.. I keyed in a new user( ie. kim225) yesterday 14:33pm. Before I call my customer and start setting up, I tried to log in using this new customers user name(normally I don't do this), but rejected. The reason is user name and password is not valid. I am using my other computer(windows 95) in my office to dial. So it dials and makes handshake and start verifying user name and pass word. And it gives me an error messge window and ask me enter password again and again..... and disconnects. When I try to make connection with any other old usernames, it connects right away. So I go to my UNIX(BSDI 2.0) machine, open etc/raddb directory and check users file, surely new user kim225 is there on top of other files. I go to etc , check password file and see kim225 also. When I had this same problems about a month ago, about 2 weeks after installing new v.90 code, I called and begged to connect to 3Com's tech support(since I do not have service contract). After several tries, they helped me out. But the guy connected to our server and corrected and did not tell me exactly how it wsa done. I asked for manuals and he tried to send by e-mail but it was too big, he had problems sending it, so I never got the manuals for Hiper Chassis. I can open up hiper chassis and type in "list connection" and it gives me who is connected.... that is all I know... He said two things, not 100% sure though... 1) reboot the whole chassis ... from Total Control manager (I can open this total control manager and see their connection speed and things, and tha is about it) Can you tell me how to reboot the whole chassis....(it will disconnect everybody, that is how much I know) And it did not solve the problem, he said he is going to reset the 2nd card(I have only two DSP cards) seperately. and it worked. But he did not tell me how. I guess I should reboot from Hiper>> prompt, so I tried Hyper>> reset interface slot:2/mod:[1-23] but it gave me error message.... should I type in modems? or authentication instead fo interface? I key in users in BATS accounting system in UNIX. How do I reset/reload radius daemon in UNIX machine? or is it in TCM? Thanks in advance. Ken.
Subject: Re: (usr-tc) Telepath modem running 1.41.017
From: Jerry Kalligonis <jerryk@blazenet.net>
Date: 1998-11-25 13:05:28
Just thought I would add that I experienced the same problem with this version of code. Using mon ppp it seemed like it was experiencing the LCP problem that web tv and imac's had. It did not get up to the authentication stage. I'm still running 4.0.30 on our production chassis' this being one of the reasons... Jerry At 10:56 AM 11/25/98 -0600, you wrote: >Does anyone know of issues with this particular modem. I'm working with a >customer running 1.2.5 on his DSP's and 4.1.72 - 7 on his HiPer ARC. With >the same user account I can connect 20 times out of 20 with my courier. The >client that has a Telepath connects 1 out of every 3-7 times. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Telepath modem running 1.41.017
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 13:30:53
>Just thought I would add that I experienced the same problem with this >version of code. Using mon ppp it seemed like it was experiencing the LCP >problem that web TV and imac's had. It did not get up to the >authentication stage. I'm still running 4.0.30 on our production chassis' >this being one of the reasons... > Thanks, that does help. We are seeing exactly the same thing on ours. The user attempts to connect, handshakes and goes no further. Monitor radius shows nothing. It just seems to be hanging. I guess I'll call 3COM and open a tkt with them. Thought I might have some bad code on that modem but if you are seeing it too then maybe it's a bug with something else. Thanks again >Jerry > >At 10:56 AM 11/25/98 -0600, you wrote: >>Does anyone know of issues with this particular modem. I'm working with a >>customer running 1.2.5 on his DSP's and 4.1.72 - 7 on his HiPer ARC. With >>the same user account I can connect 20 times out of 20 with my >courier. The >>client that has a Telepath connects 1 out of every 3-7 times.
Subject: (usr-tc) Edgeserver call-back only at 28.8 ??
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-11-25 13:31:34
Hi, We have deployed a TC at a customers site which he will use with call-back feature. This rack is laid out the following way : USR-TC 70amp chassis w/ fantray 1 DUAL E1-PRI card 4 Quad modem single-sided (software version 5.10.9) 1 Edgeserver (486 based) version 1.5.0 1 NMC (software version 5.5.5) We use win NT RAS for dial-up (due to SecurID) and would like to be able top set up a callback system. This works fine as long as the call is V.90. With ISDN, the call-in is ok, but the call-back is V.34, which is not good at all... Is there something to configure in the edgeserver so that the call out will be made with the same protocol (ISDN or analog) as the call in ? RADIUS is NOT used, we log into an NT domain through the edgeserver, using NT domain accounts, and using RADIUS with this configuration is not an option, as we do not have either Netserver or HiperARC. One option available is that all calls out be ISDN, I know I could set that up by selecting stuff in the quad modem config, bu I'd rather not experiment with this, has anyone ever done this, or has a configuration template for the quads ? I'm sorry if this FAQ stuff, but 'till now there is no FAQ ;-) and my experience is mostly with HiPer chassis... Thanks for any help / pointers, Robert
Subject: Re: (usr-tc) A rather nasty problem with NMCs
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-11-25 13:46:18
Ignore it. I'm officially a dumbass. I locked myself out of my own NMCs. *laf* It's unfortunate that you have to add each host one at a time, instead of an entire list of IPs and THEN setting the whole lot of them. My brain is in Cisco-mode this morning. =o -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 There isn't any reason why Linux can't be implemented as an enterprise computing solution. Find out what you've been missing while you've been rebooting Windows NT. -- Eric Hammond
Subject: (usr-tc) FW: (CSO TotalService) RE: (CSO TotalService) Dial out test from HiPer DSP (T1 channel)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 13:52:13
-----Original Message----- [mailto:"Nair, Shibu (MED, Wipro Systems, Inc)"@totalservice.usr.com] Sent: Wednesday, November 25, 1998 10:53 AM HiPer DSP (T1 channel) Hi Since i have not get any reply iam sending this again with more details... I have tried dialing from the mdm prompt of Hiper DSP card. As soon as i tried i checked the at status on the tslot device on HiPER DSP. Initially it gave dialout and then it connection out which is shown below, (This is the case of when i dial out to a normal telephone number) span1/tslot1> displ atst Tslot Status Modem Status Call ID Action Q931 Connect Srvc State Queued Ref 01 Conn Out 001 IS 0x00040001 None 0x00000000 Still when i try dialing to a unix host iam not getting the unix host prompt. and mdm> prompt is returning back... Hope somebody can help me on this, My span card configuration is shown below, correct me if iam wrong.... span1> displ ccrcfig Span1 Configured Signal Mode is (sigmode): ROBBED BIT Span1 Signal Mode Active is: ROBBED BIT Span1 DNIS Enable is (dnisena): DNIS ADDRESS Span1 Dial In Out Trunk Start (diotrst): WINK Span1 Dial In Address ACK Wink (daackwnk): ACK WINK DISABLED Span1 Dial Out Address Delay (doadrdly): 70 milliseconds Span1 Dial In Out Trunk Type (dtrnktyp): E&M TYPE II Span1 Configured Switch Type is (swtype): 5ESS Span1 Switch Type Active is: 5ESS Span1 Idle Byte is (idlebyte): 0xFE Span1 Ana Calls Blocked Err Code (ancbec): 58 Span1 Digi Calls Blocked Err Code (dcbec): 58 Span1 No IGWS Avail Err Code (noigwsav): 58 Span1 Chan Blocked Err Code (chanblck): 58 Span1 Block Call Type is (blcaltyp): BLOCK NONE Span1 Tone Type is (tonetype): DTMF TONE Span1 Number Of DTMF Tones is (numdtmft): 5 Span1 Dial Out Select Direction (dseldir): DOWN Span1 Dial Out Next Timeslot (dntslot): 24 Span1 Channelized T1 Profile (cprofile): E&M TYPE II GENERIC PROFILE Regards Shibu ---------- From: "Nair, Shibu (MED, Wipro Systems, Inc)"@totalservice.usr.com[SMTP:"Nair, Shibu (MED, Wipro Systems, Inc)"@totalservice.usr.com] Reply To: user-forum-totalcontrol@totalservice.usr.com Sent: Tuesday, November 24, 1998 2:01 PM Subject: (CSO TOTALservice) Dial out test from HiPer DSP (T1 channel) card Hi I was testing my T1 ckt using atdt command on HiPer DSP card console. First i diald to my telephone number(to confirm) using atdt command from T1 card prompt, I did the following for the same... >chdev mdm mdm1> atdt32853 My telephone ring for a while and disconnect... Now i tried to dial to a portmaster(which is configured for dialup) from HiPer DSP card prompt. I have followed the above steps with appropriate dialup number. But i did not get the loging prompt of the machine.... Did i do anything wrong....? How do i see the status of the dilaup channel..? Pls help me on this .... (Pls note that, i have tested using console which is connected to HiPer DSP card). Regards Shibu
Subject: (usr-tc) 4.1.72-7(?) code question
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-25 13:58:10
The 4.1.72-7 HARC code fixes document mentions a couple of fixes wrt MPIP. Can someone at USR/3Com check out trouble ticket 58316 and let me know if these fixes address this problem? If these fixes address this problem, then one of the fixes mentions the requirement of a new version of code on the NETServer (which I understand is going to be required to fix the issues in 58316), if this fix relates to this trouble ticket, when will the corresponding NETServer code be available? I am assuming it will be a ER/SR for 3.8.1....and I'm assuming that it will be later than 3.8.90 (ie, 3.8.89 or lower number) as I have 3.8.90 and it didn't fix the problem. Thanks -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: MegaZone <megazone@megazone.org>
Date: 1998-11-25 14:13:26
Once upon a time David Bolen shaped the electrons to say... >Hmm, since a Username attribute isn't even permitted in an >Access-Accept (see RFC2138, although I think I saw some e-mail >comments about changing that to permit it fly by recently), other than Yes, I believe it will be permitted in the final version of the RFC. If I'm recalling my ietf-radius threads properly. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!
Subject: (usr-tc) HiPer ARC 4.0.30
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 14:28:23
I have a customer with 1.2.5 on his DSP's and 4.0.30 on his HiPer ARC. NMC is running 5.5.5. It seems, each day, 7-8 modems change from up up to down up. When I reset the DSP the problem goes away just to come back another day. :( I don't remember if there was a bug relating to something like this in 4.0.30. If there was, I can use that as a reason to make the upgrade happen. I would appreciate any help on this. Thank you.
Subject: RE: (usr-tc) Scripting the config of a HARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 14:57:52
See chapter 10-150 of the 4.1 HiPer ARC user manual. There is a good sized example in there >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Eric >Sent: Friday, November 20, 1998 4:49 PM >To: TC List >Subject: (usr-tc) Scripting the config of a HARC > > >How can you script the configuration of a HARC? I was told that you can >TFTP the file onto the HARC and then type "do filename" > >I'd like to be able to easily batch setup a HARC. With easy prompts, >like: > >-What is my IP address? >-What is my netmask? >-What is my gateway? >etc. > >Can someone send me some instructions on how to do this and maybe a sample >script? > >Eric >--- >Eric J. Lorenzo >Sr. Field Engineer >lorenzo@ispchannel.com >v:650.237.1465 >http://www.ISPchannel.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: (usr-tc) rcvdGatewayDiscCmd
From: Charles Sprickman <spork@inch.com>
Date: 1998-11-25 14:59:06
Hi, From what I understand "rcvdGatewayDiscCmd" means that the ARC/Netserver has essentially dropped DTR on a modem to cause a hangup. What are the various reasons a Netserver might do this besides idle-timeout and session-timeout? I'm all of a sudden seeing lots of these on all my chassis. While it's implied that this is the Netserver dropping the call for a reason, is it possible that a line drop could result in this cause code (ie: Netserver realizes call is gone and terminates it)?? Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=
Subject: Re: (usr-tc) 4.1.72-7(?) code question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-25 15:17:33
On Wed, 25 Nov 1998, Jeff Mcadams wrote: > The 4.1.72-7 HARC code fixes document mentions a couple of fixes wrt > MPIP. Can someone at USR/3Com check out trouble ticket 58316 and let me > know if these fixes address this problem? If these fixes address this > problem, then one of the fixes mentions the requirement of a new version > of code on the NETServer (which I understand is going to be required to > fix the issues in 58316), if this fix relates to this trouble ticket, > when will the corresponding NETServer code be available? I am assuming > it will be a ER/SR for 3.8.1....and I'm assuming that it will be later > than 3.8.90 (ie, 3.8.89 or lower number) as I have 3.8.90 and it didn't > fix the problem. The problem that HiPer arc fixes with MPIP is 1. VTP problem 2. Deregistration problem In the first case the VTP problem - the hiper arc would not send correct data over the tunnel - meaning users after sometime would not be able to make a MPIP multilink call The second problem is is how to deregister a MPIP link. Some clients would not send deregistration properlly - meaning the NeTServer code changed its way of MPIP operation and that cause the HiPer arc not to be able to deregister the link properlly. The NeTServer code you have does have the fixes but there was some additional fixes in a subsequent ER you need that code. krish > > Thanks > -- > 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) Seeking a way to 'hide' users from "list connections"
From: David Bolen <db3l@ans.net>
Date: 1998-11-25 15:26:25
Ricky Beam <jfbeam@Interpath.net> writes: > Hmm, this makes me wonder what happens if the RADIUS server rewrites the > username in the access-accept. Hmm, since a Username attribute isn't even permitted in an Access-Accept (see RFC2138, although I think I saw some e-mail comments about changing that to permit it fly by recently), other than ignoring it, I'm guessing that nothing would happen :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: (usr-tc) Netserver reboot
From: Martin Lathoud <nytral@endirect.qc.ca>
Date: 1998-11-25 15:29:32
Hi, I am new to this list and since web archives don't seem to be up, I will ask here my question: I am experiencing self-reboot from my Netserver card (3.8.1) used only for dialin PPP, from once a day to once a week. Sometimes it hangs, but more generaly I only see that lights turn red then blinking green.. It is running with 20MB. I would like to know if someone already met this kind of problem and if I have a way to be sure that it's an hardware failure, not sofware (support didn't find anything so they suggest I replace the card... they are soo helpful.. not! ). TIA, Martin
Subject: (usr-tc) Dial out from HiPer DSP card
From: MED, Wipro Systems, Inc <"nair, shibu (med, wipro systems, inc)">
Date: 1998-11-25 15:41:41
Hi Iam new to Total Control Enterprise Network Hub. I have configured Channelised T1 ckt for the HiPer DSP card. Since i do no have Total Control Manager software, iam testing using the console connection. I did the following test to ensure the dialout from the HiPerDSP ... 1) I have dialed to my local telephone and received the dial tone.. >mdm <telephone number> 2) I have dialed to a machine which has dialup setup At this time it is trying for dialing out and comes back to the mdm prompt. Iam not getting machine access when i dial.... mdm2> atdt<machine dialup number> mdm2> HiPer DSP Rev. 1.0.7 Pls help on this problem.... Regards Shibu
Subject: RE: (usr-tc) rcvdGatewayDiscCmd
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-25 15:45:21
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman >Sent: Wednesday, November 25, 1998 1:59 PM >To: usr-tc@xmission.com >Subject: (usr-tc) rcvdGatewayDiscCmd > > >Hi, > >>From what I understand "rcvdGatewayDiscCmd" means that the ARC/Netserver >has essentially dropped DTR on a modem to cause a hangup. Not exactly. Remember the NMC is the one reporting to you a "received gateway disconnect command" What this means is the HiPer ARC told the NMC the user has disconnected before the NMC could get the info from somewhere else. >What are the >various reasons a NetServer might do this besides idle-timeout and >session-timeout? I'm all of a sudden seeing lots of these on all my >chassis. > >While it's implied that this is the NetServer dropping the call for a >reason, is it possible that a line drop could result in this cause code >(ie: Netserver realizes call is gone and terminates it)?? Doubt it. In that case the NMC would probably hear from the modem the call disconnected from before it heard from the Hiper ARC. I'm definately not an expert on this but that is the way it was explained to me by NetWork Engineering so if my answer is wrong it is because I was mis-informed. > >Thanks, > >Charles > >=-----------------= = >| Charles Sprickman Internet Channel | >| INCH System Administration Team (212)243-5200 | >| spork@inch.com access@inch.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) Dial out from HiPer DSP card
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-25 16:04:14
On Wed, 25 Nov 1998, Nair, Shibu (MED, Wipro Systems, Inc) wrote: > Hi > > Iam new to Total Control Enterprise Network Hub. > > I have configured Channelised T1 ckt for the HiPer DSP card. > > Since i do no have Total Control Manager software, iam testing using the > console connection. > > I did the following test to ensure the dialout from the HiPerDSP ... > > 1) I have dialed to my local telephone and received the dial tone.. > >mdm <telephone number> > > 2) I have dialed to a machine which has dialup setup > > At this time it is trying for dialing out and comes back to the mdm > prompt. > > Iam not getting machine access when i dial.... The DSP cards also needs a packetbus card in the chassis like the hiper arc or the NETServer - Do you have those? krish > > mdm2> atdt<machine dialup number> > mdm2> > > HiPer DSP Rev. 1.0.7 > > Pls help on this problem.... > > Regards > Shibu > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Scripting the config of a HARC
From: norm_miller@3com.com
Date: 1998-11-25 17:07:07
FYI, Just some things I use. As you may, or may not know, the ARC has a very handy little command called DO. With the DO command you can execute a text file of commands, any ARC commands. It also has TFTP capability which most 3COM products have. What this allows you to do is TFTP several versions of the ARC code onto the ARC and swap back and forth between versions by copying the file on the ARC to netserve.dmf then rebooting the ARC. When the ARC comes up it sees the netserve.dmf file and loads it. To swap back, copy the original file to netserve.dmf, reboot etc. You should be able to keep 2 to 3 different code files on the ARC at a time if needed. Depends on space. To get the code file to the ARC you will need a TFTP client package. TFTP is included in UNIX, however very few of us carry around a laptop with Solaris or Linux on it. To get around this minor inconvenience 3COM in its infinite wisdom (in the person of Dan Gill) wrote a little Windows TFTP application that we give away to all of our customers that request it. It is called 3CServer. You can pull it off the 3Com web site Go to www.3com.com and search on 3CServer. Getting back to the DO command, If you want to, you can create multiple ARC configuration files. Thou shalt not use Notepad, Edit, or WordPad. You can use Vi or Word. Just make sure that if you use Word that you save them using the format Text Only. Otherwise, Word will add a carriage return line feed that the ARC does not like. What I use this for is that in the lab, I use a variety of different configs, depending on what particular feature I am trying to test. I create the config files in Word, and save them with the Text Only format and then, using 3CServer, TFTP the files down to the ARC. When ready to run a particular test do a DEL CONFIG on the ARC and it deletes all .cfg files and reboots. Key point: DO NOT save the config files with a .cfg extension. If you do, then when you issue the delete config command, you also lose your text files with the config commands. Save it with a .txt or anything as long as it is not .cfg. When the system comes up say No to the quick config and do a DO textfilename.txt The system is now configured. I always have a SAVE ALL as the last command in the file and I reboot before running any tests. Below is a sample config file: This may be helpful in creating canned configs for installs. If someone was good at writing Word forms to populate the site and ip variables this may save quite a bit of time on installs. regards, /norm Below is a sample config file: Cut here ======================= set system name "SysName" transmit_authentication_name "SysName" set system location "SysLocation" set system contact "NotMe" add snmp community public address 0.0.0.0 access RW enable security_option remote_user_administration telnet add user "!root" password "WhatEver" type login,manage add ip network ip interface eth:1 address 220.10.10.2/C frame ethernet_ii enable no enable ip network ip add ip defaultroute gateway 220.10.10.1 metric 1 add tftp client 0.0.0.0 set authentication primary_server xxx.xxx.xxx.xxx set accounting primary_server xxx.xxx.xxx.xxx primary_secret MySecret set accounting attribute_style netserver set ntp primary_server xxx.xxx.xxx.xxx enable ntp reconfigure ip network ip interface eth:1 set ip network ip routing_protocol ripv1 add ip pool ippool initial_pool_address 130.20.20.2 size 128 set authentication primary_secret MySecret disable authentication local enable authentication hint_assigned set modem_group all connection_type no_prompt message "\b" set ppp session_start_message enable service_loss_busyout radius disable telnet trying_message delete user adm set interface eth:1 filter_access on enable ip proxy_arp_all_dialin set command history 50 save all reboot after the save. Cut here ======================= "Eric" <elorenzo@mediacity.com> on 11/20/98 05:49:07 PM Please respond to usr-tc@lists.xmission.com cc: (Norm Miller/US/3Com) How can you script the configuration of a HARC? I was told that you can TFTP the file onto the HARC and then type "do filename" I'd like to be able to easily batch setup a HARC. With easy prompts, like: -What is my IP address? -What is my netmask? -What is my gateway? etc. Can someone send me some instructions on how to do this and maybe a sample script? Eric --- Eric J. Lorenzo Sr. Field Engineer lorenzo@ispchannel.com v:650.237.1465 http://www.ISPchannel.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: (usr-tc) Trade HiperARC for HiperDSP
From: billt@dscga.com
Date: 1998-11-25 17:14:26
I have an extra Hiperarc card set I'd love to trade for a HiperDSP card. Anyone interested?
Subject: Re: (usr-tc) new user log in problem with v.90
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-26 10:59:06
On Tue, 24 Nov 1998, Gorkem Yuksel wrote: > Hi! > Everybody. > > I am a new guy on the block.(small ISP) > > I am having some problems with new user's logging in. > > It does not allow to logging in right away when it comes to new users. > > Sometimes it started working 7 hours later, 1.5 hours later depending on > the Hiper DSP's mood, I guess. > > But all the old users connecting OK. All the new users you key in today > will be ok by tommorrow. > > I have TCM, Hiper DSP cards, NMC card, Hiper ARC card, about 6 month old. > We upgraded to v.90 a month ago, it worked fine I guess. > (or I did not have customers who wanted an instant setup???) > > I have system release 3.3. > Hiper ARC 1.1.11 > Hiper DSP T1/PRI 1.2.5 > NMC 16Meg 486 5.5.5 > TCM Windows 5.5.1 Hiper arc version 1.1.11 does not sound right. Guess you have 4.1.11. When you see this problem can you get a trace - you can either do mon ppp or mon radius from the hiper arc. That will tell us what the problem is. krish > > I e-mailed for help to 3Com but no answer for 3 days... > > I do not have tech support contract...too much money.. > > It started happening last Sat and Sun...Mon and Tue.. which is today. > I had one new customer yesterday.. it did not rscognize his username and > password right away, but started working about one and half hour later. > > I have another new one keyed in 14:33 pm today, it is not working yet > (16:37). > I just keep typing in his user name and password by using dial up every 15 > to 30 mins to see if it is working. I did not call this customer to set up > his internet account yet. I may have to wait till tomorrow. > > Anybody have any good sugestions, please write me, I will appreciate it > very much. > > Please write all the detailed instructions, since I am not that good.. > > > Ken. 905-826-0737 ken@gncom.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) new user log in problem with v.90
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-26 12:02:10
On Thu, 26 Nov 1998, Gorkem Yuksel wrote: > How do I do mom ppp and mom radius??? > > just type "mom ppp" at the hiper>> prompt?? When you recreate the problem, logon to the HiPer arc as admin user. Type mon ppp It will give you a menu - you can monitor based on user name choose that and capture the data it sends. Then make another call and this type on the hiper arc type mon radius that also provides you with a menu. Choose the user option and capture the same. Once you get this capture, send it to me and also let me know the version number of the hiper arc, DSP and also what radius you are using. regards krish > > Ken. > > ---------- > From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] > Reply To: usr-tc@lists.xmission.com > Sent: Thursday, November 26, 1998 11:59 AM > To: Gorkem Yuksel > Cc: 'usr-tc@lists.xmission.com' > Subject: Re: (usr-tc) new user log in problem with v.90 > > On Tue, 24 Nov 1998, Gorkem Yuksel wrote: > > > Hi! > > Everybody. > > > > I am a new guy on the block.(small ISP) > > > > I am having some problems with new user's logging in. > > > > It does not allow to logging in right away when it comes to new users. > > > > Sometimes it started working 7 hours later, 1.5 hours later depending on > > the Hiper DSP's mood, I guess. > > > > But all the old users connecting OK. All the new users you key in today > > will be ok by tommorrow. > > > > I have TCM, Hiper DSP cards, NMC card, Hiper ARC card, about 6 month old. > > We upgraded to v.90 a month ago, it worked fine I guess. > > (or I did not have customers who wanted an instant setup???) > > > > I have system release 3.3. > > Hiper ARC 1.1.11 > > Hiper DSP T1/PRI 1.2.5 > > NMC 16Meg 486 5.5.5 > > TCM Windows 5.5.1 > > Hiper arc version 1.1.11 does not sound right. Guess you have 4.1.11. > When you see this problem can you get a trace - you can either do mon ppp > or mon radius from the hiper arc. That will tell us what the problem is. > > krish > > > > > I e-mailed for help to 3Com but no answer for 3 days... > > > > I do not have tech support contract...too much money.. > > > > It started happening last Sat and Sun...Mon and Tue.. which is today. > > I had one new customer yesterday.. it did not rscognize his username and > > password right away, but started working about one and half hour later. > > > > I have another new one keyed in 14:33 pm today, it is not working yet > > (16:37). > > I just keep typing in his user name and password by using dial up every 15 > > to 30 mins to see if it is working. I did not call this customer to set up > > his internet account yet. I may have to wait till tomorrow. > > > > Anybody have any good sugestions, please write me, I will appreciate it > > very much. > > > > Please write all the detailed instructions, since I am not that good.. > > > > > > Ken. 905-826-0737 ken@gncom.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. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) new user log in problem with v.90
From: Gorkem Yuksel <gorkem@gncom.com>
Date: 1998-11-26 12:18:51
How do I do mom ppp and mom radius??? just type "mom ppp" at the hiper>> prompt?? Ken.
Subject: RE: (usr-tc) rcvdGatewayDiscCmd
From: John Powell <jp@packet.ae.usr.com>
Date: 1998-11-26 13:26:21
On Wed, 25 Nov 1998, Brian K McIntire wrote: > >>From what I understand "rcvdGatewayDiscCmd" means that the ARC/Netserver > >has essentially dropped DTR on a modem to cause a hangup. > > Not exactly. Remember the NMC is the one reporting to you a "received > gateway disconnect command" What this means is the HiPer ARC told the NMC > the user has disconnected before the NMC could get the info from somewhere > else. Not correct. Charles' original statement was correct. This cause is stored in the modem and only transferred via the NMC, the NMC's role is passive not active. You could get the same data by attaching directly to the modem and executing an ATI6. Whatever the root cause, it is definitely the gateway (ARC/NS/Edgeserver) instructing the modem to hangup. Common causes are idle-timeout, session-limit, failure to login in the specified period, failure to authenticate, etc. I guess there could be some session failures that might cause the gateway to hangup also, not sure (sorry, just a modem geek here). I am not sure, but I guess a user initiated disconnect, such as a telnet session (non-PPP) terminated with an "exit", or some sort of PPP disconnect could also cause this term cause. Normally the latter is done with the more terse, V.42 disc or NormalUserCallClear (remote modem saying adios in one way or another). Just for kicks, I took a walk through one of our corp telecommuting chassis (pretty typical ISP-like production environment) and found almost all of the disconnects were V42 disc or normalUSerCallClear, the only gateway initiated discs were session limit (3 hours in our case). JP
Subject: RE: (usr-tc) rcvdGatewayDiscCmd
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-26 15:52:43
>> >>From what I understand "rcvdGatewayDiscCmd" means that the >ARC/Netserver >> >has essentially dropped DTR on a modem to cause a hangup. >> >> Not exactly. Remember the NMC is the one reporting to you a "received >> gateway disconnect command" What this means is the HiPer ARC told the NMC >> the user has disconnected before the NMC could get the info from >somewhere >> else. > >Not correct. Charles' original statement was correct. > >This cause is stored in the modem and only transferred via the NMC, the >NMC's role is passive not active. Makes more sense than what I was told over a year ago by a nameless 3COM employee. I have always thought of the NMC as strictly a UI to the chassis. Just trying to help. Sorry, I'll stop randomly quoting what I have been told without thinking about it first. In the interest of pulling at least one foot out of my mouth and Since no one from 3COM has commented about the NAS side of this to help answer your questions let me put my neck out again. :) I have seen a bad card in the chassis causing "interference or garbage" on the packet bus resulting in random disconnects where the modem reports "Received Gateway Disconnect command" So basically, anything ahead of the modem connection is going to show up with that error. Anything on the modem, or initiated by the client modem, or between the client modem and the chassis modem will show up with something else. (Duh. Again; sorry) Also, with some versions of quad modem software I have seen calls drop when I rebooted another card on the chassis. Normally, I would say that means there is a hardware malfunction but once that card came back up again and we upgraded it we could not duplicate the problem again so I guess it was software related. Oh, I also saw it one time when we had a version of NetServer software with a memory leak. All calls were eventually dropping or would not even connect. Received Gateway disconnect command was always the reason. Sh mem on the NetServer showed only a few bytes of memory remaining. Of course, I've also seen the error when the HiPer ARC crashed. I'll stick my neck out again and tell you something else I was told. I hope 3COM will forgive the reference. No-one expects them to be perfect. It sounds as vague and strange now as when he first told me but.....When a user initiates something where a response of some kind is expected but never received a timeout occurs and the call may sometimes drop. Sounds technical doesn't it. Makes no sense to me though. The NAS should handle all requests and retransmit when necessary. Why would the user get dropped? To me, one thing should have nothing to do with the other. If the user gets dropped it should be a bug, but that's my opinion. This is not a random quote. I've got a file a few megabytes in size with all things I have ever been told by high level 3COM & former USR engineers neatly entered the day they told me in as close to the original wording as when they told me. I don't pretend to know everything so I keep it and use it often. (I'm sure someone will try to flame me for this. Oh well.) I hope starting this argument was at least helpful. Sometimes starting one and putting your neck out is the only way to get anyone who really knows the answer to comment on it. (They can smell the blood.) :) Anyway, e-mails seen by the people who have the answers go unanswered all the time. At least John commented on it and helped us out. >You could get the same data by attaching directly to the modem and executing an ATI6. Whatever >the root cause, it is definitely the gateway (ARC/NS/EdgeServer) instructing the >modem to hang-up. > >Common causes are idle-timeout, session-limit, failure to login in the >specified period, failure to authenticate, etc. I guess there could be >some session failures that might cause the gateway to hang-up also, not >sure (sorry, just a modem geek here). > >I am not sure, but I guess a user initiated disconnect, such as a telnet >session (non-PPP) terminated with an "exit", or some sort of PPP >disconnect could also cause this term cause. Normally the latter is done >with the more terse, V.42 disc or NormalUserCallClear (remote modem saying >adios in one way or another). > >Just for kicks, I took a walk through one of our Corp telecommuting >chassis (pretty typical ISP-like production environment) and found almost >all of the disconnects were V42 disc or NormalUserCallClear, the only >gateway initiated discs were session limit (3 hours in our case). > >JP
Subject: RE: (usr-tc) rcvdGatewayDiscCmd
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-26 16:32:36
On Thu, 26 Nov 1998, Brian K McIntire wrote: > >> >>From what I understand "rcvdGatewayDiscCmd" means that the > >ARC/Netserver > >> >has essentially dropped DTR on a modem to cause a hangup. > >> > >> Not exactly. Remember the NMC is the one reporting to you a "received > >> gateway disconnect command" What this means is the HiPer ARC told the NMC > >> the user has disconnected before the NMC could get the info from > >somewhere > >> else. > > > >Not correct. Charles' original statement was correct. > > > >This cause is stored in the modem and only transferred via the NMC, the > >NMC's role is passive not active. > > Makes more sense than what I was told over a year ago by a nameless 3COM > employee. I have always thought of the NMC as strictly a UI to the chassis. > Just trying to help. Sorry, I'll stop randomly quoting what I have been > told without thinking about it first. It does not make sense. Don't say that you have been told by someone in 3com and you have a record - rather a journal of everything that was said to you with date and time and with their signature to prove it etc etc. Everyone in 3com who worked in the past ( USR ) and who is working now and those people who have access to yadda yadda search can see what this problem means. This problem is simple and stright forward. The modem disconnected the call because the modem was told to do so by the Gateway card. Once this is done - the modem sends this info to the NMC or to the Gateway card and in some cases to both to send the same to Trap destinations or to Radius accounting servers. A call can be disconnected by a Gateway card (NETServer, EdgeServer, Hiper arc, X.25 Card, App Card ... etc) for the simple reason that it did not like the call. Say for example during a ppp session you the hiper arc receives lot of errors and this continues to happen to a certain level - the the hiper arc can tell the modem to disconnect. This method is a very normal way of clearing a call. If you feel that there is a abnormal disconnects and you feel that for some reaon your NETServer/HiPer arc is just disconnecting users - you need to go around and find it why it is happening. You need radius accounting logs, syslogs and then you must corelate them with the gateway disconnect you see. > > In the interest of pulling at least one foot out of my mouth and Since no > one from 3COM has commented about the NAS side of this to help answer your > questions let me put my neck out again. :) > > I have seen a bad card in the chassis causing "interference or garbage" on > the packet bus resulting in random disconnects where the modem reports > "Received Gateway Disconnect command" > So basically, anything ahead of the modem connection is going to show up > with that error. Anything on the modem, or initiated by the client modem, > or between the client modem and the chassis modem will show up with > something else. (Duh. Again; sorry) > Not True, if you have a bad card in the chassis you will see the connection to that port causing problems or that card is also capable of disconnecting all the cards from the chassis - meaning you will have modems get off the packet bus. But no Modem card is intelligent enough to send out gateway disconnect reason without receiving them. > Also, with some versions of quad modem software I have seen calls drop when > I rebooted another card on the chassis. Normally, I would say that means > there is a hardware malfunction but once that card came back up again and we > upgraded it we could not duplicate the problem again so I guess it was > software related. You have to take every problem case by case. You cannot assume that two problems can be uniquely the same - just because it looks the same. This problem that you may have seen could be due to chassis awarness in the quad 4.0 code but then again this was fixed long long ago. > > Oh, I also saw it one time when we had a version of NetServer software with > a memory leak. All calls were eventually dropping or would not even > connect. Received Gateway disconnect command was always the reason. Sh mem > on the NetServer showed only a few bytes of memory remaining. > Memory leak --- If you run into this then you will have problems with calls droped but again you will not be able to make new calls or even telnet to the NETServer. Yes in this case the gateway card has no memory so the calls were told be droped. > Of course, I've also seen the error when the HiPer ARC crashed. > Yes - this is possible again the modem did get a disconnect from the hiper arc. > I'll stick my neck out again and tell you something else I was told. I hope > 3COM will forgive the reference. No-one expects them to be perfect. > It sounds as vague and strange now as when he first told me but.....When a > user initiates something where a response of some kind is expected but never > received a timeout occurs and the call may sometimes drop. Sounds technical > doesn't it. Makes no sense to me though. The NAS should handle all > requests and retransmit when necessary. Why would the user get dropped? To Again I have to ask you to take a look back and see in what situation this particular statement was made. Go back and take a look at your notes and see why this statement was made and in what refrence this was made. There can be a situation which could be true. I am not sure nor can I think of a situation right now but there could be something like that. Just because it was told you does not mean that you were told a lie. It all depends upon when and whom you asked the question. > me, one thing should have nothing to do with the other. If the user gets > dropped it should be a bug, but that's my opinion. > A bug is when a user gets droped without any reason. If there is a valid reason then you have to take a look why this happened and if the reason is right its not a BUG. > This is not a random quote. I've got a file a few megabytes in size with > all things I have ever been told by high level 3COM & former USR engineers > neatly entered the day they told me in as close to the original wording as > when they told me. I don't pretend to know everything so I keep it and use > it often. (I'm sure someone will try to flame me for this. Oh well.) > krish > I hope starting this argument was at least helpful. Sometimes starting one > and putting your neck out is the only way to get anyone who really knows the > answer to comment on it. (They can smell the blood.) :) Anyway, e-mails > seen by the people who have the answers go unanswered all the time. At > least John commented on it and helped us out. > > >You could get the same data by attaching directly to the modem and > executing an ATI6. Whatever >the root cause, it is definitely the gateway > (ARC/NS/EdgeServer) instructing the > >modem to hang-up. > > > >Common causes are idle-timeout, session-limit, failure to login in the > >specified period, failure to authenticate, etc. I guess there could be > >some session failures that might cause the gateway to hang-up also, not > >sure (sorry, just a modem geek here). > > > >I am not sure, but I guess a user initiated disconnect, such as a telnet > >session (non-PPP) terminated with an "exit", or some sort of PPP > >disconnect could also cause this term cause. Normally the latter is done > >with the more terse, V.42 disc or NormalUserCallClear (remote modem saying > >adios in one way or another). > > > >Just for kicks, I took a walk through one of our Corp telecommuting > >chassis (pretty typical ISP-like production environment) and found almost > >all of the disconnects were V42 disc or NormalUserCallClear, the only > >gateway initiated discs were session limit (3 hours in our case). > > > >JP > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Telepath modem running 1.41.017
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-11-27 00:58:54
The last few Telepath user I tried to debug were connecting without v.42 or MNP 4 error correction -- both to Quads and DSP's. That may be the real problem -- things often don't work too well when you can't correct line errors. Disabling v.42 (S15=128) didn't seem to help... it didn't connect with MNP 4 either. I didn't research this too much farther... so there's likely a lot I'm missing here. I suspect upgrading to v.90 may have helped -- I think they were x2-only modems. But maybe it'll give you something else to look at? Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Wed, 25 Nov 1998, Brian K McIntire wrote: > >Just thought I would add that I experienced the same problem with this > >version of code. Using mon ppp it seemed like it was experiencing the LCP > >problem that web TV and imac's had. It did not get up to the > >authentication stage. I'm still running 4.0.30 on our production chassis' > >this being one of the reasons... > > > Thanks, that does help. We are seeing exactly the same thing on ours. The > user attempts to connect, handshakes and goes no further. Monitor radius > shows nothing. It just seems to be hanging. I guess I'll call 3COM and > open a tkt with them. Thought I might have some bad code on that modem but > if you are seeing it too then maybe it's a bug with something else. > > Thanks again > > >Jerry > > > >At 10:56 AM 11/25/98 -0600, you wrote: > >>Does anyone know of issues with this particular modem. I'm working with a > >>customer running 1.2.5 on his DSP's and 4.1.72 - 7 on his HiPer ARC. With > >>the same user account I can connect 20 times out of 20 with my > >courier. The > >>client that has a Telepath connects 1 out of every 3-7 times. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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: mpip
From: C Thompson <cthompson@wingnet.net>
Date: 1998-11-27 10:36:50
I have a question on setting up multiple MPIP servers. We have three chasses (a, b, and c with address 1, 2, and 3 respectively). If I want to set up 'a' as a server, I do the following: Chassis Command
Subject: Re: (usr-tc) Re: mpip
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-27 11:54:04
Thus spake C Thompson >I have a question on setting up multiple MPIP servers. We have >three chasses (a, b, and c with address 1, 2, and 3 respectively). >If I want to set up 'a' as a server, I do the following: [snip] That should pretty much cover it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Dual logins
From: Bob Fager <rdfager@cube.ice.net>
Date: 1998-11-27 12:22:01
We have been using pmmon to limit multiple logins now for a few month and have had great success with it. When I first installed it I heard from a few angry customers who insisted that they were not connected more than once. However, on every occassion I was able to go through our radius logs and find records of multiple logins. Logging the "Calling-Station-Id" really helped with this. Customers quiet down when you can give them the telephone number the connections were made from. Just my $.02 Bob On Fri, 27 Nov 1998, Ralph Helfenberger wrote: > Hi > I've been follwing the thread "Solution for idle time limits and dual > logins". It was very interesting for me. As far as I could follow there > are two main solutions to prevent dual logins: > > 1) Every login runs through a single point RADIUS authentication. This > point has a table with users already logged in and it disconnects users, > if they already have an active session. Obvious drawbacks: If the RADIUS > server doesn't get the notification of an "end of session" this user can > login in again (exept if there is some kind of timeout mechanism). Other > drawback: The RADIUS servers can't do load sharing. Other drawback: > There is a single point of failure. > > 2) There is an independent server wich regularly polls all NAS for > doubled logins. It disconnects all users wich are logged in twice. > Drawback: users acutally get the access but will be disconnected later. > This can cause a lot of support calls. > > I'd like to hear from you who is using wich mechanism and what the > experiences are? How reliable does it run? I should implement something > like that in an environment with about 10 TotalControl chassis > (Netserver mainly). > > Thanks for your comments. > > Ralph > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) rcvdGatewayDiscCmd
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-11-27 13:36:00
>-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan >Sent: Thursday, November 26, 1998 4:33 PM >To: Brian K McIntire >Cc: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) rcvdGatewayDiscCmd > > >On Thu, 26 Nov 1998, Brian K McIntire wrote: > >> >> >>From what I understand "rcvdGatewayDiscCmd" means that the >> >ARC/Netserver >> >> >has essentially dropped DTR on a modem to cause a hangup. >> >> >> >> Not exactly. Remember the NMC is the one reporting to you a "received >> >> gateway disconnect command" What this means is the HiPer ARC >told the NMC >> >> the user has disconnected before the NMC could get the info from >> >somewhere >> >> else. >> > >> >Not correct. Charles' original statement was correct. >> > >> >This cause is stored in the modem and only transferred via the NMC, the >> >NMC's role is passive not active. >> >> Makes more sense than what I was told over a year ago by a nameless 3COM >> employee. I have always thought of the NMC as strictly a UI to >the chassis. >> Just trying to help. Sorry, I'll stop randomly quoting what I have been >> told without thinking about it first. > >It does not make sense. Don't say that you have been told by someone in >3com and you have a record - rather a journal of everything that was said >to you with date and time and with their signature to prove it etc etc. >Everyone in 3com who worked in the past ( USR ) and who is working now >and those people who have access to yadda yadda search can see what this >problem means. > >This problem is simple and stright forward. The modem disconnected the >call because the modem was told to do so by the Gateway card. Once this >is done - the modem sends this info to the NMC or to the Gateway card and >in some cases to both to send the same to Trap destinations or to Radius >accounting servers. > >A call can be disconnected by a Gateway card (NETServer, EdgeServer, >Hiper arc, X.25 Card, App Card ... etc) for the simple reason that it did >not like the call. Say for example during a ppp session you the hiper >arc receives lot of errors and this continues to happen to a certain >level - the the hiper arc can tell the modem to disconnect. > >This method is a very normal way of clearing a call. If you feel that >there is a abnormal disconnects and you feel that for some reaon your >NETServer/HiPer arc is just disconnecting users - you need to go around >and find it why it is happening. > >You need radius accounting logs, syslogs and then you must corelate them >with the gateway disconnect you see. I told you we could get someone to comment on this once we started arguing about it >> >> In the interest of pulling at least one foot out of my mouth and Since no >> one from 3COM has commented about the NAS side of this to help >answer your >> questions let me put my neck out again. :) >> >> I have seen a bad card in the chassis causing "interference or >garbage" on >> the packet bus resulting in random disconnects where the modem reports >> "Received Gateway Disconnect command" >> So basically, anything ahead of the modem connection is going to show up >> with that error. Anything on the modem, or initiated by the >client modem, >> or between the client modem and the chassis modem will show up with >> something else. (Duh. Again; sorry) >> >Not True, if you have a bad card in the chassis you will see the >connection to that port causing problems or that card is also capable of >disconnecting all the cards from the chassis - meaning you will have >modems get off the packet bus. But no Modem card is intelligent enough >to send out gateway disconnect reason without receiving them. I have escalated a few tickets that were resolved by replacing bad quad modem cards. The original symptom "Received gateway Disconnect Command". Perhaps the tech that worked on each of the escalated tickets did something else to resolve the problem and didn't document it. I don't know. I only log information not ticket #'s (Unless they are my tickets). Wish i had some tickets #'s to give you. > > >> Also, with some versions of quad modem software I have seen >calls drop when >> I rebooted another card on the chassis. Normally, I would say that means >> there is a hardware malfunction but once that card came back up >again and we >> upgraded it we could not duplicate the problem again so I guess it was >> software related. > >You have to take every problem case by case. You cannot assume that >two problems can be uniquely the same - just because it looks the same. >This problem that you may have seen could be due to chassis awarness in >the quad 4.0 code but then again this was fixed long long ago. > >> >> Oh, I also saw it one time when we had a version of NetServer >software with >> a memory leak. All calls were eventually dropping or would not even >> connect. Received Gateway disconnect command was always the >reason. Sh mem >> on the NetServer showed only a few bytes of memory remaining. >> >Memory leak --- If you run into this then you will have problems with >calls droped but again you will not be able to make new calls or even >telnet to the NETServer. >Yes in this case the gateway card has no memory so the calls were told be >droped. > >> Of course, I've also seen the error when the HiPer ARC crashed. >> >Yes - this is possible again the modem did get a disconnect from the >hiper arc. > > >> I'll stick my neck out again and tell you something else I was >told. I hope >> 3COM will forgive the reference. No-one expects them to be perfect. >> It sounds as vague and strange now as when he first told me >but.....When a >> user initiates something where a response of some kind is >expected but never >> received a timeout occurs and the call may sometimes drop. >Sounds technical >> doesn't it. Makes no sense to me though. The NAS should handle all >> requests and retransmit when necessary. Why would the user get >dropped? To >Again I have to ask you to take a look back and see in what situation >this particular statement was made. >Go back and take a look at your notes and see why this statement was made >and in what refrence this was made. There can be a situation which could >be true. I am not sure nor can I think of a situation right now but >there could be something like that. Just because it was told you does >not mean that you were told a lie. It all depends upon when and whom you >asked the question. > >> me, one thing should have nothing to do with the other. If the user gets >> dropped it should be a bug, but that's my opinion. >> >A bug is when a user gets droped without any reason. If there is a valid >reason then you have to take a look why this happened and if the reason >is right its not a BUG. > >> This is not a random quote. I've got a file a few megabytes in size with >> all things I have ever been told by high level 3COM & former USR >engineers >> neatly entered the day they told me in as close to the original >wording as >> when they told me. I don't pretend to know everything so I keep >it and use >> it often. (I'm sure someone will try to flame me for this. Oh well.) >> > >krish > > >> I hope starting this argument was at least helpful. Sometimes >starting one >> and putting your neck out is the only way to get anyone who >really knows the >> answer to comment on it. (They can smell the blood.) :) Anyway, e-mails >> seen by the people who have the answers go unanswered all the time. At >> least John commented on it and helped us out. >> >> >You could get the same data by attaching directly to the modem and >> executing an ATI6. Whatever >the root cause, it is definitely >the gateway >> (ARC/NS/EdgeServer) instructing the >> >modem to hang-up. >> > >> >Common causes are idle-timeout, session-limit, failure to login in the >> >specified period, failure to authenticate, etc. I guess there could be >> >some session failures that might cause the gateway to hang-up also, not >> >sure (sorry, just a modem geek here). >> > >> >I am not sure, but I guess a user initiated disconnect, such as a telnet >> >session (non-PPP) terminated with an "exit", or some sort of PPP >> >disconnect could also cause this term cause. Normally the >latter is done >> >with the more terse, V.42 disc or NormalUserCallClear (remote >modem saying >> >adios in one way or another). >> > >> >Just for kicks, I took a walk through one of our Corp telecommuting >> >chassis (pretty typical ISP-like production environment) and >found almost >> >all of the disconnects were V42 disc or NormalUserCallClear, the only >> >gateway initiated discs were session limit (3 hours in our case). >> > >> >JP >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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) Dual logins
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-11-27 17:57:46
Hi I've been follwing the thread "Solution for idle time limits and dual logins". It was very interesting for me. As far as I could follow there are two main solutions to prevent dual logins: 1) Every login runs through a single point RADIUS authentication. This point has a table with users already logged in and it disconnects users, if they already have an active session. Obvious drawbacks: If the RADIUS server doesn't get the notification of an "end of session" this user can login in again (exept if there is some kind of timeout mechanism). Other drawback: The RADIUS servers can't do load sharing. Other drawback: There is a single point of failure. 2) There is an independent server wich regularly polls all NAS for doubled logins. It disconnects all users wich are logged in twice. Drawback: users acutally get the access but will be disconnected later. This can cause a lot of support calls. I'd like to hear from you who is using wich mechanism and what the experiences are? How reliable does it run? I should implement something like that in an environment with about 10 TotalControl chassis (Netserver mainly). Thanks for your comments. Ralph
Subject: Re: (usr-tc) Dual logins
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-27 21:21:53
Quoth Ralph Helfenberger <rhelfenberger@comlight.ch> -- : 1) Every login runs through a single point RADIUS authentication. This : point has a table with users already logged in and it disconnects users, : if they already have an active session. Obvious drawbacks: If the RADIUS : server doesn't get the notification of an "end of session" this user can : login in again (exept if there is some kind of timeout mechanism). And this drawback classifies such a method as a kludge. To actually solve the problem, the authentication system is going to need to verify that its database of connections is accurate. : Other drawback: The RADIUS servers can't do load sharing. Other : drawback: There is a single point of failure. It's nontrivial, but you *can* make your RADIUS server set use a common database among all of the servers. There are fault-tolerant network databases to be had, and this is a good application of one. We should be careful to generalize our solutions: if we design strictly for one case -- where any multiple concurrent session is intolerable -- then won't be able to gracefully handle probable future cases, where each customer has access to a certain number of concurrent sessions that's greater than one.
Subject: Re: (usr-tc) Dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-28 09:32:13
Thus spake Mark R. Lindsey >Quoth Ralph Helfenberger <rhelfenberger@comlight.ch> -- >: 1) Every login runs through a single point RADIUS authentication. This >: point has a table with users already logged in and it disconnects users, >: if they already have an active session. Obvious drawbacks: If the RADIUS >: server doesn't get the notification of an "end of session" this user can >: login in again (exept if there is some kind of timeout mechanism). >And this drawback classifies such a method as a kludge. To actually >solve the problem, the authentication system is going to need to verify >that its database of connections is accurate. I disagree that its a kludge...at least in theory. This really would be the clean way to do it, the problem is, is that it seems that noone can make RADIUS client systems that can guarentee that the right records get to the right places. It would also be nice if RADIUS had the support for an incremental check or something, but in theory, even that isn't needed. Now, of course, in practice, this doesn't work, and since we're dealing with the real world, this isn't the answer. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Dual logins
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-28 09:49:06
: Thus spake Mark R. Lindsey : >Quoth Ralph Helfenberger <rhelfenberger@comlight.ch> -- : >: If the RADIUS server doesn't get the notification of an "end of : >: session" this user can login in again (exept if there is some kind : >: of timeout mechanism). : : >And this drawback classifies such a method as a kludge. : : I disagree that its a kludge...at least in theory. This really would be : the clean way to do it, the problem is, is that it seems that noone can : make RADIUS client systems that can guarentee that the right records get : to the right places. Perhaps, but only if your theory doesn't account for servers (NASsen) that die and network links that never come back (where `never' refers to a very long time). As with the case of network design, your theory *does* need to account for all of the circumstances; as in this example, if you design around perfect operation conditions in a world where of imperfect operating conditions, then you have a poor design. Take another example from a related discipline: we started using RAID systems when it became obvious that our assumption of perfect discs is invalid. By designing such that Disc Failure is a normal operating condition, we are able to operate through it. Similarly, we should *plan* on things breaking, because Excrement Occurs. Any design that ignores this (at the higher layers, anyway) is doomed to be replaced by one that does.
Subject: Re: (usr-tc) Dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-28 10:03:39
Thus spake Mark R. Lindsey >Similarly, we should *plan* on things breaking, because Excrement >Occurs. Any design that ignores this (at the higher layers, anyway) is >doomed to be replaced by one that does. Agreed...thus my qualifications of things being "in theory." Now, how to plan for operational breakdowns (ala a disk dieing in a RAID set). Incremental RADIUS checks would be a start, even ICMP reachability checks would be a start. Making sure reboot RADIUS requests go through is another important point. These of course are mostly protocol issues that require changes, additions to the RADIUS protocol, so they really don't help at the moment, but I think its the way to go rather than using a possibly platform specific kludge like pmmon to check various systems. That we have a RADIUS server (Cistron I think?) that *does* manage to handle this doesn't make it any less of a kludge. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) Dual logins
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-11-28 10:17:34
Quoth Jeff McAdams: : Now, how to plan for operational breakdowns (ala a disk dieing in : a RAID set). Incremental RADIUS checks would be a start, even ICMP : reachability checks would be a start. Making sure reboot RADIUS : requests go through is another important point. These of course are : mostly protocol issues that require changes, additions to the RADIUS : protocol [...] I like RADIUS the way it is. (Maybe I'm simplistic.) I think this problem can be solved externally to the protocol. Consider: Each NAS has a table available via SNMP that has a list of all current sessions, and the indeces of that table are the Port numbers, as sent to the RADIUS accounting server. As such, a database of current sessions could be maintained, and verified. As new authentication requests are received, that database is consulted, and entries in it are verified using SNMP. To do this, we don't need a new RADIUS -- all we need is NASsen with the appropriate tables. I understand that the ARC has such a table, and that's a good start.
Subject: (usr-tc) radius on usr-tc
From: newbie@www.datatone.com
Date: 1998-11-28 15:08:02
Hi, I posted this to portmaster-radius and didnt get any reply..so I am trying this list now..any help is greatly appreicated.. TIA harish Greetings: I have a problem with radius and USR Total Control( I am new to USR TC). I am running radius v 1.16 with esv a patch to control multiple logins, with 4 portmaster3 and 2 portmaster2 ( I am familiar with PM2 and PM3s) o n a Linux redhat machine and everything is fine. Now I am trying to use the same radius server with USR TC, b ut authentication fails with bad password..! I am using my laptop to login via dialup, If I dial into portmas ter to login using same username and password, I get authenticated OK. If I change the phone number and dial into USR TC (only phone number changed on laptop, nothing else), I do not get authenticated..radius with -x o utput shows bad password..I change the phone number to login via PM and I am OK.. I tried seraching 3Com website and Livingston Mailing archive and dont see anything that can help..I have pos ted the radius -x output from both PM and TC, while trying to log on.. Any one has seen these problem..or what am I doing wrong with TC..? thanks in advance. harish radius entry for user test # test Password="UNIX" # OUTPUT (radius) while trying to logon via PM2: radrecv: Request from host d0dcc009 code=1, id=11, length=74 User-Name = "test" Password = "@\334\036\372d\375\374\346vH}\370\204\354\035\020" NAS-IP-Address = xxx.xxx.192.9 NAS-Port = 1 NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP Sending Ack of id 11 to d0dcc009 (516comm) radrecv: Request from host d0dcc009 code=4, id=12, length=90 Acct-Session-Id = "65000004" User-Name = "test" NAS-IP-Address = xxx.xxx.192.9 NAS-Port = 1 NAS-Port-Type = Async Acct-Status-Type = Start Acct-Authentic = RADIUS Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = xxx.xxx.192.248 Acct-Delay-Time = 0 User test logged on 516comm S1 Sending Accounting Ack of id 12 to d0dcc009 (516comm) OUTPUT (radius) while trying to logon via TC: radrecv: Request from host cf618602 code=1, id=52, length=188 User-Name = "test" Password = ".\321\202\325\374\202\304\356\202\241\255\335\024\002?g" NAS-IP-Address = xxx.xxx.134.2 NAS-Port = 31 Service-Type = Framed-User Framed-Protocol = PPP Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" NAS-Identifier = "usr1" Acct-Session-Id = "0802016c" NAS-Port-Type = Async Authenticate: from xxx.xxx.134.2 - Bad password: test Sending Reject of id 52 to cf618602 (xxx.xxx.134.2) radrecv: Request from host cf618602 code=1, id=52, length=188 User-Name = "test" Password = ".\321\202\325\374\202\304\356\202\241\255\335\024\002?g" NAS-IP-Address = xxx.xxx.134.2 NAS-Port = 31 Service-Type = Framed-User Framed-Protocol = PPP Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" NAS-Identifier = "usr1" Acct-Session-Id = "0802016c" NAS-Port-Type = Async Dropping duplicate: from xxx.xxx.134.2 - ID: 52 USR TC Version: Command> ver U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 Build date: Aug 11 1998 Build time: 13:49:21 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced
Subject: Re: (usr-tc) radius on usr-tc
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-28 15:50:48
Check the secret keys. When you dial into the USR-Tc NETServer your authentication is denied because of wrong password. Basically it looks like a password mismatch. Check the secret. Just re-entry the radius secret on the NETServer and in the radius clients file. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 28 Nov 1998 newbie@www.datatone.com wrote: > Hi, > I posted this to portmaster-radius and didnt get any reply..so I am trying this list now..any help is greatly appreicated.. > > TIA > harish > > Greetings: > > I have a problem with radius and USR Total Control( I am new to USR TC). I am running radius v 1.16 with esv > a patch to control multiple logins, with 4 portmaster3 and 2 portmaster2 ( I am familiar with PM2 and PM3s) o > n a Linux redhat machine and everything is fine. Now I am trying to use the same radius server with USR TC, b > ut authentication fails with bad password..! I am using my laptop to login via dialup, If I dial into portmas > ter to login using same username and password, I get authenticated OK. If I change the phone number and dial > into USR TC (only phone number changed on laptop, nothing else), I do not get authenticated..radius with -x o > utput shows bad password..I change the phone number to login via PM and I am OK.. > > I tried seraching 3Com website and Livingston Mailing archive and dont see anything that can help..I have pos > ted the radius -x output from both PM and TC, while trying to log on.. > Any one has seen these problem..or what am I doing wrong with TC..? > > thanks in advance. > > harish > > radius entry for user test > > # > test Password="UNIX" > # > > OUTPUT (radius) while trying to logon via PM2: > > radrecv: Request from host d0dcc009 code=1, id=11, length=74 > User-Name = "test" > Password = "@\334\036\372d\375\374\346vH}\370\204\354\035\020" > NAS-IP-Address = xxx.xxx.192.9 > NAS-Port = 1 > NAS-Port-Type = Async > Service-Type = Framed-User > Framed-Protocol = PPP > Sending Ack of id 11 to d0dcc009 (516comm) > radrecv: Request from host d0dcc009 code=4, id=12, length=90 > Acct-Session-Id = "65000004" > User-Name = "test" > NAS-IP-Address = xxx.xxx.192.9 > NAS-Port = 1 > NAS-Port-Type = Async > Acct-Status-Type = Start > Acct-Authentic = RADIUS > Service-Type = Framed-User > Framed-Protocol = PPP > Framed-IP-Address = xxx.xxx.192.248 > Acct-Delay-Time = 0 > User test logged on 516comm S1 > Sending Accounting Ack of id 12 to d0dcc009 (516comm) > > > OUTPUT (radius) while trying to logon via TC: > > radrecv: Request from host cf618602 code=1, id=52, length=188 > User-Name = "test" > Password = ".\321\202\325\374\202\304\356\202\241\255\335\024\002?g" > NAS-IP-Address = xxx.xxx.134.2 > NAS-Port = 31 > Service-Type = Framed-User > Framed-Protocol = PPP > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > NAS-Identifier = "usr1" > Acct-Session-Id = "0802016c" > NAS-Port-Type = Async > Authenticate: from xxx.xxx.134.2 - Bad password: test > Sending Reject of id 52 to cf618602 (xxx.xxx.134.2) > radrecv: Request from host cf618602 code=1, id=52, length=188 > User-Name = "test" > Password = ".\321\202\325\374\202\304\356\202\241\255\335\024\002?g" > NAS-IP-Address = xxx.xxx.134.2 > NAS-Port = 31 > Service-Type = Framed-User > Framed-Protocol = PPP > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > NAS-Identifier = "usr1" > Acct-Session-Id = "0802016c" > NAS-Port-Type = Async > Dropping duplicate: from xxx.xxx.134.2 - ID: 52 > > USR TC Version: > > Command> ver > U.S. Robotics > Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 > Build date: Aug 11 1998 > Build time: 13:49:21 > > Network Interface Card: Ethernet & Frame Relay Combination (26) > ISDN Interface Card : MUNICH32 (4) > Packet Bus Circuit : Enhanced > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Dual logins
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-11-28 16:35:58
Thus spake Mark R. Lindsey >I like RADIUS the way it is. (Maybe I'm simplistic.) Of course, if RADIUS worked as it was *supposed* to with all that, most of this would be unnecessary...*some* of it would still be needed, but not nearly as much of it. >Each NAS has a table available via SNMP that has a list of all current >sessions, and the indeces of that table are the Port numbers, as sent to >the RADIUS accounting server. Someone (David?) correct me here if I'm wrong, but I don't know of any pre-defined SNMP trees that have this information in it, meaning we're back to each vendor defines thier own tree instance and table structure that the system then has to be able to handle. Now, standardizing it on SNMP is an improvement...but that does leave some of the boxes out in the cold...ala NETServer. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
Subject: Re: (usr-tc) radius on usr-tc
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-11-28 17:40:13
On Sat, 28 Nov 1998 newbie@www.datatone.com wrote: > Hi, > I have checked and entered the secret twice while trying to trouble shoot the problem..so I dont think it is the secret... > If secret keys are fine then it is a problem in terms of using PAP / CHAP. Also check your user make sure that the netserver itself on flash does not have a user with the same name. krish > thanks for the reply... > > harish > > >From owner-usr-tc@lists.xmission.com Sat Nov 28 16:44:30 1998 > Date: Sat, 28 Nov 1998 15:50:48 -0600 (CST) > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: newbie@www.datatone.com > cc: -v@www.datatone.com, usr-tc@lists.xmission.com > Subject: Re: (usr-tc) radius on usr-tc > > Check the secret keys. When you dial into the USR-Tc NETServer your > authentication is denied because of wrong password. Basically it looks > like a password mismatch. Check the secret. Just re-entry the radius > secret on the NETServer and in the radius clients file. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Sat, 28 Nov 1998 newbie@www.datatone.com wrote: > > > Hi, > > I posted this to portmaster-radius and didnt get any reply..so I am trying this list now..any help is greatly appreicated.. > > > > TIA > > harish > > > > Greetings: > > > > I have a problem with radius and USR Total Control( I am new to USR TC). I am running radius v 1.16 with esv > > a patch to control multiple logins, with 4 portmaster3 and 2 portmaster2 ( I am familiar with PM2 and PM3s) o > > n a Linux redhat machine and everything is fine. Now I am trying to use the same radius server with USR TC, b > > ut authentication fails with bad password..! I am using my laptop to login via dialup, If I dial into portmas > > ter to login using same username and password, I get authenticated OK. If I change the phone number and dial > > into USR TC (only phone number changed on laptop, nothing else), I do not get authenticated..radius with -x o > > utput shows bad password..I change the phone number to login via PM and I am OK.. > > > > I tried seraching 3Com website and Livingston Mailing archive and dont see anything that can help..I have pos > > ted the radius -x output from both PM and TC, while trying to log on.. > > Any one has seen these problem..or what am I doing wrong with TC..? > > > > thanks in advance. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 on usr-tc
From: newbie@www.datatone.com
Date: 1998-11-28 17:47:51
Hi, I have checked and entered the secret twice while trying to trouble shoot the problem..so I dont think it is the secret... thanks for the reply... harish From owner-usr-tc@lists.xmission.com Sat Nov 28 16:44:30 1998 cc: -v@www.datatone.com, usr-tc@lists.xmission.com Check the secret keys. When you dial into the USR-Tc NETServer your authentication is denied because of wrong password. Basically it looks like a password mismatch. Check the secret. Just re-entry the radius secret on the NETServer and in the radius clients file. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 28 Nov 1998 newbie@www.datatone.com wrote: > Hi, > I posted this to portmaster-radius and didnt get any reply..so I am trying this list now..any help is greatly appreicated.. > > TIA > harish > > Greetings: > > I have a problem with radius and USR Total Control( I am new to USR TC). I am running radius v 1.16 with esv > a patch to control multiple logins, with 4 portmaster3 and 2 portmaster2 ( I am familiar with PM2 and PM3s) o > n a Linux redhat machine and everything is fine. Now I am trying to use the same radius server with USR TC, b > ut authentication fails with bad password..! I am using my laptop to login via dialup, If I dial into portmas > ter to login using same username and password, I get authenticated OK. If I change the phone number and dial > into USR TC (only phone number changed on laptop, nothing else), I do not get authenticated..radius with -x o > utput shows bad password..I change the phone number to login via PM and I am OK.. > > I tried seraching 3Com website and Livingston Mailing archive and dont see anything that can help..I have pos > ted the radius -x output from both PM and TC, while trying to log on.. > Any one has seen these problem..or what am I doing wrong with TC..? > > thanks in advance.
Subject: Re: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-11-29 18:41:58
David Bolen was heard to say: >Ricky Beam <jfbeam@Interpath.net> writes: > >> Hmm, this makes me wonder what happens if the RADIUS server rewrites the >> username in the access-accept. > >Hmm, since a Username attribute isn't even permitted in an >Access-Accept (see RFC2138, although I think I saw some e-mail >comments about changing that to permit it fly by recently), other than >ignoring it, I'm guessing that nothing would happen :-) Like 3Com is known for following standards? --Ricky
Subject: RE: (usr-tc) Dial out from HiPer DSP card
From: MED, Wipro Systems, Inc <"nair, shibu (med, wipro systems, inc)">
Date: 1998-11-29 19:39:06
Hi Thank you for the response.... I have these too... My box containing one NMC , one ARC, and two HiPer DSP which connected to T1 ckt. Pls help me out... TIA Regards Shibu ---------- From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] Reply To: usr-tc@lists.xmission.com Sent: Wednesday, November 25, 1998 4:04 PM To: Nair, Shibu (MED, Wipro Systems, Inc) Cc: 'usr-tc@xmission.com' Subject: Re: (usr-tc) Dial out from HiPer DSP card On Wed, 25 Nov 1998, Nair, Shibu (MED, Wipro Systems, Inc) wrote: > Hi > > Iam new to Total Control Enterprise Network Hub. > > I have configured Channelised T1 ckt for the HiPer DSP card. > > Since i do no have Total Control Manager software, iam testing using the > console connection. > > I did the following test to ensure the dialout from the HiPerDSP ... > > 1) I have dialed to my local telephone and received the dial tone.. > >mdm <telephone number> > > 2) I have dialed to a machine which has dialup setup > > At this time it is trying for dialing out and comes back to the mdm > prompt. > > Iam not getting machine access when i dial.... The DSP cards also needs a packetbus card in the chassis like the hiper arc or the NETServer - Do you have those? krish > > mdm2> atdt<machine dialup number> > mdm2> > > HiPer DSP Rev. 1.0.7 > > Pls help on this problem.... > > Regards > Shibu > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) Dial out from HiPer DSP card
From: MED, Wipro Systems, Inc <"nair, shibu (med, wipro systems, inc)">
Date: 1998-11-29 19:39:06
Hi Thank you for the response.... I have these too... My box containing one NMC , one ARC, and two HiPer DSP which connected to T1 ckt. Pls help me out... TIA Regards Shibu ---------- From: Tatai SV Krishnan[SMTP:tkrishna@bubba.ae.usr.com] Reply To: usr-tc@lists.xmission.com Sent: Wednesday, November 25, 1998 4:04 PM To: Nair, Shibu (MED, Wipro Systems, Inc) Cc: 'usr-tc@xmission.com' Subject: Re: (usr-tc) Dial out from HiPer DSP card On Wed, 25 Nov 1998, Nair, Shibu (MED, Wipro Systems, Inc) wrote: > Hi > > Iam new to Total Control Enterprise Network Hub. > > I have configured Channelised T1 ckt for the HiPer DSP card. > > Since i do no have Total Control Manager software, iam testing using the > console connection. > > I did the following test to ensure the dialout from the HiPerDSP ... > > 1) I have dialed to my local telephone and received the dial tone.. > >mdm <telephone number> > > 2) I have dialed to a machine which has dialup setup > > At this time it is trying for dialing out and comes back to the mdm > prompt. > > Iam not getting machine access when i dial.... The DSP cards also needs a packetbus card in the chassis like the hiper arc or the NETServer - Do you have those? krish > > mdm2> atdt<machine dialup number> > mdm2> > > HiPer DSP Rev. 1.0.7 > > Pls help on this problem.... > > Regards > Shibu > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-29 21:08:29
On Wed, 25 Nov 1998, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > >Sent: Tuesday, November 24, 1998 5:32 PM > >To: Brian > >Cc: USRobotics TC Mailing List > >Subject: Re: (usr-tc) default routes > > > > > >list rtab pre > > > >will show you the route table and the routes that is stored in flash > > I tried this. list rtab preferred did not show me the second default route > i added. However, if i delete the primary default route the one I had > enetered before with a metric of 2 showed up under list rtab preferred and > list ip routes. exactly, so how can you see both the defaults that you have added? > > > >krish > > > >----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > >tkrishna@bubba.ae.usr.com > >----------------------------/ http://interproc.ae.usr.com ----/ > >The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Tue, 24 Nov 1998, Brian wrote: > > > > > How do you view the default routes on an arc that are set? > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: RE: (usr-tc) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-29 21:09:51
On Wed, 25 Nov 1998, Brian K McIntire wrote: > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > >Sent: Tuesday, November 24, 1998 7:00 PM > >To: Tatai SV Krishnan > >Cc: USRobotics TC Mailing List > >Subject: Re: (usr-tc) default routes > > > > > > > >It doesnt show you all of them, only the one it is using. Watch, I start > >off with 208.206.76.1 as my default route. Then add 208.206.76.44, which > >then becomes the preffered route, then I drop 208.206.76.44 and it goes > >back to 208.206.76.1. > > Did you specify a metric of 2 for the second entry? When i did it did not > over ride the primary until the primary went down no i used a metric of 1 for both.......which may be wrong, but you would think it would still be able to display it somewhere. when you say the primary went down, how does it know the state of the primary? > > Where in the arc can I get a list of all the > >currently added defaultroutes? > > > >Brian > > > > > >HiPer>> list rtab pre > >ROUTING TABLE PREFERRED ROUTES > >Destination Prot Age NextHop Metric Interface > > 0.0.0.0/0 REMOTE 25 208.206.76.1 1 eth:1 > >. > >. > >. > > > >HiPer>> add ip deFAULTROUTE gatEWAY 208.206.76.44 metric 1 > >HiPer>> list rtab pre > >ROUTING TABLE PREFERRED ROUTES > >Destination Prot Age NextHop Metric Interface > > 0.0.0.0/0 REMOTE 25 208.206.76.44 1 eth:1 > >. > >. > >. > >HiPer>> del ip deFAULTROUTE gatEWAY 208.206.76.44 > >HiPer>> list rtab pre > >ROUTING TABLE PREFERRED ROUTES > >Destination Prot Age NextHop Metric Interface > > 0.0.0.0/0 REMOTE 25 208.206.76.1 1 eth:1 > >. > >. > >. > > > > > > > > > > > > > >On Tue, 24 Nov 1998, Tatai SV Krishnan wrote: > > > >> list rtab pre > >> > >> will show you the route table and the routes that is stored in flash > >> > >> krish > >> > >> ----------------------------------------- > >> \ T.S.V. Krishnan \ > >> \ Network System Engineer \ ( : - : ) > >> \ 3Com ............ \ > >> ----------------------------------------------/ > >> tkrishna@bubba.ae.usr.com > >> ----------------------------/ http://interproc.ae.usr.com ----/ > >> The Yadda Yadda Search - for simple anwers - > http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Tue, 24 Nov 1998, Brian wrote: > > > > > > > > How do you view the default routes on an arc that are set? > > > > > > Brian > > > > > > > > > > -------------------------------------------------------------------------- > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service > Provider > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: (usr-tc) systest007
From: Brian Jacklin <csabmj@mail.tds.net>
Date: 1998-11-29 21:10:16
I've got a netserver that is telling me that the ports are in systest007 state. They work fine, user's are able to log and function without a problem. How can I get rid of this message? Thanks
Subject: RE: (usr-tc) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-29 21:11:11
On Wed, 25 Nov 1998, Tatai SV Krishnan wrote: > _list rtab en HiPer>> _list rtab en ROUTING TABLE ENTRIES Destination Prot Fwd Pref Age NextHop Metric Interface Flags 0.0.0.0/0 REMOTE 1 30 0 208.206.76.44 1 eth:1 yet if I delete that above default route, it will start using the first I added which is 208.206.76.1............no where does it show the 208.206.76.1 in this command. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Wed, 25 Nov 1998, Brian K McIntire wrote: > > > >-----Original Message----- > > >From: owner-usr-tc@lists.xmission.com > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > >Sent: Tuesday, November 24, 1998 5:32 PM > > >To: Brian > > >Cc: USRobotics TC Mailing List > > >Subject: Re: (usr-tc) default routes > > > > > > > > >list rtab pre > > > > > >will show you the route table and the routes that is stored in flash > > > > I tried this. list rtab preferred did not show me the second default route > > i added. However, if i delete the primary default route the one I had > > enetered before with a metric of 2 showed up under list rtab preferred and > > list ip routes. > > > > > >krish > > > > > >----------------------------------------- > > > \ T.S.V. Krishnan \ > > > \ Network System Engineer \ ( : - : ) > > > \ 3Com ............ \ > > > ----------------------------------------------/ > > >tkrishna@bubba.ae.usr.com > > >----------------------------/ http://interproc.ae.usr.com ----/ > > >The Yadda Yadda Search - for simple anwers - > > http://interproc.ae.usr.com/tkb.html > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Tue, 24 Nov 1998, Brian wrote: > > > > > > > > How do you view the default routes on an arc that are set? > > > > > > Brian > > > > > > > > > -------------------------------------------------------------------------- > > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: Re: (usr-tc) default routes
From: Brian <signal@shreve.net>
Date: 1998-11-29 21:13:46
On Tue, 24 Nov 1998, John Rockwell wrote: > 'list ip defaultroute' should do the trick. > Thanks! HiPer>> list ip defaULTROUTE Configured default routes Address Mask Gateway Metric State 0.0.0.0 0.0.0.0 208.206.76.44 1 ENABLED 0.0.0.0 0.0.0.0 208.206.76.1 1 ENABLED btw, I know I should have made the second one a metric of 2 > > At 05:16 PM 11/24/98 -0600, you wrote: > > > >How do you view the default routes on an arc that are set? > > > >Brian > > > > > >-------------------------------------------------------------------------- > >Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > >Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > >signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > >(318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 Rockwell > e-mail: jrockwel@clarityconnect.com > Network Engineer > Clarityconnect, Inc. > Ithaca Area: (607)257-8268 > Outside Ithaca Area: (888)322-4900 > Try us: http://www.clarityconnect.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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: (usr-tc) duck sound on modems
From: Brian <signal@shreve.net>
Date: 1998-11-29 21:16:46
Anyone ever dial up their TC hub (hdm's) and hear what sounds like a duck quack? I think its the sound of a modem half way thru negotiation to be honest........... Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1
Subject: (usr-tc) Wink Timing?
From: Russ Miescke <russm@powerweb.net>
Date: 1998-11-29 23:55:08
I have a HyperDSP running a chanelized T1. We had a problem with only 9 of the 24 channels working tonight. When I finally got someone to look at the provisioning at the telco (Ameritech), they told me that 15 channels had been removed from service by the switch. The reason the person gave me was that the wink that the switch was sending out was set to happen every 250 milliseconds, and wink back from our DSP was happening every 150 ms. They explained that after a while, the switch determines that it is getting no response from my equipment, and it will automatically remove the channel from service. Anyone ever hear of this? Is there a setting for wink timing on the HiperDSP? Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net
Subject: Re: (usr-tc) Wink Timing?
From: Frank Basso <frank@okwhatever.com>
Date: 1998-11-30 08:19:39
I experienced the same issue with Pacific Bell. Make sure that the Telco has no custom channel blocking features enabled. You can see if this is so from HiPer DSP NIC console port. I was showing several channels out of service due to custom channel blocking. -----Original Message----- >I have a HyperDSP running a chanelized T1. We had a problem with only 9 of >the 24 channels working tonight. When I finally got someone to look at the >provisioning at the telco (Ameritech), they told me that 15 channels had >been removed from service by the switch. The reason the person gave me was >that the wink that the switch was sending out was set to happen every 250 >milliseconds, and wink back from our DSP was happening every 150 ms. They >explained that after a while, the switch determines that it is getting no >response from my equipment, and it will automatically remove the channel >from service. > >Anyone ever hear of this? Is there a setting for wink timing on the >HiperDSP? > > >Russ Miescke >Power Web Connect >russm@powerweb.net >http://www.powerweb.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) PRI card, or Used Rack with PRI card and V.90 wanted
From: Dwight G. Jones <djones@imagen.net>
Date: 1998-11-30 10:52:21
Please contact djones@imagen.net
Subject: RE: (usr-tc) rcvdGatewayDiscCmd
From: David Bolen <db3l@ans.net>
Date: 1998-11-30 12:29:06
Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> writes: > A call can be disconnected by a Gateway card (NETServer, EdgeServer, > Hiper arc, X.25 Card, App Card ... etc) for the simple reason that it did > not like the call. Say for example during a ppp session you the hiper > arc receives lot of errors and this continues to happen to a certain > level - the the hiper arc can tell the modem to disconnect. While the majority of services discussed here relate to PPP sessions, just for another data point, the disconnect originating from the NETServer/ARC is also fairly typical if you are using tunneled TCP sessions (e.g., netdata) to service async users, over which a higher order protocol is running. In such a case, a proper shutdown by the end user creates a disconnect sequence in the protocol being tunneled, at which point the TCP session is going to tear down. But you end up in a race condition; either the customer is going to disconnect the modem which will be seen over the telco call path, or the server is going to disconnect the TCP session which is seen by the NETServer. Depending on which arrives at the chassis first, that call will either disconnect (as perceived by the modem which is in the "middle") from the network (NETServer/ARC) side or the telco (DS0 channel) side. One could also imagine that if a customer's PC is slow to disconnect (or has some fixed delay before hangup) the actual phone line after shutting down the PPP stack, that a similar race condition might exist even for PPP sessions. On our network (which takes a lot of tunneled TCP calls) we see somewhere around a 15% disconnect as a system wide average from the network side with the rcvdGatewayDiscCmd, generally second only (although by a large margin) to a normal V.42 disconnect from the telco side. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/
Subject: Re: (usr-tc) Seeking a way to 'hide' users from "list connections"
From: David Bolen <db3l@ans.net>
Date: 1998-11-30 12:31:53
Ricky Beam <jfbeam@Interpath.net> writes: > Like 3Com is known for following standards? Hmm - it's hard to answer a statement like that in blanket terms, but it seems to me the TC chassis does pretty well in that regard. Certainly with respect to this discussion and RADIUS it fits the RFC. There are some nits but nothing overly significant to my mind - probably one of the bigger ones is their construction of vendor specific attributes, but that's not in violation of the RFC, just not the suggested format - and I sort of like 3Com's format better anyway. -- David
Subject: Re: (usr-tc) Upgrading Network Manager Card 4Meg. ....
From: Victor J. Velazquez <victorv@infi.net>
Date: 1998-11-30 13:57:17
Copy the 5.3.2 file to the sdl subdirectory of the USRSuite directory. To upgrade the NMC to 5.3.2 you need to use TCM. In TCM select Configure then select download and check the box for the NMC and click OK. At 09:39 PM 11/30/98 +0400, you wrote: >Hi, >I wish to upgrade NMC 4Meg to ver. 5.3.2 for Y2K compliance. Present version on NMC is 4.3.9. I have already downloaded the file. What I don't know is >how to apply this patch. I can see a executable file pcsdl.exe upon >unzipping the code. Can someone please help me in knowing the correct >procedure for applying this patch. > >Regards >mahinderj@ohitelecom.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: (usr-tc) Upgrading Network Manager Card 4Meg. ....
From: Mahinder Kumar <mahinderj@ohitelecom.com>
Date: 1998-11-30 21:39:34
Hi, I wish to upgrade NMC 4Meg to ver. 5.3.2 for Y2K compliance. Present = version on NMC is 4.3.9. I have already downloaded the file. What I = don't know is how to apply this patch. I can see a executable file pcsdl.exe upon unzipping the code. Can someone please help me in knowing the correct procedure for applying this patch. Regards mahinderj@ohitelecom.com
« October 1998December 1998 »
USR Total Control Mailing List Archive · Messages from 1995–2001 · Generated from archived data