| The log will show a message for when the upgrade occured and the fact
that the configuration was cleared at that time.
The error log (for most hub modules) is a rolling log, keeping the last
N entries and displaying them in reverse cronological order (most
recent to least recent). In the case of the hub manager, it keeps 6
entries. It is not modified in any way by looking at it.
If you have an SNMP mib browser, you can read the error log using the
pcomErrLog group; see the DEChub 900 Public Common MIB.
|
| We have had another failure but this time its taken out 2 floors and affected
many users.
The original config was:
Flr
30 HUB 900
-----------------
|DB900| |90C|
---+-[B] | | |
| | | | |
| | *--+-----+-* |
| | | | |
| | [] | ----|
| | \| |
| | [] | |
| -----\-\---------
| \ \
| \ ----90C
| \
| ----90C
|
Flr | +
29 | HUB 900 +
| ----------------- +
| |DB900|90C| |DB| +
---+-[A] | | |90| +
---+-[B] | | |[]+----------[ ]
| | | | | | +
| | *--+-*-+--+* | +
| | | | | | +
| | [] |---- ---| +
| | \| | +
| | [] | | Existing
| -----\-\--------- Thickwire
| \ \
| \ ----90C
| \
| ----90C
|
SUN file server
We made some changes to the hub on 29. The AB ports of the DB900 were set to
the front panel so we could connect 30 and the SUN into FDDI. The hub on 29
and on 30 had the in-band IP address set with slot 8 (DB 900) as the IP
services. The DB 900 did not have an IP address.
These changes were made around 6 PM. The next morning the hub on 29 had lost
its IP address. The DB 900 was also reset as port 3 no longer connected to the
thinwire, it was back to the front panel.
We entered an IP address via the setup port and then thru HUBWATCH redirected
port 3 back into the thinwire. The config has been stable for the last 2+
weeks.
Config as of Saturday morning:
Flr
30 HUB 900
-----------------
|DB900| |90C|
---+-[B] | | |
| | | | |
| | *--+-----+-* |
| | | | |
| | [] | ----|
| | \| |
| | [] | |
| -----\-\---------
| \ \
| \ ----90C
| \
| ----90C
|
Flr | +
29 | HUB 900 +
| ----------------------- +
| |DC900|DB900|90C| |DB| +
---+-[M] | | | |90| +
-----+-[M] | | | |[]+----------[ ]
| ---+-[M] | *--+-*-+--+* | +
| | | | | | | | +
| | | A*====*B | | | | +
| | | B*====*A | | | | +
| | | | | | | | +
| | | | [] |---- ---| +
| | | | \| | +
| | | | [] | | Existing
| | ----------\--\--------- Thickwire
| | \ \
| | \ ----90C
| | \
| | ----90C
| |
SUN file
servers
We have not made any changes to 30 other than connecting to a concentrator
instead of a bridge.
29 had the A and B of both the bridge and concentrator pushed into the
backplane. Port 3 remained connected to the thinwire in the hub. Only the
hubs have an IP address set.
This morning both hubs had lost their IP addresses. The FDDI segment in HUB
29 was gone. The DC 900 had lost its A and B ports into the backplane
and were now back to the front panel. The DB 900 had also lost its A
and B ports and the thinwire into the hub, all were back to front panel.
Another interesting thing came up is that the SUN servers complained of seeing
duplicate addresses. The message said that they saw two duplicate IP addresses
and gave the MAC addresses for the two DB 900's. The MAM doesn't have a MAC
address and the bridges don't have an IP address. So how would the two get
equated?
The hubs, bridges and concentrators are production units and the firmware was
pulled as part of DCF kit. I can get exact revs if necessary but off the top
of my head:
HUB ROM 1.1.6 Firmware 3.0.0
DB900 ? Firmware 1.2.1
DC900 ? ?
Any ideas??
Confused,
dave
PS. Customer is checking to see if anyone has pirated the 2 IP addresses used
for the hubs.
PSS. I have also power cycled both hubs when the firmware version (3.0.0)
appeared in the display during the self test. This was done after all
the network changes on Saturday. I was told that this would insure
a complete restart of the hub.
|
| Can you read the error log on the hubs that lost configurations?
It looks like they've been through a factory reset. There is a
mechanism in the firmware that can do this intentionally for certain
bugs (when not clearing the config might leave the hub unable to run at
all). If this has happened there will be a marker in the error log.
You can read it at the setup port, or if you have a tool that will
compile the mib (like PNV), it is readable via the pcomErrLog group.
|
| We have some problems that seems to be close to the above.
We saw different funny things (I wrote separate in other entries here). One was
the FDDI ring (ring between two hubs, with each 2 Concentrators) and 7 HUBS
more with Bridges900, each dual homes to the two building HUBs.
Two CISCO 7010 dual homes to the buildinghubs, too.
One day, the FDDI ring went slower and slower. (Polycenter Netview turned some
nodes red) After power off/on of both building-HUBs, the ring went o.k., but
one of both loosed the IP address. Only one, and only the address. All other
configuration stored o.k.
On an other HUB (same customer, other city, other FDDI, same
configuration-philosophy, only one building HUB). We loosed the the IP adress
of the building HUB, too. The same time some other things in the hub happened,
I described in other entries.
Are there known problems, fixes, ..... arround..
Found no entries in the LOG file except
Entry = 10
Time Stamp = 0 0
Reset Count = 14
Stop Thrash Cleared Non-Volatile Data
Entry = 9
Time Stamp = 0 0
Reset Count = 13
Catch VO=07C SR=2000 PC=41F0A6
Entry 8,7,6,5 are like entry 9, but other SR and other PC
Roland
|