How to design a scalable IP Plan

Learn the basics of IP Plan Design, both service-based and geography-based

Share This Post

IP addresses form the backbone of any network. In fact, they define the logical position of all the devices you have. You can think of them as a roadmap of your infrastructure. Because of that, it is important to plan them carefully: if you lay the backbone carefully, your network will scale up to incredible size. If you don’t, at some point it won’t be able to grow and even collapse in the worst cases. Having a clear IP Plan means planning how to distribute IP addresses in your infrastructure. Despite its importance, having a clear IP Plan is not necessarily complex. In this article, we will see how to create and maintain one.

Of course, IP Plans are all about IP addresses. If you are not familiar with them, we have some useful articles for you. Start with plain IPv4 addressing, then check IPv4 subnetting and finally IPv6 addressing.

The IP Plan

Before creating a solid IP Plan, we need to understand one. We should not limit ourselves to understand what an IP Plan is, but also what is its purpose.

An IP Plan is a document defining the strategy to assign IP addresses. The IP Plan contains all the private and public networks your company has, and for each all the hosts contained. The plan also groups subnets into logical entities, like sites, physical locations, or countries. In other words, the IP Plan is the go-to document about the IP addresses of the company.

Why would we spend time identifying and documenting all IP addresses? Can’t we just add new ones as we need them? Having an IP plan brings several benefits, the most important being: you can always scale your infrastructure up. With a good IP Plan, if your company purchases three new offices you know you will have addressing space for them. Even if you face a merger, integrating the addresses of the purchased company will be much easier. Thus, the purpose of the IP plan is to distribute IP addresses intelligently.

Since the IP plan has a strategy, it tells you what to do when you need new addresses. From this, we know what is the most challenging task when deploying an IP plan: making it consistent. You need to define a strategy that can satisfy well current and future needs. Nonetheless, remember that IP addresses are not forever. Eventually, we will transition from IPv4 to IPv6, and then to something else. Neither IP Plans are forever, but they should last long enough: as long as the IP addresses they define exist. A solid IP Plan can easily last for 20+ years.

How to create an IP Plan

The tools

Theoretically, you could define an entire IP Plan on a piece of paper. In practice, you might want to use better tools. For small companies, using Microsoft Excel may be enough. You should prepare a few spreadsheets, one for each site ideally. On each, you can create a tab for each subnet and list all the hosts in IT, one per row. However, working with Excel poses serious constraints. First, it is hard to ensure you always have up-to-date information, in case multiple people work other infrastructure. It is also harder to maintain consistency with a template in the long run.

Fortunately, we have a much better option. The best approach is to use an IP Address Management (IPAM) software, something that is designed for that. Typically, all IPAMs come in the form of servers/appliance you can access from a web interface, much more comfortable if you have several colleagues working on the addresses. IPAMs allows you to manage allocated IP addresses and subnets, but they don’t define the strategy for allocating them. For that, you should write a clear document that explains what to do. Ideally, any network engineer reading that document, even if new to the company, should be able to assign consistent addresses to the new site or location.

If you need an IPAM in your company, you can start with GestiòIP to stay with something light and free. For bigger enterprises, you may want to check out also other products like Infoblox or BlueCat. Today, we won’t see how to use these tools. Instead, we will see how to define the strategy.

The Strategy

The initial and most important part of an IP plan is its strategy. It is a simple document, generally, a Word document or better yet a PDF, explaining how to deal with IP addresses. It lists all the different types of locations your company has or might have. For each, it indicates how to create IP addresses. Ideally, it also defines how to deal with exceptions, like pre-allocating spare networks. The plan should cover any possible case, but remain clear and concise.

What to consider in the IP Plan Strategy

When you start working on an IP Plan, you should think about the features that will matter to you. Below, a list of things you should always consider. Read the following sections, and use them to asses your situation. Write down your findings, as you will need them later on when you actually define the plan.

Site categories

A company will have multiple locations: offices, plants, kiosks, and more, depending on the business. Each location is unique, but many of them can be grouped into categories from a network perspective. For now, we will focus on the categories of “simple” sites, not considering data centers.

In the end, all sites will talk to each other in some way: they are interconnected with one another. In fact, this is probably the only thing all sites have in common. Thus, we can classify them into categories based on the connections they use to talk with the other sites. In general, you can have three types of technology for remote connectivity: MPLS, Internet, and SD-WAN. Of course, the Internet may be a VDSL line or a UTMS link, but this does not change the Layer 3 architecture. Thus, we can focus on the link type. Also consider, for the sites that do not have Internet links on-site, how will they reach the Internet?

Once you know which kind of links you have, focus on what combinations you may have in each site. For example, you could have 1 MPLS link and a plain Internet link, or dual MPLS and single Internet. List all the combinations you have or you will possibly have, and classify them as categories (e.g. “CAT-A” or “CAT-B” etc.). Once you have this clear, you can start working on the architecture inside the site.

