CN101136830B - Loop prevention method after RPR bridge fault recovery - Google Patents

Abstract

The invention discloses a method for avoiding a loop after a RPR bridge fault recovers, comprising the following steps: A. After learning that the fault of the fault point in the RPR bridge ring returns to normal, set the maximum transmission unit value of the fault recovery node to one Predetermined value, and send a notification message for notifying the failure of the point of failure to the cross-ring bridge device in the RPR bridge ring; B. each RPR cross-ring bridge device in the RPR bridge ring receives the fault recovery node The sent notification message detects the working status of the respective RPR cross-ring bridge devices, and only keeps one of the active RPR cross-ring bridge devices in the active state. The invention ensures the correct forwarding of the cross-ring business through the cooperation of the fault recovery node and the cross-ring bridge equipment, and solves the loop problem that may occur after the fault point is restored.

Description

Loop avoidance method after RPR bridge failure recovery

technical field

The invention relates to the technical field of network communication, in particular to a method for avoiding loops after fault recovery of an RPR bridge. the

Background technique

Resilient Packet Ring (RPR) technology is a new network architecture and technology designed to meet the requirements of packet-based MAN; it is a ring network composed of packet switching nodes, and adjacent nodes pass through a For fiber optic connections; its network topology is based on two rings transmitting in opposite directions. RPR has the following technical characteristics: 1. Effective multiplexing of transmission bandwidth; 2. Fast ring-bridge protection switching function; 3. Automatic topology discovery. the

A ring network formed by applying the RPR technology is called an RPR ring network, which can be called an RPR ring for short. The packet switching devices on the ring network are called RPR devices. When the RPR device uses the 48-bit MAC address used in Ethernet as the address identifier to uniquely identify the RPR device and carries Layer 2 Ethernet packets through Ethernet Over RPR, the RPR ring can also be called an RPR bridge ring Or bridge mode RPR ring. The devices on the RPR bridge ring can also be called RPR bridge devices, and the MAC addresses on the RPR bridge devices can also be called RPR MAC addresses. As shown in FIG. 1 , a schematic structural diagram of two RPR bridge rings intersecting two RPR bridge devices is described. the

In FIG. 1, there are two RPR bridge rings, which are RPR bridge ring 1 and RPR bridge ring 2 respectively. There are four RPR bridge devices on each RPR bridge ring, and RPR bridge ring 1 and RPR bridge ring 2 intersect at RPR cross-ring bridge device 1 and cross-ring bridge device 2 . Wherein, the cross-ring bridge device is connected to two RPR bridge rings at the same time, and is responsible for forwarding data messages between the two RPR bridge rings. In order to simplify the description, the RPR cross-ring bridge device is simply referred to as the cross-ring bridge device in the following description.

On the RPR bridge ring, because the RPR bridge ring carries Layer 2 Ethernet packets, and the packets between the RPR bridge rings are forwarded through the Address Resolution Protocol (MAC), when two RPR bridge rings intersect The RPR cross-ring bridge device will generate a loop, that is, a loop will be generated between the RPR cross-ring bridge device 1 and the RPR cross-ring bridge device 2 as shown in FIG. 1 , and a broadcast storm phenomenon occurs. the

The current existing method is to cut links through Spanning Tree Protocol (STP) or Rapid Spanning Tree Protocol (RSTP) to generate a loop-free minimum spanning tree, and then generate a minimum spanning tree based on the minimum Trees are used to forward packets on Layer 2 Ethernet to prevent loops in Layer 2 network communication. When a device or link fails on the Layer 2 network, STP or RSTP will recalculate the minimum spanning tree to obtain a new forwarding tree, thus ensuring normal operation of protection services after a failure occurs. the

Although the above method can solve the problems that may occur between the cross-ring bridge devices, this method is because the convergence speed of STP and RSTP is relatively slow, and even RSTP can only reach the level of second-level convergence speed, which prolongs the network communication time. Increase the load of network communication. the

Now there is also a RPR bridge redundancy protection method. This method introduces a new protocol type and utilizes the interaction of the protocol and the triggering of single-ring RPR protection switching to achieve a protection switching capability of 100 ms. the

However, when two faults occur between two RPR cross-ring bridge devices in a ring, and respectively occur on both sides of an RPR cross-ring bridge device, as shown in Figure 2, in order to ensure that the two bridge rings Any point between (RPR bridge ring 1 and RPR bridge ring 2) is reachable, and both RPR cross-ring bridge devices need to be responsible for forwarding cross-ring services (both are in active state). In this case, when one of the node faults (such as fault point 1) recovers, there is no fault point in the adjacent section of RPR bridge device 1 and RPR bridge device 2, and the working modes of RPR bridge device 1 and RPR bridge device 2 will be Change to a normal state, and the faulty point can forward data packets after recovery. Since the RPR cross-ring bridge device cannot immediately perceive this change and cannot immediately change its working status, the two RPR cross-ring bridge devices are still in the master state and are responsible for forwarding data services across the ring bridge , so that the broadcast loop problem will occur, as shown in Figure 3. the

In the aforementioned existing a kind of RPR bridge redundancy protection method, it is to adopt to the original point of failure that has just returned to normal on the RPR ring, delay a period of time and then carry out message forwarding or carry out the forwarding of broadcast data message. As for the situation when two failure points appear, there is no clear solution proposed in this existing solution. the

Contents of the invention

In view of the problems existing in the above-mentioned prior art, the purpose of the present invention is to provide a method for avoiding loops after an RPR bridge failure recovers. The broadcast loop problem that may occur when one of the fault points recovers after the situation of two fault points. the

In order to achieve the above object, the present invention provides a method for avoiding loops after RPR bridge fault recovery, the method may further comprise the steps:

A. After knowing the fault recovery of the fault point in the RPR bridge ring, set the maximum transmission unit value of the fault recovery node to a predetermined value, and send a message to the span-ring bridge device in the RPR bridge ring to notify the fault point The notification message that the fault has been recovered; wherein, the predetermined value of the maximum transmission unit value can ensure that the protocol message passes, but the value of the data message cannot pass, and its value is between 30 and 81 bytes; The failure recovery node is a device adjacent to the failure point;

B. Each RPR cross-ring bridge device in the RPR bridge ring receives the notification message sent by the failure recovery node, detects the working status of each RPR cross-ring bridge device, and only keeps one of the active RPR cross-ring bridge devices active state. the

Preferably, said step A also includes:

Before setting the maximum transmission unit value of the failure recovery node, record the normal maximum transmission unit value of the failure recovery node. the

Preferably, after the failure of the failure point in the RPR bridge ring in the step A returns to normal, before setting the maximum transmission unit value of the failure recovery node to a predetermined value, it also includes:

Trigger the network topology convergence process;

After step A, the method further includes: restoring the maximum transmission unit value of the failure recovery node to the recorded normal maximum transmission unit value after topology convergence. the

Preferably, said step A also includes:

After the maximum transmission unit value is set to the predetermined value, the working state of the failure recovery node is set as a normal state. the

Preferably, the predetermined value of the maximum transmission unit value is a value that can ensure the passage of the protocol message but not the data message, and the value is between 30 and 81. the

Preferably, said step B also includes:

Compare the priorities of the RPR cross-ring bridge devices in the active state, and keep the RPR cross-ring bridge device with the highest priority in the active state. the

Preferably, in the step A, it is known that the failure of the fault point in the RPR bridge ring has returned to normal as:

When the fault point is the RPR bridge device in the RPR bridge ring, it is known by the fault point itself that its fault has returned to normal;

When the fault point is a link in the RPR bridge ring, the fault recovery node adjacent to the fault point learns that the fault of the fault point has recovered to normal. the

Preferably, the failure recovery node in the RPR bridge ring is an RPR bridge device or an RPR cross-ring bridge device. the

Preferably, the notification message is a message implemented by extending an existing message, or is a newly defined message. the

Preferably, in the step B, when a ring-spanning bridge device detects that its working state is the standby state, it does not process the notification message it receives. the

Preferably, in the step B, when a span-ring bridge device detects that its own working state is in the active state, but there are no other span-ring bridge devices connected to it in the active state; or when a span-ring bridge device When it detects that its own working state is active, but its priority is higher than that of other cross-ring bridge devices connected to it in active state, it will not process the notification message received by it . the

Preferably, in the step B, when a span-ring bridge device detects that its working state is active, and there is a span-ring bridge with a higher priority among other span-ring bridge devices connected to it in the active state When the device is activated, the low-priority cross-ring bridge device exits the active state. the

