This chapter covers the following key topics:

•  Route Reflectors
A method of managing expanding mesh requirements in large ASs by using selected routers as focal points for internal BGP sessions

•  Confederations
A method of managing expanding mesh requirements in large ASs by creating sub-ASs

•  Controlling IGP Expansion
Methods of managing networks in which expansion is characterized by the use of multiple IGPs

•  Virtual Private Networks with Route Reflectors
A method of developing restricted network access, within an AS, using route reflectors

Chapter 8
Controlling Large-Scale Autonomous Systems

Autonomous systems consisting of hundreds of routing nodes can pose a serious routing management problem for network administrators. Service providers and customers each have their own set of problems when dealing with large networks. On the service provider side, the majority of routers run BGP. The IBGP mesh will grow beyond the provider's control. On the customer side, however, the majority of routers run IGPs, which also may grow beyond the customer's control.

This chapter discusses methods and techniques that can be used to better control the deployment of BGP and IGPs inside large autonomous systems. There are no absolute rules that say a provider or customer should or should not use one of the methods discussed in this chapter, or which method to prefer. Keep in mind that any new technique brings with it its own complexities. Imposing complex techniques on situations that do not really need them could hurt more than help.

Route Reflectors

In some ISP networks, the internal BGP mesh becomes quite large (more than 100 internal BGP sessions per router), which strongly suggests that some new peering mechanism be implemented. The route reflector [1] concept is based on the idea of specifying a concentration router to act as a focal point for internal BGP sessions. Multiple BGP routers can peer with a central point (the route reflector), and then multiple route reflectors peer together.

Route reflectors are only recommended for ASs with a large internal BGP mesh, on the order of more than 100 sessions per router. The route reflector concept introduces processing overhead on the concentration router and, if configured incorrectly, can cause routing loops and routing instability. As a result, route reflectors are not recommended for every topology. If it can be tolerated, a full mesh is the better solution.

---

Troubleshooting:  
Ch. 11, pp. 422-426. Route Reflectors

---

Internal Peers Without Route Reflectors

Without route reflectors, BGP speakers in an AS will have to be fully meshed. We have already discussed this behavior in this book; the following illustration is just a reminder. In figure 8-1, RTA, RTB, and RTC form an internal BGP full mesh. Each router acts as a BGP peer with the other two routers. RTA and RTB are physically connected, as are RTB and RTC. No physical connection exists between RTA and RTC.

Figure 8-1  Internal peers in mesh environment.

RTA gets an update from an external peer and will pass it on to its two internal peers, RTB and RTC. Note that even though there is no physical connectivity between RTA and RTC, RTA will manage to pass the update to RTC via the BGP peering session. RTB and RTC, in turn, will pass on the update to their external peers.

RTB will not pass on the update to RTC, because RTC is an internal peer and the update received by RTB also comes from an internal peer. Without the internal BGP session between RTA and RTC, RTC would never get the update; hence, the full mesh is necessary.

Internal Peers with Route Reflectors

The route reflector acts as a concentration point for other routers called clients. The clients peer with the route reflector and exchange routing information with it. In turn, the route reflector will pass on (reflect) the information between clients.

In figure 8-2, RTA gets an update from an external peer and passes it on to RTB. RTB is configured as a route reflector with two clients, RTA and RTC. RTB will reflect the update from client RTA to client RTC. In this configuration, a peering session between RTA and RTC is not really needed because the route reflector is propagating the BGP information to RTC.

Figure 8-2  Internal peers using a route reflector.

In an AS where routers have to build BGP sessions with too many other routers, the route reflector concept becomes very helpful and very scalable.

Naming Conventions and Rules of Operation

The route reflector is a router that can perform the route reflection function. The IBGP peers of the route reflector fall under two categories, clients and nonclients. A route reflector and its clients form a cluster. All peers of the route reflector that are not part of the cluster are non-clients. Figure 8-3 illustrates these components.

Figure 8-3  Route reflection process components.

Non-clients must be fully meshed with the route reflector and each other because they follow the basic rules of the IBGP mesh. Clients should not peer with internal speakers outside their associated cluster. As you can see, these conditions have been met for the clients and non-clients in figure 8-3.

The route reflector function is implemented only on the route reflector; all clients and non-clients are normal BGP peers that have no notion of the route reflector. Clients are only considered as such because the route reflector lists them as clients.

Any route reflector that receives multiple routes for the same destination will pick the best path based on the usual BGP decision process.The best path would be propagated inside the AS based on the following rules of operation (propagation to EBGP runs as usual):

•  If the route is received from a non-client peer, reflect to clients only.

•  If the route is received from a client peer, reflect to all non-client peers and also to client peers, except the originator of the route.

•  If the route is received from an EBGP peer, reflect to all client and non-client peers.