Conference 7.286::fddi

    500 is the max; 100 is sometimes cited as a good design target for
    performance reasons (but 500 works, and is supported).
    
    Note that concentrators with MACs are considered stations, but from
    your topology description, you're nowhere near violating any of the
    limits. If the ciscos can't deal with 40+ stations, offer the customer
    DECNIS 500/600's. Our brouters aren't limited to 15-station rings.
                        

    Unless something has changed recently, Cisco is know to be notoriously
    bad at brigding fddi. The throughput, from the Bradner reports have
    been pretty bad. I havn't seen the latest report, so I don't know if
    this has changed. This may be why Cisco wants to lower the number of
    stations on the ring. I've worked on rings with alot more stations than
    15 and have had no problems.
    
    

    
    Thanks for the input.  
    
    re .1
    
    Thanks, I didn't realize that the concentrators had to be counted also.
    
    re .2
    
    Yup, I know that the Cisco Brouters are bad, I mean when we first put
    up the ring, the FDDI controllers on the AGS+ brouters were dropping
    packets on the input side, when there wasn;t even any traffic on the
    ring, outside of routing updates and one DECmcc station :-). 
    
    
    Thanks again,
    
    Dave
    
    

You might use the difference between 15 and 500 as a way to illustrate how
poor cisco's FDDI implementation is.

Be sure to make it clear that we support the full ANSI standard limit, though
we recommend 100 as a good design practice.  (That's very different from saying
we only support 100... we do NOT say that!)

	paul

    Hi Dave,
    
    ...when you say that the customer is seeing multiple "ring inits" per
    day....can I assume that we are talking about MAC layer or datalink
    layer problems?
    
    What is happeing to the DECnet/IP/LAT/etc. that is running over this
    network?  Are the sessions breaking?
    
    You didn't say anything about the the physical cabling for the
    network....are we certain that each fiber run meets the ANSI specs for
    distance and loss budget?
    
    -Jeff

    
    
    Hi Jeff -
    
    The problem would not appear to be with wiring.  All the fiber runs
    were optically TDR'd when installed. The RFP specs were correct for
    FDDI and were adhered to.  After getting hold of one of the folks
    interfacing with Cisco on the problem, it seems that the ring inits
    happen when they are running backups across the ring.  Initially, the
    problem was really bad, ie. DECnet, LAT, SCS and TCP/IP would all fail
    during an "incident" that seemed to correspond will a ring init and
    claim frames being dumped on the ring.  Cisco found a bug and issued a
    patch (there have been over 40 firmware and O/S upgrades/patches over
    the course of a year).  Now the symptoms have been greatly reduced. 
    Only LAT and SCS traffic seems to get disrupted now and not all the
    time.
    
    To clarify, it appears that Cisco said that it was 15 routers, not 15
    stations that they recommend on the ring.  They guess that the token is
    not making it around the ring and hence a timeout and ring init and
    the claim process starts again.  One thing they will try is to change
    the TTRT parameter.  I guess what I don;t understand is that I thought
    the controller would have to release the token in a timely manner, so
    that it will make around the ring.  What they are implying is that a
    busy brouter will not release the token and the right time, but I
    thought that was in the firmware of the FDDI card, so as to try and
    eliminate those problems.
    
    
    Dave (who is not actively involved in the problem, but interested)

Cisco is full of it.  The more likely answer is that they made a mistake made
by lots of people: falling behind, getting some soft error (like packet loss,
or queue full) and handling that by reinitializing the adapter.  This is a 
known bad idea on Ethernet, but fairly harmless there.  It's a bad idea on
FDDI as well, but somewhat nastier there because it causes ring reinit.
Not that a ring reinit is all that big a problem... but normally it indicates
transmission problems, and this sort of bug would mask those symptoms.

It is definitely the case that the adapter is responsible for releasing the
token at the correct time. This is done by the MAC chip, and all MAC chips
I know of do this correctly.  There's nothing any higher layer function can
do to interfere with this.  Cisco is just showing their FDDI ignorance.

	paul

    
    Thanks Paul,
    
    I appreciate your re-affirmation of the chip set handling the token
    negotiations.  I guess we should be dropping off more "FDDI Primer"
    books at customers. :-)
    
    It is easy to see why the customer is confused by all the smoke and
    mirrors.
    
    Thanks,
    
    Dave
    

Seriously... the FDDI primer is a very good book, and it should be given to
as many people as possible.  ESPECIALLY it should be given to customers who
are being subjected to ignorant nonsense (or FUD) from other vendors.

	paul

    
    	Is the FDDI primer available on the net ?
    
    	Colin