I've spent too much time debugging this type of problem.
In our case, it was due to what our telco (Ameritech) is calling
"routine exercise" on the line. At some regular period of time,
they will remove the BRI from service, do some quick tests, and
put it back into service. They *generally* don't do this if there
is a call on the line.
The way that we notice that this is the problem is as follows:
1. Check for the ISDN "heartbeat".
$ aa04> set console
$ Setting CONSOLE to admin session
$ aa04> set debug isdn-d
$ Enabling ISDN frame debugging
$ D10: recv 02 91 01 33
$ D10: send 02 91 01 6f
$ D11: send 00 e1 01 eb
$ D11: recv 00 e1 01 07
$ aa04> reset console
$ Console RESET
$ aa04> set debug isdn-d off
$ Disabling ISDN frame debugging
$ aa04>
We see that there is traffic on D10 and D11 (our two D channels on
this box). If there is a problem, no traffic is seen on one of the
channels.
2. Check to see what the last event was on the line:
You need to "set debug 0x54" and do a "show sX" where X is the
session associated with an ISDN line. We normally see a
"No Event Identified" when the line got "exercised".
So, specifically, if you see this type of thing, you can usually call
your telco/PTT and ask them to remove routine exercise from the line.
Livingston *is* working on a fix for this. A certain tech over there
needs a big box of chocolate chip cookies for helping me out with this
matter.
Please note that your problem and this problem may not be in the least
bit related!
Final relevant fact - we see this problem only on 5ess switches.
DMS100's aren't giving us this problem.
If anyone would like any further info, please e-mail me directly.
I'm about 20M behind on PM-Users.
-- Jeffrey Haas -+- jmh@msen.com -+- http://www.msen.com/~jmh /\/\sen, Inc. "Michigan's Best Run Internet Service Provider."