LaserWriter 16/600 PS: Problem w/ Novell Services on WANs (5/95)


I ran into some problems with the Apple LaserWriter 16/600 PS, corrected by turning off the Novell option in the printer. Here is the problem I had with the LaserWriter 16/600 PS on my Novell WAN (Wide Area Network).

The Novell traffic generated by two LaserWriter 16/600 printers may have been generating as much as 40% or more of our traffic back to our backbone, and our T1 has been "bumping" 100% utilization on occasion, which is unusual for our network. We noticed a dramatic drop in traffic after to turning off the Netware support on these printers.

The captures with a network sniffer show the printers attempting to configure themselves as queue servers for Netware. To do this they attach to each Novell Netware server advertising print services and see if any queues match those on the print server. If they do not succeed they in one pass of all servers they try each again, and again, and again. It looks like the printers poll continually.

Is there a way to change this behavior?

The IPX implementation on the LaserWriter 16/600 PS has a potential problem on some networks. The problem is a potential degradation of network performance, especially across WAN links, when the Netware mode on the Apple LaserWriter 16/600 PS is enabled (the default) and the Novell server(s) have PSERVER queues.

When the LaserWriter 16/600 PS first starts up and periodically thereafter, it tries to attach to each Novell Netware server that is advertising print services to see if any queues on the server should be serviced by the printer. On a large, multiple server or multiple printer network, these informational packets can consume a large amount of bandwidth. The impact can be greater if the network is also on a WAN, because the informational packets stretching across slower speed WAN links may have greater impact on those links.

The solution is to use LWPMAN to configure the printer for specific servers that are local to the printer, to prevent unnecessary traffic from being sent everywhere. As a temporary fix, or a secondary fix, you can adjust the queues scan time defaults from within LWPMAN as well (if the queue is scanned less often, less packets are transmitted, but the job remains in the queue, unserviced for a longer stretch of time).


Support Information Services

Published Date: Feb 19, 2012