Managing allocatiions out of a CIDR block
I am trying to rewrite the system that we use to allocate blocks from our provider blocks to customers. Previously the smallest block we allocated was a class C and so this process was pretty easy but now I want to be able to optimally use our allocations and allocate blocks down to a /30. Does anyone have any ideas, or code, that will manage multiple CIDR blocks and keep track of the currently unused parts of the block and given a requirement find an appropriate allocation (while not fragmenting it like crazy). It would be also useful if it could collect together POP specific blocks so that, for example, two parts of the same class C were at the same POP. Ideas, suggestions? Thanks, Mark.
Does anyone have any ideas, or code, that will manage multiple CIDR blocks and keep track of the currently unused parts of the block and given a requirement find an appropriate allocation (while not fragmenting it like crazy).
Isotro has code that allows you to manage IP address space, and understands CIDR. It uses a commercial database, and connects to both a DNS server and a DHCP server. They were recently bought by Bay. If you are looking for an automatic system to allocate blocks, this does not do that. You have to tell the system who has what block. But it has all the hooks you need to develop that kind of system. Eric Carroll eric.carroll@acm.org Tekton Internet Associates
In message <199802100855.TAA02809@kuji.off.connect.com.au>, Mark Prior writes:
I am trying to rewrite the system that we use to allocate blocks from our provider blocks to customers. Previously the smallest block we allocated was a class C and so this process was pretty easy but now I want to be able to optimally use our allocations and allocate blocks down to a /30. Does anyone have any ideas, or code, that will manage multiple CIDR blocks and keep track of the currently unused parts of the block and given a requirement find an appropriate allocation (while not fragmenting it like crazy). It would be also useful if it could collect together POP specific blocks so that, for example, two parts of the same class C were at the same POP.
Ideas, suggestions?
While I don't know of any existing code offhand (I keep meaning to write something, but never have the time, yada yada), you might want to take a look at RFC 1219 for address allocation. :: Mike ::
Mark Prior writes...
I am trying to rewrite the system that we use to allocate blocks from our provider blocks to customers. Previously the smallest block we allocated was a class C and so this process was pretty easy but now I want to be able to optimally use our allocations and allocate blocks down to a /30. Does anyone have any ideas, or code, that will manage multiple CIDR blocks and keep track of the currently unused parts of the block and given a requirement find an appropriate allocation (while not fragmenting it like crazy). It would be also useful if it could collect together POP specific blocks so that, for example, two parts of the same class C were at the same POP.
Ideas, suggestions?
I started writing one of these. I've been busy so it has been wallowing in some subdirectory. But it will be web page based using CGI. Any browser can access it (with authorization and valid IP) so people who work from Win95 or Mac or UNIX workstations can access it. It is being written in C and is to be tested under Apache on Linux, but will probably work fairly well on any UNIX with a CGI conforming HTTP server. It will need its own userid to run as (root not advised, but the personal userid of the network administrator would work). It will be completely CIDR. So if you add or delete or assign a /23 you will be working with an aligned pair of class-C networks as one. It will keep its own data files so no special DB server is needed (there isn't that much to keep). It will generate SWIP templates and allocation reports usable to request more space. Any other features you think should be in it before I get too far along in the basic design? At this time I don't know when it will be complete. Looks like 2-4 months. Could be more. Less if my own need for it increases to where I can justify more time in it. I just completed the CGI for my "Grass Roots Servers" project and you can see a sample of my work (with source) at this location: http://www.best.com/~philh/grs/ (click on "The TLD selector") -- Phil Howard | die7spam@anyplace.net crash328@nowhere8.com ads2suck@dumb7ads.com phil | blow9me3@nowhere3.com stop2it9@no6where.com die9spam@spammer7.org at | end1ads5@spammer9.edu blow2me8@lame5ads.edu suck4it8@anyplace.org milepost | stop3it1@nowhere7.com w6x9y8z7@noplace9.org w7x5y0z9@noplace8.com dot | ads6suck@anywhere.org stop8ads@anywhere.org stop0it5@lame0ads.edu com | stop2ads@no9place.net eat1this@noplace0.com die5spam@spammer1.org
A couple of weeks ago I asked: I am trying to rewrite the system that we use to allocate blocks from our provider blocks to customers. Previously the smallest block we allocated was a class C and so this process was pretty easy but now I want to be able to optimally use our allocations and allocate blocks down to a /30. Does anyone have any ideas, or code, that will manage multiple CIDR blocks and keep track of the currently unused parts of the block and given a requirement find an appropriate allocation (while not fragmenting it like crazy). It would be also useful if it could collect together POP specific blocks so that, for example, two parts of the same class C were at the same POP. Ideas, suggestions? Well I had a number of people respond, some with ideas and some asking to find out what I found out so ... The only publically available code I was pointed at was "Tree" <URL:ftp://ftp.bt.net/pub/networking/tools/tree/tree-2.1.5.tar.Z>. This seems to handle the basic allocation OK, although I'm not sure it conforms to the APNIC's guidelines on the block size to allocate. Also it could be painful if you have a number of separate blocks to allocate out of since you must specify the block before requesting the allocation. You will also still need some other DB (lookaside file, whatever) to associate the allocation to a customer, which isn't a real drama since you need to keep all sorts of other stuff to keep the registries happy anyway :-) Some other people provided ideas on how they might do it and I have decided to follow that route, ie roll my own in perl. This will allow me to do my own "specials" and easily integrate it with the rest of my system. Thanks to everyone for the pointers and advice, Mark.
participants (4)
-
Eric M. Carroll -
Mark Prior -
Michael K. Sanders -
Phil Howard