Conference 7.286::fddi

Well,

It looks like Cisco does not agree with APPLETALK and NOVELL formats
when they are on the FDDI...

Our Bridges were transparent Ethernet-to-Ethernet and as far as I know
we implement an agreed fix for Appletalk, no private encapsulation. 
I would assume this is true also for Novell IPX. 

So - If we are sure about the Ciscos being up to rev ?
Do cisco claim to support these protocols on FDDI ?

If they do, and the boxes are up to rev - I motion we start throwing stones ;-)
and also add this one to the list of how Cisco really 
copes with the FDDI environment. Assuming you customer did not miss
any fine print in the documentation.

You might want to start telling your customer about FDDI on DECNIS 600
that will arrive at Interop this fall.

Torbjorn

    re: .0
    
    What frame formats are they using on the NetWare network? ETHERNET_II,
    ETHERNET_802.3?
    
       - Larry

    
    cisco supports routing of AppleTalk across FDDI and I've seen it work
    between cisco routers on FDDI.  (I'm waiting for one customer to switch
    on AppleTalk over the DEMFA(s) connected to the same ring and see what
    happens ...)
    
    You say all protocols are routed and not bridged, but do the
    Ethernet/FDDI bridges pass AppleTalk?  If so, did the customer switch
    off AppleTalk on the Ethernet interface in the cisco box when he
    enabled it on the FDDI interface?  If not, did he ensure that the
    network number(s) and zone list were identical?  (I'm not sure if cisco
    would even allow more than one interface with the same AppleTalk info)
    
    

    If your customer is using AppleTalk Phase 1, then the problem is
    occuring due to special processing of such packets by our bridges
    (a few notes back, there is a detailed explanation of how this works
    by Paul Koning in response to a query).  The good news is, it can
    be changed to work with Ciscos: just remove the AARP protocol type
    from the NTP table using management.
    
    As far as the Netware problem: the key question is the one that Larry
    asked.  My guess is that your customer is using the "raw 802.3" Novell
    format.  If so, you can do one of 2 things: ask them to use Ethernet
    format instead if possible.  Or, you may be able to get a special version
    of the DECbridge firmware to deal with precisely this problem when Ciscos
    are on the same FDDI.  Send mail to LEVERS::KRISHNA if you prefer the
    latter (I would recommend the former).
    
    Anil

    RE:.-1
    
    Let's assume for the moment that the problem with Appletalk routing is
    as described. Ie. The customer is using Appletalk V1. If we remove the
    entry for AARP from the NTP table, would Appletalk V2 still work and
    would Appletalk V1 work on the other side of the bridges?
    
    In other words, if this entry messes up the cisco and does nothing
    useful, why is it there? I think we may be on the right track. I just
    need to understand this a little better before I go to the customer to
    discuss.
    
    Regarding Netware, the customer says they are using 802.3 packet
    types. This is probably their problem. I'll try to convince them to
    change Netware as well as contacting the person mentioned to get a
    further description of the problem and how it is resolved.
    
    Thanks,
    Mike

    If you remove the AARP entry from your bridges then depending on your
    configuration, AppleTalk Phase 2 might stop working across the bridges
    (but not across a DECbridge/Cisco router pair).  If you *didn't* have
    a Cisco router on the FDDI, both AppleTalk 1 and 2 would work across
    all bridges.  The reason for having the NTP table is to make both
    AT 1 and 2 work, normally it wouldn't because of a misunderstanding
    by AppleTalk 2 designers.  If you really need to understand the
    details, look at note 628.3.
    
    Anil

    Thanks for the explanation.
    
    Is there any way to make Appletalk 1 & 2 work simultaniously with
    DECbridges and Cisco? If so, how? If not, is this cisco's fault or ours?
    
    Thanks,
    Mike

I today read a document that had a pointer to a FIX needed for Novell IPX
on FDDI.

IPX FIX - correct handling of Novell IPX DSAP=FF, NO specification reference,
Practice described in DEC Notes file;  FILES::TOKEN_RING  Note 16.4


For the Appletalk the pointer was te following;

APPLEtalk II FIX - IEEE (draft) 802.1h 05-MAR-92, Draft Recommended Practice,
MAC bridging in IEEE 802 LANs (APPLETALK II FIX)

Probably you should inform the customer about this and ask him to
talk to Cisco.

	Torbjorn

PS,

There is another one too -

KINETICS FIX - correct handling of 802.2 frame with incorrect length value
on CSMA/CD LAN, NO specification reference, practice described in DEC Notes
file  LEVERS::ARCH_IMP  Note 10.2

I don't know if this is an open notes file.