Intra-site Architecture

Ideally, all sites should have the same addressing space, regardless of their category. This way, if you later add a new MPLS or Internet link, the IP Plan will be ready to host them both. Thus, you need to design an addressing space that can fit all the categories. Once you have clear the different categories of sites, you can start thinking about what will go inside the site.

At this point, questions are about subnet sizes and routing. Starting from the easy ones, you need to understand how much clients each site will possibly have, at most. Then, start to classify them by services: computers, meeting rooms, IP phones, servers, and so on. The greater the detail you can reach, the better. All of these groups of devices will probably constitute individual networks, forming the backend of the site.

DMZs and interactions with the provider

Once the backend is clear, start thinking about services that may be exposed to the Internet, or to other sites. If so, you will need at least one DMZ. At this point, you can also think about the routing device. Will it be your multilayer switch, firewall, or will it be on the provider? If you plan to expose services on the Internet, it must be a firewall. Once you have the Layer 3 device clear, you can start thinking if you need a routing protocol to talk with your provider. Generally, a default route for Internet is enough, but you want some control on the private network. Using a routing protocol, instead of static routes, gives your more flexibility and control – at expense of ease of use.

When designing the architecture of a site, you need to consider the worst case. Combine all the needs all sites may possibly have: you need to create an architecture that fits all sites, in any case. Depending on the IP plan you will adopt, it might be hard to add services on each site outside the original plan. Regarding the interaction with the provider, consider how many transit networks you will need. In general, you need one transit network for each service, like MPLS and Internet.

Summarization and Redistribution Boundaries

So far, so simple. Summarization and redistribution boundaries are often the scary part of an IP Plan, as they require you to know your provider’s network. Thus, you will need to talk with them to see what is feasible and what isn’t. Do that, as this can be very important if your business plans to expand, particularly through the acquisition of other companies. Of course, this is even more crucial if your company is active worldwide.

The first thing you want to consider is the propagation of routes. The simplest scenario is a flat MPLS, where all sites announce their networks and routes reach all other sites. Think carefully if this is the only thing you will possibly need, as moving away from it is not simple. Consider if you need anycast or route filtering. For example, you may want that some sites are isolated in a bubble and can talk only to each other, and not to the rest of the network. This will define how many VRFs you will need in your provider’s network. You may also want to consider SD-WAN, an overlay of DMVPN tunnels over the Internet and MPLS. Consider if you want to summarize at some boundaries, like at a regional or country level.

The details…

Once you have an idea of the high-level configuration you need, start thinking about actual details. This includes how many sites you have in each summarization boundary (region, country). Then, consider how many routes will each site advertise for each kind: global and filtered. Most providers will put hard or soft limits on the routes you can advertise on each site. Even more, they will put limits on the total routes in the MPLS as well. Try to organize technical workshops with your provider to see what they can do and what not. For example, if you need to perform route filtering see if they can filter on what you want, like route tags.

QoS and Services

At this point, we have a clear view of the geographical and logical topology of the network. Yet, we should dive deeper into the services that use the network, and what kind of quality of services they need. If your company reaches remote locations in the world, chances are the bandwidth is going to be limited. In this case, or in case of real-time applications like Voice & Video, you will probably need QoS. If you are unfamiliar with it, read this article about Quality of Service.

Basically, QoS grants different levels of network quality to different types of traffic. It may reserve some bandwidth for some traffic, delay some other, or drop something else. QoS is effective only during link saturation and can give you greats benefit if your link may get saturated, but is not saturated 100% of the time. A network device marks the traffic with its priority (the class) based on some parameters, like source or destination IP addresses or ports.

Thus, think about all the services you have in your network and what quality they need. You can generally classify them in real-time applications, business-critical applications, and best-effort applications (no quality granted). Decide how to identify the category (a common approach is based on source/destination addresses), and which device will actually define the category. Will it be you, or will it be the provider’s router? For this topic, talk with your provider to identify the best scenario. The distribution of bandwidth between applications is not important in your IP Plan. However, how you classify the categories is extremely important, especially if you do that based on IP addresses.

Besides QoS…

QoS is a feature of your network, and when dealing with it you should deal with other services as well. For example, consider if you need Policy-Based Routing and what are the scenarios for that. Then, check with your provider if they can manage to provide you the return traffic, or if you need to use some other mechanism like altering BGP attributes.

Defining the IP Plan

Ok, now you should have a clear assessment of your network. It is time to use that information to define the IP Plan. That IP Plan should contain information about several items. Just read on…

The Major networks

Always obtain your IP Plan from the 10.0.0.0/8 major. Other private networks like 192.168.0.0/16 and 172.16.0.0/12 are not big enough, no matter how small your company might be. Still, you can use them for transit networks you won’t route globally.

