2007 May 15 - Tue

One Unified Address Management (OUAM)

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.