Writing a Custom IPAM Application

Four years ago, I lamented the lackluster selection of IPAM applications available for service providers. Unfortunately, it seems not much has changed lately. I was back to exploring IPAM offerings again recently, this time with the needs of a cloud hosting provider in mind. I demoed a few tools, but none of them seemed to fit the bill (or they did, but were laughably overpriced).

So, I decided to write my own. In my rantings a few years back, I had considered this option:

Could I create a custom IPAM solution with everything we need? Sure! The problem is that I'm a network engineer, not a programmer (a natural division of labor which, it seems, is mostly to blame for the lack of robust IPAM solutions available). Even if I had the time to undertake such a project, I have little interest in providing long-term maintenance of it.

My opinion has not changed, but I've come to realize that if I want a tool that fits my requirements, I will need to build it. And after surprisingly little time, I'm happy to report that I have now have a kick-ass IPAM tool that does exactly what I want it to.

While I can't share the code, which is owned by and purpose-built for my employer, I would like to share some tips I picked up in the process with the hope of convincing others that rolling your own tools really isn't that hard. And in many cases, it may be well worth the effort.

Start with a framework

I've noticed that many people, when they set about building a tool from scratch, actually start from scratch: They write their own HTTP request handlers, their own database schema abstractions, and so on. If you're writing a tool which is to be a standalone product in its own right, this might make sense, but if all you need is a simple application for internal use, this approach will cost you hundreds of hours of time better spent on actual application logic and features.

The better option is to start with a framework like Django (Python) or Rails (Ruby). Frameworks reduce development overhead by providing the boilerplate code necessary for common functions: database ORM, authentication, templating, etc. Frameworks allow you to produce a usable bare-bones application in just a few hours.

It's no secret that I'm a big advocate of Python and Django (which powers Packetlife.net), but generally speaking, any mainstream framework should suffice for a relatively simple project like an IPAM application. Obviously, there's a learning curve associated with any platform if you're not already familiar with it, but it's a solid investment of time, especially if you might want to develop other web applications in the future.

Python's netaddr is awesome

Obviously, robust handling and representation of IP addresses and networks is crucial to the performance and integrity of an IPAM application. Fortunately, Python's awesome netaddr library comes packed with just about everything you might need. netaddr provides objects which include simple, convenient methods for manipulating IP addresses and making complex calculations.

>>> from netaddr import *
>>> my_net = IPNetwork('192.0.2.0/24')
>>> my_net.version
4
>>> my_net.netmask
IPAddress('255.255.255.0')
>>> my_net.broadcast
IPAddress('192.0.2.255')
>>> len(my_net)
256
>>> list(my_net[0:4])
[IPAddress('192.0.2.0'), IPAddress('192.0.2.1'), IPAddress('192.0.2.2'), IPAddress('192.0.2.3')]
>>> '192.0.2.123' in my_net
True
>>> '192.0.3.17' in my_net
False
>>> list(my_net.subnet(26))
[IPNetwork('192.0.2.0/26'), IPNetwork('192.0.2.64/26'), IPNetwork('192.0.2.128/26'), IPNetwork('192.0.2.192/26')]

You can even feed netaddr a list of prefixes within an aggregate, and it will caluclate the remaining available space:

>>> aggregate = IPSet(['192.168.0.0/16'])
>>> in_use = IPSet(['192.168.1.0/24', '192.168.2.0/24', '192.168.8.0/22', '192.168.192.0/18'])
>>> aggregate ^ in_use
IPSet(['192.168.0.0/24', '192.168.3.0/24', '192.168.4.0/22', '192.168.12.0/22', '192.168.16.0/20', '192.168.32.0/19', '192.168.64.0/18', '192.168.128.0/18'])

netaddr provides a huge chunk of the functionality any IPAM tool needs, for free. And it's even fully IPv6-compatible!

Take advantage of PostgreSQL's network address types

When I first pondered how to store IP addresses in a database, I figured it would make sense to use a 128-bit integer coupled with an integer mask length. Unfortunately, PostgreSQL, my database of choice, doesn't provide a 128-bit integer field. However, it does provide the cidr and inet address types, which were purpose-built for storing IP addresses.

Even cooler, these fields come with built-in functions and operators which allow for very flexible queries. And if you're using Django, you can leverage the django-netfields package to use these fields natively in your application.

Plan for VRF support (even if you don't need it)

Back when I was working for a managed services provider with hundreds of tenants, robust VRF support was a crucial requirement for an IPAM solution. These days, I don't have as much need for it, but based on past experience I decided to include the feature anyway. Although you might not have any immediate need to track multiple routing tables, it's trivial to add a VRF field to address objects and treat null values as belonging to the global table.

Also, be sure never to assume that an IP address will be unique in the database (even for public IP space). Never use an IP address itself to refer to an object (e.g. when forming a URL). Instead, use the primary key of its database object, which is guaranteed to be unique.

Laying the groundwork for this feature will help mitigate any issues in adding full VRF support in the future should the need arise.

Rely on native IP behavior to build hierarchies

I've seen IPAM products where each prefix is manually assigned to a parent prefix using a unique key in the database. This makes no sense. For example, if I have defined 10.10.0.0/16, I don't need to specify it as a parent network if I create 10.10.10.0/24 in the same network: This relationship is already effected by the very nature of IP (so long as both networks belong to the same routing table).

If you ever find yourself manually assigning one address object as the parent or child of another, you're probably doing something wrong.

Pay careful attention to VLAN scope

When devising a scheme to organize VLANs, remember that VLAN IDs are technically unique only within the context of a single switch. For the sake of simplicity, most people try not to reuse VLAN IDs within a given domain such as a site or building, but it happens more often than you might think. For instance, suppose you never reuse VLAN IDs, except for VLAN 999, which is used for a separate guest wireless network at each site. Well, this one exception to the rule means that you can't declare the VLAN ID field unique in the database schema. It's easy to get bit by exceptions like this, so you're best off not making any assumptions about uniqueness period.

Treat IPv4 and IPv6 equally

Any time you return a list of address objects, it should include relevant addresses belonging to both the IPv4 and IPv6 families. Use the same model to store both address types. You can always add an option to explicitly filter for one or the other, but you want to avoid having to make two separate database queries to retrieve both types.