Implementing the present invention has the following beneficial effects: the present invention sends a notification message to the cross-ring bridge device through the fault recovery node. After the cross-ring bridge device receives the notification message, the cross-ring bridge device will The working status/priority of other cross-ring bridge devices to perform subsequent actions (such as maintaining the active state or exiting the active state). In this way, after the failure point is recovered, only one cross-ring bridge device is in the active state, ensuring the correct forwarding of cross-ring services, solving the loop problem in information transmission after the fault point is restored, and there is no need for intra-ring business impact, and has no impact on the convergence of the single-ring protocol. the

Description of drawings

FIG. 1 is a schematic diagram of a prior art RPR bridge-ring network topology. the

FIG. 2 is a communication schematic diagram in the case of two faults occurring simultaneously on one RPR bridge ring in the prior art RPR bridge ring network. the

Fig. 3 is a schematic diagram of a situation where two faults occur simultaneously on an RPR bridge ring in an RPR bridge ring network in the prior art and a broadcast loop is generated when one fault recovers. the

FIG. 4 is a flow chart of a method for preventing a broadcast loop from being generated by a fault recovery node when a non-cross-ring bridge device in an RPR bridge of the present invention recovers from a fault. the

FIG. 5 is a flowchart of a method for avoiding a broadcast loop by a cross-ring bridge device when a non-span-ring bridge device in an RPR bridge recovers from a fault according to the present invention. the

Detailed ways

Preferred embodiments of the present invention will be described in detail below in conjunction with the accompanying drawings. the

The present invention provides a method for avoiding loops after RPR bridge fault recovery. The method solves the problem of recovering one fault point when two fault points appear on an RPR bridge ring at the same time in the application scenario of RPR intersecting rings. Possible broadcast loop problems. The loop avoidance method after the RPR bridge fault recovers is to control the passage of data packets on the RPR ring through the cooperation between the fault recovery node and the cross-ring bridge device, so as to avoid the loop phenomenon on the RPR ring. the

First, please refer to Figure 2, which illustrates an RPR bridge ring network, in which there are two intersecting RPR bridge rings, and the two RPR bridge rings include RPR bridge device 1, RPR bridge device 2, RPR bridge device 3, and RPR bridge ring Bridge device 4 and RPR cross-ring bridge device 1 and RPR cross-ring bridge device 2 . When fault point 1 and fault point 2 exist at the same time, RPR bridge device 1 and RPR bridge device 2 work in protection mode, that is, in the wrap state. No packets will pass through fault point 1, and there will be no The emergence of a broadcast loop. In order to ensure that any point on the two RPR bridge rings can communicate with each other, the working status of RPR cross-ring bridge device 1 and RPR2 cross-ring bridge device are both master (Master) The bridge device is responsible for forwarding cross-ring services, that is, data services can be forwarded in different RPR bridge rings, so that any nodes in the two RPR bridge rings can access each other.

After the fault point 1 recovers, there is no fault point in the adjacent section of the RPR bridge device 1 and the RPR bridge device 2, and the working modes of the RPR bridge device 1 and the RPR bridge device 2 will both change to the normal state. After the working modes of RPR bridge device 1 and RPR bridge device 2 become normal, data packets can pass through the fault point. Since the RPR cross-ring bridge device cannot immediately perceive this change and will not perform state transition, as shown in Figure 3, a broadcast loop problem may occur. Below in conjunction with accompanying drawing 4 and accompanying drawing 5, to illustrate in the present invention, when fault point 1 or fault point 2 recovers, how to avoid the loop in Fig. road phenomenon. the

Please refer to Fig. 4, this figure is the main flowchart of the processing of the failure recovery node in the present invention, the failure recovery node referred to herein refers to the equipment adjacent to the failure point, for failure point 1, its failure recovery node refers to the RPR bridge device 1 or RPR bridge device 2 adjacent to fault point 1. Taking fault point 1 recovery in Figure 3 as an example for illustration, the processing flow includes the following steps:

Step 40: After learning that the failure point 1 in the RPR bridge ring has recovered, a topology convergence process will be triggered; in the RPR bridge ring, the fault point can be the RPR bridge device or the link connecting the RPR bridge device road. Here, since the fault point 1 is a link, after its fault recovers, its edge state disappears, and the fault recovery node (RPR bridge device 1 or RPR bridge device 2) can know that the fault of the fault point 1 has returned to normal. In some other cases, for example, the fault point is an RPR bridge device in the RPR bridge ring, in this case, the fault point itself can know whether its fault has recovered to normal. the

