Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

No IPCP negotiation

I have a 3725 with a PRI card and MICA modems acting as a sort of access server for regional offices that primarily use dial as a backup interface. I've gotten this working for several regional offices without a major problem, yet one which I tried to bring up recently using the same dialer config doesn't seem to get through the IPCP negotiation. Here's the 3725's debug output:

Aug 22 16:46:42.255 EDT: Modem 2/2 Mica: configured for Answer mode, with Null s

ignaling, 0x0 tone detection.

Aug 22 16:46:42.255 EDT: %ISDN-6-CONNECT: Interface Serial1/0:0 is now connected

to nnnnnnnnnn N/A

Aug 22 16:46:42.383 EDT: Modem 2/2 Mica: in modem state CALL_SETUP

Aug 22 16:46:42.391 EDT: Modem 2/2 Mica: in modem state CONNECT

Aug 22 16:46:42.403 EDT: Modem 2/2 Mica: in modem state V8BIS_EXCHANGE

Aug 22 16:46:46.879 EDT: Modem 2/2 Mica: in modem state LINK

Aug 22 16:46:50.291 EDT: Modem 2/2 Mica: in modem state RANGING

Aug 22 16:46:55.208 EDT: Modem 2/2 Mica: in modem state HALF_DUPLEX_TRAIN

Aug 22 16:46:56.168 EDT: Modem 2/2 Mica: in modem state TRAINUP

Aug 22 16:46:58.248 EDT: Modem 2/2 Mica: in modem state EC_NEGOTIATING

Aug 22 16:46:59.476 EDT: Modem 2/2 Mica: in modem state STEADY

Aug 22 16:46:59.476 EDT: Modem 2/2 Mica: received ConnectInfo

Aug 22 16:46:59.492 EDT: Modem 2/2 Mica: CONNECT at 31200/28800 (Tx/Rx), V34+, L

APM, V42bis

Aug 22 16:46:59.836 EDT: TTY67: DSR came up

Aug 22 16:46:59.836 EDT: tty67: Modem: IDLE->(unknown)

Aug 22 16:47:01.836 EDT: %LINK-3-UPDOWN: Interface Async67, changed state to up

Aug 22 16:47:01.836 EDT: As67 PPP: Using modem call direction

Aug 22 16:47:01.836 EDT: As67 PPP: Treating connection as a callin

Aug 22 16:47:01.836 EDT: As67 PPP: Session handle[7A000191] Session id[168]

Aug 22 16:47:01.836 EDT: As67 PPP: Phase is ESTABLISHING, Passive Open

Aug 22 16:47:01.836 EDT: As67 LCP: State is Listen

Aug 22 16:47:03.848 EDT: As67 LCP: TIMEout: State Listen

Aug 22 16:47:03.848 EDT: Modem 2/2 Mica: PPP escape_map: Tx map = FFFFFFFF, Rx m

ap = 0

Aug 22 16:47:03.848 EDT: As67 PPP: Authorization NOT required

Aug 22 16:47:03.848 EDT: As67 LCP: O CONFREQ [Listen] id 41 len 41

Aug 22 16:47:03.848 EDT: As67 LCP: ACCM 0x000A0000 (0x0206000A0000)

Aug 22 16:47:03.848 EDT: As67 LCP: AuthProto CHAP (0x0305C22305)

Aug 22 16:47:03.848 EDT: As67 LCP: MagicNumber 0x9B586741 (0x05069B586741)

Aug 22 16:47:03.848 EDT: As67 LCP: PFC (0x0702)

Aug 22 16:47:03.848 EDT: As67 LCP: ACFC (0x0802)

Aug 22 16:47:03.848 EDT: As67 LCP: MRRU 1524 (0x110405F4)

Aug 22 16:47:03.848 EDT: As67 LCP: EndpointDisc 1 [hostname] (0x130C0141495053

4F5F505249)

Aug 22 16:47:05.864 EDT: As67 LCP: TIMEout: State REQsent

Aug 22 16:47:05.864 EDT: As67 LCP: O CONFREQ [REQsent] id 42 len 41

Aug 22 16:47:05.864 EDT: As67 LCP: ACCM 0x000A0000 (0x0206000A0000)

Aug 22 16:47:05.864 EDT: As67 LCP: AuthProto CHAP (0x0305C22305)

Aug 22 16:47:05.864 EDT: As67 LCP: MagicNumber 0x9B586741 (0x05069B586741)

[snip]

Aug 22 16:47:05.864 EDT: As67 LCP: EndpointDisc 1 [hostname] (0x130C0141495053

4F5F505249)

