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. Aside from a handful of peripheral company-specific changes not yet supported as configuration options, /branches/stable has been in live production use on an ongoing basis.

Releases

Stable version, v2.8.2

​Tarball and ​signature
​SVN tag
​SVN latest patch - note this may include things not in the latest tag or tarball!

Try out the live ​demo - full access is available using the default admin/admin user/password. Note that actual sending of emails has been disabled in the code in this install.

Development

The Subversion tree root is ​https://secure.deepnet.cx/svn/ipdb. A few large features have had branches created to isolate known-broken checkpoint checkins from other development work, but most other work is done directly on /trunk. Bugfixes are sometimes initially committed to /branches/stable, then merged back to /trunk.

(Mis)Features:

• Stable branch mostly supports IPv6, although there may still be a few lurking bugs, and there are "recommended practices" for v6 allocations that are not implemented. See #24, among others. For instance, IP pools effectively can't be used the same way for IPv6 as IPv4 since the usual single allocation for an end user is a /64.
• 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 from r396 through around r520 removed almost all of the lingering ​ViaNet-specific or generic-but-inherited legacy code by way of converting the HTML output to HTML::Template and converting custom CGI parameter handling to CGI::Simple.

Conventions

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

Requirements

• Perl
  • Standard modules: These should be included in any base Perl install
    • File::Path
    • CGI::Carp
    • POSIX
    • Sys::Syslog
  • Extra modules:
    • NetAddr::IP >= 4.0.27. 3.x may work, however 4.x has been current on all of my development platforms for more than 5 years and crosschecks have found versions < 4.027 or so to be missing some important methods
    • DBI
    • DBD::Pg
    • Sys::SigAction. This isn't strictly required; it's used in an example hook for validating customer IDs against an external database. It could arguably be replaced with sigaction() from the POSIX module when using Perl >= 5.8.2. See eg ​Sys::SigAction for some thoughts on the gritty details.
• 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 varying degress of trouble and hackery.
• 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.