Hello Sherif,
As I know MST replicates IST (instance 0) BPDU to all VLANs PVST+/PVRSTP have to simulate PVST+ / PVRSTP neighbor.
Correct. Note that by replicating the IST into all defined VLANs on the PVST+ boundary port, the MST region appears to run PVST+ in which all VLANs are identically configured (i.e. have the same root bridge ID and priorities, same costs, same port priorities etc. - all derived from the IST=MSTI0).
So If MST receives PVST+/PVRSTP BPDU for VLAN 5 and VLAN 10 then MST replicates IST to VLAN 5 and VLAN 10 only (not all vlans in IST) and sent to PVST+/PVRSTP neighbor
No, I believe it is different. As soon as a Cisco switch running MSTP receives a PVST+ BPDU on one of its trunk ports, it starts the PVST Simulation on that port, and starts replicating the IST data into PVST+ BPDUs on all defined and allowed VLANs on that port. It does not matter for which VLANs the PVST+ BPDUs were received; what matters is that PVST+ BPDUs were received at all. So if your MST switch has 100 VLANs defined, it will send 100 PVST+ BPDUs on the boundary trunk port towards the PVST+ neighbor every 2 seconds by default. Each of these PVST+ BPDUs will contain the same data copied from the IST.
Also please note that it does not matter at all which VLANs are mapped onto IST. The IST may actually run without any VLAN mapped into it. Still, on PVST boundary trunk ports, its data will be replicated into PVST+ BPDUs sent for all defined and allowed VLANs on those ports, even if no VLANs are mapped onto the IST inside the MSTP region.
Now as MST replicates IST only , does this mean that PVST+ / PVRSTP VLANs should be defined in MST instance 0 or I can define them in other instance ?
No. There is no relation between VLANs in the PVST+ region and between VLANs mapped onto the IST instance. As I said earlier, the PVST Simulation makes the MSTP region to appear as a single switch that is identically configured for all VLANs it knows about, without considering their assignment into individual MST instances.
An important fact to consider here is that the role and state of a boundary trunk port (Designated, Root, Alternate, Backup; Discarding, Learning, Forwarding) that are determined by the IST are replicated onto all other MST instances in the MST region. If the IST determines that the port shall be Designated Forwarding, then all MST instances are Designated Forwarding on that port. The same is valid for all other possible port role and state combinations. Because the MST thinks in instances, not in VLANs, it would difficult or even impossible to block or unblock a boundary port for different VLANs. For example, unblocking a port for VLAN 10 while keeping it blocked for VLAN 20 would be impossible if both these VLANs were mapped onto the same MST instance. Hence, making the IST-determined state and role of a boundary port to be mandatory for all other instances was the easiest and most workable thing to do.
This fact poses a very strong requirement on the PVST+ region: as all received PVST+ BPDUs on a boundary trunk port are processed by the IST, they all must be identical because otherwise, they would contradict each other and could not be processed by a single IST instance.
That means that for the PVST Simulation to work successfully, the PVST+ region
- either must not contain a root bridge for any VLAN whatsoever (because in that case, it does not send BPDUs towards the MST region as it is the MST region which contains a root bridge for all VLANs)
- or if it contains a root bridge, it must contain it for all VLANs and this bridge must be identical for all VLANs including the total costs to reach that root
Note that on all recent Catalyst switches, a bridge ID always contains the VLAN number for which the BPDU is generated (a so-called extended system ID). Because of this, the second alternative can never be met by current Catalyst switches where the extended system ID can not be deactivated. As a result, if interconnecting an MST region with a PVST+ region, make sure that the root bridge for the IST in the MST region has the lowest priority in the entire network whatsoever to also become the root for all VLANs in the PVST+ region.
MST/PVST+ interworking is a complicated topic and is poorly documented, so do not be taken aback at first by these intricacies. Please feel welcome to ask further!
Best regards,
Peter
