Method and device for synchronizing information between switches

Abstract

The present invention provides a method and device for synchronizing information between switches. The present invention extends the existing BGP to automatically synchronize target data to be synchronized between switches in a SAN, such as IP service zone configuration information of an access device, and / or device discovery information of an access device, and / or information on whether a switch supports a default IP service zone, so that all switches in a SAN that need to be synchronized with each other can promptly sense changes between each other, such as a newly connected access device, newly added or changed IP service zone configuration information, and a switch that enables or disables the default IP service zone function, and timely and intelligently adjust related configurations, realizing plug-and-play and rapid fault detection, and finally helping to realize no packet loss and high throughput transmission of Ethernet in a SAN.

Description

[Technical field]

[0001] The present invention relates to the field of network communication technology, and more particularly to a method and apparatus for synchronizing information between switches applied to a storage area network (SAN). [Background technology]

[0002] In a SAN, a switch can be connected to a host (Initiator) and / or a storage device (Target) as the core of a network. Here, devices such as a host and / or a storage device connected to a switch are called access devices, and the switch is called an access switch.

[0003] Currently, the "NVMe over RoCEv2 Network Control Optimization Technical Requirements and Test Specifications" specifies the interaction process and message packets between access devices and switches, but does not specify how to synchronize information between switches. Here, NVMe stands for Non-Volatile Memory express, and RoCEv2 stands for RDMA (Remote Direct Memory Access) over Converged Ethernet version 2. However, in concrete implementation, it is necessary to synchronize information between switches. For example, when switch s1 is newly connected to storage device a1, host a2 connected to switch s2 needs to know that storage device a1 is online in order to exchange data with storage device a1. Based on this, when storage device a1 is online, switch s1 needs to timely synchronize the information that storage device a1 is online to switch s2, so that switch s2 can forward this information to host a2. However, currently, the network control optimization technical requirements and test specifications do not specify how to synchronize information between switches. Summary of the Invention [Problem to be solved by the invention]

[0004] The embodiments of the present invention provide an inter-switch information synchronization method and electronic device for realizing information synchronization between switches in a SAN. [Means for solving the problem]

[0005] An embodiment of the present invention provides an information synchronization method between switches applied to a storage area network (SAN), the method comprising: obtaining target data to be synchronized; and transmitting a BGP route to which the target data is added via a BGP session established with a specified switch, thereby synchronizing the target data between each target switch that needs to be synchronized with the specified switch.

[0006] An embodiment of the present invention further provides an electronic device, the electronic device including a processor and a machine-readable storage medium; the machine-readable storage medium stores machine-executable instructions executable by the processor; The processor is adapted to execute machine-executable instructions to perform the steps of the above-described methods. Effect of the Invention

[0007] As can be seen from the above technical solutions, in an embodiment of the present invention, target data to be synchronized between switches in a SAN is automatically synchronized, such as IP service zone configuration information of an access device, and / or device discovery information of an access device, and / or information on whether a switch supports a default IP service zone, so that all switches in a SAN that need to be synchronized with each other can promptly sense each other's changes, such as newly connected access devices, newly added or changed IP service zone configuration information, and switches that enable or disable the default IP service zone function, and quickly adjust related configurations, thereby realizing plug-and-play and rapid fault detection, and ultimately helping to realize zero packet loss and high throughput transmission of Ethernet in a SAN.

[0008] Furthermore, in an embodiment of the present invention, by extending the existing BGP and synchronizing switches in a SAN in the form of BGP routes, changes to the SAN are minimal, which is advantageous in achieving interoperability and standardization between vendors. [Brief description of the drawings]

[0009] The accompanying drawings described herein, which are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present invention and, together with the description, serve to explain the principles of the invention.

[0010] [Figure 1] 2 is a flow chart of a method provided by an embodiment of the present invention. [Diagram 2] 1 is a schematic diagram of a SAN provided by an embodiment of the present invention. [Diagram 3] FIG. 2 is a schematic diagram of a first networking provided by an embodiment of the present invention; [Figure 4] FIG. 2 is a schematic diagram of a second networking provided by an embodiment of the present invention; [Diagram 5] FIG. 4 is a schematic diagram of a third networking provided by an embodiment of the present invention. [Figure 6] FIG. 4 is a schematic diagram of a fourth networking provided by an embodiment of the present invention. [Figure 7] FIG. 5 is a schematic diagram of a fifth networking provided by an embodiment of the present invention. [Figure 8] FIG. 11 is a schematic diagram of a sixth networking provided by an embodiment of the present invention. [Figure 9] FIG. 2 is a schematic diagram of IP service zone configuration information provided by an embodiment of the present invention; [Figure 10] 4 is a schematic diagram of device discovery information of an access device provided by an embodiment of the present invention; [Figure 11] 2 is a schematic diagram of default IP service zone information provided by an embodiment of the present invention; [Figure 12] FIG. 2 is a schematic diagram of example networking provided by an embodiment of the present invention. [Figure 13] FIG. 2 is a structural diagram of an apparatus provided according to an embodiment of the present invention; [Figure 14] 1 is a structural diagram of an electronic device provided by an embodiment of the present invention; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] In this specification, the examples shown in the accompanying drawings are described in detail. When the following description refers to the accompanying drawings, like numerals in different drawings refer to the same or similar elements unless otherwise specified. The embodiments described in the following examples do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present invention, as detailed in the appended claims.

[0012] The terms used in the present invention are intended to describe specific embodiments and are not intended to limit the present invention. The singular forms "a," "the," and "the" used in the embodiments of the present invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0013] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present invention, and to more easily comprehend the above-mentioned objectives, features and advantages of the embodiments of the present invention, the following provides a more detailed description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings.

[0014] FIG. 1 is a flow chart of a method provided by an embodiment of the present invention. In the embodiment, the method is applied to a switch in a SAN. Optionally, the method is applied to any switch in an NVMe over RoCEv2 network in a SAN as shown in FIG. 2. Here, the NVMe over RoCEv2 network is implemented based on the UDP layer of the Ethernet TCP / IP protocol. For ease of explanation, the switch to which the method shown in FIG. 1 is applied is referred to as one of the switches shown in FIG. 2, i.e., switch 201.

