Figure 32 BGP Route Reflector Cluster

However, most ISPs choose to implement clusters with two route reflectors, as in Figure 3-3. This gives them redundancy in the cluster if one route reflector fails.

Figure 3-3. BGP Route-Reflector Cluster with Two Route Reflectors

Figure 3-3. BGP Route-Reflector Cluster with Two Route Reflectors

Network designers should be aware of some caveats when configuring route reflectors. As soon as a router is configured as a route reflector, it is assigned a cluster identifier automatically by the BGP process. This cluster ID is the BGP router ID, usually the loopback interface address of the router. The goal of a cluster ID is only to reduce the propagation of BGP updates between route reflectors when the same client uses multiple route reflectors. A route reflector will not accept an update coming from another route reflector that has the same ID (the ID is stored in the cluster-list attribute). This is because this update has been received already from the client (because the client peers with all route reflectors of the cluster).

Now, what if the cluster ID in both route reflectors isn't the same? In that case, a client connected to two route reflectors sends its update to both, and each route reflector sends this update to the other. The result is that they receive the same update twice. Now route reflectors act as BGP routers. When they discover that the update is exactly the same, they select just one (the one with the shortest cluster list) and propagate that one to other neighbors. There will be no routing loops because we are talking about identical updates: same net/mask, same next hop.

Some ISPs choose to change the default cluster ID to values that let them more easily identify regions/clusters in the backbone. And quite often they set the cluster

ID of the route reflectors in each PoP to be the same value. They should do so only with the purpose of the cluster ID kept in mind:

• Each client must peer with both route reflectors. Failure to do so could result in routing loops.

• The physical path from the client to the route reflector must not be through another route reflector in the cluster. Failure to adhere to this will result in a routing black hole.

Is the overhead of one extra routing update worth sacrificing for an increased risk in routing black holes because of network topology?

Note the last point: It seems to be accepted wisdom and, indeed, is often documented that the cluster ID should be the same on both route reflectors in a cluster. This is potentially dangerous and could cause more problems than leaving the status quo. (One example might be the situation in which one reflector is physically reachable from the client only through the other reflector. The best path could be valid through the cluster ID but could be unreachable.)

Finally, there is little wrong with having overlapping route-reflector clusters, as shown in Figure 3-4. Many ISPs that have installed a route-reflector hierarchy across their backbones have done so very successfully simply using the default IOS Software values for the cluster ID. The early IOS Software restriction of a route-reflector client being able to belong to only one route reflector now has been removed, so setting up clients to be members of two clusters is common practice across the Internet. If in doubt, the question to ask is this: "Is the overhead of one extra routing update worth sacrificing for an increased risk in routing black holes because of network topology?" Network topology changes on a monthly or more frequent basis in an ISP backbone, so what might have been a perfect design on the first day potentially could become a liability later.

Figure 3-4. Overlapping Route-Reflector Clusters

Figure 3-4. Overlapping Route-Reflector Clusters

cluster-id 0,0.0.2 ibgp peering cluster-id 0,0.0.1

Was this article helpful?

0 0

Post a comment