WO2018120228A1

WO2018120228A1 - Method and device for recovering from ring circuit fault, and node apparatus

Info

Publication number: WO2018120228A1
Application number: PCT/CN2016/113969
Authority: WO
Inventors: 王德海; 普云; 吴俊宏
Original assignee: 华为技术有限公司
Priority date: 2016-12-30
Filing date: 2016-12-30
Publication date: 2018-07-05

Abstract

Disclosed are a method and device for recovering from a ring circuit fault, and a node apparatus. The method comprises: when recovering from a link fault on a ring circuit, a non-faulty node apparatus on the ring circuit receiving a link recovery NR message sent by a faulty node apparatus; the non-faulty node apparatus eliminating node identifiers stored on a port of the non-faulty node apparatus that receives the NR message and on a port that does not receive the NR message; the non-faulty node apparatus learning a new node identifier when receiving an RPL owner port blocked (RB) message sent by a ring circuit protection link (RPL) owner, wherein the new node identifier is a node identifier on an RPL owner port; and, on the basis of a result indicating that the new node identifier is inconsistent with the node identifier currently saved on a port receiving the RB message, the non-faulty node apparatus deleting an address forwarding entry learned during the fault period, and re-learning the address forwarding entry.

Description

Loop fault recovery method, device and node device

Technical field

The present invention relates to the field of Ethernet technologies, and in particular, to a loop fault recovery method, apparatus, and node device.

Background technique

ERPS (English: Ethernet Ring Protection Switching, referred to as Ethernet Loop Protection Switching) provides carrier-class reliability. It can perform fast switching within 50ms when a fault occurs in the ring network topology to ensure normal transmission of services. In addition, the ERPS technology is also applicable to a scenario in which a ring network is formed with a third-party device, and a 50 ms service is quickly converged and switched. ERPS can eliminate the Layer 2 loop of the network by selectively blocking redundant links of the network loop, that is, half-ring transparent transmission.

The basic concept of ERPS technology:

Ring: Ring, which consists of nodes and links to form an Ethernet loop;

Node: the device on the ring;

RPL (English: Ring Protection Link, referred to as: Ring Protection Link);

RPL Owner: A node connected to the RPL and responsible for controlling the behavior of the RPL. It can be called an RPL owner.

SF (English: Signal Fail, referred to as signal failure), link failure signal.

The way ERPS technology works is as follows:

When the loop is in the stable state, the RPL Owner port is blocked, and the data packets cannot be forwarded through the RPL Owner port. At this time, only the RPL Owner port can send the ERPS protocol (English: Ring Auto Protection Switching, R-APS). For example, the RPL Owner port sends an RPL Owner port blocking (English: RPL Blocked, RB for short) message. Other node devices on the loop. The port that receives the RB packet on the other node device learns the node identifier (English: Node Identification). At this time, the node identifier learned by the port of the RB packet received by the other node device is the node identifier of the RPL Owner. In practical use, The node identifier can be represented by the media access control (English: Media Access Control, MAC address) address of the node device. The situation applies to the MAC address of all ports on a node device and the MAC address of the node device are the same, or the port. There is no MAC address. The node ID can also be represented by the MAC address of the port on the node device. This applies to the case where each port on a node device has its own MAC address. Correspondingly, the port that receives the RB packet on the other node device learns that the node identifier is the MAC address of the RPL Owner port.

In addition, the port that receives the data packet on the node device learns the address forwarding entry to form a routing forwarding table.

When the non-RPL link on the loop is faulty, the blocked state of the RPL Owner port is removed and data packets can be forwarded. The node device where the faulty port resides sends SF packets to other node devices on the ring. After receiving the SF packet, the port of the other node device learns that the new node ID is the MAC address of the faulty port. In addition, the node ID learned on the faulty port is cleared, and the original address forwarding entry of the device where the faulty port is located is triggered, and the address forwarding entry is re-learned. However, at this time, the other port on the node device where the faulty port is located does not receive the SF packet sent by itself, so the other port does not relearn the node identifier, so it is still the node identifier that was originally learned, that is, RPL. MAC address of the Owner port. Similarly, the port of the other node device that does not receive the NR packet sent by the node device where the faulty port is located does not relearn the node identifier, so it is still the MAC address of the RPL Owner port.

When the link is faulty, the node device where the faulty port resides sends a link recovery (English: No Request, NR for short) message to other node devices on the loop. The port that receives the NR packet from other node devices deletes the new node identifier, that is, the MAC address of the faulty port, but does not clear the address forwarding entry learned during the fault. However, at this time, the other port on the node device where the faulty port is located does not receive the NR packet sent by itself, so the node identifier saved on the other port is still the MAC address of the RPL Owner port. Similarly, the node identifier on the port of the NR packet sent by the node device that does not receive the faulty port on the other node device will not be cleared, so it is still the MAC address of the RPL Owner port.

Next, the RPL Owner port is re-blocked and sends RB messages to other node devices. Its The port that receives the RB packet on the node device re-learns the node identifier. In the existing protocol, if the node ID learned by the port is the same as the node ID originally stored on the port, the re-learning address forwarding entry will not be triggered. Therefore, the other port of the faulty node device re-learns the MAC address of the RPL Owner port according to the RB packet, and the node identifier of the node that is currently saved is the same, so the address of the node device where the faulty port is learned is transferred. The published item will not change, and it is still the address forwarding entry learned during the failure. Therefore, traffic packets are sent to the RPL Owner port, which is discarded by the RPL Owner port. This causes traffic corruption when the fault is rectified. After the address forwarding entry is aged, the traffic forwarding can be normal after the address forwarding entry is re-learned. This problem also exists on non-faulty node devices.

Summary of the invention

The embodiment of the invention provides a loop fault recovery method, device and node device, which are used to solve the technical problem that the data packet forwarding is abnormal after the fault recovery in the prior art.

In a first aspect, an embodiment of the present invention provides a loop fault recovery method, which is described from the perspective of a non-faulty device. The method includes: when the link failure on the loop recovers, the non-faulty node device on the loop receives the NR message sent by the failed node device; and the non-failed node device clears the port that receives the NR message by itself. And the node identifier saved on the port that does not receive the NR packet; when the non-faulty node device receives the RB packet sent by the RPL Owner, learns a new node identifier, and the new node identifier is an RPL Owner port. The non-faulty node device deletes the address forwarding entry learned during the failure and re-learns the address based on the result that the new node identifier is inconsistent with the node identifier currently stored on the port that receives the RB packet. Forward the entry. In the solution of the embodiment of the present invention, when the RPL Owner sends the RB message to the other node device after receiving the NR message sent by the faulty node device, the non-faulty node device receives the port of the RB message. The learned node identifier is inconsistent with the currently stored node identifier (because the non-failed node device has cleared its own receipt and the node identifier saved on the port that did not receive the NR packet when receiving the NR packet, so the current storage The node ID is empty, so the non-failed node device is triggered to delete the address forwarding entry learned during the failure and relearn New address forwarding entry. Therefore, after the non-faulty node device receives the data packet, the data packet can be forwarded normally according to the re-learned address forwarding entry. Compared with the fault recovery method in the prior art, the method in the embodiment of the present invention does not cause packet loss, and does not need to wait for the address aging time to enable the data packet to be forwarded normally, thereby improving the ERPS half-ring switching performance. .

In a second aspect, an embodiment of the present invention provides a loop fault recovery method, which is described from the perspective of a faulty device. The method includes: when a link failure of the loop recovers, the failed node device on the loop sends an NR message to the non-faulty node device; the failed node device clears all ports of the loop on the ring to save The node identifier is learned. When the faulty node device receives the RB packet sent by the RPL Owner, the new node identifier is learned, and the new node identifier is the node identifier of the RPL Owner port; the faulty node device is based on the new node. As a result of inconsistent with the node identifier currently stored on the port that receives the RB packet, the address forwarding entry learned during the failure is deleted and the address forwarding entry is re-learned. In the solution of the embodiment of the present invention, when the RPL Owner sends the RB message to the other node device after receiving the NR message sent by the faulty node device, the faulty node device receives the port learning of the RB message. The node ID that is reached is inconsistent with the currently stored node ID (because the faulty node device has cleared the node identifier saved by all ports on the loop, so the currently stored node identifier is empty), so the faulty node device is triggered. Delete the address forwarding entry learned during the fault and relearn the new address forwarding entry. Therefore, after the faulty node device receives the data packet, the data packet can be forwarded normally according to the re-learned address forwarding entry. Compared with the fault recovery method in the prior art, the method in the embodiment of the present invention does not cause packet loss, and does not need to wait for the address aging time to enable the data packet to be forwarded normally, thereby improving the ERPS half-ring switching performance. .

In one possible design, the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a medium access control MAC address.

In one possible design, the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.

In a third aspect, an embodiment of the present invention provides a loop fault recovery apparatus, where the loop fault recovery apparatus includes a party in a possible implementation manner of any one of the first aspect to the second aspect. Functional module of the law.

Based on the same inventive concept, the implementation of the method in any of the possible implementations of the first aspect to the second aspect and the beneficial effects thereof may be referred to due to the principle and the beneficial effects of the device. For the implementation of the device, reference may be made to the implementation of the method in any of the possible implementations of the first aspect to the second aspect, and the repeated description is not repeated.

In a fourth aspect, an embodiment of the present invention provides a node device. The node device includes: a sending port, a receiving port, and a processor. The transmitting port can be used to perform the steps transmitted in the loop failure recovery method of the aforementioned first aspect. The receiving port may perform the steps received in the loop failure recovery method of the aforementioned first aspect. The processor can perform the steps of learning or clearing in the loop failure recovery method of the aforementioned first aspect.

In a fifth aspect, an embodiment of the present invention provides a node device. The node device includes: a sending port, a receiving port, and a processor. The transmitting port can be used to perform the steps of the loop failure recovery method in the aforementioned second aspect. The receiving port may perform the steps received in the loop failure recovery method of the aforementioned second aspect. The processor can perform the steps of learning or clearing in the loop failure recovery method of the aforementioned second aspect.

In a sixth aspect, an embodiment of the present invention provides a non-volatile computer storage medium, where the non-volatile computer storage medium stores program code, where the program code includes the first aspect to the second An instruction of a method in any of the possible implementations of the aspects.

DRAWINGS

FIG. 1 is a structural diagram of a loop according to an embodiment of the present invention;

2 is a structural diagram of a node device according to an embodiment of the present invention;

3 is a flowchart of a loop fault recovery method on a non-faulty node device side according to an embodiment of the present invention;

FIG. 4 is a flowchart of a loop fault recovery method on a faulty node device side according to an embodiment of the present invention;

5a-5c are schematic diagrams of a loop fault change and a processing manner according to an embodiment of the present invention;

6 is a schematic diagram of a processing manner after a link failure recovery in the prior art;

FIG. 7 is a functional block diagram of a loop fault recovery apparatus according to an embodiment of the present invention.

detailed description

The embodiment of the invention provides a method, a device and a node device for recovering a loop fault, which are used to solve the technical problem that the data packet forwarding is abnormal after the loop fault recovery in the prior art.

The technical solutions in the embodiments of the present invention will be described below in conjunction with the accompanying drawings in the embodiments of the present invention.

It is understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

The term "and/or" in this context is merely an association describing the associated object, indicating that there may be three relationships, for example, A and / or B, which may indicate that A exists separately, and both A and B exist, respectively. B these three situations. In addition, the character "/" in this article generally indicates that the contextual object is an "or" relationship.

As described in the background, the node device in the loop may be the same as the node identifier that is learned after the RP packet is sent by the RPL Owner port after the fault is recovered. The port that does not receive the NR packet re-learns the address forwarding entry. Therefore, the node device that has not received the NR packet uses the old address forwarding entry learned during the fault to forward the data packet until the old address forwarding entry is forwarded. Aging, but the old address forwarding entry will cause the data packet to be sent to the blocked RPL Owner port. The data packet will be discarded. As a result, the data packet forwarding is abnormal.

In order to solve the above technical problem, the embodiment of the present invention provides a loop fault recovery method, which can be applied to the loop structure shown in FIG. The loop fault recovery method in the embodiment of the present invention is based on the loop architecture shown in FIG. 1. After the link is restored, the node device where the faulty port is located not only receives the NR packet but also receives the NR packet. The node ID stored on the port will be Cleared, the node identifier stored on the port that did not receive the NR packet is also cleared, and/or the original failed node device also clears the node identifier saved by all its ring ports, so when these ports receive the RPL again When the RB message sent by the Owner is inconsistent with the currently stored node identifier (currently empty), the port is re-learned. Therefore, after receiving the data packet, the node device can forward the data packet according to the re-learned address forwarding entry. Compared with the fault recovery method in the prior art, the method in the embodiment of the present invention does not cause packet loss, and does not need to wait for the address aging time to enable the data packet to be forwarded normally, thereby improving the ERPS half-ring switching performance. .

Specifically, as shown in FIG. 1 , the node device A to the node device E are, for example, switches, and the node devices are connected to form a layer 2 loop or a layer 3 loop. In the case of no failure, data packets can be transmitted in the loop except for the blocked RPL Owner port.

Each node device can be separately connected to a terminal, where a MAC address is used to represent each terminal, such as terminal MAC1 to terminal MAC5 in FIG. The address forwarding entries learned on each node device can be classified into two types. The outgoing port of the address is the port on the ring, and the outgoing port of the other type is the non-ring port. For example, on the node device D. The egress port of the learned terminal MAC1 is D3, which is the ring-down port, and the egress port of the terminal MAC2 learned on the node device D is D1, which is the egress port on the ring. In this way, an address forwarding table for each node device can be formed.

In this embodiment, each node device has at least one pair of ports on the ring; for example, the ring ports on the node device D are D1 and D2.

It should be noted that the node device E and the node device D are not directly connected through the ring port, but are connected through a third-party network. Therefore, in the loop structure shown in FIG. 1, the ERPS protocol packet, for example, the SR packet. The NR message and the RB message cannot reach the node device D from the node device E, and cannot reach the node device E from the node device D. The node device E and the node device D can transmit data messages through the third network. The loop structure shown in Figure 1 can also be referred to as a half-ring structure.

It should be understood that FIG. 1 is described by taking five node devices on the loop as an example. However, in actual applications, any number of node devices may be included in the loop, and those skilled in the art may set according to actual requirements.

Referring to FIG. 2, FIG. 2 is a schematic structural diagram of a node device according to an embodiment of the present invention. The node device is, for example, a possible block diagram of any node device of the node device A to the node device E. As shown in FIG. 2, the node device includes: a processor 10, a transmitting port 20, a receiving port 30, and a memory 40. The memory 40, the transmit port 20 and the receive port 30, and the processor 10 can be connected via a bus. Of course, in the actual application, the memory 40, the transmitting port 20, and the receiving port 30 and the processor 10 may not be a bus structure, but may be other structures, such as a star structure, which is not specifically limited in the present application.

Optionally, the processor 10 may be a general-purpose central processing unit or an application specific integrated circuit (ASIC), and may be one or more integrated circuits for controlling program execution, and may be A hardware circuit developed using a Field Programmable Gate Array (FPGA) can be a baseband processor.

Alternatively, processor 10 may include at least one processing core.

Optionally, the memory 40 may include one or more of a read only memory (English: Read Only Memory, ROM for short), a random access memory (English: Random Access Memory, RAM), and a disk storage. Memory 40 is used to store data and/or instructions needed by processor 10 to operate. The number of memories 40 may be one or more. The memory 40 can also be used to store the foregoing address forwarding entry, node identifier, and the like.

Optionally, the sending port 20 and the receiving port 30 are physically independent of each other or integrated.

The number of the sum of the sending port 20 and the receiving port 30 is at least two. The sending port 20 for packet output can also be called an egress port. The receiving port 30 for packet input can also be called an ingress port.

Referring to FIG. 3, FIG. 3 is a flowchart of a loop fault recovery method according to an embodiment of the present invention. In the method shown in FIG. 3, it is described from the perspective of a non-faulty node device. As shown in FIG. 3, the method includes:

Step 101: When the link failure on the loop recovers, the non-faulty node device on the loop Receiving an NR message sent by the failed node device;

Step 102: The non-faulty node device clears its own port that receives the NR packet and the node identifier that is saved on the port that does not receive the NR packet.

Step 103: When the non-faulty node device receives the RB packet sent by the RPL Owner, learns a new node identifier, where the new node identifier is a node identifier of the RPL Owner port.

Step 104: The non-faulty node device deletes the address forwarding entry learned during the fault and re-learns the address translation based on the result that the new node identifier is inconsistent with the node identifier currently stored on the port that receives the RB packet. Publish the item.

Therefore, when the RPL Owner sends an RB message to another node device after receiving the NR message sent by the failed node device, the node identifier and the current port learned by the port receiving the RB message on the non-faulty node device The stored node identifiers are inconsistent (because in step 102, the non-faulty node device has cleared its own received and the node identifier saved on the port that did not receive the NR packet, so the currently stored node identifier is empty), so The non-failed node device is triggered to delete the address forwarding entry learned during the failure and relearn the new address forwarding entry. Therefore, after the non-faulty node device receives the data packet, the data packet can be forwarded normally according to the re-learned address forwarding entry. Compared with the fault recovery method in the prior art, the method in the embodiment of the present invention does not cause packet loss, and does not need to wait for the address aging time to enable the data packet to be forwarded normally, thereby improving the ERPS half-ring switching performance. .

Referring to FIG. 4, FIG. 4 is a flowchart of a method for recovering a loop fault according to an embodiment of the present invention. In the method shown in FIG. 4, a node device from which a faulty port is located (hereinafter referred to as a faulty node) The angle of the device is described. As shown in FIG. 4, the method includes:

Step 201: When the link failure of the loop is restored, the faulty node device on the loop sends an NR packet to the non-faulty node device.

Step 202: The faulty node device clears its own node identifier saved on all ports on the loop.

Step 203: When the faulty node device receives the RB packet sent by the RPL Owner, learns a new node identifier, where the new node identifier is a node identifier of the RPL Owner port.

Step 204: The faulty node device deletes the address forwarding entry learned during the fault and re-learns the address forwarding table based on the result that the new node identifier is inconsistent with the node identifier currently stored on the port that receives the RB packet. item.

Therefore, when the RPL Owner sends an RB message to another node device after receiving the NR message sent by the failed node device, the node identifier and the current storage learned by the port receiving the RB message on the faulty node device The node identifiers are inconsistent (because in step 202, the failed node device has cleared its own node ID saved on all ports on the loop, so the currently stored node identifier is empty), so the node device that triggered the fault is deleted. The address forwarding entry learned during the failure and re-learning the new address forwarding entry. Therefore, after the faulty node device receives the data packet, the data packet can be forwarded normally according to the re-learned address forwarding entry. Compared with the fault recovery method in the prior art, the method in the embodiment of the present invention does not cause packet loss, and does not need to wait for the address aging time to enable the data packet to be forwarded normally, thereby improving the ERPS half-ring switching performance. .

To facilitate the understanding of the specific implementation process and beneficial effects of the loop failure method in the embodiments of the present invention, those skilled in the art will be specifically exemplified below.

Referring to FIG. 4a, when the loop is in a stable state, node device A functions as an RPL Owner, and port 1 on node device A (hereinafter referred to as port A1 for convenience of description) is in a blocked state (port A1 in FIG. 4a). The black dot indicates that the port A1 is blocked. That is, the data packet cannot be forwarded through the port A1, but the R-ARS, such as the NR packet and the RB packet, can be sent through the port A1. In the steady state, the node device A sends the RB message to the node device E through the port A1, and sends the RB message to the node device B through the port 2 on the node device A (hereinafter referred to as the port A2 for convenience of description). Correspondingly, port 2 of node device E (for ease of description, hereinafter referred to as port E1) will learn that the node identifier is port A1, for example, represented by the MAC address of port A1, (A1) next to port E2 in Figure 5a. Indicates that the node ID learned by port E2 is port A1. Because the port 1 of the node device E (hereinafter referred to as the port E1) is connected to the third-party network, the RB packet cannot be forwarded. Therefore, the node device E does not forward the RB packet.

Correspondingly, port 1 of node device B (hereinafter referred to as port B1) will receive the node device A to send. The RB message and the learned node ID is port A1. The node device B then forwards the RB message to the node device C through its own port 2 (hereinafter referred to as port B2). Correspondingly, the port 1 of the node device C (hereinafter referred to as C1) receives the RB packet, and the learned node identifier is port A1. Similarly, the node device C forwards the RB message to the node device D through its own port 2 (hereinafter referred to as port C2). Correspondingly, the port 1 of the node device D (hereinafter referred to as D1) receives the RB packet, and the learned node identifier is port A1. Because the port 2 of the node device D (hereinafter referred to as the port D2) is connected to the third-party network, the RB packet cannot be forwarded, so the node device D does not forward the RB packet.

For the node device B, when the source MAC address is MAC1 and the destination MAC address is the MAC2 data packet, the node device B learns the address forwarding entry as the destination MAC address is MAC1. The outbound port is port B2, and the address forwarding entry can be simply represented as MAC1->B2. On the other hand, when the destination MAC address is MAC2 and the destination MAC address is MAC2, the destination MAC address learned by the node B is MAC2. The corresponding egress port is port B3. The address forwarding entry can be simply represented as MAC2->B3.

Similarly, for the node device B, when the source MAC address is MAC4 and the destination MAC address is the data packet of the MAC2, the address forwarding entry learned by the node device B is the destination MAC address. The corresponding egress port is port B1. The address forwarding entry can be simply represented as MAC4->B1.

Therefore, the address forwarding routing table on the node device B can be as shown in Table 1.

目的地址Destination address	出端口Out port
MAC1MAC1	B2B2
MAC2MAC2	B3B3
MAC4MAC4	B1B1

Table I

In Table 1, the routing table can include two fields, a destination address field and an out port field. The destination address field is used to represent the destination address of the data packet. The outbound port field is the egress port corresponding to the destination address.

For the node device C, when the source MAC address is MAC1 and the destination MAC address is the MAC2 data packet, the node device C learns the address forwarding entry as the destination MAC address is MAC1. The outbound port is port C2, and the address forwarding entry can be simply represented as MAC1->C2. On the other hand, when the destination MAC address is MAC3 and the destination MAC address is MAC3, the destination MAC address learned by the node C is MAC3. The corresponding egress port is port C3. The address forwarding entry can be simply represented as MAC3->C3.

Similarly, for the node device C, when the source MAC address is MAC4 and the destination MAC address is the data packet of the MAC1, the address forwarding entry learned by the node device C is the destination MAC address. The corresponding egress port is port C1. The address forwarding entry can be simply represented as MAC4->C1.

Therefore, the address forwarding routing table on the node device C can be as shown in Table 2.

目的地址Destination address	出端口Out port
MAC1MAC1	C2C2
MAC3MAC3	C3C3
MAC4MAC4	C1C1

Table II

It should be noted that, in this embodiment, a Layer 2 loop is taken as an example, so the destination address is represented by a MAC address, and in the Layer 3 loop, the destination address may be a network protocol (English: Internet Protocol, referred to as IP) )address. In the implementation of the method of the embodiment of the present invention, the principle of the use of the Layer 2 loop and the Layer 3 loop is the same. Therefore, in the embodiment, for the sake of brevity of the description, a Layer 2 loop is taken as an example for description.

