From: Andy (trung@vnsystem.net)
Date: Thu Jun 02 2005 - 13:36:57 GMT-3
Hi Tom,
I'm using a isdn simulator for lab purpose only ;-)
With your guide, i finally understand what happend with my configuration
before.
The isdn sim doesn't pass the reject to client and that's why the client
keep holding the call and wait for carrier timeout. For this reason, server
side fails to make a callback because there's no more channel available. So
when i change the wait-for-carrier timeout to 15s, the client clears the
call right after this timer expires and at the same time it receive call
setup (callback) from server. -> callback completes successully
05:02:27: ISDN BR0: TX -> DISCONNECT pd = 8 callref = 0x0D
05:02:27: Cause i = 0x8090 - Normal call clearing
05:02:27: ISDN BR0: RX <- SETUP pd = 8 callref = 0x08
Thank you Tom for giving me a light at the end of tunnel.
Your guide was extremely helpful for me.
Sincerely,
Andy.
----- Original Message -----
From: "Tom Lijnse" <Tom.Lijnse@globalknowledge.nl>
To: "Andy" <trung@vnsystem.net>; "john matijevic" <matijevi@bellsouth.net>;
"mani poopal" <mani_ccie@yahoo.com>; "ccie2be" <ccie2be@nyc.rr.com>; "Chuck
South" <cciesouth@bellsouth.net>; "Cisco certification"
<ccielab@groupstudy.com>
Sent: Thursday, June 02, 2005 6:25 PM
Subject: RE: Re Re: ISDN callback/dialer load-threshold.
Hi Andy,
This post crossed my previous post, so maybe that has already answered
your question. I have personally never gotten consistent results with
the 'dialer wait-for-carrier' timer, so that's why I personally prefer
tuning the enable-timeout in general.
Looking at your debugs I see a couple of strange things though.
Let's strip the debugs to the bare essentials:
On client
R6#
05:02:12: BR0 DDR: Attempting to dial 888111
05:02:12: ISDN BR0: TX -> SETUP pd = 8 callref = 0x0D
05:02:12: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x8D
R6# <---------waiting for 15 seconds--------------->
05:02:27: BRI0: wait for isdn carrier timeout, call id=0x800D
05:02:27: ISDN BR0: TX -> DISCONNECT pd = 8 callref = 0x0D
05:02:27: ISDN BR0: RX <- RELEASE pd = 8 callref = 0x8D
05:02:27: ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0x0D
05:02:27: ISDN BR0: RX <- SETUP pd = 8 callref = 0x08
05:02:27: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
05:02:27: ISDN BR0: TX -> CALL_PROC pd = 8 callref = 0x88
05:02:27: ISDN BR0: TX -> CONNECT pd = 8 callref = 0x88
05:02:27: ISDN BR0: RX <- CONNECT_ACK pd = 8 callref = 0x08
R6#
05:02:28: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed
state to up
--------------------------------------------------------
On Server
05:00:56: ISDN BR0: RX <- SETUP pd = 8 callref = 0x0C
05:00:56: BR0 DDR: Caller id: Callback server starting to 666111
05:00:56: ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0x8C
05:00:56: Cause i = 0x8095 - Call rejected
R8(config-if)# <---------waiting for 15 seconds--------------->
05:01:11: DDR: Callback timer expired
05:01:11: BR0 DDR: beginning callback to 666111
05:01:11: ISDN BR0: TX -> SETUP pd = 8 callref = 0x05
05:01:11: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x85
05:01:11: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x85
05:01:11: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
05:01:11: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x05
R8(config-if)#
05:01:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed
state to up
R8(config-if)#
05:01:17: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 666111
On the server side I see the RX <- SETUP come in and the server
immediately rejects the call (TX -> RELEASE_COMP). After 15 seconds
(enable-timeout) it dials back. So far, so good, no problems here.
(Apart from the fact that I would personally change the enable-timeout
to get a faster callback).
On the client side I see the TX -> SETUP go out, the switch sends a
CALL_PROC message, but then it receives no further messages from the
switch even though the server has rejected the call. That's why after 15
seconds (which is what you set your wait-for-carrier timer to) the
client decides it has been waiting long enough and disconnects the call
on its own accord (TX -> DISCONNECT).
Then it receives the callback call and all is well.
So it works, although it takes 15 seconds. Again, this could be improved
by changing the enable-timeout on the server side.
What I find a bit worrying is that the reject from the server side is
not passed along by the switch to the client side. What kind of ISDN
switch are you using? Is this a real switch? Or some emulator?
Hope this helps,
Tom Lijnse
CCIE #11031
Global Knowledge
P.S. Regarding the reference to CCIE Practical Studies. To start with
they are discussing PPP callback, not d-channel callback. But even then,
what they're trying to say is that the wait-for-carrier on the client
side should always be longer than the enable-timeout on the server side
to make sure that the client will not dial again before the server gets
a chance to call back. This especially makes sense in your particular
case, as the wait-for-carrier only seems to kick in when you don't
receive a disconnect from the switch. That's probably also why it never
worked for me as I do get all the messages passed back to the client by
the switch.
-----Original Message-----
From: Andy [mailto:trung@vnsystem.net]
Sent: donderdag 2 juni 2005 12:33
To: Tom Lijnse; john matijevic; mani poopal; ccie2be; Chuck South; Cisco
certification
Subject: RE: Re Re: ISDN callback/dialer load-threshold.
Hi Tom,
I do debug isdn q931 command on bold router as you recommended and i
realize
the problem from this line:
04:20:07: BRI0: wait for isdn carrier timeout, call id=0x8003
So i think the server side can't make a callback because of its attempt
is
timed out before the wait-for-carrier-time at client expires. With that
thought in mind, i change the Wait for carrier from default value (30
secs)
to 15s which is equal to the dialer enable-timeout on server side and
ping
callback server from client:
R6#p 10.0.0.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
R6#
Wow, that works.
Then i try again with debug q931
On client
R6#
05:02:12: BR0 DDR: Dialing cause ip (s=10.0.0.6, d=10.0.0.8)
05:02:12: BR0 DDR: Attempting to dial 888111
05:02:12: ISDN BR0: TX -> SETUP pd = 8 callref = 0x0D
05:02:12: Bearer Capability i = 0x8890
05:02:12: Channel ID i = 0x83
05:02:12: Keypad Facility i = '888111'
05:02:12: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x8D
05:02:12: Channel ID i = 0x89
R6# <---------waiting for 15 seconds--------------->
05:02:27: BRI0: wait for isdn carrier timeout, call id=0x800D
05:02:27: ISDN BR0: TX -> DISCONNECT pd = 8 callref = 0x0D
05:02:27: Cause i = 0x8090 - Normal call clearing
05:02:27: ISDN BR0: RX <- RELEASE pd = 8 callref = 0x8D
05:02:27: ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0x0D
05:02:27: ISDN BR0: RX <- SETUP pd = 8 callref = 0x08
05:02:27: Sending Complete
05:02:27: Bearer Capability i = 0x8890
05:02:27: Channel ID i = 0x89
05:02:27: ENDPOINT IDent i = 0xFF83
05:02:27: Calling Party Number i = 0x80, '888111', Plan:Unknown,
Type:Unknown
05:02:27: Called Party Number i = 0xA1, '666111', Plan:ISDN,
Type:National
05:02:27: Low Layer Compat i = 0x8890
05:02:27: ISDN BR0: llc valid, speed 64, call type is DATA
speed:-1 async:Y
05:02:27: ISDN BR0: Event: Received a DATA call from 888111 on B1 at 64
Kb/s
05:02:27: ISDN BR0: Event: Accepting the call id 0xD
05:02:27: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
05:02:27: ISDN BR0: TX -> CALL_PROC pd = 8 callref = 0x88
05:02:27: Channel ID i = 0x89
05:02:27: ISDN BR0: TX -> CONNECT pd = 8 callref = 0x88
05:02:27: Channel ID i = 0x89
05:02:27: ISDN BR0: RX <- CONNECT_ACK pd = 8 callref = 0x08
05:02:27: BR0:1 DDR: dialer protocol up
R6#
05:02:28: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed
state to up
--------------------------------------------------------
On Server
05:00:56: ISDN BR0: RX <- SETUP pd = 8 callref = 0x0C
05:00:56: Sending Complete
05:00:56: Bearer Capability i = 0x8890
05:00:56: Channel ID i = 0x89
05:00:56: ENDPOINT IDent i = 0xFF82
05:00:56: Calling Party Number i = 0x80, '666111', Plan:Unknown,
Type:Unknown
05:00:56: Called Party Number i = 0xA1, '888111', Plan:ISDN,
Type:National
05:00:56: Low Layer Compat i = 0x8890
05:00:56: ISDN BR0: llc valid, speed 64, call type is DATA
speed:0 async:N
05:00:56: ISDN BR0: Event: Received a DATA call from 666111 on B1 at 64
Kb/s
05:00:56: ISDN BR0: Event: Accepting the call id 0xD
R8(config-if)#
05:00:56: BR0 DDR: Caller id: Callback server starting to 666111
05:00:56: ISDN BR0: TX -> RELEASE_COMP pd = 8 callref = 0x8C
05:00:56: Cause i = 0x8095 - Call rejected
R8(config-if)# <---------waiting for 15 seconds--------------->
05:01:11: DDR: Callback timer expired
05:01:11: BR0 DDR: beginning callback to 666111
05:01:11: BR0 DDR: Attempting to dial 666111
05:01:11: ISDN BR0: TX -> SETUP pd = 8 callref = 0x05
05:01:11: Bearer Capability i = 0x8890
05:01:11: Channel ID i = 0x83
05:01:11: Keypad Facility i = '666111'
05:01:11: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0x85
05:01:11: Channel ID i = 0x89
05:01:11: ISDN BR0: RX <- CONNECT pd = 8 callref = 0x85
05:01:11: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
R8(config-if)#
05:01:11: DDR: Freeing callback to 666111
05:01:11: ISDN BR0: TX -> CONNECT_ACK pd = 8 callref = 0x05
05:01:11: BR0:1 DDR: dialer protocol up
R8(config-if)#
05:01:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
changed
state to up
R8(config-if)#
05:01:17: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 666111
The configuration on bold side:
R6#sr in b0
Building configuration...
Current configuration : 284 bytes
!
interface BRI0
ip address 10.0.0.6 255.255.255.0
encapsulation ppp
dialer wait-for-carrier-time 15
dialer string 888111
dialer-group 1
isdn switch-type basic-ni
isdn spid1 66612345
isdn spid2 66654321
end
R6#
---------------------
R8#sr int b0
Building configuration...
Current configuration : 237 bytes
!
interface BRI0
ip address 10.0.0.8 255.255.255.0
encapsulation ppp
dialer string 666111
dialer-group 1
isdn switch-type basic-ni
isdn spid1 88812345
isdn spid2 88854321
isdn caller 666111 callback
end
But, let take a look at CCIE Practical Studies vI p.486.
The interval set for dialer enable timeout must be less than that set
for
DDR fast call rerouting (the interval set by dialer wait-for-carrier
command). Cisco recommends setting wait-for-carrier timer on calling
side to
twice the length of the dialer enable-timeout timer on the callback
side.
So what's the point ? I don't get it.
Andy.
----- Original Message -----
From: "Tom Lijnse" <Tom.Lijnse@globalknowledge.nl>
To: "Brian Lee" <ipgirl@gmail.com>; "john matijevic"
<matijevi@bellsouth.net>; "mani poopal" <mani_ccie@yahoo.com>; "ccie2be"
<ccie2be@nyc.rr.com>; "Chuck South" <cciesouth@bellsouth.net>; "Cisco
certification" <ccielab@groupstudy.com>
Sent: Thursday, June 02, 2005 2:02 PM
Subject: RE: Re Re: ISDN callback/dialer load-threshold.
> Hi all,
>
> There's on thing I'd like to add to this discussion that may help you
> troubleshoot ISDN callback.
>
> ISDN callback is really all about the timing.
>
> When using PPP callback everything is nicely negotiated. The client
and
> server both know what's going on.
> When using ISDN D-channel callback the 'server' simply does rejects
the
> incoming call based on calling-line-id and then tries to call back.
The
> client does not really understand what's going on and will typically
try
> to dial again. You could run into issues where the callback call fails
> because all channels are in use (though in my experience that mainly
> happens when you try to combine this with multilink). So basically
when
> doing ISDN callback if you want smooth operation you may have to tune
> some of the timers to ensure that the server calls back at the right
> moment.
>
> Let's give you an example. I have the following basic configuration:
>
> On the 'client':
>
> R4#sh run int bri 1/0
> Building configuration...
>
> Current configuration : 189 bytes
> !
> interface BRI1/0
> ip address 172.16.45.4 255.255.255.0
> encapsulation ppp
> dialer map ip 172.16.45.5 name R5 65
> dialer-group 1
> isdn switch-type basic-net3
> ppp authentication chap
> end
>
> and on the 'server':
>
> R5#sh run int bri 1/0
> Building configuration...
>
> Current configuration : 214 bytes
> !
> interface BRI1/0
> ip address 172.16.45.5 255.255.255.0
> encapsulation ppp
> dialer map ip 172.16.45.4 name R4 66
> dialer-group 1
> isdn switch-type basic-net3
> isdn caller 66 callback
> ppp authentication chap
> end
>
> Now let's ping from the client while 'debug isdn q931' is turned on:
>
> R4#ping 172.16.45.5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 172.16.45.5, timeout is 2 seconds:
>
> *Mar 17 00:49:46.064: ISDN BR1/0 Q931: TX -> SETUP pd = 8 callref =
> 0x07
> Bearer Capability i = 0x8890
> Standard = CCITT
> Transer Capability = Unrestricted Digital
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0x83
> Called Party Number i = 0x80, '65'
> Plan:Unknown, Type:Unknown
> *Mar 17 00:49:46.104: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref
=
> 0x87
> Channel ID i = 0x89
> *Mar 17 00:49:46.120: ISDN BR1/0 Q931: RX <- CALL_PROC pd = 8 callref
=
> 0x87..
> *Mar 17 00:49:50.252: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8
callref
> = 0x87
> Cause i = 0x8095 - Call rejected
> Facility i = 0x91A11202011D020122300AA1053003020100820101
> - ETSI Supplementary Service, Invoke, AOC-D Charging Units: 0
> *Mar 17 00:49:50.260: ISDN BR1/0 Q931: TX -> RELEASE pd = 8 callref =
> 0x07
> Cause i = 0x8095 - Call rejected
> *Mar 17 00:49:50.288: ISDN BR1/0 Q931: RX <- RELEASE_COMP pd = 8
> callref = 0x87.
> *Mar 17 00:49:52.060: ISDN BR1/0 Q931: TX -> SETUP pd = 8 callref =
> 0x08
> Bearer Capability i = 0x8890
> Standard = CCITT
> Transer Capability = Unrestricted Digital
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0x83
> Called Party Number i = 0x80, '65'
> Plan:Unknown, Type:Unknown
> *Mar 17 00:49:52.100: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref
=
> 0x88
> Channel ID i = 0x89
> *Mar 17 00:49:52.120: ISDN BR1/0 Q931: RX <- CALL_PROC pd = 8 callref
=
> 0x88..
> Success rate is 0 percent (0/5)
> R4#
> *Mar 17 00:49:56.248: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8
callref
> = 0x88
> Cause i = 0x8095 - Call rejected
> Facility i = 0x91A11202011E020122300AA1053003020100820101
> - ETSI Supplementary Service, Invoke, AOC-D Charging Units: 0
> *Mar 17 00:49:56.256: ISDN BR1/0 Q931: TX -> RELEASE pd = 8 callref =
> 0x08
> Cause i = 0x8095 - Call rejected
> *Mar 17 00:49:56.284: ISDN BR1/0 Q931: RX <- RELEASE_COMP pd = 8
> callref = 0x88
> *Mar 17 00:50:01.352: ISDN BR1/0 Q931: RX <- SETUP pd = 8 callref =
> 0x01
> Bearer Capability i = 0x8890
> Standard = CCITT
> Transer Capability = Unrestricted Digital
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0x89
> Calling Party Number i = 0x0183, '65'
> Plan:ISDN, Type:Unknown
> Called Party Number i = 0x81, '66'
> Plan:ISDN, Type:Unknown
> *Mar 17 00:50:01.356: %LINK-3-UPDOWN: Interface BRI1/0:1, changed
state
> to up
> *Mar 17 00:50:01.360: ISDN BR1/0 Q931: TX -> CALL_PROC pd = 8 callref
=
> 0x81
> Channel ID i = 0x89
> *Mar 17 00:50:01.380: ISDN BR1/0 Q931: TX -> CONNECT pd = 8 callref =
> 0x81
> *Mar 17 00:50:01.428: ISDN BR1/0 Q931: RX <- CONNECT_ACK pd = 8
callref
> = 0x01
> Channel ID i = 0x89
> *Mar 17 00:50:02.532: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> BRI1/0:1, changed state to up
> R4#
> *Mar 17 00:50:07.360: %ISDN-6-CONNECT: Interface BRI1/0:1 is now
> connected to 65 R5
>
> As you can see the call eventually connects, but it takes about 15
> seconds before the callback call comes in (RX <- SETUP). It does work
> though eventually. You can also see that the 'client' tried to call
out
> at least two times (count the occurrences of TX -> SETUP).
>
> Now let's try to improve this. To start with I'd like to put in a bit
of
> a disclaimer. I have seen the behavior of the timers on ISDN change in
> different IOS versions and the documentation isn't really very clear
on
> them, so don't assume that the values in this example will always work
> for you. You may have to experiment a bit. But here we go:
>
> There's one timer that defaults to 15 seconds, the re-enable timer. So
> chances are that tuning this timer on the server side will improve the
> time between the incoming call and the callback. So let's set this
timer
> to 1 second on the server side:
>
> R5(config)#int bri 1/0
> R5(config-if)#dialer enable-timeout 1
>
> And try our ping from the client again:
>
> R4#ping 172.16.45.5
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 172.16.45.5, timeout is 2 seconds:
>
> *Mar 17 01:02:38.472: ISDN BR1/0 Q931: TX -> SETUP pd = 8 callref =
> 0x0C
> Bearer Capability i = 0x8890
> Standard = CCITT
> Transer Capability = Unrestricted Digital
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0x83
> Called Party Number i = 0x80, '65'
> Plan:Unknown, Type:Unknown
> *Mar 17 01:02:38.512: ISDN BR1/0 Q931: RX <- SETUP_ACK pd = 8 callref
=
> 0x8C
> Channel ID i = 0x89
> *Mar 17 01:02:38.532: ISDN BR1/0 Q931: RX <- CALL_PROC pd = 8 callref
=
> 0x8C.!!!!
> Success rate is 80 percent (4/5), round-trip min/avg/max = 32/32/32 ms
> R4#
> *Mar 17 01:02:39.760: ISDN BR1/0 Q931: RX <- SETUP pd = 8 callref =
> 0x0D
> Bearer Capability i = 0x8890
> Standard = CCITT
> Transer Capability = Unrestricted Digital
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0x8A
> Calling Party Number i = 0x0183, '65'
> Plan:ISDN, Type:Unknown
> Called Party Number i = 0x81, '66'
> Plan:ISDN, Type:Unknown
> *Mar 17 01:02:39.768: %LINK-3-UPDOWN: Interface BRI1/0:2, changed
state
> to up
> *Mar 17 01:02:39.772: ISDN BR1/0 Q931: TX -> CALL_PROC pd = 8 callref
=
> 0x8D
> Channel ID i = 0x8A
> *Mar 17 01:02:39.788: ISDN BR1/0 Q931: TX -> CONNECT pd = 8 callref =
> 0x8D
> *Mar 17 01:02:39.836: ISDN BR1/0 Q931: RX <- CONNECT_ACK pd = 8
callref
> = 0x0D
> Channel ID i = 0x8A
> *Mar 17 01:02:40.940: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> BRI1/0:2, changed state to up
> *Mar 17 01:02:42.664: ISDN BR1/0 Q931: RX <- DISCONNECT pd = 8
callref
> = 0x8C
> Cause i = 0x8095 - Call rejected
> Facility i = 0x91A112020126020122300AA1053003020100820101
> - ETSI Supplementary Service, Invoke, AOC-D Charging Units: 0
> *Mar 17 01:02:42.668: %ISDN-6-CONNECT: Interface BRI1/0:2 is now
> connected to 65 R5
> *Mar 17 01:02:42.672: ISDN BR1/0 Q931: TX -> RELEASE pd = 8 callref =
> 0x0C
> Cause i = 0x8095 - Call rejected
> *Mar 17 01:02:42.700: ISDN BR1/0 Q931: RX <- RELEASE_COMP pd = 8
> callref = 0x8C
>
> As you can see see we now only have one incoming and one outgoing
call.
> Actually the incoming call happens before the original reject even
> reaches the client.
>
> So concluding: When your ISDN callback does not work as expected, look
> at the debug isdn q931 results and see if you can spot the problem
there
> and then change timers accordingly.
>
> I hope this helps you troubleshooting ISDN d-channel callback.
>
> Regards,
>
> Tom Lijnse
>
> CCIE #11031
> Global Knowledge
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Brian Lee
> Sent: donderdag 2 juni 2005 5:22
> To: 'john matijevic'; 'mani poopal'; 'ccie2be'; 'Chuck South'; Cisco
> certification
> Subject: Re: Re Re: ISDN callback/dialer load-threshold.
>
> Andy,
> I have exactly the same problem as yours.
> I can't configure isdn callback neither over a dialer profile nor over
a
>
> BRI.
> The routers negotiates the calback (matching caller iD), they
disconect,
> the callback server attempt to call back, but the call never
establish.
> I'm still stuck on this.
>
> Brian.
>
> ----- Original Message -----
> From: "Andy" <trung@vnsystem.net>
> To: "'john matijevic'" <matijevi@bellsouth.net>; "'mani poopal'"
> <mani_ccie@yahoo.com>; "'ccie2be'" <ccie2be@nyc.rr.com>; "'Chuck
South'"
>
> <cciesouth@bellsouth.net>; <ccielab@groupstudy.com>
> Sent: Tuesday, May 31, 2005 12:24 AM
> Subject: Re Re: ISDN callback/dialer load-threshold.
>
>
>> Hi John,
>> i've tried to configure dialer profile for callback on server side,
> not
>> with ppp cmd but "dialer caller xxx callback" instead. Unfortunately
> it
>> did not work.
>> The debug dialer said the client side attempt to call, the server
side
>
>> disconnect and starting to callback but... that's all. The isdn bri
> did
>> not come up.
>> So what's the problem here ?
>>
>> TIA,
>>
>> Andy.
>>
>> ----- Original Message -----
>> From: "john matijevic" <matijevi@bellsouth.net>
>> To: "'john matijevic'" <matijevi@bellsouth.net>; "'mani poopal'"
>> <mani_ccie@yahoo.com>; "'ccie2be'" <ccie2be@nyc.rr.com>; "'Chuck
> South'"
>> <cciesouth@bellsouth.net>; <ccielab@groupstudy.com>
>> Sent: Saturday, July 31, 2004 11:02 PM
>> Subject: RE: Re: ISDN callback/dialer load-threshold.
>>
>>
>>> Hello again Mani,
>>> I have the output, I configured dialer profile on the client:
>>> r1#deb dialer
>>> Dial on demand events debugging is on
>>> r1#ping 172.16.12.2
>>>
>>> Type escape sequence to abort.
>>> Sending 5, 100-byte ICMP Echos to 172.16.12.2, timeout is 2 seconds:
>>> ....
>>> Success rate is 0 percent (0/5)
>>> r1#
>>> 01:40:43: BR0 DDR: rotor dialout [priority]
>>> 01:40:43: BR0 DDR: Dialing cause ip (s=172.16.12.1, d=172.16.12.2)
>>> 01:40:43: BR0 DDR: Attempting to dial 5552002
>>> 01:40:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
>>> 01:40:43: BR0:1: interface must be fifo queue, force fifo
>>> 01:40:43: %DIALER-6-BIND: Interface BR0:1 bound to profile Di0
>>> 01:40:43: BR0:1 DDR: Callback negotiated - waiting for server
> disconnect
>>> 01:40:43: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
>>> 01:40:43: DDR: Callback client for r2 5552002 created
>>> 01:40:43: BR0 DDR: has total 0 call(s), dial_out 0, dial_in 0
>>> 01:40:43: BR0:1 DDR: disconnecting call
>>> 01:40:43: %DIALER-6-UNBIND: Interface BR0:1 unbound from profile Di0
>>> r1#
>>> 01:40:58: BR0:1: interface must be fifo queue, force fifo
>>> 01:40:58: %DIALER-6-BIND: Interface BR0:1 bound to profile Di0
>>> 01:40:58: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
>>> r1#
>>> 01:40:59: BR0:1 DDR: dialer protocol up
>>> 01:40:59: BR0:1 DDR: Callback received from r2 5552002
>>> 01:40:59: DDR: Freeing callback to r2 5552002
>>> r1#
>>> 01:41:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
>>> changed sta
>>> to up
>>> r1#sh run int d0
>>> Building configuration...
>>>
>>> Current configuration : 206 bytes
>>> !
>>> interface Dialer0
>>> ip address 172.16.12.1 255.255.255.0
>>> encapsulation ppp
>>> dialer pool 1
>>> dialer remote-name r2
>>> dialer string 5552002
>>> dialer-group 1
>>> ppp callback request
>>> ppp authentication chap
>>> end
>>>
>>> r1#sh run int bri0
>>> Building configuration...
>>>
>>> Current configuration : 201 bytes
>>> !
>>> interface BRI0
>>> no ip address
>>> encapsulation ppp
>>> dialer pool-member 1
>>> isdn switch-type basic-5ess
>>> cdapi buffers regular 0
>>> cdapi buffers raw 0
>>> cdapi buffers large 0
>>> ppp authentication chap
>>> end
>>>
>>> r1#
>>>
>>> I can also configure it with server if you would like to see.
>>> I hope that helps you.
>>>
>>> Here is a link to dialer profiles on DocCD:
>>>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
>>> fdial_c/fnsprt5/dcdiprof.htm#1001553
>>>
>>>
>>> Sincerely,
>>>
>>> John Matijevic, CCIE #13254, MCSE, CNE, CCEA
>>> Network Consultant
>>> Hablo Espanol
>>> 305-321-6232
>>>
>>> -----Original Message-----
>>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
>>> john matijevic
>>> Sent: Saturday, July 31, 2004 11:32 AM
>>> To: 'mani poopal'; 'ccie2be'; 'Chuck South'; ccielab@groupstudy.com
>>> Subject: RE: Re: ISDN callback/dialer load-threshold.
>>>
>>> Hello Mani,
>>> I am pretty sure this can be used via Dialer profiles as well. I am
> in
>>> the process of testing it, again and will post my configuration when
>>> finished. As far as the two dialer map statements, I only had one
> dialer
>>> map statement, I also had a switch that I configure that uses one
bri
>>> number for both channels.
>>>
>>>
>>> Sincerely,
>>>
>>> John Matijevic, CCIE #13254, MCSE, CNE, CCEA
>>> Network Consultant
>>> Hablo Espanol
>>> 305-321-6232
>>> -----Original Message-----
>>> From: mani poopal [mailto:mani_ccie@yahoo.com]
>>> Sent: Saturday, July 31, 2004 11:05 AM
>>> To: ccie2be; john matijevic; 'Chuck South'; ccielab@groupstudy.com
>>> Subject: Re: Re: ISDN callback/dialer load-threshold.
>>>
>>> Hi John,
>>>
>>> Excellent reply. John now my next question, what is the equivalent
>>> command for call back in non legacy DDR,ie Dialer profiles(is it ppp
>>> callback accept on server/ppp callback request on client or some
> other
>>> commands). If members have config examples it is appreciated. In
> the
>>> Chucks ISDN example I saw only one dialer map ip statement, I think
> it
>>> shold be two statements with both dial strings(for both bri channels
> of
>>> destination, if not dialer will not bring the second channel)
>>>
>>> thanks
>>>
>>> Mani
>>>
>>>
>>> B.ENG,A+,CCNA,CCNP,CCNP-VOICE, CSS1,CNA,MCSE
>>> (416)431 9929
>>> MANI_CCIE@YAHOO.COM
>>> _____
>>>
>>> Do you Yahoo!?
>>> Yahoo!
>>>
>
<http://us.rd.yahoo.com/mail_us/taglines/50x/*http:/promotions.yahoo.com
>>> /new_mail/static/efficiency.html> Mail - 50x more storage than
other
>>> providers!
>>>
>>>
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:40 GMT-3