From: Paul Borghese (PAUL98@xxxxxxxxxxx)
Date: Thu Apr 13 2000 - 11:12:25 GMT-3
How about letting us post the scenarios developed by the group members to
GroupStudy.com notes section. At least give us a link on your site (hint,
hint).
Paul
-----Original Message-----
From: Derek Small (Fuse) <dwsmall@fatkid.com>
To: ccielab@groupstudy.com <ccielab@groupstudy.com>
Date: Wednesday, April 12, 2000 5:13 PM
Subject: Re: Problem with snapshot routing.
>Just an FYI for everyone. The solution that Xuping posted did solve the
>Snapshot routing problem. I'll have the completed solution up on
Fatkid.com
>in a week or two.
>
>I don't want to abuse this group, but would anyone else be interested in
>some more stuff like this (giving away time slots for solutions?) Seems
like
>it might be a win-win.
>
>Paul, any problems with this?
>
>Derek Small
>dwsmall@fatkid.com
>
>
>----- Original Message -----
>From: xuping <cnmiecxu@public.bta.net.cn>
>To: Derek Small (Fuse) <dwsmall@fatkid.com>
>Cc: <ccielab@groupstudy.com>
>Sent: Sunday, April 09, 2000 6:36 AM
>Subject: My Answer: Problem with snapshot routing.
>
>
>> >The solution for the SnapShot routing scenario is broken. The server
>> >router, R2, is not sending or receiving RIP updates when snapshot brings
>> the
>> >BRI up. What is wrong?
>> >
>> >Hint, I have removed the dialer option from the "snapshot server 5"
>command
>> >under the BRI, that didn't do it.
>>
>>
>> The option "dialer" after "snapshot server 5" is tell the snapshot
>> process by which method to learn who is the snapshot client (the peer)
>>
>> In your R2
>>
>> interface BRI0
>> ip address 172.1.4.1 255.255.255.0
>> encapsulation ppp
>> isdn spid1 0835866101 8358661
>> isdn spid2 0835866301 8358663
>> dialer idle-timeout 300
>> dialer map ip 172.1.4.2 broadcast 8358662
>> dialer load-threshold 1 either
>> dialer-group 1
>> snapshot server 5 dialer
>> no fair-queue
>> ppp multilink
>> no shutdown
>>
>> when you delete the "dialer" option, the snapshot process will have no
>idea
>> about who make the connection, the snapshot process will try to bring up
>> another connection using "dialer map ip 172.1.4.2 broadcast 8358662"
>> statement for its routing purpose instead of utilizing the already
>connected
>> channel.
>>
>> solution 1:
>> give snapshot process some other methed to identify the connection, say,
>> give dialer map a remote-connection-name, and uses chap or pap to
identify
>> the connection by connection name. like this:
>>
>> username R3 password 0 cisco
>>
>> interface BRI0
>> ip address 172.1.4.1 255.255.255.0
>> encapsulation ppp
>> isdn spid1 0835866101 8358661
>> isdn spid2 0835866301 8358663
>> dialer idle-timeout 300
>> dialer map ip 172.1.4.2 name R3 broadcast 8358662
>> dialer load-threshold 1 either
>> dialer-group 1
>> snapshot server 5
>> no fair-queue
>> ppp multilink
>> ppp auth chap
>> no shutdown
>>
>> solution 2:
>>
>> use dialer profile, unlike physical interface may defind mutiple dialer
>map
>> statement (making a physical BRI interface to be a point-to-multipoint
>> style). a dialer profile define a pure point-to-point connection (since
>> only one dialer string may defined in a dialer), snapshot process will
not
>> confused in such a enviroement.
>>
>> interface BRI0
>> no ip address
>> encapsulation ppp
>> isdn spid1 0835866101 8358661
>> isdn spid2 0835866301 8358663
>> dialer pool-member 1
>> ppp multilink
>>
>> interface Dialer 1
>> ip address 172.1.4.1 255.255.255.0
>> dialer idle-timeout 300
>> dialer remote-name R3
>> dialer pool 1
>> dialer string 8358662
>> dialer load-threshold 1 either
>> dialer-group 1
>> snapshot server 5
>> ppp multilink
>>
>> I have repeat the problem and test both configs on my test bed(with
>> defferent ISDN No.), both works.
>>
>> I suppose if your ISDN switch can send correct caller ID, your config
will
>> work without any change when delete "dialer" option.
>>
>> xuping
>> cnmiecxu@public.bta.net.cn
>>
>>
>>
>>
>>
>>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:13 GMT-3