| 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 |
I have an issue with 4 DEC FDDI concentrators on 3 rings. These 4 FDDI
stations are issuing SMT frames advertising their upstream neighbours as unknown
using the reserved address 00-00-00-f8-00-00. These devices later became
unavailable to SNMP management or TCP/IP pings.
Is this known behaviour? We saw this once at the weekend but did not realise it
at the time when one concentrator FCGENA_180A was hung in management. We also
had one 900TH that was also issuing 00-00-00-f8-00-00 as its upstream neighbour
this was swapped as we thought at that time it was faulty.
Regards
Alan Brodie
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2042.1 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Wed May 15 1996 16:43 | 14 | |
That address was given to ANSI by Digital for the specific purpose
of identifying unknown addresses.
In the ANSI SMT spec I have (7.2c) it's referred to as
SMT_Unknown_Address. See section 7.1.6 and 8.2.2.1, for example.
...from 8.2.2.1:
UNA Upstream Neighbor Address. The UNA identifies the
most-recently-known upstream neighbor address. This
variable is exported to extermal management entities. If
unknown, the UNA is reported as SMT_Unknown_Address.
MDL
| |||||
| 2042.2 | NPSS::MDLYONS | Michael D. Lyons DTN 226-6943 | Wed May 15 1996 16:46 | 5 | |
P.S. I assume you made a typo - SMT-Unknown-Address is in the
specification as 00-00-F8-00-00-00, not 00-00-00-F8-00-00. Is the
concentrator really reporting the wrong address?
MDL
| |||||
| 2042.3 | My mistake | SEDSWS::BRODIE | Thu May 16 1996 05:02 | 8 | |
My mistake in the original note I failed to point out that the 900MX's in question are issuing the SMT broadcast advertising their UNA (Upstream Neighbour Address) at 00-00-00-f8-00-00 continously. This I believe is not normal behaviour. Regards Alan | |||||
| 2042.4 | 49393::HOTZ | gimme an F !!!, ...D !!!, ...D !!!, ...I !!!, what's that spell !!!? | Fri May 17 1996 10:56 | 27 | |
Do you have DECswitches 900 V1.4.* or earlier on the concentrators? They had a problem with NIFs. It's fixed in 1.5.*. If that's not the case, what's connected on the concentrators? Remember, the FDDI-MAC is at the exit (B-port) on a concentrator. Therfore the devices on the m-ports are upstream to the concentrator. greg schweiz, suisees, switcherland. . . When a DECswitch 900 is removed from a concentrator M port ... for longer then 2 * 4 minutes (2 * T_NN_Out, 2* 228 sec) and then reconnected, it will stop sending and responding to NIFs. However (in the 2nd case) it sets the "Address recognized" and "Frame Copied" frame status indicators in NIF request frames from its upstream neighbor and it learns the UNA, as seen with HUBwatch. The MAC counters also increment the Copied Count, but not the Transmit Count. An FDDI ring mapping device (HP-Analyzer) will see a ring discontinuity since the up- and downstream neighbors of the bridge can't find out what's inbetween them (DNA, UNA = 00-00-F8-00-00-00) | |||||