From: Andy (trung@vnsystem.net)
Date: Thu Jun 02 2005 - 07:32:41 GMT-3
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!
>>>
>>>
> _______________________________________________________________________
>>> Please help support GroupStudy by purchasing your study materials
> from:
>>> http://shop.groupstudy.com
>>>
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
> _______________________________________________________________________
>>> Please help support GroupStudy by purchasing your study materials
> from:
>>> http://shop.groupstudy.com
>>>
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:40 GMT-3