ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-01 Thread Sam Deckert 

Here is the debug isdn events output from when the 1700 disconnects:

clarendon2-gw#
04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is DATA,
b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from 0353324231
clarendon, call lasted 20 seconds
04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA


Here is the debug isdn events output from the 2611 side of things:
05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
05:12:30064771072: ISDN BR0/1: Event:  Call to  was hung up.
05:12:32225367716: ISDN BR0/1: process_disc_ack(): call id 0x25, ces 1, call
type DATA
05:12:30906921739: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected from
unknown , call lasted 20 seconds
05:12:3871552: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to down
05:12:3862421: ISDN BR0/1: received HOST_DISCONNECT_ACK call_id 0x25
05:12:30064771072: ISDN BR0/1: HOST_DISCONNECT_ACK: call type is DATA

I am still working on it!  Thought it might be the fast-idle timer, so made
it
a large value, to no avail.

Thanks again if anyone can help!

Sam.


- Original Message -
From: Sam Deckert
To: [EMAIL PROTECTED]
Sent: Monday, July 02, 2001 3:09 PM
Subject: ISDN B Channel Disconnecting


Hello everyone,

I am having a bit of an ISDN related problem at the moment and was wondering
if anyone is able to help.

I am connecting two sites together via 128k isdn, with one site having a 2611
and the other a 1700.

I have the two sites permanently connected fine with the first B channel,
however whenever I issue the "dialer load-threshold 1 either" command one
each
router to always have the 2nd B channel up, the second B channel connects and
remains connected for 20 seconds exactly before disconnecting.  The 1st B
channel remains connected regardless.

I have tried changing the idle-timeout values to no avail, and just cant
figure it out.

I guess it is probably something simple, but just cant work it out.

Here is the BRI config of the 2611:

username clarendon2-gw password 7 094E1B040D0210
!
hostname clarendon
ip subnet-zero
no ip finger
!
ipx routing 0030.854f.c9e0
ipx gns-response-delay 1500
isdn switch-type basic-net3
!
!
interface BRI0/1
 ip unnumbered BRI0/0
 encapsulation ppp
 no ip mroute-cache
 dialer idle-timeout 200
 dialer enable-timeout 5
 dialer wait-for-carrier-time 15
 dialer map ip xxx.xxx.xxx.xxx name clarendon2-gw broadcast
 dialer map ipx FEEDBEEF.0002.1761.29dd name clarendon2-gw broadcast
 dialer load-threshold 1 either
 dialer-group 1
 ipx network FEEDBEEF
 no ipx route-cache
 ipx watchdog-spoof
 isdn switch-type basic-net3
 isdn calling-number 
 no fair-queue
 compress stac
 no cdp enable
 ppp authentication chap
 ppp multilink
!
dialer-list 1 protocol ip permit
dialer-list 1 protocol ipx permit
no cdp run


Here is the config of the 1700:

hostname clarendon2-gw
!
username clarendon password 7 011153094F0C01
!
!
ipx routing 0002.1761.29dd
ipx gns-response-delay 1500
isdn switch-type basic-net3
!
interface BRI0
 ip unnumbered FastEthernet0
 encapsulation ppp
 dialer idle-timeout 200
 dialer map ip xxx.xxx.xxx.xxx name clarendon broadcast 
 dialer load-threshold 1 either
 dialer-group 1
 ipx network FEEDBEEF
 no ipx route-cache
 ipx watchdog-spoof
 isdn switch-type basic-net3
 no fair-queue
 compress stac
 no cdp enable
 ppp authentication chap
 ppp multilink
!
ip classless
no ip http server
!
dialer-list 1 protocol ip permit
dialer-list 1 protocol ipx permit
no cdp run
!
no scheduler allocate
end


What do you think???  Any advice, suggestions welcome and most appreciated!

Thanks...

Sam.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=10596&t=10596
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-01 Thread Tony Medeiros 

Do a "debug PPP authen" and a "debug PPP negotiation".  It looks like CHAP
is failing.
Tony M.
#6172

- Original Message -
From: Sam Deckert 
To: 
Sent: Sunday, July 01, 2001 10:48 PM
Subject: ISDN B Channel Disconnecting Cont... [7:10596]


