Time To Say Goodbye To Static IPs

Configuring static IP addresses on switches, routers, log servers, databases, management systems and other parts of the infrastructure is a common practice. It's also a bad one. Extending that error to virtual machines and applications is worse.

The thinking behind the practice is that if all else fails, IT can still connect to critical services because the IP address is static and therefore known. That may be true, but with the advent of server virtualization and the inevitable migration to IPv6 addresses, it's time to end this well-intentioned but misguided habit. The fact is, static IPs break the mobility and flexibility that server virtualization provides. As for IPv6, do you really want to keep lists of all those 32- digit addresses in hex?

A Better Choice
Extend your use of DNS and DHCP to these systems. I know some IT pros will argue that this is dangerous and insecure. After all, if DNS and DHCP services fail, you won't know the IP addresses for important network devices or virtual servers. It would also force IT to treat DNS and DHCP like mission-critical services, which means spending more time and resources to keep them up and running. But DNS and DHCP are already used for essential devices and applications, such as VoIP phones, Active Directory services, and wired and wireless desktops. If your DNS or DHCP servers fail, you have to get them restored right away.

In other words, DNS and DHCP are already essential, and it's time to treat them as such. Moreover, by expanding use of DNS and DHCP to eliminate static IPs, you can take better advantage of server virtualization. One of the benefits of virtualization is it lets you move VMs around your data center and even between data centers. Data center automation simplifies VM moves and VM provisioning.

Those actions, as well as others, are difficult or impossible to do if you use static IP addresses. What happens if you bring up a VM on, or move a VM to (not a live migration, of course), a subnet where there is an address collision? You must, as part of the move, change the node's IP address. You can do that using automation software like Puppet, but it's not only a lot more integration work, it's one more function that can fail. Static IPs are also more difficult to use with virtual appliances because they are often physical-to-virtual clones of their hardware counterparts, and IP configuration can't easily be automated.

And managing static IP addresses only gets more complicated as you move up into applications because those assignments are buried in configuration files.

Frankly, the IP address assigned to a host shouldn't matter. What's more important and useful to IT is the host name: You can decouple a name, which is portable, from an IP address, which may not be. You want to connect your application to database.example. com, not 2001:0db8:85a3::8a2e:0370:7334.

I can hear the concerns from operations and security about how DNS and DHCP aren't reliable or secure. But it's your job to make them so. Do it now, and you can thank me later.