08-20-2011 08:27 AM - edited 03-07-2019 01:47 AM
As I know that in case of trunk, Cisco sends BPDU for each VLAN allowed in the trunk using Cisco reserved multicast address 01:00:0C:CC:CC:CD. This is true for PVST+ or Per-VLAN RSTP
For compatibility with other vendors, when using trunk Cisco also sends BPDU using standard IEEE multicast address on VLAN 1
When using access ports, Cisco sends BPDU for that VLAN only
Thanks to correct me If above is not correct.
Now my question is, do Cisco uses its reserved multicast address when sending BPDUs on access ports or send it using IEEE standard multicast
address ?
I believe It is sent using Cisco reserved multicast address unless It is VLAN 1 , correct ?
Appreciate If you can post a document If possible
Thanks in advance for your assistance
08-20-2011 11:49 AM
Hi Sherif,
A quite exhaustive overview of how the PVST+/RPVST+ BPDUs are encapsulated and addressed on 802.1Q trunks can be found in this document:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00801d11a0.shtml#topic1
In short, a trunk always sends a combination of standard and (R)PVST BPDUs:
Now my question is, do Cisco uses its reserved multicast address when sending BPDUs on access ports or send it using IEEE standard multicast address?
When sending BDPUs on access ports, they are always sent to the IEEE standard STP MAC address. There is no need - and no reason - to send BPDUs on access ports to any special address because by definition, an access port belongs to a single VLAN only, and therefore, no special VLAN-aware STP is necessary to be run on such a port.
I believe It is sent using Cisco reserved multicast address unless It is VLAN 1 , correct ?
No, not correct. The BPDUs are always sent to the standard IEEE address, and the contents of these BPDUs is derived from the STP instance for the access VLAN of the port (e.g. an access port in VLAN 10 sends standard IEEE BPDUs with data derived from STP instance running in VLAN 10).
Best regards,
Peter
08-20-2011 01:17 PM
Hi Peter,
Many thanks for your time to explain in such details .. much appreciated
Another question plz
In case we have MST at one side and PVST+ or PVRSTP at the other side
As I know MST replicates IST (instance 0) BPDU to all VLANs PVST+/PVRSTP have to simulate PVST+ / PVRSTP neighbor.
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
Correct ?
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 ?
Thanks for your assistance
08-20-2011 02:38 PM
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
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
08-24-2011 03:57 PM
Dear Peter
Many many thanks for your support . Much appreciated
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 ?
So VLANs mapping to instance 0 or any other instance wont make a difference as MST replicates IST to all VLANs allowed on the boundary trunk , i.e not VLANs defined at IST 0 only , correct ?
Another 2 question plz
1- PVRSTP will have same behavior of PVST+ as both using per-vlan STP , correct ?
2- If the router that is running MST is not a cisco router , what will happen ?
I believe If the port of cisco router running PVST+ that is connected to MST non cisco router not is a trunk with native VLAN 1 or an access port, then MST router wont understand STP BPDU and will broadcast it normally as If it is a normal broadcast packet , correct ?
Thanks for your assistance
08-25-2011 04:47 AM
Hello Sherif,
So VLANs mapping to instance 0 or any other instance wont make a difference as MST replicates IST to all VLANs allowed on the boundary trunk , i.e not VLANs defined at IST 0 only , correct ?
Yes, perfectly correct.
Another 2 question plz
1- PVRSTP will have same behavior of PVST+ as both using per-vlan STP , correct ?
Correct. However, to my experience, there is some gotcha in the way how Cisco MST reverts to PVRST+. Under some circumstances, I have not yet been able to precisely define them, the boundary port reverts to PVST+, not to PVRST+ even if the neighboring switch runs PVRST+. I need more time to perform a series of experiments to understand it better.
2- If the router that is running MST is not a cisco router , what will happen ?
A pure IEEE MST implementation can fall back to 802.1D legacy STP or to 802.1w RSTP on a boundary port. It will emit a normal STP or RSTP BPDU with the data derived from IST. These BPDUs would not be tagged. The role/state of the boundary port as determined by IST and its interaction with the non-MST world will then determine the state for all instances on that boundary port. Remember, an MST region looks just like a single STP/RSTP switch to non-MSTP switches, and appears to run a single STP instance - the IST.
If a pure IEEE MST switch is connected to a Cisco PVRST+ or PVST+ switch, the STP running in the native VLAN (which always speaks the IEEE STP/RSTP in parallel to PVST+/PVRST+) on the Cisco switch will merge with the IST running in the MST region. PVST+/PVRST+ BPDUs are addressed and encapsulated differently, and they will simply be multicasted across the entire MST region. If the MST region has more boundary ports in the Forwarding state, the PVST+/PVRST+ BDPUs will simply flow across the MST region as if it was a hub.
Complex enough? I had my fair share of troubles understanding these peculiar details, and I still feel somewhat unsteady in those. But please do continue asking! You are helping myself to understand it better.
Best regards,
Peter
08-25-2011 05:30 AM
Many thanks Peter
I beleive I have no further questions from the time being regarding this topic
For second question
I believe (or at least that what my lab showed) it will always be PVST+ unless below 2 cases occurs. In this case It will be read as "P2p Bound(RSTP)"
- MSTP region 1 <> MSTP region 2
- MSTP @ access port <> PVRSTP @ access port
4948-1#sh spanning-tree vlan 260
MST0
Spanning tree enabled protocol mstp
Root ID Priority 0
Address 001d.70d6.9b80
Cost 20000
Port 3 (GigabitEthernet1/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 61440 (priority 61440 sys-id-ext 0)
Address 001f.ca43.b200
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/3 Root FWD 20000 128.3 P2p Bound(RSTP) <<----
4948-1#
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide