[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
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

3289.0. "DECSWITCH 900EF Config Problems !!" by ZUR01::ACKERMANN () Fri Feb 16 1996 03:40

    
    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.RTitleUserPersonal
Name
DateLines
3289.1My 2 cents....NETCAD::BATTERSBYFri Feb 16 1996 12:2931
    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