Next, if there is a port failure in the loop, the node device where the faulty port is located sends SF packets to other non-faulty node devices on the loop. The port that receives the SF packet on the other non-faulty node device learns the new node identifier, that is, the identifier of the faulty port. Specifically, please refer to FIG. 5b, assuming that because the port C2 and/or the port D1 fails, or the link between the node device C and the node device D fails, the node device C cannot pass the port C2 and the port D1 and the node. Point device D performs message transmission.

Therefore, the node device C sends the SF packet to the node device B through the port C1. Correspondingly, the port B2 of the node device B receives the SF packet and learns the new node identifier, which is the port C2. The node device B then forwards the SF message to the node device A through its own port B1. Port A2 of node device A receives the SF packet and learns the new node identifier, which is port C2. The node device A then forwards the SF message to the node device E through its own port A1. Correspondingly, the port E2 of the node device E receives the SF packet, and the learned node identifier is the port C2. Because the port E1 of the node device E is connected to the third-party network, the SF packet cannot be forwarded, so the node device E does not forward the SF packet. Similarly, because the port D2 of the node device D is connected to the third-party network, the SF packet cannot be forwarded, so the node device D does not forward the SF packet. Of course, in the actual application, if the node D2 of the node device D is also connected to the node device, the SF message can be sent to the connected node device through the port D2, and the port of the connected node device that receives the SF packet learns. Go to the new node ID, port D1.

