Five tips for better IP summarization

One of the most evident signs of a well-designed network is that its IP address space is well-summarized. To do this takes careful planning, foresight and some determination. Conversely, if you see a highly fragmented, disorganized address space, you can bet that network administrators are spending more time than they should managing it, that it's more difficult to troubleshoot and wastes addresses and network resources (although performance degradation from the larger routing table won't be noticeable in smaller networks).

The reasons to summarize your address space are intuitively obvious to most network administrators, and well-documented if you're not familiar with them. But despite the best intentions of many administrators, the plan goes awry somewhere. Often, the scheme just isn't robust enough. Sometimes, it's a big event, like mergers and acquisitions that create unforeseen issues. Overlapping IP migration projects are possibly the most frustrating, where a network admin starts to clean up the network, then leaves and is replaced by another network admin who has a different idea, and begins a new project. This happens a lot when a company has a high turnover rate or uses consultants.

Here are a few tips to conquer address summarization:

1. Pick a good scheme and stick with it – maybe easier said than done, but worth the effort to try
2. Resist the urge to over allocate space – too many people say "there's no way we'll ever need that many addresses!" and regret it later. If your company gets bought, you don't want to be the network admin that decided to use a /16 subnet from the 10.x network for a hundred servers. Use common sense. Keeping your space small also lessens your chances of IP conflicts when you merge with another organization that uses the same space.
3. For each site, pick an appropriately sized subnet, and then use a consistent group of addresses from that subnet (e.g. the first /24 in the subnet) for the infrastructure addresses like routed links and loopback addresses, and the rest of the subnet for user and server subnets. Separating your infrastructure addresses from your users and servers helps when you're defining firewall rules and access-lists.
4. Try to keep your geographies summarizable. This may not seem useful if all the sites have their own connection to the backbone, like an MPLS cloud, so that you get an individual route for each site anyways. However, you will probably want to configure separate NAT translations for Europe and U.S. sites. (e.g. so American users don't get the French or German version of google or yahoo) Keeping the geographies summarizable isn't just about keeping the routing table small. It potentially helps in a lot of ways.
5. Keep track of the subnets used. Too often, when subnets are no longer needed, usually after a migration, they're left out there in the configurations, and not returned to the available pool. Or, only a device or two will remain, wasting a whole subnet. Be persistent.

Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSP^TM: Secure PIX and Secure VPN Study Guide published by Sybex.