IPplan - IP address management and tracking

1.1. Copyright Information

This document is copyrighted (c) 2002 Richard E and is distributed under the terms of the Linux Documentation Project (LDP) license, stated below.

Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below.

1.2. Disclaimer

No liability for the contents of this documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a new edition of this document, there may be errors and inaccuracies, that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility for that.

All copyrights are held by their by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

Naming of particular products or brands should not be seen as endorsements.

You are strongly recommended to take a backup of your system before major installation and backups at regular intervals.

1.3. New Versions

See the CHANGELOG file for more information.

1.4. Credits

Thanks to ValueHunt Inc. for the use of their layout class used for rendering all HTML pages.

Thanks to AdoDB for the use of their generic database abstraction class.

1.5. Feedback

Feedback is most certainly welcome for this document. Without your submissions and input, this document wouldn't exist. Please send your additions, comments and criticisms to the following email address : <richarde@users.sourceforge.net>.

1.6. Translations

See the INSTALL and TRANSLATIONS files on how to enable multilingual support and how to do a translation to your own language. Doing a translation does not require any programming experience. Current languages supported are English, French - Auto Translation, German - Auto Translation, Italian - Auto Translation, Norwegian - Auto Translation, Portuguese - Auto Translation and Spanish - Auto Translation.

2.1. Databases

IPplan requires a working database installation. The following databases currently work:

• MySQL 3.23.15 or higher (preferred)

• PostgreSQL 7.1 or higher

• Oracle 9i or higher (SQL99)

• Microsoft SQL server (both 7 and 2000)

The following may work, but are untested - Sybase. In fact, any database that supports SQL99 compliant joins, in particular LEFT JOIN, should work. See limitations section below for more.

The web scripting language php 4.1 or higher must also be installed as a module in Apache (NOT as a cgi). Php must have the preferred database driver compiled in and enabled. See the respective web sites and installation documents for more detail. IPplan works just fine with a combination of the Apache web server and php on a Windows platform - just read the relevant installation instructions for Windows carefully.

IPplan is also known to work in a distributed, replicated MySQL environment with multiple database servers. See www.oreilly.com for more information.

2.2. Additional features

To enable SNMP support, you will require the ucd-snmp package installed and configured in your environment. This must also be activated in the php configuration. SNMP support is only required if you wish to read routing tables directly from routers.

3.1. Customization

IPplan is customizable in many ways. Se the sections on templates, triggers and pollers. You can also extend the menu system to include your own custom menus for other systems at your site - see the config.php file for an example.

4.1. Screenshots

You can find some screen shots here.

5.1. Services company

As a services company your primary use of IPplan will be to manage individual IP address records and the address plan of one or more customers.

5.2. ISP

In ISP mode, you will assign blocks of IP address space to your customers. In this mode, you will not be concerned at all with individual IP address records and how the customer breaks down his assigned address space. When you operate as an ISP, you may also generate SWIP/registrar entries, which are only useful if you deal directly with ARIN or any other registrar. (SWIP is enabled in the config.php file, see ARIN tutorial for more details). All the relevant SWIP/registrar information is entered when the customer is created.

When using this mode, I suggest creating a dummy customer which holds all the allocated address space from your regional registrar (ARIN?) already broken up into the various blocks that you will eventually assign to your customers. All these blocks should be called "free" to allow them to be found using the "Find free" menu option. Once you are ready to assign a block, create a new customer with all the relevant SWIP/registrar information completed, go to your dummy customer and move a block of address space to the newly created customer, and finally generate a SWIP/registrar entry for the new block. In this mode areas and ranges are not too relevant except for the dummy customer (see concepts below). You may also need to create a template for your registrar in the templates directory. If you have done this, feel free to contribute it to IPplan.

6.1. Deployment strategy

So in a new installation, first create the areas, then create ranges adding them to areas, and finally create subnets. Searching is now a simple matter of selecting an area which will display all the ranges for the area, or selecting no area and simply selecting a range from the total list of ranges, or simply selecting a base network address.

Note that within a customer or autonomous system, no overlaps are allowed. This follows standard IP address rules. To handle challenges like NAT or other overlapping address space, you will be required to create multiple autonomous systems. See 'Searching' below how to see information across multiple autonomous systems.

6.2. Linking addresses

IP address records can be linked together. This allows one address or multiple addresses to reference another address or addresses. Using this feature allows for the referencing of NATed addresses or having a link to a loopback address of a device. Linking is done on the IP address details page by completing the "Linked address" field. Once the field is completed, you can follow the link. The link also appears on subnet summary pages.

You can also link many addresses in one go by choosing multiple addresses in the "Select multiple addresses to do a bulk change" window, then completing the "User" field as follows:

LNKx.x.x.x userinfo

The LNK identifier must be in uppercase, followed by exactly one valid IP address with no spaces, then followed by an optional space and user description. After the page is submitted, the embedded LNK will vanish.