Step 41: After the topology changes, before the topology convergence is completed, it is necessary to judge the work of the failure recovery node (RPR bridge device 1 or RPR bridge device 2) or the failure point (when the failure point is a device in the RPR bridge ring) whether the status has changed;

Step 42: The failure recovery node (RPR bridge device 1 or RPR bridge device 2) detects whether its own working state has changed from a protection state (wrap) state to a normal (normal) state? Here, if the detection result is yes, that is, when the failure recovery node has become a normal (normal) state, then go to step 43; if the detection result is no, that is, when the failure recovery node is still in the protection (wrap) state, Then wait for a predetermined time (such as 1 to 3 seconds), and go to step 41 to continue testing;

In this step, if the point of failure is an RPR bridge device, then detect whether the working state of the point of failure changes from a protection state to a normal state, similarly, when the detection result is yes, go to step 43; when the detection result is no , wait for the predetermined time, and go to step 41 to continue testing;

Step 43: The fault recovery node sends a notification message on the two RPR bridge rings, and notifies the RPR cross-ring bridge device 1 and the RPR cross-ring bridge device 2 that the fault at the fault point 1 has returned to normal;

The notification message sent by the failure recovery node can be implemented by expanding the existing message, or by using a new message type;

Step 44: Record the current normal value of the maximum transmission unit (Maximum TransmissionUnit, MTU) of the failure recovery node; and set a predetermined value for the MTU value of the failure recovery node, preferably, the fixed value is between 30-81 value;

The purpose of this set MTU value is to ensure that protocol packets such as TP and TC can pass through the fault point 1, but data packets cannot pass through. Because the length of TP packets is 26 bytes and the length of TC packets is 29 bytes, the value of the MTU must be greater than or equal to 30 bytes, while the length of RPR packets containing extended data must be at least 18+64 bytes (Ethernet The minimum length of the network is 64 bytes) = 82 bytes, so the MTU value is required to be less than or equal to 81 bytes, and the MTU value can be set from 30 to 81 bytes. For example, it can be set to 64 bytes. When information is transmitted in the RPR bridge ring, since the data message cannot pass through the fault point after the MTU is modified to a predetermined value, a loop can be effectively avoided. the

Step 45: After the topology converges, restore the MTU value of the failure recovery node to the normal value of the MTU recorded in the previous step; further, the working state of the failure recovery node can be set to a normal state;

Step 47: The program ends. the

Similarly, for the fault point 2, the fault recovery nodes are RPR cross-ring bridge device 1 or RPR cross-ring bridge device 2 respectively. When the fault point 2 recovers, the fault recovery node can easily perceive that the fault point 2 has returned to normal , and can change its own working state according to it, so as to avoid loops. The process of changing its own state will be described in conjunction with Fig. 5 . the

When a cross-ring bridge device receives the notification message notifying that fault point 1 has recovered in the above step 43 of Figure 4, or when it detects that the fault of adjacent fault point 2 has recovered, the cross-ring bridge device The bridge device should carry out the corresponding data processing process according to its own working status and priority. The main purpose is to keep only one of the cross-ring bridge devices in the active state for cross-ring forwarding of data packets, and the other cross-ring bridge devices exit the active state and become standby state, data packets cannot be forwarded across rings, thereby avoiding the loop in FIG. 3 . The priority mentioned here refers to an attribute value set for each cross-ring bridge device in advance according to certain rules. The priority setting of the cross-ring bridge device can be configured according to the needs. ID number, IP address, MAC address, custom identifier or custom serial number, etc. the

The processing process of the cross-ring bridge equipment is described below in conjunction with flow chart 5:

Step 51: The cross-ring bridge device (such as cross-ring bridge device 1 or cross-ring bridge device 2) receives the notification message sent from the fault recovery node, or detects that the adjacent fault point has recovered;

Step 52: Judging whether its own working state is in the active state at this time, if it is not in the active state, then do not process the received notification message, and go to step 56; if it is in the active state, Then go to step 53;

Step 53: Whether the cross-ring bridge device has other cross-ring bridge devices connected to it in the active state on the RPR bridge ring, if not, the cross-ring bridge device still maintains the active state, and reports the received notification The text is not processed, and go to step 56; if there are other cross-ring bridge devices connected to it in active state, then go to step 54;

