Strange problem 827

Hi all,

i've a strange problem with a Cisco 827.

It is configured on a Adsl connection with 8 static ip addresses, auth is PPPoA and encapsulation mux.

The router correctly connects to Internet and everything seems to go fine.

after a while (1 minute or 1 hour or more) Atm goes down so the Dialer Interface tries to connect again.

After some disconnections and reconnections, the Virtual-access1 interface remains down and there is no way other than reload to pull it up again. I tried to shut/no shut the Atm interface but only a reload can solve.

What is that "Vi1 PPP: Authorization NOT required" that can be read below in console log ? It could be the real problem, but i'm not sure.

Can somebody help me to solve this behaviour ?

Thanks for any answer.

Console log:

************************************************************ 22:28:56: Vi1 CHAP: I CHALLENGE id 1 len 34 from "c72g1.xx-atm2" 22:28:56: Vi1 PPP: Sent CHAP SENDAUTH Request to AAA 22:28:56: Vi1 PPP: Received SENDAUTH Response from AAA = FAIL 22:28:56: Vi1 CHAP: O RESPONSE id 1 len 47 from "USERID" 22:28:56: Vi1 EVT: Packet [34] 0 0x80B03434 22:28:56: Vi1 CHAP: I SUCCESS id 1 len 4 22:28:56: Vi1 EVT: Hook [34] 1 0x0 22:28:56: Vi1 EVT: Packet [34] 2 0x80D65334 22:28:56: Vi1 EVT: Packet [34] 2 0x80B03434 22:28:56: Vi1 EVT: Packet [34] 1 0x80B02904 22:28:56: Vi1 EVT: Packet [34] 2 0x80B02BD0 22:28:56: Vi1 EVT: Packet [34] 2 0x80D65334 22:28:56: Di1 EVT: Update Addr [0] 0 0xD9859970 22:28:56: Vi1 EVT: Add Route [34] 0 0xD5CD1842 22:28:57: Vi1 EVT: Packet [34] 1 0x80D65334 22:28:57: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up 22:28:57: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:07: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:08: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:18: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:18: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:28: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:28: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:38: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:38: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:48: Vi1 EVT: Packet [34] 1 0x80D65334 22:29:59: Vi1 EVT: Packet [34] 1 0x80D65334 22:30:41: Vi1 PPP: Authorization NOT required 22:30:41: Di1 EVT: Update Addr [0] 0 0x0 22:30:41: Di1 EVT: Remove Route [0] 0 0xD5CD1842 22:30:42: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state do down 22:30:43: Vi1 PPP: Authorization NOT required 22:31:34: Vi1 PPP: Authorization NOT required 22:32:25: Vi1 PPP: Authorization NOT required 22:33:17: Vi1 PPP: Authorization NOT required 22:34:08: Vi1 PPP: Authorization NOT required 22:34:59: Vi1 PPP: Authorization NOT required 22:35:50: Vi1 PPP: Authorization NOT required 22:36:42: Vi1 PPP: Authorization NOT required 22:37:33: Vi1 PPP: Authorization NOT required 22:38:25: Vi1 PPP: Authorization NOT required 22:39:15: Vi1 PPP: Authorization NOT required 22:40:07: Vi1 PPP: Authorization NOT required 22:40:58: Vi1 PPP: Authorization NOT required 22:41:50: Vi1 PPP: Authorization NOT required 22:42:41: Vi1 PPP: Authorization NOT required 22:43:32: Vi1 PPP: Authorization NOT required ***************************************************************

Interface status on problem

*************************************************************** Interface IP-Address OK? Method Status Protocol ATM0 unassigned YES NVRAM up up Dialer1 unassigned YES BOOTP up up Ethernet0 111.111.111.113 YES NVRAM up up Loopback0 unassigned YES NVRAM up up Virtual-Access1 unassigned YES unset up down ***************************************************************

Sh run:

*************************************************************** version 12.2 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname r1-4 ! no logging buffered enable secret 5 ********************* ! ip subnet-zero ip name-server 208.67.222.222 ! ! ! ! interface Loopback0 no ip address ! interface Ethernet0 ip address 111.111.111.113 255.255.255.248 hold-queue 100 out ! interface ATM0 no ip address no atm ilmi-keepalive ! pvc 8/35 encapsulation aal5mux ppp dialer dialer pool-member 1 ! dsl operating-mode auto hold-queue 224 in ! interface Dialer1 ip address negotiated ip mtu 1492 encapsulation ppp dialer pool 1 dialer remote-name inf dialer idle-timeout 0 dialer persistent dialer-group 1 ppp authentication chap callin ppp chap hostname ****************** ppp chap password 7 ******************* ! ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 no ip http server ! ! dialer-list 1 protocol ip permit ! line con 0 session-timeout 35791 stopbits 1 line vty 0 4 password 7 ********************** login ! scheduler max-task-time 5000 sntp server 193.204.114.105 end **********************************************************
Reply to
Vouno
Loading thread data ...

