[c-nsp] RE: [cisco-nas] Problem with ISDN backup (stuck CCBs in 12.3(11)T?)

[piestaga]

Hi,

First of all thanks for the answers :-)

I actually did that. I debug almost all parameters of the connection that
should be useful during troubleshooting of ISDN calls (well, except debug
isdn q921).
I have not found anything "special" what could cause such a behaviour.

But I decided to take a closer look at the rest of configuration (which
primary I though as not important).

And probably (I am still not quite sure) it was a good shoot.

Few words of explanation:

Backup ISDN Dialer should dial out to LAC (where pre authentication takes
place) and after correct authentication the LAC should establish the L2TP
tunnel to LNS and put ISDN PPP into it.
LNS should finally terminate the PPP and assign the call to the relevant
VRF.

There is something wrong with LAC config, because L2TP tunnel is always
disconnected somewhere in the middle of establishing process.
I still don't know what is wrong, but I suspect that this misconfiguration
causes the ISDN dialer to dial out again and again.

Show dialer command displayed about 300 call attempts to LAC during few
minutes of observation.

I still do not know why there are problems with this "stuck CCBs" and I
still  can not clear that entries (neither clear interface BRI 0/0 nor clear
dialer sessions helps in that. Only router reset clear that state) but
untill I correct the whole call scenario, the detailed debug of ISDN does
not make sens.

I suspect, that the wrong (or incomplete) config of the rest of environment
put the ISDN interface into that "hung" state.

Well, I believe I am not wrong :-)

Regards
Piestaga





At 08:51 AM 11/8/2004 -0600, Josh Duffek wrote:

> > Global ISDN Switchtype = basic-net3
> > ISDN BRI0/0 interface
> >         dsl 0, interface ISDN Switchtype = basic-net3
> >     Layer 1 Status:
> >         ACTIVE
> >     Layer 2 Status:
> >         Layer 2 NOT Activated
> >     Layer 3 Status:
> >         0 Active Layer 3 Call(s)
> >         CCB:callid=8097, sapi=0, ces=1, B-chan=1, calltype=DATA,
> > hdlctype=HDLC-TRUNK
> >         CCB:callid=8098, sapi=0, ces=1, B-chan=2, calltype=DATA,
> > hdlctype=HDLC-TRUNK
> >     Active dsl 0 CCBs = 2
> >     The Free Channel Mask:  0x80000000
> >     Total Allocated ISDN CCBs = 2

This is your problem; the question is what's causing it.  As Josh says,
the CCB's are hung (either the initial calls were not cleared correctly,
or they were but we still didn't clean up after ourselves).

VRF Dialer-Watch support was added in 12.3(7)T, but I'm not sure this
new functionality would cause this problem.  It's more likely DW/ISDN
related.

I don't see any bugs that seem relevant.  If possible, I would suggest
you reproduce the problem, doing the following:

debug dialer
debug isdn q931
debug isdn code (hidden)
debug isdn event
sh isdn stat
primary(s) down, dialer up
primary(s) up, dialer down
sh isdn stat
und all

Thanks,

mark