Conference 7.286::fddi

           <<< SCACT::SYS$APPLROOT:[NOTES$LIBRARY]APPLETALK.NOTE;1 >>>
                  -< Apple's AppleTalk Networking Protocols >-
================================================================================
Note 13.1                       APPLETALK on FDDI                         1 of 3
SCADMN::MERRELL "Dtn 521-3107/Santa Clara, CA"        8 lines  13-AUG-1990 00:34
                       -< Apple is aware of the problem >-
--------------------------------------------------------------------------------
    AppleTalk Phase 2 uses two IEEE 802.3 (actually 802.2 if I remember
    correctly) packet types. One of these (the AARP packet) uses a vendor
    code in the SNAP header of 000000 rather than Apple's assigned code of
    080007. As a result, several 10-100 bridges (our included, I believe)
    have a problem with these packets. Apple has been made aware of the
    problem, and is supposedly working on a fix.

    Greg

    Also, the new firmware for the bridges coming out in June will handle
    the Apple address translation properly.
    
    Debbie
    

re -.1

Do you have the details of HOW the new firmware has fixed this problem ?

Thanks,

Steve

The details are somewhat messy to explain.  The summary is that there is a
table of protocol types which lists the protocols that don't play by the
rules.  Currently, Appletalk (or more exactly, Appletalk ARP) is the only
entry in that table.  Protocols found in the table have their "Ethernet Mapping"
done via OUI 00-00-F8 rather than the usual 00-00-00.  Frames arriving
from the FDDI side with OUI 00-00-00 and a protocol type in the table pass
through unchanged, rather than getting mapped back into Ethernet form.  So
Appletalk-2 messages stay unchanged all across, and Appletalk-1 messages
are carried across the FDDI as 00-00-F8-xx-yy messages.

	paul

cisco is saying that they have worked out a fix with Apple, and are now the 
only FDDI vendor capable of handling Appletalk Phase II.   They are saying Apple 
will not release the "fix" to other vendors.

Can anyone confirm/deny this story?

Bob

I have in my grubby mitts a document describing how this problem is to be fixed
entitled "Draft Recommended Practice 802.1<?> MAC Bridging of Ethernet in IEEE
802 LANs [May 2, 1991]". This contains a table of entries that require special
processing - the only entry is for AppleTalk ARP (which is AppleTalk Phase I not
Phase II).

RE: .5 - what is supposed to be the problem with Phase II AppleTalk ?

Eric

Re .6: the problem is actually with Appletalk V2: if you omit the table entry
then V1 works correctly and V2 doesn't.

Re .5: bullsh*t.  You should tell your customer that cisco doesn't know what
it's talking about.  Digital in fact has defined, AND contributed to IEEE 802,
the general solution to the Appletalk problem and others like it (if we ever
see any, which so far we haven't).

	paul

    Just for my information,...
    
    	Is this the case where the hardware is only capable of sending
    even numbers of bytes,.. and thus an 802.3 frame's length field
    can be one off? As I remember this was tossed by our products
    as a bad frame,.. since the length was wrong. By enforccing the
    letter of the law for 802.3 we were rendering this product
    disfunctional,.. but other vendors,... who don't enforce the
    letter of the law,.. would pass these frames along.
    
    	If this is not the same problem we are talking about,..
    I'm curious as heck to know what this problem is. Any pointers
    to technical descriptions would be appreciated.
    
    	Thanks
    						/Bill
    

The problem is that AppleTalk ARPV2 use ProtoID of 00-00-00-80-F3 which when
forwarded onto and off of a FDDI ring gets turned into an Ethernet Frame with
a protocol of 80-F3.

    re .8:
    
    The problem you describe,.. has been fixed as well,...
    
    Anil (sorry, couldn't resist :-)
    
    ps: wonder if that was simply a misinformed cisco sales guy.  I have
    a hard time believing that they would make an official statement like
    that.  Actually, since cisco bridges are (currently) encapsulating,
    they shouldn't have a problem with appletalk.

Sorry for the delay...  don't get into notes much in Q4!

   The cisco guy is an ex-Deccie named Gary Kunis.  Lots of arrogant talk,
some good technical background, and the customer just swallows it hook,
line, and sinker.

   Can someone send me an electronic copy of the 802.1<?> document mentioned in 
an earlier reply, so that I can put this thing to bed?

                        Thanks....   Bob

    Is the "specialized AppleTalk translation capability in the DECbridge
    500 device to accomodate the AppleTalk protocol and Kinetics devices"
    mentioned in the June sales update referring to the workaround for the
    problem mentioned in this note? and is already implemented in the new
    bridges like DECbridge 510 and 6xx series? 
    
    A customer is experiencing a problem with AppleTalk Phase II over
    DECbridge 500 (current firmware version is 2.1).  What is the
    firmware version that will upgrade the 500 to a DECbridge 510?
    
    thanks

    Lillian,
       The latest version of the DECbridge firmware is V3.0. This is the
    version that contains the Appletalk translation that is talked about in
    this note. If the customer (HKUST?) is still running v2.1, then they
    also missed the v2.2 upgrade wchich gave them SMT v6.2, FDDI source
    address filtering, the ability to disable automatic address learning
    and also ring mapping. If the customer upgrades to v3.0, he'll get all
    these capabilities as well.
    
    Debbie
    

re:                    <<< Note 246.12 by HGOVC::LILLIANTANG >>>
   
  >  What is the
  >  firmware version that will upgrade the 500 to a DECbridge 510?
    
    None. This upgrade would require a hardware module change, from AP to
    AP2.

    THANKS for the info.
    
    1.  re .13) Debbie, you're right, the customer is HKUST.  
    
    2.  same request as .11), is there a copy of the documentation
    mentioned in this note, or other related articles available?  Can the
    release notes for the firmware v3.0 be obtained on the network?  
    
    Thanks again, Lillian