Hello Folks @ 3000-l,
Re: nsdir and checksum
--------------------------------------------------------Donna Writes--
hi all! does anyone know of a way to convince NMMGR in maintenance
/character mode to fill-in the checksum field for an nsdir entry?
we're having to update all our classics so they can talk to their
neighboring Unix system. at roughly 250 machines...this is a royal
pain to have to do by hand. we can script everything except for the
checksum.
otoh, our MPE v reference material strongly warns against turning on
checksumming on the configuration side. it talks about seriously
degrading performance...not a good thing on a 37! any comments about
turning on checksumming this way? -- Donna Garverick
--------------------------------------------------------Donna Writes--
Sorry to jump into this sooo late, I see that a lot of discussion has
already taken place.
I have not attempted to investigate a solution for mass updating the
NSDIR entry since I have a couple of answers, one of which was already
pointed out in this Thread.
1. It has already been pointed out that enabling the TCP Checksum
globally can be performed in NMMGR screen Path: NETXPORT.GPROT.TCP
[Y]Checksum Enabled (Y For Yes, N For No
I recommend this configuration option every chance I get.
2. Donna points out in her message "...talk to their neighboring Unix
system", and in this case the configuration option in NSDIR or in TCP
global configuration may be unnecessary since a non-3000 and a 3000
system will 'ALMOST' always negotiate Checksum Enabled in the initial
SYN/SYN-ACK/ACK hand shake. This is not a widely known negotiation
and not RFC standard... how it works... A non-3000 system will send a
SYN to the 3000 with a non-zero TCP Checksum and the 3000 will
automatically understand that it must use TCP Checksum on this
connection irrelevant of configuration; In the outbound case the 3000
will send a SYN with a zero TCP Checksum, the non-3000 system will
send the SYN-ACK with a TCP Checksum and then the 3000 will
automatically understand that it must use TCP Checksum on this
connection irrelevant of configuration. In the above statement I
wrote "will ALMOST always negotiate Checksum Enabled", I and the HP-RC
have seen rare cases where a non-3000 host was checking the TCP
Checksum on the incoming SYN packet and would reject a SYN packet with
a zero TCP Checksum and in this rare case we enabled TCP Checksum
global or in the NSDIR entry for the specific host.
Hmmm.... That was a mouthful. Not "not RFC standard" ? What's this
about ? TCP as per the RFC is required to implement TCP Checksum.
Having this option disabled is non-standard.
Now to answer a few more questions about TCP Checksum
----------------------------------------------------------------------
I would leave the checksum off (if possible). Networks now days are
robust enough that if you get a packet, the checksum doesn't add much.
If I remember correctly the checksum is not for the data portion, just
the IP header information. In the next release of the IP standard
IPv6, checksumming is no longer an option. You can't checksum...
----------------------------------------------------------------------
The Checksum we are talking about is TCP Checksum, not IP checksum.
The TCP Checksum calculation includes the data portion of the TCP
packet and assures integrity of data at level 4 in the ISO 7-layer
model protecting the data from corruption in most of layer 4 Transport
(TCP),layer 3 Network (IP),Layer 2 Data Link (Hardware Interface) and
layer 1 Physical Hardware Connection on both the sending and receiving
systems.
Another protection for data may be present at the Layer 2 Data Link
depending on link type. With Ethernet as an example a CRC is computed
which includes data. This CRC is capable of catching packets
corrupted over a network, but does not cover the possibility the
packet is corrupted in/on the physical H/W interface card or on the
physical DMA write from the H/W card to a memory location on either
the sending or receiving systems. Some folks have suggested the
implementation of the CRC is not consistence within the industry
accost all H/W Network devices.
The TCP checksum provides protection to the point that the local
socket SEND copies data from your application to TCP and the remote
socket RECV copies data from TCP to your application.
Responses to other questions and input
----------------------------------------------------------------------
And MPE has a history of both repeated software bugs and numerous
hardware failure modes which result in silent corruption of network
traffic (resulting in silent corruption of user database contents in
some cases) if the TCP level checksums are not enabled.
----------------------------------------------------------------------
I agree that H/W cards can go bad due to numerous situations
environmental and other including manufacturing defects, but this is
certainly rare as most folks out on the 3000-l will attest to the
quality of HP3000 hardware. In any event I would want to protect my
data at as high a level as possible and TCP Checksum meets that
requirement.
I have not seen the 'software bugs' referenced. I did a quick review
of the fixes for the Ethernet link and NS-Transport. We have no
fixes for the Ethernet LAN driver on any supported MPE/iX release
(5.5,6.0,6.5) where data corruption was reported and repaired and no
significant outstanding (SR) issues. We have few (1-2) unique cases
of fixes for the NS-Transport on all supported MPE/iX releases where
missing data or duplicate data was passed from TCP to a customer
application which was reported and repaired early in MPE/iX 5.5 and no
significant outstanding (SR) issues. Realistically TCP and the LAN
links are used very heavily in highly diverse networking environments
and to use a H/W term are "well burned in" with the exception of
problems which can be introduced when new H/W and/or S/W solutions are
implemented.
Another question:
----------------------------------------------------------------------
What gives??? Is it yes or no???
Checksum enabled (Y/N)
Specifies whether or not checksumming will be enabled
in the local configuration. *** [Checksumming causes
significant overhead and is not normally needed for
this protocol; therefore, HP recommends the default
value (N) for this field unless communication to a
non-HP machine is desired.] *** (Note that checksumming
may be done anyway if determined by the destination
path report in the network directory or by the
values specified in the NetIPC intrinsics, IPCCONNECT
and IPCRECVCN.)
Default Value: N
Range: Y or N
----------------------------------------------------------------------
This is the help screen which exists today in NMMGR and IMHO this is
old-old-old. Though I have not the time/resources to perform
performance studies on multiple systems to prove or disprove the
performance implications of enabling TCP Checksum, I will say this
screen originated from MPE/VE machines when TCP was first available on
the HP 3000. I expect the TCP Checksum has a minimal impact in both
performance and transfer speed, but as others have said both
performance and transfer speed are really irrelevant if you data base
includes data corrupted over the network. TCP Checksum Enabled is an
insurance policy you can't afford to not buy.
As I mentioned above if you are transferring data from 3000 to a
non-3000 you are already using TCP Checksum, so the only case where
you are not already using TCP Checksum is a 3000 to 3000 connection
where TCP Global Checksum is not enabled and TCP NSDIR Checksum is not
enabled on either system. This is another good reason to enable TCP
Checksum globally.
In what case would I want to have TCP Checksum disabled ? The only
valid case I can think of is if I wanted to avoid the overhead
between 2 specific systems which were running 1 socket based
application which performed the data checksum at a higher level, at
the application level as an example.
Now to wrap things up... What happens when TCP receives a corrupt
packet and TCP Checksum is enabled for a connection or globally ?
On the console:
---------------
** NETXPORT TCP : PACKET DISCARD; Checksum error
- Loc: 12002; Class: 3; Parm= $868BF340; PIN: 2112
In the NMLG files:
------------------
**********************************************************************
* WED, MAY 10, 2000, 2:58:41.4 PM NETXPORT(3) *
*--------------------------------------------------------------------*
* Event : PACKET DISCARD *
* Entity : TCP *
* Internal Event : Checksum error *
* Log Class : Non-critical error *
* Port ID/PIN/KSO : $000002C0 *
* Location : 12002 Parameter : $868BF340 *
* Info Section (hex): *
* 0000: 0067 0018 002A 2EE2 0000 02C0 0003 868B *
* 0008: F340 0001 *
*--------------------------------------------------------------------*
* Port Message Frame: *
* Data Section (hex): * * 0000: 0000 0000 *
**********************************************************************
On your face:
-------------
//;~)
I hope this helps.
Regards,
James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.
|
