Xref: utzoo comp.dcom.lans:8007 comp.sys.novell:1425
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!acc.flint.umich.edu!jal
From: jal@acc.flint.umich.edu (John Lauro)
Newsgroups: comp.dcom.lans,comp.sys.novell
Subject: Re: IPX Encapsulation over Ethernet
Message-ID: <1991May7.233920.7888@engin.umich.edu>
Date: 7 May 91 23:39:20 GMT
References: <6843@s3.ireq.hydro.qc.ca>
Sender: news@engin.umich.edu (CAEN Netnews)
Organization: University of Michigan - Flint
Lines: 18

In article <6843@s3.ireq.hydro.qc.ca> cayer@ireq.hydro.qc.ca () writes:
>Can this cause problems inside a multi-protocols network 
>(ipx, decnet, tcp/ip, ...) ?
Generally not, for the following reasons:
   - Most packets are filtered out by destination address.  So what
     ever is on the destination will be able to decode it.  This leaves
     only broadcasts.
   - The broadcasts are ignored by other protocols becasue they don't
     pass all the tests.  (Such as checksums, etc.)
Even with the above in mind, we still run everything econfiged.

>I have heard that other forms of encapsulation do exist. A

Yes, you can econfig the servers (2.15-2.2) and many of the ipx drivers.
(Novell uses type 8137).  With NW 386 3.11, or ODI you can even encapsilate
IPX inside of IP.  Using type 8137 works well with packet drivers and TCP/IP.
Using IP is generally only done between servers over company networks that
only route IP.