> Here is the debug isdn events output from when the 1700 disconnects:
>
> clarendon2-gw#
> 04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
> 04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is
DATA,
> b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
> 04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
0353324231
> clarendon, call lasted 20 seconds
> 04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> 04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
> 04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
>
>
> Here is the debug isdn events output from the 2611 side of things:
> 05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
> 05:12:30064771072: ISDN BR0/1: Event:  Call to  was hung up.
> 05:12:32225367716: ISDN BR0/1: process_disc_ack(): call id 0x25, ces 1,
call
> type DATA
> 05:12:30906921739: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
from
> unknown , call lasted 20 seconds
> 05:12:3871552: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
down
> 05:12:3862421: ISDN BR0/1: received HOST_DISCONNECT_ACK call_id 0x25
> 05:12:30064771072: ISDN BR0/1: HOST_DISCONNECT_ACK: call type is DATA
>
> I am still working on it!  Thought it might be the fast-idle timer, so
made
> it
> a large value, to no avail.
>
> Thanks again if anyone can help!
>
> Sam.
>
>
> - Original Message -
> From: Sam Deckert
> To: [EMAIL PROTECTED]
> Sent: Monday, July 02, 2001 3:09 PM
> Subject: ISDN B Channel Disconnecting
>
>
> Hello everyone,
>
> I am having a bit of an ISDN related problem at the moment and was
wondering
> if anyone is able to help.
>
> I am connecting two sites together via 128k isdn, with one site having a
2611
> and the other a 1700.
>
> I have the two sites permanently connected fine with the first B channel,
> however whenever I issue the "dialer load-threshold 1 either" command one
> each
> router to always have the 2nd B channel up, the second B channel connects
and
> remains connected for 20 seconds exactly before disconnecting.  The 1st B
> channel remains connected regardless.
>
> I have tried changing the idle-timeout values to no avail, and just cant
> figure it out.
>
> I guess it is probably something simple, but just cant work it out.
>
> Here is the BRI config of the 2611:
>
> username clarendon2-gw password 7 094E1B040D0210
> !
> hostname clarendon
> ip subnet-zero
> no ip finger
> !
> ipx routing 0030.854f.c9e0
> ipx gns-response-delay 1500
> isdn switch-type basic-net3
> !
> !
> interface BRI0/1
>  ip unnumbered BRI0/0
>  encapsulation ppp
>  no ip mroute-cache
>  dialer idle-timeout 200
>  dialer enable-timeout 5
>  dialer wait-for-carrier-time 15
>  dialer map ip xxx.xxx.xxx.xxx name clarendon2-gw broadcast
>  dialer map ipx FEEDBEEF.0002.1761.29dd name clarendon2-gw broadcast
>  dialer load-threshold 1 either
>  dialer-group 1
>  ipx network FEEDBEEF
>  no ipx route-cache
>  ipx watchdog-spoof
>  isdn switch-type basic-net3
>  isdn calling-number 
>  no fair-queue
>  compress stac
>  no cdp enable
>  ppp authentication chap
>  ppp multilink
> !
> dialer-list 1 protocol ip permit
> dialer-list 1 protocol ipx permit
> no cdp run
>
>
> Here is the config of the 1700:
>
> hostname clarendon2-gw
> !
> username clarendon password 7 011153094F0C01
> !
> !
> ipx routing 0002.1761.29dd
> ipx gns-response-delay 1500
> isdn switch-type basic-net3
> !
> interface BRI0
>  ip unnumbered FastEthernet0
>  encapsulation ppp
>  dialer idle-timeout 200
>  dialer map ip xxx.xxx.xxx.xxx name clarendon broadcast
>  dialer load-threshold 1 either
>  dialer-group 1
>  ipx network FEEDBEEF
>  no ipx route-cache
>  ipx watchdog-spoof
>  isdn switch-type basic-net3
>  no fair-queue
>  compress stac
>  no cdp enable
>  ppp authentication chap
>  ppp multilink
> !
> ip classless
> no ip http server
> !
> dialer-list 1 protocol ip permit
> dialer-list 1 protocol ipx permit
> no cdp run
> !
> no scheduler allocate
> end
>
>
> What do you think???  Any advice, suggestions welcome and most
appreciated!
>
> Thanks...
>
> Sam.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=10597&t=10596
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-01 Thread Sam Deckert 
gicNumber 0x31E921E3 (0x050631E921E3)
05:32:00: BR0:2 LCP:MRRU 1524 (0x110405F4)
05:32:00: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
05:32:00: BR0:2 LCP: O CONFACK [ACKsent] id 64 len 31
05:32:00: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
05:32:00: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
05:32:00: BR0:2 LCP:MRRU 1524 (0x110405F4)
05:32:00: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
05:32:01: BR0:2 LCP: TIMEout: State ACKsent
05:32:01: BR0:2 LCP: State is Listen
05:32:01: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from 0353324231
clarendon, call lasted 20 seconds
05:32:4294967296: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
05:32:4294967296: BR0:2 LCP: State is Closed
05:32:6451316372: BR0:2 PPP: Phase is DOWN


2611 (called) router:

06:28:36: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to up
06:28:36: BR0/1:2 PPP: Treating connection as a callin
06:28:36: BR0/1:2 PPP: Phase is ESTABLISHING, Passive Open
06:28:36: BR0/1:2 LCP: State is Listen
06:28:38: BR0/1:2 LCP: TIMEout: State Listen
06:28:38: BR0/1:2 LCP: O CONFREQ [Listen] id 55 len 31
06:28:38: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:38: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:38: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:38: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:40: BR0/1:2 LCP: TIMEout: State REQsent
06:28:40: BR0/1:2 LCP: O CONFREQ [REQsent] id 56 len 31
06:28:40: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:40: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:40: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:40: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:42: BR0/1:2 LCP: TIMEout: State REQsent
06:28:42: BR0/1:2 LCP: O CONFREQ [REQsent] id 57 len 31
06:28:42: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:42: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:42: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:42: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:44: BR0/1:2 LCP: TIMEout: State REQsent
06:28:44: BR0/1:2 LCP: O CONFREQ [REQsent] id 58 len 31
06:28:44: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:44: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:44: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:44: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:46: BR0/1:2 LCP: TIMEout: State REQsent
06:28:46: BR0/1:2 LCP: O CONFREQ [REQsent] id 59 len 31
06:28:46: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:46: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:46: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:46: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:48: BR0/1:2 LCP: TIMEout: State REQsent
06:28:48: BR0/1:2 LCP: O CONFREQ [REQsent] id 60 len 31
06:28:48: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:48: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:48: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:48: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:50: BR0/1:2 LCP: TIMEout: State REQsent
06:28:50: BR0/1:2 LCP: O CONFREQ [REQsent] id 61 len 31
06:28:50: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:50: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:50: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:50: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:53: BR0/1:2 LCP: TIMEout: State REQsent
06:28:53: BR0/1:2 LCP: O CONFREQ [REQsent] id 62 len 31
06:28:53: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:53: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:53: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:53: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:55: BR0/1:2 LCP: TIMEout: State REQsent
06:28:55: BR0/1:2 LCP: O CONFREQ [REQsent] id 63 len 31
06:28:55: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:55: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:55: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:55: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:57: BR0/1:2 LCP: TIMEout: State REQsent
06:28:57: BR0/1:2 LCP: O CONFREQ [REQsent] id 64 len 31
06:28:57: BR0/1:2 LCP:AuthProto CHAP (0x0305C22305)
06:28:57: BR0/1:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
06:28:57: BR0/1:2 LCP:MRRU 1524 (0x110405F4)
06:28:57: BR0/1:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
06:28:244813135884: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
from unknown , call lasted 20 seconds
06:28:246971236352: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
down
06:28:245705605152: BR0/1:2 LCP: State is Closed
06:28:246973732444: BR0/1:2 PPP: Phase is DOWN


