[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

819.0. "IPX Fix" by CTOAVX::BEAULIEU () Tue Dec 22 1992 15:03

    
    Hi,
    
    I have seen several references to a IPX fix for FDDI,(LLC header
    missing???) both in the new DECnis 621 cards, and in the DECbridge 620. 
    Can anyone give me a good description of what the problem is and how we 
    fixed it. 
    
    Thanks, Mike Beaulieu
    
    Also, on a side note, I have a VAX 8600 running Berkley BSD 4.3 RENO
    #28, at my site. It seems that IP works fine over the Enet, but it
    can't access the FDDI ring. Looks like the DECbridge 620 is trashing
    the packets. Any clues???

T.R Title User Personal
Name Date Lines

819.1 KONING::KONING Paul Koning, A-13683 Tue Dec 22 1992 16:19 36

T.R	Title	User	Personal Name	Date	Lines
819.1		KONING::KONING	Paul Koning, A-13683	`Tue Dec 22 1992 16:19`	36
	Bridges should do IP just fine. You should make sure fragmentation is enabled (it should be by default, I believe). What brand of FDDI node are you trying to talk to? What symptoms do you see? As for IPX, here's a description of the workaround, which Krishna sent me recently. Note that it's not really a fix; the problem is with Novell, and the best answer is not to use that incorrect packet format. There's a configuration option that lets you do it right (but doing it wrong is the default...). paul ---------------------------------------------------------------------------- Novell stations source two flavors of IPX frames on a CSMA/CD LAN, 1) The normal Ethernet V2.0 format with a ptype of 81-37 and 2) "Raw" 802.3 frame. The raw 802.3 frame does not have the 802.2 LLC header, hence after the length field on the 802.3 header it has the IPX (network layer) header. Fortunately the first two bytes of the IPX header (checksum field) is always FF-FF (since checksum is disabled in IPX). So that is the only way to distinguish a raw IPX frame. The IPX fix involved translating raw IPX frames on the NI side to SNAP encapsulated frame (RFC 1042) with a ptype of 81-37 on the FI side and vice versa from FI side to NI side. On the DECbridge when we receive a 802.3 frame while doing the DSAP filtering I checked for a DSAP and SSAP of FF-FF and if so (raw IPX) I jumped to the hack. In the hack I replaced the length field with 81-37 (ptype) so that it looks like Ethernet V2.0 frame so that the TP would translate it to a SNAP encapsulated frame on FDDI. In the reverse direction when we receive a SNAP encapsulated IPX frame on FI, at the TP while the translation is done, when the ptype field is moved from FIPM to NIPM, I check if the ptype is 81-37 and if so I overwrite the ptype field on the NIPM with the data length of the packet so that it looks like a raw IPX frame on the NI side.

Bridges should do IP just fine.  You should make sure fragmentation is enabled
(it should be by default, I believe).  What brand of FDDI node are you trying
to talk to?  What symptoms do you see?

As for IPX, here's a description of the workaround, which Krishna sent me
recently.  Note that it's not really a fix; the problem is with Novell,
and the best answer is not to use that incorrect packet format.  There's
a configuration option that lets you do it right (but doing it wrong is
the default...).

	paul

----------------------------------------------------------------------------

Novell stations source two flavors of IPX frames on a CSMA/CD LAN, 1) The normal
Ethernet V2.0 format with a ptype of 81-37 and 2) "Raw" 802.3 frame. The 
raw 802.3 frame does not have the 802.2 LLC header, hence after the length
field on the 802.3 header it has the IPX (network layer) header. Fortunately
the first two bytes of the IPX header (checksum field) is always FF-FF (since
checksum is disabled in IPX). So that is the only way to distinguish a raw
IPX frame.

The IPX fix involved translating raw IPX frames on the NI side to SNAP 
encapsulated frame (RFC 1042) with a ptype of 81-37 on the FI side and
vice versa from FI side to NI side. 

On the DECbridge when we receive a 802.3 frame while doing the DSAP filtering
I checked for a DSAP and SSAP of FF-FF and if so (raw IPX) I jumped to the
hack. In the hack I replaced the length field with 81-37 (ptype) so that it
looks like Ethernet V2.0 frame so that the TP would translate it to a 
SNAP encapsulated frame on FDDI. In the reverse direction when we receive a
SNAP encapsulated IPX frame on FI, at the TP while the translation is done,
when the ptype field is moved from FIPM to NIPM, I check if the ptype is
81-37 and if so I overwrite the ptype field on the NIPM with the data length
of the packet so that it looks like a raw IPX frame on the NI side.