[0015] As shown in FIG. 1, the method may include the following steps.

[0016] In step 101, the switch 201 obtains the target data to be synchronized.

[0017] In a SAN, the data to be synchronized may be IP service zone configuration information of an access device in the SAN, and / or device discovery information of the access device, and / or information on whether the switch 201 supports a default IP service zone.

[0018] For example, when IP service zone configuration information corresponding to at least one self-defined IP service zone is added from outside to the switch 201, or when IP service zone configuration information corresponding to at least one self-defined IP service zone added to the switch 201 is changed, the newly added IP service zone configuration information or the changed IP service zone configuration information needs to be synchronized with each target switch (for example, the switch 202 to the switch n shown in FIG. 2) in the SAN that needs to be synchronized with the switch 210. At this time, the newly added IP service zone configuration information or the changed IP service zone configuration information may be determined as the target data to be synchronized. Note that the specific content of the IP service zone configuration information is not particularly limited in this embodiment, and will be described below with an example, and a detailed description will be omitted here.

[0019] As another example, in this embodiment, when the switch 201 is newly connected to an access device such as a host and / or a storage device, the newly connected access device transmits an access message to the switch 201. The access message may be, for example, a Link Layer Discovery Protocol (LLDP) packet. The switch 201 adds new device discovery information of the newly locally connected access device based on the access message such as the LLDP packet. The switch 201 needs to synchronize the device discovery information with each target switch in the SAN that needs to be synchronized with the switch 210, and at this time, the device discovery information may be determined as the target data to be synchronized. Note that the specific content of the device discovery information is not particularly limited in this embodiment, and will be described below with an example, and detailed description will be omitted here.

[0020] As another example, in this embodiment, when the switch 201 enables or disables the default IP service zone function, the switch 201 needs to synchronize information on enabling or disabling the default IP service zone function with each target switch in the SAN that needs to be synchronized with the switch 210, and at this time, the information on the switch 201 enabling or disabling the default IP service zone function (i.e., information on whether the switch 201 supports the default IP service zone) may be determined as the target data to be synchronized. Note that the specific content of the information on whether the switch 201 supports the default IP service zone is not particularly limited in this embodiment, and will be described below with an example, with detailed description omitted here.

[0021] The above is merely an example for explaining a method for determining target data to be synchronized, and the above-described example for determining target data to be synchronized may or may not appear simultaneously, and this embodiment is not particularly limited. Also, in this embodiment, the specific content of the target data is merely an example and is not intended to be limited. In this embodiment, it may be set according to the needs of actual services in the SAN. In this embodiment, the focus is only on the fact that the target data to be synchronized is data that needs to be synchronized between switches in the SAN, and the specific format and content of the target data to be synchronized are not particularly limited.

[0022] In S102, the switch 201 transmits a BGP (Border Gateway Protocol) route to which the target data is added via a BGP session established with the designated switch, thereby synchronizing the target data between the switch 201 and each target switch that needs to be synchronized.

[0023] BGP does not support data to be synchronized between switches in a SAN, such as the above IP service zone configuration information, device discovery information of an access device, and information on whether the switch 201 supports a default IP service zone. In this embodiment, the existing BGP is extended so that the extended BGP supports data to be synchronized between switches in a SAN. The switch 201 may generate a BGP route (also called an extended BGP route) to which target data is added, based on the extended BGP.

[0024] Thereafter, as described in step 102, the switch 201 transmits the BGP route to which the target data is added via the BGP session established with the designated switch, thereby synchronizing the target data between the switch 201 and each target switch that needs to be synchronized. Finally, the data that needs to be synchronized between the switches in this embodiment is realized using the extended BGP route.

[0025] The switch designated in step 102 may be at least one of the target switches, or may be at least one of the non-target switches other than all of the target switches. This embodiment is not particularly limited, and will be described below by way of an example, and detailed description will be omitted here.

[0026] The BGP session in step 102 may be an Internal Border Gateway Protocol (IBGP) session or an External Border Gateway Protocol (EBGP) session. An example will be given below, and a detailed description will be omitted here.

[0027] Up to this point, the flow shown in FIG. 1 is completed.

[0028] According to the flow shown in FIG. 1, target data to be synchronized between switches in a SAN, such as IP service zone configuration information of an access device, and / or device discovery information of an access device, and / or information on whether a switch supports a default IP service zone, can be automatically synchronized. In this way, all switches in a SAN that need to be synchronized with each other can promptly sense each other's changes, such as a newly connected access device, newly added or changed IP service zone configuration information, and a switch that enables or disables the default IP service zone function, and can timely and intelligently adjust related configurations, thereby realizing plug-and-play and rapid fault detection, and ultimately helping to realize no packet loss and high throughput transmission of Ethernet in a SAN.

[0029] Furthermore, in this embodiment, by extending the existing BGP and synchronizing the switches in the SAN in the form of BGP routes, there are fewer changes to the SAN, which is advantageous for realizing interoperability and standardization between vendors.

[0030] Below, we will first use networking as an example to explain the above step 102, i.e., switch 201 sends a BGP route with the target data attached via a BGP session established with the specified switch, and synchronizes the target data between switch 201 and each target switch that needs to be synchronized.

[0031] Example 1: Figure 3 is a schematic diagram of a first networking provided by an embodiment of the present invention. The networking shown in Figure 3 is relatively simple. As shown in Figure 3, assuming that the target switches that need to be synchronized with switch 201 are switches 202 to 204, IBGP sessions are established between each pair of switches 201 to 204.

[0032] Based on this, in the above step S102, the switch 201 transmitting the BGP route to which the target data has been added via the BGP session established with the designated switch may include the switch 201 transmitting the BGP route to which the target data has been added via the BGP sessions established with each of the switches 202 to 204. Finally, synchronization of the target data is realized among the switches 202 to 204 that need to be synchronized with the switch 201.

