On 13/Mar/18 18:47, [email protected] wrote:
> Ok you’re still missing the point, let me ty with the following example. > > Now suppose we both have: > pe1-cluster-1 sending prefix X to rr1-cluster1 and rr2-cluster1 and these are > then reflecting it further to RRs in cluster2 Okay, so just to be pedantic, fully-meshed RR's don't "reflect" routes to each other (they can, but it's redundant). But I get what you're trying to say... > Now in your case: > rr1-cluster2 receives prefix X from both rr1-cluster1 and rr2cluster1 –so how > may paths will it keep? yes 2 > rr2-cluster2 receives prefix X from both rr1-cluster1 and rr2cluster1 –so how > may paths will it keep? yes 2 > > In my case: > rr1-cluster2 receives prefix X from rr1-cluster1 –so how may paths will it > keep, yes 1 > rr2-cluster2 receives prefix X from rr2-cluster1 –so how may paths will it > keep, yes 1 Yes, understood. So in our case, we are happy to hold several more paths this way within our RR infrastructure in exchange for a standard, simple configuration, i.e., a full-mesh amongst all RR's. Having to design RR's such that RR1-Cluster-A only peers with RR1-Cluster-B_Z, rinse repeat for RR2-* is just operational complexity that requires too much tracking. Running the network is hard enough as it is. We are taking full advantage of the processing and memory power we have on our x86 platforms to run our RR's. We don't have the typical constraints associated with purpose-built routers configured as RR's. It's been a long time since I had dedicated Juniper M120's running as RR's - I'm never going back to those days :-). Mark. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
