cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1265
Views
4
Helpful
19
Replies

ISDN problem. CHAP success but then immediate disconnect.

mattbauer
Level 1
Level 1

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 192.168.0.0 255.255.255.0 Dialer1

dialer-list 1 protocol ip permit

Any ideas?

Thanks

Matt

19 Replies 19

Richard Burts
Hall of Fame
Hall of Fame

Matt

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.

HTH

Rick

HTH

Rick

smothuku
Level 7
Level 7

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 :)

satish

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:

ACTIVE

Layer 2 Status:

TEI = 67, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

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.

Thanks

Matt

hi,

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

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

regards,

shri :)

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).

HI,

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.

regards,

shri

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 :)

Hi,

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 !!!

reagrds,

shri.

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]

Thanks,

Satish

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.

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.

http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a00800b4130.shtml

Thanks,

Satish

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

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?

Hi,

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.

Regards,

Dandy

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: