Can I get an IP? Do what?

How many times have you asked or been asked for an IP address for your network and heard the famous words of “just ping until you find an available address” or “we have an IPAM solution but not everyone enters information correctly”? Oh, the joys of IP address management. It comes with such joy sometimes, doesn’t it? In this time of where we are today; it is amazing to me that organizations still function in this manner especially when everyone seems to think they want dynamic and elastic environments, correct? Why is it that just to get an IP address is such a tedious effort involving too many hoops to go through? Is it because your organization doesn’t currently have a good policy on these sorts of tasks? Or is it because there are too many manual processes in place to accomplish this simple task? So why then, would you not want to implement a streamlined, automated process to handle this workflow of assigning IP addresses by removing all of the middleman processes involved as well? Are you serious? Is what you are thinking right? If we were to do that it would mean that we would be slowly removing tasks and procedures that we are responsible for. Oh, the famous “worried about being replaced by automation” response. So how do you handle IP address management in your environments?

  • We spread the list out on an IP subnet table so we can track either and entire section of IP's and down to the specific groups that IPs are being used for

  • We have a very simple way of managing IPs... a very very long list of all IP's possible, with the currently used IP's highlighted and notarized as to whom it belongs to.

  • It gets more complicated when we try to get more secure and implement firewalls on our hosts that block ICMP.  Now if you ping an IP address, it APPEARS that it is available, when a host is actually using it.  If you 'ping -a' the IP then the name of the host will resolve...most windows machines will register themselves in DNS.  Some of the non-windows systems have to be manually entered into DNS - hopefully with a reverse pointer to resolve with the -a parameter.

    We have Big Brother / Watchman that runs a nightly report.  It is configured with the subnets and if it scans them.  If it finds a DNS entry or if it is able to ping an IP address then it marks that address as 'Not Available'.  Not real-time, but it's something to use when looking for an available address.  We have a small team so we can let the other folks know if we're grabbing an IP...otherwise it wouldn't show up on the report until the next day.

    I see the use for IPAM to be more of a part of our ITIL implementation.  It won't stop folks from entering a static IP, but it could delegate who can add/remove entries in DHCP, DNS and WINS. This way changes could be self-documenting.  There would likely be a change ticket also created for these changes, but the delegation and logging would be a good way to audit these changes.  It would also be good to perform a network scan and see what IP addresses have 'popped up' that were not assigned with the IPAM so they could be investigated.

    What I would want in such a tool is that it not be cumbersome to use.

  • We have other challenges here...

    When a server is provisioned it is provided a DHCP based ip for a "provisioning vlan".  When it is moved into "production", it then gets a new static IP.

    The first is automated and the second is more of a manual process.

    Ideally, IPAM would provide a quick source of the new static IP..assuming it is up to date and correct.

  • We are making great use of Solarwinds IPAM locally vs spreadsheet and Infoblox at the corporate-wide level for subnet allocation and DNS services.

    But the real solution is to remove the problem of having to ask for an IP address. With openstack for example a guest is often set to deploy with an internal dhcp address based on dnsmasq. Then if the engineer wants a "static IP" for firewall rules or external access then they login to the openstack portal and request a "floating IP" which can move around even as the underlying machine is migrated.

    Best part is the floating IP ranges are setup per project so you have access controls and when a machine is decommissioned the IP goes back into the available pool.

    Based on seeing that I think we're all doing it wrong.