BGP Multiple Route Reflectors

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.

Find more posts tagged with

Comments

networker050184

Yes this is a sound design. I've seen it used in a large network with no problems.

Ryan82

Yep, its a good idea for redundancy. Another recommended practice would be to have a physical link between your RR's as they recommend that you do not have a IBGP peering between your RR's that is formed by traversing a RR client.

I recommend reading BGP Design and Implementation. It's filled with great nuggets of design recommendations.

Turgon

MississippiGuardsman wrote: »

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.

Sounds good.

vinbuck

What are y'alls thoughts on using the cluster-id attribute? I've read some mixed opinions about using it. Something about causing instability to the clients in certain situations.

networker050184

I've never seen any issues with it personally. The cluster-id is attached to the update so its not really a cluster without that. Its just two separate updates.

Forsaken_GA

MississippiGuardsman wrote: »

What are y'alls thoughts on using the cluster-id attribute? I've read some mixed opinions about using it. Something about causing instability to the clients in certain situations.

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.

vinbuck

Forsaken_GA wrote: »

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

Forsaken_GA

MississippiGuardsman wrote: »

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

When you're carrying full routes from multiple providers, you start to become somewhat concerned with resource utilization hehe. It's also a matter of scale - if you're peering 3 RRs as clients, no big deal. If you're peering 300.... that's an awful lot of extra control plane traffic.

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.

vinbuck

Thanks for all the replies y'all. Been really digging into RRs and how they can be used in iBGP networks. One thing that kind of suprised me is that you can split RRs for the different address families and actually have RRs for ipv4 and vpnv4 routes on different routers (that only operate on the control plane and aren't forwarding data). Needless to say, that looks more like a model for a large SP since I can't justify a lone 7609 in my design to act as just a RR let alone TWO of them

. Since this is an MPLS network that i'm working on, I did some seraching on RRs and MPLS and got much more focused results. It looks like i'm going to make every iBGP router (about 20) a client of two different RRs that are directly connected to each other (OSPF is the existing IGP to acheive connectivity for iBGP clients). I'm also going to tweak the config to use peer groups to simplify the config and reduce BGP update traffic. All in all it seems to coming together well, just have some more GNS3 testing to do before I start preps to put it into production.

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?

Ryan82

EBGP peers have a default TTL of 1, IBGP peers have a default TTL of 254. If they used the EBGP multihop command for IBGP neighbors then they obviously didn't understand its purpose.