IP Allocation and Management? 22
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?"
Write Them All Out By Hand (Score:2, Funny)
Look, maybe I won't think you're the most technological person ever, but damn will I be impressed.
A serious hassle...but.. (Score:2, Insightful)
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 here... (Score:4, Funny)
-Adam
"His cook has been goosed as ordered, sir."
Idea (Score:3, Interesting)
DNS and Spreadsheets... (Score:5, Informative)
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?
Re:DNS and Spreadsheets... (Score:2)
Re:DNS and Spreadsheets... (Score:1)
Obfuscation is a two-edged sword. Yes, it makes it slightly more difficult for hackers to figure out what's what, but it also makes it more difficult on your administrators. I would much rather not waste my time trying to figure out what a particular bit of hardware is. Hackers have basically unlimited time and multiple techniques to identify a device, so obfuscated names are of limited value in terms of reducing risk.
Re:DNS and Spreadsheets... (Score:2)
So, if I put names in the DNS like: this-is-a-fake-name-to-fool-the-733t-hax0rs.get-a
It's almost a cliche: Security through obscurity is no security at all.
On the other hand, it sure is handy to be able to tell, at a glance, what an IP is supposed to be used for.
Re:DNS and Spreadsheets... (Score:1)
If you allow hackers to attack your network with nmap you've already lost the battle.
Re:DNS and Spreadsheets... (Score:2)
If you allow hackers to attack your network with nmap you've already lost the battle.
And out of curiousity, oh great net guru, how do you go about preventing/spoofing nmap attacks without bogging down your edge routers? Turning off spoofed packets is easy. Not responding to ICMP broadcasts is easy. Setting up ACLs for services is easy. What do you propose, rewriting the TCP/IP stacks or installing funky-do routers which mangle off-colour packets? How much time and energy do you have for this, and what exactly is the gain?
nmap just tells you the OS and what services you run; the information lets you tailor your attacks and scans but little else so long as you're up on your network security.
Re:DNS and Spreadsheets... (Score:1)
That way you get the advantage and the bad guys dont...
QIP from lucent software (Score:1, Informative)
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
FreeIPdb (Score:4, Informative)
Among other software, there's FreeIPdb [freeipdb.org].
In the last month or two this subject has been discussed at least once on NANOG [nanog.org]. You might also try searching the inet-access list archives at MARC [theaimsgroup.com]
-Nathan
Commercial product (Score:2, Informative)
Postgresql (Score:3, Informative)
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).
Some thoughts... (Score:2)
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.
Freeipdb/NorthStar (Score:2, Informative)
You can also check out NorthStar [brownkid.net]. Same type of thing, but already has functionality to assign blocks to users (ie. delegate blocks to a manager or a customer).
Re:Freeipdb/NorthStar (Score:1)
PHP and MySQL (Score:1)