Re: BGP RR+Peergroup

From: Ivan Harvard <ivanharvard_at_gmail.com>
Date: Fri, 9 Aug 2013 10:45:53 -0500

RFC for "First Implementation" is RFC4456
I don't think an RFC exists for "Second Implementation" ....I've been
trying to find to no much success. Please give me a reference link to
documentation for where you got this second implementation from. Thanks

On Thu, Aug 8, 2013 at 12:16 PM, routingfreak <routingfreak_at_gmail.com>wrote:

> Hi
>
> The first implementation is sending the same routes to the client who has
> originated the route and client ignores it by using Originator ID and later
> implementations dont send updates back to the client who originated it.
> There are separate RFCs for this. I dont have the numbers on top of mind.
>
>
> On Thu, Aug 8, 2013 at 1:26 AM, Ivan Harvard <ivanharvard_at_gmail.com>wrote:
>
>> Hi Guys,
>>
>> Any mechanism in place on RR to prevent sending updates to client whom it
>> received from?
>>
>> RRC1--------RR-------RRC2
>>
>> Assume RR is configured with a peer-group, to which RRC1 and RRC2 belongs
>> if RRC1 sends update to RR, is there any mechanism on RR that prevents it
>> from replicating back towards RRC1?
>>
>> I know there is a loop prevention on RRC1 in that if it sees its
>> originatorID/clusterID in the updates back from RR, RRC1 will drop it.
>> Trying to find out if there is a mechanism on RR itself that excludes RRC1
>> from the update/replication group.
>>
>> Cheers
>> Ivan
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Regards
> Routing Freak CCIE#35889 (SPv3)

Blogs and organic groups at http://www.ccie.net
Received on Fri Aug 09 2013 - 10:45:53 ART

This archive was generated by hypermail 2.2.0 : Sun Sep 01 2013 - 08:35:50 ART