ISDN problem. CHAP success but then immediate disconnect.

Unanswered Question
Dec 26th, 2007
User Badges:

Hi all

It's been a long time since Ive used ISDN and Im wondering if there is something basic that Ive overlooked.

Below is some debug output of the disconnection problem:

BR0/0/0:1 LCP: State is Open

BR0/0/0:1 PPP: Phase is AUTHENTICATING, by both

BR0/0/0:1 CHAP: O CHALLENGE id 32 len 34 from "local-router"

BR0/0/0:1 PPP: I pkt type 0xC223, datagramsize 33 link[ppp]

BR0/0/0:1 CHAP: I CHALLENGE id 203 len 29 from "remote-router"

BR0/0/0:1 CHAP: Using hostname from interface CHAP

BR0/0/0:1 CHAP: Using password from interface CHAP

BR0/0/0:1 CHAP: O RESPONSE id 203 len 34 from "local-router"

BR0/0/0:1 PPP: I pkt type 0xC223, datagramsize 8 link[ppp]

BR0/0/0:1 CHAP: I SUCCESS id 203 len 4

BR0/0/0:1 PPP: I pkt type 0xC021, datagramsize 8 link[ppp]

BR0/0/0:1 LCP: I TERMREQ [Open] id 91 len 4

BR0/0/0:1 LCP: O TERMACK [Open] id 91 len 4

BR0/0/0:1 PPP: Sending Acct Event[Down] id[4873]

BR0/0/0:1 PPP: Phase is TERMINATING

So it seems that authentication is ok, but then (I guess) I recieve a termination request (I TERMREQ) which I respond to (O TERMACK) thus closing the connection.

The question is, why do I recieve this termination request?

Unfortunately asking the remote end is not giving me any clues. They are a government department and will not give me any information other than "This is a standard config at our end that has been working with others for 5 years". They will not give me a recommended config or even look at logs etc. So before I go back to them again, I want make sure that there's nothing missing from my end.

Here's my config:

interface BRI0/0/0

bandwidth 64

no ip address

ip accounting output-packets

encapsulation ppp

dialer pool-member 1

isdn switch-type ntt

peer default ip address dhcp

no keepalive


interface Dialer1

bandwidth 64

ip address dhcp

encapsulation ppp

dialer pool 1

dialer idle-timeout 600

dialer string 12345678

dialer-group 1

peer default ip address dhcp

no keepalive

ppp authentication chap

ppp chap hostname hostname

ppp chap password password

ip route Dialer1

dialer-list 1 protocol ip permit

Any ideas?



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Richard Burts Wed, 12/26/2007 - 20:13
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN


I do not see any particular issue in what you have posted. I would suggest running debug isdn q931 and debug ppp negotiation and testing again. Perhaps the additional debugs will shed some light on the problem.



smothuku Wed, 12/26/2007 - 21:08
User Badges:
  • Silver, 250 points or more

Hi Matt ,

"isdn switch-type" is ntt at your end .Plz make sure that same switch type could be present at other end.

As suggested by Rick , please paste the debug isdn q931 output.If possible show isdn histroy and sh isdn status outputs also to verify whether the call is connecting or not.

If possible provide us the config of both the routers.

Cheers :)


mattbauer Wed, 12/26/2007 - 22:04
User Badges:

Rick, satish

Thanks for the replys. The snippets of debug (where I thought the problem was) at the top of my post included ppp neg, ppp auth and isdn q931. But Ive attached the full debug output to this post.

Here's a "show isdn status":

Global ISDN Switchtype = ntt

ISDN BRI0/0/0 interface

dsl 0, interface ISDN Switchtype = ntt

Layer 1 Status:


Layer 2 Status:


Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask: 0x80000003

Total Allocated ISDN CCBs = 0

"show isdn history" isnt very interesting, but Ive attached it anyway.

satish, unfortunately I cant get access to the remote router or even see the config (please see my first post). I realise there may be something wrong on that side, but I want to make sure Ive got everything covered on my end . But I do know that switch-type is NTT on both ends.



shrikar.dange Wed, 12/26/2007 - 22:35
User Badges:
  • Bronze, 100 points or more


can you check the dialer idle time-out under the bri interface?

I think it can be set to a very low value.


shri :)

mattbauer Wed, 12/26/2007 - 22:38
User Badges:

Ive got the dialer idle-timeout set on the Dialer1 interface and it's set to 600. Even if it was set very low, I dont think that's the issue. The disconnect always happens immediately after CHAP success (within a fraction of a second).

shrikar.dange Wed, 12/26/2007 - 23:00
User Badges:
  • Bronze, 100 points or more


as per your isdn debug attachement is shows that you are "recievig" the TREMREQ for link termination.

And in my knowledge LCP Link Termination

happens when the link is ready to be shut down, LCP terminates it. The device initiating the shutdown (which may not be the one that initiated the link in the first place) sends a Terminate-Request message. The other device replies back with a Terminate-Ack. A termination request indicates that the device sending it needs to close the link. And ,this is a request that cannot be denied.

So in my view the problem is at other end router.



mattbauer Wed, 12/26/2007 - 23:05
User Badges:

shri, I dont know much about LCP, but that's exactly what I thought also.

Unfortunately I've yet to convice the other end.

But it's good to hear someone backing up my story :)

shrikar.dange Wed, 12/26/2007 - 23:12
User Badges:
  • Bronze, 100 points or more


