Slashdot Mirror
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?"
...and then scan them in and display them as a gif on www.yourispname.com.
Look, maybe I won't think you're the most technological person ever, but damn will I be impressed.
A few years ago I had to allocate single IP's to a now defunct Cable Modem ISP user base. I was handed this job when it was being handled by using Microsoft Excel, of all the stupid things. Upon learning this, I sent a memo to several of the in-house engineers and said "What can you guy's do to assist in this matter?". One of the unix guru's got together with one of our webmaster's, and they were in the middle of writing a nice little database with GUI system. Then upper management decided to combine the accounting system, the tech call center data, and the sales order system into one large package. A year later, I was still using Excel to allocate IP's. Later, after I had left the company, I found out this system wide package never got completed.
The moral here: keep it simple, clean, and efficent. And I'm pretty sure there are lots of folks who are current with all the latest database
technology that could handle this matter.
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."
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.
SIG: HUP
I've always used excel.
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?
Meep Meep!
Expensive, but really nice and integrates with bind.
.. etc blah blah.
Full control
scheduling
web interface if you would like
batch
Designed to drop in a manage your BIND DNS servers.
Really really nice and worth the bucks
Have someone build you *YOUR OWN* system. We also doled out IPs based on a regional layout. We had a guy that built a system that generated SWIPs (very good idea, BTW -- however, I will assume you knew that), kept all allocated blocks (we did octets as a base for our customers and allocated larger blocks as necessary) in an SQL database, and provided a PHP frontend for it.
Just make sure you set up a prebuilt scheme to allocate the IPs as necessary. If you don't go ahead and allocate the IPs for connection IP's (/30's), subnets (/29's) and the like, you will be in deep trouble later on.
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
Care about freedom?
Become a card carrying member of the GOA.
Lucent's QIP has been around for 5 or 6 years and is pretty good for centrally managing address space. At a former employer we used it to manage a /8, a /24, and numerous RFC-1918 subnets for a network spanning a couple hundred sites in a few dozen countries. Runs on NT, W2K, HP-UX, AIX, and Solaris.
(Disclaimer: I am not now, nor have I ever been, affiliated with Lucent.)
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.
/24 come from a /23, or a /22?), etc., but this is a good start.
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
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).
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Secondly, if you want to keep router tables from exploding, ALWAYS allocate in a heirarchical manner. If the router is A.B.C, then the machines should not be D.E.F.G. (I've seen places that do this kind of scattered allocation. It's MURDER on the routers!)
Since you've split the groups into heirarchical arrangements, you NEVER need to deal with more than 254 at a time (the maximum in any given range at any given level, as you need one for the broadcast, and 0 is reserved).
Dealing with 254 is a LOT easier than dealing with a few tens of thousands, but it's still a lot. As searches -tend- to be linear (boo!!!), you can reduce this still further. I'd split the block into 2-4 sub-groups, starting with the most frequently-accessed.
Now you're down to about 60 or so addresses, in any given sub-group. If there are neat divisions you can use, split each block of 60 into those.
At this point, you've specified the main division, the frequency of access, and the minor division. If you've more than 10 addresses left to worry about, you've probably not split enough, further up.
Once you're down to 6-10 addresses, it's easy to have web-based allocation. A basic web page, with radio buttons and an entry for the name should be all you need. A space that small can then be stored in an indexed sequential file, without any problems.
(Indeed, this is how you'd store the entire IP scheme, by using several layers of index, and then a final, short, sequential list for the data.)
Once you've got that, you just do regular updates on your DDNS servers, and you're fine.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Check out FreeIPdb. It's a postgres backed db that's meant for this type of thing. Future versions are going to incorporate RWHOIS, SWIP and other.
You can also check out NorthStar. Same type of thing, but already has functionality to assign blocks to users (ie. delegate blocks to a manager or a customer).
Use PHP and MySQL :) Pretty easy and efficient in my opinion.