Conference 7.286::fddi

1697.0. "Ring initializations and strange UNA/DNA address (00-00-f8-00-00-00)" by 51847::EBC () Fri May 26 1995 10:19

Konfiguration:
Port shown beside modules are Hub Backplane connections.
Ports shown inside modules are front panel connections.
There are currently no other systems connected to the FDDI.
The Decs900EF's bridge to a number of Ethernet segments.
The problems started when 5 XL590 NT systems with DEFTA interfaces were
connected to the FDDI. These have been moved back to Ethernet and a 6'th
XL590 connected to the FDDI.

			HUB 1					HUB 2
	Deccon900-1	Deccon900-2	Decs900EF-1		Decsw900EF-2
	---------	---------	---------		---------
 AXP OSF----1	!A  ---A!	!   ---A!	!   ----------------A	!
 DEFAA	!  MMF	!   !	!	!   !	!	!   !		!	!
	!	!B---	!	!B---	!   B--------	       B!	!
	!	!	!	!	!	!		!	!
	!	!	!	!	!	!		!	!
	!	!	!	!	!	!		!	!
	!	!	!	!	!	!		!	!
	!	!	!	!	!	!		!	!
	!	!	!	!	!	!		!	!
	!	!	!	!	!	!		!	!
	!	!   --------5	!	!	!		!	!
	!	!   !	!  MMF	!	!	!		!	!
 XL590 NT --6	!   !	!   6	!	!	!		!	!
 DEFPA	!  UTP	!   !	!  UTP	!	!	!		!	!
	---------   !	---------	---------		---------
		    !
		Analyzer

Intermittantly large numbers of ring initializations are observer (on the
modules counters and reported by the AXP).

Each time it is seen on the analyzer, that the XL590 reports unknown UNA and
then rapidly sees it's UNA again (in this case the UNA is the AXP). The same
is seen if the XL590 is moved to port 6 on Deccon900-2 (in this case the 
analyzer is the UNA) or if Deccon900-2 and XL590 is moved to Hub 2.

In both of the two cases when we have monitored the problem with the analyzer,
we have also seen a strange behaviour on the Decs900EFs.

The first time Decs900EF-1 was not visible on the ring and it's neighbours
reported seeing an intermediate system with address 00-00-f8-00-00-00.

The second time Decs900EF-1 reported a DNA with address 00-00-f8-00-00-00 and
Decs900EF-2 reported an UNA with address 00-00-f8-00-00-00.

In both cases a reset with current settings of the Decs900EF's cleared up the
addressing problem, and subsequent attempts to reproduce the problem were
unsuccessfull.

00-00-f8- is an address block assigned to Digital, but I am not aware of any
special use of it, and 00-00-f8-00-00-00 does not look like a genuine address.

Not having much experience troubleshooting FDDI, I find it hard to find out
what is going on, so any suggestions would be much appreciated.

Erik B. Christensen
MCS-COMMS
Copenhagen

    >>In both of the two cases when we have monitored the problem with the 
    >>analyzer, we have also seen a strange behaviour on the Decs900EFs.
     
    Well,....don't keep us in suspense. :-)
    
    What's the "strange behaviour" you see on the DECswitch 900EF's??
    Can you describe it? What are the LEDs doing? Does the DECswitch
    crash? Are there eror log entries in the DECswitch?
    I can't read between the letters of "strange behaviour" too well.
    
    Bob

>>00-00-f8- is an address block assigned to Digital, but I am not aware of any
>>special use of it, and 00-00-f8-00-00-00 does not look like a genuine address.
    
    I believe we "donated" 00-00-F8-00-00-00 for use as a NULL address
    rather than use the older "00-00-00-00-00-00" address.  We've been
    using the 00-00-F8-00-00-00 address in this way for a few years now.
    
    After Paul Koning left Digital, I believe Henry Yang (NETCAD::YANG)
    became keeper of the Digital OUI's and protocol id's.  Feel free to
    check with Henry for more info on this.
    
    /l

OK, the hub modules reporting 00-00-F8-00-00-00 as the UNA/DNA instead of their
real UNA/DNA was the "strange behaviour" to me. After reading .2, I suppose it
just means the station reports not seeing any neighbour.
There were no abnormal indications on the module leds and the modules were
seemingly functioning correctly (traffic was floowing across the ring without
noticeable interruption).
On both the concentrators and the bridges "ring init's received" were increasing
rapidly but "ring init's initiated" stayed at 0.

Erik

Hi,

I had the same address on a DECBridge900MX, FW1.4.0. The problem I have is
that the listener from DECELMS will report an error and is not able to scan the 
ring anymore. ELMS is used in the EY-D994E course which I give here in Nijmegen.
Resetting to defaults or loading again the firmware is not the solution. The
strange thing about it is that it is only one bridge that have this "problem".
What I want to try is to load the V1.5.0 software in the DB900 (Will become a
DS900EF hopefully).

Lodewijk
[Posted by WWW Notes gateway]

00-00-f8-00-00-00 is the SMT-Unknown-Address

I had escalated this, the answer was: it's fixed in V1.5 of the DECswitch 900.

The problem:
The switch v1.4.0 stops sending and responding to NIFs if it is disconnected
from the ring for more then about 8 minutes (2* T_NN_Out). (T_NN_Out > 228s per
SMT 7.2e)

greg