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

Conference npss::gigaswitch

Title:GIGAswitch
Notice:GIGAswitch/FDDI Jan 97 BL3.1 914.0 documentation 412.1ion 412.1
Moderator:NPSS::MDLYONS
Created:Wed Jul 29 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:995
Total number of notes:4519

942.0. "Disable Spanning Tree on Giga?" by SPANKY::DANIELS () Thu Feb 27 1997 17:48

A customer has 4 Fddi rings comming back to a Gigaswitch with one large 
spanning tree.  He would like to break each ring into separate spanning trees 
(establish root bridge on each ring) but still retain communication across
rings through the Gigaswitch.  The rings are physically seperate in that
creating a loop would be less than easy to do (I know...I know...).  Is this
as simple as disabling spanning tree for the ports via mib variable or is it
more complicated.  I just started reading V3.1 release notes regarding Logical
Bridge Domains but this sounds more complicated than what he would like to do
(ie - tied to Learning Domains).  Is there any other "gotchas" in doing this
other than running the risk of not detecting a loop?  The Gigaswitch is 
currently (behind) at V2.2.

Any direction would be appreciated.

Thanks,
Jim
T.RTitleUserPersonal
Name
DateLines
942.1NPSS::MDLYONSMichael D. Lyons DTN 226-6943Fri Feb 28 1997 15:419
        It's just as simple as you describe, along with the dangers you
    describe.
    
        Multiple logical bridge domains won't help you because traffic is not
    allowed between them with this implementation.
    
        Please, please, please upgrade to BL3.1
    
    MDL
942.2ThanksSPANKY::DANIELSMon Mar 03 1997 07:422
    Thanks for the reply Mike.  Will upgrade in March, customer has
    a scheduled shutdown.  
942.3AMCFAC::RABAHYdtn 471-5160, outside 1-810-347-5160Mon Mar 03 1997 15:202
Upgrade online.  Apparently the dual SCP option supports online firmware
upgrading.  Naturally you'd upgrade one of them at a time.
942.4NPSS::MDLYONSMichael D. Lyons DTN 226-6943Mon Mar 10 1997 10:5710
        Upgrading the elected SCP will cause all the line cards to power
    cycled with the current firmware.  This is very noticeable to most
    network managers!
    
        This behaviour has recently come under discussion again, and it is
    possible that it may be changed if there is sufficient interest. 
    Please forward all comments and business justifications to the product
    manager (Bernie Zarin).
    
    MDL
942.5AMCFAC::RABAHYdtn 471-5160, outside 1-810-347-5160Mon Mar 10 1997 13:144
re .4:

I gather that upgrading the standby SCP is ok?  Once it is upgraded, a failover
can be forced?  Ah, the failover leads to line cards cycling?
942.6NPSS::MDLYONSMichael D. Lyons DTN 226-6943Mon Mar 10 1997 15:223
       ...yes, the failover leads to the line cards recycling...
    
    MDL
942.7AMCFAC::RABAHYdtn 471-5160, outside 1-810-347-5160Tue Mar 11 1997 11:4610
re .6:

Line card recycling leads to all of the standard communication disruptions
(spanning tree, prelearning, etc.), right?  So, if the applications can
configure upper layers to tolerate these and can choose a time of acceptable
impact then a weak form of online firmware upgrade is possible.  Otherwise you
may need two GIGAswitch/FDDI components.

Hmm, even with only a single SCP, this weak form of online firmware upgrade is
possible.  Is the time of impact reduced by having redundant SCP's?
942.8NPSS::MDLYONSMichael D. Lyons DTN 226-6943Tue Mar 11 1997 13:4311
        It only saves the SCP diagnostic time which takes about 45 seconds.
    
        If your customer can reconfigure the upper layer applications to
    tolerate two minute+ outages, then your customer is one of the few
    which can do so...  Most are rather upset at the idea of a 15 second
    outage.
    
        The dual homed type of configuration discussed in many other notes
    is about the least intrusive to upgrade, but that one takes a hit too.
    
    MDL