Multiple Spanning Tree Instance 0

Tom Hill tom at ninjabadger.net
Wed Mar 4 23:34:58 UTC 2015


On 27/02/15 11:03, Chris Marget wrote:
> On Wed, Feb 25, 2015 at 4:09 PM, Graham Johnston <johnstong at westmancom.com>
> wrote:
> 
>> > We are planning a migration from Rapid PVST+ to Multiple Spanning Tree to
>> > better support a mixed vendor environment.  My question today is about MST
>> > Instance 0.  In practice do you map any VLANs there other than VLAN 1?
> 
> I'd hoped to see some responses to this thread because I recently had some
> awkward moments with a vendor after discovering that their switch wouldn't
> allow me to map VLANs to STP instances in an arbitrary manner. I took the
> position that the implementation was faulty, their position was more along
> the lines of "Well, why would you want to do that anyway?"
> 
> Addressing the question directly, I know of two switching platforms which
> force the operator to map VLANs other than 1 into instance 0.
> 
> Some Broadcom FASTPATH based platforms fail to mention VLAN 4094 in any
> 'show spanning-tree' commands, but always maps it to instance 0.
> 
> The implementation of MST available on Cumulus Linux only supports instance
> 0, maps all VLANs there. My Cumulus experience is a bit dated, this may
> have changed in the last year.

Every vendor of switches has, for a multitude of reasons that I don't
want to have to list, implemented VLAN mapping to instances in MSTP
differently.

Furthermore, if you do manage to have all of your vendors converge (I've
done so with 5 different implementations) when it comes to CHANGING
those mappings after things go live, you'll wish you never bothered. As
soon as the configuration hash differs, you'll fallback to the CIST anyway.

The only sane way to do STP today, is to run MSTP and leave everything
in instance 0 (configure nothing if you can get away with it). Using
only the CIST allows you to interact with RSTP very well. Smarter
protocols exist for making better use of your bandwidth. (i.e. ECMP,
LACP, etc.)

As for migrating away from PVST+: break the loops and config the devices
over to MSTP one by one. You should make sure that the connected switch
-- singular -- isn't going to down the interface at the sight of MSTP
BPDUs, and expect a short period of listening & learning, but it should
in theory make for only small amounts of frame loss as it converges. I'd
start with your root bridge and work your way outward.

HTH

-- 
Tom


More information about the NANOG mailing list