From: Andy Hogard (andyhogard@gmail.com)
Date: Wed Jul 30 2008 - 16:50:25 ART
Yeah thats fine, 'm not worried about the split horizon issues.
If you look at the entire scenario then the routing table of R2 is complete,
because it has got other links to the spokes apart from the frame relay.
Just the authentication part, 'cos the mentioned solution doesn't works as
proposed. I will be doing virtual templates towards the end of my day, and
trying to work it out as suggested by Thor Kopp. :)
Greets,
Andy.
On 7/31/08, John <jgarrison1@austin.rr.com> wrote:
>
> The way I see it The hub is the update source for both spoke routers and
> the spokes don't send updates to each other. Actually the spokes frame map
> has no broadcast so they can't broadcast to each other. You probably need
> to disable split-horizon on R2 to get all the routes to the spokes
> ----- Original Message ----- From: "Andy Hogard" <andyhogard@gmail.com>
> To: <ccielab@groupstudy.com>
> Sent: Wednesday, July 30, 2008 12:12 PM
> Subject: key chain over frame hub and spoke running rip!!
>
>
> Hey all,
>>
>> I have been a subscriber for this list for some time now, although this is
>> my very first post (so a bit excited about it).
>>
>> Alright here is the scenario w/o wasting any further time, I have three
>> routers, Hub R2(multipoint sub-intf) connected to spokes R5 and R6 and 'm
>> running rip as my routing protocol. Here is what the scenario wants from
>> me,
>> under rip authentication tasks, updates between R2 to R5 will use md5
>> algorithm "ipexpert_R2toR5" ..and updates between R2 to R6 will use md5
>> algorithm "ipexpert_R2toR6".
>>
>>
>> Ok, and this is what I have configured ..on R2,
>>
>> interface Serial1/1.256 multipoint
>> ip rip authe mode md5
>> ip rip authentication key RIP_KEY_FR1
>> ip address 150.50.100.2 255.255.255.0
>> frame-relay map ip 150.50.100.5 205 broadcast
>> frame-relay map ip 150.50.100.6 206 broadcast
>> exit
>>
>> key chain RIP_KEY_FR1
>> key 1
>> key-string ipexpert_R2toR5
>> key 2
>> key-string ipexpert_R2toR6
>>
>> end
>> wr
>>
>> and on R6, I have the following configured:
>>
>> int s 1/1
>> ip address 150.50.100.6 255.255.255.0
>> encapsulation frame-relay
>> no dce-terminal-timing-enable
>> no arp frame-relay
>> frame-relay map ip 150.50.100.2 602 broadcast
>> frame-relay map ip 150.50.100.5 602
>> no frame-relay inverse-arp
>> ip rip authe mode md5
>> ip rip authentication key RIP_KEY_FR1
>> exit
>>
>> key chain RIP_KEY_FR1
>> key 2
>> key-string ipexpert_R2toR6
>>
>> end
>>
>> wr
>>
>> on R5, i have the following:
>>
>> int s 1/1
>> ip address 150.50.100.5 255.255.255.0
>> encapsulation frame-relay
>> no dce-terminal-timing-enable
>> no arp frame-relay
>> frame-relay map ip 150.50.100.2 502 broadcast
>> frame-relay map ip 150.50.100.6 502
>> no frame-relay inverse-arp
>> ip rip authe mode md5
>> ip rip authentication key RIP_KEY_FR1
>> exit
>>
>> key chain RIP_KEY_FR1
>> key 1
>> key-string ipexpert_R2toR5
>>
>>
>> Ok, after having this in place I have figured that the link between R2 and
>> R6 will always get me a authentication error, as R2 will always send key 1
>> to both R5 and R6. Hence I may have to use a common key for the entire hub
>> and spoke network and have some send/accept lifetime for key 1 then when
>> its
>> expires use key 2 perhaps. Or is there a way that above config is do-able
>> with some tweaking, where in R2 will use updates using both the keys 1 and
>> 2
>> ..eh..!?
>>
>> This scenario has been taken from the ipexpert rns wb, its good that its
>> there ..sought of an eye-opener for me. But I don't think proctor guide
>> highlights this issue, instead I think they give the same config ..and all
>> should work smooth as per them, which is what makes me ponder and think
>> ..ya?!
>>
>>
>> Let your two cents flow. :D
>>
>>
>> Greets,
>> Andy.
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:58 ART