You have the ppp authentication configured so that it is only required if your internet provider attempts to establish a connection to YOU. Your internet provider will NEVER attempt to connect to you, your end ALWAYS initiates the ppp connection. You need to configure ppp authentication on outbound (or inbound and outbound) connections. The message you are seeing on the console is telling you that you are initiating a ppp connection, and authentication is not required, because that is how you have it configured. I'm not sure of the syntax, but I think the command is "ppp authentication chap callout" on the dialer interface. Not sure why this works at all, but it is probably a bug in IOS where it really does do outbound chap authentication on the first ppp connection.

Scott

Reply to
Thrill5

Authentication != Authorization

  1. Authentication answers "Who are you?". It's working:

  1. Authorization answers "Are you (see 1) allowed to do this?"

Since "Authorization NOT required", we don't care.

  1. We seem to be able to negotiate IPCP.

changed state to up

And a litle while later it goes down again.

changed state do down

My guess is that even though negotiation works, so obviously we are able to talk to the ISP, we foul up when we try to send a real IP packet and the interface perhaps goes down because of missed keepalives.

What debugs are these? Perhaps plain old "debug ppp negotiation" by itself might be good to see.

Reply to
Martin Gallagher

thanks for your answer but the error talks about AUTHORIZATION, not AUTHENTICATION.

The error in in some other place.

Reply to
Vouno

Hi Martin,

your answer is very useful, so i have tracked the logs you suggested to see where is the problem, but i wasn't able to find a solution, so i'll ask you some more questions

Right.

So it's a normal thing ? Logs are telling me that we don't need autorization 'cause the other end didn't ask it ?

This is right too.

I'll try this too, but it doesn't explain the imposibility to raise up the Virtual-Access interface.

Below you'll find PPP NEGO and PPP AUTH debug logs. Looking at logs seems something about LCP. What can i do to solve the issue ?

Log after a reload with connection completed successfully

