Policy issuing method, controller, route reflector device, and network system

Abstract

The application provides a policy issuing method, a controller, a route reflector device and a network system. The method comprises the following steps: a policy generation component of a master controller generates a policy issuing instruction according to a current policy, stores the policy issuing instruction into a policy issuing table, and broadcasts the policy issuing instruction to BGP components of controllers in a controller cluster; the BGP components of the controllers determine whether to issue the policy issuing instruction according to BGP neighbor information of the BGP components and RR devices indicated by the policy issuing instruction, wherein the BGP neighbor information is used to indicate the RR devices connected with the controllers; and if yes, the BGP component which determines to issue the policy issuing instruction sends the policy issuing instruction to the connected RR device through a virtual IP address of the master controller. The application reduces the number of BGP neighbors on the RR device side and the controller side, and also reduces the data amount borne by the BGP components in each controller.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of network communication, in particular to a policy issuing method, a controller, a route reflector device and a network system. BACKGROUND

[0002] SRv6 (Segment Routing) technology as the core technology of IPv6 network is being applied on a large scale, and one of the key technologies is the issue of SRv6 TE Policy (Segment Routing IPv6 Traffic Engineering Policy) policy. The BGP (Border Gateway Protocol) protocol adopts the working mode of neighbor peers, and the BGP neighbors maintain a long connection and always perform keep-alive. Once the connection is disconnected, the BGP end needs to clear the route information from the BGP neighbor, and when the neighbor is reestablished, the two neighbors need to perform full route synchronization. The RR (Route Reflector) device is a special device used to broadcast the TE Policy to all the following routers, so the RR device maintains a long connection with the controller, and the controller issues all the primary and backup TE policies calculated according to the user's intention to the RR device, which is then reflected to each router by the RR device.

[0003] In order to ensure the reliability of the policy on the RR device, that is, the neighbor state of the RR device and the controller remains stable and cannot be disconnected at will, otherwise the RR device will clear the TE data according to the routing protocol, and the relevant hanging routing devices will also be synchronized to clear, causing the entire network to oscillate, and even network failure. The current solution is to let the RR device establish a neighbor with each controller node (the controller node can be referred to as a controller) of the controller cluster, and the policy on each controller node is exactly the same. As long as the RR device has a normal neighbor with one of the controller nodes, it can at least maintain one copy of the route.

[0004] However, each RR device needs to establish a neighbor relationship with every controller node in the controller cluster. Since there are N controller nodes in the cluster, there are N neighbors. This means that each of the N controller nodes on the controller side needs to maintain the same routing information. When there are M RR devices, the controller side and the RR devices need to establish N*M neighbor relationships, and each neighbor needs to maintain data synchronization. The controller side needs to store a large amount of TE Policy data. Simultaneously, the large number of neighbor relationships between RR devices and the controller means a significant amount of repetitive TE Policy data synchronization is required. Given the already large volume of TE Policy data, further increasing the synchronization data exponentially due to reliability concerns will lead to performance pressure on both ends of the device and network bandwidth issues. Summary of the Invention

[0005] The purpose of this application is to address the shortcomings of the prior art by providing a policy distribution method, controller, routing reflector device, and network system to solve the problems of excessive duplication and large data volume during TE Policy data synchronization in the prior art, which affect device performance and network bandwidth.

[0006] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0007] Firstly, this application provides a policy distribution method applied to a controller cluster in a network system. The network system further includes at least one RR device. The controller cluster is deployed with a distributed cache for storing policy distribution announcements. The controller cluster includes a master controller and at least one slave controller. Each controller includes a policy generation component and a BGP component. Each RR device is communicatively connected to one controller in the controller cluster. The method includes:

[0008] The policy generation component of the main controller generates policy delivery instructions according to user business requirements, stores the policy delivery instructions in the policy delivery table, and broadcasts the policy delivery instructions to the BGP components of each controller in the controller cluster.

[0009] The BGP component of each controller determines whether to issue the policy issuance instruction based on the BGP neighbor information and the RR device indicated by the policy issuance instruction;

[0010] If so, the policy issuance instruction is sent to the RR device connected to the controller via the unified IP address of the controller cluster, so that the RR device can update its local policy table according to the instruction identifier in the policy issuance instruction.

[0011] Optionally, the determining whether to issue the policy issuing instruction according to the RR device indicated by the BGP neighbor information and the RR device indicated by the policy issuing instruction comprises:

[0012] If the RR device indicated by the BGP neighbor information is the same as the RR device indicated by the policy issuing instruction, it is determined to issue the policy issuing instruction.

[0013] Optionally, the method further comprises:

[0014] The master controller determines the fault controller according to the monitoring messages of the controllers.

[0015] If the fault controller is the master controller, a new master controller is elected by the slave controllers, and the unified IP address is used as the IP address of the new master controller.

