Subject: (usr-tc) 2 Issues

From: Barry Yost <[email-masked]>
Date: Wed, 29 Sep 1999 20:48:19 +0000

We have recently consolidated all of our nodes to use the
TC HiPerARC + DSP chasses, and in doing so, have come across 2 issues:

The main problem is what I refer to as "hung modem" where 2 contiguous modems
in a DSP will somehow fail in such a way that incoming calls are answered,
but never complete the carrier. (list con shows them as call type
DIALIN INVALID) The errant modems show orders of magnitude more failed calls
in performance monitor. What the user dialing in experiences is something like
this: The TC picks up and transmits the answer tone. The client modem begins
making the handshake sounds, but the TC continues with the single tone as if
the client modem had not responded. Selecting the modems in TCM and
performing a software reset on them will clear it up 99% of the time.
They always appear in pairs.

Does anyone know what might cause this?
The chases have 130A dual power supplies, and the following code rev's:
DSP: 2.0.81
ARC: 4.2.32
NMC: 6.2.17

(This happens in different POPs as well.)

Also, we had bad experiences turning on BACP in earlier code rev's of the ARC
cards, and at 3Com's advise, left the feature disabled. We have many users of
Ascend Pipeline routers that apparently insist on using bacp for dynamic
bandwidth if they can't have their proprietary Ascend protocol. One user in
particular has spent extensive hours with Ascend trying unsuccessfully to make
a P130 do dynamic channel allocation with our HiPerARC servers.
Does anyone have a workaround for this, or has BACP been stabalized enough
to warrant activating the feature? 

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Curt Shambeau <[email-masked]>
Date: Wed, 29 Sep 1999 21:00:16 +0000

> Does anyone know what might cause this?

DSP Lockups.  Each DSP handles 2 modems, and as such, when it locks up in
any way, it takes out 2 modems.   Depending on switch type, it manifests
itself to the customer in various ways.  You described one.  

This has been a horrible bug in the DSP since it was first introduced, and
they have NEVER been able to fix it.  It has gotten better over the years,
but it is still a major concern for us.

Our solution is to watch for it - busy out the entire card, wait for
customers to drop off the card, and then reboot it.

---------------------------------------------------------------------
| Curtis V. Shambeau  |  [email-masked]  |  Senior Vice President  |
|   ExecPC, Inc. - A Voyager.net company - NASDAQ Symbol:  VOYN     |
---------------------------------------------------------------------

-

---

From: [email-masked]
Date: Wed, 29 Sep 1999 21:08:05 +0000

This is an unacceptable alternative!  If you experience these
problems and it has been noted by 3Com, then it should be addressed and
corrected!!  What about all those that are running several HUNDRED TC
hubs!

Just my .02 worth!

==============================================================================
Phillip Ferraro				WorldNet Access, Inc
[email-masked]	Onslow County's PREMIER InterNet Service 
Voice (910) 346-0835		    824 Gumbranch Square, Suite R3
FAX   (910) 455-1933		     Jacksonville, Nc  28540-6269
==============================================================================

-

---

From: Curt Shambeau <[email-masked]>
Date: Wed, 29 Sep 1999 21:11:02 +0000

> corrected!!  What about all those that are running several HUNDRED TC

I agree that it is unacceptable, and I am running several hundred TC hubs.

-

---

From: [email-masked]
Date: Wed, 29 Sep 1999 21:37:49 +0000

It happened about 3 times in a year over 6 DSP's.... ANY complex equipment
will have quirks.

Solution?  A pager and a perl script.

Paul Farber
Farber Technology
[email-masked]
Ph  570-628-5303
Fax 570-628-5545

-

---

From: Carl Litt <[email-masked]>
Date: Wed, 29 Sep 1999 21:39:22 +0000

Not only is it unacceptable to have to babysit a ~$10,000 DSP card,
but we can't do it here anyways.  When we soft-busy out the card,
incoming callers get a switch-bitch message.  (We're new to PRI,
and haven't had time to debug yet).

We're using round-robin modem assignment.  With fixed assignment, a bad
modem will always be assigned to the n'th DS0.  Any time that DS0 rings,
that bad modem answers.  With round-robin on PRI, the bad modem will
answer once, then rotate out to be the spare for a little while.

I usually have several modems each day going FUBAR.  Of course, you 
can't busy out a modem, and software resets don't do the job, so we're
stuck living with it.

I noticed this behaviour of the locking modem pairs months ago and
pointed it out on the list, but couldn't get a discussion going.

Anyone have any suggestions?

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 29 Sep 1999 21:51:04 +0000

Thus spake Carl Litt
>and haven't had time to debug yet).

Get off of NI-2 and go to a custom translation.  NI-2 doesn't have any
concept of "service messages" meaning that if you soft-busy out a ds0,
it has no way of informing the switch of that, so the switch will still
try to send calls down that ds0.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-