Jason, Thanks for the response and tips. Although this news is not particularly what I wanted to hear. One would think a Telco would have to provide you with service messages if that's what your equipment needed. I understand that it probably has to do with some feature set for which they have to pay for that feature to be enabled in the switch - and since my three PRIs aren't providing enough revenue for them they don't want to do this for us. I did have the service messages disabled on all three DSPs already and unfortunately I still experience these random alarms showing up on one of the three PRIs, usually the last in the hunt. I end up having to do something really funky to get all three to come back up in _apparent_ service - reboot the fronts from right to left and then immediately reboot the backs from right to left. Any variance from this procedure ends up producing continuing alarms on one or more of them. Incidentally, I know its all about service messages - Had the same problem when we took over some circuits after a buyout and those were all provisioned NI2 - same exact problems, and when we had them changed over to custom (on a 5E switch) the problems went away and all of our functionality was back. The way I see it, that's a lower quality of service from the Telco since we are guaranteed to have more problems on NI2 provisioned circuits than on Custom. Wonder if the same problems occur with people using Ascend, Livingston and the like. Mike ---------- Original Message ---------------------------------- From: Jason <jaslist@iland.net> Reply-To: usr-tc@mailman.xmission.com Date: Tue, 26 Mar 2002 14:14:56 -0600

We had similar problems in a small town with a DMS10 switch. There is a setting from the console at the DSP which disables service messages. We also asked if they (Sprint) could enable service messages, since it's very difficult to manage problem modems/dsp's if we can't busy out DS0's. They of course told us no, and they would not even consider enabling that feature until more people wanted it. So we are SOL. However since I have disabled service messages I have not had 1 DSP crash.

At the console of the DSP type: 'chdev span' 'set servicemsg disable' 'cmd svspcfg'

-- That last command will save the config to NVRAM. Also, if you try and busy out a DS0, or send some type of service message the DMS10 will probably puke, and cause that DSP to crash (at least that is what happened to us) Hope this helps!!!

At 01:41 PM 3/26/2002, you wrote:

...

Currently we have a 3com Chassis at a remote POP serving customers in Alltel-land. This is a pretty remote place, and so Alltel is only using a DMS-10. They have provisioned our circuits NI2 - Despite my asking for them to provide Custom settings, they will not do so - claiming that their switch does not have the capabilities to do so (or that their policy doesnt allow for Custom).

NMC 7.1.8 HiperARC 4.1.26 DSP 2.1.9

The PRIs are FAS, NI2.

Right now we have three of these PRIs in this area. I can't keep any three of them operating at the same time. I'm used to running everything with 5ESS Custom settings rather than NI2. It will fill the first two cards in the hunt up and then bail on the third - an alarm will come on on the third one, and then I"ll have to resort to some ridiculous reset scheme in order to get all three circuits back up and green.... Then, when customers fill up 1 and 2 and get to PRI #3, it'll happen all over again.

I also am not able to adequately take individual DS0s out of service like I am on the other equipment.

Is there anything I can do on my end to make up for the fact that I'm forced to use NI2 and not have service messages? I'm just wondering if there is a workaround (or better configuration) that will allow me to manage this remote dialup chassis a little better and use all available circuits without these types of problems.

I'm also interested if I should be able to demand Custom rather than NI2 - I think Alltel once told me that their tariff does not allow for Custom or something to that effect. Is this baloney?

Any suggestions would be greatly appreciated.

Thanks,

Mike Tindor FIRST Internet

________________________________________________________________ 1st.net

_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc

************************ Jason Watkins I-Land NOC jwatkins@iland.net ************************

_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc

________________________________________________________________ 1st.net