In addition, when the link is faulty, the node identifier stored on the faulty port is cleared by the faulty node device. Therefore, the node identifier saved by port C1 is still port A1, and the node identifiers on port C2 and port D1 are empty.

After the node ID of the faulty port is cleared, the address forwarding entry on the node where the faulty port is located is also cleared. Therefore, the node device where the faulty port resides re-learns the address forwarding entry. At this time, the RPL Owner port is unblocked, that is, the port A1 is changed to the unblocked state, and the data packet and the data packet can be forwarded through the port A1. The link between the node device C and the node device D is faulty, so the source MAC address is MAC1, and the data packet whose destination MAC address is MAC2 is transmitted from the third-party network to the node device E and the node device A because of the broadcast mechanism, and then The port B1 enters the node device B. Therefore, when the destination MAC address learned by the node device B is the destination MAC address, the corresponding egress port is the port B1, and the address forwarding entry can be simply represented as MAC1->B1. On the other hand, when receiving a data packet whose source MAC address is MAC2 and the destination MAC address is MAC1, the corresponding forwarding port is the port when the destination MAC address learned by the node B is MAC2. B3, the address forwarding entry can be simplified. Single is represented as MAC2->B3.

Therefore, during the link failure, the address forwarding routing table on the node device B can be as shown in Table 3.