Step 54: Determine whether the priority of the cross-ring bridge device is lower than that of other cross-ring bridge devices connected to it in the active state, if the judgment result is no, the cross-ring bridge device still maintains the active state, And do not process the received notification message, and go to step 56, if the judgment result is yes, then go to step 55;

Step 55: The cross-ring bridge device exits the active state and is no longer responsible for the forwarding of cross-ring services;

Step 56: the process ends. the

In summary, the present invention sends a notification message to the cross-ring bridge device through the fault recovery node. After the cross-ring bridge device receives the notification message, the cross-ring bridge device 1 and the cross-ring bridge device 2 will both /priority and the working status/priority of other cross-ring bridge devices to perform subsequent actions (such as maintaining the active state or exiting the active state). In this way, after the failure point is recovered, only one cross-ring bridge device is still in the active state, ensuring the correct forwarding of cross-ring services, solving the loop problem in the information transmission after the fault point is restored, and the ring business is also It has no effect, and has no effect on the convergence of the single-ring protocol. the

The above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto, any changes or variations that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention Replacement should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (11)

1. the loop prevention method behind the RPR bridge fault recovery is characterized in that, said method comprising the steps of:

A. the fault recovery of the fault point in knowing the RPR bridged ring normal after, the maximum transmission unit value of fault recovery node is made as a predetermined value, and cross-ring bridge device sends the notice message that the fault that is used to notify this fault point has been recovered in described RPR bridged ring; Wherein, the predetermined value of described maximum transmission unit value is for passing through by the guarantee agreement message, and the intransitable value of data message, it is worth between 30 to 81 bytes; Described fault recovery node is the equipment contiguous with described fault point;

B. each the RPR cross-ring bridge device in the described RPR bridged ring receives the notice message that the fault recovery node is sent, and detects the operating state of RPR cross-ring bridge device separately, only makes one of them master remain the main state of using with the RPR cross-ring bridge device.

2. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 1 is characterized in that, described steps A also comprises:

Before the maximum transmission unit value of fault recovery node is set, write down the normal maximum transmission unit value of described fault recovery node.

3. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 2, it is characterized in that, after the fault recovery of the fault point in described steps A in the RPR bridged ring is normal, the maximum transmission unit value of fault recovery node is made as before the predetermined value, also comprises:

Trigger network topological convergence process;

After steps A, also comprise: after topological convergence, the maximum transmission unit value of described fault recovery node is reverted to the normal maximum transmission unit value that is write down.

4. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 1 is characterized in that: described steps A also comprises:

Maximum transmission unit value is made as after the described predetermined value, and the operating state of setting described fault recovery node is a normal condition.

5. as the loop prevention method behind each described RPR bridge fault recovery of claim 1 to 4, described step B also comprises:

Respectively be in the main priority of using the RPR cross-ring bridge device of state, make the RPR cross-ring bridge device of limit priority remain the main state of using.

6. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 4 is characterized in that, the fault of knowing the fault point in the RPR bridged ring in the described steps A has returned to normally and has been:

When described fault point is RPR bridge device in the described RPR bridged ring, self know that by described fault point its fault recovered normal;

When described fault point is link in the described RPR bridged ring, by knowing that with the contiguous described fault recovery node in described fault point the fault of described fault point recovered normal.

7. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 6 is characterized in that, the fault recovery node in the described RPR bridged ring is RPR bridge device or RPR cross-ring bridge device.

8. as the loop prevention method behind each described RPR bridge fault recovery of claim 1 to 4, it is characterized in that described notice message is a kind of message that expands realization on existing message basis, or a kind of message of redetermination.

9. as the loop prevention method behind each described RPR bridge fault recovery of claim 1 to 4, it is characterized in that, among the described step B, be stand-by state, then its received described notice message do not handled when a cross-ring bridge device detects self operating state.

10. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 5, it is characterized in that, among the described step B, be mainly use state when a cross-ring bridge device detects self operating state, but when not having connected other cross-ring bridge devices that are in main usefulness state; Be mainly use state perhaps, but its priority is not then handled its received described notice message when all being higher than the connected priority that is in main other cross-ring bridge devices with state when a cross-ring bridge device detects self operating state.

11. the loop prevention method behind the RPR bridge fault recovery as claimed in claim 5, it is characterized in that, among the described step B, when a cross-ring bridge device detects self operating state is the main state of using, and connected being in when having the higher cross-ring bridge device of priority in main other cross-ring bridge devices with state, the cross-ring bridge device that priority is low withdraws from the state of using of leading.

Images