Sorry this message got so long! I suscribe to the digest so CC: me if
you want me to read it before tomorrow :).
> On Tue, 15 Oct 1996, Jon Lewis wrote:
> > Command> sh isdn
> > D Ports State Change Start Up Down Time Sess In Out Err
> > -- ------- --------- ------ ----- ----- ----- ----- ------ ------- ------- ----
> > 0 S0/S1 Initial 0 2029 26 684 342 205 315294 320099 9
> > 1 S2/S3 Active 7:45 181 16 76 38 23 307334 307303 6
> > 2 S4/S5 Active 1:09 4707 24 44 22 5861 361463 355400 113
> > 3 S6/S7 Initial 0 13244 20 302 151 408 353229 353604 110
If you remember, I corresponded privately with you a bit on this when ours
was doing it. I also worked with John @ Livingston on a trouble ticket.
Since then, both the telco and I have changed out absolutely
everything. All that we could tell was that it was *probably* due to
excessive low level errors on the line (I had one doing the excessive
"Start" thing). Ours only got better when the entire telco circuit was
replaced onto thicker gauge copper and the linecard at the telco was
replaced.
1. have them come out and measure your DB loss on the circuit. If
it is anywhere near the threshold, see if they can improve
it (usually by cutting out bridge taps or moving the
circuit onto thicker gauge copper). I *think* the DB
figure they used here for a threshold was around -30 DB.
2. have them replace the line card at the switch - we just had a
BRI installed that sync'd up but the lineman's box showed
continuous flashing error LEDs. He could talk on it but
data showed huge error rates. The line card was the
problem. (Again - it WOULD sync up - deceptively the
PM didn't show any evidence of a problem).
3. I upgraded the memory on the PM to 4M, but have since returned
to 1M - that didn't affect the problem at all.
Summary: The excessive restarts are due to errors on the copper - a
telco issue. It is a very difficult one to find, however. We fooled
with this all summer, literally.
One last PM note, however:
Eventually, after many thousands of errors, it seemed that the Portmaster
then had a problem regaining sync AT ALL and would get stuck in Initial
state (probably where your's above are at). After that point, any
other channel that lost sync for whatever reason, was then hosed. We
would eventually lose even good lines in this fashion (try pulling the
connector/jumpers on a working line and I'll bet they won't re-sync).
In that situation, a reboot of the PM would regain sync for all the
channels. So there is a likely PM bug in the very extreme case
caused by massive errors on the line. The fundamental problem is
at the telco, however, it eventually will cause a PM malfunction.
We haven't seen this situation occur since the error/re-start
business has improved (when telco changed to better copper).
NOTE: This PM bug paragraph is my own opinion and there is very little
proof one way or another. However, there is no other explanation as
to why the PM reboot would clear the problem and all lines would resync.
Also - don't forget about your copper from your junction box to the PM -
try distinct, quality cables instead of the 5-in-1 and other things
(I'm not saying the 5-in-1 cable isn't quality - just that separate
cables will rule out cross-talk, loss, etc in that cable :).
> > Will an upgrade to 3.3.3 likely do anything for this problem? I've not
> > yet tried rebooting the portmaster...in case Livingston wants to get into
> > it and mess with it.
>
> I'm not sure an upgrade to 3.3.3 will help.
>
> What would also be useful is some trend information, like a 'show isdn'
> every hour or half hour.
>
> JGT
> - --
> John G. Thompson Livingston Enterprises Inc. Phone: (800) 458-9966
I didn't try 3.3.3, but did try an unpublished beta prior to 3.3.3's
release and it really didn't help.
I wrote a quick script that used "pmwho" to do the "sh isdn" and log
the output and the date to a file from cron. It's quick and dirty, but let
me know if you want it.
Later!
Derric
-- Derric Scott Scott Network Services, Inc. P. O. Box 361353 derric@scott.net (205)987-5889 Birmingham, AL 35236