目的地址Destination address	出端口Out port
MAC1MAC1	B1B1
MAC2MAC2	B3B3
MAC4MAC4	B1B1

Table 3

Similarly, for the node device C, the link between the node device C and the node device D is faulty, so the source MAC address is MAC1, and the data packet whose destination MAC address is MAC2 is transmitted from the third-party network to the node due to the broadcast mechanism. The device E, the node device A, and the node device B then enter the node device C from the port C1. Therefore, when the destination MAC address learned by the node device C is the destination MAC address, the corresponding egress port is the port C1, and the address is transferred. The publication item can be simply expressed as MAC1->C1. On the other hand, when receiving a data packet whose source MAC address is MAC3 and the destination MAC address is MAC1, the corresponding forwarding port is the port when the destination MAC address learned by the node device C is MAC3. In C3, the address forwarding entry can be simply represented as MAC3->C3.

Therefore, the address forwarding routing table on the node device C can be as shown in Table 4.

目的地址Destination address	出端口Out port
MAC1MAC1	C1C1
MAC3MAC3	C3C3
MAC4MAC4	C1C1

Table 4

After the new address forwarding entry is created, the data packet on the loop is forwarded by unicast according to the new address forwarding entry.

The link fault is restored to normal due to the repair of the technician or other reasons. In the prior art, the node device where the faulty port is located sends an NR message to other node devices. After receiving the NR packet, the other non-faulty node device deletes the node identifier stored on the port that receives the NR packet, but does not store the new node identifier, that is, the other node device receives the NR at this time. The node ID on the port of the packet is empty. The other non-faulty node devices will not clear the address forwarding entry, so the other non-faulty node devices still store the address forwarding entries learned during the fault. For a faulty node device, because the other ring port on the failed node device will not receive the NR packet sent by itself, the node identifier stored on the port on the ring will not be cleared.

