DHCP, DNS, and IPAM (DDI) continue to grow in complexity of management and troubleshooting as networks grow more complex. Your customers expect operational simplicity, speed, and performance. Without a centralized contextual view of your entire DDI environment, it will become impossible for you to meet these expectations as multicloud and SASE architectures become mainstream.

Sustainable Network Management for DDI - Whitepaper

Sustainable Network Management for DDI

DHCP, DNS, and IPAM (DDI) continue to grow in complexity of management and troubleshooting as networks grow more complex. Your customers expect operational simplicity, speed, and performance. Without a centralized contextual view of your entire DDI environment, it will become impossible for you to meet these expectations as multicloud and SASE architectures become mainstream. 

More about this whitepaper

An understanding of common use cases DDI admins deal with regularly

Solutions to pain points that arise when using native DNS, DHCP, and IPAM tools

A deep dive of the benefits offered by modern DDI solutions like Micetro

What you get

Get access to whitepaper.

Micetro, by Men&Mice, is a sustainable DDI network management solution that gives you orchestration of your entire DDI infrastructure on-premises and in the cloud. Micetro provides one software solution your teams will feel comfortable using, making migration and management less risky and rip-and-replace projects a thing of the past.

Conceptually DNS (Domain Name System), DHCP (Dynamic Host Configuration Protocol), and IP (Internet Protocol) addressing, or DDI, implementations are not difficult to manage. When admins and engineers first start learning about how these technologies are managed, they often learn about how to install the DNS and DHCP MMC snap-ins on a Microsoft server and it seems straightforward. However, implementing and managing DDI infrastructure in the present-day real world is not simple.

Depending on the size and architecture of your enterprise network the data you need to build a full picture of your DDI system is scattered everywhere. The more sites you have, the more your data is scattered and managed by several different people or teams. You may be using spreadsheets to manage this IP address information. This is very common for large and small enterprises.

You may also be working with several different vendors for DNS and DHCP. Perhaps you’re obtaining DHCP information from ISC, Microsoft, or Cisco devices. You may be managing DNS via Microsoft, BIND, AWS, Azure, and some external DNS provider.

The above example shows what solutions may be used at just one site. This site may include a data center, campus, and some branch connections. It may look the same or completely different from another site. You may have multiple sites with Layer 2 extensions or possibly multiple sites with overlapping networks that need to be managed separately.

A developer or application owner puts in a ticket for new IP addresses and DNS names. Typically this can take days or even weeks to resolve the ticket when not using a centralized DDI solution. This kind of ticket generally needs to go through several teams all working with different tools and all dependent on each other and the management tools they’re using. The changes being made may need to go through an approval committee as well, and then be implemented during a previously scheduled change management window. So even though everyone is working quickly on their part of the ticket, the time does add up.

Modern enterprise applications are not simple to bring to market either. The idea of the three-tier application is mostly just theoretical at this point.

In fact, most of these tiers will have multiple bare metal servers, VMs, and containers within them, all needing IP addresses and DNS names. Afterall, you don’t want developers hard coding IP addresses into their apps. That will create problems later.

Taking, as an example, just one of these services, the following is likely the process that an IT team will go through to complete the task:

Pick the correct internal network (or subnet) to use that has the proper access to other services with which this service may need to connect internally

Find an available IP address in that network. This could mean scouring several different spreadsheets maintained by multiple people.

Double check that the IP address isn’t already being used either through static assignment or being served out as part of a DHCP scope

If you’re using DHCP, make sure that the IP address is excluded on all relevant DHCP servers, especially if you’re using split-scope DHCP

If it’s available, make sure to take it off the list so that it doesn’t get used by someone else.

Assign that IP address to the server either manually or through the use of DHCP reservations

Create a DNS record (likely an A record) for it to be used internally

Possibly create a DNS PTR record for reverse lookups

Either create a DNS TXT record to record notes for what this new DNS name is for or record it back in your spreadsheet because documentation is important.

If this service needs to be accessed by external users (or customers) choose an external IP address, or port, for these users to get to it. You may be using Network Address Translation (NAT) especially in the case of IPv4. There are a few ways to accomplish this, but there needs to be an IP address to which we assign to a DNS record.

Enter an external DNS name so that people can get to it from the outside, likely with a DNS A record.

Register that A record so that it appears on the Authoritative DNS server.

Create a txt record or document this information in your spreadsheet.

