Network Architecture & Design

 View Only
Expand all | Collapse all

MSTP in a rapidly changing environment

  • 1.  MSTP in a rapidly changing environment

    Posted 09-05-2016 10:19
    I'm having a hard time integrating MSTP in my environment.
    Basically it's a rapidly changing environment where projects change on a weekly, sometimes even daily basis.
    This means that adding VLANs and creating new networks and firewall policies is a very frequent task.

    The topology consists of a pair of core switches (MLAG peers) and lots of edge switches (20+). All of those belong to the same MSTP region.

    What happens is that often I have to add another VLAN/network for a particular area (covered by a particular edge switch) and since I want to have it protected by STP i end up with a very time consuming task.
    Problem is, when I create another VLAN I have to make MSTP digest consistent throughout my whole topology.
    That means I have to go through all of core and ALL of my edge switches (20-30 of them) and create the VLAN, auto-bind it to a MSTI and finally even add it to the uplink.
    Basically it's such an overhead I'm almost thinking of binding only permanenly existing VLANs (e.g. infrastructure, sales...) and leave the project VLANs outside of STP completely.

    Creating a script to automate the config at least on the edge switches seems very dangerous...

    I hate to say this but something like this is a breeze on cisco.
    There you can manage and propagate VLANs with VTP (yes i know of the shortcomings...); MSTP can be configured in advance identically everywhere since VLANs don't have to _exist_ in order to be defined in MSTI config.

    I desperately need some advice or suggestion how to reduce the overhead this imposes...

    To sum it up,
    Problem 1 - is there really no way to make MSTP config consistent everywhere before VLANs are even created on the switch? E.g. configure mstp to bind vlans 1-999 to MSTI before all of those VLANs even exist - just so that the digest matches everywhere.

    Problem 2 - is there really no way to simplify VLAN propagation? MVRP comes really close but it's meant only for AVB. Since it's impossible to manually adding ports to dynamically created VLAN it's useless in this scenario.

    If those problems aren't solved, how do you guys cope?

    Thanks in advance,

    Regards,
    Vladimir



  • 2.  RE: MSTP in a rapidly changing environment

    Posted 09-05-2016 10:38
    What is preventing you from using elrp? The configuration is much simpler and it works great.


  • 3.  RE: MSTP in a rapidly changing environment

    Posted 09-05-2016 10:44
    Core and some of the edge switches are extreme, but edge varies so i'd keep it vendor free.


  • 4.  RE: MSTP in a rapidly changing environment

    Posted 09-05-2016 10:54
    That makes sense. Unfortunately stp is not my bag, best of luck.


  • 5.  RE: MSTP in a rapidly changing environment

    Posted 09-05-2016 10:55


  • 6.  RE: MSTP in a rapidly changing environment

    Posted 09-05-2016 12:16
    I've just gone from 15.5 to 16.1.
    Also most of my extremes are G1, so they won't be going 21.x very soon...


  • 7.  RE: MSTP in a rapidly changing environment

    Posted 09-06-2016 10:42
    How about adding a tagged vlan to all your end system ports, such as STP_VLAN? You can setup that one vlan to do spanning tree and then you can leave it alone, and add and delete other vlans off of the port, without affecting your STP config.


  • 8.  RE: MSTP in a rapidly changing environment

    Posted 09-06-2016 10:44
    I like that idea,

    That's like the ELRP spanning tree config.


  • 9.  RE: MSTP in a rapidly changing environment

    Posted 09-07-2016 13:49
    On which side you mean? The core or on the edge switches?

    In any case, I assume you mean to abandon MSTP and just use plain STP with only one VLAN participating?
    I guess that defeats the whole concept then.


  • 10.  RE: MSTP in a rapidly changing environment

    Posted 09-07-2016 14:15
    On the edge.

    Do you currently use MSTP to load balance vlans across redundant links, or need different root?


  • 11.  RE: MSTP in a rapidly changing environment

    Posted 09-07-2016 16:56
    There's a few hundred vlans we manage (small number of access ports per vlan tho) so MSTP makes most sense in terms of reduced cpu footprint.
    Also, different root is desirable (currently not needed) for cases when integrating dedicated project equipment into existing infrastructure.



  • 12.  RE: MSTP in a rapidly changing environment

    Posted 09-07-2016 18:51
    One note: Using one STP vlan will not work with EXOS's implementation of STP. EXOS always blocks on a VPIF (VLAN/port interface), even with 802.1d and 802.1w STP modes. Because of this, any vlans not added to the spanning tree domain will not be blocked, even if the port is not in the forwarding state.


  • 13.  RE: MSTP in a rapidly changing environment

    Posted 09-07-2016 19:37
    Even with Edge-safeguard enabled? Below is a sample config of what I've used.

    create vlan "STPVlan"configure vlan STPVlan tag 1111
    configure vlan STPVlan add ports all tagged

    configure mstp region STPVlan
    configure stpd s0 delete vlan default ports all
    disable stpd s0 auto-bind vlan default
    configure stpd s0 mode mstp cist
    create stpd STPVlan_stm
    configure stpd STPVlan_stm mode mstp msti 1

    configure stpd STPVlan_stm add vlan STPVlan ports all dot1d

    configure stpd s0 ports mode dot1d 1:1-52,2:1-24
    configure stpd s0 ports cost auto 1:1-52,2:1-24
    configure stpd s0 ports link-type edge 1:1-48,2:1-24
    configure stpd s0 ports edge-safeguard enable 1:1-48,2:1-24 recovery-timeout 60
    configure stpd s0 ports bpdu-restrict enable 1:1-48,2:1-24 recovery-timeout 60

    enable stpd s0 ports all

    configure stpd STPVlan_stm ports mode dot1d 1:1-52,2:1-24
    configure stpd STPVlan_stm ports cost auto 1:1-52,2:1-24

    configure stpd STPVlan_stm ports edge-safeguard enable 1:1-48,2:1-24 recovery-timeout 60
    configure stpd STPVlan_stm ports bpdu-restrict enable 1:1-48,2:1-24 recovery-timeout 60

    enable stpd STPVlan_stm ports all
    enable stpd s0
    enable stpd STPVlan_stm


  • 14.  RE: MSTP in a rapidly changing environment

    Posted 09-07-2016 19:43
    Hypothetically, let's say I were to have all extreme hw and decide on MLAG and ELRP.
    I'm going off topic here, so If needed i'll open another discussion.

    Since access port VLAN membership changes frequently, I guess ELRP has to be configured for all VLANs. Having a dummy vlan for ELRP doesn't seem like a solution since ELRP frames have to be untagged when leaving the access port? Tagged ELRP frames would be dropped by customer equipment and loops wouldn't be detected.

    First, what about CPU footprint on ELRP for few hundred VLANs?

    Second, is it planned to implement the vlan range configuration for elrp?
    Even with 16.1.3 sw it's not possible to simply run "configure elrp-client periodic vlan <1-4095> .... ".
    I was really overjoyed when I upgraded to 16.1+ and discovered this "enhancement".

    On a side note..Interesting how nobody asked when I mentioned MLAG and STP in the same sentence...
    I just read in the documentation that STP and MLAG ports don't go together.
    Basically i'd be stuck with multiple (M)STP isolated segments (on each edge sw).



  • 15.  RE: MSTP in a rapidly changing environment

    Posted 09-08-2016 01:47
    Do you need MSTP to the edge, or could you just have it at the core and then have STP at the edge?


  • 16.  RE: MSTP in a rapidly changing environment

    Posted 09-09-2016 12:15
    If we create a version of ezspantree that works with 16.1, would that solve the problem? It would function the same way as https://github.com/extremenetworks/EXOS_Apps/tree/master/EZ_SpanningTree