> I would strongly advise against the previous suggestion of not running > iBGP between the routers. While the topology in particular may > function without it, the next person to come along and work on the > network may not expect it to be configured Hmm... really depends. I can easily recall scenarios, where an iBGP between RRs would increase chances of service outage.
Say, RRs are offline and don't pass traffic at all. They just don't (or rather, even must not) have any "their own" routes to attract traffic. The lack of inter-RR exchange is just an additional security (and simplicity) measure. No session means no routing-policy, no leakage of something (e. g. due to software bugs). Imagine you use RRs to inject initially static routes into the network (flowspec, blackhole, whatever). There is no reason to share this between RRs, instead, you want both reflectors to redistribute it independently. If your forget to configure these statics on both RRs (very common mistake), than, having an iBGP between them, you will still see two copies of the route in the network despite you have configured it only once. Thus you won't suspect that an RR failure will lead to a withdrawal of these routes. So I personally would recommend to filter such updates between RRs even when you have reasons for a session between them. > inconsistent with standards and best practices and may, thorough a > seemingly unrelated change in topology, break things horribly. BTW, I don't really believe there exists a common standard or best-practice prescribing to do this. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp