MSTP Multi-Process
Background
The following describes the network shown in Figure 10-11:
UPEs are deployed at the aggregation layer and are 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 and are running STP or RSTP. In addition, UPE1 and UPE2 work for different carriers, so they need to reside on different spanning trees whose topology changes do not affect each other.
On the network shown in Figure 10-11, switching devices and UPEs construct multiple Layer 2 rings. STP must be enabled on these rings to prevent loops. UPE1 and UPE2 are connected to multiple access rings that are independent of each other. The spanning tree protocol cannot calculate a single spanning tree for all switching devices. Instead, the spanning tree protocol must be enabled on each ring to calculate a separate spanning tree.
MSTP supports MSTIs, but these MSTIs must belong to one MST region in which devices must have the same configurations. If the devices belong to different regions, MSTP calculates the spanning tree based on only one instance. Assume that devices on the network belong to different regions, and only one spanning tree is calculated in one instance. In this case, the status change of any device on the network affects the stability of the entire network. On the network shown in Figure 10-11, the switching devices connected to UPEs support only STP or RSTP but not MSTP. When MSTP-enabled UPEs receive RST BPDUs from the switching devices, the UPEs consider that they and switching devices belong to different regions. As a result, only one spanning tree is calculated for the rings composed of UPEs and switching devices, and the rings affect each other.
To prevent this problem, MSTP multi-process is introduced. MSTP multi-process is an enhancement to MSTP, allowing ports on switching devices to be bound to different processes. MSTP calculation is performed based on processes. In this manner, only ports that are bound to a process participate in the 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 10-11 can be divided into multiple MSTP processes by using MSTP multi-process. Each process controls a ring composed of switching devices. The MSTP processes have the same functions and support MSTIs. The MSTP calculation for one process does not affect the MSTP calculation for another process.
In addition to applying to MSTP, MSTP multi-process also applies to RSTP and STP.
Purpose
Allows STP to work under far more networking conditions.
To help a network running different spanning tree protocols run properly, you can bind different spanning tree protocols to different processes. In this manner, every process calculates a separate spanning tree.
Improves the networking reliability. For a network composed of many Layer 2 access devices, using MSTP multi-process reduces the adverse effect of a single node failure on the entire network.
The topology is calculated for each process. If a device fails, only the topology corresponding to the process to which the device belongs changes.
Reduces the network administrator workload during network expansion, facilitating operations and maintenance (O&M).
To expand a network, all you need to do is 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 parts of ports on a device. Layer 2 ports on a device are separately managed by multiple MSTP processes.
Implementation
Public link status
On the network shown in Figure 10-11, the public link between UPE1 and UPE2 is a Layer 2 link running MSTP and is different from the links connecting switching devices to UPEs. This difference lies in the fact that ports on the links connecting switching devices to UPEs only participate in the calculation for a single access ring and a single MSTP process. The ports on the public link, on the other hand, 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.
A port on the public link participates in the calculation for multiple MSTP processes, and obtains different states. As a result, the port cannot determine its state.
To prevent these problems from occurring, it is defined that a port on a public link always adopts its state in MSTP process 0 when participating in the calculation for multiple MSTP processes.
After a device starts, MSTP process 0 exists by default, and MSTP configurations in the system view and interface view belong to this process.
The device is incompatible with non-standard STP, RSTP, and MSTP, for example, PVST+. It transparently forwards PVST+ packets in a VLAN as common data packets.
Reliability
On the network shown in Figure 10-12, after the topology of a ring changes, the MSTP multi-process mechanism helps UPEs flood a topology change (TC) packet to all devices on the ring and prevent the TC packet from being flooded to devices on the other ring. UPE1 and UPE2 update MAC address and ARP entries on the ports corresponding to the changed spanning tree.
On the network shown in Figure 10-13, if the public link between UPE1 and UPE2 fails, multiple switching devices that are connected to the UPEs will unblock their blocked ports.
Assume that UPE1 is configured with the highest priority, UPE2 with the second highest priority, and switching devices with default or lower priorities. After the link between UPE1 and UPE2 fails, the blocked ports on switching devices no longer receive packets of higher priorities. For this reason, these ports re-perform state machine calculation. If the calculation changes the blocked ports to designated ports, a permanent loop occurs, as shown in Figure 10-14.
Solutions
To prevent a loop between access rings, use either of the following solutions:
Configure an inter-card Eth-Trunk between UPE1 and UPE2.
An inter-card Eth-Trunk is used as the public link between UPE1 and UPE2 to improve link reliability, as shown in Figure 10-15.
Configure root protection between UPE1 and UPE2.
If all physical links between UPE1 and UPE2 fail, configuring an inter-card Eth-Trunk cannot prevent the loop. In this case, root protection can be configured to prevent the loop shown in Figure 10-14.
On the light blue ring shown in Figure 10-16, UPE1 is configured with the highest priority, UPE2 with the second highest priority, and switching devices with default or lower priorities. In addition, root protection is enabled on UPE2.
Assume that a port on S1 is blocked. When the public link between UPE1 and UPE2 fails, the blocked port on S1 begins to calculate the state machine because it no longer receives BPDUs of higher priorities. After the calculation, the blocked port becomes the designated port and performs P/A negotiation with the downstream device.
After S1, which is directly connected to UPE2, sends BPDUs of higher priorities to the UPE2 port enabled with root protection, the port is blocked. From then on, the port remains blocked because it continues receiving BPDUs of higher priorities. In this manner, no loop will occur.
