Mark Prior > CIDR-Assign-0.01 > CIDR::Assign



Annotate this POD

View/Report Bugs
Module Version: 0.01   Source  


CIDR::Assign - Manage assignments out of a group of CIDR blocks


use CIDR::Assign;

$obj = CIDR::Assign->new($filename);


$network = $obj->assignNetwork($length, $customer, $ones, $zeros, $location);

$obj->changeState($network, $state, $customer, $location);


($network, $state, $date, $customer, $location) = $obj->iterateAllocations;


This module can be used to manage customer assigments out of a provider block. The CIDR block is represented as a B-Tree in a Berkeley DB database and is originally populated by invoking initialiseBlock with each provider block.

new will create the DB file, whose name is passed as a parameter, if necessary, and then tie it to an internal hash used by the other routines. This routine attempts to acquire a lock on the DB file using lockf in an attempt to control access to the file. Should acquiring the lock fail the routine will return "undef".

DESTROY closes the DB file and releases the lock on the file.

Networks can be allocated out of the assigned blocks by calling assignNetwork specifying the size of the block required. The system then scans the tree for a "free" block that is of the required size. If a block isn't available then it splits the next largest block and invokes itself. Should there be no free block available for allocation then the routing returns "undef".

The parameters "ones" and "zeroes" are used to indicate if the allocation can make use of an all ones or all zeros network if necessary.

The parameter "location" is optional but if present and the allocation is smaller than a /24 it will try to choose a block in the same location as other allocations in order to avoid too much fragmentation of the address space.

changeState can be used to change the state of a block in the free, for example, to add existing allocations to the tree or return an allocation to the free pool.

initialiseBlock adds a new block into the allocation pool.

iterateAllocations allows the caller to traverse the tree, much like "each", and returns a list of information about each allocation. This list is comprised of network, state (currently 'taken', 'free' or 'holding'), date of last operation and customer indentifer (and possibly location) if the block is not free.

errorMessage return a string suitable for printing that describes the latest error condition.


Mark Prior <>

Original idea and code by Andrew Rutherford <>


This module uses the following modules


The Berkeley DB is used for storage of the allocations, in B-Tree format.


The allocations file is locked with lockf to avoid problems with NFS.

syntax highlighting: