steve@kn5f.jsc.nasa.gov (Steve Price) (06/03/91)
I have heard rumors that data integrity is in jepordy when transfering files across routers using IPX. I performed my own little test using a batch file to transfer a file to a remote 3.11 server, transfer it back , and check it's CRC, and do it again in a loop. The server was thru 4 cisco routers. I got 5 instances over 5 hours of CRC's that didn't match. The problem was first seen when our multiuser database files were getting corrupted by users across one router while in the presence of a noisy lan segment at that location. I read that IPX does no error checking, but depends on the 802.3 CRC checking. Should we expect errors with IPX when using routers or are we chasing a wild goose?
timm@Sed.Novell.COM (Tim Myers) (06/04/91)
In article <1991Jun3.142905.29531@aio.jsc.nasa.gov> steve@kn5f.jsc.nasa.gov (Steve Price) writes: > I have heard rumors that data integrity is in jeopardy when transfering > files across routers using IPX. You've been talking to those IP-on-the-backbone-or-bust bigots again, haven't you? > I performed my own little test... [story deleted] > The problem was first seen when our multiuser database files were > getting corrupted by users across one router while in the presence > of a noisy lan segment at that location. ^^^^^ I see, so IPX is somehow at fault. :-) > I read that IPX does no error checking, but depends on the 802.3 CRC > checking. Software CRCs are redundant since Ethernet interface cards do it for you in hardware. IPX was designed to NOT waste any time computing redundant CRCs. > Should we expect errors with IPX when using routers or are > we chasing a wild goose? Do your cisco routers route packets with CRC errors? Our cisco routers don't. If yours do then go get a new router. Put a network analyzer on each port of each cisco and check it out. Do your Ethernet drivers pass on packets with CRC errors to an application? Our drivers don't. If your drivers do then go get a new driver. ++Tim =========================================== Tim Myers Senior Software Consultant Novell, Inc. "Macintosh: the only GUI that doesn't SUCK."
tom@rsp.UUCP (Thomas Ruf) (06/05/91)
timm@Sed.Novell.COM (Tim Myers) writes: >You've been talking to those IP-on-the-backbone-or-bust bigots again, >haven't you? >Software CRCs are redundant since Ethernet interface cards do it for you in >hardware. IPX was designed to NOT waste any time computing redundant CRCs. Ha Ha Ha ! Ethernet CRC is just that: a link level checksum. It does NOT cover: RAM errors in routers Software problems in routers Link Errors in OTHER medias between Etherent segments I'd rather have my CPU spent some cycles checking end-to-end checksums as in tcp/ip than blindly trust all those fancy boxes moving bits over the ocean. >Our drivers don't. If your drivers do then go get a new driver. >Senior Software Consultant >Novell, Inc. If your consultant doesn't recommend end-to-end checksums, go get another consultant :-) Cheers, Thomas , inventor of IPX over UDP/IP, of course with NO WAY of turning off UDP checksums. -- Thomas Ruf tom@rsp.de Schneider & Koch GmbH Schneider & Koch, Inc {uunet,mcvax}!unido!rsp!tom Germany Palo Alto
timm@Sed.Novell.COM (Tim Myers) (06/08/91)
In article <1056@rsp.UUCP> tom@rsp.UUCP (Thomas Ruf) writes: > I'd rather have my CPU spent some cycles checking end-to-end checksums > as in tcp/ip than blindly trust all those fancy boxes moving bits over > the ocean. Did the original post from NASA mention anything about moving bits over the ocean? The implementors of IPX thought differently about how CPU cycles should be spent--checksums are ignored. The designers of AppleTalk also thought differently--checksums are optional. This different thinking about what is best for specific applications is what has led to a polyglot protocol world. Yes, there is a place for end-to-end checksums, but I don't need it on my LAN. If you want to send bits over the ocean you have my blessing to use TCP/IP on your WAN. If you want to send bits to the other end of the solar system you will need yet another protocol because your precious checksums will not deliver the goods. > Thomas , inventor of IPX over UDP/IP, of course with NO WAY of > turning off UDP checksums. Then you especially should understand the issues, both for and against the use of checksums, cyclic redundancy checks, and error correction codes on a LAN, MAN, or WAN! ++Tim Are we about finished with this subject? =========================================== Tim Myers Senior Software Consultant Novell, Inc. "Macintosh: the only GUI that doesn't SUCK."
jbreeden@netcom.COM (John Breeden) (06/08/91)
In article <1991Jun7.185359.659@npd.Novell.COM> timm@Sed.Novell.COM (Tim Myers) writes: >In article <1056@rsp.UUCP> tom@rsp.UUCP (Thomas Ruf) writes: >The implementors of IPX thought differently about how CPU cycles should >be spent--checksums are ignored. The designers of AppleTalk also thought >differently--checksums are optional. Big difference between CAN'T do and optional. At least Apple was smart enough to make it optional. I guess this is a case of Novell being right and every other NOS implementation being wrong. It's easy to under- stand when you realize this is the same company that brings us a 802.2 header with the SAPs set to ff's and a 802.3 frame on broadband with the lenght field set to 00 (-: -- John Robert Breeden, jbreeden@netcom.com, apple!netcom!jbreeden, ATTMAIL:!jbreeden ------------------------------------------------------------------- "The nice thing about standards is that you have so many to choose from. If you don't like any of them, you just wait for next year's model."
dougm@ico.isc.com (Doug McCallum) (06/11/91)
In article <1056@rsp.UUCP> tom@rsp.UUCP (Thomas Ruf) writes: >timm@Sed.Novell.COM (Tim Myers) writes: > >>You've been talking to those IP-on-the-backbone-or-bust bigots again, >>haven't you? >>Software CRCs are redundant since Ethernet interface cards do it for you in >>hardware. IPX was designed to NOT waste any time computing redundant CRCs. > >Ha Ha Ha ! Ethernet CRC is just that: a link level checksum. It does NOT >cover: > RAM errors in routers > Software problems in routers > Link Errors in OTHER medias between Etherent segments >I'd rather have my CPU spent some cycles checking end-to-end checksums >as in tcp/ip than blindly trust all those fancy boxes moving bits over >the ocean. Things can be worse than just routers and other intermediate devices on the LAN. I've seen some LAN cards which appear as memory to the host develop problems with their RAM. The Ethernet CRC gets generated after that so appears as a correct packet on the local LAN. You don't notice until some file has become corrupted. Of course, if Novell did use checksums it would be very difficult to tell a Novell 802.3 packet from any 802.3/802.2 packets.