[0016] If the fault controller is a slave controller, the master controller acquires the load information of each slave controller in the controller cluster, determines a target slave controller according to the load information of each slave controller, and sends a takeover instruction to the target slave controller, so that the target slave controller establishes a connection with the RR device connected to the fault controller according to the takeover instruction.

[0017] Optionally, the target slave controller establishes a connection with the RR device connected to the fault controller according to the takeover instruction comprises:

[0018] The target slave controller sends a BGP connection request to the RR device connected to the fault controller through the unified IP address, and establishes a BGP connection with the RR device connected to the fault controller.

[0019] The target slave controller acquires the current policy issuing instruction of the RR device connected to the fault controller from the policy issuing table according to the takeover instruction, and sends the current policy issuing instruction to the RR device.

[0020] Optionally, the distributed cache further stores a full policy table, and the method further comprises:

[0021] Any controller connected to the RR device receives a full policy synchronization request of the RR device connected to itself.

[0022] The any controller sends the full policy table to the connected RR device through the unified IP address.

[0023] In a second aspect, the present application provides a policy issuing method, applied to an RR device in a network system, the network system further comprising a controller cluster, the RR device being in communication connection with one controller in the controller cluster, and the method comprising:

[0024] receiving a policy issuing instruction sent by the controller cluster, and updating a local policy table according to the policy issuing instruction;

[0025] determining whether to perform full policy updating according to an instruction identifier of the policy issuing instruction and an instruction identifier of a last policy issuing instruction;

[0026] if yes, sending a full policy synchronization request to the controller cluster to obtain a full policy table of the device, and updating the local policy table according to the full policy table.

[0027] Optionally, the method further comprises:

[0028] if the controller connected by the RR device fails, retaining the local policy table and a last processed policy issuing instruction;

[0029] receiving a BGP connection request sent by a new controller of the controller cluster, and establishing a BGP connection with the new controller according to the BGP connection request sent by the non-failed controller;

[0030] receiving a current policy issuing instruction sent by the new controller, and updating the local policy table according to the current policy issuing instruction.

[0031] In a third aspect, the present application provides a controller, which, when in operation, is configured to perform the steps performed by the controller in the policy issuing method according to the first aspect and the second aspect.

[0032] In a fourth aspect, the present application provides an RR device, which, when in operation, is configured to perform the steps performed by the RR device in the policy issuing method according to the first aspect and the second aspect.

[0033] In a fifth aspect, the present application provides a network system, comprising a controller cluster and at least one RR device according to the fourth aspect, the controller cluster being deployed with a distributed cache for storing a policy issuing table, the controller cluster comprising a plurality of controllers according to the third aspect, and each RR device being in communication connection with one controller in the controller cluster.

[0034] The beneficial effects of the present application are: each RR device only establishes a BGP neighbor relationship with one controller in the controller cluster, and the controller implements the instruction issuing of the connected RR device based on the BGP protocol. The RR device does not have to establish a BGP neighbor relationship with each controller, and each controller in the controller cluster does not have to store the data of all RR devices. Not only does this reduce the number of BGP neighbors on the RR device side and the controller side, but it also reduces the number of SRv6 TE Policy carried by the BGP component in each controller. Moreover, the RR device side communicates with the controller cluster through a virtual IP address, without having to be aware of which specific controller in the cluster is connected to, further improving the security and reliability of the controller cluster communication.

[0035] In order to make the above objectives, characteristics and advantages of the present application more apparent and easy to understand, a preferred embodiment is described below, and the accompanying drawings are described in detail as follows. BRIEF DESCRIPTION OF DRAWINGS

[0036] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be considered as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0037] Figure 1 A schematic diagram of the architecture of a network system in the prior art is shown;

[0038] Figure 2 A schematic diagram of the architecture of a network system provided by the embodiments of the present application is shown;

[0039] Figure 3 A flowchart of a controller cluster side policy issuing method provided by the embodiments of the present application is shown;

[0040] Figure 4 A flowchart of a controller cluster side fault switching method provided by the embodiments of the present application is shown;

[0041] Figure 5 Another flowchart of a controller cluster side fault switching method provided by the embodiments of the present application is shown;

[0042] Figure 6 A flowchart of a controller cluster side full data updating method provided by the embodiments of the present application is shown;

[0043] Figure 7 A flowchart of a RR device side policy issuing method provided by the embodiments of the present application is shown;

[0044] Figure 8 A flowchart of a failure switching process on the side of an RR device is shown.

[0045] Figure 9 An interaction logic diagram of a policy issuing method is shown.

[0046] Figure 10 A structural schematic diagram of an electronic device is shown. DETAILED DESCRIPTION