[0033] Optionally, in this embodiment, an IBGP session may be established between any two switches to transmit BGP routes, and preferably, a switch may prohibit forwarding of received BGP routes according to IBGP characteristics to avoid the same BGP route being repeatedly transmitted within the SAN.

[0034] Up to this point, the description of the first embodiment is complete.

[0035] Second Embodiment: In this embodiment, one of the switch 201 and the target switches that need to be synchronized with the switch 201 may be a reflector, and the rest may be clients of the reflector. FIG. 4 is a schematic diagram of a second networking provided by an embodiment of the present invention. As shown in FIG. 4, the target switches that need to be synchronized with the switch 201 are the switches 202 to 204, respectively. In this embodiment, one of the switches 201 to 204 may be a reflector, and the remaining switches may be clients.

[0036] In this embodiment, an IBGP session is established between the reflector and each client, and an IBGP session is not established between the clients. The reflector forwards the generated or received BGP route to each client via the IBGP session established with each client, but the client does not forward the received BGP route after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector via the IBGP session established with the reflector, and the reflector forwards the received BGP route to other clients.

[0037] In the case where the switch 201 is a reflector and the switches 202 to 204 are clients, in this embodiment, an IBGP session is established between the switch 201 as a reflector and each client. An IBGP session is not established between the switches 202 to 204 as clients. Based on this, in the above step S102, the switch 201 transmits the BGP route to which the target data is added via the BGP session established with the designated switch, which may include the switch 201 as a reflector transmitting the BGP route to which the target data is added to each client via the IBGP session established with each client. Finally, the synchronization of the target data is realized between the switches 202 to 204 that need to be synchronized with the switch 201. Here, after receiving the BGP route to which the target data is added transmitted from the switch 201 as a reflector, the switches 202 to 204 as clients do not forward the received BGP route in order to avoid the same BGP route being repeatedly transmitted within the SAN.

[0038] Furthermore, in the case where the switch 202 is a reflector (similar to the switch 203 and the switch 204 being reflectors) and the switches 201, 203 and 204 are clients, in this embodiment, in the above step S102, the switch 201 transmits the BGP route to which the target data is added via the BGP session established with the designated switch, which may include the switch 201, which is a client, transmitting the BGP route to which the target data is added to the switch 202, which is a reflector, via the IBGP session established with the switch 202, which is a reflector, and then the switch 202 receives the BGP route to which the target data is added, and then forwarding the received BGP route to the switch 203 via the IBGP session established with the switch 203, and forwarding the received BGP route to the switch 204 via the IBGP session established with the switch 204. Finally, synchronization of the target data is realized between the switches 202 to 204 that need to be synchronized with the switch 201. After receiving the BGP route with the above target data added from switch 202, which is a reflector, client switches 203 and 204 do not forward the received BGP route to avoid the same BGP route being repeatedly sent within the SAN.

[0039] Up to this point, the description of the second embodiment is complete.

[0040] Example 3: In this example, one asymmetric switch other than the switch 201 and each of the target switches that need to be synchronized with the switch 201 may be a reflector, and the switch 201 and each of the target switches that need to be synchronized with the switch 201 may be a client of the reflector. As an example, the asymmetric switch here may be a non-access switch, that is, a switch that is not connected to an access device such as a host or a storage device.

[0041] 5 is a schematic diagram of a third networking provided by an embodiment of the present invention. As shown in FIG. 5, target switches that need to be synchronized with switch 201 are switches 202 to 204, respectively. In this embodiment, one non-access switch (switch 205) may be a reflector, and switches 201 to 204 may be clients.

[0042] In this embodiment, an IBGP session is established between the reflector and each client, and an IBGP session is not established between the clients. The reflector forwards the generated or received BGP route to each client via the IBGP session established with each client, but the client does not forward the received BGP route after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector via the IBGP session established with the reflector, and the reflector forwards the received BGP route to other clients.

[0043] In the present embodiment, when the switch 205 is a reflector and the switches 201 to 204 are clients, in the above step S102, the switch 201 transmits the BGP route to which the target data is added via the BGP session established with the designated switch, which may include the switch 201 transmitting the BGP route to which the target data is added to the switch 205, which is a reflector, via the IBGP session established with the switch 205, which is a reflector, and then the switch 205 receives the BGP route to which the target data is added, and then forwarding the received BGP route to the switch 202 via the IBGP session established with the switch 202, forwarding the received BGP route to the switch 203 via the IBGP session established with the switch 203, and forwarding the received BGP route to the switch 204 via the IBGP session established with the switch 204. Finally, synchronization of the target data is realized between the switches 202 to 204 that need to be synchronized with the switch 201. After receiving the BGP route with the above target data added thereto from switch 205, which is a reflector, client switches 202 to 204 do not forward the received BGP route in order to avoid the same BGP route being repeatedly sent within the SAN.

[0044] Up to this point, the description of the third embodiment is complete.

[0045] Fourth embodiment: In this embodiment, two or more of the switch 201 and the target switches that need to be synchronized with the switch 201 may be set as reflectors, and the remaining may be set as clients of the reflectors. FIG. 6 is a schematic diagram of a fourth networking provided by an embodiment of the present invention. As shown in FIG. 6, the target switches that need to be synchronized with the switch 201 are respectively the switches 202 to 204. In this embodiment, two or more of the switches 201 to 204 may be set as reflectors, and the remaining switches may be set as clients.

[0046] In this embodiment, an IBGP session is established between reflectors, an IBGP session is established between the reflector and a client, and an IBGP session is not established between clients. The reflector forwards the generated or received BGP route to each client through the IBGP session established with each client, but the client does not forward the received BGP route after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector through the IBGP session established with the reflector, and the reflector forwards the received BGP route to other clients.

[0047] In the present embodiment, when the switches 201 and 204 are reflectors and the switches 202 and 203 are clients, an IBGP session is established between the switches 201 and 204, and an IBGP session is established between each of the switches 201 and 204 and each of the clients. An IBGP session is not established between the switches 202 and 203.