7.1. Admin user

Firstly you will need to create users and groups using the admin user defined in the config.php script. The admin user can only be used on the admin pages. Once you are done with the admin functions, you will be required to re-authenticate as one of the newly created users as soon as you access functions on the main index page.

7.2. Customer access

When a customer is created, a group must be assigned to the customer. This will be the customers admin group and all members of this group can create and delete both subnets, ranges, areas and individual IP address records for the customer.

When the subnet is created, the creator will choose a subnet admin group.

7.3. Subnet access

The users assigned to the group that has subnet access can only modify individual IP records for that subnet.

Initially I would create three groups, one group that can create customers, one group that can create subnets, areas and ranges, and another group which can only modify individual IP records. Normally in large networks the people that modify IP records are not the same people that administer routers and configure the IP address space.

If a group is set to see only a particular customer, the same group needs to be used for all operations for the customer. The side effect to this is that the users assigned to the group have full access to the customer and can make any changes to the customers data, including creating and deletion of subnets. This is not ideal and will be changed in future.

7.4. Group authority boundaries

Areas of responsibility can be assigned to a group, thus limiting what address space a group can create networks in. The default behavior allows administration anywhere. Care should be taken when using this feature as changing the boundaries at a later stage may orphan some parts of the database and yield it inaccessible.

Bounds are also useful to create users that only have read access to the IPplan information. Create a very restrictive bound for the group the user belongs to outside your normal address space.

13.1. TAB delimited data

Network definitions or individual ip records can be imported in TAB delimited format.

The order of columns for network definitions or subnet descriptions are (three columns required): The first column contains the IP base address, the second the description and the third the mask either in dotted decimal format or in bit format.

The order of columns for importing IP records should be (six columns required): The first column contains the IP address, the second the user, the third the location, the fourth the description, the fifth the hostname and the sixth the telephone number.

If you have more than six columns, the remaining columns will be entered into the user defined fields specified in the template. The order will be the order the fields are defined in the XML template file. See the templates section for details on how the templates work.

13.2. Importing using NMAP

A typical application for this would be to obtain data for networks that there are no records for. NMAP would be used to obtain the host info of all the addresses that are active on the network. Once this is done, the data can be read into IPplan. The NMAP parameters are:

 -sP -oX output.xml

To speed up the process, you can add -n to not resolve host names. The import process also understands the -O operating system detection parameter. To use -O, you will need to drop the -sP parameter. Using -O increases scanning time significantly.

14.1. Registrar templates

Templates for sending information to registrars should be well formed XML stylesheets. See the existing templates in the /ipplan/templates directory for examples and which variables are available. Currently only the xsl:value-of select="variable"/ tag is understood and all other tags are stripped. This is to prevent requiring the XSLT php library. In future XML stylesheets will be supported in full.

14.2. IP address templates

The administrator can define a custom template in IPplan to allow the addition of as many custom fields to the ip address records as desired. This functionality allows flexibility in the way data is added to the database. Some uses for this include tracking asset information or WAN circuit information.

Format:

The template is a well formed XML file called iptemplate.xml and should be stored in the /ipplan/users directory. A sample template called iptemplate.xml.sample can be found in this directory. An additional template called iptemplate-network.xml can be created. If this template is created, this template will be used for network addresses (the first address of the subnet). This is useful to define subnet wide information like VLAN id's, telco line numbers, router configurations etc. If the iptemplate-network.xml does not exist, then the iptemplate.xml template will be used for network addresses.

The template file must be surrounded with <TEMPLATE> statements. Note that XML tags are case sensitive and must match as per the example. Each field is contained in a <FIELD></FIELD> statement. Each field must have exactly one <DEFINITION> line. Any line with an error will be silently ignore! The following are valid for a definition:

NAME

DESCRIP

TYPE

MAXLENGTH

SIZE

ROWS

REGEX

^[a-zA-Z0-9]$

ensures that the field only contains numbers and letters. See http://regexlib.com/ for more on regular expressions.

Regular expressions are PERL compatible and use a / character as the delimiter, thus if you want to match on a /, you will need to escape the /. So to match a letter, / and a number, this is the expression

^[a-zA-Z\/0-9]$

Regular expression | can be used for multiple matches. Thus the following will match a field or a blank entry

^[a-zA-Z\/0-9]$|^$

ERRMSG

Default template:

The default template contains one field which is the "Additional information" field of older versions of IPplan. If you do not want this field, change the template or delete the template entirely.

Template rules:

If you delete the template all fields will vanish and cannot be accessed. IP records that have been completed with fields from a template will not be lost, but records that do not have template fields cannot have template fields added until the template is either restored or similar fields are added.

Deleting fields from a template results in existing fields in the database with template data using a default field definition. The data is not lost. It is not a good idea to modify or change the template on a production system. Plan the template fields carefully before implementing.