This post continues what was published in SEP, Specifying an Interface to Block
Table 1 lists the situations in which the topology of a SEP segment changes.
SEP Topology Change | Description |
Topology change caused by an interface fault | Figure 1 shows an interface fault in a SEP segment. An interface fault can be a link fault or a neighboring interface fault. If a device that has an interface in the forwarding state in the SEP segment receives a fault advertisement packet, the device needs to send a Flush-Forwarding Database (Flush-FDB) packet through the interface to notify other nodes in the SEP segment that the topology has changed. |
Topology change caused by a fault being rectified and the preemption function taking effect | One or more faults occur in the SEP segment. When the last faulty interface recovers and the blocked interface is preempted, the topology is considered changed. Preemption is triggered by the primary edge interface. When an interface in a SEP segment receives a preemption packet from the primary edge interface, the interface needs to send Flush-FDB packets to notify other nodes in the SEP segment that the topology has changed. |
Figure 1 Networking diagram for SEP topology change notification
The topology change notification function is configured on devices that connect an upper-layer network and a lower-layer network. If the topology of either of the networks changes, these devices inform the other network of the change.
Table 2 lists the scenarios in which topology changes are reported.
SEP Topology Change Notification | Scenario | Description | Solution |
Topology change notification from a lower-layer network to an upper-layer network | Networking where a SEP network is connected to an upper-layer network running other features such as SEP, STP, RRPP |
| Configure the SEP topology change notification function. |
Networking scenario where a host is connected to a SEP network by using a SmartLink group | During an active/standby switchover of member interfaces in the SmartLink group, the host sends a SmartLink Flush packet to notify the connected devices in the SEP segment of the switchover. If the connected devices in the SEP segment cannot identify the SmartLink Flush packet (that is, if these connected devices in the SEP segment cannot detect any topology change of the lower-layer network), traffic will be interrupted. | Enable the edge devices in the SEP segment to process SmartLink Flush packets. | |
Topology change notification from an upper-layer network to a lower-layer network | Networking scenario where a SEP network is connected to an upper-layer network configured with CFM. | If a fault occurs on the upper-layer network, the topology of that network changes but the lower-layer network cannot detect the change. As a result, traffic is interrupted. | Configure association between SEP and CFM As shown in Figure 2 , association between SEP and CFM is configured on LSW1. |
Figure 2 Networking diagram of association between SEP and CFM
As shown in Figure 2, association between SEP and CFM is configured on LSW1 in the SEP segment. When CFM detects a fault on the network at the convergence layer, LSW1 uses a CCM to notify the Operation, Administration, and Maintenance (OAM) module of the fault. Then, the SEP status of the interface associated with CFM goes Down.
The interface associated with CFM is in the SEP segment. If this interface goes Down, LSW2 needs to send a Flush-FDB packet to notify the other nodes in the SEP segment that the topology has changed. After LSW3 receives the Flush-FDB packet, the blocked interface on LSW3 is unblocked and enters the Forwarding state. This interface then sends a Flush-FDB packet to instruct the other nodes in the SEP segment to refresh their MAC address forwarding tables and ARP tables. The lower-layer network can detect the fault of the upper-layer network, and therefore reliable service transmission is guaranteed.
