MSTP Multi-Process
Background
MSTP multi-process is an enhancement to MSTP and allows ports on switching devices to be bound to different processes. A process controls a ring composed of switches, which means that only the ports bound to a process can participate in MSTP calculation for this process.
With MSTP multi-process, spanning trees of different processes are calculated independently and do not affect each other.
The network shown in Figure 1 can be divided into multiple MSTP processes by using MSTP multi-process. In Figure 1:
User-facing Provider Edges (UPEs) are deployed at the aggregation layer, running MSTP.
UPE1 and UPE2 are connected by a Layer 2 link.
Multiple rings are connected to UPE1 and UPE2 through different ports.
Switching devices on the rings reside at the access layer, running STP or RSTP. Because UPE1 and UPE2 work for different carriers, they reside on different spanning trees so that their topology changes do not affect each other.
MSTP multi-process is applicable to MSTP, RSTP, and STP.
Purpose
Greatly improves the applicability of STP to different networking conditions.
On a network running different spanning tree protocols, devices that run different spanning tree protocols can be bound to different processes, allowing every process to calculate a separate, independent spanning tree.
Improves networking reliability.
Network topology is calculated for each process so that, if a device fails, only the topology corresponding to the process that the device belongs to is affected. On a network with many Layer 2 access devices, MSTP multi-process reduces the adverse effect of a single node failure on the entire network.
Reduces the network administrator workload during network expansion.
To expand a network, a network administrator must configure new processes, connect the processes to the existing network, and keep the existing MSTP processes unchanged. If device expansion is performed in a process, only this process needs to be modified.
Implements separate Layer 2 port management
An MSTP process manages separate port functions on a device. Layer 2 ports on a device are separately managed by multiple MSTP processes.
Additional Concepts
Public link status
In Figure 1, the public link between UPE1 and UPE2 is a Layer 2 link running MSTP. This public link is different from the links that connect switching devices to UPEs. The ports on the public link need to participate in the calculation for multiple access rings and MSTP processes. Therefore, the UPEs must identify the process from which MST BPDUs are sent.
In addition, a port on the public link participates in the calculation for multiple MSTP processes, and obtains different status. As a result, the port cannot determine its status.
To prevent this situation, the port always adopts its status in MSTP process 0 when participating in the calculation for multiple MSTP processes.
By default, MSTP process 0 is created when a device starts, and MSTP configurations in the system view and interface view belong to this process.
Reliability
On the network shown in Figure 2, after the topology of a ring changes, the MSTP multi-process mechanism helps UPEs flood a TC BPDU to all devices on the ring and prevent the TC BPDU from being flooded to devices on the other ring. UPE1 and UPE2 update MAC and ARP entries on the ports corresponding to the changed spanning tree.
On the network shown in Figure 3, if the public link between UPE1 and UPE2 fails, multiple switching devices that are connected to the UPEs will unblock their blocked ports.
UPE1 is configured with the highest priority, UPE2 with the second highest priority, and all other switches with default or lower priorities. After the link between UPE1 and UPE2 fails, the blocked ports (replacing the root ports) on switching devices no longer receive packets with higher priorities, triggering state machine calculation. If the calculation changes the blocked ports to designated ports, a permanent loop forms, as shown in Figure 4.
Loop prevention solutions
To prevent a loop from occurring between access rings, use either of the following solutions:
Configure an inter-board Eth-Trunk link between UPE1 and UPE2.
An inter-board Eth-Trunk link can be used as the public link between UPE1 and UPE2 to improve link reliability, as shown in Figure 5.
Configure root protection between UPE1 and UPE2.
If all physical links between UPE1 and UPE2 fail, configuring an inter-board Eth-Trunk link cannot prevent the loop. Root protection can be configured to prevent the loop, as shown in Figure 4.
The blue ring in Figure 6 is used as an example. UPE1 is configured with the highest priority, UPE2 with the second highest priority, and switching devices on the blue ring with default or lower priorities. Root protection is enabled on UPE2.
If a port on S1 is blocked, when the public link between UPE1 and UPE2 fails, the blocked port on S1 starts to perform state machine calculation. After calculation, the blocked port becomes the designated port and performs P/A negotiation with the downstream device.
After S1 sends BPDUs of higher priorities to the UPE2 port enabled with root protection, the port is blocked. The port remains blocked because it continues to receive BPDUs of higher priorities, which prevents loops from occurring.
