Utility services like DNS, DHCP, NTP, AAA, and network management contribute to a smoothly running network. I’m an advocate for designated utility subnets for these services. Why have utility services subnets? It allows the network administrators to more easily monitor, manage, protect, and provision the services. It becomes much easier to troubleshoot problems with the services when they are in known locations with a few well-known access paths and methods.
What size network needs utility subnets? Are they appropriate for a small network comprised of less than ten routers and switches? Once the network is large enough to require multiple subnets, it is appropriate to consider one or more separate services subnets. Very small organizations may rely on a single services subnet while larger enterprises will want two or more redundant services subnets. Some organizations may want to provision services subnets per function in order to make ACL and security easier to manage for each function.
MPLS networks in particular will benefit from services subnets. It is much easier and less expensive to consolidate services in a few places and create the appropriate VRF import lists and firewall rules to restrict undesired connectivity while still providing access to a common set of services. In addition, as networks begin the migration to IPv6 and DNS becomes more critical to network operations, the services subnet concept becomes more important.
Where should services subnets be located? Within an organization’s data centers makes a lot of sense, but separate from the application subnets. Protect the services from attacks from the network clients and servers with firewall rules that only allow the desired connectivity. It is easier to design good security around a few services subnets than when those same services are on general application subnets where a lot of different firewall rules must be concurrently implemented.
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html