Re: ISDN Backup errors using dialer interfaces

wordworship · ‎01-09-2007

Below are the messages I am getting, At the end of teh log you will see where the call suddenly gets dropped.

Jan 9 19:20:31.348: BR1/0:1 LCP: AuthProto CHAP (0x0305C22305)

Jan 9 19:20:31.348: BR1/0:1 LCP: MagicNumber 0x17107D0B (0x050617107D0B)

Jan 9 19:20:31.352: ISDN BR1/0 Q921: User RX <- RR sapi=0 tei=104 nr=81

Jan 9 19:20:31.356: BR1/0:1 PPP: I pkt type 0xC021, datagramsize 19 link[ppp]

Jan 9 19:20:31.356: BR1/0:1 LCP: I CONFREQ [REQsent] id 40 len 15

Jan 9 19:20:31.356: BR1/0:1 LCP: AuthProto CHAP (0x0305C22305)

Jan 9 19:20:31.356: BR1/0:1 LCP: MagicNumber 0x1B9DFF31 (0x05061B9DFF31)

Jan 9 19:20:31.356: BR1/0:1 LCP: O CONFACK [REQsent] id 40 len 15

Jan 9 19:20:31.356: BR1/0:1 LCP: AuthProto CHAP (0x0305C22305)

Jan 9 19:20:31.356: BR1/0:1 LCP: MagicNumber 0x1B9DFF31 (0x05061B9DFF31)

Jan 9 19:20:31.360: BR1/0:1 PPP: I pkt type 0xC021, datagramsize 19 link[ppp]

Jan 9 19:20:31.360: BR1/0:1 LCP: I CONFACK [ACKsent] id 51 len 15

Jan 9 19:20:31.360: BR1/0:1 LCP: AuthProto CHAP (0x0305C22305)

Jan 9 19:20:31.360: BR1/0:1 LCP: MagicNumber 0x17107D0B (0x050617107D0B)

Jan 9 19:20:31.360: BR1/0:1 LCP: State is Open

Jan 9 19:20:31.360: BR1/0:1 PPP: Phase is AUTHENTICATING, by both

Jan 9 19:20:31.360: BR1/0:1 CHAP: O CHALLENGE id 13 len 28 from "LABBRI1"

Jan 9 19:20:31.368: BR1/0:1 PPP: I pkt type 0xC223, datagramsize 31 link[ppp]

Jan 9 19:20:31.368: BR1/0:1 CHAP: I CHALLENGE id 16 len 27 from "LABPRI"

Jan 9 19:20:31.372: BR1/0:1 CHAP: Using hostname from unknown source

Jan 9 19:20:31.372: BR1/0:1 CHAP: Using password from AAA

Jan 9 19:20:31.372: BR1/0:1 CHAP: O RESPONSE id 16 len 28 from "LABBRI1"

Jan 9 19:20:31.384: BR1/0:1 PPP: I pkt type 0xC223, datagramsize 8 link[ppp]

Jan 9 19:20:31.384: BR1/0:1 CHAP: I SUCCESS id 16 len 4

Jan 9 19:20:31.388: BR1/0:1 PPP: I pkt type 0xC223, datagramsize 31 link[ppp]

Jan 9 19:20:31.388: BR1/0:1 CHAP: I RESPONSE id 13 len 27 from "LABPRI"

Jan 9 19:20:31.388: BR1/0:1 PPP: Phase is FORWARDING, Attempting Forward

Jan 9 19:20:31.388: BR1/0:1 PPP: Phase is AUTHENTICATING, Unauthenticated User

Jan 9 19:20:31.388: BR1/0:1 PPP: Sent CHAP LOGIN Request

Jan 9 19:20:31.388: BR1/0:1 PPP: Received LOGIN Response PASS

Jan 9 19:20:31.388: BR1/0:1 PPP: Phase is FORWARDING, Attempting Forward

Jan 9 19:20:31.388: BR1/0:1 PPP: Phase is AUTHENTICATING, Authenticated User

