Conference 7.286::fddi

1210.0. "DECbridge 500 causes network degradation at site!" by STRWRS::KOCH_P (It never hurts to ask...) Thu Jan 13 1994 15:18

    I have a problem which I will be opening a call for with field service.
    I have a customer who has a DECbridge 500 in a configuration which is
    too detailed to put in here. I can fax a copy of a configuration to
    anyone willing to help out on this.
    
    The problem is that when the customer has the DECbridge 500 in their
    network, SIGNIFICANT delays are introduced. This was found by a trial
    and error approach by an outside network consulting firm. I couldn't
    see how this could be, but I saw it for myself. I kept saying that this
    seem improbable, but I was proved wrong. 
    
    This customer just purchased and put this into their network this past
    summer. I am in the processing of verifying the firmware, but given its
    order date, it seems most likely that it is V1.3.
    
    The customer is now removing the DECbridge 500 from their network and
    losing connectivity at one site from the SMF ring we installed between
    the 2 sites. This is a high priority problem. I know this isn't an
    official support channel, but I will be opening a call officially, but
    I wanted to see if anyone was interested in taking a stab at it.
    
    The configuration includes Fibronics 8210 bridges and Spanning Tree has
    been disabled on these bridges because Fibronics said due to their
    configuration, Spanning Tree was not required. Our bridges in the
    network (DECbridge 500, LANbridge 150) are running Spanning Tree.

What sort of delays?  Between which points?  Using what test procedure?
(I can't tell from your statement whether you're talking about FDDI repeat
delay, bridge forwarding delay, or fault recovery delay.)

	paul

    One real simple way that a DECbridge 500/600 series bridge can
    exhibit delays like fault recovery delay, and maybe to a lesser
    degree bridge forwarding delay, is if there are unused AUI Ethernet
    ports (IE: without an AUI cable connected to it). The bridge performs
    MAC maintenance background diags periodically on ports to see if it is
    still a useable port. If there is no AUI cable connected to an AUI
    ethernet port, it will be reported by the bridge operational code as
    a possible dead port. This nusiance can be eliminated by simply putting 
    an AUI loopback on any unused AUI ports of a DECbridge 500/600 series
    bridge. One will see an improvement in the bridge's performance after
    having done this.
    
    Bob