The Florida Museum, like most modern businesses, leverages an Ethernet network to facilitate much of our communication, data processing, and data storage needs.  Our network allows our computers to “talk” to other nearby computers, printers, a variety of Florida Museum and University of Florida servers, and of course, the Internet.  However, none of this communication would be possible without an IP Address.

Your computer’s IP Address determines which network it belongs to, and by extension, the other devices with which it can communicate.  It also determines whether or not your computer belongs to a private network (such as the Florida Museum’s workstation networks) or a public network (such as the network where the our www.floridamuseum.ufl.edu server lives).

My computer’s private IP address:	10.243.11.108
Our www.floridamuseum.ufl.edu server’s public IP Address:	128.227.30.254

A DHCP service facilitates the assignment of an IP address to your computer when it boots up.  For many years, OMT ran a multiple DHCP services to answer the need for IP addressing across our growing collection of buildings and facilities, including Dickinson, Powell/McGuire, Building 105, the Special Projects Lab, Bartram, and the Randell Research Center.  One helpful feature of our DHCP service was that it’s configuration was automatically and dynamically derived from our official OMT Network Inventory.  This arrangement allows us to observe the IT principle of one true source and also gave our Help Desk Technicians a simple and reliable way to add new devices to the network.

Earlier this year, UFIT approached OMT about adopting their centralized DHCP service, InfoBlox.  Using this service appeals to us in terms of avoiding duplication and leveraging centralization whenever possible.  However, the interface for InfoBlox is somewhat terse, and intended for use by only one or two administrators per unit.  With the high volume of devices that we routinely cycle on and off our network(s), this would represent a high administrative time cost.  We needed a way to populate the InfoBlox configuration form our official OMT Network Inventory so we could maintain the functional advantages of our existing address assignment methods.

Once we had the software development resources available, we set about writing a small application to act as the “bridge” (aka middleware) between our OMT Network Inventory and the InfoBlox systems. After a short but lively development cycle, we implemented our middleware and adopted the UF InfoBlox DHCP service.  The net gain for us is a centralization of our DHCP services, which ultimately simplifies our server infrastructure and allows us to focus on projects and processes (e.g. Specify) that more directly impact our mission.