Referring to FIG. 6, the implementation in the prior art is: after the link failure is recovered, at this time, the node device C and the node device D have not resumed communication, so the node device C sends the NR to the node device B through the port C1. The packet, correspondingly, the port B2 of the node device B receives the NR packet and clears the stored node identifier, that is, the port C2. The node device B then forwards the NR message to the node device A through its own port B1. Port A2 of node device A receives the NR packet and clears the stored node identifier, that is, port C2. The node device A then forwards the NR message to the node device E through its own port A1. Correspondingly, the port E2 of the node device E receives the NR message and clears the stored node identifier, that is, the port C2. Because the port E1 of the node device E is connected to the third-party network, the NR message cannot be forwarded, so the node device E does not forward the NR message. Similarly, because the port D2 of the node device D is connected to the third-party network, the NR message cannot be forwarded, so the node device D no longer forwards the NR message. Of course, in actual use, if node device D The port D2 is also connected to the node device, and then the NR message can be sent to the connected node device through the port D2, and the port of the connected node device that receives the NR message clears the stored node identifier, that is, the port D1.

In addition, since the port B1 is not the receiving port of the NR message, the node identifier stored on the port B1 is not emptied, and is still the port A1. Port C1 is also not the receiving port of NR packets, so the node identifier stored on port C1 will not be emptied, and it is still port A1. After the processing of this step, the node identifier stored on each port is as shown in FIG. 6.

Optionally, after receiving the NR packet sent by the faulty node device, the RPL Owner blocks the port A1 and can send an NR packet to the other node device to notify the other node that the link fault has been recovered. Further, the RPL Owner may send an RB packet to the other node device, indicating that the port A1 is blocked. For a schematic diagram of RB packet transmission, please refer to Figure 5a. The node ID of the port that receives the RB packet is A1, but the node ID currently stored on port B1 and port C1 is also A1. Therefore, if the two are consistent, the re-learning address forwarding entry will not be triggered. Therefore, the address forwarding entry on node device B is still shown in Table 3. The address forwarding entry on node device C is still shown in Table 4. In this case, the data packet whose destination address is MAC1 is still sent to the node device A through the port B1, and the port A1 is blocked. Therefore, the data packet is discarded by the port A1, so the data packet cannot be normal. Forward.

In order to solve the technical problem, in the embodiment of the present invention, after the link failure is recovered, the non-faulty node device performs step 101 and step 102, that is, the non-faulty node device receives the NR message sent by the failed node device, and Clear the node ID saved on the port that it received and that did not receive the NR message. In other words, the non-failed node device also clears the node identifier saved on the port that has not received the NR message.

Similarly, after the link failure is recovered, the faulty node device performs step 201 and step 202, that is, the faulty node device sends an NR message to the non-faulty node device, and empties its own saved on all ports on the loop. Node ID. In other words, the failed node device also empties the node identifier saved on its own non-faulty port.

For example, after the fault is recovered, after step 101 and step 102, on each port The case of the stored node identification is shown in Figure 4c. That is, the node device C sends an NR message to the other non-faulty node device on the loop. After receiving the NR message sent by the node device C, the port device B clears the node identifier stored on the port B2. Further, the node device B also clears the node identifier stored on the port B1. After receiving the NR message sent by the node device B, the port device A2 clears the node identifier stored on the port A2. Further, the node device A also clears the node identifier stored on the port A1. After the port E2 receives the NR message sent by the node device A, the node device E clears the node identifier stored on the port E2.

