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

RE: (usr-tc) Connect via the Arc to the Dsp
by Stainforth, Matthew 14 Jan '00

14 Jan '00

go to 3kb and search for "reverse telnet"...that should get you the article that explains it in detail. > -----Original Message----- > From: Terry Kennedy [SMTP:terry@olypen.com] > Sent: Thursday, January 13, 2000 10:53 PM > To: usr-tc(a)lists.xmission.com > Subject: (usr-tc) Connect via the Arc to the Dsp > > I've heard this can doen rather using console cables to each > DSP. Can someone point me to right docs to figure this out. I > can't find it anywhere. Meanwhile back to the PDF files. > Thanks > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) State of the Hub (part 1)(take 2)
by Jeff Mcadams 14 Jan '00

14 Jan '00

We've recently seen the release of HiPer Arc releases 4.2.32 and 4.1.22. So now seems to be an appropriate time to take a look at the State of the Hub (with apologies to the U.S. Government and Larry Wall for the name). I'm trying to bring about some structure to these messages that I post to give people a bit more assistance in finding the content that they need/are interested in out of my greater ramblings. I'll start off with some specific issues and questions that I have (essentially like the rest of my messages), and then go into some rather more broad thoughts. First, with release of 4.1.22, 3Com seems to have added some support, or at least control over directed broadcasting. Specifically disable/enable ip directed_bcast_forwarding. The release notes describe it as "When enabled, it allows directed broadcast forwarding from the user." My question is...how does this work? It seems to imply that it magically figures out what's going to be a directed broadcast that the user is sending out and drops it on the floor. I hope this isn't the case, but that it only drops directed broadcasts for directly connected networks. This, of course, because there is no way for the Arc to know if something is going to be a directed broadcast on a remote network. :) Second, SAA (Source Address Assurance) now pays attention to the netmask assigned on a connection to check to make sure that the source address coming in from that connection is indeed supposed to be able to be sourced from there. Previously, this only worked for /32's, but the description in the Release Notes indicates that it now considers the netmask for that. Does it consider a seperate route? I can understand if it wouldn't...that's considerably less trivial, but it would be good functionality to add to this feature. Even further...would be to allow it if the address is reachable (As best the Arc can tell) from that connection...which means that it may not even be in the routing table. You'd have to consult with the OSPF table (well...not in 4.1.x, but in later code), as well as any other routing protocol tables and static routes that aren't preferred. Anyway...just a question that I'm sure will come up before long that will be good to get clarified. :) OK...now on to greater, broader, longer-standing issues. :) 3Com's release numbering (at least on the total control stuff) is still nuts. I'm not sure what would be a good solution...but some releases counting up, and some releases counting down is just completely confusing to customers. Even long-time customers can have difficulty figuring out what the status of a particular release is, and which releases are newer than others. New customers are usually totally baffled, and understandbly so. This really needs to be changed...its been a call that those of us on the list have been making for many years, with no result. The best response (and given the people that are responding, this is understandable) that we get is yet another explanation of the current release numbering system, which isn't what is needed. I applaud Mike Wronski's and Krish's and Chuck Stace's, and the rest of the crew's patience in explaining this time and time again to new folks, and clarifying the status of releases when they're asked about. Really though, 3Com as a whole, would be much better served by letting these people do the job they were hired to do, not looking up (I know, most of you know them well enough that you don't have to look them up) what the status of a specific version of code is. Security releases are still taking *WAY* too long to be made widely available. There have been several security issues that have been made public in the last year or so, ER's have been made available that address these issues. Due to the nature of ER's though, these are not widely available, or publicized, or clearly understood (see the release number issue above ;). HiPerBomb was announced (I believe by Ed Taylor?) in mid-August. I had announced an SNMP security hole before that...both of which affected 4.1.59-6. Though ER's were available, it has taken 5 months for an SR to be made available (in the 4.1.x tree) that includes these fixes. This is an order of magnitude or two off from the amount of time this should be. Security fixes for problems of the magnitude represented by HiPerBomb and the SNMP issues that had been brought should have code widely available that addresses these on the order of a week or so from the time that they are made known to 3Com. I still get reports of people running into problems with NETServers, and 3Com continues to be unresponsive in dealing with thier handling of the practical end of support for this product. At this point, support contracts for the NETServer products should have all expired (unless 3Com continued to sell support for NETServers after they lost access to the source code which would be even worse!), so complaints have less of a basis at this point, but given the poor way that 3Com originally handled the NETServer to HiPer Arc transition, some complaints still are valid. Hopefully, 3Com has at least learned from the NETServer fiasco and won't repeat the same mistake twice, but that's little consolation for people that are still making do with buggy NETServer code as a result of 3Com's abrupt transition from the NETServer platform to the HiPer Arc platform. (cont. due to message size limitations) -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

RE: (usr-tc) HyperARC/DSP Problem
by Stainforth, Matthew 13 Jan '00

13 Jan '00

