Route reflectors will preserve all iBGP attributes, however some implementations still allow attributes to be changed or filtering to be applied. So if you peer RR’s from multiple ASs with each other using eBGP, you will still need to redistribute prefixes from ebgp into ibgp on the RRs in order to get the information exchanged to the other routers in the AS.) (Note : a RR will only reflect the routes within the same AS. And if you have more routes, you may need to reconsider the design and split up the network (AS) into smaller networks (ASs) and use eBGP to exchange information between the various networks. Of course, you can set up multiple RR’s for added redundancy (you just need to set up all clients and non-clients to peer with all RRs)… and as long as you don’t have thousands of routes exchange via BGP, the extra load should not be a big issue either. The drawbacks of using a RR are clear : the RR is now a sinle point of failure and the RR process will put somewhat more load on the router. So instead of having to configure 10 iBGP peers, you only need to set up 5 relationships. RR clients 2 and 4 only need to peer with router5 (the RR). Router 1 and 3 now only have to peer with each other and with the RR. So in other words, if we look back at the example of 5 routers, and now assume that router5 is a RR, and router 2 and 4 are RR clients, then the iBGP setup would look like this :

Non-clients still need to be configured to form a full mesh with the RR and the other iBGP speakers (but not with the other clients that are part of the RR cluster) Peers of the RR that are not part of the cluster are non-clients. The RR and the clients now form a cluster. When a host is connected to a RR, it becomes a client. Route reflectors introduce the concept of ‘clients’ and ‘non-clients’. The RR reflects the information to other BGP peers (iBGP and eBGP)

These clients peer with the RR (Route reflector) and exchange information with it. Both solutions have some drawbacks too, but we’ll talk about that when we get there.Ī route reflector is a router that acts as a hub between various iBGP clients. You can use route reflectors and confederations to decrease the number of peer relationships you need to configure and maintain. But if using iBGP is your only option, how can you make your life easier ? there are numerous reasons to consider when designing your network. Some critics might even say that using peer-groups makes it more difficult when you are using multiple route-maps.Ī lots of work, risk of making mistakes…. Nice, but using peer-groups only limits the number of lines of screenos statements, it does not defeat the full mesh requirement. If you define a route-map directly on a peer, it will take precedence over the global route-map in the peer-group. If you are using route-maps, you can either define the route-map in the peer group, and/or directly on a specific peer. So you basically need to create a peer group, set the parameters that will be applied to all peers in this group (remote-as and md5-authentication parameters) and then you define the peers into the peer group. Set neighbor 192.168.21.15 peer-group iBGPPeers Set neighbor 192.168.3.10 peer-group iBGPPeers Set neighbor 192.168.0.30 peer-group iBGPPeers Set neighbor peer-group 'iBGPPeers' md5-authentication 'iBGPTest' Set neighbor peer-group 'iBGPPeers' remote- as 65500

Bgp full mesh