As I explained in my 3 previous posts, we have been getting a problem with
fast busies being issued to customers on a 4 PM3 huntgroup when all ports
are not in use. On one occasion, my telco was able to track the problem
down to the 6th (5th if you start at 0) B channel on my 3rd PRI (1st PRI
in second PM3). Basically, when a call came down that channel, the PM
would refuse the call. No modems are stuck in ADMIN, DOWN or ERROR state.
I had the telco "busy-out" that B channel and the problem went away for a
while.
We had this fast busy problem again last night. I noticed that port S22
was not accepting calls, and rebooted the portmaster. Port S22 still did
not accept any calls. What I didn't realize at the time, was that this was
probably due to the fact that they busied out B channel 5, which I later
learned (see below) was assigned to S22. However, while searaching for the
"req channel not avail" error that "show s22" was listing in it's
"Disconnect" field, I came across an interesting thread from Sept 98. That
thread identified port S22 as being the main culprit in a lot of problems.
Please see http://www.dataman.nl/showport.lp?i=442106&s=pEQhHIGxhGjnX8op .
There are a lot of other random occurrences of disconnect problems in the
portmaster-users archive. I'm suprised that Livingston seemed so unaware
of this when I called.
While working with Livingston, I came across an UNDOCUMENTED command that
may be beneficial to this list. Please note that I know very little about
the various parameters of this command and neither did the tech support
person. The command I used was to show B channel statistics, but there are
many parameters and no-doubt many of them are not meant to be messed with.
Therefore, please use this at YOUR OWN RISK as you might be able to screw
something up if you experiment with other settings.
The PM3 has a DSU framing chip that was made in Munich, Germany. The
command that references this chip is called "munich" :
pm3_1> munich
usage: munich channels
usage: munich intr
usage: munich intrq
usage: munich recv <portname | all>
usage: munich spec
usage: munich stat <portname | all>
usage: munich statd
usage: munich stats [<dev_n>]
usage: munich statt <portname | all>
usage: munich statr <portname | all>
usage: munich timeslots
usage: munich xmit <portname | all>
pm3_1>
There are two parameters that I have been introduced to. They are "munich
stats" and "munich channels". They basically show information about B
channels and which ports are attached to which B channels, as well as
various other receive/transmit stats. I don't recommend messing with
anything else.
Example:
To show channels on Line0:
pm3_2> munich channels 0
ch port dv readq xmitq cur_rd cur_td
0 S6 0 0- 5 0- 0 391c2c 000000
1 S3 0 2- 1 0- 0 39206c 000000
2 S11 0 3- 2 0- 0 39249c 000000
3 S19 0 3- 2 0- 0 3928bc 000000
4 S9 0 2- 1 0- 0 392ccc 000000
5 S22 0 0- 0 0- 0 000000 000000
6 S7 0 4- 3 0- 0 39352c 000000
7 S18 0 3- 2 0- 0 39393c 000000
8 S4 0 1- 0 0- 0 393d3c 000000
9 S16 0 3- 2 0- 0 39417c 000000
10 S1 0 4- 3 0- 0 3945ac 000000
11 S21 0 3- 2 0- 0 3949bc 000000
12 S2 0 5- 4 0- 0 394dfc 000000
13 S20 0 2- 1 0- 0 3951ec 000000
14 S15 0 1- 0 0- 0 3955fc 000000
15 S17 0 1- 0 0- 0 395a1c 000000
16 S10 0 4- 3 0- 0 395e6c 000000
17 S0 0 2- 1 0- 0 39626c 000000
18 S8 0 0- 5 26-27 39666c 3969b0
19 S12 0 2- 1 20-20 396aac 396d7c
20 S5 0 0- 5 0- 0 396eac 000000
21 S13 0 0- 5 0- 0 3972cc 000000
22 S14 0 4- 3 0- 0 39772c 000000
23 D0 0 3- 2 3- 4 397b3c 397d3c
Note that S22, my problem port, has 0's going across the statistical
fields. This is probably because my telco still has it "busied out", so I
haven't seen what a port looks like when it's messing up. Regardless, with
this problem, it is useful to be able to see which B channels are getting
which ports. The "munich stats" command also looks useful for
troubleshooting:
pm3_2> munich stats 0
| Transmit| Receive | td td
prt dv ch cur_rd cur_td |state good| good bad | idle cnt
S6 0 0 391c2c 000000 | Off 0| 0 0 | 0 0
S3 0 1 39206c 000000 | Off 0| 0 0 | 0 0
S11 0 2 39249c 000000 | Off 0| 8 0 | 0 0
S19 0 3 3928bc 000000 | Off 0| 6 0 | 0 0
S9 0 4 392ccc 000000 | Off 0| 3 0 | 0 32
S22 0 5 000000 000000 | Off 0| 0 0 | 0 64
S7 0 6 39352c 000000 | Off 0| 2 0 | 0 0
S18 0 7 39393c 000000 | Off 0| 0 0 | 0 0
S4 0 8 393d3c 000000 | Off 0| 1 0 | 0 0
S16 0 9 39417c 000000 | Off 0| 3 0 | 0 0
S1 0 10 3945ac 000000 | Off 0| 0 0 | 0 0
S21 0 11 3949bc 000000 | Off 0| 0 0 | 0 0
S2 0 12 394dfc 000000 | Off 0| 0 0 | 0 0
S20 0 13 3951ec 000000 | Off 0| 0 0 | 0 32
S15 0 14 3955fc 000000 | Off 0| 0 0 | 0 0
S17 0 15 395a1c 000000 | Off 0| 0 0 | 0 0
S10 0 16 395e6c 000000 | Off 0| 10 0 | 0 0
S0 0 17 39626c 000000 | Off 0| 0 0 | 0 0
S8 0 18 39666c 3969b0 | Off 3b9| 6e 0 | 0 31
S12 0 19 396aac 396d7c | Off 933| 157 20 | 7 32
S5 0 20 396eac 000000 | Off 0| 1 0 | 0 0
S13 0 21 3972cc 000000 | Off 0| 1 0 | 0 0
S14 0 22 39772c 000000 | Off 0| 0 0 | 0 0
D0 0 23 397b4c 397e20 | Act 18d7| 18c4 0 | 0 31
Again, aside from obvious things, I know very little about this command.
Hopefully Lucent will get with the program and document it, as I was told
that up until recently, only engineers knew about this. Again, use this at
your own risk.
-Jason
oooooo o o oo o o--o | J Hatch "You toucha my SPARC, I breaka you face."
oo o o oo oo o--o | System Administrator, B e r k s h i r e N e t
- - - -- - - | email: zone@berkshire.net phone: (413) 442-7805
oo o o oo o o | web: http://www.BERKSHIRE.net/
oooooo o o oo o o--o | Cdomain Web based WHOIS: http://www.CDOMAIN.com
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>