Jan 9 19:20:31.388: BR1/0:1 CHAP: O SUCCESS id 13 len 4

Jan 9 19:20:31.388: BR1/0:1 PPP: Phase is UP

Jan 9 19:20:31.388: BR1/0:1 PPP: Process pending ncp packets

Jan 9 19:20:31.392: ISDN BR1/0 Q921: User TX -> INFO sapi=0 tei=104, ns=81 nr=121

Jan 9 19:20:31.392: ISDN BR1/0 Q931: DISCONNECT pd = 8 callref = 0x2A

Cause i = 0x8090 - Normal call clearing

Jan 9 19:20:31.412: ISDN BR1/0 Q921: User RX <- RR sapi=0 tei=104 nr=82

Jan 9 19:20:31.604: ISDN BR1/0 Q921: User RX <- INFO sapi=0 tei=104, ns=121 nr=82

Jan 9 19:20:31.604: ISDN BR1/0 Q931: RELEASE pd = 8 callref = 0xAA

Jan 9 19:20:31.604: ISDN BR1/0 Q921: User TX -> RR sapi=0 tei=104 nr=122

Jan 9 19:20:31.604: %LINK-3-UPDOWN: Interface BRI1/0:1, changed state to down

Jan 9 19:20:31.604: ISDN BR1/0 Q921: User TX -> INFO sapi=0 tei=104, ns=82 nr=122

Jan 9 19:20:31.604: ISDN BR1/0 Q931: RELEASE_COMP pd = 8 callref = 0x2A

Jan 9 19:20:31.608: BR1/0:1 PPP: Sending Acct Event[Down] id[3C]

Jan 9 19:20:31.608: BR1/0:1 PPP: Phase is TERMINATING

Jan 9 19:20:31.608: BR1/0:1 LCP: State is Closed

Jan 9 19:20:31.608: BR1/0:1 PPP: Phase is DOWN

Jan 9 19:20:31.628: ISDN BR1/0 Q921: User RX <- RR sapi=0 tei=104 nr=83

spremkumar · ‎01-09-2007

Hi

As per the output the call clearing is normal

Cause i = 0x8090 - Normal call clearing you can also enable debug q931 and capture the logs.

Also do mention are you facing any issues with the ISDN connectivity at present ?

regds

Richard Burts · ‎01-10-2007

Boomie

I agree with Edwin that a statement from you about whether there is a problem and if so what the problem is would help us to focus on the right aspect of things.

Edwin - the message that gives the normal call clearing code IS output from debug isdn q931, so obviously it is already turned on.

The logs show normal negotiation of Link Control Protocol (LCP) and successful negotiation of authentication. It shows the beginning of negotiation of Network Control Protocol (NCP) and disconnect. I am assuming that the disconnect originated on the other end and that logs from the other end might help show what caused the disconnect. I might make a guess that there was some problem with the NCP information presented but it would require more information about the environment to be sure of that.

HTH

Rick

HTH

Rick

spremkumar · ‎01-10-2007

Hi Rick

Thanks for pointing me out. :-)

I terribly missed out the starting of the line which indicates q931...

regds

wordworship · ‎01-10-2007

Thanks for the responses.

The description of the setup is below:

Below is the line to an almost an exact setup of what we have except that its the BRI calling into the PRI. We are using Chap authentication. Like you said everything appears to be fine with layer 1 and layer 2, but layer 3 seems to be the problem.

http://cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a0080094b7a.shtml

wordworship · ‎01-10-2007

sorry that was the wrong link:

http://cisco.com/en/US/tech/tk801/tk133/technologies_configuration_example09186a0080093f7e.shtml

Richard Burts · ‎01-10-2007

Boomie

It is interesting to see the link that illustrates something similar to your setup. But it does us little good in understanding what your problem is. If you want us to help you with your issue you will need to provide additional information that shows your environment. It would be helpful to start with the configuration of both routers. Perhaps you could also get debug output from the other router that shows what it is doing during the call.

HTH

Rick

HTH

Rick