You come into the office on a Monday morning after a weekend network upgrade. Almost everything appears to be working normally, except your networked laser printer is not visible on the network. Which of these would be the most likely cause of this issue?
A) The printer’s print queue is corrupted
B) The printer is out of ink
C) The new network configuration can’t support laser printers
D) The printer has a bad IP address
E) The printer had a long weekend and needs another cup of coffee before it really kicks in
The answer: D) The printer has a bad IP address
If a major network event has occurred, then it’s possible that the devices on the network need to be restarted with the updated network configuration information. Since printers are rarely restarted, a manual reboot may be necessary before the other network devices can see the printer.
 |
Want to know more? Watch “Troubleshooting Printer Problems.”Resolving printer issues is one of the more challenging aspects of your CompTIA A+ career. The printing process includes different devices, network connections, and moving parts. In this video, you’ll learn how to gather troubleshooting information, identify solutions, and resolve some of the most common printing issues. |
I agree more with the A answer here. In any networked environment, printers are configured with static IP addresses. It would be bad to do it as a DHCP address since then the printer queue would not be able to get to the printer. Therefore they should not have a bad IP address after any network incident. Answer C would be more believable if it said the network could not recognize the printer IP address.
It would be unusual to find anyone using static IP addressing, except maybe in a very small office (even then, most printers are still configured by default with DHCP). Although DHCP is most often used to provide IP addressing from an available pool, certain addresses can be reserved for devices such as printers or servers. If the network configuration changes, you only need to update the DHCP server to change the network configuration of these reserved devices.
Client PC’s – DHCP
Servers – Static IP’s
Printers – Static IP’s
Network Devices – Static (with management ports on separate vlan of course)
I set statics on printers because I don’t want the addresses to change – the Monday Morning scenario is one reason why – and sometimes filter printer traffic with acl’s to manage access/bandwidth. (Some are really noisy on the wire. Check it out with wireshark.)
Just me though. I’ve just never seen a printer use dhcp in a business environment.
Am I weird or what? 🙂
John
BTW – Nice site with excellent resources! Glad I found it!
The problem with static IP addresses on devices is that they have the potential to break if something changes on the network. In this question, the network did dramatically change, and if the IP addressing scheme of the subnet was modified (or printers were moved to a different subnet, or the entire floor was split into different subnets), the static IP addressing on the printers would have caused the printers to appear broken on Monday morning. It’s much more typical in mid-size to large environments to find all devices using DHCP with DHCP reservations used for devices where the IP address shouldn’t change (printers, servers, etc.). With DHCP reservations, all IP addresses can be centrally managed and you don’t have to wander around a building and manually reconfigure all of your printers after a major network change!
One notable exception is the use of management IP addresses on network infrastructure devices. Since you need to access these devices if there’s a network issue, you almost always see these devices configured with static IP addresses.
I too have set printers to static addresses..The network environment I work is a small company relatively speaking..However in the above scenario would a corrupted print queue really prevent the printer from being seen on the network even if it was DHCP configured?
Holden, a corrupted print queue wouldn’t prevent users from seeing the printer on the network, so it’s not the most likely cause of the issue listed above.