Conference 7.286::fddi

973.0. "Adding an FDDI adapter to a running system? Be careful" by JEDI::CAUDILL (Kelly - NaC Tech Support - 264-3320) Thu May 27 1993 10:03

    I thought I had seen more discussion on this somewhere but I can not
    find it.  I talked about it in note 918 a little.  But didn't get much
    confirmation/denial/etc.  I saw it happen again yesterday at a pretty
    knowlegeable site so I thought I would stir a little.
    
    If you upgrade a system by adding an FDDI adapter (eg adding a DEMFA to
    a VAX 6000) you must be sure to either remove the ethernet circuit from
    DECnet's definitions or change the topology of the extended LAN.
    
    Here's the scenario:
    
    	The VAX has an ethernet.  The customer puts in an FDDI backbone
    	and bridges this ethernet to the FDDI.
    
    	Eventually they see the light and install an FDDI controller in
    	this VAX.  They switch DECnet on the VAX to use the FDDI controller. 
    	And suddenly performance gets worse and/or things start acting wierd.
    
    If you have a device defined as a LINE in NCP - regardless of whether
    you have it defined STATE OFF - NETACP will allocate and initialize the
    device when STARTNET.COM does the NCP SET KNOWN LINES ALL command.
    
    When NETACP initializes a LAN device, it sets the address to the
    "DECnet modified address" (ie AA-00-04-00-xx-yy).  So, here we have
    this VAX with an adapter on the FDDI which is using this address and an
    adapter on the ethernet (bridged to the FDDI) using the same address.
    So, this one address exists in two places on the extended LAN.
    
    What will the bridges do?  How will DECnet act?  
    
    The way to solve this is to NCP> PURGE LINE <the ethernet circuit name> ALL
    and reboot.  You should probably PURGE the CIRCUIT definition too.
    
    I'm talking about DECnet Phase IV, of course.  The same problem can
    happen with Phase V but then it is easier to solve.  In Phase V, you
    are allowed to have multiple LAN adapters connected, you just need to
    make sure that no more than one of the Routing Circuits which are
    connected the same extended LAN has Enable PhaseIV Address = True.
    
    This problem can also be caused by LAT.  If you tell LAT to init the
    device with the DECnet address, you must be sure to only do so on one
    of your connections to the same extended LAN - and it should probably
    be the same one DECnet is using :-)  But, then again, isn't LAT only
    supposed to be run on one adapter on the extedned LAN anyway?

    Note that OpenVMS AXP Version 1.5 does not allow this problem to occur.
    
    OpenVMS VAX V5.4-3 and on have a Duplicate Address Test (DAT) check. 
    However, that check does not work 100% of the time.  In particular it
    does not work well on FDDI because of the way FDDI frames are removed
    from the ring.  The same DAT check is in OpenVMS AXP Version 1.0.
    
    However, in OpenVMS AXP Version 1.5, the DAT check was modified to work
    100% of the time.  If you have problems with the DAT check in OpenVMS
    Version 1.5 (or later), please let us know.