cayer@ireq.hydro.qc.ca (Cayer) (05/22/91)
A little while ago, I posted this request for information: ------------------------------------------------------------ >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. --------------------------------------------------------------- My first question was about the non conforming IPX encapsulation over ethernet: can this cause problems in a multi-protocol network? The answer seems to be yes. From Alex Stagg (ats@boaz.udev.cdc.com ): > I don't know why, but for some reason, Novell chose to implement an > 802.3 header without the 802.2 LLC header. Yes, it can cause problems > if 1) other devices on the network don't discard the IPX stuff by > not properly and logically following the 802.2 spec (they should > since the IPX checksum 0xffff is not a valid DSAP/SSAP combination) or > 2) the Novell code doesn't discard non-IPX data (by validating the > "non-checksum"). > ... > I don't have any experience but I've heard that Decnet and NetWare > running with 802.3 headers only have problems running on the same > network. From brian@napa.Telebit.com: > Yes, you are seeing old netware. Novell's old encapsulation can > cause problems on a multi-protocol network. They are getting away > from this in their newer NOS. From Markus Mueller (mueller@komsys.tik.ethz.ch): > Perfectly right. Things are even worse: Usually the checksum > value is hex FFFF (no checksum??), making the packet look like > having an LSAP of hex FF under IEEE 802.2 which stands for > "any LSAP". Therefore a system running a true 802.3 protocol > (CDCnet; ISO/OSI) is likely to choke. > The reverse also happens: if a Novell station (client or server) > sees a true IEEE 802.3 packet addressed to it (usually a broadcast) > it may react wich ABEND... From jal@acc.flint.umich.edu (John Lauro): >> 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. From Matt Gutherz (matt@zeus.sbi.com): > You are correct. The default IPX/Novell encapsulation is their > twist on 802.3. It is an IPX datagram in an 802.3 packet rather > than an IPX datagram in an 802.2 datagram in an 802.3 packet. > You are also correct about it possibly causing problems in a multi- > protocol environment. Fortunately, some/must network equipment is > able to deal with this inconsistancy. From Doug McCallum (dougm@ico.isc.com): > Correct. What Novell calls 802.3 is just 802.3 MAC framing and > not full compliance with the 802.3 specification. > > It can confuse some systems, especially those with older > implementations of 802.2. Most newer ones understand that there > are lots of Netware sites using the broken 802.3 method. From: haas%basset@cs.utah.edu (Walt Haas) > The famous Novell framing crock... yes their default is to > violate both the Ethernet and IEEE standards. They provide > an option, ECONFIG 8137, to do correct Ethernet framing. I > insist that all Novell machines on our University network do > proper Ethernet framing. With that proviso Novell is a good > network citizen. With the default Novell framing they > conflict with certain ISO protocol implementations. From Joel M. Halpern (jmh@network.com): > THe IPX encapsulation is a broken kludge. IPX actually has an > ethertype assigned, but does not use it. > > A smart device can recognize an IPX packet (see below), but a > device which is not aware of IPX will potential become confused > by the IPX packets. > > The trick is that when an apparent 802.2 packet arrives, one > performs two checks. > 1) If the length is greater than the IPX max, it is not IPX. > > 2) round the 802.2 length up to an even boundary, and compare > witht the hypothesised IPX length which starts 2 bytes after > the end of the MAC header. If these match, it is an IPX > packet. > > Note that because the maximum IPX length is less than 768, no > 802.2 UI frame can be mistaken for an IPX frame. > > There is one other fact. Most of the time, IPX does not use the > checksum field, and therefore, no router will mistake the packet > for any other protocol packet. Also, even if it somehow decided > it was an 802.2 SNAP packet, or OSI packet, the Control field can > not contain 03 on an IPX packet, so it will still be > dropped/bridged/whatever. This is the fact > that saves most bridge/routers from blowing up on IPX packets. From jbreeden@netcom.COM (John Breeden) >>> 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. ----------------------------------------------------------------- My second question was about the other forms of encapsulation. I will summarize the answers for the sake of brevity. The encapsulations are: - IPX inside 802.3 without 802.2 - IPX inside ethernet type 8137 - With ODI, Novell now support: - IPX inside 802.2 inside 802.3 - IPX inside TCP/IP (only between servers) - IPX inside 802.2 with SNAP extensions ??? Almost everybody mention that it is better to use ethertype 8137 (econfig command) to avoid problems. In the presence of OSI software (using CLNP) it should be better to use the 802.2 encapsulation. ------------------------------------------------------------- Once again, thanks. --- Andre Cayer cayer@ireq.hydro.qc.ca