| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
Hello,
I have a strange Config phenomen on 2 Different Hub900:
The Hub-Config is as follows:
HUbwatch 4.1.1
Slot:
HUB MAM Version 4.1.0
1x DECswitch 900EF Version 1.5.2 8
1x Portswitch 900TP Version 2.1.0 7
1x DECSERVER 900TM NAS 1.5 BL95C 5
DECSWITCH 900EF: Slot 8
----------------
Port1 ----------- FDDI External to other HUBs
Port2 ----------- External to DELNI
Port3 ----------- Thinwire Connected to BP
Port4 ----------- LAN Segment 1 BP
Port5 ----------- LAN Segment 2 BP
Port6 ----------- LAN Segment 3 BP
Port7 ----------- External to DELNI
Portswitch 900TP: Slot 7
------------------------
LAN 1 ----------- Group1 (10 Ports) 8 PCs Connected
LAN 2 ----------- Group2 (10 Ports) external no Connections
LAN 3 ----------- Group3 (10 Ports) external no Connections
Thinwire is NOT Connected
Problem:
--------
The Customer connected Port4 of the SWITCH 900EF to LAN 1.
On the PORTSWITCH 900TP he connected Group 1 to LAN 1.
Optical it looks connected. But The Status on Port 4 says: Broken!
The Port 4 State LED # and the --> LED remains off.
Now he changed the Connection of Port4 and Group 1 to LAN Segment 2,
no success. Now he changes them back to LAN Segment 1, now it works!
It works as long as he dont thouches the Config. When he tries
to connect Port 5 of the SWITCH 900EF and Group 2 to LAN 2 he has the
same problem as above. He always has to trie several Times!
The same Problem he has in another Hub with a similar Config of the
Modules, same FW Revision. On this other Hub he changed the BACKplane
and the MAM Module, but the Problem remains on. If the config ones
is "accepted", then the Hub works fine. But as soon as he changes
something on the config (add on of a new Group) the Problem appears
again.
Thanks for any help
Daniel MCS Switzerland
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3289.1 | My 2 cents.... | NETCAD::BATTERSBY | Fri Feb 16 1996 12:29 | 31 | |
I'll take a stab at this, and will preface it with some assumptions.
Assumption - Prior to the customer connecting port 4 of the
DECswitch in slot 8 to LAN 1, there is no inbound traffic coming
into the DECswitch's other ports.
When a DECswitch port has been unused for more than roughly a
couple of minutes, the firmware ceases to routinely perform
MAC maintenance on that port, and puts the port to "sleep" or
as you see it when you look at the port status, it's in the
broken state. It's not broken in the sense of really being broken,
it's simply a state where because the port has been inactive beyond
a certain software timer period it is deemed inactive or "broken"
by the DECswitch firmware.
Now, it's my understanding that if there is *any* port on the
DECswitch with a decent amount of traffic going in either direction
that the other ports will "wake up" when connected to a link such
as your LAN1 very quickly. what I mean by "wake up" is the port going
into the sequential learning, pre-forwarding, and forwarding state. If
a port has been inactive and there has been very little or no traffic
going into or out of the bridge, it will take seconds or up to 1-2
minutes for the transmit and receive queues to fill up. With any modest
amount of traffic the transmit & receive queues should fill up in
microseconds, and the bridge port state led should start to blink and
the traffic --> led should be flickering.
So when the customer changes ports, uses new ports, or swaps ports
there may be some time delay before the port in question goes into
forwarding. Unless I'm mis-interpreting something, I think this
may possibly be what is going on.
Bob
| |||||