Also sprach mmm3@cornell.edu
Well...I spent some time with the Verizon engineers who are familiar with our set-up troubleshooting this problem. I did the same thing I did the other day when the ARC went down: busied out all the PRIs on that chassis. We watched as calls were routed correctly onto the next available PRI as they are supposed to. The difference between this time and the time I was having trouble was I had a functioning NIC behind the HiPerARC. This raises an interesting question: does a dead ARC-NIC cause some kind of strange state on the chassis whereby it somehow holds the hunt group hostage? If so, how??? Any clues, 3Com?
A dead nic does not hold the hunt group hostage. The hunt group is dependent on your Telco provider. If your hunt sequence is first available - a dead nic will roll over.
I *know* that this is how it's supposed to happen. However, this is not the way the chassis was behaving in Real Life. I had done a local busy-out on all the PRIs on the chassis and calls were *not* rolling onto the next available PRI. The only way I could get the calls to carry through was to power down the chassis. My question is *why* did I have to do this? I *should* have been able to just send telco a busy signal and have the calls roll on.
Let's be careful about what's being said here. *If* you have the service loss busy-out functions on the Arc set up, then the Arc can tell the NMC to busy out lines if the Arc looses its NIC...if you don't have the service loss busy out stuff set up...you should get a modem connect, but then no authentication (assuming RADIUS here...if non-RADIUS, then you'll just get no traffic throughput). If you loose a DSP or dual-pri nic, then the pri/t1 will be down, and the switch should skip it regardless (this has nothing to do with the chassis...the switch will see an alarm on the t1/pri and not even attempt to send calls down it). Now then...we get to the issue of setting busy-outs... This gets into how the switch handles things that the chassis tells it. The way to get calls to hunt past lines for PRI is to set the B channels as Local Out Of Service (LOOS). For the switch to know that the lines are out of service, though, requires that service messages be able to be passed between the chassis and the switch...NI-2 doesn't support service messages, you'll need a custom translation of some type to do service messages in my experience. *If*, however, you set the equipment to generate a "busy" signal...the switch will honor that...meaning that it will pass that busy signal back to the end-customer and the end-customer will get a busy signal on their line. By default, the chassis are set to generate cause code 58 I believe, which will actually end up generating either a fast busy signal, or some sort of voice message indicating all circuits are busy or something like that. Cause code 17 will generate a normal busy signal in case you're interested. The crux of the issue, though, is that once the switch has decided to try to send a call down a B channel, the only thing the chassis can really do is reject the call, which results in a busy signal or voice message, or something along those lines, for the end-customer. The only way to prevent this from happening is for the chassis to inform the switch ahead of time (via service messages) to not send the call down that B channel, so the switch won't even try. -- 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.