... [same "REQsent" sequence repeats 7 times] ....

Aug 22 16:47:21.801 EDT: Modem 2/2 Mica: in modem state TERMINATING

Aug 22 16:47:21.801 EDT: Modem 2/2 Mica: received TerminateInfo

Aug 22 16:47:21.865 EDT: Modem 2/2 Mica: in modem state IDLE

Aug 22 16:47:21.897 EDT: Modem 2/2 Mica: DISCONNECT after 00:00:40, due to reaso

n (0x8220) EC rcvd DISC frame.

Aug 22 16:47:21.897 EDT: TTY67: DSR was dropped

Aug 22 16:47:21.897 EDT: tty67: Modem: READY->HANGUP

Aug 22 16:47:21.897 EDT: TTY67: dropping DTR, hanging up

Aug 22 16:47:21.897 EDT: TTY67: Async Int reset: Dropping DTR

Aug 22 16:47:21.897 EDT: tty67: Modem: HANGUP->IDLE

Aug 22 16:47:21.905 EDT: %ISDN-6-DISCONNECT: Interface Serial1/0:0 disconnected

from nnnnnnnnnn , call lasted 39 seconds

Thinking this may have had something to do with PPP/CHAP, I turned all that off on both ends, but still no dice.

I am stumped now.

1 ACCEPTED SOLUTION

Accepted Solutions

Re: No IPCP negotiation

ok. Looks like speed mismatch may very well be the culprit.

Can you follow the directions listed in the following URL to troubleshoot this issue.

http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a0080143175.shtml#modemcannotsendorreceivedata

HTH,

Sundar

15 REPLIES

Re: No IPCP negotiation

Hi,

Looking at the debugs it doesn't look like an authentication failure. The debugs do not get past the LCP stage. The problem I see is this router sending LCP messages as indicated by 'LCP: O CONFREQ' but there's not a single incoming packet in the debug capture. It appears like a physical layer issue or a problem with the configuration on the remote router.

Hope that helps!

Regards,

Sundar

New Member

Re: No IPCP negotiation

Thanks for taking the time to reply, Sundar.

I can see that there's nothing incoming. I do not suspect physical layer problems at this end, since other offices can connect on the same PRI. I also wonder how this could be physical layer if the modems actually connect and negotiate, as you can see from the debug.

The relevant portions of the remote router config are below. They were copied verbatim from a known working config in another regional office.

multilink virtual-template 1

!

interface Serial0/0.100 point-to-point

description

backup delay 5 5

backup interface Dialer1

ip address nnn.nnn.nnn.nnn

frame-relay interface-dlci 100 IETF

!

interface Serial0/1

physical-layer async

no ip address

encapsulation ppp

dialer in-band

dialer rotary-group 1

dialer-group 1

async default routing

async mode dedicated

!

interface Serial0/2

physical-layer async

no ip address

encapsulation ppp

dialer in-band

dialer rotary-group 1

dialer-group 1

async default routing

async mode dedicated

!

interface Virtual-Template1

ip address negotiated

ppp multilink

!

interface Dialer1

ip address negotiated

ip access-group 102 out

encapsulation ppp

no ip mroute-cache

dialer in-band

dialer idle-timeout 300

dialer string nnnnnnnnnn

dialer hold-queue 15

dialer load-threshold 90 outbound

dialer-group 1

ppp multilink

!

ip classless

ip route 0.0.0.0 0.0.0.0 Serial0/0.100 nnn.nnn.nnn.nnn

ip route 0.0.0.0 0.0.0.0 Dialer1 240

!

line 2 3

modem InOut

modem autoconfigure type usr_sportster

transport input all

stopbits 1

speed 115200

flowcontrol hardware

Hall of Fame Super Silver

Re: No IPCP negotiation

George

I see in the config that the remote router has Frame Relay as its primary link and configures backup interface to Dialer1. This means that unless the Frame Relay is down the Dialer1 will not work. And the Dialer1 is what has the information about how to initiate the call. Can you tell us how the test was initiated?

Also I note that the remote configures dialer-group on the async lines and the Dialer1 as it should, but I do not see any dialer-list. Is it there and if so what does it contain?

HTH

Rick

New Member

Re: No IPCP negotiation

Thanks for taking the time to reply, Richard.

The test was initiated by powering off the external CSU/DSU to simulate frame-relay failure.

The dialer-list and access-list are boring, which was why I didn't include them. We like to start off with as little as possible to get a working config, then restrict traffic as necessary. But since you ask:

access-list 102 deny udp any any eq rip

access-list 102 permit icmp any any

access-list 102 permit ip any any time-range normal-biz

dialer-list 1 protocol ip list 102

Hall of Fame Super Silver

Re: No IPCP negotiation

George

Thanks for verifying that the test was initiated by actually failing the Frame Relay. That is the best way to test the backup.

I am not seeing a problem in the config that you posted from the remote. Is it possible to get debug output from the remote when it attempts to initiate the call?

HTH

Rick

New Member

Re: No IPCP negotiation

Rick, thanks for following up.

Getting debug output from the remote will be difficult. It's a small remote office with no IT staff or expertise, and no syslogging capability. I had the test last week because I had a guy there for other reasons, but now we're not due back for some time. Plus, shutting down the frame is disruptive, so we have to do this at off-peak hours.

Hall of Fame Super Silver

Re: No IPCP negotiation

George

I understand and sympathesize about the difficulty in testing if the router is remote. I have two suggestions that may help work this out.

1) you could test with the Frame Relay up (so it will not be disruptive) by temporarily removing the backup interface commands. I would suggest this:

- telnet to the remote router.

- do terminal monitor or configure logging to the buffer for debug.

- start debugging for the dialing activity.

- remove the backup interface command from the Frame Relay inteface.

- configure a static route for some destination or subnet pointing at the dialer interface.

- ping an address in the static route that you just configured.

- the existing default static route will continue to send most traffic over the Frame Relay. The ping should be sent to the dialer interface and should bring it up.

- capture the debug output.

- remove the extra static route.

- replace the backup interface command on the Frame Relay interface.

- turn off debuging.

OR

2) you could test by configuring another dialer interface which is not controlled by backup interface.

- telnet to the remote router.

- do terminal monitor or configure logging to the buffer for debug.

- start debugging for the dialing activity.

- configure interface dialer2 similar to what is configured for dialer1.

- configure a static route for some destination or subnet pointing at the new dialer interface.

- ping an address in the static route that you just configured.

- the existing default static route will continue to send most traffic over the Frame Relay. The ping should be sent to the new dialer interface and should bring it up.

- capture the debug output.

- remove the extra static route.

- remove the extra dialer interface.

- turn off debuging.

I think that either of these might work for you and provide helpful information.

HTH

Rick

New Member

Re: No IPCP negotiation

Rick:

Thanks for your very detailed instructions. I captured a dialing event from the remote this morning. Here's the debug:

Aug 28 10:36:26.580 EDT: CHAT2: Attempting async line dialer script

Aug 28 10:36:26.584 EDT: CHAT2: process started

Aug 28 10:36:26.584 EDT: CHAT2: Asserting DTR.....

Aug 28 10:36:49.937 EDT: TTY2: no timer type 1 to destroy

Aug 28 10:36:49.937 EDT: TTY2: no timer type 0 to destroy

Aug 28 10:36:51.937 EDT: %LINK-3-UPDOWN: Interface Serial0/1, changed state to up

Aug 28 10:36:51.937 EDT: Se0/1 PPP: Treating connection as a callout

Aug 28 10:36:51.937 EDT: Se0/1 PPP: Phase is ESTABLISHING, Active Open [0 sess,0 load]

Aug 28 10:36:51.937 EDT: Se0/1 PPP: No remote authentication for call-out

Aug 28 10:36:51.937 EDT: Se0/1 LCP: O CONFREQ [Closed] id 4 len 36

Aug 28 10:36:51.941 EDT: Se0/1 LCP: ACCM 0x000A0000 (0x0206000A0000)

Aug 28 10:36:51.941 EDT: Se0/1 LCP: MagicNumber 0xA85CA1CC (0x0506A85CA1CC)

Aug 28 10:36:51.941 EDT: Se0/1 LCP: PFC (0x0702)

Aug 28 10:36:51.941 EDT: Se0/1 LCP: ACFC (0x0802)

Aug 28 10:36:51.941 EDT: Se0/1 LCP: MRRU 1524 (0x110405F4)

Aug 28 10:36:51.941 EDT: Se0/1 LCP: EndpointDisc 1 [hostname] (0x130C015641504149505F5231)

Aug 28 10:36:53.937 EDT: Se0/1 LCP: TIMEout: State REQsent

Aug 28 10:36:53.937 EDT: Se0/1 LCP: O CONFREQ [REQsent] id 5 len 36

Aug 28 10:36:53.937 EDT: Se0/1 LCP: ACCM 0x000A0000 (0x0206000A0000)

