For the longest time, I thought that the sum total of the ip address management solutions out there revolved around NorthStar and IPplan, neither of which really were as robust as I'd like.
A recent 'net search comes up with some different candidates. A IP Addressing Space Management
Applications? has
some interesting pointers to IP Address Management solutions, both Open Source as well as Commercial. One Open
Source solution that appeared to be a stand out is Carnegie
Mellon's Network Registration/Network Monitoring solution. It is under active development. Internet2 has some links to solutions that handle various combinations of Agents, Registration,
and Active/Passive Detection.
Some of the above actually crosses over into the region of Network Authentication, of which Internet2's SALSAK is trying to rigorize through
a Poicy Framework. Their second
draft has better details, in my opinion.
So I can come back to this later, in following the various links from an earlier mentioned table, I came across PacketFence which is a Network Access Control
(NAC) solution wrapped up in a VMWare deployment package.
When coming up with an IP Address Management Solution, BT Diamond IP has a handy guide to Best Practices for
Next-Generation IP Address Management.
During my initial thoughts of what I'd like to see, I was focussing more on address management, floor diagrams,
and port management than on DNS and DHCP. I figured DNS would be easy by simply exporting bind files on an as
required basis. I havn't considered DHCP integration yet, but should be straight forward with dhcp configuration
file exports, or data base lookups.
I had put together a schema diagram of what I was thinking of for ip address and facilities management.
Here is a description of the various links:
- Host -> Location: every host is associated with a particular location, floor, rack, shelf, etc
- Interface -> Host: an interface, and its sub-interfaces are associated with a host
- Interface -> Address:
- an interface, or sub-interface will have an associated address
- an interface will need multiple sub interfaces to contain additional addresses
- these sub-interfaces may simply be 'secondary address blocks', or secondary addresses, or vlans
- Interface -> Circuit: an interface is associated with a particular circuit, patch panel, connector, etc
- Circuit -> Address:
- a circuit may reference an address or address range that can be used to find attached interfaces, hosts,
and circuits (and is recursive by looking at subnets and contained addresses)
- thus routed address blocks shouldn't be referenced this way, only a circuit with ip endpoints should have
an address reference
- Port -> Address: for ports routed to different locations, or are routed, this is where this is
documented,
such as on NAT.d addresses (eg port 80 (http) or port 25 (smtp))
- Address -> Organization: Every address range is associated with a controlling organization
Some of the tables have 'self' links. This provides an ability for defining a hierarchy of relationships:
- Address: address blocks can be subdivided down to a /32
- Interface: a phsysical interface may be divided into sub-interfaces
- Circuit: a circuit may be composed of sub-circuits, wire going from wall jack to IDF to MDF to IDF to
wall
jack
- Location: a building may have multiple floors, a server room may have multiple racks, a rack will
have
multiple 'U' locations
Here is a sql schema file to go along with the diagram. It
is based upon PostgreSQL as it has native data types for handling ip addresses and mac addresses.