Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
The Internet

IP Allocation and Management? 22

Posted by Cliff from the for-those-of-you-with-IPs-to-spare dept.
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?"
This discussion has been archived. No new comments can be posted.

IP Allocation and Management? More

IP Allocation and Management?

Comments Filter:
  • ...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 here... (Score:4, Funny)

    by stienman ( 51024 ) <adavis@@@ubasics...com> on Tuesday December 11, 2001 @09:09PM (#2690613) Homepage Journal
    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 (Score:3, Interesting)

    by autocracy ( 192714 ) <slashdot2007@sto ... .com minus berry> on Tuesday December 11, 2001 @09:09PM (#2690620) Homepage
    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... (Score:5, Informative)

    by Meleschi ( 4399 ) <{meleschi} {at} {gmail.com}> on Tuesday December 11, 2001 @10:37PM (#2691087) Homepage Journal
    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? :-)
    • Having descriptive DNS names for your equipment is a security risk. Why tell hackers what you have?

      • 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.

      • "Having descriptive DNS names for your equipment is a security risk. Why tell hackers what you have?"

        So, if I put names in the DNS like: this-is-a-fake-name-to-fool-the-733t-hax0rs.get-a- clue.com that will solve my problem? Uh, no. A quick nmap will tell you most of what you need to know about how a host and the network it's on is utilized.

        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.
        • It's unprofessional to introduce *any* security risk onto your network.

          If you allow hackers to attack your network with nmap you've already lost the battle.

          • 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.

      • if its only for internal use, why not set up and internal DNS server and add the hostnames as /etc/hosts (or whatever your equiv for your systems)

        That way you get the advantage and the bad guys dont...

  • QIP from lucent software (Score:1, Informative)

    by Anonymous Coward
    Expensive, but really nice and integrates with bind.

    Full control
    scheduling
    web interface if you would like
    batch .. etc blah blah.

    Designed to drop in a manage your BIND DNS servers.

    Really really nice and worth the bucks

  • FreeIPdb (Score:4, Informative)

    by wierdo ( 201021 ) on Wednesday December 12, 2001 @01:03AM (#2691806)

    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)

    by belphegor ( 221200 )
    Lucent's QIP [lucent.com] 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.)

  • Postgresql (Score:3, Informative)

    by coyote-san ( 38515 ) on Wednesday December 12, 2001 @11:23AM (#2693265)
    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).
  • First, since you are "managing" the IP addresses, you are implcitly saying that there is a dynamic relationship between IP number and machine. This tells me that dynamic DNS is a good place to start. (Always start with the obvious!)


    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)

    by cdh ( 6170 )
    Check out FreeIPdb [freeipdb.org]. 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 [brownkid.net]. 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.

Slashdot Top Deals

What is research but a blind date with knowledge? -- Will Harvey

Close