MST 802.1s question

[urbinir]

Hi

I have two 6509s at Core with MST 802.1s configured with two internal istances (IST1 and IST2)

IST0 have no vlan mapping neither vlan 1.

One 6509 is root bridge for IST0 and IST1 and the other one is root bridge for IST2

If I connect the 6509 to a non-cisco switch with RSTP 802.1w at the boundary port what happened if the VLAN 1 on Cisco switch is not mapped on IST0?

Could I connect the non-cisco switch with two uplinks to the Cisco 6509?Is better using a trunk or access port?

Thanks

Riccardo

[Peter Paluch · Accepted solution]

Hi Riccardo,

If I connect the 6509 to a non-cisco switch with RSTP 802.1w at the 
boundary port what happened if the VLAN 1 on Cisco switch is not mapped 
on IST0?

Nothing bad will happen. The 6509 will speak 802.1w RSTP (if the boundary port is an access port) or 802.1D STP (if the boundary port is a trunk port) to the non-Cisco switch. As the non-Cisco switch probably does not perform per-VLAN STP, the notion of VLAN1 mapped to whatever instance has no meaning here. The boundary port will be discarding or forwarding for all instances (and thus for all VLANs) depending on normal STP rules. BPDUs sent out the boundary port will have their contents derived from the instance 0.

Could I connect the non-cisco switch with two uplinks to the Cisco 6509?Is better using a trunk or access port?

Yes, you can, and I would suggest configuring an EtherChannel in that case. Whether using a trunk or access port - there is no general answer to that, and it depends exclusively on your needs. If the non-Cisco switch has several VLANs defined then you need to use a trunk port. If only a single VLAN is used on the switch then an access port will suffice. Note that Cisco's MSTP implementation rather sadly reverts to slow 802.1D STP on trunk ports which may be a problem to fast convergence.

It would be of course the best solution if the non-Cisco switch was configured for MSTP as well. Mixing various STP versions in a single network is generally not recommended.

Best regards,

Peter

[urbinir]

Hi Peter

thanks very much for your answer

Unfortunately the non-cisco switch don't support MST but only RSTP802.1w and you are right they don't understand PVST+.

The customer might change them but , maybe , next year.

I have a question

At boundary port why the trunk doesn't permit the rapid transition while the access do?

I thought that MST could convert in RSTP if the boundary port hear a BPDU RSTP or in STP if the boundary port hear a STP802.1d BPDU in any condition (trunk or access)

Thanks Riccardo

[Peter Paluch · Accepted solution]

Hi Riccardo,

I thought that MST could convert in RSTP if the boundary port hear a 
BPDU RSTP or in STP if the boundary port hear a STP802.1d BPDU in any 
condition (trunk or access)

Yes - according to IEEE standard, MSTP should revert to RSTP operation on a region boundary.

The things are complicated in Cisco implementation because Cisco switches try to convert the MSTP on the region boundary to PVST+ BPDUs for all currently created VLANs. I guess that Cisco engineers were probably concerned that maintaining up to 4094 Proposal/Agreement states on a single trunk would not be worth the added complexity of the IOS code and system requirements (then again, this is exactly what RPVST+ does so this is really trying to make savings where none can be achieved!), and so they probably decided to revert to legacy 802.1D on MSTP boundary ports.

So in short, the PVST Simulation on the MSTP region boundary is actually what makes the troubles here. I have been a vocal critic of this approach multiple times on these forums. For example, it is perhaps not so commonly deployed but it is perfectly correct and even advantageous in certain scenarios to have a switched network divided into multiple regions. A pure IEEE MSTP implementation would allow for rapid reconvergence in cases of topology changes. Unfortunately, with Cisco's MSTP implementation, inter-region links revert to 802.1D mode of operation with their 30-50s unblocking time and nothing can be done about it. Probably too few customers are nagging about this...

Best regards,

Peter

[urbinir]

Hi Peter

thanks again for your answer

So if I understand, on the boundary port if the port is in access there is only a VLAN (vlan native) so the switch with MSTP must send the correct BPDU in according at neighbor STP (RSTP BPDU) and PVST Simultion doesn't run

If the boundary port is a trunk dot1q (more than a VLAN) the switch wth MSTP start to run the PVST Simulation and try to bound a PVST+  neighbor but at the end run STP 802.1d because the neighbor switch doesn't understand PVST+

The PVST Simulation depend on IOS or is the default behaviour of all switch Cisco and you cannot disable it?

Thanks Riccardo

[Peter Paluch · Accepted solution]

Hi Riccardo,

So if I understand, on the boundary port if the port is in access there 
is only a VLAN (vlan native) so the switch with MSTP must send the 
correct BPDU in according at neighbor STP (RSTP BPDU) and PVST Simultion
 doesn't run

Yes. On an access port, the PVST Simulation is not running because there is only a single VLAN present.

If the boundary port is a trunk dot1q (more than a VLAN) the switch wth 
MSTP start to run the PVST Simulation and try to bound a PVST+  neighbor
 but at the end run STP 802.1d because the neighbor switch doesn't 
understand PVST+

Basically, correct, but even if the neighboring switch did support Rapid PVST+ or RSTP, the Cisco switch running MSTP would revert to 802.1D PVST+ and 802.1D STP (non-rapid). Note that on Cisco switches, it is not possible to activate only the pure 802.1D STP or 802.1w RSTP. On trunks, Cisco switches will always run the proprietary PVST along with the standard STP/RSTP.