[0048] Based on this, in the above step S102, the switch 201 transmits the BGP route to which the target data is added via the BGP session established with the designated switch, which may include the switch 201, which is a reflector, transmitting the BGP route to which the target data is added to the switch 204, which is a reflector, via the IBGP session established with the switch 204, which is a reflector, and the switch 201, which is a reflector, transmitting the BGP route to which the target data is added to each client via the IBGP session established with each client. Finally, synchronization of the target data is realized between the switches 202 to 204 that need to be synchronized with the switch 201. After receiving the BGP route to which the target data is added transmitted from the switch 201, which is a reflector, the switches 202 and 203, which are clients, do not forward the received BGP route in order to avoid the same BGP route being repeatedly transmitted within the SAN.

[0049] Optionally, in this embodiment, when switch 204, which is a reflector, receives a BGP route to which the above-mentioned target data is added, in order to realize a redundant backup, switch 204 transmits the BGP route to which the target data is added to each client via the IBGP session established with each client, so that after switch 202 and switch 203, which are clients, receive the same BGP route, i.e., the BGP route to which the above-mentioned target data is added, via different BGP sessions, switch 204 may determine the BGP route received by one BGP session as the optimal route and back up and record the BGP route received by the other BGP session.

[0050] If a failure subsequently occurs in switch 201, which is a reflector, and the IBGP session between switch 201 and switch 203, which is a client, is disconnected, switch 203 deletes all routes sent from switch 201. At this time, switch 203 has recorded therein the same route as the route sent from switch 204, which is a reflector, and therefore switch 203 communicates using the recorded BGP route, thereby improving the reliability of communication.

[0051] Furthermore, in the case where the switches 202 and 204 are reflectors and the switches 201 and 203 are clients, in this embodiment, an IBGP session is established between the switches 202 and 204, and an IBGP session is established between each of the switches 202 and 204 and each client. An IBGP session is not established between the switches 201 and 203. Based on this, in the above step S102, the switch 201 transmits the BGP route to which the target data is added via the BGP session established with the specified switch, which may include steps 601 to 602.

[0052] In step 601, switch 201, which is a client, transmits a BGP route to which the target data has been added via an IBGP session established with switch 202, which is a reflector. When switch 202 receives the BGP route to which the target data has been added, it transmits the BGP route to which the target data has been added to another client, i.e., switch 203, via an IBGP session established with the other client.

[0053] In step 602, switch 201, which is a client, transmits a BGP route to which the target data has been added via an IBGP session established with switch 204, which is a reflector. When switch 204 receives the BGP route to which the target data has been added, it transmits the BGP route to which the target data has been added to another client, i.e., switch 203, via an IBGP session established with the other client.

[0054] Finally, synchronization of the target data is achieved among switches 202 to 204 that need to be synchronized with switch 201.

[0055] As described above, the switch 203, which is a client, finally receives the same BGP route, i.e., the BGP route to which the target data is added, through a different BGP session. After the switch 203, which is a client, receives the same BGP route, i.e., the BGP route to which the target data is added, through a different BGP session, it determines the BGP route received through one BGP session as the optimal route, and backs up and records the BGP route received through the other BGP session. If a failure occurs in the switch 202, which is a reflector, and the IBGP session between the switch 203, which is a client, and the switch 202 is disconnected, the switch 203 deletes all routes transmitted from the switch 202. At this time, the switch 203 has the same route recorded as the route transmitted from the switch 204, which is a reflector, recorded in it, so that the switch 203 communicates using the recorded BGP route, thereby improving the reliability of communication.

[0056] In this embodiment, after a client receives a BGP route with the above target data added and sent from a reflector, the client does not forward the received BGP route to avoid the same BGP route being sent repeatedly within the SAN.

[0057] Up to this point, the description of the fourth embodiment is complete.

[0058] Embodiment 5: In this embodiment, two or more asymmetric switches other than the switch 201 and each of the target switches that need to be synchronized with the switch 201 may be set as reflectors, and the switch 201 and each of the target switches that need to be synchronized with the switch 201 may be set as clients of the reflector. As an example, the asymmetric switches here may be non-access switches, that is, switches that are not connected to access devices such as hosts and storage devices.

[0059] Fig. 7 is a schematic diagram of a fifth networking provided by an embodiment of the present invention. As shown in Fig. 7, target switches that need to be synchronized with switch 201 are switches 202 to 204, respectively. In this embodiment, two non-access switches (switch 205 and switch 206) may be reflectors, and switches 201 to 204 may be clients.

[0060] In this embodiment, an IBGP session is established between the reflector and each client, and an IBGP session is not established between the reflectors or between the clients. The reflector forwards the generated or received BGP route to each client via the IBGP session established with each client, but the client does not forward the received BGP route after receiving the BGP route from the reflector. After generating a BGP route, the client sends the BGP route to the reflector via the IBGP session established with the reflector, and the reflector forwards the received BGP route to other clients.

[0061] In the case where switches 205 and 206 shown in FIG. 7 are reflectors and switches 201 to 204 are clients, in this embodiment, in the above step S102, switch 201 transmits a BGP route to which the target data is added via a BGP session established with the specified switch, which may include steps 701 to 702.

[0062] In step 701, switch 201 transmits the BGP route with the target data added to switch 205, which is a reflector, via the IBGP session established with switch 205, which is a reflector. After switch 205 receives the BGP route with the target data added, switch 205 forwards the received BGP route to each client other than switch 201, i.e., switches 202 to 204, via the IBGP sessions established with each client.

[0063] In step 702, switch 201 transmits the BGP route with the target data added to switch 206, which is a reflector, via the IBGP session established with switch 206. After switch 206 receives the BGP route with the target data added, switch 206 forwards the received BGP route to each client other than switch 201, i.e., switches 202 to 204, via the IBGP sessions established with each client.

[0064] Finally, steps 701 and 702 above achieve synchronization of the target data among switches 202 to 204 that need to be synchronized with switch 201. In this embodiment, after receiving the BGP route to which the target data is added and transmitted from switch 205 or switch 206, which is a reflector, switches 202 to 204 do not forward the received BGP route in order to prevent the same BGP route from being repeatedly transmitted within the SAN.

[0065] In this embodiment, as in the fourth embodiment, the switches 202 to 204, which are clients, finally receive the same BGP route, i.e., the BGP route to which the target data is added, through different BGP sessions. After the switches 202 to 204, which are clients, receive the same BGP route, i.e., the BGP route to which the target data is added, through different BGP sessions, the BGP route received through one BGP session is determined as the optimal route, and the BGP route received through the other BGP session is backed up and recorded, thereby realizing a redundant backup and improving reliability. For example, assuming that a failure occurs in the switch 205, which is a reflector, and the IBGP session between the switch 203 and the switch 205, which are clients, is disconnected, the switch 203 deletes all routes transmitted from the switch 205, but at this time, the same route as the route transmitted from the switch 206, which is a reflector, is recorded in the switch 203, so the switch 203 communicates using the recorded BGP route, thereby improving the reliability of communication.

[0066] Up to this point, the description of the fifth embodiment is complete.

[0067] Example 6: This example takes an EBGP session as an example. As shown in Fig. 8, in this example, each target switch that needs to be synchronized with the switch 201 may be the switch 202 to the switch 204, and an EBGP session may be established between the switch 201 and the switch 202, an EBGP session may be established between the switch 201 and the switch 204, and an EBGP session may be established between the switch 202 and the switch 203. Based on this, in the above step S102, the switch 201 may transmit the BGP route to which the target data is added via the BGP session established with the designated switch, which may include steps 801 to 802.

[0068] In step 801, switch 201 sends the BGP route with the target data added to switch 202 via the EBGP session established with switch 202, so that switch 202 receives the BGP route with the target data added, and then forwards the received BGP route to switch 203 via the EBGP session established with switch 203.

[0069] In step 802 , the switch 201 transmits the BGP route to which the target data has been added to the switch 204 via the EBGP session established between the switch 201 and the switch 204 .

[0070] Finally, by performing steps 801 and 802, synchronization of the target data between switches 202 and 204 that need to be synchronized with switch 201 is achieved.

[0071] Up to this point, the description of the sixth embodiment is complete.

[0072] In this embodiment, it is only necessary to ensure that information is synchronized between switches according to the extended BGP, and the specific networking form is not particularly limited. The networking illustrated in the above embodiments 1 to 6 is merely an example and is not intended to be limiting.

[0073] The BGP route in step 202 above will now be described.

[0074] In this embodiment, the BGP route is added to the Multi-Protocol Reachable NLRI (MP_REACH_NLRI) attribute of the BGP Update packet.

[0075] As an example, the MP_REACH_NLRI attribute may include at least an Address Family Identifier (AFI) and a Subsequent Address Family Identifier (SAFI).

[0076] Here, the AFI in this embodiment may be different from the predefined AFI value, for example, the AFI is 6000 in this embodiment.

[0077] Here, the SAFI in this embodiment may be different from the predefined SAFI value, for example, the SAFI is 254 in this embodiment.

[0078] Optionally, in this embodiment, the BGP route is specifically added to the NLRI of the MP_REACH_NLRI attribute. As described above, the target data added to the BGP route includes at least the IP service zone configuration information of the access device, and / or the device discovery information of the access device, and / or information on whether the switch 201 supports a default IP service zone.

[0079] Optionally, as shown in Fig. 9, the IP service zone configuration information includes at least the BGP route identifier (Route ID) of the switch 201, the IP service zone identifier (Zone Name), and the IP address (IP Address) of the access device to which the IP service zone configuration information belongs. Here, the IP service zone identifier is an identifier of a self-defined IP service zone, which is different from the default IP service zone. In this embodiment, the IP address may be an IPv4 address or an IPv6 address, and is not particularly limited.

[0080] Optionally, as shown in Fig. 10, the device discovery information of the access device includes at least a MAC address of the access device, a port identifier (Port Name) of a port of the access device connected to the switch 201, and a BGP route identifier (Route ID) of the switch 201. Optionally, the device discovery information of the access device shown in Fig. 10 may also include a length of the Port Name (denoted as the Port Identifier Length).

[0081] In this embodiment, the device discovery information of the access device further includes device attribute information of the access device.

[0082] Optionally, the device attribute information of the access device at least includes an IP address (IPv4 address or IPv6 address) of the access device, status information of the access device (including at least online information or offline information), and a role type of the access device (including at least a storage system and / or a host). In this embodiment, the IP address of the access device, the status information of the access device, and the role type of the access device may each be represented by a TLV, and are not limited here.

[0083] Optionally, in one example, when determining whether the current BGP route and the previously received BGP route are the same route, it may be determined directly by the MAC address of the access device, the port identifier of the access device's port connected to switch 201, and the BGP route identifier of switch 201. Thus, as one example, the MAC address of the access device, the port identifier of the access device's port connected to switch 201, and the BGP route identifier of switch 201 are considered to be part of the prefix of the NLRI.

[0084] In this embodiment, the information on whether the switch 201 supports the default IP service zone is at least: A BGP route identifier (Route ID) for the switch 201; or The BGP route identifier (Route ID) and enable indication value (Enable) of the switch 201 are included. Here, when the enable indication value is a first value, it indicates that the switch 201 supports a default IP service zone, and when the enable indication value is a second value, it indicates that the switch does not support a default IP service zone. In this embodiment, the BGP route identifier and the enable indication value may be expressed by a TLV. FIG. 11 shows the BGP route identifier and the enable indication value of the switch 201.

[0085] The above is an example in which the switch 202 actively transmits a BGP route. Optionally, in this embodiment, the switch 202 may receive a BGP route transmitted from another switch via a BGP session such as an IBGP session or an EBGP session, and locally add or update a corresponding route configuration information entry based on the received BGP route. The route configuration information entry is related to data to be synchronized that is added to the received BGP route. For example, if the data to be synchronized is newly added IP service zone configuration information, the route configuration information entry here may include the newly added IP service zone configuration information, etc.

[0086] Optionally, as described above, in this embodiment, the switch 202 may receive BGP routes with the same data to be synchronized via different BGP sessions and determine the optimal route according to a route priority scheme.

[0087] The route cancellation provided by the embodiment of the present invention will now be described.

[0088] In this embodiment, the switch 201 is taken as an example for explanation, and the switch 201 also needs to cancel at least one stored BGP route. For example, when a host or storage device connected to the switch 201 goes offline, the BGP route corresponding to the offline host or storage device needs to be canceled. That is, at this time, the switch 201 judges that it is necessary to cancel at least one stored BGP route. When the switch 201 judges that it is necessary to cancel at least one stored BGP route, it first deletes the stored at least one BGP route that needs to be canceled, and sends a notification via a BGP session to instruct each of the above target switches to delete the at least one BGP route that needs to be canceled and the route configuration information entry corresponding to the at least one BGP route.

[0089] Similarly, when the switch 201 receives at least one BGP route to be withdrawn via a BGP session, it deletes the stored at least one BGP route and the route configuration information entry corresponding to the at least one BGP route.

[0090] Optionally, in this embodiment, at least one BGP route that needs to be withdrawn is added to the Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) attribute of the BGP Update packet, where the AFI and SAFI in the MP_UNREACH_NLRI attribute refer to the description of the MP_REACH_NLRI attribute above.

[0091] The methods provided by the embodiments of the present invention have been described above. The methods will now be further illustrated by the following specific examples.

[0092] FIG. 12 is a schematic diagram of networking of an embodiment provided by an embodiment of the present invention. In FIG. 12, switch 1201 and switch 1202 are configured as reflectors and configured with the same Cluster ID. Switch 1203 and switch 1204 are configured as clients of the reflector. Switches 1201 to 1204 are configured in the same AS and are IBGP peers with each other. Based on the description of the above embodiment 4, in FIG. 12, BGP sessions are established between switch 1201 and switch 1202, between switch 1201 and switch 1203, between switch 1201 and switch 1204, between switch 1202 and switch 1203, and between switch 1202 and switch 1204.

[0093] When the IP service zone configuration of host B is added to switch 1201, switch 1201 acquires the newly added IP service zone configuration, and generates and records a BGP route to which the IP service zone configuration is added. After that, switch 1201 transmits the BGP route via the BGP sessions established with switches 1202, 1203, and 1204. Switches 1202 to 1204 receive, record, and analyze the BGP route, and newly add an IP service zone configuration entry for the remote end, i.e., host B, locally.

[0094] If the IP service zone configuration of host B already recorded in switch 1201 needs to be changed, switch 1201 updates the existing corresponding BGP route. Then, switch 1201 transmits the updated BGP route via the BGP sessions established with switches 1202, 1203, and 1204. Switches 1202 to 1204 receive, record, and analyze the updated BGP route, and update the IP service zone configuration entry of the remote end recorded locally. The updated IP service zone configuration entry is the same as the changed IP service zone configuration entry described above.

[0095] When it is necessary to delete the IP service zone configuration of host B already recorded in switch 1201, switch 1201 cancels the existing corresponding BGP route. Then, switch 1201 transmits the BGP route withdrawal notification via the BGP sessions established with switches 1202, 1203, and 1204. When switches 1202 to 1204 receive the BGP route withdrawal notification, they delete the recorded corresponding BGP route and the recorded IP service zone configuration entry of the corresponding remote end (i.e., host B).

[0096] In this embodiment, when it is necessary to change the IP service zone configuration of host B already recorded in switch 1201, as described above, according to the method of deleting the IP service zone configuration of host B already recorded in switch 1201, first cancel the existing corresponding BGP route, then send a BGP route cancellation notice to switches 1202 to 1204 to instruct switches 1202 to 1204 to delete the recorded corresponding BGP route and the recorded corresponding IP service zone configuration entry of the remote end (i.e., host B). After that, the operation of adding the IP service zone configuration of host B to switch 1201 is performed. How to specifically perform this mainly depends on whether the changed IP service zone configuration is an important feature such as a feature parameter for determining whether the BGP route is the same route as another route (the feature parameter here may be the above IP service zone configuration information or other self-defined parameters, etc., and this embodiment is not particularly limited). If the changed IP service zone configuration is an important feature, first cancel the existing corresponding BGP route, and then add the IP service zone configuration of host B to switch 1201 to realize the update. If the changed IP service zone configuration is not a critical feature, then we directly update and send the existing corresponding BGP routes as described above.

[0097] When the switch 1204 is newly connected to an access device such as a host or a storage device, the newly connected access device first transmits an LLDP packet to the switch 1204 after it becomes online, and the switch 1204 adds new device discovery information of the newly connected access device locally, and generates and records a corresponding BGP route. Then, the switch 1204, which is a client, transmits the BGP route to the switch 1201 through a BGP session established with the switch 1201, which is a reflector. The switch 1204, which is a client, transmits the BGP route to the switch 1202 through a BGP session established with the switch 1202, which is a reflector. The switch 1201, which is a reflector, reflects the received BGP route to the switch 1203 through a BGP session established with the switch 1203, which is a client. The switch 1202, which is a reflector, reflects the received BGP route to the switch 1203 through a BGP session established with the switch 1203, which is a client. Switch 1203 receives the two same routes reflected from switch 1201 and switch 1202, and selects the optimal route according to the BGP protocol specifications and actual implementation.

[0098] Furthermore, regardless of whether the optimal route is the BGP route reflected from switch 1201 or switch 1202, the route information (also called data to be synchronized) attached to the BGP routes reflected from switch 1201 and switch 1202 is the same, so switch 1203 can analyze the device discovery information of the access device newly connected to switch 1204 from the route information.

[0099] Based on this, if the optimal route is the BGP route reflected from switch 1201, when switch 1201 fails, the BGP session between switch 1203 and switch 1201 will be disconnected, and switch 1203 will delete all routes sent from switch 1201, but at this time switch 1203 still holds the same route sent from switch 1202, so switch 1203 has the BGP route generated by switch 1204. Therefore, by deploying two reflectors, switch 1201 and switch 1202 at the same time, it can play the role of redundant backup and improve reliability.

