NDPS 3.0, which is included in NetWare 6, is written to support IP natively. All communication between NDPS clients and NDPS back-end services will automatically switch to use the protocol or protocols available at the client and server. Thus, much of the effort to switch to an IP network will consist of configuring the clients and servers to use IP only. (This is normally done during the installation process.) However, there are some protocols used by NDPS gateways to communicate with printers that have inherent IPX dependencies. This section provides guidelines for switching these configurations to use IP-based protocols. None of the changes described will require the clients' installation and configuration to change.
The following scenarios are described in this section:
Several third-party gateways support both IPX-based and IP-based communication to printers. The process to switch a third-party gateway to use IP is likely to differ from gateway to gateway and should be explained in each gateway's documentation. If a specific third-party gateway doesn't support IP, you might need to use the Novell gateway.
The Remote Printer protocol (RP) is inherently IPX-based. Configurations using printers in remote printer mode can use one of the following configurations to conform to an IP setting:
As stated before, the best way today to communicate to a printer with NDPS is through a third-party gateway. If you plan to reconfigure a printer to support IP, you should check whether a third-party gateway for that printer has become available.
Option #2 is simpler and offers better performance than option #3, but it requires the printer to support LPR/LPD mode and have IP configured. Options #4 and #5 are also simple, but they might not be a viable option in some settings because they require the printer to be directly attached to a workstation or server. Of the three options, only #5 maintains a Pure IP environment.
Option #3 requires an isolated IPX segment to exist in the network. Communication with this segment can be filtered and/or translated by a Migration Agent, thus maintaining the IP segments free of IPX communication. The advantages of option #3 are that it doesn't require any changes to the current printing configuration and doesn't add much overhead to networks that already manage isolated IPX segments.
The best alternatives for this scenario to support IP are to (1) use a third-party gateway (see Migrating a Printer in RP Mode to IP) or (2) reconfigure the Novell gateway to communicate with the printer through a different protocol altogether. If neither of these options are feasible, the following configuration is available to isolate the IPX traffic generated by printers in QServer mode:
The advantages of this option are that it doesn't require any changes to the current printing configuration and doesn't add much overhead to networks that already manage isolated IPX segments.