solution Use Case
IPAM (IP Address Management)
Managing and monitoring IP addresses has become an inevitable part of network management. This use case shows an example of a company moving away from manual and spreadsheet-based IP address management and implementing DataMiner as an IPAM system, as part of a large DataMiner rollout in a new content management center.
IPAM gives network admins a real-time inventory of all IP addresses, including details like subnets, hostname, status, and associated hardware. To achieve this, DataMiner interfaces with the relevant DNS and DHCP servers to retrieve IPs, hostnames, DNS records, DHCP scopes and releases, etc. It enriches this with additional parameters extracted from various Cisco Nexus and Catalyst network switch tables (e.g. IP route, ARP, interface brief). Additional notes and comments can be entered manually or via an easy-to-use web interface.
A first IPAM MVP (minimum viable product) was rolled out based on DataMiner’s low-code HTML5 apps and DataMiner Object Model (DOM). Stored in a high-performance Elasticsearch database, the state-aware DOM objects used for the IPAM app can be expanded at any point in time. This can for example include multicast address ranges, which can easily be made available to third-party systems (e.g. broadcast and SDN controllers) via DataMiner’s new user-definable (RESTful) APIs. And whenever DataMiner or a third-party system has taken an available multicast IP from the pool to provision a new device, e.g. an SDI-to-IP gateway, the object state for that multicast IP changes from free to in use.
This way, DataMiner acts as the central repository to manage both broadcast and IT infrastructure and gives the network administrator full visibility over all IP addresses.
USE CASE DETAILS
The IPAM app comes with multiple tabs. This screenshot shows a list of subnets, their VLAN IDs, and the VLAN names. Users can easily filter by names, subnet masks, VLAN IDs, etc. The "last seen" column indicates when DataMiner last polled the data, and the "last updated" column indicates when the data last changed.
Network admins can edit every entry, for example to add a description to a VLAN.
The IP addresses tab aggregates data from multiple data sources and shows a list of all IPs and their MAC addresses but also the connected Ethernet switch and its switch port.
Additional administrative data, for example the owner of a device, can easily be added to each entry.
It is also possible to add new entries manually. This is useful for situations where an administrator already knows about a certain device that will be added to the network later. There are some mandatory fields, like the MAC address, that must be entered up front, while other fields will be automatically populated by IPAM when the device is connected to the network for the first time.
The polling speed of DNS servers, DHCP servers, and Ethernet switches can be configured here.
An important feature of every IPAM system is the capability to identify duplicate IP addresses. DataMiner will automatically find those and show them on the "Duplicate IP" tab.
This is a screenshot showing the data pages of the DataMiner DHCP server connector, where you can see both the scopes and leases. DHCP scopes define the consecutive ranges of IP addresses that can be used, and the DHCP leases show the temporary assignment of an IP address to a device.
The DHCP server requires a user name and password to authenticate. The scopes and leases are updated based on a regular polling interval, but you can also force an update manually at any time.
This screenshot shows the DNS server connector. The connector extracts all A records and PTR records. The A records table points a domain name to an IP address, and the PTR (pointer) records allow you to resolve an IP address to a domain or host name often used for DNS lookups.
Similar to the DHCP configuration, the DNS server also requires authentication with a valid user name and password.
The "Interface Brief" table gets polled through the Cisco Nexus connector. There we can extract the VLANs associated with an IP address.
The "ARP" table in the Cisco Nexus connector gives us the description for every MAC address.
Finally, the "IP Route" table has all the information required to identify the next hop and connected switch and switch port.
This app was built in such a way that new elements can be added on the fly. Those can for example be additional switches or a third-party database providing extra administrative data (e.g. a CDMB with the rack position of each device). Under the hood, DataMiner "inter-app" classes are used. These allow every element to easily forward info to IPAM on request. You only need to expand the DOM object to store new data and implement a small change on the DataMiner connector for the new element in case the "inter-app" class is not part of that connector yet. The IPAM app will automatically be adjusted.
Interested in how those HTML5 pages get created? You don't need to be a developer with coding capabilities: just go into the edit mode. With DataMiner GQI (Generic Query Interface), you can easily create a new query using the wizard that you can see on the right. "ipdom" is the DataMiner DOM object that has data stored in the DataMiner Elasticsearch database. In a next step, the IP address is used, and those where the count is greater than 1 are filtered out. And with that, DataMiner knows about duplicate entries. To finish the query, we go back to our "ipdom" object and select the columns (IP address, subnet, MAC address, etc.) that we want to display in our table. And that's it.