NetWare/IP Q & A
Articles and Tips: article
01 Jun 1997
Q.What is the best tool for analyzing NetWare/IP communication?
A. Use Novell's LANAlyzer for Windows. It will properly decode NetWare/IP packets, including DSS-DSS and DSS-NWIP synchronization. You may also try protocol forcing with Network General's SNIFFER-force all UDP packets on port 0xABCD (default NWIP port) to decode the data portion as XNS.
Q. Does NetWare/IP work with NLSP (Novell Link State Protocol)?
A. Yes. You may enable NLSP on IPX links to NetWare/IP servers. However, NetWare/IP links do not propagate NLSP domain information. Therefore, two NLSP domains connected through NetWare/IP view the NetWare/IP link as a SAP/RIP compatible link, not as a NLSP link, and the two NLSP areas are viewed as separate NLSP domains, not as a common NLSP domain.
Q. How does NetWare/IP's performance compare to IPX?
A. Technically, NetWare/IP is 5-8% slower than native IPX. However, when implemented over slow WAN links, most customers actually notice a net performance increase as NetWare/IP eliminates SAP/RIP traffic from consuming unnecessary WAN bandwidth. Most end-users will never notice a performance difference between NetWare/IP and IPX.
Q. Do all applications work with NetWare/IP?
A. Yes. NetWare/IP was engineered to provide complete backwards compatibility with existing IPX applications. Novell has yet to discover an application that won't run with NetWare/IP. However, be aware that broadcast based IPX applications that do not use SAP for service advertisement are limited to the broadcast range of IP. For example, a broadcast based IPX game, such as DOOM, will typically be limited to the local IP subnet, unless IP UDP broadcast forwarding for the NetWare/IP UDP port has been enabled on your IP routers.
Q. When I unzip the NetWare/IP files, I receive errors. Is this file corrupted?
A. No. The NetWare/IP files contain very deep directory structures that may not unzip correctly if you are unzipping on a DOS machine. DOS only supports a directory path name of 64-bytes. If you experience any errors while unzipping the NetWare/IP files, please try unzipping the files to a directory off the root of your drive, such as C:\NWIP, or by using the "MAP ROOT" command on your NetWare server.
Q. I've heard that NetWare/IP is tunneling? Is this true?
A. NetWare/IP isn't tunneling-tunneling implies that ALL information is sent through the IP tunnel, whether the information is a broadcast or point-to-point communication. NetWare/IP encapsulates point-to-point information inside a UDP packet. Broadcasts are never encapsulated; instead, they are handed directly by a NetWare/IP server or DSS. Novell determined that by maintaining the IPX header in the NetWare/IP packet we could ensure maximum backwards compatibility.
Novell encapsulates an IPX header in a UDP packet, while Microsoft encapsulates a NetBIOS header inside of a TCP packet. While both solutions use encapsulation, only Novell has committed to provide a truly native IP solution by removing the IPX header from the UDP packet. An NCP within a UDP or TCP packet is currently under investigation and may be implemented very soon.
Q. How well does NetWare/IP scale?
A. Very well. Novell currently has several customers than have implemented single NetWare/IP domain solutions with more than 5000 NetWare/IP clients and 200 servers. One customer has successfully deployed 15,000 NetWare/IP clients and > 600 NetWare/IP file server. Testing in Novell's SuperLab facility verified that NetWare/IP could scale to more than 2000 NetWare/IP servers within a single NetWare/IP domain. Novell even has two customers that are deploying NetWare/IP to potentially 70,000 - 120,000 NetWare/IP desktops, and 5,000 - 11,000 file servers. Implementations of these magnitudes take time, but Novell is committed to make these configurations successful.
Q. I would like to completely remove IPX from my local segment, but can't because many of my printers require IPX to service NetWare queues. Do you have any suggestions?
A. Yes. If your printer supports LPR-LPD printing, use the LPR_GWY.NLM that is included with NetWare/IP 2.2. This NLM works in conjunction with PSERVER to pull print jobs from a NetWare print queue for printing on a LPD (line printer daemon) device, such as a printer.
Q. How do I configure LPR_GWY printing?
A. When configuring a printer with NWAdmin, select "Unix or TCP/IP" as the type, and enter the DNS name of the IP printer.
Q. Is NetWare/IP supported on SFT III?
A. Yes. NetWare/IP 2.2 is supported on SFT III.
Q. Is NetWare/IP enabled for SMP (symmetric multi processing)?
A. Not currently. A scalability increase will result when BTRIEVE.NLM is fully SMP enabled, thereby improving the performance of DSS. BTRIEVE.NLM is no longer owned by Novell, but is currently undergoing SMP enabling. However, many customers have successfully implemented very large NetWare/IP implementations without the need for SMP.
Q. How does NetWare/IP use DNS?
A. NetWare/IP servers and client may optionally query DNS during initialization to locate domain SAP/RIP servers (DSSes). NetWare/IP servers and client are usually configured for specific DSSes and NetWare/IP servers, but DNS may be used as a last resort to locate NetWare/IP services during initialization.
Q. Is DNS required for NetWare/IP?
A. No. However, Novell strongly recommends configuring DNS with the NetWare/IP domain information to provide an additional level of fault tolerance for client initialization. DNS is also used in NetWare/IP DSS management to "Display All DSSes" for the NetWare/IP domain. If DNS isn't configured for NetWare/IP, administrators may experience lengthy timeouts during administration as NetWare/IP attempts to verify NWIP information within DNS.
Q. Does NetWare/IP 2.2 provide DNS services?
A. Yes. NetWare/IP 2.2 includes DNS that is BIND 4.8.3 compatible. Any NetWare 4.1 server may be configured as a master or replica name server of a DNS domain. The master or replica DNS database may exist on any DNS platform-for example, it is possible to configure a NetWare 4.1 server to maintain a replica DNS database where the master DNS database resides on a Unix machine.
Q. Does the NetWare/IP DNS domain contain entries for all NetWare/IP servers and clients?
A. No. The NetWare/IP DNS domain only contains name server records (ns) for selected DSSes of the NetWare/IP domain. NetWare/IP servers and client that use DNS host names may be located anywhere in the DNS hierarchy.
Q. Does Novell support Dynamic DNS?
A. Yes. Several utilities and applications, such as UNICON and NFS, exploit the dynamic DNS feature of NetWare DNS servers. This permits adding or removing DNS records without restarting the DNS server.
Q. What exactly is a DSS?
A. DSS is an acronym for Domain SAP/RIP Service. NetWare over IPX uses SAP broadcasts for services advertisement and queries, but broadcasting in an IP environment is often not possible across IP subnets. Therefore, an alternative name service for advertising NetWare services and routes was created. This name service, known as DSS, replaces the IPX broadcast based SAP and RIP. The DSS is simply an NLM built on the BTRIEVE database engine for storing NetWare service and route information that would have been broadcast as SAPs and RIPs in an IPX environment.
Q. What improvements to DSS does NetWare/IP 2.2 include?
A. The DSS.NLM includes two important features. First, NetWare/IP 2.2 provides the capability to filter SAP/RIP records between DSS servers. Second, NetWare/IP 2.2's DSS.NLM has been optimized for greater scalability while consuming fewer server resources. Existing NetWare/IP 2.1 customers generally notice a 25% to 50% gain in DSS performance, as evidenced by CPU utilization reduction, after upgrading NetWare/IP 2.1 to NetWare/IP 2.2.
Q. How does NetWare/IP 2.2 DSS SAP filtering work?
A. DSS SAP filtering determines the type of SAP/RIP records exchanged between the secondary DSS servers and the primary DSS. It is possible to filter on a SAP type (i.e., advertising print server), SAP name, including wildcards (i.e., NWIPDEMO-FS1, LEX*, HP*), or even subnet (i.e., don't include records from 188.8.131.52). Note that this only affects DSS-DSS synchronization, NOT DSS-NWIP synchronization. If NWIP-DSS SAP filtering, or more granular SAP filtering is desired, consider using the FILTCFG.NLMthat ships with NetWare 4.x.
Q. What SAPs does NetWare require for NetWare 4?
A. NetWare 4.x uses some common SAPs. Generally, you will want to propagate the following SAP types: 0x0004 (NetWare 386 server), 0x0278 (NetWare Directory Services), 0x026B (Time Synchronization), and 0x0107 (RCONSOLE). You should understand the ramifications of filtering any of these NetWare SAPs. For example, it is possible to filter the time synchronization SAP (0x026B), but alternative time synchronization steps must be taken, such as implementing time synchronization configured lists. Other SAP types may be required by your third party software. For a list of the known SAP types, please download LISTNG.EXE from the Novell support channels, such as CompuServe or www.Novell.com.
Q. Should every NetWare/IP server also be configured as a DSS?
A. No. The DSS functionality should be limited to a few select NetWare 4.1 servers. It is not necessary to place a DSS at every geographical site that contains a NetWare/IP server or client. DSS servers should be placed at aggregation points within your WAN infrastructure, or at locations were where several (>15) NetWare/IP servers are located.
Q. How many DSSes should I deploy?
A. Each DSS can handle between 50 to 100 NetWare/IP servers, depending upon such factors as the DSS hardware (CPU, memory), number of SAP/RIP records, DSS-DSS and DSS-NetWare/IP synchronization intervals, and how often SAP/RIP information changes within your network. Generally, plan on at least one DSS server per 50 NetWare/IP servers. If your configuration is less than 50 servers, you should have at least two DSS servers to provide fault tolerance.
Q. Should all DSS servers have name server (ns) records in DNS?
A. No. Only a few selected secondary DSS servers should have ns records in DNS. Remember that these secondary DSS servers will be contacted by NetWare/IP servers and clients if other DSSes aren't available during the initialization process. Plan accordingly-only enter those DSS servers that you wish to make available through DNS queries.
Q. Should I enter a name server (ns) record in DNS for my primary DSS?
A. No, unless your configuration is less than 50 servers and you've only deployed two DSSes. Generally, the primary DSS shouldn't have a name server (ns) record in DNS to prevent NetWare/IP servers and clients from using the resources of the primary DSS. In larger configurations (>50 NetWare/IP servers), the processing power of the primary DSS is reserved to maintain synchronization of the secondary DSS server databases.
Q. Should I dedicate servers to perform the DSS functionality?
A. If your configuration is very large (>200 NetWare/IP servers), strongly consider configuring a lightly-loaded or dedicated NetWare 4.x server as the primary DSS. If a single secondary DSS will provide DSS services to more than 50 NetWare/IP servers, consider dedicating a NetWare server to provide this functionality. If a DSS will provide DSS services to fewer than 30 NetWare/IP servers, there is no need to dedicate a server as a secondary DSS. Of course, several factors previously listed will affect DSS performance, but these NWIP-DSS ratios generally work in most configurations.
Q. Can a single NetWare server provide both DNS and DSS services?
A. Yes. DNS, DSS, DHCP, LPR_GWY, and NWIP.NLM may run concurrently on any existing NetWare 4.x server.
Q. Is there any way to track CPU utilization on a DSS server?
A. Yes. Load the MONITOR.NLM, select "Processor Utilization", and look for DSS related processes.
Q. Is there any way to track the amount of data transferred during DSS-DSS and DSS-NWIP synchronization?
A. Yes. From the NetWare/IP server or DSS, load Unicon, select "Configure Error Reporting", select "Configure Error Logging/SNMP Alert Levels", and set the first two selections to "DEBUG". You'll notice new entries on the PKERNEL screen that show the type of synchronization traffic (either DSS2DSS or DSS2NWIP), the IP address of the remote server, the number of SAPs and RIPs exchanged, and the size of the data transmitted in bytes.
Q. What happens when the Primary DSS is unavailable? How long before records time out?
A. If the primary DSS is unavailable, all secondary DSSes will 'freeze' records that are learned from other DSSes. The secondary DSS will continue to accept and distribute SAP/RIP records to/from any NetWare/IP server, thereby permitting all NetWare/IP servers that share a common DSS to function normally. The secondary DSS will also continue to report the SAP/RIP records learned from the primary DSSes to NetWare/IP indefinitely.
Q. Is there any way to look at the contents of the DSS database?
A. Yes. From UNICON, you may browse the DSS database for either SAP or RIP entries. You'll see the number of sources reporting the service/route, the local subnet of the service or gateway, and the DSS responsible for maintaining the DSS record. You may also save the DSS database to a text file by selecting "Save SAP Records" or "Save RIP Records".
Q. Does DSS and NetWare/IP use SNMP? Does it include a MIB?
A. Yes. NWIP.NLM and DSS.NLM both provide SNMP alerting and a common management MIB (DSSMIB.MIB). You may select the level of SNMP error reporting from the UNICON console.
Q. I've configured a server to provide DSS services, but not DNS services. However, I see that DNS server is running in the Unicon "Start/Stop Services" list. Why is DNS loading if I haven't configured this server as a DNS?
A. When a server or client connects to a DSS server, it verifies that the DSS server is a valid DSS for the NetWare/IP domain by requesting an SOA (Start of Authority) record from the DSS server for the NetWare/IP domain. NAMED.NLM is auto-loaded by the DSS.NLM to provide the SOA record to the client. Even though DNS is running (NAMED.NLM is loaded), the DSS server does not provide full DNS services, unless you have configured DNS services in UNICON.
Q. What new features does NetWare/IP 2.2 include for the NetWare/IP server?
A. There are two very important enhancements to NWIP.NLM. First, the NWIP.NLM keeps a local copy of the DSS Btrieve database. In prior versions of NetWare/IP, NWIP.NLM would download the entire DSS SAP/RIP database every time the NLM was initialized. Since NetWare/IP keeps a local copy of the DSS Btrieve database, only changes to the DSS database are synchronized during NWIP.NLM initialization. This greatly reduces DSS-NWIP traffic during NWIP.NLMinitialization.
Secondly, the NWIP.NLM may now respond to client queries during initialization. In previous versions of NetWare/IP, NetWare/IP clients were required to contact a DSS to initialize, often requiring a DSS to be located at any site that contained NetWare/IP clients. However, with NetWare/IP 2.2, a NetWare/IP client needs only to contact a NetWare/IP serverCthere is no requirement to place a DSS at every site where NetWare/IP clients exist.
Q. Can I use INETCFG to configure NetWare/IP?
A. Somewhat. NetWare/IP 2.2 includes the necessary files for INETCFG interoperability. However, UNICON is still required for configuring and managing NetWare/IP.
Q. Can I use FILTCFG.NLM to filter SAPs and RIPs with NetWare/IP 2.2?
A. Yes. Be sure to load the NWIP.NLM with "name=(name)", such as "LOAD NWIP name=NWIP_1" so that FILTCFG.NLM will recognize the NetWare/IP interface. Remember that you must enable IPX filtering in INETCFG before using FILTCFG for either IPX or NetWare/IP.
Q. I have multiple adapters in my server, all configured with TCP/IP. Can NetWare/IP 2.2 use multiple adapters?
A. Yes. However, NetWare/IP will only use one adapter for NetWare/IPCDSS synchronization.
Q. How many NetWare/IP-IPX gateways should I configure on each segment? Are there any special considerations for multiple NetWare/IP-IPX gateways on a common IPX segment?
A. Only one NetWare/IP-IPX gateway is required per segment. Multiple NWIP-IPX gateways improve fault tolerance, but may affect DSS performance and IPX SAP/RIP broadcasts. When multiple NWIP-IPX gateways report the same IPX information to a DSS, the DSS must work harder to process redundant information. Likewise, every NWIP-IPX gateway will periodically broadcast SAPs and RIPs learned from the DSS to local IPX segments, increasing IPX broadcast traffic and potentially affecting other IPX devices. If you must configure more than two NetWare 4.x servers to use both NetWare/IP and IPX, consider loading IPXRTR with "routing=none" to prevent both DSS overload and IPX SAP/RIP broadcasts. For example, if 10 NetWare/IP servers also shared a common IPX segment, configure all but two of the servers with "LOAD IPXRTR routing=none".
Q. What clients are currently supported by NetWare/IP?
A. NetWare/IP currently supports DOS, Windows 3.1, Windows for Workgroups, Windows 95, and Windows NT Server and Workstation. OS/2 and Macintosh versions are finishing final test and should be available with the next major release of the NetWare operating system.
Q. What TCP/IP stacks are supported by NetWare/IP?
A. For DOS, Windows 3.1, and Windows for Workgroups-Novell's 16-bit Lan WorkPlace TCP/IP stack, Client32 32-bit TCP/IP stack, and FTP's ONNET. Another major TCP/IP vendor will soon announce NetWare/IP availability on their stack.
For Windows 95 and Windows NT-any stack written to Microsoft's TDI spec, including the 32-bit TCP/IP stack that ships with both of these products.
NetWare/IP support for Macintosh, and possibly OS/2, are forthcoming.
Q. What is NSQ_BROADCAST?
A. NSQ_BROADCAST is an acronym for Nearest Server Query. This setting determines the behavior of the NetWare/IP client when attempting to locate a service. If NSQ_BROADCAST is set ON, the client will first send a UDP broadcast to the local IP subnet to locate a service. This broadcast will only be answered if there is a NetWare/IP server on the same IP subnet. If the UDP broadcast fails, the NetWare/IP client will then contact the Nearest NetWare/IP server for service information. If set to OFF, the NetWare/IP never uses UDP broadcasts to locate services; instead, it will send the request directly to the Nearest NetWare/IP Server.
Q. Does NetWare/IP work over PPP? Any special considerations?
A. Yes. NetWare/IP works over PPP. If you are using NetWare/IP on Client32 for Windows 95, be sure to download and apply a new NWIP95.NLM from the NWP951.EXE. If you are using NetWare/IP over PPP, consider setting NSQ_BROADCASTto NO or off. This will prevent unnecessary traffic on the PPP link.
Dynamic Host Configuration Protocol (DHCP)
Q. Does Novell provide DHCP (Dynamic Host Configuration Protocol)?
A. Yes. NetWare/IP 2.2 includes DHCPSRVR.NLM, which can answer both DHCP and BOOTP requests. The DHCPSRVR.NLM may be loaded on any NetWare 4.x server, including servers that provide DNS and DSS information.
Q. How do I configure the DHCP server?
A. Load the DHCPCFG.NLM. Follow the menu structure. Future versions may include a snap-in DLL for the NWAdmin GUI utility.
Q. What information can your DHCP server provide?
A. Novell's DHCP server provides the standard IP information, including leasing of an IP address, subnet mask, IP gateway, DNS domain name and up to three DNS name servers. In addition to the standard IP information, Novell's DHCP server may also distribute specific NetWare/IP information, such as NetWare/IP domain, NSQ broadcast, up to five nearest NWIP servers, and up to 5 preferred DSSes. Lastly, Novell's DHCP can provide NetBIOS Name Server information (a.k.a. WINS) and NetBIOS node types (b, p, h, m).
Q. Which clients may use your DHCP server?
A. Both BOOTP and DHCP clients. BOOTP clients, such as Novell's 16-bit TCP/IP, may even obtain NetWare/IP information from the DHCP server. Windows 95 and Windows NT 32-bit DHCP clients may also receive all information, including WINS and NWIP, from a NetWare DHCP server. If DHCP is present and configured with NetWare/IP information, new NetWare/IP servers will attempt to auto-configure from the DHCP NetWare/IP information.
Q. Can I use Microsoft's DHCP server to provide NetWare/IP information to DHCP clients?
A. Yes. However, Microsoft's DHCP server won't respond to BOOTP clients. If you need to support BOOTP clients, or if you wish to provide NetWare/IP information to BOOTP clients, use Novell's DHCP server. To use the Microsoft DHCP server, you must create two DHCP records using the Microsoft DHCP Manager utility.
The first record is identifier 062, type is string, value is NetWare/IP Domain name.
The second record is more difficult. The identifier 063, the type is byte array, and the value is an array of bytes depending upon the NetWare/IP configuration.
length is 1 byte, 1 for Yes, 0 for No
length is multiple of 4 bytes
length is multiple of 4 bytes
length is 1 byte
length is 1 byte
length is one byte, 1 for Yes, 0 for No
length is multiple of 4 bytes
The general format is (tag) (length) (value). For example, to set NSQ_BROADCAST to Yes, DHCP would be configured with (0x05, 0x01, 0x01), where 0x05 is NSQ_Broadcast, 0x01 is the length, and 0x01 is the value (1 for Yes). The entry 0x07 0x04 0x11 0x22 0x33 0x44 means "Nearest NetWare/IP Server" (0x07) has a length of 4 bytes (0x04), and the value is 184.108.40.206 (0x11 0x22 0x33 0x44). This is tedious to configure, but works. Novell is investigating a GUI utility that would greatly simplify NetWare/IP DHCP information configuration for a Microsoft DHCP server.
Q. Any other considerations when using DHCP?
A. Your router may need a software/firmware update before you can use the DHCP forwarding capability of the router. Check with your router vendor(s).
Q. Is a DHCP server required on every IP segment?
A. No. DHCP server may be centrally located or distributed across multiple segments. On segments where DHCP servers do not exist, you must configure a router or NetWare server to forward DHCP requests to the DHCP server. NetWare 4.1 includes the BOOTPFWD.NLM to forward both BOOTP and DHCP requests from local IP segments to remote BOOTP and DHCP servers. Load BOOTPFWD.NLM directly or configure through the server's INETCFG utility.
Common NetWare/IP Issues
Below is a list of common NetWare/IP symptoms, issues, and possible resolutions.
Symptom: RCONSOLE fails. NLIST /SERVER displays remote services, but IPX clients are unable to connect to remote services. Watchdog disconnects active users.
Problem: (1) NetWare/IP's internal IPX address has been duplicated with another IPX address, either a server's internal IPX address, or an IPX segment address; (2) IPXRTR has been loaded with "routing=none", (3) "Forward IPX information to DSS" has been set to NO.
Details: (1) NetWare/IP uses a virtual IPX address to 'advertise' the NetWare/IP segment to the internal server operating system. If this address is duplicated, it is possible that packets destined for NetWare/IP links may be rerouted to other servers or IPX segments that are misconfigured with the NetWare/IP virtual IPX address. Check or change the NetWare/IP virtual IPX address by with the UNICON utility and reconfigure the primary DSS, if necessary.
(2) By default, NetWare/IP modifies the AUTOEXEC.NCF file to auto-load IPXRTR with routing disabled. This prevents NetWare/IP from forwarding SAP/RIP information learned from the DSS to IPX segments connected to NetWare/IP servers. This also prevents IPX segment information from reaching the DSS. Therefore, remote NetWare/IP servers can't "see" the IPX segment because the segment information hasn't been propagated to DSS. Check to see if IPXRTR has been loaded with routing disabled on your NetWare/IP - IPX gateways.
(3) By default, NetWare/IP servers that also have IPX bound will not report SAPs and RIPs learned from the IPX segment to the NetWare/IP DSS. This prevents remote NetWare/IP servers from "seeing" IPX segments connected to the local NetWare/IP server. Check the status "Forward IPX information to DSS" in the UNICON configuration of the NetWare/IP server.
Symptom:"Undefined Public Symbol" during UNISTART.NCF execution. DSS or NetWare/IP no longer auto-loads from AUTOEXEC.NCF or UNISTART.NCFfile.
Problem: Load order in UNISTART.NCF file is incorrect. Load statements missing from UNISTART.NCF.
Details: NetWare/IP uses UNISTART.NCF to load the necessary NetWare/IP modules. When the UNICON option "Start/Stop Services" is used to start or stop DNS, DSS, NetWare/IP, LPR_GWY, or XCONSOLE, the UNISTART.NCF file may be updated. For example, if you use "Start/Stop services" to unload Domain SAP/RIP service, the "Load DSS" line is commented out of the UNISTART.NCF file. Restarting DSS from "Start/Stop Services" will un-comment the "Load DSS" statement in the UNISTART file, allowing DSS.NLMto load when UNISTART is executed. Note that UNISTART.NCF may also be used by other products, such as NFS, that may rearrange the load order of modules used by NetWare/IP.
* Originally published in Novell AppNotes
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.