[0100] If the device discovery information of an access device, such as a host or storage device, connected to the switch 1204 changes, the access device notifies the switch 1204 by sending an LLDP packet, and the switch 1204 updates the device discovery information of the locally connected access devices and the corresponding recorded BGP routes.

[0101] Thereafter, switch 1204, which is a client, transmits the updated BGP route to switch 1201 via the BGP session established with switch 1201, which is a reflector. Switch 1204, which is a client, transmits the updated BGP route to switch 1202 via the BGP session established with switch 1202, which is a reflector.

[0102] The switch 1201, which is a reflector, reflects a received BGP route to the switch 1203, which is a client, via a BGP session established with the switch 1203, which is a client.

[0103] The switch 1202, which is a reflector, reflects the received BGP route to the switch 1203, which is a client, via a BGP session established with the switch 1203, which is a client.

[0104] Finally, switch 1203 receives the two same routes reflected from switch 1201 and switch 1202, and selects the optimal route according to the BGP protocol specification and actual implementation. Note that the change in the device discovery information of the access device is similar to the change in the above IP service zone configuration, so further explanation is omitted.

[0105] When an access device such as a host or a storage device connected to switch 1204 goes offline, switch 1204 revokes the existing BGP route when it discovers that the corresponding device has gone offline (e.g., LLDP has aged, the connection has been cut, etc.). Then, switch 1204, which is a client, sends a route withdrawal notification to switch 1201, which is a reflector, via the BGP session established with switch 1201. Switch 1204, which is a client, sends a route withdrawal notification to switch 1202, which is a reflector, via the BGP session established with switch 1202.

[0106] The switch 1201, which is a reflector, reflects the route withdrawal notification to the switch 1203, which is a client, via a BGP session established with the switch 1203.

[0107] The switch 1202, which is a reflector, reflects the route withdrawal notification to the switch 1203, which is a client, via a BGP session established with the switch 1203.

[0108] Finally, after receiving the route withdrawal notice reflected from switch 1201 and switch 1202, switch 1203 deletes the corresponding BGP route and changes the device state information corresponding to the BGP route to offline.

[0109] The above explanation only takes the IP service zone configuration and device discovery information as examples, and other situations can be inferred, so explanations are omitted here.

[0110] An apparatus provided according to an embodiment of the present invention will now be described.

[0111] FIG. 13 is a structural diagram of an apparatus provided by an embodiment of the present invention. The apparatus is applied to a switch in a SAN. As shown in FIG. 13, the apparatus includes: an acquisition unit used for acquiring target data to be synchronized; and a route unit used to transmit a BGP route having the target data attached thereto via a BGP session established with a designated switch, thereby synchronizing the target data between each target switch that needs to be synchronized with the switch.

[0112] Optionally, the above target data may include at least: The IP service zone configuration information of the access device, and / or the device discovery information of the access device, and / or information on whether the switch supports a default IP service zone.

[0113] Optionally, the IP service zone configuration information includes at least: The IP service zone configuration information includes a BGP route identifier (Route ID) of the switch, an IP service zone identifier, and an IP address of an access device to which the IP service zone configuration information belongs, and the IP service zone identifier is an identifier of a self-defined IP service zone and is different from a default IP service zone.

[0114] Optionally, the device discovery information of said access device comprises at least: The MAC address of the access device, the port identifier of the port of the access device connected to the switch, and the BGP route identifier (Route ID) of the switch.

[0115] Optionally, the device discovery information of the access device further comprises device attribute information of the access device; The device attribute information of the access device includes at least an IP address of the access device, status information of the access device, and a role type of the access device; the IP address is an IPv4 address or an IPv6 address, The status information includes at least online information or offline information; The role types include at least a storage system and / or a host.

[0116] Optionally, information on whether the switch supports a default IP service zone or not is provided at least: A BGP route identifier (Route ID) of the switch; or The switch's BGP route identifier (Route ID) and enable indication value are included; When the enable indication value is a first value, it indicates that the switch supports a default IP service zone, and when the enable indication value is a second value, it indicates that the switch does not support a default IP service zone.

[0117] Optionally, the specified switch is at least one of the target switches; or The designated switch is at least one non-targeted switch other than the switch and the target switch.

[0118] In this embodiment, the route unit is further used to locally add or update a corresponding route configuration information entry when receiving a BGP route sent from another switch through a BGP session established with the specified switch, according to the received BGP route, where the route configuration information entry is related to the data to be synchronized that is added to the received BGP route.

[0119] In this embodiment, the route unit is further used to determine the optimal route according to the route preference scheme when receiving BGP routes with the same data to be synchronized via different BGP sessions.

[0120] In this embodiment, the route unit further stores the BGP routes, and when at least one stored BGP route needs to be canceled, deletes the stored at least one BGP route that needs to be canceled, and sends a notification via a BGP session established with a designated switch to instruct the target switch to delete the at least one BGP route that needs to be canceled and a route configuration information entry corresponding to the at least one BGP route.

[0121] In this embodiment, the route unit is further used for deleting at least one stored BGP route and a route configuration information entry corresponding to the at least one BGP route when the route unit receives at least one BGP route to be cancelled via a BGP session established with a specified switch.

[0122] In this embodiment, the BGP route is added to the MP_REACH_NLRI attribute of the BGP Update packet, and the AFI and SAFI in the MP_REACH_NLRI attribute are specified in advance and do not conflict with predefined AFI and SAFI values.

[0123] In this embodiment, at least one BGP route that needs to be withdrawn is added to the MP_UNREACH_NLRI attribute of the BGP Update packet, and the AFI and SAFI in the MP_UNREACH_NLRI attribute are pre-specified and do not conflict with pre-defined AFI and SAFI values.

[0124] Up to this point, the description of the structure of the device shown in FIG. 13 is completed.

[0125] An embodiment of the present invention further provides a hardware structure of the apparatus shown in Fig. 13. Fig. 14 is a structural diagram of an electronic device provided by an embodiment of the present invention. As shown in Fig. 14, the hardware structure may include a processor and a machine-readable storage medium, in which machine-executable instructions executable by the processor are stored, and the processor is used to execute the machine-executable instructions to implement the method disclosed in the above embodiment of the present invention.

