cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
534
Views
0
Helpful
8
Replies

Cisco 801 won't accept incoming

mpwk
Level 1
Level 1

We have a Cisco 801 router with IOS version 12.0(5)T

We use dial on demand. The C801 can connect to a C1603 router. But when this router calls the C801 it fails. We get the following debug output.

When we use for the C1603 a C765 we get exactly the same result. What to do ??

03:43:12886343524: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 96 changed to up

03:43:13693565491: BR0:1 DDR: Caller id 515431540 matched to profile WgoFraneker

03:43:12884901920: BRI0:1: interface must be fifo queue, force fifo

03:43:12884902554: %DIALER-6-BIND: Interface BRI0:1 bound to profile Dialer2

03:43:03: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

03:43:03: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 515431540

03:43:03: isdn_call_connect: Calling lineaction of BRI0:1

03:43:03: BR0:1 PPP: Treating connection as a callin

03:43:03: BR0:1 PPP: Phase is ESTABLISHING, Passive Open

03:43:03: BR0:1 LCP: State is Listen

03:43:05: BR0:1 LCP: TIMEout: State Listen

03:43:05: BR0:1 LCP: O CONFREQ [Listen] id 43 len 15

03:43:05: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:05: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:07: BR0:1 LCP: TIMEout: State REQsent

03:43:07: BR0:1 LCP: O CONFREQ [REQsent] id 44 len 15

03:43:07: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:07: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:09: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 515431540

03:43:09: BR0:1 LCP: TIMEout: State REQsent

03:43:09: BR0:1 LCP: O CONFREQ [REQsent] id 45 len 15

03:43:09: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:09: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:11: BR0:1 LCP: TIMEout: State REQsent

03:43:11: BR0:1 LCP: O CONFREQ [REQsent] id 46 len 15

03:43:11: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:11: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:13: BR0:1 LCP: TIMEout: State REQsent

03:43:13: BR0:1 LCP: O CONFREQ [REQsent] id 47 len 15

03:43:13: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:13: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:15: BR0:1 LCP: TIMEout: State REQsent

03:43:15: BR0:1 LCP: O CONFREQ [REQsent] id 48 len 15

03:43:15: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:15: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:17: BR0:1 LCP: TIMEout: State REQsent

03:43:17: BR0:1 LCP: O CONFREQ [REQsent] id 49 len 15

03:43:17: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:17: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:19: BR0:1 LCP: TIMEout: State REQsent

03:43:19: BR0:1 LCP: O CONFREQ [REQsent] id 50 len 15

03:43:19: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:19: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:21: BR0:1 LCP: TIMEout: State REQsent

03:43:21: BR0:1 LCP: O CONFREQ [REQsent] id 51 len 15

03:43:21: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:21: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:23: BR0:1 LCP: TIMEout: State REQsent

03:43:23: BR0:1 LCP: O CONFREQ [REQsent] id 52 len 15

03:43:23: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:23: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:25: BR0:1 LCP: TIMEout: State REQsent

03:43:25: BR0:1 LCP: O CONFREQ [REQsent] id 53 len 15

03:43:25: BR0:1 LCP: AuthProto CHAP (0x0305C22305)

03:43:25: BR0:1 LCP: MagicNumber 0x314D1C71 (0x0506314D1C71)

03:43:27: BR0:1 LCP: TIMEout: State REQsent

03:43:27: BR0 DDR: has total 2 call(s), dial_out 0, dial_in 0

03:43:27: Calling lineaction of BRI0:1

03:43:27: BR0:1 PPP: Treating connection as a callin

03:43:27: BR0:1 PPP: Phase is ESTABLISHING, Passive Open

03:43:27: %DIALER-6-UNBIND: Interface BRI0:1 unbound from profile Dialer2

03:43:27: BRI0:1 DDR: disconnecting call

03:43:27: BR0:1 LCP: State is Listen

03:43:27: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from 515431540 , call lasted 24 seconds

03:43:115964116992: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down

03:43:115965549821: isdn_call_disconnect: Calling lineaction of BRI0:1

03:43:120259084287: BR0:1 LCP: State is Closed

03:43:115965558628: BR0:1 PPP: Phase is DOWN

03:43:115970166292: BRI0:1 DDR: disconnecting call

8 Replies 8

svermill
Level 4
Level 4

I would maybe take a look at authentication setup to start. You can always 'debug xxx authentication.' Is your 801 set up properly for chap or does it use only pap?

This is actually the output from the debug ppp auth and debug ppp neg. The 801 is setup for chap, but when i set both routers to pap the result is exactly the same.

Sorry, I meant on the other end. I assume this is the 801 output because of the "treating connection as callin" output. I have seen almost the exact same output you posted when trying to set up ppp between a 1720 and an old Dr. Bond router. I can't remember all the details off hand, but I seem to recall an authentication issue. But that lcp "phase is establishing, passive open" looks odd. Think "active open" is what you should normally see. Maybe compare your debug of a good 801 to 1603 negotiation would help.

There is also 'debug ppp error'

I was able to replicate your exact output on my routers in many different ways. Basically, anything that invalidates ppp on the called-to router will produce your output on the calling router. This is a result of not receiving valid LCP response. Even when authentication is misconfigured, you should at least get CONFnaks and/or CONFrejs back from the called-to router. So I guess you might want to focus on PPP and LCP settings before you mess with authentication. Ignore the guy who suggested that.

I haven't found anything usefull to change PPP and LCP settings. Any usefull options I could try ?

The debug option ppp error did not produce new debug info, so it's propably a LCP problem.

I don't have an ISDN simulator in my lab right now but with just a couple of back-to-back routers here in my office I can set up ppp and run some debug. With the calling router interface shut down or configured for HDLC, basically any significant misconfiguration, the called-to router outputs exactly what you have posted. If PPP is just somewhat misconfigured, you at least see the I CONFREJ coming in from the calling router on the called-to router debug. So I would be looking very closely at layer 2 on the calling router. Does it agree that the call is in fact up? Does it think it is outputting O CONFREQ and timing out like the other side or is LCP never kicking in at all because of some other issue (ISDN, dialer setup, etc)?

Essentially, are the 1603 and the 801 in concurrence regarding the state of the call/interface?

The configuration of the 1603 and the 801 are almost identical. Both connect to the internet and to each other. However the 1603 cannot connect to the 803 but the 803 can make a connection to the 1603. Also a 765 cannot connect to the 801. I don't what else I can change in the 801 setup. I can now only test a connection to the 801 with the 765 because I cannot use the 1603 from here. Unfortunately the 765 has not any usefull debug info.

I wish that I could have been more help to you. I would suggest that you open a case with the TAC. For all you know, you could be troubleshooting a known bug that is easily fixed.

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: