Route Reflectors

One of the big advantages of route reflectors is that you can stage your migration to them, which means that you can configure one router at a time without disrupting normal operation of the whole network.

In short, the iBGP forwarding rules are broken; route reflectors are capable of forwarding iBGP-learned routes to other iBGP peers. It is important to understand that only the routers configured as route reflectors will forward routes to other iBGP peers. Therefore, only the route reflectors need any special configuration.

Because route reflectors may be deployed throughout the network at any given time, study their implementation in parts of the network illustrated in Figure 8-1. The core will maintain a full mesh configuration as long as all the routers at its edge are route reflectors. Some parts of the network may have a two-tier route reflection structure. In general, the best way to place clusters in the network is to follow the physical topology. A router configured as a route reflector will categorize its iBGP neighbors as clients and non-clients (refer to Figure 8-4). Clients are routers that depend on the route reflector to receive internal routing information; clients do not need any type of special configuration—in fact, all they need is an iBGP session to the route reflector. A route reflector and its clients are collectively known as a cluster.

Figure 8-4 Two-Tier Route Reflector Mesh

Figure 8-4 Two-Tier Route Reflector Mesh

Figure 8-4 shows two separate clusters; each one will be covered here. Router C is a route reflector with four clients (Router I, Router G, Router E, and Router F). If both Router I and Router G have external connections, the prefixes are forwarded as follows:

1. Routers I and G receive an external route. (Assume it's for the same prefix.)

2. Both routers announce this prefix to their iBGP neighbor—Router C is their only iBGP peer.

3. Router C compares the routes and selects one best path.

4. Because it is a route reflector, Router C propagates its best path to all its other clients and non-clients. (Router A is the only non-client peering with Router C, in this case.)

Note that in Router C's case the clients don't have iBGP sessions between them. Router B is a route reflector with three fully-meshed clients. The full mesh at the client level yields two different results. First, the route reflector doesn't have to reflect the information between clients. Although you might be thinking that a fully-meshed configuration defeats the purpose of having a route reflector, it isn't true! Keep in mind that the objective is to reduce the number of iBGP peers: the clients have a full mesh, but they don't have to peer with the rest of the network! If Router H has an external connection, the prefixes are forwarded as follows:

1. Router H receives an external route, and it propagates it to all of its iBGP peers (Router D, Router E, and Router B).

2. Routers D and E don't do anything more—they follow the rules!

3. Router B will propagate the path information (if it is the best path) to its nonclients (Router A and Router X).

As a side note, if Router B were to reflect the best path back to its clients, there would be redundant information. The issue here is not the redundant information that the clients would receive but the processing that is required by the route reflector. In other words, it is recommended to have a cluster with a full mesh of clients if clients are present in a significant number or if the physical topology dictates this to be so.

Was this article helpful?

0 0

Post a comment