DeepNet IP Database

This is an IP address management tool I developed originally for my then and current employer ​ViaNet Internet Solutions as a replacement/upgrade for an existing internal staff tool that got left gathering dust.

I started originally from the perspective of exporting netblock allocation data to ​rWHOIS from the existing tool.

On trying to make sense of the existing tool's database structure, and how it handled netblocks (basically, it didn't; it allocated ranges of IP addresses which were free to begin and end places other than CIDR boundaries), I started replacing data structures and code to get the stored data consistent enough to export to ​rWHOIS. That basic need was met before using source control, and is represented by r4 - almost a complete replacement of the original code.

Code has since developed to support most of the needs of a medium-sized ISP. As of writing, code up to SVN revision r396 (/branches/stable) has been in live production use.

(Mis)Features:

As of v2.6:

• mostly supports IPv6, although a few segments still assume v4 addresses.
• internal data structures emulate the general routing configuration of most networks, although it does not directly represent or emulate deep routing chains.
• "maxiumum contiguous free space" allocation alogorithm; if a /29 and /26 are allocated from a /24, then allocation of a /27 will happen from the free space between the /29 and /26. Planned enhancement: Reserve space for expanding a block (#24).

This also relies on NOC staff using the IPDB allocation interface to request address space for customers, rather than looking at what's free on the router and using something handy... as well as relying on NOC staff to enter whatever arbitrary changes they've made. Planned enhancement: Module to walk router configs (either live or backup copies) and compare with allocations as listed (#25).

• hook to support checks against an external system for customer IDs
• rWHOIS export with either organization name/address or customer data as contact for published netblocks. This can be toggled on a per-allocation basis. Note that you still need to submit SWIP templates (if you're getting address space from ARIN) if you wish to delegate rDNS nameserver authority on /24 and larger blocks.
• preliminary support for email notifications to arbitrary destinations on any action. Currently, static IP assignments, netblock assignments, deallocations, and updates to blocks with the SWIP flag set will generate notices.

Notes on SVN history

Original development was done without any regard for keeping proprietary or company-specific information out of the code and SVN (eg, database passwords, hostnames, hacks for certain bits of awkward legacy data). I've taken the in-house repository used for development, and recreated all revisions up to r396 without most information specific to ​ViaNet.

Development past r396 has been committed entirely to this new repository, and most of those commits have been to trim out some dangling bits of hardcodedness necessary to make it simple(r) to install this and use it for any organization without having to patch the code.

Conventions

• A "larger" block is one with more IP addresses in it. Conversely, a "smaller" block is one with fewer addresses.

Requirements

• Perl
  • NetAddr::IP. I would not recommend using anything older than 4.x; however it should work well enough with 3.x.
  • CGI::Carp
  • DBI
  • File::Path
  • POSIX
  • Sys::SigAction. This isn't strictly required; it's used in an example hook for validating customer IDs against an external database.
  • Sys::Syslog
• PostgreSQL v7.4 or higher. Postgres provides an IP address/IP netblock data type, and operators to match; much of the functionality relies on these database operations. Other database engines could be used, with variying degress of trouble and hackery. v8.x is probably a good idea since 7.x is no longer supported upstream.
• Webserver supporting CGI executables. Note that the current code is somewhat inflexible about its web path, but that's due to be fixed (see #3, #15, and #17).

CPU and memory requirements have not been very high to date at ​ViaNet; performance has mainly been impacted by everything else we've crammed onto the same server.