That was my original thought when this thread started. If that's the case, you need to set the NFAS Interface ID on your second card to whatever the telco has it set to on their end and the Logical Group Number to the same number as your first card. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Mark Thornton [mailto:mark@corridor.net] > Sent: Thursday, January 13, 2000 4:36 PM > To: usr-tc(a)lists.xmission.com > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > Is this an NFAS problem? Our PRI lines all appear as a single > trunk at the > telco, controlled by the NFAS functionality across as many > PRI lines that > are included in the NFAS group. At least that is how the switch guys > described it to me. All I do at my end is make sure the > second, third, etc. > card are set up as being a member of the NFAS group, and > determine whether I > am going to add additional d channels for redundancy. If the > PRI lines are > not part of an NFAS group, then there must be some sort of hunting or > rollover involved. > > It is very similar to the way our incoming T1's are handled, > they all are > piled into one big group as available lines with no hunting > set up at all. > While hunting would be beneficial in some troubleshooting > situations we had > it get messed up so many times they moved to this mode. Any > time we add > lines the switch tech just adds the transport layer to the > group and whamo, > there are additional lines at our site that work without the > intervention of > some other "programming tech" at the telco. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

Re: (usr-tc) HyperARC/DSP Problem
by K Mitchell 13 Jan '00

13 Jan '00

At 11:26 AM 1/13/00 -0500, Paul Farber wrote: >Call in to the rack and see if you get 'dead air'. IE pick up with no >negotiation. This isn't always conclusive. You may have a customer getting "dead air" and, since that channel's in use, you'll get rolled over to a working modem. >Or if you get a busy but still have open modems. I don't think there is a >way in TCM to check it. I'm not aware of any way to through TCM either. -- Kirk Mitchell-General Manager mitch(a)keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

RE: (usr-tc) Netserver PRI Max connections
by Phil Le Clercq 13 Jan '00

13 Jan '00

Yep it's set to 60. "Assigned Pool Size: 60" Phil -----Original Message----- From: Charles Sprickman [mailto:spork@inch.com] Sent: Thursday, January 13, 2000 4:03 PM To: 'usr-tc(a)lists.xmission.com' Subject: RE: (usr-tc) Netserver PRI Max connections It's a dumb question, but you do have a big enough IP pool, right? :) Charles - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) Netserver PRI Max connections
by Phil Le Clercq 13 Jan '00

13 Jan '00

Hi all, I have a chassis with dual pri, 56 digital modems ( 14 quads) and one Netserver (3.8.1). My problem is the chassis never takes more than 30 calls. Both PRI's (European) are working ok, I got the telco to busy out the other feeds so all calls went to this chassis. You can see the modem's taking the call but above 30 connections the user gets "disconnected from the remote machine" as an error. I believe the problem lies with the Netserver. I guess I'm just missing a command to set max connections to 56 but I cant remember or find it! I presumed that Netservers were set to 60 connections by default, this is something I've not had to do before as all our others chassis' have 30 ports only. Thanks in advance for any help :-) Cheers, Phil - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) DSP cards rebooting
by Cheryl Johnson 13 Jan '00

13 Jan '00

Anyone else have this problem using the 2.0.60 version on the HiPerDSP cards? This code is supposed to help with the modem pair problem. Although this problem has not been as noticeable as the past, I still have various modem problems and recently noticed DSP cards rebooting. I just recently upgraded the TC chassis to the code above and seem to having problems with it. I have also been experimenting with increasing the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with increasing this setting? I am not sure if this may be causing problems or not. Cheryl Johnson netadmin(a)seidata.com SEI Data Network Services, Inc.

3 4

Re: (usr-tc) HiperARC 4.1.22 and 5.10.9 Quads
by Greg Coffey 13 Jan '00

13 Jan '00

We've been running it for weeks with no apparent problems. I don't know if its any better but it's certainly not any worse. At 05:02 PM 1/12/00 -0600, you wrote: >Will HiperArc version 4.1.22 work with: > >NMC 5.5.5 >Quad Modem version 5.10.9 >Dual Channelized T1 (386) 4.2.1 > >I'm scared to upgrade to 6.1.6 on the Single-Sided Quads. 5.10.9 is very >stable for us. Anyone running 6.1.6 fine??? > >- > andrew > > >- > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey(a)vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

Re: (usr-tc) Disconnect reasons
by Steve Valiunas 12 Jan '00

12 Jan '00

Greg, See the Hiper Network Management Card SNMP and MIB Reference (# 1.024.1661-00), available on http://totalservice.3com.com. Chapter 24: Modem Disconnect and Fail to Connect Reason Reference is what you'll be interested in. STeve Valiunas "Greg owens" <gowens(a)magnolia-net.com> on 01/11/2000 07:35:08 PM Please respond to usr-tc(a)lists.xmission.com Sent by: "Greg owens" <gowens(a)magnolia-net.com> To: usr-tc(a)lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: (usr-tc) Disconnect reasons Looking at the Total Control It will list several types of disconnect reasons.....rcvdGatewayDiscCmd, NormalUserCallClear,v42DisconnectCm, along with several others...Where can I find a explanation of these reasons. Which ones other than CarrierLoss should alert me to problems other than the users just logged off. Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com

3 2

(usr-tc) RADIUS check items?
by Jesse Sipprell 12 Jan '00

12 Jan '00

Can anyone tell me what RADIUS check attributes are sent (by the HARC) in the initial auth request packet in order to determine an Async or ISDN call? Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800.496.4736 * Finger jss(a)evcom.net for my PGP Public Key * - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1