Internet Routing Architectures (CISCO):Controlling Large-Scale Autonomous Systems



























Previous
Table of Contents
Next




Using Confederation to Control IGP Expansion
Confederations can also be used to control the expansion of IGPs.You have already seen how a confederation can divide the AS into multiple smaller sub-ASs. If each sub-AS is running a different IGP, then the centralized design described in would be a viable approach. The IGPs are now running independently of one another, and the whole AS is still considered as a single entity to the outside world. Each IGP will be injected into BGP for interregional connectivity. Internal non-BGP routers in each region will default to the BGP border router, which contains all routes. Internet connectivity can be provided via the central AS to provide a central default for all the different regions. This is similar to the scenario in figure 8-15.

On the negative side, confederations require extra configuration and do not provide the capability of setting policies between the sub-ASs because the whole AS is still considered one entity. Besides, any confederation design that is not centralized could introduce further complications in route optimality inside the confederation.
Virtual Private Networks with Route Reflectors
Virtual Private Networks (VPNs) are private networks in the sense that they require traffic exchange within their network boundaries and no access to or from other networks that are not part of the VPN. Providers and large enterprises are faced every day with the challenges of private data exchange. A large organization with different geographic locations, for example, serviced by a large provider, may want to restrict which regions can exchange traffic with each other. It is then the provider's duty to provide this level of privacy. Similarly, an enterprise that is a collection of smaller business units might want to implement data exchange restrictions between the units. So far, the only way to achieve this behavior is via packet filters and traffic pipes (tunnels), which protect information from being exchanged between private entities. This section attempts to find a solution to this problem using a route reflector hierarchical concept.
We will conceptualize a large AS, as shown in figure 8-16, as consisting of three hierarchical levels: customers (Level 3), distribution (Level 2), and core (Level 1). Customer, in this sense, means a unit or region that has the same data access and restriction criteria. Each distinct group of customers is served by a distinct Virtual Private Network. Figure 8-16 contains two such VPNs, VPN1 and VPN2.

Figure 8-16  Route reflector hierarchy.
Level 3 (L3), the customer level, is following a 0/0 default toward Level 2 (L2), the distribution level. At the customer level, the only routes exchanged are the ones generated locally. To reach other parts of the VPN, the customer will send its traffic toward the distribution level. The customer router is announcing its routes toward the distribution routers (L2) with a specific BGP community that is representative of its particular VPN. In figure 8-16, VPN1 is announcing its routes with a community C1, whereas VPN2 is announcing its routes with a community C2.

At Level 2, the distribution routers will receive the routing updates and will propagate (reflect) them to Level 1, the core routers. As such, the core routers will have all the VPN routes tagged with the VPN community. The core routers in turn will advertise these routes only to the distribution that can service a particular VPN. That means a distribution router that is servicing VPN1 will receive only routes that belong to VPN1. The distribution routers of VPN1 will not carry any routes of the other VPNs.
To understand the outcome of this design, consider two cases. In the first case, a customer in VPN1 is trying to access another customer in VPN1. In the second case, a customer in VPN1 is trying to access a customer not in VPN1.
In the first case, if the destination is within Level 3, the customer router would have the specific route in its routing table. If the destination is not in Level 3, the customer has no choice but to follow a 0/0 default toward Level 2. At Level 2, because the distribution router has knowledge of all VPN1 routes via the core, the distribution router will forward the traffic toward the core router. At the core, all destinations are known, and the traffic will be delivered to its destination in VPN1.
In the second case, the customer of VPN1 is trying to access a destination not inside VPN1. The traffic will follow the 0/0 default toward Level 2. At the distribution level, the routers have no knowledge of any destinations other than VPN1, and the traffic will be dropped. This will preserve the private aspects of the VPNs.
It is important to note, in this scenario, that the service provider is not providing global connectivity (Internet connectivity), but rather connectivity just among the different components of the organization (intranet connectivity). In fact, in this route reflector approach to servicing VPNs, Internet connectivity for the VPNs cannot be achieved. This is because Level 3 has to follow defaults toward the distribution and cannot follow a default toward the Internet. In addition, if Internet connectivity were provided on the distribution level, then customer traffic toward a different VPN could be rerouted to that VPN via the Internet, which defeats the purpose of VPNs. Finally, if Internet connectivity were provided via the core, then customer traffic would not be able to reach the Internet because the traffic will be dropped at the distribution router, which would not have the route in its routing table.
Given that private networks are supposed to be private, Internet connectivity might not be a requirement. For an organization that wants both VPNs and Internet connectivity, a method other than this specific hierarchical route reflector approach must be used.
Looking Ahead
You have seen so far how BGP can be a powerful tool in giving routing a more structured look. You have learned how to manipulate traffic and how to segment the AS into more controlled elements. One more aspect that needs discussion is route instabilities on the Internet. Many factors induce route fluctuations and, in turn, traffic fluctuations. Some of these elements can be avoided and some are beyond your control. The Internet has become a necessity for everyday operations; it is in your best interest to respect and protect its integrity. The following chapter discusses the causes of route instability and some of the measures taken to stop or at least dampen its effect.




Previous
Table of Contents
Next