Subject: (usr-tc) Fast busy...

From: [email-masked]
Date: Fri, 13 Oct 2000 19:53:05 +0000

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: [email-masked]
**********************************************

-
 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: Fri, 13 Oct 2000 20:15:42 +0000

Also sprach [email-masked]
>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: [email-masked]
Date: Fri, 13 Oct 2000 20:31:43 +0000

>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!

-

---

From: Jeff Mcadams <[email-masked]>
Date: Fri, 13 Oct 2000 20:38:47 +0000

>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Veda Narayan <[email-masked]>
Date: Mon, 16 Oct 2000 01:37:37 +0000

> 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

> with the bad NIC on the HiPerARC?

===========

-V

==========

-

---

From: Veda Narayan <[email-masked]>
Date: Mon, 16 Oct 2000 01:43:27 +0000

> 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

===========

-V

==========

-

---

From: [email-masked]
Date: Mon, 16 Oct 2000 13:28:52 +0000

>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"?)

-

---

From: Veda Narayan <[email-masked]>
Date: Mon, 16 Oct 2000 20:00:01 +0000

> 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

===========

-V

==========

-

---

From: Veda Narayan <[email-masked]>
Date: Mon, 16 Oct 2000 20:00:04 +0000

-V

===========

-V

==========

-

---

From: [email-masked]
Date: Mon, 23 Oct 2000 13:10:49 +0000

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?

-

---

From: Mailing List Reader <[email-masked]>
Date: Tue, 24 Oct 2000 00:18:11 +0000

Anyone have a source for the 64MB to 128MB upgrade to the HiPerARC card?
The 3Com version is VERY expensive!

-

---

From: Veda Narayan <[email-masked]>
Date: Tue, 24 Oct 2000 22:45:52 +0000

> 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

===========

-V

==========

-

---

From: [email-masked]
Date: Wed, 25 Oct 2000 13:14:56 +0000

>on your Telco provider.  If your hunt sequence is first available - a dead nic

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.

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 25 Oct 2000 15:39:41 +0000

>>> 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
>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: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Aaron Nabil <[email-masked]>
Date: Sun, 29 Oct 2000 15:38:45 +0000

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.  

-