[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

3518.0. "strange behaviour of DECswitch-900EF fwding tables" by CHEFS::PADDICK (Michael Paddick - BRS Bristol, UK) Wed May 08 1996 09:52

         We have observed a strange behaviour with a DECswitch-900EF 
         when disabling bridge ports via HUBwatch.
         
         
         In the following diagram,the FDDI port (1) of the DS900 is in 
         backup due to spanning tree, the root bridge is out on the 
         Ethernet somewhere, and the DECswitch is set up for 
         LANbridge-100 STP. 
         We turned the Ethernet port (7) of the DS900 'off' from 
         HUBwatch, and we were then unable to talk to the 
         DECserve-90TL. After much investigation, what appears to be 
         happening is :-
         On examining the forwarding table in the DS900. Normally the 
         MAC address for the DECserver comes up as port 3 (backplane 
         thinwire). BUT when we 'disabled' port 7 (the active spanning 
         tree port), we could no longer ping the DECserver or connect 
         via LAT, and on examining the forwarding table, the MAC 
         address for the DECserver was showing on port 7!
         
         Further experimentation showed that if we disable whichever 
         port on the DECswitch that is in a STP forwarding state, the 
         MAC address for the DECServer moves to that port, and the 
         server then goes 'un-reachable'. 
         
         The same behaviour shows if the FDDI is the STP forwarding 
         link, and that is then disabled from HUBwatch. Ie. the MAC 
         address for the DECserver moves from port 3 to port 1.
         
         If we separate the Ethernet into two sections such that there 
         is no loop between the two bridges, then the problem does not 
         exist. If we re-connect the two sections of the Ethernet via 
         a third 10/10 bridge, the problem re-appears.
         
         Putting a PC running IRIS on the thin-wire channel (via a 
         DECrepeater-90C) shows that while the switch is in this 
         state, only Broadcast traffic is present on the thin-wire, 
         and the ping traffic generated by the VAX is not forwarded 
         onto that channel.
         
                 *****************************
                 *     FDDI Ring             *
                 *****************************1
          ................             .............    .............
          .              .             .           .3   .           .
          . DECbridge    .             .           .~~~~.DECserver  .
          .      510     .             .DS900EF    .    .     90TL  .
          .              .             .           .    .           .
          ................             .............    .............
                 |                           |7
                 |                           |
                 |                           |
         --------------------------------------------
            |          Ethernet
            |
       ............
       .          .
       . VAX      .
       ............
         
         
         To summarize:-
         1. If we disable a port that's in STP forwarding, any device 
         on the thin-wire channel goes unreachable, and it's MAC 
         address appears to move to the disabled port.
         2. If we disable a port which is in STP backup, there's no 
         problem.
         3. If we actually physically unplug an STP forwarding port, 
         there's no problem. In fact, once a port is disabled and has 
         shown the 'problem' if that port is then unpluged, the 
         problem goes away.
         4. The switch is running version 1.5.2 firmware.
         5. HUBwatch is version 4.1 for DOS.
         6. HUB is running version 4.1.1.
         
         
         Any idea as to what might be going on? I guess it's something 
         to do with STP running across the 'disabled' ports. 
         
         Meic.
    
T.RTitleUserPersonal
Name
DateLines
3518.1Any answers?CHEFS::PADDICKMichael Paddick - BRS Bristol, UKMon May 13 1996 12:383
    Doesn't anyone have any comments on .0 ??
    
    
3518.2NPSS::WADENetwork Systems SupportMon May 13 1996 13:117
    
    I'll take some time in the lab this morning and post my results. 
    
    Bill Wade
    Network Product Support

    
3518.3NPSS::WADENetwork Systems SupportTue May 14 1996 18:5525
    
    I worked on this in the lab and was unable to reproduce the problem.
    
                                      FDDI
    			   ----------------------- backup
                           |			  |
    			DEFBA(A)	     (B)DEFBA --------HUBwatch PC
                           |			  |      3
                           |7			 7|
    	                   -----------------------
			              |
    				    root
    
    Disabling port 7 on B caused no problems and the PC stayed with port 3. 
    I tried with both LB100 and IEEE 802.1d spanning tree mode via the
    root.
    
    Is your DEFBA in Spanning Tree auto-select mode?
    
    What version of code is running on the DEFBA?
    
    Bill Wade
    Network Product Support
    
    							
3518.4Channel 3 internal or external?CHEFS::PADDICKMichael Paddick - BRS Bristol, UKThu May 16 1996 14:3814
    Bill,
    
    How was your PC connected to port 3?
    
    Was it via a crossed UTP cable direct into the port, or was it via some
    form of repeater card across the thin-wire channel (3)?
    
    
    I can't get access to our network todey, but I will try to repeat the
    exercise. I did try repeatedly on the day it was happening.
    
    Regards,
    
    Meic.
3518.5Answer to .3 questionsCHEFS::PADDICKMichael Paddick - BRS Bristol, UKThu May 16 1996 14:5012
    Bill,
    
    To anser questions in .3 that I forgot:-
    
    The DEFBA is running "HW=v1/2,RO=v0.4,SW=v1.5.2"
    
    It's running LB100 mode, and is not autoselect. 
    (We have LB100's in our LAN).
    
    Regards,
    
    Meic.
3518.6DECswitch900EF doe not default to the thinwire....NETCAD::BATTERSBYDon't use time/words carelesslyThu May 16 1996 14:549
    There is a veiled reference made in .0 to the use of the 
    hub backplane thinwire channel. Please keep in mind when 
    using the DECswitch900EF, that there is no port that defaults
    to the backplane thinwire channel nor is there any default
    connection made to the thinwire channel. Port 3 can be re-directed
    to the thinwire channel as an *option* from HUBwatch, but there
    is *no* default connection made to the thinwire channel.
    
    Bob
3518.7NPSS::WADENetwork Systems SupportThu May 16 1996 15:0613
    Mike,
    
    The DEFBA is locked down to IEEE 802.1d spanning tree mode by default.
    If you have LB100s in your net you need to set the DEFBAs to
    auto-select so they will revert to LB100 spanning tree mode.
    
    Looks like you have two spanning trees running here.
    
    
    For my test I came in through the front panel port 3.
    
    Bill                
     
3518.8CHEFS::PADDICKMichael Paddick - BRS Bristol, UKThu May 16 1996 16:2522
    Re: .6  I know that port 3 doesn't 'default' to the thinwire, and
    I wasn't hinting at that in .0.
    We have the DECserver-90TL on the backplane 'thin-wire' channel, and
    therefore have to have port 3 of the DEFBA on that channel, as port 3
    is the only one that can connect to the 'thin-wire'.
                                                        
    Re: .7 As I stated, the DEFBA is set up for LB100 mode, because I know
    for a fact that there are LB100's in the LAN. Therefore, we only have a
    LB100 STP domain across all our bridges. I know it's set up for LB100,
    because I set it that way (not autoselect) with HUBwatch.
    
    Bill, 
    
    Is there any chance you could repeat the exercise with port 3
    facing in to the backplane, maybe via a repeater to the PC, or perhaps
    you have a DECserver you could put in there and try to ping it etc.
    like I have here. 
    This may be the significant difference.
    I will try to repeat your configuration and see if it still happens 
    here. My guess is that it wont.
    
    Meic.
3518.9Autoselect is only way DEFBA's will see LB100's...NETCAD::BATTERSBYDon't use time/words carelesslyThu May 16 1996 16:449
    >> because I set it that way (not autoselect) with HUBwatch.
       
    Ok let's get our terminology correct....
    Uhmmm what Bill is trying to tell you is that in order for the
    DEFBA's to *see* the LB100 spanning tree hellos, you must *set*
    the DEFBA's to autoselect. The DEFBA's aren't going to hear the
    LB100's unless you *set* them *to* autoselect mode. Got it? :-)
    
    Bob :-)
3518.10Definitely LB100, and Definitely goes wrong.CHEFS::PADDICKMichael Paddick - BRS Bristol, UKFri May 17 1996 12:1421
    OK Bob,
    Sorry. I have got the DECswitch set up for Autoselect, and it has
    switched itself into LB100 mode having seen a LB100 multicast inbound.
    The important thing from the point of my 'problem' is that all the
    bridges in our LAN are running in LB100 mode, as they now are.
    I know that I need the DECswitch to be in Autoselect. I just got a bit
    confused with the terminology.
    I *definitely* do not have multiple STP domains. The root bridge as
    perceived by the DEFBA is the same as the one seen by all other bridges
    in our LAN.
    
    Anyway; Bill,
    I have repeated the experiment this morning, and it is definitely
    behaving in the way I described, if the DECserver, or any other device
    is on port the backplane 'thin-wire' channel via port 3.
    It seems that the DECswitch's frowarding tables get confused when a
    port is disabled by SNMP, as different from physically 'broken' by
    unplugging the cable.
    
    Meic.
     
3518.11NPSS::WADENetwork Systems SupportFri May 17 1996 12:5321
    I'll give it another try with the DEFBA(B) port 3 redirected to the BP 
    thinwire and the HUBwatch PC coming in to the thinwire through a repeater 
    port -


                                    FDDI
		   ----------------------- backup
                   |			  |
		DEFBA(A)	     (B)DEFBA ----------------
                   |			  |   3(BP thinwire)  |
                   |7			 7|                   |
                   -----------------------                    |
	                  |                               repeater
    	    	    	 root                                 |
							      |
							      |
							 HUBwatch PC
	
    
    Bill 
3518.12Thank ewe.CHEFS::PADDICKMichael Paddick - BRS Bristol, UKFri May 17 1996 13:026
    Thanks Bill,
    
    Your diagram in .11 looks the same as I have here.
    
    Meic.
    
3518.13NPSS::WADENetwork Systems SupportFri May 17 1996 21:4213
    I was able to reproduce the MAC address moving to the disabled port.  
    
    The communication between modules on the thinwire through port 3 on
    the DEFBA did not appear to be disrupted as the address moved back to
    port 3.  It looks like the address moves to the disabled port if the
    source is quiet.  Strange.
    
    I advise you to open an IPMT against the DEFBA so we can track the problem.
                                                   
    Bill Wade
    Network Product Support

    
3518.14IPMT on its way.COMICS::BUTTGive me the facts real straight.Mon May 20 1996 08:146
    Bill
    
    Mike has filed an IPMT for this problem. You should see it soon !
    
    Rgds Richard.