- Original Message -
From: "Tony Medeiros" 
To: "Sam Deckert" ; 
Sent: Monday, July 02, 2001 4:19 PM
Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-01 Thread Sam Deckert 

I just did a debug ppp error on both routers when dialling in, however did
not have anything come up - so not sure if the problem is with ppp.  Bugger!

Here was the output:

1700 (calling):
05:51:64424509440: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
05:51:35: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from 0353324231
clarendon, call lasted 20 seconds
05:51:150323855364: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down

2611 (called):
06:48:11: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to up
06:48:133143986184: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
from unknown , call lasted 20 seconds
06:48:135302086656: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
down

- Original Message -
From: "Sam Deckert" 
To: "Tony Medeiros" ; 
Sent: Monday, July 02, 2001 4:54 PM
Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]


> Thanks Tony,
>
> I thought that the ppp authentication was going ok, as the first channel
is
> always connected, however it is only the second channel that is
disconnected
> after 20 secs.
>
> I was looking at the output from the debug commands you suggested, and saw
> the following on the router being called:
>
> 06:28:36: BR0/1:2 PPP: Phase is ESTABLISHING, Passive Open
> 06:28:36: BR0/1:2 LCP: State is Listen
> 06:28:38: BR0/1:2 LCP: TIMEout: State Listen
>
> Does this mean that the router being called is listening for the first
> authentication from the client, however times out?  I guess what could be
> happening is that CHAP disconnects the call after 20secs of attempting to
> challenge???
>
> Here is the output from "debug PPP authen" and "debug PPP negotiation" on
> each router though.  Pease let me know if you see anything funny - I am
> searching on CCO to try and find out
>
> Sam.
>
> 1700 (calling) router:
>
> 05:31:180388626431: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
> 05:31:178241142757: BR0:2 PPP: Treating connection as a callout
> 05:31:178247820600: BR0:2 PPP: Phase is ESTABLISHING, Active Open
> 05:31:176093659168: BR0:2 LCP: O CONFREQ [Closed] id 55 len 35
> 05:31:180388626431: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:176093659136: BR0:2 LCP:MagicNumber 0x03470C22 (0x050603470C22)
> 05:31:176093659136: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:176093659136: BR0:2 LCP:EndpointDisc 1 Local
> (0x131001636C6172656E646F6E322D6777)
> 05:31:42: BR0:2 LCP: I CONFREQ [REQsent] id 55 len 31
> 05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> 05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:42: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
> 05:31:42: BR0:2 LCP: O CONFACK [REQsent] id 55 len 31
> 05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> 05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:42: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
> 05:31:43: BR0:2 LCP: TIMEout: State ACKsent
> 05:31:43: BR0:2 LCP: O CONFREQ [ACKsent] id 56 len 35
> 05:31:43: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:43: BR0:2 LCP:MagicNumber 0x03470C22 (0x050603470C22)
> 05:31:43: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:43: BR0:2 LCP:EndpointDisc 1 Local
> (0x131001636C6172656E646F6E322D6777)
> 05:31:44: BR0:2 LCP: I CONFREQ [ACKsent] id 56 len 31
> 05:31:44: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:44: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> 05:31:44: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:44: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
> 05:31:44: BR0:2 LCP: O CONFACK [ACKsent] id 56 len 31
> 05:31:44: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:44: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> 05:31:44: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:44: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
> 05:31:45: BR0:2 LCP: TIMEout: State ACKsent
> 05:31:45: BR0:2 LCP: O CONFREQ [ACKsent] id 57 len 35
> 05:31:45: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:45: BR0:2 LCP:MagicNumber 0x03470C22 (0x050603470C22)
> 05:31:45: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:45: BR0:2 LCP:EndpointDisc 1 Local
> (0x131001636C6172656E646F6E322D6777)
> 05:31:46: BR0:2 LCP: I CONFREQ [ACKsent] id 57 len 31
> 05:31:46: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> 05:31:46: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> 05:31:46: BR0:2 LCP:MRRU 1524 (0x110405F4)
> 05:31:46: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
> 05:31:46: BR0:2 LCP: O CONFACK [ACKsent] id 57 len 31
> 05:31:46: BR0:2 LCP:AuthPr

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread Tony Medeiros 

It now looks like it's dying at the LCP phase.  I would try and remove stac
compression and see if that works.  stac maybe incompatable with MLPPP.
Then, if that doesn't help, Try and get rid of "isdn calling number".  That
is a fluky command that doesn't work right unless CLID is sent from the
telco.  I have had lousy luck with that command.

Keep trying to "simplify " your config untill it works.   Then add more
complexity and see where it breaks.

Ain't dial a Bitch ???  Seems like I always have to fight to get it to work
right.  Thank God for debugs !!

Tony M.
#6172
- Original Message -
From: Sam Deckert 
To: 
Sent: Monday, July 02, 2001 12:12 AM
Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]


