Conference 7.286::fddi

1791.0. "Architectural conflict: FDDI & NETBEUI???" by VMSNET::STEIDLE_S () Sun Aug 27 1995 19:15

    Hi, All
    
    We have a customer that has a an OSF box on an FDDI ring.  This Alpha
    is a server to PCs on Ethernet.  When the Connection to the server is
    over NETBEUI, the PC intermittently drops the connection.  The
    connection will stay up for 3 to 60 minutes. The easiest way to force
    the problem is witha large file copy or program load (I know, a program
    load is a file copy).  
    
    A trace on the Ethernet side with IRIS revealed that the connection is
    rejected at the DLL level when a SMB data frame arrives out of
    sequence.  On 4 different traces, we see 7 to 15 data packets arriving
    wit one of the packets out of sequence.  The PC then issues a DLL ACK,
    and .3 msec later, issues DLL Poll Reject.
    
    A Microsoft article on the details of NETBEUI specifically states that
    NETBEUI will not tolerate packets out of sequence.
    
    The question is, how is the packet getting out of sequence?  We just
    completed analyzing an FDDI trace of a broken NETBEUI session
    and we saw NO PACKETS OUT OF SEQUENCE. We only see them on the Ethernet
    side. 
    
    This Evidence seems to point to the bridge.  However, there are six
    bridges and all of the nodes on the other side of the bridges experience
    the problem.  
    
    All my other customers use FDDI to link up wiring closets.  This is the
    only customer I have that is using NETBEUI to talk to a node ON THE
    RING.  
    
    If the nodes negotiate an FDDI frame size of 1518,  Is there anything
    Going on here, such as segmentation, that would cause a packet to get
    out of sequence? If the answer is yes, then do we need to state that
    you cannot use NETBEUI to talk to a node on an fddi ring?  
    
    Sorry for the lack of technical detail.  My knowledge is a mile wide
    and an inch deep.  
    
    Thanks for any light you can shed on this.
    
    BTW: TCP/IP has no problems. Neither does netbeui talking from a node
    on an ethernet segment to a node on another segment on the other side
    of the ring.
    
    
    Scott,

    >>The question is, how is the packet getting out of sequence?  We just
    >>completed analyzing an FDDI trace of a broken NETBEUI session
    >>and we saw NO PACKETS OUT OF SEQUENCE. We only see them on the Ethernet
    >>side. 
    
    If you're talking about NetBEUI under Digital UNIX, you should really
    check with the Digital UNIX folks (especially the protocol folks) about
    any caveats to running NetBEUI under FDDI.  We already know from
    experience that Microsoft's NetBEUI stack has a problem dealing on FDDI
    with packet sizes larger than max Ethernet (1518 bytes including 4 byte
    CRC).  There is no such thing as NetBEUI fragmentation and the
    (presumed) packet size negotiation in a "dumbbell network" (two FDDI
    rings connected by an Ethernet segment) doesn't work.
    
    >>If the nodes negotiate an FDDI frame size of 1518,  Is there anything
    >>Going on here, such as segmentation, that would cause a packet to get
    >>out of sequence? If the answer is yes, then do we need to state that
    >>you cannot use NETBEUI to talk to a node on an fddi ring?  
    
    You can definitely review an FDDI LAN trace to see whether there are
    larger than 1518 byte NetBEUI packets destined to an Ethernet node. 
    That would tell you that you have a problem on the server stack side.
    
    -Larry

Actually is would be the PATHWORKS OSF folks (see the RANGER::PWOSF conference).

Found it....

We moved the server off the ring and onto the Ethernet.  After about an hour, 
our sniffer captured another packect out of sequence event.  The trace looked 
just like the others.  Oh well.  If nothing else, I got an education.  Thanks 
Larry.

Scott