Subject: (usr-tc) Upgrade to 5.0.9 beware of ppp offloading ?

From: Donald Baud <[email-masked]>
Date: Tue, 20 Jun 2000 23:35:44 +0000

Hi,
I upgraded several  TC boxes to the latest code Harc 5.0.9 and DSP 2.1.9
All went well, and I haven't heard any complaining.
Yesterday though, I upgraded the last chassis and for some reason each
HiperDSP would answer most of the PRI channels except a few (2 or 3) and
gives a fast busy signal to the unlucky caller.
The Performance monitor reports "Dialing(3)" on the faulty channels instead
of the usual "Incoming call is connected(5)" in the DS0 Timeslot status.
The only way to fix this was to busy out those channels.

-I switched the DSP cards to another chassis and the problem disapears.  So
DSP's are fine
-I changed the cage (chassis skeleton) and the problem persists. So the cage
is fine
-I changed the HiperArc card and the problem was fixed.  So there was
something wrong with the card

When a caller dials into one of those defective PRI channels, The following
error message is reported on the HiperArc console:
At 12:36:53, Facility "GWC Modem Driver", Level "CRITICAL":: GWCMDMDRV FSM
illegal event interface slot:1/mod:13, state WaitCallLstRsp   , event
NotifyDisconnect

The only difference I could see was that the "defective" hiperarc had ppp
offloading disabled.  Unfortunately, now that my chassis is running fine
with the new HiperArc (with ppp offloading enabled), I nolonger can test or
confirm this theory.
I am hoping someone would comment or confirm this behaviour with 5.0.9 with
ppp offloading disabled.

BTW:
5.0.9 is running fine with 64Meg HiperArc cards

-
 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: Jeff Mcadams <[email-masked]>
Date: Wed, 21 Jun 2000 00:04:18 +0000

Also sprach Donald Baud
>The only difference I could see was that the "defective" hiperarc had
>ppp offloading disabled.  Unfortunately, now that my chassis is running
>fine with the new HiperArc (with ppp offloading enabled), I nolonger
>can test or confirm this theory.

Well, not trying to make light of your situation at all, and I certainly
agree with you, this probably should be checked out to see if this is
the case, but if it works when ppp offloading is *en*abled, then I don't
see this being a huge issue since enabling ppp offloading is the
preferred manner anyway.  :)  Obviously if something else crops up that
would require ppp offloading to be disabled, then we'd have a problem,
but if enabling it fixes it, I'd say enable it and be happy.  :)

>I am hoping someone would comment or confirm this behaviour with 5.0.9
>with ppp offloading disabled.

FWIW, my one chassis running 5.0.9 has ppp offloading enabled and I
haven't seen any evidence of any problems like this.

>5.0.9 is running fine with 64Meg HiperArc cards

This really *shouldn't* make any difference, although I certainly don't
think its a bad idea to include this info...mine has 128megs.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Mike Andrews <[email-masked]>
Date: Wed, 21 Jun 2000 21:16:45 +0000

More likely it's a chassis awareness problem... your "bad" ARC probably
doesn't know the DSP's are there.  Do a "list chassis" and "list
interface" and make sure all your modem cards are listed there.  If
they're not, you'll get fast busies when calls hit them.

Mike Andrews (MA12) * [email-masked] * http://www.bit0.com/
VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY
Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville
www.fark.com: If it's not news, it's Fark.  (Or something like that.)

-

---

From: Donald Baud <[email-masked]>
Date: Fri, 23 Jun 2000 19:23:54 +0000