> I just did a debug ppp error on both routers when dialling in, however did
> not have anything come up - so not sure if the problem is with ppp.
Bugger!
>
> Here was the output:
>
> 1700 (calling):
> 05:51:64424509440: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
> 05:51:35: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
0353324231
> clarendon, call lasted 20 seconds
> 05:51:150323855364: %LINK-3-UPDOWN: Interface BRI0:2, changed state to
down
>
> 2611 (called):
> 06:48:11: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to up
> 06:48:133143986184: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
> from unknown , call lasted 20 seconds
> 06:48:135302086656: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
> down
>
> - Original Message -
> From: "Sam Deckert"
> To: "Tony Medeiros" ;
> Sent: Monday, July 02, 2001 4:54 PM
> Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]
>
>
> > Thanks Tony,
> >
> > I thought that the ppp authentication was going ok, as the first channel
> is
> > always connected, however it is only the second channel that is
> disconnected
> > after 20 secs.
> >
> > I was looking at the output from the debug commands you suggested, and
saw
> > the following on the router being called:
> >
> > 06:28:36: BR0/1:2 PPP: Phase is ESTABLISHING, Passive Open
> > 06:28:36: BR0/1:2 LCP: State is Listen
> > 06:28:38: BR0/1:2 LCP: TIMEout: State Listen
> >
> > Does this mean that the router being called is listening for the first
> > authentication from the client, however times out?  I guess what could
be
> > happening is that CHAP disconnects the call after 20secs of attempting
to
> > challenge???
> >
> > Here is the output from "debug PPP authen" and "debug PPP negotiation"
on
> > each router though.  Pease let me know if you see anything funny - I am
> > searching on CCO to try and find out
> >
> > Sam.
> >
> > 1700 (calling) router:
> >
> > 05:31:180388626431: %LINK-3-UPDOWN: Interface BRI0:2, changed state to
up
> > 05:31:178241142757: BR0:2 PPP: Treating connection as a callout
> > 05:31:178247820600: BR0:2 PPP: Phase is ESTABLISHING, Active Open
> > 05:31:176093659168: BR0:2 LCP: O CONFREQ [Closed] id 55 len 35
> > 05:31:180388626431: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:176093659136: BR0:2 LCP:MagicNumber 0x03470C22
(0x050603470C22)
> > 05:31:176093659136: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05:31:176093659136: BR0:2 LCP:EndpointDisc 1 Local
> > (0x131001636C6172656E646F6E322D6777)
> > 05:31:42: BR0:2 LCP: I CONFREQ [REQsent] id 55 len 31
> > 05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> > 05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05:31:42: BR0:2 LCP:EndpointDisc 1 Local
(0x130C01636C6172656E646F6E)
> > 05:31:42: BR0:2 LCP: O CONFACK [REQsent] id 55 len 31
> > 05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> > 05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05:31:42: BR0:2 LCP:EndpointDisc 1 Local
(0x130C01636C6172656E646F6E)
> > 05:31:43: BR0:2 LCP: TIMEout: State ACKsent
> > 05:31:43: BR0:2 LCP: O CONFREQ [ACKsent] id 56 len 35
> > 05:31:43: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:43: BR0:2 LCP:MagicNumber 0x03470C22 (0x050603470C22)
> > 05:31:43: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05:31:43: BR0:2 LCP:EndpointDisc 1 Local
> > (0x131001636C6172656E646F6E322D6777)
> > 05:31:44: BR0:2 LCP: I CONFREQ [ACKsent] id 56 len 31
> > 05:31:44: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:44: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> > 05:31:44: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread Alex Lee 

If I read it correctly, it seems the command 'dialer load-threshold 1' will
not bring up addtional link anymore :-

Quote
When Multilink PPP is configured and you want a multilink bundle to be
connected indefinitely, use the dialer idle-timeout command to set a very
high idle timer. (The dialer load-threshold 1 command no longer keeps a
multilink bundle of n links connected indefinitely and the dialer
load-threshold 2 command no longer keeps a multilink bundle of two links
connected indefinitely.)
Unquote

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/d
ial_c/dcprt2/dcppp.htm





"Sam Deckert" wrote in message ...
>Here is the debug isdn events output from when the 1700 disconnects:
>
>clarendon2-gw#
>04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
>04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is
DATA,
>b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
>04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
0353324231
>clarendon, call lasted 20 seconds
>04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
>04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
>04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
>04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
>04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
>
>
>Here is the debug isdn events output from the 2611 side of things:
>05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
>05:12:30064771072: ISDN BR0/1: Event:  Call to  was hung up.
>05:12:32225367716: ISDN BR0/1: process_disc_ack(): call id 0x25, ces 1,
call
>type DATA
>05:12:30906921739: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
from
>unknown , call lasted 20 seconds
>05:12:3871552: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
down
>05:12:3862421: ISDN BR0/1: received HOST_DISCONNECT_ACK call_id 0x25
>05:12:30064771072: ISDN BR0/1: HOST_DISCONNECT_ACK: call type is DATA
>
>I am still working on it!  Thought it might be the fast-idle timer, so made
>it
>a large value, to no avail.
>
>Thanks again if anyone can help!
>
>Sam.
>
>
>- Original Message -
>From: Sam Deckert
>To: [EMAIL PROTECTED]
>Sent: Monday, July 02, 2001 3:09 PM
>Subject: ISDN B Channel Disconnecting
>
>
>Hello everyone,
>
>I am having a bit of an ISDN related problem at the moment and was
wondering
>if anyone is able to help.
>
>I am connecting two sites together via 128k isdn, with one site having a
2611
>and the other a 1700.
>
>I have the two sites permanently connected fine with the first B channel,
>however whenever I issue the "dialer load-threshold 1 either" command one
>each
>router to always have the 2nd B channel up, the second B channel connects
and
>remains connected for 20 seconds exactly before disconnecting.  The 1st B
>channel remains connected regardless.
>
>I have tried changing the idle-timeout values to no avail, and just cant
>figure it out.
>
>I guess it is probably something simple, but just cant work it out.
>
>Here is the BRI config of the 2611:
>
>username clarendon2-gw password 7 094E1B040D0210
>!
>hostname clarendon
>ip subnet-zero
>no ip finger
>!
>ipx routing 0030.854f.c9e0
>ipx gns-response-delay 1500
>isdn switch-type basic-net3
>!
>!
>interface BRI0/1
> ip unnumbered BRI0/0
> encapsulation ppp
> no ip mroute-cache
> dialer idle-timeout 200
> dialer enable-timeout 5
> dialer wait-for-carrier-time 15
> dialer map ip xxx.xxx.xxx.xxx name clarendon2-gw broadcast
> dialer map ipx FEEDBEEF.0002.1761.29dd name clarendon2-gw broadcast
> dialer load-threshold 1 either
> dialer-group 1
> ipx network FEEDBEEF
> no ipx route-cache
> ipx watchdog-spoof
> isdn switch-type basic-net3
> isdn calling-number 
> no fair-queue
> compress stac
> no cdp enable
> ppp authentication chap
> ppp multilink
>!
>dialer-list 1 protocol ip permit
>dialer-list 1 protocol ipx permit
>no cdp run
>
>
>Here is the config of the 1700:
>
>hostname clarendon2-gw
>!
>username clarendon password 7 011153094F0C01
>!
>!
>ipx routing 0002.1761.29dd
>ipx gns-response-delay 1500
>isdn switch-type basic-net3
>!
>interface BRI0
> ip unnumbered FastEthernet0
> encapsulation ppp
> dialer idle-timeout 200
> dialer map ip xxx.xxx.xxx.xxx name clarendon broadcast
> dialer load-threshold 1 either
> dialer-group 1
> ipx network FEEDBEEF
> no ipx route-cache
> ipx watchdog-spoof
> isdn switch-type basic-net3
> no fair-queue
> compress stac
> no cdp enable
> ppp authentication chap
> ppp multilink
>!
>ip classless
>no ip http server
>!
>dialer-list 1 protocol ip permit
>dialer-list 1 protocol ipx permit
>no cdp run
>!
>no scheduler allocate
>end
>
>
>What do you think???  Any advice, suggestions welcome and most appreciated!
>
>Thanks...
>
>Sam.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=10647&t=10596
--
FAQ, list archives, and subscri

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread Jim Barksdale 