The above list is 15 fundamental steps long without extra processes which may be standard for your company. They also rely on humans not making any errors as well as remembering and prioritizing the documentation process. The above process is simply not sustainable for enterprise environments with dozens of DNS and DHCP servers as well as several teams managing and depending on this information. It becomes even more unsustainable as IPv6 becomes more prevalent internally and externally for several reasons, not the least of which being the IPv6 isn’t easily read by humans due to it being 128 bits and written in hexadecimal.

There are a few main functions for which we count on DDI management, no matter how you’ve implemented it.

Keeping track of which IP addresses are in use and which may be assigned next

Understanding which DNS names are assigned to which IP addresses as well as easily finding reverse lookups of IP to DNS name

Managing automatic assignment of IP addresses to devices and tracking DHCP scopes

Knowing which IP ranges are used for which network (Wireless, Server, VOIP, WAN, SD-WAN, LAN, etc)

Ensuring Active Directory Site IP address configurations are in sync and validated

Managing redundancy for DHCP and DNS in case of an outage or performance issue

Easily parse through indexed custom properties and enable fast search and filtering

Enabling proper and detailed access to and auditing of the entire DDI environment

The above functions require multiple native tools, and even with multiple native tools, it’s not possible to achieve all of the above capabilities.

While there are certainly access controls for any DNS and DHCP implementation, they are not replicated across your DNS and DHCP services. You may be using Active Directory Security Groups to manage permissions in Microsoft, Linux permissions for ISC implementations, and then the access controls from other service providers like public cloud or external DNS service providers. Because of this, there’s no way to get centralized audit trails or reports for your entire environment. Also, due to the sheer amount of access control tools, it becomes nearly impossible to manage and keep these users, groups, and roles up to date.

Depending on the tool you also aren’t likely to get all the information you need even after digging through the logs. To get proper details of the history of CRUD (Create, Read, Update, Delete) operations, you need to understand who made the change, when the change was made, what the change was, and why the change was made. Without that information, it becomes difficult to troubleshoot and understand the information in any meaningful way.

As multicloud becomes ubiquitous and SASE architectures begin to catch on, organizations need to embrace sustainable networking models. Sustainable network management solutions allow enterprises to abandon the old rip-and-replace methodology by using a software overlay solution that provides centralized visibility, management, and security.

Micetro: A Sustainable Network Management Solution

Micetro, by Men&Mice, is a sustainable network management software solution focused on DDI. Its easily upgraded overlay architecture allows Enterprise IT teams to enjoy the benefits and security of viewing and controlling their Enterprise DDI solution in a matter of seconds as opposed to the old, lengthy ways of managing several different solutions in silos as described earlier in this paper.

Micetro provides companies with a viable alternative to ripping out solutions, instead of continuing the cycle of technical debt. Companies can now safely and securely deploy, view, manage, and even easily migrate to the most appropriate on-premises and cloud DDI solutions without undergoing risky, expensive, and unsustainable rip and replace projects.

No matter which DNS, DHCP, or IPAM tools you’re using on-premises or in the cloud, Micetro will allow you to manage all DDI information from the same place.

There are different views for DNS, DHCP, and IPAM (DHCP information is under the IPAM tab), but they are similar enough to lower the learning curve for managing Micetro. While the solution contains individual modules that can be licensed separately, the power of the solution lies in the integration.

One of the major benefits of Micetro is that it will work in any greenfield or brownfield environment. Importing your information into the solution is easy and flexible. Most commonly users will import their IP information from spreadsheets, which can be done in a few different ways:

Networks – Import the framework, or the network boundaries and let Micetro discover and validate which IP addresses are being used

IP Addresses – Import everything and have Micetro validate which IP addresses are being used

Devices – Import information from devices such as routers and access points

DHCP Reservations – Import information about DHCP scopes in DMZs or other networks that Micetro can’t get to due to security boundaries

Micetro will validate whether IP addresses are in use in three ways: ping (ICMP), SNMP, and LLDP. Now within Micetro you can rely upon any IP address information, such as whether it’s claimed, assigned, or free, to be correct. Any IP conflicts will also be quickly pointed out so that corrective action may be taken.

Once IP information has been imported you may choose to connect DHCP and DNS services to Micetro to sync DHCP and DNS information with the Micetro database. The information gained from DNS and DHCP services will also work to validate the use of IP addresses and provide more contextual information such as if an IP address has been assigned a DNS name or if it’s part of a DNS scope.