I dont think there is any problem with your config. The switch type is also seems okay.If that was the problem then the link will not etablish in the first place and you will get the error notification msges.In the sh isdn status output also shows that the layer 2 is UP multilink estblshd. This means that the switch type is okay.

Well i dont think any config error at your side.

Best of luk !!!



smothuku Wed, 12/26/2007 - 23:45
User Badges:
  • Silver, 250 points or more

Hi Matt ,

from the output of dubug we can observe that "%ISDN-6-DISCONNECT: Interface BRI0/0/0:1 disconnected from 12345678 remote-router, call lasted 1 seconds "

Means call is connecting for 1 secon...

Possiblility is authentication mismatch on one end.

Please check the usernam xxxx password xxx configured on both the ends once again.

and add the following commands on your router and check the issue .

int bri0

ppp authentication chap

ppp chap hostname xxxx

encapsulation ppp

ppp chap password XXXX.

int di1

dialer remote-name XXXX(other router username)

*******Another test you can do is place test isdn call and check whether isdn is connecting with the help of sh isdn statius command..

To make an ISDN data call, use the isdn call interface command in privileged EXEC mode.

isdn call interface interface-number dialing-string [speed 56 | 64]



mattbauer Thu, 12/27/2007 - 00:02
User Badges:

Satish, I didnt think it was a username/password issue because you can also see this output in the debug:

"CHAP: I SUCCESS id 6 len 4"

But yes, I have double/tripe/quadruple/etc checked the username/password. It is correct.

And yes Ive added your new config and Ive also used that isdn call command (it's "isdn test call..." for me). Same results unfortunately.

I just noticed this in my logs:

"*Dec 27 07:56:44.095: BR0/0/0:1 CHAP: O RESPONSE id 11 len 34 from "local-router"

*Dec 27 07:56:44.151: BR0/0/0:1 CHAP: I FAILURE id 11 len 78 msg is "Authentication failure code=20 detail=Pool-address has already been useMJ"

*Dec 27 07:56:44.155: BR0/0/0:1 LCP: I TERMREQ [Open] id 30 len 4

*Dec 27 07:56:44.155: BR0/0/0:1 LCP: O TERMACK [Open] id 30 len 4"

This new "Pool-address" error message only seems to pop up after numerous dial attempts. Therefore Im guessing that it's a red-herring. It's probably giving that error because it's re-dialing so quickly after the last call attempt.

smothuku Thu, 12/27/2007 - 00:13
User Badges:
  • Silver, 250 points or more

Hi Matt ,

I think u have confident about the authentication configured on both ends.

Then try this to check how the authentication is working ...

****Enable "debug ppp negotiation" and "debug ppp authentication".

Please find the enclosed url which can help you for trouble shooting isdn.



mattbauer Thu, 12/27/2007 - 00:16
User Badges:

Those debugs were already enabled. The output was in the attachment that you looked at.

shrikar.dange Thu, 12/27/2007 - 03:55
User Badges:
  • Bronze, 100 points or more

Hi matt,

The only thing which comes in to my mind is the DHCP config.

Are sure about the DHCP bindings and everything else is in its place?

Danilo Dy Thu, 12/27/2007 - 04:20
User Badges:
  • Blue, 1500 points or more


Accroding to these lines...

*Dec 27 05:47:49.210: ISDN BR0/0/0 Q931: RX <- DISCONNECT pd = 8 callref = 0x8B

Cause i = 0x8090 - Normal call clearing

Locking Shift to Codeset 6

Codeset 6 IE 0x1 i = 0x82, '10'

The termination is initiated by the local router. The code for "Normal call clearing" suggest a higher protocol problem. The most common cause is "authentication".

Please turn ON "debug ppp negotiation" and "debug ppp authentication" and give is the log again.



mattbauer Thu, 12/27/2007 - 04:37
User Badges:

guys, deb ppp neg and deb ppp auth *were* on. The text document I attached earlier called isdn-debug.txt has all of those debugs on. Furthermore, it says: "CHAP: I SUCCESS id 255 len 4" which presumably means CHAP authentication was successful.

Re: DHCP, Ive been told by the other end that I will definately be getting my IP address via DHCP. It's their standard config.

paolo bevilacqua Thu, 12/27/2007 - 05:08
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member


Actually "RX <- DISCONNECT" means the local router has received a disconnect request, consequently the termination is by the remote router, not the local one. This is also confirmed by:

BR0/0/0:1 LCP: I TERMREQ [Open] id 91 len 4

I guess they are asking for the debugs taken on the remote router.

dphills18 Thu, 12/27/2007 - 14:56
User Badges:

i had this very issue not too long ago. i goofed up and had the wrong network set on my concentrator. verify the network and wildcard mask on your concentrator.

hope that helps.

mattbauer Thu, 12/27/2007 - 15:02
User Badges:

ok, so I think it quite clear that my end config looks pretty tight and, as suspected, the remote router is initiating the disconnect for reasons unknown.

So until I can squeeze more information out of the other side, Im stuck.

Ill post an update if/when I find a solution.

Thanks for the information so far everyone.


paolo bevilacqua Thu, 12/27/2007 - 15:26
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member


I guess your router is calling, right ?

So please try "ppp authentication chap callin", or remove "ppp authentication" altogether.

Also please re-enable keepalives that is normal operation.


This Discussion