I'm not sure if this will help since the problem seems to be brnging up the
second B
channel.

I know if there is a speed mismatch the line will drop after about a 20
second
connection.  Does not even bother to do the CHAP before failing.

I ran into this again last week because I had a finger check in a copy paste
of
configurations.  One side I had the statement 'speed 56' in the dialer map
statement and
not in the other.  Removed it and everything worked.

Try adding the statement speed 56 on both sides to see if this helps.

The US seems to have more of a problem with needing to set the speed to 56
than anywhere
else.

Jim

Sam Deckert wrote:

> Here is the debug isdn events output from when the 1700 disconnects:
>
> clarendon2-gw#
> 04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
> 04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is
DATA,
> b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
> 04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
0353324231
> clarendon, call lasted 20 seconds
> 04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> 04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
> 04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
>
> Here is the debug isdn events output from the 2611 side of things:
> 05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
> 05:12:30064771072: ISDN BR0/1: Event:  Call to  was hung up.
> 05:12:32225367716: ISDN BR0/1: process_disc_ack(): call id 0x25, ces 1,
call
> type DATA
> 05:12:30906921739: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
from
> unknown , call lasted 20 seconds
> 05:12:3871552: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
down
> 05:12:3862421: ISDN BR0/1: received HOST_DISCONNECT_ACK call_id 0x25
> 05:12:30064771072: ISDN BR0/1: HOST_DISCONNECT_ACK: call type is DATA
>
> I am still working on it!  Thought it might be the fast-idle timer, so made
> it
> a large value, to no avail.
>
> Thanks again if anyone can help!
>
> Sam.
>
> - Original Message -
> From: Sam Deckert
> To: [EMAIL PROTECTED]
> Sent: Monday, July 02, 2001 3:09 PM
> Subject: ISDN B Channel Disconnecting
>
> Hello everyone,
>
> I am having a bit of an ISDN related problem at the moment and was
wondering
> if anyone is able to help.
>
> I am connecting two sites together via 128k isdn, with one site having a
2611
> and the other a 1700.
>
> I have the two sites permanently connected fine with the first B channel,
> however whenever I issue the "dialer load-threshold 1 either" command one
> each
> router to always have the 2nd B channel up, the second B channel connects
and
> remains connected for 20 seconds exactly before disconnecting.  The 1st B
> channel remains connected regardless.
>
> I have tried changing the idle-timeout values to no avail, and just cant
> figure it out.
>
> I guess it is probably something simple, but just cant work it out.
>
> Here is the BRI config of the 2611:
>
> username clarendon2-gw password 7 094E1B040D0210
> !
> hostname clarendon
> ip subnet-zero
> no ip finger
> !
> ipx routing 0030.854f.c9e0
> ipx gns-response-delay 1500
> isdn switch-type basic-net3
> !
> !
> interface BRI0/1
>  ip unnumbered BRI0/0
>  encapsulation ppp
>  no ip mroute-cache
>  dialer idle-timeout 200
>  dialer enable-timeout 5
>  dialer wait-for-carrier-time 15
>  dialer map ip xxx.xxx.xxx.xxx name clarendon2-gw broadcast
>  dialer map ipx FEEDBEEF.0002.1761.29dd name clarendon2-gw broadcast
>  dialer load-threshold 1 either
>  dialer-group 1
>  ipx network FEEDBEEF
>  no ipx route-cache
>  ipx watchdog-spoof
>  isdn switch-type basic-net3
>  isdn calling-number 
>  no fair-queue
>  compress stac
>  no cdp enable
>  ppp authentication chap
>  ppp multilink
> !
> dialer-list 1 protocol ip permit
> dialer-list 1 protocol ipx permit
> no cdp run
>
> Here is the config of the 1700:
>
> hostname clarendon2-gw
> !
> username clarendon password 7 011153094F0C01
> !
> !
> ipx routing 0002.1761.29dd
> ipx gns-response-delay 1500
> isdn switch-type basic-net3
> !
> interface BRI0
>  ip unnumbered FastEthernet0
>  encapsulation ppp
>  dialer idle-timeout 200
>  dialer map ip xxx.xxx.xxx.xxx name clarendon broadcast
>  dialer load-threshold 1 either
>  dialer-group 1
>  ipx network FEEDBEEF
>  no ipx route-cache
>  ipx watchdog-spoof
>  isdn switch-type basic-net3
>  no fair-queue
>  compress stac
>  no cdp enable
>  ppp authentication chap
>  ppp multilink
> !
> ip classless
> no ip http server
> !
> dialer-list 1 protocol ip permit
> dialer-list 1 protocol ipx permit
> no cdp run
> !
> no scheduler allocate
> end
>
> What do you think???  Any advice, suggestions welcome and most appreciated!
>
> Thanks...
>
> Sam.




Message Posted at:
http://www.groupstudy.com/f

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread Jim Barksdale 

