Conference 7.286::fddi

1882.0. "ALPHAserver not seen on ring map..." by GJOVAX::OSC001 () Wed Nov 29 1995 13:50

    I've been working on a problem with a customer to correct some FDDI
    (suspected) performance problems, and wanted to run the symptoms
    through this conference to see if it rang any bells.
    
    Customer has set up an isolated FDDI ring to house an imaging
    application and it consists of: 
    
    1) VAXstation 4000 model 90 acting as a PATHWORKS server for approx. 200 
    users.  The VAXstation is connected to the ring through a turbochannel 
    adapter.  No Ethernet connections.
    
    2) ALPHAserver 1000 running VMS 6.1-1H2 and PCI FDDI adapter. This machine
    serves a large MS Access database to the 200 users. Again, no Ethernet.
    
    3) HP9000 server running Oracle Imaging Db.  FDDI only.
    
    4) Cabletron Ethernet-to-FDDI switch to support Ethernet-connected PC
    clients.
    
    5) Wellfleet BCN Network node to provide connection back to the the
    primary ring.
    
    
    About three weeks ago, the user base began complaining that performance
    to the MS Access databases on the ALPHAserver 1000.  We found no
    physical errors either from a DECnet counters point-of-view or from
    VMS's perspective.  We did see a few Ring Initializations, though. 
    Also, the users have been knocked of the PATHWORKS file service on the
    ALPHAserver a number of times with an Abort, Retry, Fail dialog box, 
    although they can simply click on the retry button and get reconnected,
    so the network interruption is short.
    
    The VAXstation reported 20 errors on the FCA0: device, also with some
    ring initializations, so to be safe we replaced the FDDI adapter.
    
    The most disturbing problem, though, is that the ring map that gets
    generated doesn't show the ALPHAserver 1000.  No matter where it gets
    plugged into the CABLEtron switch, it's not seen.  Also, the FDDI
    sniffer won't work properly when it's plugged into the ring adjacent
    to the ALPAHserver 1000.
    
    We have gotten the CS rep. involved to replace the FDDI adapter in the
    ALPHAserver, but we're not convinced that's going to help as there are
    no obvious signs that there are board-level errors.  That swap-out will
    be done this coming weekend.
    
    I am just curious why an FDDI connected node would not appear on the
    map (i.e. what would prevent it from happening), and what controls the
    dissemination of the information to build the map, (i.e. the actual
    FDDI adapter and its associated formware, or the operating system-level
    driver for the adapter.
    
    Does any of this ring any bells, or does anyone have any suggestion
    about where we should turn next?
    
    Any help appreciated.
    
    -gary

    
    It sounds as though the adapter has stopped sending NIF frames. 
    
    Once every 10 seconds, the stations sends a broadcast frame, using 
    Next station addressing. This frame is received by the downstream
    neighbor, and the combination of Next station addressing, and the 
    A bit being not set tells the neighbor that this frame came from the 
    immediately upstream MAC. This is how a station learns the address
    of its upstream neighbor (shown as the UNA in hubwatch)
    
    This station constructs a NIF response frame and sends it back to the 
    station it thinks is its upstream neighbor. The upstream station sees 
    this response, and concludes that the SA of the frame must be the 
    downstream neighbor. 
    
    If the ring mapper isn't seeing the frames, then its likely that they 
    aren't being sent by the alpha.  A reboot usually solves this, at least 
    until it stops again. Use the sniffer, and search for NIF frames from
    the alpha machine. If the sniffer can see the frames being sent, then 
    something else is happenning. 

    Well, we replaced the FDDI adapter on the ALPHA and the problem still
    persists.  I'd like to be able to sniff the network for the NIF
    packets, but we cannot put the sniffer on the ring  and get normal
    results.  It can perform some packet analysis, but it will not run in
    monitor mode (basically hangs the sniffer in monitor mode).  The funny 
    thing is, if the ALPHAserver is removed from the ring, the sniffer works 
    fine.  
    
    We (and the customer) are beginning to suspect the CableTron switch. 
    During an evaluation period some time ago, they had a DECswitch and 
    some other brand in, and never, to their recollection, had this
    problem.
    
    Has anyone heard any knock-offs on the CAbletron stuff, and is it
    possible that a switch problem could cause a server to not appear on
    the ring map (remember that the ALPHAserver has been moved to different 
    ports with the same results.
    
    BTW, thanks to .1 for the explaination of how the map is built.
    
    -gary

    
    With the sniffer removed, ask the Alpha's upstream and downstream
    neighbors to tell you who their neighbor is. If they say the neighbor 
    is the Alpha, then the Alpha is sending NIFs, and the analyzer is 
    weird.