Re: PPP events [7:58462]
Hi Erick, thanks for the feedback. The debug output is below... May 29 21:30:39.033 UTC: As132 LCP: I CONFREQ [Closed] id 41 len 24 May 29 21:30:39.033 UTC: As132 LCP:MRU 2048 (0x01040800) May 29 21:30:39.033 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.033 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.033 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:39.033 UTC: As132 LCP:MagicNumber 0xA3266B61 (0x0506A3266B61) May 29 21:30:39.037 UTC: As132 LCP: Lower layer not up, Fast Starting May 29 21:30:39.037 UTC: As132 PPP: Treating connection as a dedicated line May 29 21:30:39.037 UTC: As132 PPP: Phase is ESTABLISHING, Active Open May 29 21:30:39.037 UTC: As132 AAA/AUTHOR/FSM: (0): LCP succeeds trivially May 29 21:30:39.037 UTC: As132 LCP: O CONFREQ [Closed] id 1 len 44 May 29 21:30:39.037 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.037 UTC: As132 LCP:AuthProto PAP (0x0304C023) May 29 21:30:39.037 UTC: As132 LCP:MagicNumber 0xB1DD6D13 (0x0506B1DD6D13) May 29 21:30:39.037 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.037 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:39.037 UTC: As132 LCP:MRRU 1524 (0x110405F4) May 29 21:30:39.037 UTC: As132 LCP:EndpointDisc 1 Local (0x1310015741502D4D5 54C54494C494E4B) May 29 21:30:39.037 UTC: As132 LCP: O CONFACK [REQsent] id 41 len 24 May 29 21:30:39.037 UTC: As132 LCP:MRU 2048 (0x01040800) May 29 21:30:39.037 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.037 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.037 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:39.037 UTC: As132 LCP:MagicNumber 0xA3266B61 (0x0506A3266B61) May 29 21:30:39.785 UTC: As132 LCP: I CONFREJ [ACKsent] id 1 len 24 May 29 21:30:39.785 UTC: As132 LCP:MRRU 1524 (0x110405F4) May 29 21:30:39.785 UTC: As132 LCP:EndpointDisc 1 Local (0x1310015741502D4D5 54C54494C494E4B) May 29 21:30:39.789 UTC: As132 LCP: O CONFREQ [ACKsent] id 2 len 24 May 29 21:30:39.789 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.789 UTC: As132 LCP:AuthProto PAP (0x0304C023) May 29 21:30:39.789 UTC: As132 LCP:MagicNumber 0xB1DD6D13 (0x0506B1DD6D13) May 29 21:30:39.789 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.789 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:40.525 UTC: As132 LCP: I CONFACK [ACKsent] id 2 len 24 May 29 21:30:40.525 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:40.525 UTC: As132 LCP:AuthProto PAP (0x0304C023) May 29 21:30:40.525 UTC: As132 LCP:MagicNumber 0xB1DD6D13 (0x0506B1DD6D13) May 29 21:30:40.525 UTC: As132 LCP:PFC (0x0702) May 29 21:30:40.525 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:40.525 UTC: As132 LCP: State is Open May 29 21:30:40.525 UTC: As132 PPP: Phase is AUTHENTICATING, by this end May 29 21:30:40.541 UTC: As132 PAP: I AUTH-REQ id 1 len 17 from ciscowap May 29 21:30:40.541 UTC: As132 PPP: Phase is FORWARDING May 29 21:30:40.541 UTC: As132 PPP: Phase is AUTHENTICATING May 29 21:30:40.541 UTC: As132 PAP: Authenticating peer ciscowap May 29 21:30:40.541 UTC: AAA: parse name=Async132 idb type=10 tty=132 May 29 21:30:40.541 UTC: AAA: name=Async132 flags=0x11 type=4 shelf=0 slot=0 ada pter=0 port=132 channel=0 May 29 21:30:40.541 UTC: AAA: parse name=Serial0:0 idb type=13 tty=-1 May 29 21:30:40.541 UTC: AAA: name=Serial0:0 flags=0x51 type=1 shelf=0 slot=0 ad apter=0 port=0 channel=0 May 29 21:30:40.541 UTC: AAA/MEMORY: create_user (0x625F47BC) user='ciscowap' ru ser='' port='Async132' rem_addr='07714226291/01212757990' authen_type=PAP servic e=PPP priv=1 May 29 21:30:40.541 UTC: AAA/AUTHEN/START (2546412185): port='Async132' list='IS DN' action=LOGIN service=PPP May 29 21:30:40.541 UTC: AAA/AUTHEN/START (2546412185): found list ISDN May 29 21:30:40.541 UTC: AAA/AUTHEN/START (2546412185): Method=LOCAL May 29 21:30:40.541 UTC: AAA/AUTHEN (2546412185): status = PASS May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP: Authorize LCP May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): Port='Async132' list ='' service=NET May 29 21:30:40.541 UTC: AAA/AUTHOR/LCP: As132 (3166493837) user='ciscowap' May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): send AV service=ppp May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): send AV protocol=lcp May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): found list default May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): Method=LOCAL May 29 21:30:40.541 UTC: As132 AAA/AUTHOR (3166493837): Post authorization statu s = PASS_REPL May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP: Processing AV service=ppp May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP: Processing AV protocol=lcp May 29 21:30:40.545 UTC: As132 PAP: O AUTH-ACK id 1 len 5 May 29 21:30:40.545 UTC: Vi1 PPP: Phase is DOWN, Setup May 29 21:30:40.689 UTC: Vi1 PPP: Using set call direction May 29 21:30:40.689 UTC: Vi1 PPP: Treating connection as a callin May 29 21:30:40.689 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive
Re: PPP events [7:58462]
Wolfgang, Are these cisco routers on both sides ? do you have control of both or not? It appears as this is an async connection on this end (modem). We get a input packet with CONFREJ (reject) but it appears to get further later and rejects on IPCP. Then theres a protocol reject (PROTREJ) inbound. Once sides has a MRU of 2048 and other has MRU of 1524. I've seen some PPP connections have problems with mismatched MRUs. Need to know more about the configs on both sides, and possibly get debugs from both sides if possible. erick --- wolfgang klages wrote: Hi Erick, thanks for the feedback. The debug output is below... May 29 21:30:39.033 UTC: As132 LCP: I CONFREQ [Closed] id 41 len 24 May 29 21:30:39.033 UTC: As132 LCP:MRU 2048 (0x01040800) May 29 21:30:39.033 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.033 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.033 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:39.033 UTC: As132 LCP:MagicNumber 0xA3266B61 (0x0506A3266B61) May 29 21:30:39.037 UTC: As132 LCP: Lower layer not up, Fast Starting May 29 21:30:39.037 UTC: As132 PPP: Treating connection as a dedicated line May 29 21:30:39.037 UTC: As132 PPP: Phase is ESTABLISHING, Active Open May 29 21:30:39.037 UTC: As132 AAA/AUTHOR/FSM: (0): LCP succeeds trivially May 29 21:30:39.037 UTC: As132 LCP: O CONFREQ [Closed] id 1 len 44 May 29 21:30:39.037 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.037 UTC: As132 LCP:AuthProto PAP (0x0304C023) May 29 21:30:39.037 UTC: As132 LCP:MagicNumber 0xB1DD6D13 (0x0506B1DD6D13) May 29 21:30:39.037 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.037 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:39.037 UTC: As132 LCP:MRRU 1524 (0x110405F4) May 29 21:30:39.037 UTC: As132 LCP:EndpointDisc 1 Local (0x1310015741502D4D5 54C54494C494E4B) May 29 21:30:39.037 UTC: As132 LCP: O CONFACK [REQsent] id 41 len 24 May 29 21:30:39.037 UTC: As132 LCP:MRU 2048 (0x01040800) May 29 21:30:39.037 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.037 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.037 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:39.037 UTC: As132 LCP:MagicNumber 0xA3266B61 (0x0506A3266B61) May 29 21:30:39.785 UTC: As132 LCP: I CONFREJ [ACKsent] id 1 len 24 May 29 21:30:39.785 UTC: As132 LCP:MRRU 1524 (0x110405F4) May 29 21:30:39.785 UTC: As132 LCP:EndpointDisc 1 Local (0x1310015741502D4D5 54C54494C494E4B) May 29 21:30:39.789 UTC: As132 LCP: O CONFREQ [ACKsent] id 2 len 24 May 29 21:30:39.789 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:39.789 UTC: As132 LCP:AuthProto PAP (0x0304C023) May 29 21:30:39.789 UTC: As132 LCP:MagicNumber 0xB1DD6D13 (0x0506B1DD6D13) May 29 21:30:39.789 UTC: As132 LCP:PFC (0x0702) May 29 21:30:39.789 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:40.525 UTC: As132 LCP: I CONFACK [ACKsent] id 2 len 24 May 29 21:30:40.525 UTC: As132 LCP:ACCM 0x000A (0x0206000A) May 29 21:30:40.525 UTC: As132 LCP:AuthProto PAP (0x0304C023) May 29 21:30:40.525 UTC: As132 LCP:MagicNumber 0xB1DD6D13 (0x0506B1DD6D13) May 29 21:30:40.525 UTC: As132 LCP:PFC (0x0702) May 29 21:30:40.525 UTC: As132 LCP:ACFC (0x0802) May 29 21:30:40.525 UTC: As132 LCP: State is Open May 29 21:30:40.525 UTC: As132 PPP: Phase is AUTHENTICATING, by this end May 29 21:30:40.541 UTC: As132 PAP: I AUTH-REQ id 1 len 17 from ciscowap May 29 21:30:40.541 UTC: As132 PPP: Phase is FORWARDING May 29 21:30:40.541 UTC: As132 PPP: Phase is AUTHENTICATING May 29 21:30:40.541 UTC: As132 PAP: Authenticating peer ciscowap May 29 21:30:40.541 UTC: AAA: parse name=Async132 idb type=10 tty=132 May 29 21:30:40.541 UTC: AAA: name=Async132 flags=0x11 type=4 shelf=0 slot=0 ada pter=0 port=132 channel=0 May 29 21:30:40.541 UTC: AAA: parse name=Serial0:0 idb type=13 tty=-1 May 29 21:30:40.541 UTC: AAA: name=Serial0:0 flags=0x51 type=1 shelf=0 slot=0 ad apter=0 port=0 channel=0 May 29 21:30:40.541 UTC: AAA/MEMORY: create_user (0x625F47BC) user='ciscowap' ru ser='' port='Async132' rem_addr='07714226291/01212757990' authen_type=PAP servic e=PPP priv=1 May 29 21:30:40.541 UTC: AAA/AUTHEN/START (2546412185): port='Async132' list='IS DN' action=LOGIN service=PPP May 29 21:30:40.541 UTC: AAA/AUTHEN/START (2546412185): found list ISDN May 29 21:30:40.541 UTC: AAA/AUTHEN/START (2546412185): Method=LOCAL May 29 21:30:40.541 UTC: AAA/AUTHEN (2546412185): status = PASS May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP: Authorize LCP May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): Port='Async132' list ='' service=NET May 29 21:30:40.541 UTC: AAA/AUTHOR/LCP: As132 (3166493837) user='ciscowap' May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): send AV service=ppp May 29 21:30:40.541 UTC: As132 AAA/AUTHOR/LCP (3166493837): send AV
PPP events [7:58462]
Group, Couple of PPP questions... [1] I'm looking at the debug output of a PPP negotiation on a Cisco router. The router receives a CONFREQ in the 'Closed' state. RFC1661 specifies that the router should reply with a Terminate-Ack. However, the router replies with a CONFREQ of its own. The router then moves from the 'Closed' state to the 'REQsent' state. Hard to believe but could it be that the router is not behaving according to RFC1661. [2] In this same debug output, I see the router receive a 'FORCED CONFREQ'. This message is not in RFC1661. Is this something internal only to Cisco routers? If so, what is its purpose? Thanks __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58462t=58462 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PPP events [7:58462]
Perhaps the router isn't seeing the CONFREQ from the other router so is sending it's own. I've seen this kind of activity when troubleshooting PPP problems. Could be a line issue of some sort, code issue, misconfiguration perhaps, etc. What type of connection is this (Point to point, ISDN, etc)? You're best bet would be to post the debug output here from both routers (debug ppp nego). Set the timestamp to datetime format also (service timestamp debug datetime msec). HTH, Erick --- wolfgang klages wrote: Group, Couple of PPP questions... [1] I'm looking at the debug output of a PPP negotiation on a Cisco router. The router receives a CONFREQ in the 'Closed' state. RFC1661 specifies that the router should reply with a Terminate-Ack. However, the router replies with a CONFREQ of its own. The router then moves from the 'Closed' state to the 'REQsent' state. Hard to believe but could it be that the router is not behaving according to RFC1661. [2] In this same debug output, I see the router receive a 'FORCED CONFREQ'. This message is not in RFC1661. Is this something internal only to Cisco routers? If so, what is its purpose? __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=58529t=58462 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
