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 |