ISDN Keepalive issue - bug ?

[wpinberlin]

i have two 1721s with ATM and BRI interfaces. The ATM interfaces connect via PPPoE to a DSL Provider. I am configuring a DDR backup link with my BRI interfaces using dialer profiles. I have been able to configure the dialer interfaces and bring up the link to ping across it - but only in ONE direction! Dialing from Router A to Router B works perfectly - the link comes up and traffic flows across. However when i attempt to bring up the link from Router B the connection fails. Router B dials Router A but Router A's BRI0 interface comes up and the goes down again. doing a 'show isdn status' afterwards shows that the Layer 2 State is stuck in "TEI_ASSIGNED" and remains this way until doing a 'clear interface BRI0'. While the interface is stuck in this state it is not sending any keepalives to the ISDN provider switch. It is receiving them however - is this a bug in the IOS (Version 12.3(7)T - though both are running the same version? or any other ideas?

thanx in advance!

William

[Kevin Dorrell]

Are both of these BRI interfaces connected to the same provider ... or should I say, to the same type of ISND switch? Are the subscription details the same? If they both have the same config (apart from the dialer strings etc.), they should both behave the same. It is behaving as if the ISDN switch type was wrong on Router B.

I presume that Router B starts in state "MULTIPLE_FRAME_ESTABLISHED"? Does it show any CCBs occupied when there shouldn't be, perhaps?

Could you post the configs and any other status info that might be useful?

Kevin Dorrell

Luxembourg

[wpinberlin]

Kevin,

thanx for your ideas. they are both attached to the same type of switch (basic-net3) and have the exact same configurations - except the dialing string. Router B definitely starts in "MULTIPLE_FRAME_ESTABLISHED" and whats more the configuration works perfectly going from Router A to Router B. Router B seems to be acting as expected in both bringing up the link and bringing it back down. How would I check for occupied CCBs?

I have attached the configs.

thanx in advance!

[Kevin Dorrell]

Normally they are listed in the show isdn status

KJD

[wpinberlin]

Kevin,

yes i noticed the field the next time i ran the 'show isdn status' - but they were both showing '0'. I can get Router A back to "MULTIPLE_FRAME_ESTABLISHED" simple by doing a 'clear int bri0' - then all is normal again and i can bring the link up from the Router A end. Am I correct in assuming that the errors are coming from Router A since that is where I am seeing the stuck behaviour?

thanx,

William

[Kevin Dorrell]

I would be 95% sure that is the case. (The 5% is a disclaimer for anything starnge happening ;-) After all, it is the layer-2 that seems to be getting stuck, and that only goes as far as the local exchange. So it is a layer-2 problem between Router A and its local exchange, and Router B probably does not enter into the equation.

Are these sites near each other? Is there any chance of swapping the two routers, just to try?

My best bet would be that tere is something strange about the ISDN subscription at the Router A site.

Kevin Dorrell

Luxembourg

[wpinberlin]

Unfortunately they are not close to each other at all. I can try to get the customer to talk to their ISDN provider but i would like to get all the information that i can. Any suggestions for bebug commands beyond Q921 and show isdn status?

thanx!

William

[Kevin Dorrell]

Not really. I think the Q921 probably has everything you need, except that I'm not too confident about interpreting it.

To recap, the problem happens at Router A when Router A receives an incoming call. How to test this? I suggested ealier that you could try connecting to another ISP, but that was nonsense: that would test outgoing calls and not incoming.

I think the customer needs to talk to their ISDN provider, as you say.

Kevin Dorrell

Luxembourg

[wpinberlin]

Kevin,

in doing a 'debug isdn q931' i can see the cause of the call failure - the telco switch is sending over a RELEASE message indicating that it is seeing an "Invalid call reference value". This would explain why the call doesn't go through, however when i call in the other direction all the call reference values are exactly the same and the telco switch has no problem with it. (and of course this doesn't explain the strange behaviour of the interface after the failure...but first things first!)

[wpinberlin]

Kevin,

yes i found them immediately. there seems to be no unusual behaviour. when idle both routers show 'Total Allocated ISDN CCBs = 0'. When a successful link is created (initiated from Router A) they both show 'Total Allocated ISDN CCBs = 1'. When the link is cleared they return to zero. When an unsuccesful attempt is made to bring the link up (initiated by Router B) they remain at zero.

~William

[wpinberlin]

just to conclude... this ended up being a telco issue. the customer was contacted, they contacted the telco - who made obscure changes to the isdn swith and Viola!

it works! no change in either my configs or my test methodology. who do those carriers have working for them?