(usr-tc) Upgrade to 5.0.9 beware of ppp offloading ?
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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
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.
BTW: 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: 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.
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) * mandrews@dcr.net * 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.) On Tue, 20 Jun 2000, Donald Baud wrote:
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 "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the 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.
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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
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: 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.
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? Jeff Mcadams wrote:
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.
-- --------------------------------------------------------------------- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.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.
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: 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.
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)
- 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.
- To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.
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: 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.
participants (4)
-
Donald Baud -
Jeff Mcadams -
Mark E. Levy -
Mike Andrews