[0047] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in connection with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0048] It should be noted that the term “comprises” will be used in the embodiments of the present application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0049] In the field of SRv6 traffic engineering, RR devices and controllers can be used for the issuance of SRv6 TE policies. Figure 1 is a schematic diagram of an architecture of RR device and controller deployment in the prior art. The number of controllers and RR devices can be multiple. In order to ensure the reliability of the policies on the RR device, the neighbor state of the RR device and the controller needs to be kept stable and cannot be disconnected at will, otherwise the RR device will clear the TE Policy data according to the routing protocol, and the relevant hanging routing devices will also be synchronized to clear, causing the entire network to oscillate, and even network failure. Referring to Figure 1 Each RR device needs to establish a connection with each controller to ensure that the RR device can keep at least one correct route when an individual controller fails.

[0050] However, the prior art needs the RR device to establish a stable connection relationship with all the controllers, and in order to ensure that the RR device receives correct policies, the data of each controller needs to be kept synchronized, so the controller side needs to store a large amount of policy data, and the number of neighbor relationships between the RR device and the controller is large, which means that there is a large amount of repeated policy data in the network. As the amount of policy data increases, the performance pressure on the controller and the RR device will also increase, and even network bandwidth problems may occur.

[0051] Based on this, the present application proposes a policy distribution method, which is applied to Figure 2 The network system as shown in the figure. First, the system architecture of the present application is described. Referring to Figure 2 , a packet controller cluster and at least one RR device in the network system.

[0052] Among them, the controller cluster is deployed with a distributed cache for storing policy distribution tables, which can be Redis, for storing TE Policy data and related information of the RR device. The controller cluster includes multiple controllers (controller nodes are referred to as controllers), each controller includes a policy generation component and a BGP component, each controller establishes a connection with the distributed cache, and a load balancer is arranged between the controller cluster and the RR device. The load balancer can be deployed on the master controller, the controller cluster acts as a backend server, and the RR device acts as a client. After the request of the RR device reaches the load balancer, the load balancer forwards the request of the RR device to the controller connected by the RR device in the controller cluster. Each RR device is connected to a controller in the controller cluster and communicates through the unified IP address of the controller cluster.

[0053] When establishing a connection, the RR device can actively initiate a BGP neighbor establishment request to the unified IP address of the controller cluster. After receiving the BGP neighbor establishment request, the controller cluster can select a controller according to a preset rule through the load balancer and forward the request to the selected controller. After receiving the BGP neighbor establishment request, the selected controller establishes a BGP neighbor with the RR device that initiates the BGP neighbor establishment request and interacts.

[0054] Among them, the BGP neighbor relationship can be established between two routers running the BGP protocol, and a direct communication relationship is established between them in order to exchange routing information. These routers are called "peers". Each BGP peer will maintain a neighbor list containing the IP addresses of other BGP routers with which it has established a trust relationship. During the BGP session establishment process, neighbors exchange messages to confirm each other's identity and negotiate session parameters. Once the session is established, they exchange update messages containing routing information such as reachability and path attributes.

[0055] Figure 3 is a flowchart of a strategy issuing method given by the present application. The method can be applied to Figure 2 the controller cluster of the strategy system shown in Figure 3 The method comprises the following steps.

[0056] S301, the strategy generation component of the master controller generates a strategy issuing instruction according to the user service requirement, stores the strategy issuing instruction in the strategy issuing table, and broadcasts the strategy issuing instruction to the BGP component of each controller in the controller cluster.

[0057] The controller cluster comprises a plurality of controller nodes (referred to as controllers for short). When the controller cluster is started, each controller can obtain a master controller through election, or the user can specify any controller in the controller cluster as a master controller during initialization.

[0058] The master controller uses a unified IP address as a virtual IP address for communication with the RR device at the opposite end. The master controller and the slave controller adopt a DR (Direct Routing) mode. The BGP component of each controller can serve as a service node of the master controller. The master controller can broadcast a strategy issuing instruction to each service node and forward a request message sent by the RR device at the opposite end to each service node.

[0059] For example, the unified IP address of the controller cluster can be 192.168.1.1, Figure 2 The IP addresses of the BGP component 1, the BGP component 2 and the BGP component 3 in the controller cluster are 192.168.2.1, 192.168.2.2 and 192.168.3.2 respectively. When the master controller is determined, the master controller needs to set its own IP address to the unified IP address 192.168.1.1.

[0060] The strategy generation component can generate a strategy issuing instruction of the SRv6 TE Policy according to the user service requirement. The strategy issuing instruction can be SRv6 TE Policy data, which can be an addition, change or deletion instruction for the RR device.

[0061] After the strategy generation component generates the strategy issuing instruction, the strategy generation component can broadcast the strategy issuing instruction to each BGP component and record the strategy issuing instruction in the strategy issuing table shown in Figure 2 The BGP component can be a BGP process running in the controller and receiving the strategy issuing instruction sent by the master controller as a service node of the master controller.

[0062] It should be noted that the policy issuing table can store policy data of each RR device and policy issuing instructions, and the policy issuing instructions of each RR device are stored respectively, and the policy issuing instructions of each RR device have unique and incremental instruction identifiers. Each controller in the controller cluster can obtain the policy issuing instructions from the policy issuing table, so that each controller does not have to store a large amount of SRv6 TE Policy data but can still keep the data synchronized.

[0063] S302, the BGP component of each controller determines whether to issue the policy issuing instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the policy issuing instruction.

[0064] The BGP neighbor information is stored in the BGP component of each controller respectively, and the BGP neighbor information includes the identifier of the RR device establishing the BGP neighbor relationship with the controller, the IP address of the RR device, etc.

[0065] After the BGP component in each controller receives the policy issuing instruction broadcasted by the master controller, the BGP component can analyze the policy issuing instruction to obtain the identifier of the RR device indicated by the policy issuing instruction, and compare the identifier of the RR device indicated by the policy issuing instruction with the identifier of the BGP neighbor stored by itself. If the RR device indicated by the policy issuing instruction is the BGP neighbor, the BGP component confirms to issue the policy issuing instruction to the RR device. If the identifier of the RR device indicated by the policy issuing instruction is different from the identifier of each BGP neighbor, the policy issuing instruction is not issued.

[0066] For example, after the policy generating component of the master controller generates the policy issuing instruction for the RR device 1, the policy issuing instruction can be broadcasted to the controller cluster. Figure 2 As shown in the BGP component 1, the BGP component 2 and the BGP component 3, after each BGP component receives the policy issuing instruction, it is firstly judged whether the RR device indicated by the policy issuing instruction is the BGP neighbor of itself. The BGP component 1 confirms that the RR device 1 indicated by the policy issuing instruction is the BGP neighbor of itself, and then determines to issue the policy issuing instruction to the RR device 1. The remaining BGP components do not issue the instruction.

[0067] S303, if yes, the policy issuing instruction is sent to the RR device connected to the controller through the unified IP address of the controller cluster, so that the RR device updates the local policy table according to the instruction identifier in the policy issuing instruction.

[0068] If the RR device indicated by the policy issuing instruction is the BGP neighbor of the current controller, the BGP component in the current controller can send the policy issuing instruction to the RR device indicated by the policy issuing instruction through the unified IP address of the master controller.

[0069] The BGP component can convert the policy distribution instruction into a BGP extension protocol and send the instruction to an RR device that establishes a BGP connection with the controller to which the BGP component belongs when distributing the instruction.

[0070] In a possible implementation, each BGP component can establish a connection with an RR device group that includes a primary RR device and a backup RR device. The BGP component can send the policy distribution instruction to the primary RR device when sending the policy distribution instruction, and the primary RR device can distribute the instruction and synchronize the instruction with the backup RR device after receiving the policy distribution instruction. In another implementation, the primary RR device and the backup RR device can also be connected to different controllers. When the primary RR device is operating normally, the controller distributes the policy of the node device managed by the RR device to the primary RR device. When the primary RR device fails, the controller distributes the policy to the backup RR device.

[0071] The instruction identifier has the characteristics of uniqueness and incrementality for each RR device. Therefore, the RR device can determine whether to perform full data update based on the instruction identifier in the policy distribution instruction after receiving the policy distribution instruction. If the difference between the instruction identifier of the policy distribution instruction and the identifier of the latest policy distribution instruction saved by the RR device is within a preset range, the RR device does not need to perform full data update. If the difference between the instruction identifier of the policy distribution instruction and the identifier of the latest policy distribution instruction saved by the RR device is not within the preset range, the RR device needs to perform full data update.

[0072] Meanwhile, if the instruction identifier in the policy distribution instruction is greater than the instruction identifier of the latest policy distribution instruction saved by the RR device, the RR device can execute the policy distribution instruction to update the local policy table after receiving the policy distribution instruction. If the instruction identifier in the policy distribution instruction is equal to the instruction identifier of the latest policy distribution instruction saved by the RR device, the local policy table can remain unchanged.

[0073] In the embodiments of the present application, the network system comprises a controller cluster and at least one RR device, the controller cluster is deployed with a distributed cache for storing a policy issuing table, the controller cluster comprises a master controller and at least one slave controller, each controller comprises a policy generating component and a BGP component, each RR device is in communication connection with one controller in the controller cluster, the policy generating component of the master controller generates a policy issuing instruction according to a user service requirement, stores the policy issuing instruction into the policy issuing table, and broadcasts the policy issuing instruction to the BGP components of the controllers in the controller cluster, the BGP component of each controller determines whether to issue the policy issuing instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the policy issuing instruction, and if yes, sends the policy issuing instruction to the connected RR device through the virtual IP address of the master controller.

[0074] Each RR device only establishes a BGP neighbor relationship with one controller in the controller cluster, and the controller implements the instruction issuing of the connected RR device based on the BGP protocol. The RR device does not have to establish a BGP neighbor relationship with each controller, and each controller in the controller cluster does not have to store the data of all RR devices. Not only the number of BGP neighbors on the RR device side and the controller side is reduced, but also the number of SRv6 TE Policies carried by the BGP component in each controller is reduced. Moreover, the RR device side communicates with the controller cluster through a virtual IP address, without having to perceive which specific controller in the cluster is connected, further improving the security and reliability of the controller cluster communication.

[0075] The following is a further description of the determination of whether to issue the policy issuing instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the policy issuing instruction, the S302 step comprises:

[0076] If the RR device indicated by the BGP neighbor information is the same as the RR device indicated by the policy issuing instruction, it is determined to issue the policy issuing instruction.

[0077] The BGP component can compare the device identifier of the RR device indicated by the policy issuing instruction with the device identifier of the RR device in the stored BGP neighbor information, if the identifiers are consistent, the connected RR device is taken as a target RR device, and the policy issuing instruction is sent to the target RR device.

[0078] In the embodiments of the present application, when the controller fails, the controller cluster can also perform fault switching on the failed controller, connect the RR device connected to the failed controller to other normally operating controllers, so as to ensure the stability of the data acquisition of the RR device, as shown in Figure 4 The method of the present application further comprises:

[0079] S401, the main controller determines a fault controller according to the monitoring messages of the controllers.

[0080] In the first implementation, each controller can periodically send a monitoring message to the main controller, the monitoring message being used to indicate the current load condition and running state of the controller, and if the main controller does not receive the monitoring message of the controller within a preset time period or the monitoring message of the controller indicates that the controller is currently running abnormally, the controller can be determined as a fault controller.

[0081] In the second implementation, the monitoring process can also periodically obtain the monitoring messages of the main controller and the slave controllers, and determine the controller with a fault based on the monitoring messages.

[0082] It should be noted that the fault controller can be the main controller or the slave controller, which is not limited in the present application.

[0083] S402, if the fault controller is the main controller, a new main controller is elected by the slave controllers, and a unified IP address is used as the IP address of the new main controller.

[0084] If the main controller fails, the slave controllers can elect a new main controller at this time, and set the IP address of the new main controller as the unified IP address of the controller cluster, the new main controller receives the request message from the RR device side, and manages and monitors the slave controllers.

[0085] S403, if the fault controller is a slave controller, the main controller obtains the load information of each slave controller in the controller cluster, determines a target slave controller according to the load information of each slave controller, and sends a takeover instruction to the target slave controller, so that the target slave controller establishes a connection with the RR device connected to the fault controller according to the takeover instruction.

[0086] When the slave controller fails, the main controller can obtain the load information of each controller in the controller cluster, and determine the controller with the smallest current load as the target slave controller. The main controller can obtain the load condition of each controller based on the monitoring message, or each controller can periodically update the load information to the policy issuing table, and the main controller can obtain the load condition of each controller from the policy issuing table after monitoring the fault controller.

[0087] Optionally, the takeover instruction includes the RR device identifier connected to the fault controller and the IP address of the RR device, and the target slave controller can send a BGP connection request to the IP address of the RR device after receiving the takeover instruction, and save the identifier of the RR device and the information of the RR device as BGP neighbor information after the BGP connection is successfully established.

[0088] Further, the above target slave controller establishes a connection with the RR device connected by the takeover instruction according to the fault controller, as shown in the process of Figure 5 The process includes:

[0089] S501, the target slave controller sends a BGP connection request to the RR device connected by the fault controller through a unified IP address, and establishes a BGP connection with the RR device connected by the fault controller.

[0090] After the target slave controller receives the takeover instruction of the master controller, it can send a BGP connection request to the RR device indicated by the takeover instruction using a unified IP address and a unified routing ID of the controller cluster, and complete neighbor establishment with the RR device.

[0091] S502, the target slave controller obtains the current policy issuing instruction of the RR device connected by the fault controller from the policy issuing table according to the takeover instruction, and sends the current policy issuing instruction to the RR device.

[0092] After completing the neighbor establishment with the RR device, the BGP component of the target slave controller can read the latest policy issuing instruction issued by the RR device from the policy issuing table, that is, the current policy issuing instruction, and convert the current policy issuing instruction into a BGP protocol packet and send it to the RR device.