******************************************************************* 00:00:45: %LINK-3-UPDOWN: Interface ATM0, changed state to up 00:00:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface ATM0, changed state to up 00:00:51: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up 00:00:51: Vi1 PPP: Treating connection as a callout 00:00:51: Vi1 PPP: Phase is ESTABLISHING, Active Open 00:00:51: Vi1 PPP: Authorization NOT required 00:00:51: Vi1 PPP: No remote authentication for call-out 00:00:51: Vi1 LCP: O CONFREQ [Closed] id 1 len 10 00:00:51: Vi1 LCP: MagicNumber 0x094446C1 (0x0506094446C1) 00:00:51: Vi1 LCP: I CONFREQ [REQsent] id 1 len 15 00:00:51: Vi1 LCP: AuthProto CHAP (0x0305C22305) 00:00:51: Vi1 LCP: MagicNumber 0x95770525 (0x050695770525) 00:00:51: Vi1 LCP: O CONFACK [REQsent] id 1 len 15 00:00:51: Vi1 LCP: AuthProto CHAP (0x0305C22305) 00:00:51: Vi1 LCP: MagicNumber 0x95770525 (0x050695770525) 00:00:53: Vi1 LCP: TIMEout: State ACKsent 00:00:53: Vi1 LCP: O CONFREQ [ACKsent] id 2 len 10 00:00:53: Vi1 LCP: MagicNumber 0x094446C1 (0x0506094446C1) 00:00:53: Vi1 LCP: I CONFREQ [ACKsent] id 2 len 15 00:00:53: Vi1 LCP: AuthProto CHAP (0x0305C22305) 00:00:53: Vi1 LCP: MagicNumber 0x95770525 (0x050695770525) 00:00:53: Vi1 LCP: O CONFACK [ACKsent] id 2 len 15 00:00:53: Vi1 LCP: AuthProto CHAP (0x0305C22305) 00:00:53: Vi1 LCP: MagicNumber 0x95770525 (0x050695770525) 00:00:53: Vi1 LCP: I CONFACK [ACKsent] id 2 len 10 00:00:53: Vi1 LCP: MagicNumber 0x094446C1 (0x0506094446C1) 00:00:53: Vi1 LCP: State is Open 00:00:53: Vi1 PPP: Phase is AUTHENTICATING, by the peer 00:00:53: Vi1 CHAP: I CHALLENGE id 1 len 34 from "c72g1.xx-atm2" 00:00:53: Vi1 PPP: Sent CHAP SENDAUTH Request to AAA 00:00:53: Vi1 PPP: Received SENDAUTH Response from AAA = FAIL 00:00:53: Vi1 CHAP: O RESPONSE id 1 len 47 from "usernamet" 00:00:53: Vi1 CHAP: I SUCCESS id 1 len 4 00:00:53: Vi1 PPP: Phase is FORWARDING, Attempting Forward 00:00:53: Vi1 PPP: Phase is ESTABLISHING, Finish LCP 00:00:53: Vi1 PPP: Phase is UP 00:00:53: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 00:00:53: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) 00:00:53: Vi1 CDPCP: O CONFREQ [Closed] id 1 len 4 00:00:53: Vi1 IPCP: I CONFREQ [REQsent] id 1 len 16 00:00:53: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00) 00:00:53: Vi1 IPCP: Address 213.205.24.66 (0x0306D5CD1842) 00:00:53: Vi1 IPCP: O CONFREJ [REQsent] id 1 len 10 00:00:53: Vi1 IPCP: CompressType VJ 15 slots (0x0206002D0F00) 00:00:53: Vi1 IPCP: I CONFNAK [REQsent] id 1 len 10 00:00:53: Vi1 IPCP: Address 217.133.153.112 (0x0306D9859970) 00:00:53: Vi1 IPCP: O CONFREQ [REQsent] id 2 len 10 00:00:53: Vi1 IPCP: Address 217.133.153.112 (0x0306D9859970) 00:00:53: Vi1 LCP: I PROTREJ [Open] id 1 len 10 protocol CDPCP (0x820701010004) 00:00:53: Vi1 CDPCP: State is Listen 00:00:53: Vi1 IPCP: I CONFREQ [REQsent] id 2 len 10 00:00:53: Vi1 IPCP: Address 113.113.24.66 (0x0306D5CD1842) 00:00:53: Vi1 IPCP: O CONFACK [REQsent] id 2 len 10 00:00:53: Vi1 IPCP: Address 113.113.24.66 (0x0306D5CD1842) 00:00:53: Vi1 IPCP: I CONFACK [ACKsent] id 2 len 10 00:00:53: Vi1 IPCP: Address 111.111.111.112 (0x0306D9859970) 00:00:53: Vi1 IPCP: State is Open 00:00:53: Di1 IPCP: Install negotiated IP interface address 217.133.153.112 00:00:53: Di1 IPCP: Install route to 113.113.24.66 00:00:53: Vi1 IPCP: Add link info for cef entry 113.113.24.66 00:00:54: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up ******************************************************************

After a while and some disconnections and reconnections the debug log is this:

****************************************************************** 2d22h: Vi1 LCP: TIMEout: State Listen 2d22h: Vi1 LCP: O CONFREQ [Listen] id 125 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 126 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 127 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 128 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 129 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 130 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 131 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 132 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 133 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 134 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: State is Listen 2d22h: Vi1 LCP: TIMEout: State Listen 2d22h: Vi1 LCP: O CONFREQ [Listen] id 135 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 136 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 137 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 138 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 139 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 140 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 141 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 142 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 143 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 144 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1873A5B4 (0x05061873A5B4) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: State is Listen 2d22h: Vi1 LCP: TIMEout: State Listen 2d22h: Vi1 LCP: O CONFREQ [Listen] id 145 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 146 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 147 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 148 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 149 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 150 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 151 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 152 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 153 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: O CONFREQ [REQsent] id 154 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x18746EA1 (0x050618746EA1) 2d22h: Vi1 LCP: TIMEout: State REQsent 2d22h: Vi1 LCP: State is Listen ***************************************************************
Reply to
Vouno

Not so much the other end. PPP sometimes need authorization from AAA, ( Authentication, Authorization, Accounting) if it's configured. In this case it appears not.

Fair enough. Also you previously said it might work for up to an hour, so IPCP must be good for at least that long.

Link Control Protocol is the 1st phase of PPP negotiation. Once LCP is open you can move on to things like authentication (CHAP, PAP etc.) and IPCP (get an IP address and surf the web).

Here's when it works.

1) We send (O) a CONFigure REQuest.

00:00:53: Vi1 LCP: O CONFREQ [ACKsent] id 2 len 10

