Multiple Spanning Tree Instance 0
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? Thanks, Graham Johnston Network Planner Westman Communications Group 204.717.2829 johnstong@westmancom.com<mailto:johnstong@westmancom.com> P think green; don't print this email.
On Wed, Feb 25, 2015 at 4:09 PM, Graham Johnston <johnstong@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. /chris
On 27/02/15 11:03, Chris Marget wrote:
On Wed, Feb 25, 2015 at 4:09 PM, Graham Johnston <johnstong@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
participants (3)
-
Chris Marget -
Graham Johnston -
Tom Hill