12-26-2007 05:57 PM - edited 03-03-2019 08:03 PM
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
12-26-2007 08:13 PM
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
12-26-2007 09:08 PM
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
12-26-2007 10:04 PM
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
12-26-2007 10:35 PM
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 :)
12-26-2007 10:38 PM
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).
12-26-2007 11:00 PM
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
12-26-2007 11:05 PM
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 :)
12-26-2007 11:12 PM
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.
12-26-2007 11:45 PM
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
12-27-2007 12:02 AM
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.
12-27-2007 12:13 AM
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
12-27-2007 12:16 AM
Those debugs were already enabled. The output was in the attachment that you looked at.
12-27-2007 03:55 AM
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?
12-27-2007 04:20 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide