Route Reflectors and Peer Groups

Recall from Chapter 5, "Tuning BGP Capabilities," that a peer group is a group of BGP neighbors that shares the same routing policies. Route reflectors can be used in conjunction with peer groups only when the clients of a route reflector are fully meshed. The reasoning is as follows: in a normal situation, a router A that learns a prefix from a router B will send a WITHDRAWN message back to that router to poison that route. In other words, router A is telling B that this prefix is not reachable via A. This is to prevent a situation where A claims that a prefix is reachable via B, and B claims it is reachable via A. In a peer group, the same UPDATE or WITHDRAWN message is sent to all members of the group. In a peer group/route reflector situation, a route reflector that has learned a prefix from one of the clients and is trying to poison that route will end up withdrawing that prefix from all the other clients. Because the clients are not talking to one another via BGP, that prefix will be lost. That is why an IBGP mesh between the clients is needed for the other clients to learn that prefix directly from the source. Even with this design, the network administrator is still avoiding a full IBGP mesh between all IBGP routers in the AS and concentrating the mesh between route reflectors and clients.

With the use of peer groups, the AS design would look like rings of fully meshed BGP speakers. Route reflectors are fully meshed among each other, and clients of each route reflector are also fully meshed. Figure 8-7 illustrates such an environment; each circled area represents a distinct peer group.

Figure 8-7  Route reflectors and peer groups.

In conclusion, the route reflector concept is growing in popularity for large networks due to the fact that it is a simple approach that enables scalability without too much overhead. Migrating from a non-route reflector to a route reflector design is easy because only the route reflectors need to be modified to behave as route reflectors; all other routers would be running as usual. Routers that do not implement the route reflector behavior could be part of the AS without any loss of BGP routing information.

Confederations

Confederation [2] is another way to deal with the explosion of an IBGP mesh within an AS. As with route reflection, confederation is recommended only for cases in which the IBGP peering exceeds about 100 peering sessions per router.

---

Troubleshooting:  
Ch. 11, pp. 426-432. Confederations

---

Confederation is based on the concept that an AS can be broken into multiple sub-ASs. Inside each sub-AS, all the rules of IBGP apply. All BGP routers inside the sub-AS, for example, must be fully meshed. Because the sub-ASs each have a different AS number, external BGP must run between them. Even though EBGP is used between sub-ASs, routing inside the confederation behaves like IBGP routing in a single AS. In other words, the next hop, MED, and local preference information is preserved when crossing the sub-AS boundaries. To the outside world, a confederation looks like a single AS. Figure 8-8 illustrates an example of a confederation.

Figure 8-8  Example confederation of sub-AS constructs.

In figure 8-8, AS100 is split into two sub-ASs: AS65050 and AS65060. The AS as a whole is now one large confederation, identified by a single confederation number, 100. All the sub-ASs are shielded from the outside world and can be given any AS numbers. The numbers could be chosen from the private AS list in order not to use up any formal AS numbers.

IBGP full mesh is used within the sub-ASs, and EBGP is used between the sub-ASs, as well as between the confederation itself and outside ASs. Confederations can easily detect routing loops inside the AS because EBGP is run between sub-ASs. The AS_path list is used to detect routing updates that leave a sub-AS and try to reenter the same sub-AS. A routing update that tries to reenter a sub-AS it originated from will be detected because the sub-AS will see its own sub-AS number listed in the AS_path of the update.

The drawback with confederations is that migration from a nonconfederation to a confederation design requires major reconfiguration of the routers and a major change in the logical topology. In addition, routing through a confederation might not take an optimal path without manually setting BGP policies. Figure 8-9 illustrates this issue.

Figure 8-9  AS confederation internal and external routing.

Confederation 100 is composed of three sub-ASs: 65010, 65020, and 65030. The AS_path within confederation 100 is represented by the sequence of ASs the route has traversed all considered to be the same length, which would introduce routing suboptimality inside the AS. From the point of view of sub-AS 65030, AS_path (65010) is the same length as AS_path (65020 65010); traffic inside the confederation may take either path. Additional policies would have to be set to affect routing behavior. Local preference, for example, can be configured to make AS_path (65010) preferred over (65020 65010).

For external ASs, the confederation is a single AS, and the route taken inside the confederation is not known. This is misleading for ASs that base their routing policies on the AS_path length. To reach AS200, AS300 will most likely prefer to go via confederation 100 because the path looks shorter than the path via AS400 and AS500. In actuality, of course, confederation 100 is not the shortest path because it includes a path via three ASs, whereas the alternative (AS400 AS500) only includes two. AS300 will never know of this pitfall unless the AS100 confederation design is disclosed.

Even though routes are exchanged between sub-ASs via EBGP, all the IBGP rules still apply to have the whole AS behave as a single entity. The EBGP next hop is still carried within the AS as well as the metric and local preference values.

As far as the BGP decision algorithm, the only changes are in the way BGP routes to outside the confederation compared to how BGP routes inside the confederation. Without confederations, EBGP routes are preferred over IBGP routes. With confederations, we have introduced new types of EBGP route between the sub-ASs, called a confederation external route. BGP prefers routes in the following manner: EBGP routes to outside the confederation > confederation exterior routes > IBGP routes. This means if BGP has a choice between two paths to the same destination, one outside the confederation and one inside, BGP will pick the exterior path. If BGP has a choice between two paths to the same destination—one inside the sub-AS and one outside the sub-AS—BGP will pick the one exterior to the sub-AS. This is, of course, assuming that all other attributes are the same.