Question: I was recently graced with a new job opportunity in a large higher ed NE department. This is my first job working with a large network of several thousand users.  

Throughout my education, I followed the idea that **static IP's are useful from time to time in certain applications and historically used more in smaller networks**. To this point, it has been my belief up to this point that **DHCP is much more useful in larger settings**. For this reason, I was shocked to learn that **each of our near 3000 networking devices have painstakingly been allocated static management IP addresses**. It was explained that this was easier to handle that DHCP.  

I will admit, the scheme for the addressing is nifty. The **second octet is the device-class/network identifier**, the **third octet is the building identifier** (we have some odd 200 buildings on campus), and the **fourth is the device identifier**.  

So the scheme is understandable, but still seems like a lot of numbers to remember; imagine I am looking for a Xirrus array in say the Cafeteria on St. Phillip's Street. Yes DNS could solve this, but the IP's do sometimes get changed and that could result in a nightmare if one is changed and not the other. 

The solution to me seems a DHCP/DNS combo.

So to sum up the question, **from a management standpoint, why is it a good idea to use Static or DHCP addressing on equipment?**

Answer: 
I’ll keep this post about your situation specifically.

First and foremost, managing over 3,000 devices with static IP addresses is just plain foolish. DHCP is a well-known and established protocol that solves the tedious task of manually assigning and fixing manual IP addresses. If they are that concerned about making sure they have control over **every** IP address on their network, set them as DHCP reservations. Even from a security standpoint, you don’t stand to benefit *that* much from eliminating DHCP servers. 

By sticking with this route, you will lose:

* **Change management capabilities**
* Customer insight

The big hitter on this list is change management capabilities. If you need to swap IPs around, you really don’t have a good way to do this; and that makes (or will make) your life arduous. If your teammates aren't on board with it and want to stick with their old ways, try to rope in your management and inform them of what a colossal waste of time it is. 

Regarding your nifty IP scheme; you will still be able to maintain that; If anything, to a greater degree. [IPAM](https://networkengineering.stackexchange.com/questions/7250/what-is-ip-address-management-why-its-needed-how-does-the-vendors-like-bluec/7253#7253) gives you the capability to drill down into smaller and smaller subnet ranges, making it seemingly easy to implement in your case. This will allow you to cascade further and further down into the building/device class you desire.
I suppose it boils down to what you mean by *networking devices*. Routers, switches, firewalls, access points, etc., etc. do need to have fixed, known locations. It's a bad idea to rely on DHCP and DNS -- even where "sticky" addresses are used.

One network fault is all it takes to learn how bad an idea that is... say your network is broken *somewhere*. You (in fact, the entire engineering department) happen to be on the side that cannot reach DNS, and probably DHCP too. If all of your gear has random, unknown DHCP assigned addresses, you'll have no map, and no access to create one. If your workstation is portable, off, etc. *you* may not have an address from which to work. Various networking devices may start dropping off the network as their leases expire, other devices (like your laptop) coming online for the day won't have an address, rebooted equipment won't have addresses... A failure of the DHCP server will net a similar effect. A failure of the DNS server(s) will leave a mess of old, invalid registrations, and a bunch of holes where new registrations didn't happen -- nothing I know of will retry.