For example, after the fault is recovered, after step 201 and step 202, the node identifier stored on each port is as shown in FIG. 4c. That is, the node device C sends an NR message to other node devices on the loop, and the node device C also clears the node identifier stored on the port C1.

In the case of FIG. 4c, when the RPL Owner sends an RB message, port B1 receives the NR message and learns the node identifier, as shown in FIG. 5a. The node ID learned by the port B1 is the port A1, and the current node ID of the port B1 is empty. Therefore, the two devices are inconsistent, and the node device learns the new address forwarding entry. After learning, the new address forwarding entry is learned. It is the entry shown in Table 1, so the data packet can be forwarded normally.

In the case of FIG. 4c, when the RPL Owner sends an RB message, port C1 receives the NR message and learns the node identifier, as shown in FIG. 5a. At this time, the node ID learned by the port C1 is the port A1, and the current node ID of the port C1 is empty. Therefore, if the two are inconsistent, the node device learns the new address forwarding entry. After learning, the new address forwarding entry is learned. The entries shown in Table 2, so data packets can be forwarded normally.

Therefore, the method in the embodiment of the present invention can ensure that after the link failure is recovered, the faulty node device and the non-failed node device delete the address forwarding entry learned during the fault and relearn the address forwarding entry. The normal forwarding of data packets is ensured, and the packet forwarding entries cannot be re-learned after waiting for the address to age.

Based on the same inventive concept, an embodiment of the present invention further provides a node device (shown in FIG. 2), which is used to implement any one of the foregoing methods.

Optionally, when the node device is a non-faulty node device, the receiving port 30 is used to be a ring. When the link failure on the road is restored, the link sent by the node device receiving the fault on the loop recovers the NR message; the processor 10 is configured to clear the receiving port 30 and the NR report is not received on the node device. The node identifier saved on the port of the text; when the receiving port 30 receives the RPL owner port blocking RB packet sent by the loop protection link RPL owner, learns a new node identifier, and the new node identifier is The node identifier of the RPL owner port; and based on the result that the new node identifier is inconsistent with the node identifier currently stored on the receiving port 30, the address forwarding entry learned during the fault is deleted and the address forwarding entry is re-learned.

Optionally, the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a media access control MAC address.

Optionally, the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.

Optionally, when the node device in FIG. 2 is a faulty node device, the sending port 20 is configured to send a link recovery NR report to the non-faulty node device on the loop when the link of the loop is restored. The processor 10 is configured to clear a node identifier saved by all the ports of the node device on the loop, and the receiving port 30 is configured to receive an RPL owner port blocking RB sent by the RPL owner of the loop protection link. The processor 10 is further configured to: when the receiving port 30 receives the RB message, learn a new node identifier, where the new node identifier is a node identifier of an RPL owner port; and based on the new As a result of the inconsistency between the node identifier and the node identifier currently stored on the receiving port 30, the address forwarding entry learned during the fault is deleted and the address forwarding entry is re-learned.

Based on the same inventive concept, an embodiment of the present invention further provides a loop fault recovery apparatus, where the loop fault recovery apparatus includes a functional module for performing the foregoing method steps. In a possible implementation manner, as shown in FIG. 7, the loop fault recovery apparatus includes a receiving unit 301, a processing unit 302, and a transmitting unit 303.

Optionally, when the loop fault recovery device is configured to implement the function of the foregoing non-faulty node device, the receiving unit 301 is configured to send, when the link failure on the loop recovers, the node device that receives the fault on the loop sends The link recovers the NR message; the processing unit 302 is configured to clear the node identifier stored on all ports on the loop of the non-faulty node device on the loop; and receive the loop protection chain at the receiving unit 301. Learning the new node identifier when the RPL owner port sent by the RPL owner blocks the RB message, the new node identifier is the node identifier of the RPL owner port; and based on the new node identifier and the non-fault As a result of the inconsistent node identifier currently stored on the port on the node device, the address forwarding entry learned by the non-faulty node device during the failure is deleted and the address forwarding entry is re-learned.

Optionally, when the loop fault recovery device is configured to implement the function of the foregoing non-faulty node device, the sending unit 303 is configured to: when the link failure on the loop recovers, to the non-faulty node device on the loop The sending unit recovers the NR message; the processing unit 302 is configured to: clear the node identifier stored on all ports on the loop of the faulty node device on the loop; and receive unit 301, configured to receive the loop protection chain The RPL owner port sent by the RPL owner blocks the RB message, and the processing unit 302 is further configured to: when the receiving unit 301 receives the RB message, learn a new node identifier, where the new node identifier is a node identifier of the RPL owner port; and deleting the address of the node device that is learned during the fault based on the result that the new node identifier is inconsistent with the node identifier currently stored on the port on the faulty node device Publish the item and relearn the address forwarding entry.

The various changes and specific examples in the loop fault recovery method in the foregoing embodiment are also applicable to the loop fault recovery device of the present embodiment and the node device in FIG. 2, and the foregoing detailed description of the loop fault recovery method is provided. The loop fault recovery device in this embodiment and the implementation method of the node device in FIG. 2 can be clearly understood by those skilled in the art, and therefore, for the sake of brevity of the description, details are not described herein again.