Forgot one part...id it is only the second B channel you are having problems
with...
make sure the carrier has both channels set to handle data.  They can set
the voice/data
parameters differently for each B channel.

Jim

Sam Deckert wrote:

> Here is the debug isdn events output from when the 1700 disconnects:
>
> clarendon2-gw#
> 04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
> 04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is
DATA,
> b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
> 04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
0353324231
> clarendon, call lasted 20 seconds
> 04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> 04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
> 04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
>
> Here is the debug isdn events output from the 2611 side of things:
> 05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
> 05:12:30064771072: ISDN BR0/1: Event:  Call to  was hung up.
> 05:12:32225367716: ISDN BR0/1: process_disc_ack(): call id 0x25, ces 1,
call
> type DATA
> 05:12:30906921739: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
from
> unknown , call lasted 20 seconds
> 05:12:3871552: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
down
> 05:12:3862421: ISDN BR0/1: received HOST_DISCONNECT_ACK call_id 0x25
> 05:12:30064771072: ISDN BR0/1: HOST_DISCONNECT_ACK: call type is DATA
>
> I am still working on it!  Thought it might be the fast-idle timer, so made
> it
> a large value, to no avail.
>
> Thanks again if anyone can help!
>
> Sam.
>
> - Original Message -
> From: Sam Deckert
> To: [EMAIL PROTECTED]
> Sent: Monday, July 02, 2001 3:09 PM
> Subject: ISDN B Channel Disconnecting
>
> Hello everyone,
>
> I am having a bit of an ISDN related problem at the moment and was
wondering
> if anyone is able to help.
>
> I am connecting two sites together via 128k isdn, with one site having a
2611
> and the other a 1700.
>
> I have the two sites permanently connected fine with the first B channel,
> however whenever I issue the "dialer load-threshold 1 either" command one
> each
> router to always have the 2nd B channel up, the second B channel connects
and
> remains connected for 20 seconds exactly before disconnecting.  The 1st B
> channel remains connected regardless.
>
> I have tried changing the idle-timeout values to no avail, and just cant
> figure it out.
>
> I guess it is probably something simple, but just cant work it out.
>
> Here is the BRI config of the 2611:
>
> username clarendon2-gw password 7 094E1B040D0210
> !
> hostname clarendon
> ip subnet-zero
> no ip finger
> !
> ipx routing 0030.854f.c9e0
> ipx gns-response-delay 1500
> isdn switch-type basic-net3
> !
> !
> interface BRI0/1
>  ip unnumbered BRI0/0
>  encapsulation ppp
>  no ip mroute-cache
>  dialer idle-timeout 200
>  dialer enable-timeout 5
>  dialer wait-for-carrier-time 15
>  dialer map ip xxx.xxx.xxx.xxx name clarendon2-gw broadcast
>  dialer map ipx FEEDBEEF.0002.1761.29dd name clarendon2-gw broadcast
>  dialer load-threshold 1 either
>  dialer-group 1
>  ipx network FEEDBEEF
>  no ipx route-cache
>  ipx watchdog-spoof
>  isdn switch-type basic-net3
>  isdn calling-number 
>  no fair-queue
>  compress stac
>  no cdp enable
>  ppp authentication chap
>  ppp multilink
> !
> dialer-list 1 protocol ip permit
> dialer-list 1 protocol ipx permit
> no cdp run
>
> Here is the config of the 1700:
>
> hostname clarendon2-gw
> !
> username clarendon password 7 011153094F0C01
> !
> !
> ipx routing 0002.1761.29dd
> ipx gns-response-delay 1500
> isdn switch-type basic-net3
> !
> interface BRI0
>  ip unnumbered FastEthernet0
>  encapsulation ppp
>  dialer idle-timeout 200
>  dialer map ip xxx.xxx.xxx.xxx name clarendon broadcast
>  dialer load-threshold 1 either
>  dialer-group 1
>  ipx network FEEDBEEF
>  no ipx route-cache
>  ipx watchdog-spoof
>  isdn switch-type basic-net3
>  no fair-queue
>  compress stac
>  no cdp enable
>  ppp authentication chap
>  ppp multilink
> !
> ip classless
> no ip http server
> !
> dialer-list 1 protocol ip permit
> dialer-list 1 protocol ipx permit
> no cdp run
> !
> no scheduler allocate
> end
>
> What do you think???  Any advice, suggestions welcome and most appreciated!
>
> Thanks...
>
> Sam.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=10672&t=10596
--
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread Sam Deckert 

Thanks Alex, but I already have an idle-timer value of over 2 million
seconds as well as the load-threshold set to 1.

As Tony pointed out earlier, it appears from the debugs to be a problem
during the LCP negotiation phase, prior to even attempting to authenticate
with CHAP.

Here is some of the debug output, showing what I mean.  This is the calling
1700 router output:

05:31:180388626431: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
05:31:178241142757: BR0:2 PPP: Treating connection as a callout
05:31:178247820600: BR0:2 PPP: Phase is ESTABLISHING, Active Open
05:31:176093659168: BR0:2 LCP: O CONFREQ [Closed] id 55 len 35
05:31:180388626431: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
05:31:176093659136: BR0:2 LCP:MagicNumber 0x03470C22 (0x050603470C22)
05:31:176093659136: BR0:2 LCP:MRRU 1524 (0x110405F4)
05:31:176093659136: BR0:2 LCP:EndpointDisc 1 Local
(0x131001636C6172656E646F6E322D6777)
05:31:42: BR0:2 LCP: I CONFREQ [REQsent] id 55 len 31
05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
05:31:42: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
05:31:42: BR0:2 LCP: O CONFACK [REQsent] id 55 len 31
05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
05:31:42: BR0:2 LCP:EndpointDisc 1 Local (0x130C01636C6172656E646F6E)
05:31:43: BR0:2 LCP: TIMEout: State ACKsent


This same events occurs again, and again until 20secs are up and the line
drops.  It does not even get to the authentication phase.  I think I need to
try and figure out why it is getting a "TIMEout: State ACKsent".