Now, don’t use the entire 10.0.0.0/8 network for all your sites. First, define the size of the networks each site will need, considering spares. Then, think about how many sites you will possibly need per region (summarization boundaries). After that, consider how many regions you actually need, and what are them. For example, imagine that a /22 network will cover any possible site scenario you have. If you plan to have up to 128 sites per region, you will need a /15 major network for each region. If you have four regions, like North America, South America, EMEA and Asia-Pacific, you will do everything you need from a /13 network, that contains four /15 networks. The more summarization boundaries you have, the more addressing space you will have. A good balance is having two summarization boundaries: in this case, the first level is per-site, the second is per-region.

Once you know the size of the network you need, you can allocate it from your available addressing space. This way, you will leave space for other exceptional sites that fall outside of the IP Plan, like HQ or the Data Center.

Service-based IP Plan

You can structure your IP Plan in two ways: based on the service, or based on the location. The first makes it easy to define QoS rules, the latter makes your life easy for route summarization. There is no right or wrong approach, it depends on what you care about the most.

In a service-based IP Plan, you group networks based on their category within the summarization boundary you decided. Imagine you need a VoIP network in your sites, with a /24 subnet in each. The major might be 10.10.192.0/18: London VoIP will be 10.10.192.0/24, Paris VoIP will be 10.10.193.0/24, Madrid VoIP will be 10.10.194.0/24 and so on. Of course, sites will need other networks like Printers, Wi-Fi, LAN clients and so on. Yet, and we can see this clearly for Paris, those networks won’t be contiguous to the VoIP network. Instead, you will take them from completely different majors: the Printers’ Major, the Wi-Fi’s Major and so on. You are grouping networks for their services, within the regional/summarization boundary.

A Service-based IP Plan is designed to group addresses based on their service
This plan groups addresses based on their service and usage.

With this approach, each site can potentially advertise many different networks. This means you need to consider carefully the limits the provider puts on your routes. As an advantage, since each service is grouped in a major, you can easily implement IP-based QoS. Furthermore, you can later add more services with ease, and you don’t need to allocate all services for all sites. On the other hand, summarization at the site level is almost impossible.

Geographical IP Plan

The alternative to a service-based IP plan is a geographical IP Plan. Here, the major does not group networks of the same service. Instead, it groups networks of the same site. For example, London may have a /22 network from which you can extract a /24 network for VoIP, one for Wi-Fi, one for printers and the remaining /24 to be subnetted into transit networks.

With this approach, the Wi-Fi network is contiguous to the VoIP network, but VoIP networks from different sites are not contiguous with one another. As you can tell, this makes it a little bit more complex to define an IP-based QoS policy. However, you can easily implement site-based summarization, reducing the networks you need to advertise to the provider.

Using a geographical IP Plan you group addresses based on their physical location and not on their service
A geographical IP plan groups addresses by physical or logical location, even if they are used for different services.

You can also consider using a hybrid solution. For example, you may use a geographical IP plan that excludes VoIP. Then, you deploy VoIP networks in a service-based manner. This way, you can easily deploy QoS for them.

The Datacenter

A data center is not a normal site. It should have its own addressing plan, completely different from other sites. There are several approaches to design data centers, and we would multiple dedicated articles to cover them.

Because of that, don’t use the entire 10.0.0.0/8 network for your “normal sites”. Use only the portion of it you need, so that you can later use another portion for any data center you may want to create.

Final words…

Defining an IP Plan is a complex job that requires several people with different skills and experience. Yet, this article indicates you the right direction to follow: I used these notions in the definition of world-wide-sized IP Plans. It is now up to you to dive deeper into the topics you know your company will need and prepare the best IP Plan to meet business needs.

The golden rule here is abundance. After all, private IP addresses are free and you should not fear to use them. Of course, try to not waste them, but use them as you need them. Create several spare networks, they may save you in the future! Even when defining actual networks, design them with 20-30% of free space to host future growth. If you have questions, just let me know in the comments below. I’ll be happy to read your opinions, and even include some in this article.

Picture of Alessandro Maggio

Alessandro Maggio

Project manager, critical-thinker, passionate about networking & coding. I believe that time is the most precious resource we have, and that technology can help us not to waste it. I founded ICTShore.com with the same principle: I share what I learn so that you get value from it faster than I did.
Picture of Alessandro Maggio

Alessandro Maggio

Project manager, critical-thinker, passionate about networking & coding. I believe that time is the most precious resource we have, and that technology can help us not to waste it. I founded ICTShore.com with the same principle: I share what I learn so that you get value from it faster than I did.

Alessandro Maggio

2018-12-20T16:30:48+00:00

Unspecified

Networking

Unspecified