Now that you have an IP database you can count on, it’s also now possible to get IP addresses back. There are cases where customers have deployed Micetro and found thousands of IP addresses that were no longer in use due to issues with DHCP server processes and simple human error.

Custom properties may also be something you’ve been keeping track of in your spreadsheets. You can put those into the Micetro solution as well. Whether you’re tracking VLAN IDs, Regions, or even ULA (Unique Local Address) in the case of IPv6, you can add them in here and that information will all be indexed making it easily searchable.

By adding custom fields and specifying what will be required information, you create consistency within your network making it even more stable and easier to troubleshoot when issues do arise.

Micetro will connect to any underlying DHCP service such as ISC, ISC KEA, Microsoft, or other devices such as routers.

When viewing DHCP scopes, you can easily see which scopes are standalone, which belong to failover clusters or active/active clusters, or which are split scopes. DHCP information is pulled regularly by Micetro from the DHCP servers and along with this information, lease history is pulled as well. Now, within Micetro, you’ll have the reservation information, exclusion information, and all the associated DHCP options that have been assigned as well.

IPv4 is still very commonly used, especially internally. With IPv4 comes the possibility of DHCP scope overutilization. Within Micetro you can easily see scope utilization to proactively avoid having any of your users stuck without an IP address when they connect to the network.

Whether in the DNS or DHCP view, you have the ability to create folders and smart folders.

Folders – Manually created static containers which allow you organize networks and zones any way you like. Organize by project, user, site, or anything else that helps you clear away the white noise and makes it easier to work on your prioritized areas.

Smart Folders – Manually created dynamic containers, like saved filters. Networks and zones will automatically be added to these structures if they fall under the definition of the smart folder.

Both folders and smart folders may be nested to quickly get to the exact information you need.

Under the DNS view you have all the information from DNS services, similarly to how it was gathered for DHCP. You’re able to see all of the DNS zones and how they’re classified as primary, secondary, forwarding zones, caching zones, etc.

When double clicking into a zone, you may now see all of the records associated with that zone and the various record types. Micetro makes creating new records easier by suggesting next available IP addresses within the range you’d like to use.

In Diagram 9 you’ll notice there is the option to “Add to Request.” Depending on your role, you will have one or two options there: Create Now or Add To Request. The Create Now option is there for users who have permissions to make a change right now. The change will be sent out to the appropriate DNS services and happen immediately.

The Add To Request option is there for users with access to a particular DNS zone, but who don’t have the permissions to make changes directly. These requests will go into the Workflow queue and an approver may then Reject or Approve them.

If the request is approved, the change may either take place immediately or it may be put into the schedule queue. Then one or multiple changes may be scheduled to happen automatically during the appropriate maintenance window.

The DNS Workflow capability not only acts as a way to automatically schedule changes, but is the enterprise grade answer to giving even more granular access to DNS records within zones without having to create multiple, unnecessary access roles.

Micetro uses a pure Role Based Access Control (RBAC) model. Users and Groups may be created in Micetro or imported from other systems such as Active Directory. These users and/or groups are then assigned roles within Micetro. Permissions are only assigned to roles, they may not be assigned directly to users and groups.

General – System-wide roles that may be applied to the entire system, the entire DNS or DHCP infrastructure, or other objects across the entire DDI environment.

Specific – Roles the apply to a specific object within Micetro such as a DHCP Scope, IP Range, or DNS Zone.

Legacy – Roles that are automatically created when an organization upgrades from a previous version to version 10.1 of Micetro. These legacy roles ensure that the access permissions already set up in previous versions continue to work as they should. -

Modern, diverse networks that are managed with often globally distributed teams need a reliable, intuitive, and secure method to control access to tens of thousands of network assets. Micetro takes care of all of this no matter which underlying DDI services companies choose to use.

Men&Mice is a preferred Microsoft partner due to the unparalleled integration between the two. In fact, as long as Micetro Central is installed on a Microsoft server, Micetro doesn’t require agents on Microsoft DHCP and DNS servers and will work with full functionality.

Active Directory Users and Groups Integration

BlueCat acquires Men&Mice to boost its DNS, DHCP and IP address management platform and help organizations improve network resiliency and simplify network management.

Sustainable Network Management for DDI

More about this whitepaper

What you get

Trusted by

Get access to whitepaper.

Products

About Us

Support

Learn More

Legal