| Hello.
I just returned from installing a LAN mostly identical to the Base
Note, and have the same problem.
VERSIONS: All modules are at revision 4.1.1 of firmware. Mam=4.0.1,
DECrepeater 900FP at 2.0.0, and DECswitch 900EF's are all at 1.5.2, and
DECbrige 90FL are at 3.9.
CONFIG: I have three DECswitch 900EFs (slot 6&7&8) with all Six
Ethernets of slot 6 set to IMB-1 through IMB-6, set to a Cost of 20
under the bridge port priority window. Slot 7 switch has a few front
panel ports, the ThinWire bus on port 3, and ports 5,6,7 on IMB 1,2,3.
Slot 8 Switch has a backup (higher cost) backplane ThinWire on Port 3
and ports 5,6,7 on IMB-4,5,6. The Portswitch port groupings are a
diagonal line, from the top left. The MAC is set to 1,2. The THINWIRE
stub (group 7) is disconnected, but it's "menu" option is on ports 1,2.
PROBLEM: I have a blinking left LED (bridge standby) on all ports of
the Slot 6 Switch, as I expected, cause the cost of those redundant
ports are high. I have Solid LED's on all other bridge ports (as I
expected) except for slot 7 port 5. I don't know why this would be
the case.
VERIFICATION: I went to the remote closet, and put IRIS on the remote
fiber port. I saw Bridge Hello messages coming one per second. The
Address of the Hellos were PORT 3 of Slot 8. (The ThinWire Bus).
I removed the Bridges from IMB-1, and MY TRAFFIC DID NOT STOP. I
connected the ThinWire Stub of the Portswitch (group 7) to the
backplane Thinwire and saw the hellos as I expected. I removed the
ThinWire Stub from the backplane (and the little green THINBUS LED
changed from Solid to blinking on the 900FP), but MY TRAFFIC DID NOT STOP.
Why has the Group 7 pull down been implemented if it does not do
anything? I wish to segment my traffic on group 1, into a different
collision domain than my Thinwire bus, which has other uses. Is there
a patch kit or firmware upgrade to remedy this?
JR
|
|
This problem has been reproduced in Littleton by Engineering.
A fix is currently being worked on. Once it is completed it must go
to system test before it can be released.
In the interim the safest thing to do is NOT upgrade ANY 900FP
that will have its ThinWire disconnected from the backplane. Running
them at V1.2 with the upgraded MAM code should not create any problems.
The fix when it is developed and released will probably be known
as version 2.0.1. It should be available via WWW, anonymous FTP, or
the bulletin board. It will NOT be part of the DCF kit until the next
major release scheduled for the Q1 CY 96.
The fix used in .0 is a band-aid at best and does not appear to
survive a power failure or powering off of the hub.
|
| Well,
the last update to this problem was 5 months ago.
Is there a fix available for this yet?
What I have seen is that once you move a set of ports from the default
to another group, both group 1 & 2 are created also leaving group 7.
If you then connect group 1 & 2 to their own backplane LANs, this is
OK. However, if you then connect a DECswitch 900EF stub to the
thinwire, LAN 1 and LAN 2, you get a spanning tree shut off of LAN 1.
If according the portswitch screen, the thinwire is associated with
group 1, why can't the group which has the thinwire as a member be
connected to the thinwire LAN?
|