I have 35 T1 circuits coming into my dialup pool. These circuits are in a hunt group which Verizon (f/k/a Bell Atlantic) controls. I had some trouble with one of my chassis where the HiPerARC's NIC failed. When I went to busy out the DS0s on this chassis (whose T1s are in the middle of this hunt group), instead of the calls being routed onto the next available T1, I get a fast busy as if the chassis is "seizing" all the circuits. I had to power the chassis down in order for calls to continue on to the next T1 in the hunt group. Bell At... err... Verizon says there's nothing wrong with their hunt software. Anyone have a clue handy? Can I really not remotely busy a chassis out and leave it powered up for maintenance, or is this a peculiarity with the bad NIC on the HiPerARC? ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - 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 mmm3@cornell.edu
I have 35 T1 circuits coming into my dialup pool. These circuits are in a hunt group which Verizon (f/k/a Bell Atlantic) controls. I had some trouble with one of my chassis where the HiPerARC's NIC failed. When I went to busy out the DS0s on this chassis (whose T1s are in the middle of this hunt group), instead of the calls being routed onto the next available T1, I get a fast busy as if the chassis is "seizing" all the circuits. I had to power the chassis down in order for calls to continue on to the next T1 in the hunt group. Bell At... err... Verizon says there's nothing wrong with their hunt software. Anyone have a clue handy? Can I really not remotely busy a chassis out and leave it powered up for maintenance, or is this a peculiarity with the bad NIC on the HiPerARC?
The NIC on the HiPerARC *shouldn't* affect it...though I have seen weirder things happen. Are these channelized T1's or ISDN PRI? If its PRI...my first guess would be running a translation that doesn't support service messages, but from what you said, I'm guessing chan-T1...not sure how chan-t1 deals with that type of situation though. :/ -- 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.
Also sprach mmm3@cornell.edu
I have 35 T1 circuits coming into my dialup pool. These circuits are in a hunt group which Verizon (f/k/a Bell Atlantic) controls. I had some trouble with one of my chassis where the HiPerARC's NIC failed. When I went to busy out the DS0s on this chassis (whose T1s are in the middle of this hunt group), instead of the calls being routed onto the next available T1, I get a fast busy as if the chassis is "seizing" all the circuits. I had to power the chassis down in order for calls to continue on to the next T1 in the hunt group. Bell At... err... Verizon says there's nothing wrong with their hunt software. Anyone have a clue handy? Can I really not remotely busy a chassis out and leave it powered up for maintenance, or is this a peculiarity with the bad NIC on the HiPerARC?
The NIC on the HiPerARC *shouldn't* affect it...though I have seen weirder things happen.
Are these channelized T1's or ISDN PRI? If its PRI...my first guess would be running a translation that doesn't support service messages, but from what you said, I'm guessing chan-T1...not sure how chan-t1 deals with that type of situation though. :/
Actually, they're ISDN PRI. I should ask Bell...err...Verizon about this, I guess, and hope for a straight answer for once. Thanks! ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - 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 mmm3@cornell.edu
Actually, they're ISDN PRI. I should ask Bell...err...Verizon about this, I guess, and hope for a straight answer for once. Thanks!
Oh, they *are* PRI? Are you running NI-2 on them? If so, then you don't have service messages available to you and the chassis has no way to indicate to the switch to take those DS0's out of service...thus the switch will continue to send calls down those DS0's which the dual-pri or DSP card can only just reject, resulting in the fast busy. If you switch to custom-5ESS or custom-DMS100 or whatever switch type your on...rather than using the (sub-)standard NI-2, you should get service messages and the ability to busy out a DS0 and have the switch skip it. -- 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.
Quoting Jeff Mcadams <jeffm@iglou.com>:
Also sprach mmm3@cornell.edu
Actually, they're ISDN PRI. I should ask Bell...err...Verizon about this, I guess, and hope for a straight answer for once. Thanks!
Oh, they *are* PRI?
Are you running NI-2 on them? If so, then you don't have service messages available to you and the chassis has no way to indicate to the switch to take those DS0's out of service...thus the switch will continue to send calls down those DS0's which the dual-pri or DSP card can only just reject, resulting in the fast busy.
Jeff is correct here. Unless and until you have a switch that recognizes service messages - DMS or 5E or 4E you will not be able to busy of the B channels. However if you have a NI 2 switch Telco can configure the switch with 5E or DMS messages - if that is done there should be no issue. Its still a Bell issue - check your config and see that you send a blue alarm and ask them if they see the blue alarm V
If you switch to custom-5ESS or custom-DMS100 or whatever switch type your on...rather than using the (sub-)standard NI-2, you should get service messages and the ability to busy out a DS0 and have the switch skip it. -- 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.
=========== -V ========== - 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.
Quoting Jeff Mcadams <jeffm@iglou.com>:
Also sprach mmm3@cornell.edu
Actually, they're ISDN PRI. I should ask Bell...err...Verizon about this, I guess, and hope for a straight answer for once. Thanks!
Oh, they *are* PRI?
Are you running NI-2 on them? If so, then you don't have service messages available to you and the chassis has no way to indicate to the switch to take those DS0's out of service...thus the switch will continue to send calls down those DS0's which the dual-pri or DSP card can only just reject, resulting in the fast busy.
If you switch to custom-5ESS or custom-DMS100 or whatever switch type your on...rather than using the (sub-)standard NI-2, you should get service messages and the ability to busy out a DS0 and have the switch skip it.
Jeff is correct here. Unless and until you have a switch that recognizes service messages - DMS or 5E or 4E you will not be able to busy of the B channels.
However if you have a NI 2 switch Telco can configure the switch with 5E or DMS messages - if that is done there should be no issue.
Its still a Bell issue - check your config and see that you send a blue alarm and ask them if they see the blue alarm
The switch type is DMS100. The call routing is fixedAssignment. I think there is an issue with Verizon's switch configuration or hunt group and will be in touch with one of their engineers this morning, hopefully. (Err...what's a "blue alarm"?) ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - 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.
Quoting mmm3@cornell.edu:
The switch type is DMS100. The call routing is fixedAssignment. I think there is an issue with Verizon's switch configuration or hunt group and will be in touch with one of their engineers this morning, hopefully. (Err...what's a "blue alarm"?)
Fixed Assignment, that basically means that every DS0 is fixed and if you busy out the DS0 you will not roll over, you will net a network busy. A blue alarm - All you need to do is take b-channels out of service and see if the switch see the B as OOS - I would say this is happening for as per the switch setting you are getting a network fast busy. -V
********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu **********************************************
- 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.
=========== -V ========== - 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.
Quoting mmm3@cornell.edu:
The switch type is DMS100. The call routing is fixedAssignment. I think there is an issue with Verizon's switch configuration or hunt group and will be in touch with one of their engineers this morning, hopefully. (Err...what's a "blue alarm"?)
Fixed Assignment, that basically means that every DS0 is fixed and if you busy out the DS0 you will not roll over, you will net a network busy. A blue alarm - All you need to do is take b-channels out of service and see if the switch see the B as OOS - I would say this is happening for as per the switch setting you are getting a network fast busy. -V
********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu **********************************************
- 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.
=========== -V ========== - 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.
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? ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - 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.
Anyone have a source for the 64MB to 128MB upgrade to the HiPerARC card? The 3Com version is VERY expensive! - 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.
Quoting 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. V
********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu **********************************************
- 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.
=========== -V ========== - 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.
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. ********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu ********************************************** - 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 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.
I just ran into something interesting that is worth noting. Aparently the hiperdsp's won't re-send a service message if they lose their D-channel connection (switch goes does, PRI swapped, etc) or (like I think they should) if they get a call routed to an out-of-service B channel. So if your CO loses track of which B channels are out of service, either cause the CLEC crashed their switch or you do something like plug the PRI into the wrong slot, you'll start getting calls again to the out-of-service channels, breaking your hunting. The only cure I can think of is to reset the card. 3com should modify their software to re-send service messages if the d-channel is lost or the card gets a call on a channel that it thinks is out-of-service. - 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.
Quoting mmm3@cornell.edu:
I have 35 T1 circuits coming into my dialup pool. These circuits are in a hunt group which Verizon (f/k/a Bell Atlantic) controls. I had some trouble with one of my chassis where the HiPerARC's NIC failed. When I went to busy out the DS0s on this chassis (whose T1s are in the middle of this hunt group), instead of the calls being routed onto the next available T1, I get a fast busy as if the chassis is
How is the call being routed? First available? you will get fast busy only if its routed First Available - Bell or Verizon is wrong. Its their issue. they have to make sure that their routing is correct. V "seizing" all the circuits. I had to power the chassis down in order
for calls to continue on to the next T1 in the hunt group. Bell At... err... Verizon says there's nothing wrong with their hunt software. Anyone have a clue handy? Can I really not remotely busy a chassis out and leave it powered up for maintenance, or is this a peculiarity with the bad NIC on the HiPerARC?
********************************************************* Michelle M. Mogil Network and Computing Systems 735 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8521 email: mmm3@cornell.edu **********************************************
- 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.
=========== -V ========== - 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 (5)
-
Aaron Nabil -
Jeff Mcadams -
Mailing List Reader -
mmm3＠cornell.edu -
Veda Narayan