00:00:53: Vi1 LCP: MagicNumber 0x094446C1 (0x0506094446C1)

2) They send (I) a CONFigure REQuest. They want us to authenticate using CHAP.

00:00:53: Vi1 LCP: I CONFREQ [ACKsent] id 2 len 15 00:00:53: Vi1 LCP: AuthProto CHAP (0x0305C22305) 00:00:53: Vi1 LCP: MagicNumber 0x95770525 (0x050695770525)

3) We send (O) a CONFigure ACKnowledge. We are happy to do CHAP.

00:00:53: Vi1 LCP: O CONFACK [ACKsent] id 2 len 15 00:00:53: Vi1 LCP: AuthProto CHAP (0x0305C22305) 00:00:53: Vi1 LCP: MagicNumber 0x95770525 (0x050695770525)

4) They send (I) a CONFigure ACKnowledge.

00:00:53: Vi1 LCP: I CONFACK [ACKsent] id 2 len 10 00:00:53: Vi1 LCP: MagicNumber 0x094446C1 (0x0506094446C1)

5) LCP has been succesfully negotiated.

00:00:53: Vi1 LCP: State is Open

When it's not working.

1) We send (O) a CONFigure REQuest. We are asking the ISP to authenticate using CHAP.

2d22h: Vi1 LCP: O CONFREQ [Listen] id 125 len 15

2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF)

2) We get no response from the ISP and go round again.

2d22h: Vi1 LCP: TIMEout: State REQsent

It just *might* be that the ISP is not responding because we ask for CHAP and they just don't want to do it.

I think if you take the "ppp authentication chap callin" line off your dialer, "no ppp authentication chap", then we should never ask for any sort of authentication and it *might* make a difference.

Failing that you might be looking at a software bug where the router says it's going to send a packet and then doesn't. You might be able to see something by careful study of the router interface counters, in particular ATM0.

If you reload your router and get show interface after the virtual-access comes up, you should have a snapshot of what it looks like in good condition. Then wait till it's in the failed state and compare several show interface outputs over a span of a few minutes to see what counters are changing, and by how much.

Reply to
Martin Gallagher

I tried to set only pap authentication and no authentication at all. Provider seems to REQUIRE chap auth.

Ok. I deleted this. Now my config is:

interface ATM0 no ip address logging event subif-link-status timeout absolute 5 0 no atm ilmi-keepalive pvc 8/35 encapsulation aal5mux ppp dialer dialer pool-member 1 ! dsl operating-mode auto hold-queue 224 in ! interface Dialer0 ip address negotiated ip access-group 111 in ip mtu 1492 encapsulation ppp dialer pool 1 dialer-group 1 ppp chap hostname myusername ppp chap password 7 **************************** !

The Authorization not required message still exists

00:01:01: Vi1 EVT: Cstate [0] 4 0x80EB1610 00:01:01: Vi1 PPP: Treating connection as a callout 00:01:01: Vi1 PPP: Phase is ESTABLISHING, Active Open 00:01:01: Vi1 PPP: Authorization NOT required 00:01:01: Vi1 PPP: No remote authentication for call-out 00:01:01: Vi1 LCP: O CONFREQ [Closed] id 1 len 10 00:01:01: Vi1 LCP: MagicNumber 0x09446DFD (0x050609446DFD) 00:01:01: Vi1 EVT: Packet [0] 1 0x80B02904 00:01:01: Vi1 LCP: I CONFREQ [REQsent] id 1 len 15

I made this test too. Result is that on interface ATM0 output counters increments while in put counters freeze.

Now i'll make two tests. I'll change the 827 with a simple modem to see if the problem si the Cisco, and, if so, i'll update the firmware.

If you have some other idea...

Thanks again for your help.

Reply to
Vouno

No surprise there. What I was saying is the we should never have CHAP in our CONFREQ becuae that means we are asking the ISP to authenticate (prove who it is) to us and thye won't.

I don't think that message matters either way.

OK, so as far as we can tell we are transmitting something. Do the debugs still look like this:

2d22h: Vi1 LCP: O CONFREQ [Listen] id 125 len 15 2d22h: Vi1 LCP: AuthProto CHAP (0x0305C22305) 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF)

Or this:

2d22h: Vi1 LCP: O CONFREQ [Listen] id 125 len 15 2d22h: Vi1 LCP: MagicNumber 0x1872DCDF (0x05061872DCDF)

simple modem to see

Seems fair enough. If you ISP is friendly you could try asking them what they see at their end and why they don't respond.

Rgds, Martin

Reply to
Martin Gallagher

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.