[0126] Based on a similar idea to the above-mentioned method, an embodiment of the present invention further provides a machine-readable storage medium having computer instructions stored thereon, which, when executed by a processor, can implement the method disclosed in the above embodiment of the present invention.

[0127] Exemplarily, the machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, etc. For example, the machine-readable storage medium may be a random access memory (RAM), a volatile memory, a non-volatile memory, a flash memory, a storage drive (such as a hard drive), a solid-state drive, any storage disk (such as an optical disk, a DVD, etc.), or a similar storage medium, or a combination thereof.

[0128] The system, device, module or unit described in the above embodiments may be specifically realized by a computer chip, an entity, or a product having some function. A typical realizing device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a mobile phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, a game console, a tablet, a wearable device, or any combination of these devices.

[0129] For the sake of convenience, the above-mentioned device will be described by dividing it into various units according to their functions. Of course, when implementing the present invention, the functions of each unit may be realized by the same or multiple pieces of software and / or hardware.

[0130] As will be appreciated by those skilled in the art, embodiments of the present invention may be provided as a method, a system, or a computer program product. Thus, the present invention may employ an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product embodied in one or more computer usable storage media (including, but not limited to, magnetic disk memory, CD-ROM, optical memory, etc.) that contain computer usable program code.

[0131] The present invention will be described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, and combinations of flows and / or blocks, may be realized by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, whereby the instructions executed by the processor of the computer or other programmable data processing device generate an apparatus for implementing the functions specified in one or more flows of the flowcharts and / or one or more blocks of the block diagrams.

[0132] These computer program instructions may also be stored in a computer-readable memory that can instruct 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 that includes an instruction apparatus for implementing the functions specified in one or more flows of the flowcharts and / or one or more blocks of the block diagrams.

[0133] These computer program instructions may be loaded into a computer or other programmable data processing device such that a sequence of operational steps are executed on the computer or other programmable device to generate a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flows of the flowcharts and / or one or more blocks of the block diagrams.

[0134] The above is merely an embodiment of the present invention, and is not intended to limit the present invention. For those skilled in the art, the present invention is susceptible to various modifications and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention should be included in the scope of the claims of the present invention.

Claims

1. A method for synchronizing information between switches in a storage area network (SAN), comprising: obtaining target data to be synchronized; and transmitting a BGP route to which the target data is added via a BGP session established with the designated switch, thereby synchronizing the target data between each target switch that needs to be synchronized with the designated switch; The target data includes at least Including IP service zone configuration information of the access device, and / or device discovery information of the access device, and / or information on whether the switch supports a default IP service zone; A method for synchronizing information between switches.

2. The IP service zone configuration information includes at least The IP service zone configuration information includes a BGP route identifier (Route ID) of the switch, an IP service zone identifier, and an IP address of an access device to which the IP service zone configuration information belongs, and the IP service zone identifier is an identifier of a self-defined IP service zone different from a default IP service zone; 2. The method of claim 1 .

3. The device discovery information of the access device includes at least a MAC address of an access device, a port identifier of a port of the access device connected to the switch, and a BGP route identifier (Route ID) of the switch; 2. The method of claim 1 .

4. The device discovery information of the access device further includes device attribute information of the access device; The device attribute information of the access device includes at least an IP address of the access device, status information of the access device, and a role type of the access device; the IP address is an IPv4 address or an IPv6 address, The status information includes at least online information or offline information; The role type includes at least a storage system and / or a host; 4. The method according to claim 3 .

5. The information on whether the switch supports a default IP service zone includes at least: A BGP route identifier (Route ID) of the switch; or The switch's BGP route identifier (Route ID) and enable indicator are included; When the enable indication value is a first value, it indicates that the switch supports a default IP service zone, and when the enable indication value is a second value, it indicates that the switch does not support a default IP service zone.

2. The method of claim 1 .

6. The designated switch is at least one of the target switches, or The designated switch is at least one non-target switch other than the switch and the target switch.

2. The method of claim 1 .

7. When receiving a BGP route sent from another switch through a BGP session established with the designated switch, locally adding or updating a corresponding route configuration information entry based on the received BGP route; The route configuration information entry relates to data to be synchronized that is added to received BGP routes.

2. The method of claim 1 .

8. When receiving BGP routes with the same data to be synchronized via different BGP sessions, determining an optimal route according to a route priority scheme; 2. The method of claim 1 .

9. storing the BGP route; If at least one stored BGP route needs to be cancelled, deleting the stored at least one BGP route that needs to be cancelled, and sending a notification through a BGP session established with a designated switch to instruct the target switch to delete the at least one BGP route that needs to be cancelled and a route configuration information entry corresponding to the at least one BGP route.

2. The method of claim 1 .

10. and when at least one BGP route to be cancelled is received via a BGP session established with the designated switch, deleting the stored at least one BGP route and a route configuration information entry corresponding to the at least one BGP route.

2. The method of claim 1 .

11. The BGP session is An Interior Border Gateway Protocol (IBGP) session or an Exterior Border Gateway Protocol (EBGP) session, 2. The method of claim 1 .

12. The BGP route is added to an MP_REACH_NLRI attribute of a BGP Update packet, and the Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) in the MP_REACH_NLRI attribute are pre-specified and do not conflict with pre-defined AFI and SAFI values. The method according to any one of claims 1 to 8.

13. At least one BGP route that needs to be withdrawn is added to an MP_UNREACH_NLRI attribute of a BGP Update packet, and an Address Family Identifier (AFI) and a Subsequent Address Family Identifier (SAFI) in the MP_UNREACH_NLRI attribute are pre-specified and do not conflict with pre-defined AFI and SAFI values; 11. The method according to claim 9 or 10.

14. An electronic device comprising a processor and a machine-readable storage medium; the machine-readable storage medium stores machine-executable instructions executable by the processor; An electronic device, characterized in that the processor is adapted to execute machine-executable instructions to perform the method according to any one of claims 1 to 13.

Images