BGP Multiple Route Reflectors
vinbuck
Member Posts: 785 ■■■■□□□□□□
Hey guys, i'm working on adding a second route reflector to an iBGP network and i'm trying to understand all the ins and outs. The topology i'm going after is similar to the network in this Cisco case study
BGP Case Studies - Cisco Systems
it's under "Multiple RRs within a Cluster" in Case Study 4.
Routers RTD and RTH are both route reflectors in the same cluster. each router in the cluster is a client of both RRs and it looks like the RRs are iBGP neighbors but not clients of each other. Is this a sound topology? This is what I would like to deploy and I've labbed it up in GNS3 but wanted design advice from someone who has deployed multiple RRs within a cluster before.
BGP Case Studies - Cisco Systems
it's under "Multiple RRs within a Cluster" in Case Study 4.
Routers RTD and RTH are both route reflectors in the same cluster. each router in the cluster is a client of both RRs and it looks like the RRs are iBGP neighbors but not clients of each other. Is this a sound topology? This is what I would like to deploy and I've labbed it up in GNS3 but wanted design advice from someone who has deployed multiple RRs within a cluster before.
Cisco was my first networking love, but my "other" router is a Mikrotik...
Comments
I recommend reading BGP Design and Implementation. It's filled with great nuggets of design recommendations.
Sounds good.
It depends on what context your talking about.
It'll stop loops when you have your inter-cluster RR's peer with each other as clients, but that's a good thing, as doing that will get you route feedback, so you need that loop mechanism, and the route feedback isn't a big deal in most cases. However, if your network is very busy, the extra control plane traffic could have a negative effect on the routers resource utilization, which can lead to instability.
Of course the downside to not making your inter-cluster RR peers is a loss of redundancy, so it's pretty much pick your poison.
All the routers are 7606 and 7609 models with RSP720 Gig processors so I would imagine the increase in control plane utilization wouldn't tax them too much. I'm more concerned about the potential for loops than I am the increase in resource utilization so i'll probably use the cluster-id in my configs. I'm using it in my GNS3 sim of this network so I may take it out and see what happens
Well, sure, in a lab, it's not going to make a difference. On a service provider backbone, it might
But generally speaking, if you peer your RR's as clients of each other, the cluster-id will act as a loop prevention mechanism, it's kind of like an internal AS_PATH attribute that way (and cluster-id length is one of the path selection tie breakers). You'll just be circling extra updates around the peers until they drop them because they see their cluster-id already in the route.
On the other hand, if you don't peer them as clients, then the iBGP split horizon rules kick in, so whatever routes you were learning from that peer, you won't get from your other peers in a non-client peering scenario.
Personally, I peer my RR's as clients, but I'm only taking feeds from two providers, and my routers are pretty beefy, and my internal backbone is relatively small.
I do want to ask you guys about an odd config line I came across. All of out iBGP clients and the exisitng RR have neighbor ebgp-multihop 255 configured. I cant see any practical use for this command within an iBGP AS. Am I missing something or did spomeone just not understand the command usage?