12-21-2012 03:10 AM
Hello,
I'm having an issue with dial-up networking connections to a Cisco 2911 running IOS 15.2(4)M1. Router hardware as follows and config attached.
#sh inventory
NAME: "CISCO2911/K9", DESCR: "CISCO2911/K9 chassis, Hw Serial#: FTX1542ALP9, Hw Revision: 1.0"
PID: CISCO2911/K9 , VID: V04 , SN: FTX1542ALP9
NAME: "1 port channelized and PRI T1/E1 HWIC on Slot 0 SubSlot 0", DESCR: "1 port channelized and PRI T1/E1 HWIC"
PID: HWIC-1CE1T1-PRI , VID: V02 , SN: FOC15274A06
NAME: "12 port PVDMII digital modem on Slot 0 SubSlot 4", DESCR: "12 port PVDMII digital modem"
PID: PVDM2-12DM , VID: V01 , SN: FOC16122728
NAME: "C2911 AC Power Supply", DESCR: "C2911 AC Power Supply"
PID: PWR-2911-AC , VID: V03 , SN: DCA1527R1HU
We have many clients connecting to this rotuer via dial-up networking on Windows XP PCs. Some use ISDN and others PSTN. We're having trouble with just two clients (many others are working). From comparing two different debugs it appears that where the connection isn't working that the router is failing to instigate PPP authentication.
Working debug below
*Dec 21 09:51:43.305: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0002
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Progress Ind i = 0x8483 - Origination address is non-ISDN
Calling Party Number i = 0x2183, 'xxxxxx' <hidden for security>
Plan:ISDN, Type:National
Called Party Number i = 0x81, 'yyyyy' <hidden for security>
Plan:ISDN, Type:Unknown
*Dec 21 09:51:43.305: ISDN Se0/0/0:15 Q931: Received SETUP callref = 0x8002 callID = 0x2CC7 switch = primary-net5 interface = User
*Dec 21 09:51:43.305: ISDN Se0/0/0:15 EVENT: process_rxstate: ces/callid 1/0x2CC7 calltype 2 CALL_INCOMING
*Dec 21 09:51:43.305: ISDN Se0/0/0:15 EVENT: call_incoming: call_id 0x2CC7, Guid = 008400002B83
*Dec 21 09:51:43.309: ISDN Se0/0/0:15 EVENT: UserIdle: callid 0x2CC7 received ACCEPT_CALL (0x13)
*Dec 21 09:51:43.309: ISDN Se0/0/0:15 EVENT: process_modem_command: received event VOICE_ANS on callid 0x2CC7 and bchan 1 ces 1 cause 16 switch type 18
*Dec 21 09:51:43.309: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8002
Channel ID i = 0xA98382
Exclusive, Channel 2
*Dec 21 09:51:43.309: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8002
*Dec 21 09:51:43.309: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8002
*Dec 21 09:51:43.409: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0002
*Dec 21 09:51:43.409: ISDN Se0/0/0:15 EVENT: process_rxstate: ces/callid 1/0x2CC7 calltype 2 CALL_PROGRESS
*Dec 21 09:51:43.409: ISDN Se0/0/0:15 EVENT: isdn_neighbor_update: NLCB->State 10
*Dec 21 09:52:05.589: As0/199 PPP: Using dialer call direction
*Dec 21 09:52:05.593: As0/199 PPP: Treating connection as a callin
*Dec 21 09:52:05.593: As0/199 PPP: Session handle[A30000E9] Session id[107]
*Dec 21 09:52:05.593: %LINK-3-UPDOWN: Interface Async0/199, changed state to up
*Dec 21 09:52:05.877: As0/199 CHAP: O CHALLENGE id 1 len 35 from "<router name>"
*Dec 21 09:52:06.097: As0/199 CHAP: I RESPONSE id 1 len 27 from "<user ID>"
*Dec 21 09:52:06.097: As0/199 PPP: Sent CHAP LOGIN Request
<rest is truncated, the above block in bold only appears on working connections>
The connection that fails only gets this far
*Dec 20 10:11:57.711: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0002
Sending Complete
Bearer Capability i = 0x9090A3
Standard = CCITT
Transfer Capability = 3.1kHz Audio
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Progress Ind i = 0x8483 - Origination address is non-ISDN
Calling Party Number i = 0x2183, 'xxxxxx'
Plan:ISDN, Type:National
Called Party Number i = 0x81, 'yyyyy'
Plan:ISDN, Type:Unknown
*Dec 20 10:11:57.711: ISDN Se0/0/0:15 Q931: Received SETUP callref = 0x8002 callID = 0x2C24 switch = primary-net5 interface = User
*Dec 20 10:11:57.711: ISDN Se0/0/0:15 EVENT: process_rxstate: ces/callid 1/0x2C24 calltype 2 CALL_INCOMING
*Dec 20 10:11:57.711: ISDN Se0/0/0:15 EVENT: call_incoming: call_id 0x2C24, Guid = 008400002B83
*Dec 20 10:11:57.711: ISDN Se0/0/0:15 EVENT: UserIdle: callid 0x2C24 received ACCEPT_CALL (0x13)
*Dec 20 10:11:57.715: ISDN Se0/0/0:15 EVENT: process_modem_command: received event VOICE_ANS on callid 0x2C24 and bchan 1 ces 1 cause 16 switch type 18
*Dec 20 10:11:57.715: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8002
Channel ID i = 0xA98382
Exclusive, Channel 2
*Dec 20 10:11:57.715: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8002
*Dec 20 10:11:57.715: ISDN Se0/0/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8002
*Dec 20 10:11:57.795: ISDN Se0/0/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0002
*Dec 20 10:11:57.795: ISDN Se0/0/0:15 EVENT: process_rxstate: ces/callid 1/0x2C24 calltype 2 CALL_PROGRESS
*Dec 20 10:11:57.795: ISDN Se0/0/0:15 EVENT: isdn_neighbor_update: NLCB->State 10
Debug commands used
# show debug
PPP:
PPP authentication debugging is on
The following ISDN debugs are enabled on all DSLs:
debug isdn error is ON.
debug isdn event is ON.
debug isdn q931 is ON. (filter is OFF)
Radius protocol debugging is on
Radius packet protocol (authentication) debugging is on
I'd appreciate any advice or pointers. We've go no reason to believe anything has changed on the clients although I'm not ruling it out. We believe this may have stopped working when we moved off an older 3800 series router onto this one.
Thanks
Andrew
01-21-2013 08:15 AM
I think that if an ISDN call has established (which it looks like it has) but the higher level stuff is failing (PPP etc) then one thing could be a mismatch in dialling speed either end of the link (56k vs 64k). Not sure that would be the answer - just a thought.
Someone far cleverer than myself might be able to offer more ideas
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide