Ascend Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) 6.3.1 woes
So here's the deal
We've several Ascend 4004's on PRI's from SouthWestern Bell, and a PM3 on
PRIs from SWB. The first 2 MAXen are on one hunt group, the next 4 PRI's (a
maxen and a 3rd) are on another hunt group, and then the last 2 pri's on the
4th maxen are seperate entities as well. The 2 PRIs on the PM3 are on
another hunt group which is seperate (so we thought) from the rest of it. So
it looks something like the following:
Max1 -> 3 PRIs on 0028
Max2 -> 3 PRIs on 0028 -> flows into 0021
Max3 -> 3 PRIs on 0021
Max4 -> 1 PRI on 0021 -> flows into 0305
-> 1 PRI on 0305 -> flows into 0306
-> 1 PRI on 0306
PM3 -> 2 PRIs on 0200
Now as it turns out, the D channels for each hunt group are seperate, but
the B channels are all in the same trunk group. Max4 had 6.1.3 running,
nothing unsual as of yet, no leaky IP pools or anything of the sort. This
morning I found that we were accepting NO data calls on ANY of these hunts.
After farting around with SWB for a while we rebooted MAX4, suddenly, all
channels started taking data calls again *twilight zone music plays*.
Why would a seemingly seperate box (max4) cause unrelated trunks to stop
taking data calls? Well, here's the thing, it seems 6.1.3 did something,
sent something (we really don't know yet), to the switch which caused it to
believe that _ALL_ b channels across the hunt group (remember, we just
realized that all of our B channels are on the same trunk group), were
blocking data calls. Voice calls worked fine, data did not.
So what exactly did the MAX do to cause this? Anyone got some ideas? I'm at
a complete loss on this one.
--
GigaNews.Com
The Spot for News
http://www.giganews.com
Making UseNet a Global Priority
++ Ascend Users Mailing List ++
To unsubscribe: send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd: <http://www.nealis.net/ascend/faq>