IP Allocation and Management?

jmw asks: "I work for a large[r] regional ISP in the midwest. In the past, and through several acquisitions, we've accumulated a substantial amount of IP space - non contiguous blocks from a /24 up to /19 or more, totaling several thousand IPs. With that many IP's, it's a fairly daunting task to manage, allocate and just keep track of what we have. I'm sure some of you are in, or have been in, similar situations... CVS has been used, but not standardized on.-More people would like to see a pretty web page or the like. For those of you in this situation, what have you done?"

Comments

I can help you out here...

[stienman]

I can help you out of this mess. Just give me all the IPs you don't want to (or can't) manage, and I'll make sure they're well taken care of.

-Adam

"His cook has been goosed as ordered, sir."

Idea

[autocracy]

Create three basic classes of IPs (or whatever number suits you). Make a database to store it. Then set up calls to search by the IP you enter and have it bring up the block showing subnet mask, primary subdomain name, location, router, what part of the primary block it's in (IE if you divide up a /19 in /24s, you'll want to note it came from that higher-up block). You will want to maintain some uniformity in the size of the blocks you assign, because having /19s-/24s with constantly varyings masks will drive you up the wall no matter how much planning you use.

DNS and Spreadsheets...

[Meleschi]

I work for an ISP also that has quite a few customers throught the country...

There are multiple methods currently in use to help deal with the IP utilization scheme, but I think the two methods that we use on a per-city/regional basis would assist you the most...

One highly overlooked way of assisting with IP deligation is... DNS! Please, do yourself a favor, and complete full reverses and forwards for every ip you have.. If it's a subscriber IP, make sure the reverse has -sub- or some other method of knowing what that IP is utilized for.

In addition, if it's appropriate for your subscriber base, and you''re allowed, put something about where that ip space is being deployed also in the dns entry...

Something like this: aabbcc-westside-sub.(router interface).(domain) helps out greatly when troubleshooting ip problems, routing, etc because you don't need to do any additional checking to know where this IP space is (supposed to be) utilized.

In addition, don't forget to keep track, in a spreadsheet or database of some sort, where the ip range/block is deployed, and keep it updated when new ip's are deployed. Mark if the range is for dynamically assigned ip's (subscribers) or static IP's (special customers and/or head end equipment, router loopbacks, interfaces, etc). Stick to your assignment. Don't have multiple IP networks on the same wire if it can be avoided (unless you use Trunking of course)....

Hmmm.. Now that I think about it, it really isn't so simple, is it? :-)

FreeIPdb

[wierdo]

Among other software, there's FreeIPdb.

In the last month or two this subject has been discussed at least once on NANOG. You might also try searching the inet-access list archives at MARC

-Nathan

Postgresql

[coyote-san]

Your first step may be to put everything into a postgresql database. It supports IPADDR (IPv4) and CIDR directly, support for IPv6 addresses is being added, and if necessary you can define your own types and functions.

The first table could be something as simple as (CIDR, customer), plus blank entries for the unallocated blocks. You'll eventually want a separate customer table, a new field that shows the parent block (did this /24 come from a /23, or a /22?), etc., but this is a good start.

The benefits? You can access the database from anything - command line, MS Access (via ODBC), web pages (via Perl or JSP/JDBC), etc. It's easy to make complex queries, e.g., "show me all unassigned IP blocks adjacent to a block owned by this customer." (That particular query should actually be added as a stored procedure.)

The drawbacks? It's a SQL database, so if you (or your coworkers haven't used SQL before there's a learning curve). Finally, as others have pointed out it's easy for others to dogpile on your project - you need to be able to insist that you have something that works for you before adding in features that other groups want. Tell them it's better to wait a month (for you to finish) than for nobody to have anything (because the project is too big for your current staffing levels).