Those skilled in the art will appreciate that embodiments of the present invention can be provided as a method, system, or computer program product. Thus, embodiments of the invention may be in the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, embodiments of the invention may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) in which computer usable program code is embodied.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

It will be apparent to those skilled in the art that various modifications and changes can be made in the present application without departing from the spirit and scope of the application. Thus, if such modifications and variations of the application are claimed in the present application The present application is also intended to cover such modifications and variations within the scope of the invention.

Claims

A loop fault recovery method, comprising:

When the link failure on the loop is restored, the non-faulty node device on the loop receives the link recovery NR packet sent by the failed node device;

The non-faulty node device clears its own port that receives the NR packet and the node identifier that is saved on the port that does not receive the NR packet;

When the non-faulty node device receives the RPL owner port blocking RB message sent by the loop protection link RPL owner, learns a new node identifier, and the new node identifier is a node identifier of the RPL owner port. ;

The non-faulty node device deletes the address forwarding entry learned during the failure and re-learns the address forwarding table based on the result that the new node identifier is inconsistent with the node identifier currently stored on the port that receives the RB packet. item.
The method of claim 1, wherein the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a medium access control MAC address.
The method of claim 1, wherein the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.
A loop fault recovery method, comprising:

When the link of the loop is restored, the faulty node device on the loop sends a link recovery NR message to the non-faulty node device;

The faulty node device clears its own node identifier saved on all ports on the loop;

When the faulty node device receives the RPL owner port blocking RB message sent by the loop protection link RPL owner, learns a new node identifier, where the new node identifier is a node identifier of the RPL owner port;

The faulty node device deletes the address forwarding table learned during the fault based on the result that the new node identifier is inconsistent with the node identifier currently stored on the port that receives the RB packet. And relearn the address forwarding entry.
The method of claim 4, wherein the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a medium access control MAC address.
The method of claim 4, wherein the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.
A loop fault recovery device, comprising:

a receiving unit, configured to: when a link failure on the loop recovers, receive a link recovery NR message sent by the node device that is faulty on the loop;

a processing unit, configured to clear a node identifier saved on all ports on the loop of the non-faulty node device on the loop; and receiving, by the receiving unit, an RPL owned by a loop protection link RPL owner When the port blocks the RB message, learns a new node identifier, the new node identifier is a node identifier of the RPL owner port; and based on the new node identifier and the current port on the non-faulty node device As a result of the inconsistent stored node identifiers, the address forwarding entries learned by the non-faulty node device during the failure are deleted and the address forwarding entries are re-learned.
The device according to claim 7, wherein the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a medium access control MAC address.
The device according to claim 7, wherein the loop is a Layer 3 Ethernet loop, and an address in the address forwarding entry is a network protocol IP address.
A loop fault recovery device, comprising:

a sending unit, configured to send a link recovery NR message to the non-faulty node device on the loop when the link failure on the loop is restored;

a processing unit, configured to clear a node identifier saved on all ports on the loop of the node device on the fault on the loop;

a receiving unit, configured to receive an RPL owner port blocking RB packet sent by a loop protection link RPL owner,

The processing unit is further configured to: when the receiving unit receives the RB message, learn a new node identifier, where the new node identifier is a node identifier of an RPL owner port; As a result of the inconsistency between the new node identifier and the node identifier currently stored on the port on the faulty node device, the address forwarding entry learned by the faulty node device during the fault is deleted and the address forwarding entry is re-learned.
The device according to claim 10, wherein the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a media access control MAC address.
The device according to claim 10, wherein the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.
A node device, comprising:

a receiving port, configured to: when the link failure on the loop is restored, the link device that receives the fault on the loop recovers the NR message;

a processor, configured to clear a node identifier saved on the receiving port and the port on the node device that does not receive the NR packet; and receive, at the receiving port, an RPL sent by a loop protection link RPL owner When the owner port blocks the RB message, learns a new node identifier, the new node identifier is a node identifier of the RPL owner port; and the node identifier that is currently stored on the receiving port is inconsistent based on the new node identifier As a result, the address forwarding entry learned during the failure is deleted and the address forwarding entry is re-learned.
The node device according to claim 13, wherein the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a media access control MAC address.
The node device of claim 13, wherein the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.
A node device, comprising:

a sending port, configured to send a link recovery NR message to the non-faulty node device on the loop when the link of the loop is restored;

a processor, configured to clear a node identifier saved by all ports of the node device on the loop;

a receiving port, configured to receive an RPL owner port blocking RB packet sent by the RPL owner of the loop protection link;

The processor is further configured to: when the receiving port receives the RB packet, learn a new node identifier, where the new node identifier is a node identifier of an RPL owner port; and based on the new node As a result of the inconsistency between the identifier and the node identifier currently stored on the receiving port, the address forwarding entry learned during the fault is deleted and the address forwarding entry is re-learned.
The node device according to claim 16, wherein the loop is a Layer 2 Ethernet loop, and the address in the address forwarding entry is a media access control MAC address.
The node device of claim 16, wherein the loop is a Layer 3 Ethernet loop, and the address in the address forwarding entry is a network protocol IP address.