Internet Routing Architectures (CISCO):Handling IP Address Depletion



























Previous
Table of Contents
Next




Multihoming Scenario: Addresses Taken from One Provider
In this scenario, customers are connected to multiple providers. Customers are small enough that they need to take IP addresses from only one of their multiple providers. We will consider two ISPs, ISP1 and ISP2, and their customers: Jamesnet, Stubnet, and Lindanet. The IP address ranges for each domain, corresponding aggregate, and provider are listed in table 3-3.


Table 3-3 List of customers and corresponding providers.



Domain
Address Range
Aggregate
Provider
Address Taken From



ISP1
198.24.0.0-198.31.0.0
198.24.0.0/13

Jamesnet
198.24.0.0-198.24.15.0
198.24.0.0/20
ISP1, ISP2
ISP1

Stubnet
198.24.16.0-198.24.23.0
198.24.16.0/21
ISP1
ISP1

Lindanet
198.24.56.0-198.24.63.0
198.24.56.0/21
ISP1, ISP2
ISP1

ISP2
198.32.0.0-198.39.0.0
198.32.0.0/13




Note that Jamesnet and Lindanet are multihomed to ISP1 and ISP2 with their address ranges taken from ISP1. Stubnet is single-homed to ISP1 with an address range taken from ISP1. This is illustrated in figure 3-14.


Figure 3-14  ISP2 advertising the wrong aggregate causes black holes.
Advertising aggregates is a tricky business. Customers and ISPs have to be careful about the IP address ranges that the aggregate covers. No one is allowed to aggregate someone else's routes (proxy aggregation) unless the aggregating party is a superset of the other party or both parties are in total agreement. In the following, you will see how ISP2 can cause a routing black hole by aggregating the ranges coming from Jamesnet and Lindanet.


Troubleshooting:  Black holes that result from inappropriate aggregation of others' routes.

If ISP2 were to send an aggregate that summarizes Jamesnet and Lindanet into one update (198.24.0.0/18), then a routing black hole will occur. Stubnet, for example, which is a customer of ISP1, has an IP address space that falls inside the aggregate 198.24.0.0/18. If ISP2 were to advertise that aggregate, then traffic to Stubnet will follow the longest match and end up in ISP2. This is why ISP2 will have to specifically list each of the IP address ranges that it has in common with ISP1 on top of its own address space 198.32.0.0/13.

Figure 3-15 shows the correctly advertised aggregates. ISP2 has to advertise the aggregates from Jamesnet and Lindanet explicitly. This way, traffic advertised to Stubnet would never go to ISP2.

Figure 3-15  Correctly advertised aggregates.
Note in figure 3-15 that ISP1 is also advertising the explicit aggregates of Jamesnet and Lindanet. If ISP1 were to advertise the less-specific aggregate 198.24.0.0/13 only, all traffic toward Jamesnet and Lindanet would always follow the longest match via ISP2.

Multihoming Scenario: Addresses Taken from Different Providers
One possibility for large domains is to take addresses from different providers based on the geographic location. Consider figure 3-16. Largenet has taken its IP addresses from two different providers, ISP1 and ISP2. With this design, each provider will be able to aggregate its own address space without having to list specific ranges from the other provider. ISP1 would advertise the aggregate 198.24.0.0/13, and ISP2 would advertise the aggregate 1928.32.0.0/13. Both aggregates are supersets of an IP address block in Largenet.


Figure 3-16  Multihomed environment with addresses from different providers.
The major drawback with the design illustrated in figure 3-16 is that backup routes to multihomed organizations are not maintained. ISP2 is advertising only its block of addresses and not the block taken from ISP1. In case ISP1 has problems and the 198.24.0.0/13 is lost, traffic to Largenet destined for 198.24.0.0/20 will be affected because it is not advertised anywhere else. The same reasoning applies for Largenet's addresses taken from ISP2. If the link to ISP2 fails, accessibility of the 198.32.0.0/20 range will be impaired. To remedy this situation, ISP1 has to advertise 198.32.0.0/20 and ISP2 has to advertise 198.24.0.0/20.

Multihoming Scenario: Addresses Taken from None of the Providers
Figure 3-17 illustrates a situation in which addresses are taken from a range totally different from ISP1 or ISP2's address space. In this case, both ISP1 and ISP2 will advertise a specific aggregate (204.24.0.0/20) on top of their own ranges (198.24.0.0/13 and 198.32.0.0/13). The drawback of this method is that all routers in the Internet must have a specific route to the new range that is introduced. Too many of such instances would result in an increase in the overall routing tables.


Figure 3-17  Addresses obtained outside ISP address space.
Aggregation Recommendations
In conclusion, a domain that has been allocated a range of addresses has the sole authority for aggregation of its address space. When a domain performs aggregation, it should aggregate as much as possible without causing ambiguity such as is possible in the case of multihomed networks.

Different situations require different designs. No one specific solution can handle all cases. It is recommended that single-homed customers obtain a single contiguous prefix from the direct provider. If they change providers, a plan should be put in place to transition the addressing to the new provider's address space. For multihomed customers, address assignments should be done in a way to maximize aggregation as much as possible. In the case where aggregation impacts redundancy, redundancy should prevail even if extra networks have to be listed.
The introduction of CIDR has helped damper the explosion of global routing tables tremendously over the last few years. The Border Gateway Protocol 4 (BGP4) is the routing protocol of choice on the Internet in part because it so efficiently handles route aggregation and propagation between different autonomous systems. As this book progresses, you will see more and more examples of the importance of CIDR in controlling traffic behavior and stability.



Previous
Table of Contents
Next