Aug 28 10:36:53.937 EDT: Se0/1 LCP: MagicNumber 0xA85CA1CC (0x0506A85CA1CC)

Aug 28 10:36:53.937 EDT: Se0/1 LCP: PFC (0x0702)

Aug 28 10:36:53.937 EDT: Se0/1 LCP: ACFC (0x0802)

Aug 28 10:36:53.937 EDT: Se0/1 LCP: MRRU 1524 (0x110405F4)

Aug 28 10:36:53.941 EDT: Se0/1 LCP: EndpointDisc 1 [hostname] (0x130C015641504149505F5231)

Aug 28 10:36:55.937 EDT: Se0/1 LCP: TIMEout: State REQsent

[REQsent sequence repeats 8 times]

Aug 28 10:37:11.938 EDT: TTY2: Async Int reset: Dropping DTR

Aug 28 10:37:11.938 EDT: Se0/1 LCP: State is Listen

Aug 28 10:37:12.606 EDT: TTY2: DSR was dropped

Aug 28 10:37:12.606 EDT: tty2: Modem: READY->(unknown)

Aug 28 10:37:13.606 EDT: TTY2: dropping DTR, hanging up

Aug 28 10:37:13.606 EDT: tty2: Modem: HANGUP->(unknown)

Aug 28 10:37:13.938 EDT: %LINK-5-CHANGED: Interface Serial0/1, changed state to

reset

Aug 28 10:37:13.938 EDT: Se0/1 LCP: State is Closed

Aug 28 10:37:13.938 EDT: Se0/1 PPP: Phase is DOWN [0 sess, 0 load]

Aug 28 10:37:14.614 EDT: TTY2: cleanup pending. Delaying DTR

Aug 28 10:37:15.618 EDT: TTY2: cleanup pending. Delaying DTR

Aug 28 10:37:16.622 EDT: TTY2: cleanup pending. Delaying DTR

Aug 28 10:37:16.942 EDT: TTY2: no timer type 0 to destroy

Aug 28 10:37:16.942 EDT: TTY2: no timer type 1 to destroy

Aug 28 10:37:16.942 EDT: TTY2: no timer type 3 to destroy

Aug 28 10:37:16.942 EDT: TTY2: no timer type 4 to destroy

Aug 28 10:37:16.942 EDT: TTY2: no timer type 2 to destroy

Aug 28 10:37:16.942 EDT: Serial0/1: allowing modem_process to continue hangup

Aug 28 10:37:17.622 EDT: TTY2: restoring DTR

Aug 28 10:37:18.634 EDT: TTY2: autoconfigure probe started

Aug 28 10:37:18.942 EDT: %LINK-3-UPDOWN: Interface Serial0/1, changed state to down

Aug 28 10:37:18.942 EDT: Se0/1 LCP: State is Closed

Kind of like a bad marriage -- each side talks but neither side hears the other.

Re: No IPCP negotiation

George,

That confirms my earlier suspicion about a physical layer problem. I have seen this happen many times before where each side would send packets but neither would receive any.

I personally think the problem may be the modem at the remote site. Try changing the dip switch settings and reset it or try another modem, if possible.

HTH,

Sundar

New Member

Re: No IPCP negotiation

Thanks for replying, Sundar.

As I mentioned earlier to Rick, doing anything at the remote site is problematic at best. I think the best I can do is configure some new modems and ship them over, then try to talk someone through replacing them.

What's odd is that there are two modems at the remote, on Se0/1 and Se0/2, and I get the same problem out either one.

Re: No IPCP negotiation

Can you post the show config (after removing any confidential info) of the remote router?

New Member

Re: No IPCP negotiation

It's about 5-6 messages up in this thread (at least the relevant portions of the config.)

Re: No IPCP negotiation

ok. Looks like speed mismatch may very well be the culprit.

Can you follow the directions listed in the following URL to troubleshoot this issue.

http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a0080143175.shtml#modemcannotsendorreceivedata

HTH,

Sundar

New Member

Re: No IPCP negotiation

Well, Bingo!

Thanks, Sundar. I set "speed 38400" on the two lines and it worked. Now if only I could figure out why, since the same model of router with the same model of modem (I'm pretty sure, anyway) works from other regions even with "speed 115200." I thought that once the V34/LAPM negotiation is done, then this is all set.

Re: No IPCP negotiation

Glad to hear that :-)

Can you swap the cable and see if it lets you set the speed to 115200.

Give it a try and let us know what you find.

Good Luck!!

HTH,

Sundar

405
Views
4
Helpful
15
Replies
CreatePlease login to create content