The PVST Simulation depend on IOS or is the default behaviour of all switch Cisco and you cannot disable it?

The PVST Simulation is a built-in IOS feature. As far as I know, it cannot be disabled on low-end switches. I have seen an option of deactivating the PVST Simulation for 4500 and 6500 series switches if I am not mistaken, but the feature seems to be quite new and it did not make it into the IOS versions for 2960/3560/3750 yet. Whether there are any plans by Cisco to implement it on these switches I cannot say.

Best regards,

Peter

[urbinir]

Hi Peter

thanks very much. Your answers have been described very well

Riccardo

[Peter Paluch]

Riccardo,

You are welcome. Thank you very much for your generous ratings!

Best regards,

Peter

[urbinir]

Hi Paul

no problem..I take advantage of your patience and I ask you only the last question (I hope) because this topic interest me a lot.

If cisco and non-cisco switch run MSTP both and the port between them is a trunk dot1q , does the Cisco run PVST Emulation anyway and (maybe) when heard MSTP BPDU stopped it or , in this case, never run PVST Emulation and sending out  version 3 BPDUs only ?

Thanks a lot for your help

Riccardo

[Peter Paluch]

Hi Riccardo,

You are welcome to ask as many questions as you wish

If cisco and non-cisco switch run MSTP both and the port between them
is a trunk dot1q , does the Cisco run PVST Emulation anyway and (maybe)
when heard MSTP BPDU stopped it or , in this case, never run PVST
Emulation and sending out  version 3 BPDUs only ?

It depends on whether the two switches are in the same MSTP region. If they are then both Cisco and non-Cisco switch will speak only MSTP to each other. Specifically, the Cisco switch will not run PVST Simulation because it does not need to. Not that in this case, the port on the Cisco switch is not a boundary port. The PVST Simulation is run on a boundary port only.

However, if the two switches are each in a different MSTP region, the Cisco switch will recognize that and it will revert to PVST+ on the trunk link along with the PVST Simulation. This is where it departs from the IEEE standard: the IEEE-compliant switch would revert to using RSTP to talk to the outside world, using the IST (=MSTI 0) data as the contents of outgoing BPDUs. The entire region would then appear as a single switch to the outside world, and if the boundary port got blocked, it would be blocked for all instances, thus for all VLANs - that is the original IEEE idea of using a common spanning tree outside a region. Cisco tried to be backward-compatible with its PVST+ switches and the result is less than satisfactory, sadly.

A port on Cisco switch starts in the predefined mode, i.e. if the switch is configured to run MSTP, the port starts sending MSTP BPDUs when it comes up. However, if it hears different BPDUs from its neighbor, it will fall back to a previous STP version.

Best regards,

Peter

[urbinir]

Hi Peter,

It depends on whether the two switches are in the same MSTP region. If they are then both Cisco and non-Cisco switch will speak only MSTP to each other. Specifically, the Cisco switch will not run PVST Simulation because it does not need to. Not that in this case, the port on the Cisco switch is not a boundary port. The PVST Simulation is run on a boundary port only.

OK

However, if the two switches are each in a different MSTP region, the Cisco switch will recognize that and it will revert to PVST+ on the trunk link along with the PVST Simulation. This is where it departs from the IEEE standard: the IEEE-compliant switch would revert to using RSTP to talk to the outside world, using the IST (=MSTI 0) data as the contents of outgoing BPDUs. The entire region would then appear as a single switch to the outside world, and if the boundary port got blocked, it would be blocked for all instances, thus for all VLANs - that is the original IEEE idea of using a common spanning tree outside a region.

Cisco tried to be backward-compatible with its PVST+ switches and the result is less than satisfactory, sadly.

..mmm..It mean that if the switches are in different region even if they are both using MSTP, the Cisco will run STP 802.1d on the boundary port or run  RSTP?

Can this behaviour be different from the root bridge position?

I.e. Cisco is the root brige for IST0 and try to PVST Simulation but if the root bridge of IST0 is the non-cisco switch on the boundary port Cisco doesn't try the PVST Simulation

Best regards,

Riccardo

[Peter Paluch]

Hi Riccardo,

..mmm..It mean that if the switches are in different region even if
they are both using MSTP, the Cisco will run STP 802.1d on the boundary
port or run  RSTP?

It will run old slow 802.1D STP and PVST+. It will not run RSTP although the IEEE standard allows for it. As far as I know, nothing can be done to change it - this behavior is hard-coded in IOS.

Can this behaviour be different from the root bridge position?
I.e.
Cisco is the root brige for IST0 and try to PVST Simulation but if the
root bridge of IST0 is the non-cisco switch on the boundary port Cisco
doesn't try the PVST Simulation

I don't know - but I would not rely on such a volatile setup. The PVST Simulation has several additional requirements to run successfully, requiring that either the MSTP region is the root for all VLANs, or that the root for all VLANs is outside the MSTP region and is a single switch. Making some VLANs to have root in the MSTP region and some others outside it usually causes the PVST Simulation to fail (because it cannot replicate multiple differing outside PVST+ BPDUs correctly onto the IST) and the boundary port will be blocked. In short... the PVST Simulation is a major pain in the... you know where

Best regards,

Peter