Thanks for the suggestions, keep them coming!!!

Thanks again,

Sam.
- Original Message -
From: "Alex Lee" 
To: 
Sent: Tuesday, July 03, 2001 1:29 AM
Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]


> If I read it correctly, it seems the command 'dialer load-threshold 1'
will
> not bring up addtional link anymore :-
>
> Quote
> When Multilink PPP is configured and you want a multilink bundle to be
> connected indefinitely, use the dialer idle-timeout command to set a very
> high idle timer. (The dialer load-threshold 1 command no longer keeps a
> multilink bundle of n links connected indefinitely and the dialer
> load-threshold 2 command no longer keeps a multilink bundle of two links
> connected indefinitely.)
> Unquote
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/d
> ial_c/dcprt2/dcppp.htm
>
>
>
>
>
> "Sam Deckert" wrote in message ...
> >Here is the debug isdn events output from when the 1700 disconnects:
> >
> >clarendon2-gw#
> >04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
> >04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is
> DATA,
> >b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
> >04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
> 0353324231
> >clarendon, call lasted 20 seconds
> >04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> >04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> >04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to
down
> >04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> >04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> >
> >
> >Here is the debug isdn events output from the 2611 side of things:
> >05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
> >05:12:30064771072: ISDN BR0/1: Event:  Call to  was hung up.
> >05:12:32225367716: ISDN BR0/1: process_disc_ack(): call id 0x25, ces 1,
> call
> >type DATA
> >05:12:30906921739: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
> from
> >unknown , call lasted 20 seconds
> >05:12:3871552: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
> down
> >05:12:3862421: ISDN BR0/1: received HOST_DISCONNECT_ACK call_id 0x25
> >05:12:30064771072: ISDN BR0/1: HOST_DISCONNECT_ACK: call type is DATA
> >
> >I am still working on it!  Thought it might be the fast-idle timer, so
made
> >it
> >a large value, to no avail.
> >
> >Thanks again if anyone can help!
> >
> >Sam.
> >
> >
> >- Original Message -
> >From: Sam Deckert
> >To: [EMAIL PROTECTED]
> >Sent: Monday, July 02, 2001 3:09 PM
> >Subject: ISDN B Channel Disconnecting
> >
> >
> >Hello everyone,
> >
> >I am having a bit of an ISDN related problem at the moment and was
> wondering
> >if anyone is able

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread [EMAIL PROTECTED] 

This looks like similar symptoms to a bug I came across a while ago.
CONFREQs sent by one end and completely ignored by the other.  I was using
different hardware though, so it may be something completely different :-)
As Tony says, strip the configs down to the bare essentials.  In my case
the thing that caused it to break was the combination of priority queueing
and ppp multilink - either by itself was OK.
If stripping it down to bare essentials doesn't work, or it breaks when you
put back something you need, you might have to look at an IOS upgrade.

JMcL
-- Forwarded by Jenny Mcleod/NSO/CSDA on 03/07/2001
09:11 am ---


"Tony Medeiros" @groupstudy.com on 02/07/2001 06:20:08
pm

Please respond to "Tony Medeiros" 

Sent by:  [EMAIL PROTECTED]



To:   [EMAIL PROTECTED]
cc:


Subject:  Re: ISDN B Channel Disconnecting Cont... [7:10596]


It now looks like it's dying at the LCP phase.  I would try and remove stac
compression and see if that works.  stac maybe incompatable with MLPPP.
Then, if that doesn't help, Try and get rid of "isdn calling number".  That
is a fluky command that doesn't work right unless CLID is sent from the
telco.  I have had lousy luck with that command.

Keep trying to "simplify " your config untill it works.   Then add more
complexity and see where it breaks.

Ain't dial a Bitch ???  Seems like I always have to fight to get it to work
right.  Thank God for debugs !!

Tony M.
#6172
- Original Message -
From: Sam Deckert
To:
Sent: Monday, July 02, 2001 12:12 AM
Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]


> I just did a debug ppp error on both routers when dialling in, however
did
> not have anything come up - so not sure if the problem is with ppp.
Bugger!
>
> Here was the output:
>
> 1700 (calling):
> 05:51:64424509440: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
> 05:51:35: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
0353324231
> clarendon, call lasted 20 seconds
> 05:51:150323855364: %LINK-3-UPDOWN: Interface BRI0:2, changed state to
down
>
> 2611 (called):
> 06:48:11: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to up
> 06:48:133143986184: %ISDN-6-DISCONNECT: Interface BRI0/1:2  disconnected
> from unknown , call lasted 20 seconds
> 06:48:135302086656: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to
> down
>
> - Original Message -
> From: "Sam Deckert"
> To: "Tony Medeiros" ;
> Sent: Monday, July 02, 2001 4:54 PM
> Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]
>
>
> > Thanks Tony,
> >
> > I thought that the ppp authentication was going ok, as the first
channel
> is
> > always connected, however it is only the second channel that is
> disconnected
> > after 20 secs.
> >
> > I was looking at the output from the debug commands you suggested, and
saw
> > the following on the router being called:
> >
> > 06:28:36: BR0/1:2 PPP: Phase is ESTABLISHING, Passive Open
> > 06:28:36: BR0/1:2 LCP: State is Listen
> > 06:28:38: BR0/1:2 LCP: TIMEout: State Listen
> >
> > Does this mean that the router being called is listening for the first
> > authentication from the client, however times out?  I guess what could
be
> > happening is that CHAP disconnects the call after 20secs of attempting
to
> > challenge???
> >
> > Here is the output from "debug PPP authen" and "debug PPP negotiation"
on
> > each router though.  Pease let me know if you see anything funny - I am
> > searching on CCO to try and find out
> >
> > Sam.
> >
> > 1700 (calling) router:
> >
> > 05:31:180388626431: %LINK-3-UPDOWN: Interface BRI0:2, changed state to
up
> > 05:31:178241142757: BR0:2 PPP: Treating connection as a callout
> > 05:31:178247820600: BR0:2 PPP: Phase is ESTABLISHING, Active Open
> > 05:31:176093659168: BR0:2 LCP: O CONFREQ [Closed] id 55 len 35
> > 05:31:180388626431: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:176093659136: BR0:2 LCP:MagicNumber 0x03470C22
(0x050603470C22)
> > 05:31:176093659136: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05:31:176093659136: BR0:2 LCP:EndpointDisc 1 Local
> > (0x131001636C6172656E646F6E322D6777)
> > 05:31:42: BR0:2 LCP: I CONFREQ [REQsent] id 55 len 31
> > 05:31:42: BR0:2 LCP:AuthProto CHAP (0x0305C22305)
> > 05:31:42: BR0:2 LCP:MagicNumber 0x31E921E3 (0x050631E921E3)
> > 05:31:42: BR0:2 LCP:MRRU 1524 (0x110405F4)
> > 05:31:42: BR0:2 LCP:EndpointDisc 1 Local
(0x130C01636C6172656E646F6E)
> > 05:31:42: BR0:2 LCP: O CONFACK [REQsent] id 55 len 31
> > 05:31:42: BR0:2 LCP:Aut