[0093] It should be noted that the current policy issuing instruction includes an ID, which is used to uniquely identify the current policy issuing instruction. The ID of the policy issuing instruction of the RR device is incremental and unique, so after the RR device receives the current policy issuing instruction, it can compare the ID in the current policy issuing instruction with the ID of the last policy issuing instruction saved by the RR device itself. If the difference between the two is less than a preset threshold, the RR device can not perform full policy table update, and if the difference between the two is greater than the preset threshold, the RR device can initiate full policy table update to the controller.

[0094] The embodiments of the present application can ensure the accuracy of the RR device obtaining policy data by detecting the failure of each controller and switching the RR device connected by the fault controller, and each controller can obtain the latest policy issuing instruction of the RR device from the policy issuing table without having to save a large amount of data in each controller.

[0095] After receiving the policy issuing instruction, the RR device can determine whether there is missing data based on the ID in the policy issuing instruction, and then determine whether full data update is needed. When performing full data update, the full policy table is saved in the distributed cache, as shown in Figure 6 The policy issuing method on the side of the controller cluster further includes:

[0096] S601, any controller connected with the RR device receives a full-amount policy synchronization request of the RR device connected with itself.

[0097] The RR device identifier can be included in the full-amount policy synchronization request. After receiving the full-amount policy synchronization request, the load balancer in the master controller can determine the controller connected with the RR device based on the RR device identifier, and send the full-amount policy synchronization request to the controller connected with the RR device.

[0098] S602, any controller sends the full-amount policy table to the connected RR device through a unified IP address.

[0099] The full-amount policy table of each RR device is stored in the policy issuing table. After receiving the full-amount policy synchronization request, the controller connected with the RR device can obtain the full-amount policy table of the RR device from the distributed cache, send the full-amount policy table to the BGP component, and convert the full-amount policy table into a BGP protocol packet and send it to the RR device through the unified IP address.

[0100] The following is a further description of the policy issuing method of the present application from the side of the RR device, as shown in Figure 7 The policy issuing method from the side of the RR device includes:

[0101] S701, receiving the policy issuing instruction sent by the controller cluster, and updating the local policy table according to the policy issuing instruction.

[0102] The policy issuing instruction can be a BGP protocol packet. The controller establishes a BGP connection with the RR device and communicates through the BGP protocol.

[0103] The RR device can receive the policy issuing instruction issued by the controller in the controller cluster which establishes a BGP connection with the RR device. The controller connected with the RR device in the controller cluster sends the policy issuing instruction to the RR device through a virtual IP address. After receiving the policy issuing instruction sent by the virtual IP address, the RR device can add, change or delete the local policy table in the RR device based on the policy issuing instruction.

[0104] S702, determining whether to update the full-amount policy according to the instruction identifier of the policy issuing instruction and the instruction identifier of the last policy issuing instruction.

[0105] The policy issuing instruction has a unique and incremental instruction identifier ID for each RR device, so the RR device can determine whether there is missing data in the data synchronization process based on the policy issuing instruction. Even if the RR device is disconnected from the controller and then reconnects, the RR device can determine whether there is missing data according to the ID of the latest policy issuing instruction sent by the controller, and if there is, the RR device can initiate a full policy synchronization request to the controller to update the full policy table.

[0106] Specifically, the RR device can compare the ID of the currently received policy issuing instruction with the ID of the last received policy issuing instruction. If the difference between the ID of the last received policy issuing instruction and the ID of the currently received policy issuing instruction is less than or equal to 1, it means that the data synchronization is normal, and at this time, full policy table update is not necessary. The RR device continues to maintain the connection with the controller and receives the policy issuing instruction issued by the controller. If the difference is greater than 1, it means that there is missing data in the data synchronization, and at this time, the RR device can initiate a full data synchronization request to the controller to update the full policy.

[0107] S703, if yes, a full policy synchronization request is sent to the controller cluster to obtain the full policy table of the RR device, and the local policy table is updated according to the full policy table.

[0108] The RR device can send a full policy synchronization request to the virtual IP address of the controller cluster to obtain the full policy table of the RR device, and the full policy table is used as the local policy table of the RR device.

[0109] It should be noted that two RR devices can form a device group, and the device group is connected with the controller. The device group includes a master RR device and a backup RR device. The master RR device can perform data synchronization with the backup RR device after completing the update of the current policy, and the backup RR device is used for policy issuing when the master RR device fails.

[0110] In the embodiments of the present application, the RR device communicates with the controller cluster through a virtual IP address and receives the policy issuing instruction sent by the controller cluster. The RR device does not need to establish a connection with all controllers, but only establishes a BGP connection with one of the controllers, which can reduce the number of BGP neighbors, and the controller does not need to store a large amount of SRv6 TE Policy data. Moreover, the RR device compares the currently received policy issuing instruction with the last saved policy issuing instruction, and then determines whether to perform full update. Even if the RR device is disconnected from the controller and then reconnected, the RR device can determine whether to perform full data update based on the latest received policy issuing instruction. Compared with the full update data mode in the prior art, the method of the present application reduces the frequency of full refresh of SRv6 TE Policy data, thereby reducing the load pressure of the RR device and improving the performance of the RR device.