After upgrading some DSP's to 2.1.9 I noticed, I was getting a fast busy
signal out of a sudden on some PRI spans (it happens once every 2 days).
Although all PRI channels show InService, I can fix the problem by sending a
busy out on the PRI channels and restore them back.  This is new and I did
not have this problem with DSP codes 2.0.xx
I have reviewed the release notes and noticed a new behavior introduced with
the 2.1.9 code:
======= From the DSP 2.1.9 release notes ==================
PRI Service Messaging
The behavior of PRI Service Messaging has changed in the 2.1.9 version
of code. The 2.1.9 version of HiPer DSP code will not change the
B-channel service state from Out of Service (OOS) to In Service (IS) if a
Service ACK is not received from the switch. For this reason, if your span
does not support Service Messaging, such as NI-2, you must disable
service message support on the HiPer DSP since it is enabled by default.
To disable support, issue the set servicemsg disable span level
command from the console.
=================================================

My questions are:
- How can I find out if the telco switch (DMS100) sends a Service ACK or not
?
- What kind of problem will I get if I disable the PRI messaging support (as
stated in the release notes)
- How can I disable the PRI messaging support remotely through a HARC telnet
connection

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 23 Jun 2000 19:43:29 +0000

Also sprach Donald Baud
>My questions are: - How can I find out if the telco switch (DMS100)
>sends a Service ACK or not ?

If you're using NI-2 translation (which is not a switch type per-se),
then you don't have service messages (not sure who the bright boy was
that came up with an ISDN standard that doesn't have the ability to busy
out the lines...oi), if you're on a custom DMS-100, then you should be
OK.

>- What kind of problem will I get if I disable the PRI messaging
>support (as stated in the release notes)

You won't be able to do any of the functions that require services
messages...such as, busy out the lines with a localoutofservice command
on the ds0's.

>- How can I disable the PRI messaging support remotely through a HARC
>telnet connection

You can't directly...though you can use the Arc to set up a "virtual
console" port to each DSP and disable them through the DSP "console"
connection.  Check the Arc user manual for info on how to set up DSP
virtual consoles.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: "Mark E. Levy" <[email-masked]>
Date: Fri, 23 Jun 2000 19:55:39 +0000

This brings up another question.  We ARE on an NI-2 *&^*&$ switch.  Just
how do I go about busying out and restoring modems without having to
hardware reset the entire shooting match?

-- 
---------------------------------------------------------------------
Mark E. Levy, President
FSINet, Inc.
800-827-6085 x202
847-753-6832 fax
www.fsi.net
[email-masked]
---------------------------------------------------------------------

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 23 Jun 2000 20:03:28 +0000

Also sprach Mark E. Levy
>This brings up another question.  We ARE on an NI-2 *&^*&$ switch.
>Just how do I go about busying out and restoring modems without having
>to hardware reset the entire shooting match?

With NI-2, you really have no way to control individual ds0's, so you're
really pretty much SOL.  The only possibility is extremely
tedious...that being call your telco and have them busy the lines out
from their side :/  Depending on what type of switch you're on, it
should not be difficult to get your telco to switch to a custom
translation so you can make use of service messages.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Donald Baud <[email-masked]>
Date: Fri, 23 Jun 2000 20:37:02 +0000

If you say that disabling the messaging support on the DSP will forbid me
from using the localoutofservice command.  How do you explain that we could
busy out lines with the 2.0.x DSP code (keeping in mind that the messaging
support feature was disabled by default on those codes)

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 23 Jun 2000 21:28:08 +0000

Also sprach Donald Baud
>If you say that disabling the messaging support on the DSP will forbid
>me from using the localoutofservice command.  How do you explain that
>we could busy out lines with the 2.0.x DSP code (keeping in mind that
>the messaging support feature was disabled by default on those codes)

Uhm...the release notes indicate that service messages are *en*abled by
default on DSP code.  Having never actually run 2.0.x code, I can't say
for sure (most of my DSPs are still at 1.2.x :).

If you're on a span that supports service messages (as you seem to
indicate), then this issue really *shouldn't* be your problem, though it
might be something related.  This really only affects bringing the ds0's
in service to begin with.  If your span is dropping for some reason, and
then not getting an ACK back on its inservice message, then you could
get bitten by this issue, but then you also have to consider, "why is
the span dropping to begin with?" and "why is it not getting an ACK back
when it should?" as other issues that you can address to solve this
issue.
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-