MSTP configuration and interoperability with RSTP

[shankar]

We have a data center appliance that runs RSTP, and connects via a Cisco switch with upstream clients on an upstream VLAN and also connectes with downstream devices through a different downstream VLAN, through the Cisco switch. Our appliance uses two interfaces on the Cisco switch that runs MST so both the upstream and downstream Interfaces/VLANs become part of the MST instance. Our appliance needs both connected interfaces to be left in forwarding state but we find that MST blocks one of the two interfaces. Rightfully so as defined in the protocol!

Looking for suggestions on overcoming this issue because our deployments need both interfaces to be active.

Is there a way to exclude the two interfaces connected to our appliance from the MST region? It is much preferred that the external clients and the upstream interface on our appliance need to be on the same VLAN.

[Francois Tallet]

Hi Shankar,

The problem is that MST is running on the physical port, on at the vlan level. For the point of view of MST, there are two redundant links between the switch and the appliance, and it needs to block one. So as you said, this is normal protocol behavior (both MST and the IEEE version of RSTP would behave that way).

Right now, the only solutions I'm aware of are:

-1- running per-vlan rapid spanning tree on the Cisco switch (Rapid-PVST).

-2- filtering out the bpdus on the switch ports leading to the appliance (actually, using bpdufilter on at least one of the two ports would be enough). The drawback of this approach is that you have now connected the two vlans by a link that is not running STP. That means that you can only have one such appliance bridging between the two vlans, else you would introduce a permanent loop -> you lose any kind of redundancy.

Actually, I have software a solution for this problem, but it is not currently on the roadmap of any IOS release because of lack of customer support. Sounds weird, but I would recommend you contact someone responsible for your account and express your concern. I will forward internally, but it will have less weight.

Regards,

Francois

[shankar]

Thank you, Francios.

Option #1 is not feasible for our customers. Option #2 may be feasible in some of our smaller deployments. But as you point out, this has to be carefully done.

thanks and regards,

shankar