[0111] When the controller fails, as shown in FIG. 8, the method on the RR device side further includes: Figure 8

[0112] S801, if the controller connected by the RR device fails, the local policy table and the last processed policy issuing instruction are retained.

[0113] The BGP connection is maintained between the RR device and the controller. If the RR device is disconnected from the controller for more than a preset time threshold, the RR device can determine that the currently connected controller fails. At this time, the RR device can retain the local policy table and the last processed policy issuing instruction, and send a connection establishment request to the unified IP address of the controller cluster.

[0114] The RR device can use the BGP protocol to send a connection establishment request to the unified IP address, for example, initiate a TCP connection. After being balanced by the load balancer in the controller cluster, the RR device can establish a TCP connection with any one of the controllers in the controller cluster.

[0115] After the TCP connection is established, in the first implementation manner, the RR device can actively initiate a BGP connection request to establish a BGP neighbor relationship with the controller.

[0116] In the second implementation manner, the controller cluster can also send a BGP connection request to the RR device after establishing the TCP connection, to establish a BGP neighbor relationship with the RR device.

[0117] S802, receive the BGP connection request sent by the new controller of the controller cluster, and establish a BGP connection with the new controller according to the BGP connection request sent by the non-faulty controller.

[0118] ​The new controller is a non-faulty controller, the new controller in the controller cluster sends a BGP connection request to the RR device through a unified IP address, and the RR device establishes a BGP neighbor relationship with the new controller after receiving the BGP connection request. The IP address in the BGP neighbor information of the controller stored by the RR device is the unified IP address of the controller cluster.

[0119] S803, receiving a current policy issuing instruction sent by the new controller, and updating a local policy table according to the current policy issuing instruction.

[0120] After the new controller establishes a BGP connection with the RR device, the new controller can issue a policy issuing instruction to the RR device, and the RR device updates the local policy table after receiving the policy issuing instruction, for example, adds, deletes, or changes the local policy table in the RR device. At the same time, the policy issuing instruction also includes an instruction identifier, and the RR device can also determine whether to request a full policy table from the controller according to the instruction identifier in the policy issuing instruction. The process of requesting a full policy table is shown in the above S701-S703 steps, which will not be repeated here.

[0121] Next, the policy issuing method of the present application will be further described in combination with the system interaction logic diagram of Figure 9 .

[0122] The policy issuing component in the controller generates a policy issuing instruction according to the user's planning requirements, stores the policy issuing instruction in the policy issuing table, and broadcasts it to each BGP component. The BGP component connected to the policy issuing instruction sends the policy issuing instruction to the RR device through a unified IP address.

[0123] The RR device receives the policy issuing instruction through the BGP protocol process, updates the SRv6 TE Policy table based on the policy issuing instruction after receiving the policy issuing instruction, and determines whether to perform full data update. If yes, send a full policy synchronization request to the virtual IP address to realize data synchronization.

[0124] Figure 10 A structural schematic diagram of a controller provided by an embodiment of the present application is shown, the controller can be an electronic device, the electronic device includes: a processor 1001, a storage medium 1002 and a bus 1003, the storage medium 1002 stores machine readable instructions executable by the processor 1001, when the electronic device runs a policy issuing method as in an embodiment, the processor 1001 and the storage medium 1002 communicate through the bus 1003, the processor 1001 executes the machine readable instructions, the antecedent part of the processor 1001 method item, to execute the steps in the above policy issuing method.

[0125] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program. The computer program is executed by a processor to perform the steps in the policy issuing method.

[0126] In the embodiment of the present application, the computer program executed by the processor can further execute other machine readable instructions to perform the method as described in other embodiments. For the specific method steps and principles, refer to the description of the embodiments, which will not be described in detail here.

[0127] In the embodiments provided in the present application, it should be understood that the disclosed method can be implemented by other means. The system embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and other division manners can be used in actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some communication interfaces, systems or units, which can be electrical, mechanical or other forms.

[0128] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, i.e., they can be located in one place or distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0129] In addition, each functional unit in the embodiments provided in the present application can be integrated into one processing unit, or each unit can exist physically, or two or more units can be integrated into one unit.

[0130] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the parts of the technical solutions that essentially contribute to the prior art can be embodied in the form of software products. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0131] It should be noted that like reference numerals and letters refer to like elements throughout the several views of the drawings, and that, unless otherwise indicated, like reference numerals and letters are used again throughout the several figures, and that, unless specifically stated otherwise, the drawings are not drawn to scale.

