cayer@ireq.hydro.qc.ca (Cayer) (05/08/91)
Using my sniffer, I have noticed the following encapsulation
of the IPX protocol over ethernet:
destination source length ...
6 bytes 6 2 . MAC
. layer
...
checksum length transport type ...
2 2 1 1 . IPX
. layer
destination network node socket .
4 6 2 .
.
source network node socket .
4 6 2 .
...
...
data . Upper
... layer
The third field of the MAC layer is a length field and not
a type field as in ethernet V.2.
But, this is not IEEE 802.3 either since there is not an
IEEE 802.2 layer above the MAC layer. The IPX packet is
directly over the MAC layer.
I think that this does not respect either ethernet nor
IEEE 802.3 encoding.
Can this cause problems inside a multi-protocols network
(ipx, decnet, tcp/ip, ...) ?
I have heard that other forms of encapsulation do exist.
So, I would appreciate if someone could tell me what are
those other encapsulations, and why/when to use them.
Thanks.
--
Andre Cayer
cayer@ireq.hydro.qc.ca jal@acc.flint.umich.edu (John Lauro) (05/08/91)
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.
jbreeden@netcom.COM (John Breeden) (05/08/91)
In article <1991May7.233920.7888@engin.umich.edu> jal@acc.flint.umich.edu (John Lauro) writes: >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.) Netware running "Novell IEEE" DOESN'T ignore other IEEE broadcast traffic on the same wire (they don't "test" the packet - no checksum and invalid 802.2 SAPS). I've seen this hang Netware servers. You don't see it alot - there's still very little real IEEE/CLNS around. The solution is to run Netware as a DIX protocol (econfig it). -- 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."