NDS EXPERT Enabling Request-IPX-Checksums to Eliminate NDS Packet Corruption Problems
Articles and Tips: article
Senior Research Engineer
Systems Research Department
01 Apr 1996
On rare occasions, Novell technicians have repaired trees that are healthy with the exception of several corrupted attributes, such as object names or time stamps. After considerable investigation, we learned that these attributes were corrupted during transit from one server to another as they passed through a malfunctioning router. In response, an option has been included in DS.NLM version 4.96 and above that allows individual servers to request IPX checksums on NDS packets.
If your tree traverses a routed network or hardware that has corrupted data in the past, the potential for packet data corruption may affect the integrity of your tree. However, don't rush to enable the request-IPX-checksum feature until you've considered several issues regarding its justification, its compatibility with your system, and its effect on performance.
This AppNote describes several issues that you should consider before enabling this feature. It then tells how to enable and disable this feature, and how to check on its status.
Request-IPX-Checksums
The Request-IPX-checksums feature uses IPX checksums to guarantee the integrity of packets that are involved in NDS synchronization traffic. In the checksumming process, IPX calculates the sum of each packet's contents at both ends of the NDS communications link. If the receiving server's packet checksum agrees with the transmitting server's checksum, the packet is considered by the receiver to be consistent and correct. Otherwise the packet is discarded and a retry occurs.
IPX checksumming isn't necessary under normal conditions because Ethernet, Token-Ring, and other protocols use a cyclic redundancy check (CRC) to protect against data corruption on the wire. However, the CRC process is not infallible. The CRC only protects data while it is in transit across the LAN. One scenario that the CRC fails to catch is when your server hardware corrupts an IPX packet before the packet is transmitted. This is because the CRC is not calculated until just before the packet is placed on the wire.
Another scenario that the CRC fails to catch is when an IPX packet passes through a router. As the packet enters the router, the CRC is stripped off and the packet is checked for errors. A new CRC is appended to the packet as it is retransmitted. If the packet is corrupted in the router, neither the old nor the new CRC will suggest that corruption occured. The solution to these two unlikely scenarios is to enable request-IPX-checksums to guarantee the validity of packet data from one end of the conversation to the other.
Compatibility Issues.
IPX checksumming is initially disabled because it isn't compatible with the Ethernet 802.3 "raw" frame type. Although 802.3 frames include a checksum field, the field is used by end-systems to differentiate between the 802.3 frame and other Ethernet frame types rather than for checksums.
If your network currently uses the 802.3 frame type, or if your tree traverses links that are configured for 802.3 frames, enabling this feature will effectively disable NDS communications over those links.
For this and other reasons, Novell recommends that you migrate your servers to the Ethernet 802.2 frame type.
For more information on Novell's support of Ethernet frame types and issues involved in migrating from 802.3 raw to 802.2, see "Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2," Novell Application Notes, September 1993.
IPX checksumming is compatible with all other frame types supported by NetWare.
Performance Issues.
Request-IPX-checksums is a CPU-intensive operation that shouldn't be implemented without justification. In many systems, the potential for packet corruption is so small that the performance degradation of checksumming can't be justified. For example, networks that don't include routers don't require the use of checksums because packet corruption occurs so infrequently in these systems.
If your system has never encountered packet corruption, this option may be completely unnecessary. Or, if your system is already underpowered and the added burden of enabling request-IPX-checksums would only worsen matters, this option may not be worth the minor loss in performance.
However, if your system has encountered data corruption in the past, or if your knowledge of the system's weaknesses leads you to anticipate corruption problems, the slight performance degradation incurred by the additional overhead of the checksum operation may be necessary and justifiable.
Enabling Request-IPX-Checksums
The request-IPX-checksums feature is enabled on a server-by-server basis. This allows you to limit your system's use of IPX checksumming to those servers that require this protection. Once this feature is enabled, NDS limits the use of IPX checksums to the server's outbound NDS connections to other servers. It does not enable IPX checksumming on the server's user connections.
To enable request-IPX-checksums, enter the following SET command at the server console:
SET DSTRACE = CHECKSUM
This setting is permanent until you disable the feature using the same SET parameter with the NOCHECKSUM option:
SET DSTRACE = NOCHECKSUM
Determining the Status
The easiest way to determine whether this feature is enabled on a server is with the Directory Services trace screen.
Use RCONSOLE or go to the server console of the server whose checksum status you need to know.
Enter the following commands:
SET DSTRACE = ONSET DSTRACE = *P
Press <Alt<+<Esc< to toggle to the Directory Services trace screen. In response to your *P request, the trace screen displays the parameters as shown in Figure 1.
Figure 1: The DSTRACE *P option displays the current value for all tuneable NDS parameters.
NetWare 4.1 Directory Services 4.97, 2/29/1996 TUNEABLE PARAMETER VALUES ServerStateUpThreshold = 30 minutes External Reference Life Span = 192 hours JanitorInterval = 2 minutes FlatCleaningInterval = 60 minutes BacklinkInterval = 780 minutes Heartbeat Data = 30 minutes Heartbeat Schema = 240 minutes Requests In Progress threshold = 1000 Request IPX checksums = DISABLED IPX:RIPDelay = 20 ticks IPX:Retries = 3 IPX:TimeOutScaleFactor = 2 IPX:TimeOutShiftFactor = 4 Disk accesses before yield = 10 Connection Expiration Timeout = 135 minutes Maximum Sockets Threshold = 75% Outbound Synchronization = ENABLED Inbound Synchronization = ENABLED Schema Outbound Synchronization = ENABLED Schema Inbound Synchronization = ENABLED
The "Request IPX checksums" entry reports whether this feature is ENABLED or DISABLED.
Conclusion
Request-IPX-checksums is a powerful process that eliminates the possibility of packet corruption in NDS synchronization traffic. However, before you enable this important protection, be sure you understand its justification, as well as compatibility and performance issues.
--Ron Lee
Copyright 1996 by Novell, Inc. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Novell.
All product names mentioned are trademarks of their respective companies or distributors.
* Originally published in Novell AppNotes
Disclaimer
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.