Matt Schmitz/ January 3, 2017

Last week in IP Address Design (Part 1) we discussed an example of a bad design for IP allocations and the problems that it caused. This week we will continue by discussing the proposed solution and how it resolved those issues.


The problems with our IP Addressing scheme bothered me quite a lot – especially because IP Addressing design doesn’t really seem to be something you can easily go back and fix. We are in a somewhat unique case since we often open new locations, which is a perfect opportunity to make a positive change going forward. About a year ago, I heard that we would be opening four new data center locations in the near future. So I finally sat down and figured out a new scheme, which ultimately we deployed to all new locations.

My first goal was to start making more proper use of address space, while still making it somewhat easy to remember. As I stated in the last post, our largest data center was only using about 4,000 addresses. I began the design by trying to figure out a good starting point. A single /16 is probably still too large, but if I split up a /16 into two /17s then people will get confused about where a subnet lives. Remember that we were migrating from a very simple scheme in the past, where the second octet dictated the network location. So for the sake of simplicity, I started the design using a single /16 per data center.

Next, I needed to split up that /16 into classless subnets which could be routed in a somewhat meaningful fashion within the data center. In also trying to keep human usability in mind, I decided to split the main /16 assignment into two /17s. The top /17 subnet would be designated to all edge subnets, like the DMZ and Out of Band Management – both of which were directly terminated off of the external firewall set. The bottom /17 would be designated for all internal, protected subnets. This included anything behind the internal firewall set, like our primary internal network and some of the new isolated network segments we had built.

So here is the final scheme:

  • 10.15.0.0/16 – Overall data center allocation
    • 10.15.0.0/17 – Edge subnets
      • 10.15.0.0/18 – Main DMZ (10.15.0.0-10.15.63.255)
      • 10.15.64.0/21 – Out of band management (10.15.64.0-10.15.71.255)
      • 10.15.72.0/21 – Misc DMZ VLAN (10.15.72.0-10.15.79.255)
      • 10.15.80.0/20 – Unused (10.15.80.0-10.15.97.255)
    • 10.15.128.0/17 – Internal subnets
      • 10.15.128.0/18 – Main Internal subnet (10.15.128.0-10.15.191.255)
      • 10.15.192.0/22 – Protected subnet 1 (10.15.192.0-10.15.195.255)
      • 10.15.196.0/22 – Protected subnet 2 (10.15.196.0-10.15.199.255)
      • 10.15.200.0/21 – Unused (10.15.200.0-10.15.200.207.255)
      • 10.15.208.0/20 – Unused (10.15.208.0-10.15.223.255)
      • 10.15.224.0/19 – Unused (10.15.224.0-10.15.255.255)

Now the first thing you may notice is that there is a large amount of unused IP space – but I’m accepting that as potential for future growth. Even the large /18 allocations will allow for over 16,000 hosts, which may be more than we will need in the foreseeable future. However, as I mentioned earlier I needed to balance conservation and efficiency with human readability.

So how does this help some of our problems? We’ve already addressed the problem of IP exhaustion by dropping each data center to a single /16 subnet rather than several /16s. Routing tables are immensely simplified now due to summarization. Oh, I need a route to that other data center? Sure, now it is only a single /16 route to the VPN peer for that location. Once the traffic gets over to that local network, then we can worry about trying to route the individual allocations within there. Even then, within the data center I only need a handful of small routes. The external firewall can point the whole 10.15.128.0/17 subnet to the internal firewall set and let it handle routing from there. And finally – that pesky problem of exponential VPN tunnels. Now that each data center has a single /16, we only have to create a single tunnel between two locations which saves us a ton of valuable CPU on the VPN gateways.

Now, obviously these benefits only apply to locations where the new IP addressing scheme is the only addressing scheme. For connections back to a legacy data center, we would still have a single /16 on one side of the VPN while the other side had 4-6 /16 subnets. Even so, the VPN tunnels required for that configuration are significantly less than before. So to wrap this up, the design was proposed to the team and we decided to go with it for the four new data center builds. It is working quite well so far – and we are beginning to have conversations on back-porting this design to the legacy data centers (which will be another post for another time).

 

Have you ever had to re-design an IP addressing scheme? or have you ever been bothered by the current design and wished you could change it? Comment with your thoughts!

About Matt Schmitz

Herding packets since 2007. Perpetually trying to automate myself out of a job. I believe that all problems can be solved by implementing more IPv6. Disclaimer: All opinions posted here are my own, and do not represent any vendor or current/former employer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.