We will now take a look at route reflectors. One of the issues we talked about earlier at the start of this presentation set and we hinted at during the discussion of iBGP, is how to scale the iBGP mesh. According to the specification iBGP needs to be fully meshed. For example, if we have 14 routers we have 91 iBGP sessions. If we have 1000 routers we have just short of 500,000 iBGP sessions. The more routers we have it goes up more or less N^2. In other words something that doesn't really scale very sensibly even with the modern routers and the big CPUs we have today. So what we want to try and do is avoid the N^2 scaling problem. And two solutions were generated. The first solution is the BGP confederation which we're unlikely to cover during this series. The second one is the route reflector. The route reflector is extremely commonly deployed, it's very easy to deploy, and it's very easy to run. The route reflector actually came along a few months after the BGP confederation was first introduced into operating code. We're going to look at route reflector in this section. Now iBGP works quite straightforwardly, a prefix comes from outside the AS, it lands on router B, on the diagram, and router B will send the prefix to router A and router C via the full mesh iBGP. Router A will not take the prefix it learns from B and pass it on to C, that's part of the iBGP specification. So this is the example of a simple full mesh iBGP. The way the route reflector works is if we convert router A so the prefixes it learns from B it will actually be able to pass on to C. So it's a very, very simple modification of the iBGP spec. Let router A announce prefixes to other iBGP speakers. So that's the principle, a very simple principle and let's now look at how it is actually implemented. If we look at the diagram in this slide, we will see 3 routers in the core of the network and each of the three routers has three clients. Let's focus on router A. Router A has three clients. If a prefix is originated by one of the clients, whether it comes from outside the autonomous system, or is introduced into the AS by the client itself, that prefix will be sent by normal iBGP to router A. Router A will take that prefix and send it on to the other clients. So the other two clients will receive the prefix and router A will also send it to other normal BGP speakers. So B and C in the diagram are normal iBGP speakers. If router B has a prefix that it has learned from somewhere and it will send it to A by normal iBGP, A will send this prefix onwards to its clients as well. So the diagram actually shows the iBGP setup we now have. And it could be the physical infrastructure as well but it is actually the iBGP mesh. So the route reflector specification is described in RFC4456, but the simple summary is as on the slide. Route reflector receives path from clients and non-clients. It selects the best path. If the best path is from the client, reflect other clients and non-clients. If the best path is from a non-client reflect it only to the clients. So this means that, if we go back to router A, being a route reflector for its three clients, any prefix that lands from router B will only be sent to clients, it will not be sent to other normal BGP speakers.

© 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.