While the aforementioned approach (unique IDs and vanilla iBGP in between) seems a reasonable baseline, the best way in practice depends on factors like what sort of network the the RRs serve, how much state they need to hold, whether they are on-line (do carry transit traffic) or off-line (are just pieces of standalone control-plane).
Good discussion on same/unique cluster-ID can be found in the "JUNOS Enterprise Routing" book. Some additional ideas regarding scaling RRs for large-scale mBGP/VPN installations are in the "MPLS Enabled Applications". As cluster-ID debate easily turns into a holy-war, I ask to forgive me this bit of fuel to the fire. But having been watching several networks with the same ID approach in place for years, I must tell it's fairly OK, especially if the RRs are topologically close or you don't expect the network to scale beyond a single pair of RRs. The less amount of RIB state on RRs is not only less burden to the hardware, but also a bit of troubleshooting simplicity for NOC guys. In some cases, say, if the RRs never need to forward traffic to each other, you might even want to omit the iBGP session between them. But, again, if you just want to plug and go, the mentioned approach seems to be the right start. Regars, Pavel 06.02.2013 12:17, Huan Pham wrote: > Aggree with Doug with one condition: RRs do not share cluster ID. > > If the two RRs have the same Cluster ID, then one RR does not accept routes > advertised by the other RR which it receives from its clients. It however > DOES accept routes generated by the other RR itself. > > As a best practice, keep the Cluster ID unique to maximise the redundancy. > Although clients may receive redundant routing updates, no routing loop > occurs, nor there is a loop of routing updates. > > Huan > > > On 06/02/2013, at 2:02 PM, Doug Hanks <dha...@juniper.net> wrote: > >> vanilla ibgp between the RRs would work >> >> >> On 2/5/13 6:36 PM, "Ali Sumsam" <ali+juniper...@eintellego.net> wrote: >> >>> Hi All, >>> I want to configure two RRs in my network. >>> What should be the relation between two of them? >>> I want them to send updates to each other and to the RR-Clients. >>> >>> Regards, >>> *Ali Sumsam CCIE* >>> *Network Engineer - Level 3* >>> eintellego Pty Ltd >>> a...@eintellego.net ; www.eintellego.net >>> >>> Phone: 1300 753 383 ; Fax: (+612) 8572 9954 >>> >>> Cell +61 (0)410 603 531 >>> >>> facebook.com/eintellego >>> PO Box 7726, Baulkham Hills, NSW 1755 Australia >>> >>> The Experts Who The Experts Call >>> Juniper - Cisco Brocade - IBM >>> _______________________________________________ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
