Peter, I've just come across this thread by chance, I unfortunately don't follow this forum any more (I'm now working on FabricPath;-) I just wanted to mention that PVST simulation is only started on a port that receives "PVST" BPDUs. As a result, a Cisco switch running MST will interact according to IEEE standard RSTP rules when connected to another Cisco (or non-Cisco) switch running MST and in a different region, or with another switch running RSTP. No PVST simulation there. Then, for historic purposes;-) let me clarify why we don't do proposal/agreement in PVST simulation - when we developed MST in IOS, we did not think we would market Rapid-PVST. We thought that our customers would transition directly to MST. So there was no rapid-PVST to interact with - the first version of the proposal/agreement introduced by the IEEE mandated that the agreement was a copy of the proposal BPDU received, with the agreement bit set. So indeed, implementing the proposal/agreement mechanism on a per vlan basis was roughly as expensive and complex as running rapid-PVST on the port because we would have had to maintain a context per vlan. Thanks and regards, Francois ... View more

Hi Kevin, You are right on all your points. Basically, RSTP is run between MST region, and an RSTP bridge is considered as a region by itself. So the BPDU age is incremented each time a BPDU goes from a region to another. When BPDUs are travelling inside a region, its BPDU age is frozen (tunneled if you prefer) and the hop count is used instead. The hop count does not survive a change of region (it is ignored at the boundary of a region by a switch in a different region) so indeed, you could indeed create a ring of max_age * max_hop_count. In term of convergence time, max age is not used as long as your network is adapted for RSTP/MST (i.e. all switches are connected p2p by ports running RSTP/MST and edge ports are properly identified). Regards, Francois ... View more

Hi Guiseppe, Nuno, Instance 0 always exists, even if there are no vlan mapped to it (it's the exception, we could not get rid of this one;-) I saw that the two aggregation switches are in the same region at least. However, the access switch is not part of the same region as the aggregation switches: MST0   Spanning tree enabled protocol mstp   Root ID    Priority    0              Address     0022.5628.f300              Cost        20000              Port        23 (GigabitEthernet1/0/23)              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec   Bridge ID  Priority    32768  (priority 32768 sys-id-ext 0)              Address     0022.5628.ff80              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec Interface        Role Sts Cost      Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Gi1/0/23         Root FWD 20000     128.23   P2p Bound(RSTP) Gi1/0/24         Altn BLK 20000     128.24   P2p Bound(RSTP) So all the switches see each other (the access switch has a root port and an alternate port, it sees the agg switches), but the access switch is not in the same region as the aggs. That's why MST instance 1 and 2 don't communicate with the aggregation switches, because MST instances only work within a region. I checked 20 times the region configuration and think it is identical (feel free to check an additional 20 times, because you never know:-) A "show mst configuration digest" may help compare. I don't think you are hitting a pre-standard MST/standard MST interaction issue. I recommend that you do a "clear span detected-protocol" on the access switch. If it does not help, there is I think a "debug spanning-tree mst boundary" (I'm not sure of this any more, I don't have access to a box and it's been litterally years I've not done this, shame on me!). Enable it and do the clear span detected again, that should tell you the reason why the port was put into boundary state. HTH, Francois ... View more

I guess your firewall is operating in transparent mode. Basically you a have an ingress vlan and an egress vlan. You don't have to worry about STP. Actually, if you needed to configure STP so that your traffic goes through the firewall, that would be an indication of a problem because it would mean that the traffic could skip the firewall as a result of a network reconfiguration (like a link going down). That's something that, as a security engineer, you should not like;-) That said, it does not mean that you won't have to tune the priority of some bridges in order to get an optimal STP topology. The two vlans that you are stitching with the firewall will have a common root bridge. Put this root bridge close to the L3 interfaces (basically, make the switch hosting the SVI the root bridge), that's what *generally* result in the optimal topology (I don't know enough of your network to guarantee that of course). Regards, Francois ... View more

The hardware of the stack port cannot block, and they cannot introduce a loop either. BPDUs are sent across the stack port to synchronize STP across the members of the stack, but the forwarding across the stack does not rely on STP at all. In fact, there are several normal scenarios where the state of the stack port will be blocking. In fact, you should not see them at all in your show spanning-tree output. It's there only  because you enable "debug spanning-tree event", the whole stack port should be hidden. Now, I don't know of a case where a stack port ends up "loop inconsistent". That might well be a bug indeed, as mentioned earlier. All I can say is that your fear of loops across the stack are not realistic;-) Don't worry! Regards, Francois ... View more

Hi Kevin, MST and RSTP were designed from the ground up to interact together. You can see MST as being a simple extension over RSTP. The MST BPDU is in fact and RSTP BPDU + some few additional things required to support several instance. So basically, from the perspective of an MST bridge, an RSTP peer looks like a different MST bridge in a different region. You will have no problem running RSTP and MST together, except of course that you will only be able to run a single instance (instance 0, the CIST) at the boundary between RSTP/MST (no load-balancing). The hop count MST uses is only within a region. Between regions, MST uses the message age, just like RSTP. As you have seen, Cisco does not support a real RSTP as defined in the IEEE. We only have Rapid-PVST, which is a proprietary version running one instance of RSTP per VLAN. The trick is that we don't need to support IEEE RSTP because MST is a superset of RSTP. Running MST with no region configuraiton is basically equivalent to running RSTP;-) Hope this helps, Francois ... View more

Hi, Don't worry about the vlans. For MST, what count is the vlan to instance mapping. Basically, the lines in the "mst configuration" and that is used to define the region. If the region definition match, you can use several instance, if they don't, all your vlans will follow the topology of instance 0 (thus no load balancing possible). MST does not care about whether a vlan is defined or not. MST does not run on a vlan, does not use vlan. It computes the topologies of MST instances independently of vlans. Then vlans are mapped to those topologies. HTH, Francois ... View more

Could be a timing issue too. F0/10 is designated. That means typically that the bridge on the remote end of f0/10 has a root/alternate/backup role. In those role, no bpdu is sent. So it might well be that f0/10 never received a bpdu. If you saw some bpdu received on f0/10 in "show spanning-tree detail", then it would obviously be a bug. regards, Francois ... View more

The interaction here is between cisco proprietary PVST style RSTP and IEEE standard RSTP. What's going to happen is that vlan 1 in Cisco RPVST switches is going to interact with 3com devices (running full RSTP). Then, as Giuseppe said, all the other RPVST intances are going to treat the 3com devices as a big hub and flood their BPDUs over them. That's going to lead to sub-optimal topology and convergence. However, moving the Cisco devices to MST really makes sense in that case. RSTP is designed to interact with MST's instance 0. So basically, by moving the Cisco devices to MST, you're going to run RSTP (real IEEE RSTP this time) across the whole network. The only drawback is that RSTP only runs a single instance and there will be no load balancing possible -> however convergence should be fast. So you have the choice: -1- some form of load balancing be slow convergence -2- no load balancing but full RSTP benefit. I'd definitely pick -2-. Regards, Francois ... View more

If you reboot switch B, switch A will remain the root;-) This should not introduce any change on the link between switch A and the layer3switch, so you are safe. Sure, you'll get a topology change (which will result in a short flooding phase), but this will have no impact on the applications. Regards, Francois ... View more

I guess that Layer3Switch is connecting via switchports to A and B, else A and B are in different bridged domains... Are you running Rapid-PVST or MST ? If so, you could experience a sync if B is the root. ... View more

The "ieee" protocol is supported on switchports. Even on the 5k, it was not recommended to use ieee on the RSM btw, check the "fall back bridging" section of this old document for an explanation: http://www.cisco.com/en/US/products/hw/switches/ps679/products_tech_note09186a00800a7af2.shtml#fallback I recommend you use the vlan-bridge protocol instead. It has been designed on purpose for being run on the L3 interfaces of a bridge. Regards, Francois ... View more