So how do we set up a backbone to use route reflectors? Well the best way to do it is to divide the backbone into multiple clusters. And we have at least one route reflector and a few clients for every cluster. In fact the standard point of presence design we see in many service provider backbones today, maps very, very nicely onto the route reflector client setup. The core routers in a point of presence will be the route reflectors and the other routers in the PoP would be the clients of the route reflectors. The route reflectors are fully meshed they're normal BGP speakers with each other. The clients in the cluster only have a relationship with the route reflector, it could be fully meshed as well and some operators do this, especially where their cluster ends up being, for example, a nationwide or region wide network. And given we're only looking at iBGP, we don't touch IS-IS, OSPF, or our IGP of choice. The IGP is unchanged, we don't need to make any modifications there, it still carries the next hop address information and any local routes needed for the network. 2 new BGP attributes are introduced with route reflectors. There's the "Originator_ID" attribute which carries the router-id of the originator of the route into the local AS. And that's created by the route reflector. And there's the "Cluster_list" attribute and that "Cluster_list" attribute is the router-id of the route reflector which reflected the prefix. And this is an interesting and nice useful way of tracking the route reflectors that the prefix is passed through on its way from source to destination. The cluster-id is the router-id by default. There's rarely any need to set the cluster-id to anything else and indeed many of the problems that operators have with deploying route reflectors is misuse of the value of the cluster-id. Now again for setting up these route reflectors, multiple route reflectors can be configured in the same cluster, but in my experience this has been quite problematic. It's fine to do it as long as the two route reflectors have a direct physical connection between each other, and in most cases this is so. But many of my experiences have been where the route reflectors are not physically directly connected to each other but have other intermediate layer 3 devices as well, which can end up causing all kinds of BGP announcement problems and lack of connectivity for devices in the network. And the way that many operators today do it is that, a client can be a member of two different clusters. And commonly today, route reflectors would be found set up in a point of presence where one core router is one route reflector for one cluster and another core router is the route reflector for the other cluster. Our diagram shows this most clearly. Point of presence 1 has two core routers, there are three clients sitting in that point of presence, it could be access routers. And you see cluster one with the red connections, and you see cluster two with the [purple] connections. These are the two overlaid route reflector clusters. And as you can see in this example with three points of presence, the core routers are the router reflectors and they are fully meshed with each other. So the benefits of the route reflector is that it solves the iBGP mesh problem. It scales linearly. You can subdivide the network into as many route reflector clusters as you wish. You can have a hierarchy of route reflector clusters. A route reflector can serve clients which are themselves route reflectors for other clients. It's very easy to migrate to this, as we'll show you in a minute. We can introduce multiple reflectors for redundancy, clients can speak to route reflectors in different clusters, and packet forwarding, most importantly is not affected. This is purely about how we distribute prefixes by iBGP. For deploying route reflectors it's really important to always follow the physical topology. And this means have a direct connection between the route reflector and its client. Not having other intermediate layer 3 devices in between them unless they're the member of the same cluster. It's really important to try and keep things as simple as possible. So a typical service provider network, PoP would have two core routers, the core routers are route reflectors for the PoP, and we have two overlaid clusters. The core routers are fully meshed iBGP. And if the core mesh ends up being too big, we can create further hierarchy, we can split the backbone into multiple regions if we have to. Now when we do a deployment, it's better to work on one cluster pair at a time. Doing an entire backbone in one maintenance outage period may not be a great idea, especially if you as the operator are new to how route reflectors function. So work in one cluster pair at a time, be comfortable with the operation, before working on other parts of the network. So in this example in the diagram, we have a network with seven routers in it and we've decided to work on routers D, E, F, and G. We'll make router D the route reflector, E, F, and G become the clients. So we set up on router D, the fact that E, F, and G are route reflector clients, have the session up and running, once those sessions are running we can remove the extra iBGP sessions that E, F, and G have with routers A, B, and C in the backbone. The migration can be done really without breaking any connectivity in the network whatsoever, but I would still recommend doing any migration like this during planned maintenance outage time rather than when the network is operating live. Configuration is very simple, every vendor has their own style of doing it. In Cisco IOS it's really one extra line on the neighbor configuration indicating that this neighbor is a "route-reflector-client".
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.