Re: ISDN B Channel Disconnecting Cont... [7:10596]

2001-07-02 Thread Sam Deckert 

Thanks for you help, Jim.

I will try setting both sides to 56, however I have verified that it does
not appear to be a speed mismatch between the routers with the "debug q931"
output.  Although I guess it could still be that the telco only provisioned
a 56k line?  But the other B channel is connected fine at 64k.

Anyway, I'll include the debug q931 output from both routers, and see what
you think.  I found that each router is sending to the other a Bearer
Capability of i = 0x8890 which according to CCO, is 64k.

Also, according to CCO the problem does not appear to be at the q931 layer,
as a CONNECT_ACK is received by both routers.  It also suggests that when
the cause of the disconnection is "Cause i = 0x8090 - Normal call clearing",
as it is in this case, it is usually a problem with a higher layer.  I think
I might be slowly getting there (optimist!).

Thanks again for any help and further suggestions you might have.  From
this, do you still think I should try setting both ends to 56k??  I am in
Australia, if that helps!

Also - to give you some more background on the issue, this setup is about 1
month old.  It was working fine with both channels up at 128k, then after
about a week the second channel just started disconnecting every 20secs.
The IT guy that normally looks after the routers is on holidays, and cant be
contacted to determine whether he changed anything.  What possible problems
could it be if this was caused by the Telco?  Keep in mind that the first B
channel is up fine and does not disconnect

Thanks again for all your help!

Sam.

Here is the debug q931 output from the 1720 (calling) router:
06:21:236223201963: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x23
06:21:238379534836: Bearer Capability i = 0x8890
06:21:236223201280: Channel ID i = 0x83
06:21:236223201280: Called Party Number i = 0x80, '0353324231',
Plan:Unknown, Type:Unknown
06:21:55: ISDN BR0: RX   CONNECT_ACK pd = 8  callref = 0x23
06:21:246967297336: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
06:22:17: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from 0353324231
clarendon, call lasted 20 seconds
06:22:7301032: ISDN BR0: TX ->  DISCONNECT pd = 8  callref = 0x23
06:22:75170777588: Cause i = 0x8090 - Normal call clearing
06:22:17: ISDN BR0: RX   RELEASE_COMP pd = 8  callref = 0x23
06:22:7301036: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down


Here is the debug q931 output from the 2611 (called) router:
07:18:52: ISDN BR0/1: RX 
on B2 at 64 Kb/s
07:18:227633266687: ISDN BR0/1: TX ->  CALL_PROC pd = 8  callref = 0xD6
07:18:225498880444: Channel ID i = 0x8A
07:18:52: %LINK-3-UPDOWN: Interface BRI0/1:2, changed state to up
07:18:223338299392: ISDN BR0/1: TX ->  CONNECT pd = 8  callref = 0xD6
07:18:52: ISDN BR0/1: RX   RELEASE pd = 8  callref = 0xD6
07:19:57995155900: Cause i = 0x8090 - Normal call clearing
07:19:13: ISDN BR0/1: RX 
To: 
Sent: Tuesday, July 03, 2001 2:50 AM
Subject: Re: ISDN B Channel Disconnecting Cont... [7:10596]


> I'm not sure if this will help since the problem seems to be brnging up
the
> second B
> channel.
>
> I know if there is a speed mismatch the line will drop after about a 20
> second
> connection.  Does not even bother to do the CHAP before failing.
>
> I ran into this again last week because I had a finger check in a copy
paste
> of
> configurations.  One side I had the statement 'speed 56' in the dialer map
> statement and
> not in the other.  Removed it and everything worked.
>
> Try adding the statement speed 56 on both sides to see if this helps.
>
> The US seems to have more of a problem with needing to set the speed to 56
> than anywhere
> else.
>
> Jim
>
> Sam Deckert wrote:
>
> > Here is the debug isdn events output from when the 1700 disconnects:
> >
> > clarendon2-gw#
> > 04:14:10: ISDN BR0: Event: Hangup call to call id 0x801E
> > 04:14:10: ISDN BR0: process_disconnect(): call id 0x801E, call type is
> DATA,
> > b_idb 0x809D7DF8, ces 1, cause Normal call clearing(0x10)
> > 04:14:10: %ISDN-6-DISCONNECT: Interface BRI0:2  disconnected from
> 0353324231
> > clarendon, call lasted 20 seconds
> > 04:14:49400989532: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> > 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> > 04:14:47244640267: %LINK-3-UPDOWN: Interface BRI0:2, changed state to
down
> > 04:14:49398792589: ISDN BR0: received HOST_DISCONNECT_ACK call_id 0x801E
> > 04:14:47244640256: ISDN BR0: HOST_DISCONNECT_ACK: call type is DATA
> >
> > Here is the debug isdn events output from the 2611 side of things:
> > 05:12:32225367844: ISDN BR0/1: received HOST_DISCONNECT call_id 0x25
> > 05:12:30064771072: ISDN BR0/1: Event:  Call t