[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

2064.0. "DECbridge 620 mngt problem" by 54625::VANLOOCK (Patrick DTN 856-8648) Thu Jun 13 1996 05:41

   Hi,
   
   At a customer site, having a FDDI-ring comprised of
   5x DECbridge 620 + DEC-concentrator 500  (connecting 
   3x VAX via DEMFA) + 2x Chipcom Galactica + Cisco 7000,
   customer complains that, from time to time one of the 
   DEC-bridges becomes inaccessible for management:
   queries to this bridge via FDDI (using DECmcc (ELMS) 
   or HP-Openview (SNMP)) fails with 'no response from target'-
   messages, although this bridge still does his job at bridge 
   level.
   This situation lasts for several days and then disappears
   (management again ok), customer noticed this behaviour on
   different bridges, sometimes two at about the same time...
   
   After some investigations:
   
   ==> found management commands (ELMS as well as SNMP)
       fail IF they arrive at the 'problem' bridge via
       the FDDI-ring, but are ok if they arrive via an
       ethernetport of that bridge
       a ping fails via FDDI, but is ok via Ethernet;
        for a ping via the FDDI: the arp-cache of the issueing
        station gets the MAC-address of the FDDI-port of the 
        problembridge (station AND bridge in same IP-network)
        but the request times out...
   
   ==> DECbridge: Software Version = "V1.4"
                  ROM Version = V2.9.0
                  no filters set (for address nor protocol)
                 
   What might be happening there??
   
   Patrick
T.RTitleUserPersonal
Name
DateLines
2064.1NPSS::RAUHALAThu Jun 13 1996 17:0417
    It seems that the 620 is unable to respond to it's own address.
    Rather than processing the management packet (addressed directly
    to the bridge) it instead treats it like a regular packet and will
    forward/filter it.

    The reason the arp request works is that it gets send to the
    broadcast address, not a specific device address.

    was the customer seeing any crashes before installing V1.4 code?

    Is it possible to check (using snmp or MCC) the status of the
    4 addresses of the bridge while it's in this messed up state?
    Normally an address will be "learned" on port 1-4 but the
    4 bridge addresses should never be learned on any port, their
    status should be listed as "self".  I'm thinking maybe the
    status got messed up somehow.
    ken
2064.2Static entries with problems...54625::VANLOOCKPatrick DTN 856-8648Fri Jun 14 1996 06:3839
    
    Ken,
    
    According to some notes I made at that time:
    (hand written, no logfiles, so I'm not quite shure about query/answer)
    queries done after 'moving' MCC-station to first Ethernet-port (Line 2) 
    of this bridge ...
    
    MCC> dir bridge jnj_ns:.janbel.bridges.decbridge_620_binfb2
    
                    Address = { 08-00-2B-2C-76-FB,     <== FDDI-port
                                08-00-2B-6C-76-FB,
                                08-00-2B-2C-76-FC,
                                08-00-2B-6C-76-FC }
    
    MCC> show bridge jnj_ns:.janbel.bridges.decbridge_620_binfb2 
         forwarding database static entry 08-00-2B-2C-76-FB all char
    
       ==> reply: 'variant selector information not found in
                   variant selector list'
    
    MCC> show bridge jnj_ns:.janbel.bridges.decbridge_620_binfb2 
         forwarding database static entry 08-00-2B-6C-76-FC all status
    
       ==> reply: no such entity
    
    At this moment: all bridges behave well, so I can't get more
    (accurate) info...
    
    V1.4 was installed more than 1 year ago: reason: monitoring
    via SNMP...
    
    What do you mean with a 'crash'?  Customer didn't complain about
    lost connections ...
    
    Patrick
                          
    
                                                               
2064.3NPSS::RAUHALAFri Jun 14 1996 19:0111
    by "crash" I mean an Unsolicited Reset.
    the bridge will be down for about 1 minute while
    it runs diags and pre-forwarding mode. I was
    wondering if they had any history of crashes
    with old V1.3 code.

    Is this customer problem fairly recent (1-3 months)
    or have they been seeing this problem since they
    started using V1.4? (over 1 year).

    ken
2064.4no "crash" seen last months...54625::VANLOOCKPatrick DTN 856-8648Mon Jun 24 1996 12:1417
    
    
    Hi Ken,
    
    Sorry for this late reply (I've been 'out' for a week...)
    
    The customer can't remember when this problem first occured but
    he guess about  six months ago.
    Although the "Unsolicited Reset" counter on the bridges that recently
    experienced management-problems is now at 3 on bridge BINFB2 and
    1 on bridge BINFB6, customer was not aware of any 'unexplainable reset'
    as a "crash" would have caused.
    
    Checking the unsolicited resets on the other bridges: bridge BINFB4
    has currently 1, the other 2 (BINFB3 and BINFB5) have 0.
    
    Patrick        
2064.5NPSS::RAUHALAMon Jun 24 1996 16:553
    we are working on trying to duplicate the problem...
    
    ken