[0132] Finally, it should be noted that the above-described embodiments are merely exemplary of the application and should not be used to limit the present application and are presented in order to more fully describe the application. The application is defined by the claims and their equivalents. It is understood that where the description above refers to actions to be taken by a person, the person includes a computerized device programmed to perform the described actions. It is understood that the activities can be performed by more than one person or device. It is also understood that the activities of the person or device can be performed in an order different from the "order described, which can include frequent counter-cyclic performance.

Claims

1. A strategy distribution method, characterized in that, A controller cluster is applied to a network system, the network system further including at least one RR device. The controller cluster is deployed with a distributed cache for storing policy-based publications. The controller cluster includes a master controller and at least one slave controller. Each controller includes a policy generation component and a BGP component. Each RR device is communicatively connected to one controller in the controller cluster. The method includes: The policy generation component of the main controller generates policy delivery instructions according to user business requirements, stores the policy delivery instructions in the policy delivery table, and broadcasts the policy delivery instructions to the BGP components of each controller in the controller cluster. The BGP component of each controller determines whether to issue the policy issuance instruction based on the BGP neighbor information and the RR device indicated by the policy issuance instruction; If so, the policy issuance instruction is sent to the RR device connected to the controller via the unified IP address of the controller cluster, so that the RR device can update its local policy table according to the instruction identifier in the policy issuance instruction.

2. The method according to claim 1, characterized in that, The step of determining whether to issue the policy issuance command based on the BGP neighbor information and the RR device indicated by the policy issuance command includes: If the RR device indicated by the BGP neighbor information is the same as the RR device indicated by the policy issuance command, then the policy issuance command will be issued.

3. The method according to claim 1, characterized in that, The method further includes: The main controller identifies the faulty controller based on the monitoring messages from each controller; If the fault controller is the master controller, then a new master controller is elected by each of the slave controllers, and the unified IP address is used as the IP address of the new master controller; If the fault controller is a slave controller, the master controller obtains the load information of each slave controller in the controller cluster, determines the target slave controller based on the load information of each slave controller, and sends a takeover command to the target slave controller so that the target slave controller establishes a connection with the RR device connected to the fault controller according to the takeover command.

4. The method according to claim 3, characterized in that, The target controller establishes a connection with the RR device connected to the fault controller according to the takeover command, including: The target controller sends a BGP connection request to the RR device connected to the fault controller via the unified IP address, and establishes a BGP connection with the RR device connected to the fault controller. The target controller retrieves the current policy issuance instruction for the RR device connected to the fault controller from the policy issuance table according to the takeover instruction, and sends the current policy issuance instruction to the RR device.

5. The method according to claim 1, characterized in that, The distributed cache also stores the full policy table, and the method further includes: Any controller connected to an RR device receives a full policy synchronization request from the RR devices connected to it. Each controller sends the full policy table to the connected RR device via the unified IP address.

6. A strategy distribution method, characterized in that, The method includes an RR device applied in a network system, the network system further including a controller cluster, the RR device being communicatively connected to a controller in the controller cluster, the method comprising: The system receives policy issuance instructions sent by the controller cluster and updates its local policy table according to the policy issuance instructions. The policy issuance instructions are generated by the policy generation component of the master controller in the controller cluster according to user service requirements, and the master controller broadcasts the policy issuance instructions to the BGP components of each controller in the controller cluster. When the BGP components of each controller determine to issue the policy issuance instructions based on BGP neighbor information and the RR device indicated by the policy issuance instructions, the controller to which the RR device belongs sends the policy issuance instructions to the RR device through the unified IP address of the controller cluster. Based on the instruction identifier of the instruction issued under the aforementioned strategy and the instruction identifier of the instruction issued under the previous strategy, determine whether to perform a full strategy update; If so, a full policy synchronization request is sent to the controller cluster to obtain the full policy table of this device, and the local policy table is updated according to the full policy table.

7. The method according to claim 6, characterized in that, The method further includes: If the controller connected to the RR device fails, the local policy table and the last processed policy issuance instruction are retained. Receive a BGP connection request sent by a new controller in the controller cluster, and establish a BGP connection with the new controller based on the BGP connection request sent by the non-faulty controller; Receive the current policy issuance instruction sent by the new controller, and update the local policy table according to the current policy issuance instruction.

8. A controller, characterized in that, The controller is used to execute the steps performed by the controller in the policy distribution method as described in any one of claims 1-5.

9. A route reflector (RR) device, characterized in that, The RR device is used to execute the steps performed by the RR device in the policy distribution method as described in claim 6 or claim 7.

10. A network system, characterized in that, The network system includes: a controller cluster and at least one RR device as described in claim 9, the controller cluster being deployed with a distributed cache for storing publications under a storage policy, the controller cluster including a plurality of controllers as described in claim 8, and each RR device being communicatively connected to one controller in the controller cluster.

Images