Multiple Regions Separated by IBGP

The AS can be divided into multiple regions, each running different and independent IGPs. Regions will be logically interconnected via a full IBGP mesh. For better redundancy, regions could also be physically interconnected in a fully meshed topology. This is illustrated in figure 8-11.

Figure 8-11  Multiple regions via IBGP.

Each region will inject its IGP routes into IBGP and would inject a default route inside the region. As a result, each region will default to the BGP border router for destinations that do not belong to the region. Border routers will carry all routes from all regions (exchanged via IBGP) and will be able to direct the traffic accordingly. Each region will be totally shielded from the instabilities of all the other regions because the internal non-BGP routers are only exposed to the routes in their respective region. In case there is need for a dynamic routing protocol to be run on top of the IBGP mesh for reachabilty between peers, a separate IGP can be used.

This design is still missing one important piece: Internet connectivity. Connecting to the Internet in this scenario needs further planning. As you can see in figure 8-11, each region is already following defaults to reach other regions. If the connection point to the Internet falls behind the BGP border router (inside the region), internal non-BGP routers will have to decide between the default to the Internet or the default to other regions. This is illustrated in figure 8-12.

Figure 8-12  Multiple conflicting defaults.

To remedy this situation, all regions should always point to the BGP border router for default, whether reaching the Internet or other regions. This would require the Internet connections to be part of the central IBGP mesh, as illustrated in figure 8-13.

Figure 8-13  Multiple regions with Internet connectivity.

Regions 1, 2, and 3 are interconnected via an IBGP mesh, which also provides Internet connectivity. Internal non-BGP routers in each region will default to the BGP border router, which contains all routes. If the destination belongs to any other region, the traffic will be directed to that region. Otherwise, the traffic will be sent to the Internet connections according to BGP policies.

This method does not have the flexibility for setting policies for each region. All regions run under the same autonomous system and cannot be easily differentiated from each other by BGP. More complex designs could utilize the "community" attribute to differentiate between regions. This could be used in conjuction with a route reflector hierarchy to create large, virtual, private networks, as you will see at the end of this chapter.

Multiple Regions Separated by EBGP

If multiple policies need to be set between regions, each region can be represented as a separate autonomous system. EBGP is run between ASs and IBGP is run within each AS. If there is a need for a dynamic routing protocol to be run for reachability between EBGP peers, a separate IGP can be used. This is illustrated in figure 8-14.

Figure 8-14  Multiple regions separated by EBGP.

This seems to be the ideal solution for connectivity. Your AS is now divided into multiple ASs, with each region represented by a separate AS number and having a preferred connection to the Internet. Each AS will inject its IGP routes into BGP to be propagated to all other regions and the Internet. Internal non-BGP routers in each region will default to the BGP routers, which contain all routes. BGP policies using local preference can be set so that BGP routers prefer the interior company links for communications between regions instead of going via the Internet for interregional connectivity. Each region will prefer its own provider for Internet connectivity; if the link to the provider fails, other providers from other regions can be used.

This design looks good on paper until you try to implement it. You will realize that registering AS numbers from the InterNIC is very difficult. AS numbers are limited and could easily be depleted if misued. Good justification is needed before you receive multiple AS numbers. Getting multiple ASs for better IGP stability is usually not a good enough justification.

Using Private AS Numbers

Using private AS numbers is another way to divide a large AS into multiple regions connected by EBGP. Regions will be running IBGP internally and interconnected via EBGP. Each IGP will be injected into BGP for interregional connectivity. Internal non-BGP routers in each region will default to the BGP routers, which contain all routes. In case a dynamic protocol is needed for the EBGP peering connectivity, a separate IGP can be run on top of EBGP.

This works well without Internet connectivity. To connect to the Internet, the private AS numbers should somehow be shielded from the outside world. This would require a more involved design. Figure 8-15 illustrates a method that can be used to remedy the situation of private ASs with Internet connectivity. environment. Figure 8-15 shows an AS that is broken into multiple private sub-ASs. Region 1 is now AS65001, region 2 is AS65002, and region 3 is AS65003. Different mutually exclusive IGPs are running in each private AS.

Figure 8-15  Private ASs in a multiprovider

To provide multiple provider connectivity, AS100 is introduced as an interconnection point between all private ASs. Note that this central AS has a legal AS number. All private ASs would EBGP peer with the central AS100 for interregional and Internet connectivity.

To prevent private AS numbers from leaking to the providers, the AS_path stripping technique discussed in Chapter 5 can be used. AS100 will strip the private AS numbers before propagating the BGP updates to the Internet providers.

In figure 8-15, AS65001 is originating prefix 192.213.16.0/24. To all other private ASs, this prefix is seen with AS_path 100 65001. When the prefix gets propagated to AS200 and AS300, the private AS number will be stripped, and the remaining AS_path would be 100. To the Internet, all your networks will be advertised as if they originated from AS100.