The Problem
I’m working with a customer who has a large number of devices that are configured with static IP addresses and are not in their local DNS or WINS. Some of the devices are printers, so the local PCs are configured to access the printers via static IP address assignments.
The printer VLANs are very large, spanning large buildings or between buildings. Spanning tree loops are occasionally created (“please clean up that dangling cable – just plug the connector into that empty wall jack“). To reduce the size of the spanning tree domains, we need to split the existing subnet into smaller subnets. This means readdressing the printers.
The “Just Get It Done” Solution
The obvious solution, which doesn’t require much thought, is to create a new subnet and VLAN for each smaller region, find each printer, change its address, move its port to the new VLAN, then change the print queue on each PC that references that printer. To implement this solution, a maintenance window needs to be selected that won’t impact the customers who rely on printing services for the duration that it takes to make the conversion. We would also need a well-coordinated team to make changes to all the PCs, because I’m certain that every PC references at least one printer. And I’ll bet that some PCs reference multiple printers, so we may have to reconfigure some PCs multiple times, as the printers that they reference get moved. We could spend some more time identifying sets of printers to move at one time too, to try to make sure that we only have to visit each PC once.
The above approach isn’t very good. It is simply repeating the configuration that already exists and which is not very flexible. Any future needs for readdressing require repeating the same reconfiguration process.
A Better Solution
What are the requirements for a better solution?
- Reference printers by name, so that future addressing changes don’t require that the PC configurations be changed.
- Allow printer subnets to be readdressed or subdivided with minimal manual reconfiguration.
- Improve the flexibility of the system, allowing readdressing of printers from a common location using automated processes.
What can we do to achieve these requirements?
We can use DNS (and/or WINS) to name the printers, so that PCs can be configured once and then use the name of the printer thereafter. This provides us the flexibility of changing the address of a printer without having to reconfigure the PC. DHCP can be used to assign addresses to printers from a central location (or a few redundant locations, to provide resiliency). Dynamic DNS will need to be used so that DHCP can update addresses in DNS.
We can now use the following steps to update the printers and PCs so that future changes are easy to implement.
- Identify all printers, their current IP address and MAC address. We had to identify all printers and their IP addresses anyway, so all we’re adding is the requirement to collect the MAC address of each printer.
- Create DHCP static assignments for the printers and modify the printers to use DHCP for IP address assignment. We’re using the existing addresses, so the PCs’s can still access the printers. We’ll need a DHCP server, which should already exist anyway to assign addresses for client PCs. Its only requirement is to support dynamic DNS updates to the internal DNS servers, causing the printer names to be loaded into DNS as the printers are moved to DHCP.
- Reconfigure a few PCs to use the DNS name of the printer(s) that it needs. Verify that the printers can reference the printers if the printer’s IP address changes, by forcing an IP address change through DHCP. This makes sure that each type of PC operating system and configuration will work correctly when the printers are readdressed.
- Reconfigure the remaining PCs to reference the printers that they commonly use. Since the reconfiguration is only replacing the number with a name, this reconfiguration can be implemented over the course of several days or even weeks. There is no need for a “flag day” conversion.
- Create new VLANs and Subnets for the printers, each with a smaller scope than with the old printer VLAN/subnet.
- Set the DHCP and DNS refresh timers to low values, like 30 minutes.
- Update the static DHCP assignments for the printers that will be moved to use the new IP addresses.
- Reconfigure the each printer’s switch port to use the newly created VLAN/subnet. The printer will soon renew its address and receive a new address assignment for the new subnet. The name and the new address will be automatically updated via dynamic DNS.
- Spot check a few PCs to make sure that the printer address changes are working as expected.
Much of the above process can be performed by one person over the deployment period with minimal disruption of production use of the printers. Only the PC configuration changes will require more staff to implement. (And if you have a tool to automate PC updates, the printer configuration updates can be automated from a central location too.)
An added benefit of using DNS for printer access is having the ability to easily direct PCs to an alternative printer when one printer fails. If a printer fails, its name can be linked to the IP address of another working printer (that uses the same drivers) and no reconfiguration of the PCs is required.
I just found out that most of the PCs use print servers, which in turn use IP addresses in their configurations. We have validated that the print servers can use DNS names, so the above process will work, helping us do a slow move from using static addressing to DHCP and DNS.
Of course, we are planning to take advantage of the Infoblox DHCP, DNS, and IP Address Management tools to help us manage the above process. I’m sure that NetMRI will also come into play to identify the printers within the infrastructure, through its network discovery. Automation helps us through another challenge that would be incredibly boring if we had to do it manually.
-Terry
_____________________________________________________________________________________________
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
