Policy issuing method, controller, RR device and network system

Abstract

The invention provides a strategy issuing method, controllers, RR equipment and a network system, and the method comprises the steps: a strategy generation assembly of a main controller generates a strategy issuing instruction according to a current strategy, stores the strategy issuing instruction in a strategy issuing table, and broadcasts the strategy issuing instruction to a BGP assembly of each controller in a controller cluster, the BGP component of each controller determines whether to issue the strategy issuing instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the strategy issuing instruction, the BGP neighbor information is used for indicating the RR device connected with the controller, and if yes, the strategy issuing instruction is issued. And if yes, the BGP component which determines to issue the strategy issuing instruction sends the strategy issuing instruction to the connected RR equipment through the virtual IP address of the main controller. According to the invention, the number of BGP neighbors at the RR equipment side and the controller side is reduced, and meanwhile, the data volume borne by the BGP component in each controller is also reduced.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a policy delivery method, a controller, an RR device, and a network system. Background Art

[0002] SRv6 (Segment Routing) technology is being widely used as the core technology of IPv6 network, and one of the key technologies is the issue of issuing SRv6 TE Policy (Segment Routing IPv6 Traffic Engineering Policy). BGP (Border Gateway Protocol) adopts the working mode of neighbor peers. BGP neighbors maintain a long connection and keep alive all the time. Once the connection is disconnected, one end of BGP needs to clear the routing information from the BGP neighbor. When the neighbor is reestablished, the two neighbors need to synchronize the routes. RR (Route Reflector) devices are special devices used to broadcast TE Policy to all the routers below. Therefore, RR devices will maintain a long connection with the controller. The controller will issue all the primary and backup TE policies calculated according to the user's intention to RR devices, and then the RR devices will reflect them to each router.

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

[0004] However, each RR device needs to establish a neighbor relationship with each controller node in the controller cluster. If there are N controller nodes in the controller 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 device side need to establish N*M neighbor relationships, and each neighbor needs to keep data synchronized. The controller side needs to store a large amount of TE Policy data. At the same time, there are many neighbor relationships between RR devices and controllers, which means that a large amount of repeated synchronization of TE Policy data is required. Since the amount of TE Policy data itself is relatively large, if the synchronization data is further multiplied for reliability, it will cause performance pressure on the devices at both ends and network bandwidth problems. Summary of the invention

[0005] The purpose of this application is to provide a policy delivery method, controller, RR device and network system to address the deficiencies in the above-mentioned prior art, so as to solve the problem in the prior art that there are many repetitions and large data volumes during TE Policy data synchronization, which affects device performance and network bandwidth.

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

[0007] In a first aspect, the present application provides a policy delivery method, which is applied to a controller cluster in a network system, wherein the network system further includes at least one RR device, the controller cluster is deployed with a distributed cache for storing policy releases, 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 a controller in the controller cluster, and the method includes:

[0008] The policy generation component of the main controller generates a policy issuance instruction according to user service requirements, stores the policy issuance instruction in the policy issuance table, and broadcasts the policy issuance instruction to the BGP components of each controller in the controller cluster;

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

[0010] If so, the policy issuing 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 updates the local policy table according to the instruction identifier in the policy issuing instruction.

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

[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 main controller determines the faulty controller according to the monitoring information of each controller;

[0015] If the faulty controller is the master controller, each slave controller elects a new

[0016] The unified IP address is used as the IP address of the new main controller;

[0017] If the faulty 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 instruction to the target slave controller, so that the target slave controller establishes a connection with the RR device connected to the faulty controller according to the takeover instruction.

[0018] Optionally, the target slave controller establishes a connection with the RR device connected to the faulty controller according to the takeover instruction, including:

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

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

[0021] Optionally, the distributed cache further stores a full strategy table, and the method further includes:

[0022] Any controller connected to the RR device receives the full policy synchronization request from the RR device to which it is connected;

[0023] Any controller sends the full policy table to the connected RR device via the unified IP address.

[0024] In a second aspect, the present application provides a policy delivery method, which is applied to an RR device in a network system, wherein the network system further includes a controller cluster, and the RR device is communicatively connected to a controller in the controller cluster, and the method includes:

[0025] Receive the policy delivery instruction sent by the controller cluster, and update the local policy table according to the policy delivery instruction;

[0026] Determine whether to perform a full policy update based on the instruction identifier of the instruction issued by the policy and the instruction identifier of the instruction issued by the previous policy;

[0027] If so, a full policy synchronization request is sent to the controller cluster to obtain the full policy table of the device, and the local policy table is updated according to the full policy table.

[0028] Optionally, the method further comprises:

[0029] If the controller to which the RR device is connected fails, the local policy table and the last processed policy delivery instruction are retained;

[0030] 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-faulty controller;

[0031] Receive the current policy issuing instruction sent by the new controller, and update the local policy table according to the current policy issuing instruction.

[0032] In a third aspect, an embodiment of the present application further provides a controller, which, when running, is used to execute the steps executed by the controller in the policy delivery method described in the first aspect and the second aspect.

[0033] In a fourth aspect, an embodiment of the present application further provides an RR device, which, when running, is used to execute the steps executed by the RR device in the policy delivery method described in the first aspect and the second aspect.

[0034] In the fifth aspect, an embodiment of the present application also provides a network system, comprising: a controller cluster and at least one RR device as described in the fourth aspect, the controller cluster is deployed with a distributed cache for storage policies, the controller cluster includes multiple controllers as described in the third aspect, and each of the RR devices is communicatively connected to a controller in the controller cluster.

[0035] 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 issuance of instructions to 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 it reduce the number of BGP neighbors on the RR device side and the controller side, but it also reduces the number of SRv6 TE Policies carried by the BGP component in each controller. In addition, the RR device side communicates with the controller cluster through a virtual IP address, and does not have to sense which specific controller in the cluster it is connected to, further improving the security and reliability of controller cluster communications.

[0036] In order to make the above-mentioned objects, features and advantages of the present application more obvious and easy to understand, preferred embodiments are specifically cited below and described in detail with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

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

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

[0040] Figure 3 A flow chart of a controller cluster-side policy delivery method provided in an embodiment of the present application is shown;

[0041] Figure 4 A flowchart of a controller cluster side fault switching provided by an embodiment of the present application is shown;

[0042] Figure 5 Another flow chart of performing a failover on one side of a controller cluster provided in an embodiment of the present application is shown;

[0043] Figure 6 A flowchart of a controller cluster side performing a full data update provided by an embodiment of the present application is shown;

[0044] Figure 7 A flowchart of a method for issuing a policy on an RR device side provided in an embodiment of the present application is shown;

[0045] Figure 8 A flowchart of a fault switching on one side of an RR device provided in an embodiment of the present application is shown;

[0046] Fig. 9 An interactive logic diagram of a policy delivery method provided in an embodiment of the present application is shown;

[0047] Fig.10 A schematic structural diagram of an electronic device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0048] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here 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 application claimed for protection, but merely represents the 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 making creative work belong to the scope of protection of the present application.

[0049] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0050] In the SRv6 traffic engineering field, RR devices and controllers can be used to deliver SRv6 TE policies. Figure 1 This is a schematic diagram of the architecture of RR devices and controller deployment in the prior art. There can be multiple controllers and RR devices. To ensure the reliability of the policies on the RR devices, the neighbor status between the RR devices and the controllers needs to remain stable and cannot be disconnected at will. Otherwise, the RR devices will clear the TE Policy data according to the routing protocol, and the related downstream routing devices will also clear the data synchronously, causing the entire network to oscillate or even fail. Figure 1 , each RR device needs to establish a connection with each controller to ensure that when an individual controller fails, the RR device can maintain at least one correct route.

[0051] However, the existing technology requires that the RR device establish a stable connection with all controllers, and in order to ensure that the RR device receives the correct policy, the data of each controller needs to be synchronized. Therefore, a large amount of policy data needs to be stored on the controller side, and the number of neighbor relationships between the RR device and the controller is large, which means that there is a large amount of duplicate policy data in the network. As the amount of policy data continues to increase, the performance pressure on the controller and RR device will continue to increase, and may even cause network bandwidth problems.

[0052] Based on this, this application proposes a strategy delivery method, which is applied to Figure 2 The network system shown. First, the system architecture of this application is described. Figure 2 , a packet controller cluster and at least one RR device in the network system.

[0053] The controller cluster is deployed with a distributed cache for storing policies published. The distributed cache can be Redis, which is used to store TE Policy data and related information of RR devices. The controller cluster includes multiple controllers (controller nodes are referred to as controllers for short). Each controller includes a policy generation component and a BGP component. Each controller establishes a connection with the distributed cache. A load balancer is set between the controller cluster and the RR device. The load balancer can be deployed on the main controller. The controller cluster serves as a backend server and the RR device serves 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 to 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.

[0054] 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 through the load balancer according to the preset rules 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 initiated the BGP neighbor establishment request and interacts with it.

[0055] Among them, the two routers running the BGP protocol can establish a BGP neighbor relationship, and a direct communication relationship is established between them to exchange routing information. These routers are called "peers". Each BGP peer maintains 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.

[0056] Figure 3 This is a flow chart of a policy delivery method provided in this application. This method can be applied to Figure 2 In the controller cluster of the system under the strategy shown, refer to Figure 3 , the method comprising:

[0057] S301. The policy generation component of the main controller generates a policy issuance instruction according to user service requirements, stores the policy issuance instruction in a policy issuance table, and broadcasts the policy issuance instruction to the BGP components of each controller in the controller cluster.

[0058] The controller cluster includes multiple controller nodes (referred to as controllers for short). When the controller cluster is started, each controller can elect a master controller, or during initialization, the user can designate any controller in the controller cluster as the master controller.

[0059] The master controller uses the unified IP address as the virtual IP address for communicating with the peer RR device. The master controller and the slave controller use the DR (Direct Routing) mode. The BGP component of each controller can serve as the service node of the master controller. The master controller can broadcast policies and issue instructions to each service node, and forward request messages sent by the peer RR device to each service node.

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

[0062] The policy generation component can generate SRv6 TE Policy policy delivery instructions based on user service requirements. The policy delivery instructions can be SRv6 TE Policy data, specifically, instructions for adding, changing, or deleting RR devices.

[0063] After generating the policy delivery instruction, the policy generation component can broadcast the policy delivery instruction to each BGP component and record the policy delivery instruction in Figure 2 The policy is issued in the table shown in FIG. 1. The BGP component may be a BGP process running in the controller, and as a service node of the main controller, receives the policy issuing instruction sent by the main controller.

[0064] It should be noted that the policy data and policy delivery instructions of each RR device can be stored in the policy delivery statement. The policy delivery instructions of each RR device are stored separately, and the policy delivery instructions of each RR device have a unique and incremental instruction identifier. Each controller in the controller cluster can obtain the policy delivery instruction from the policy delivery statement, so that each controller does not need to store a large amount of SRv6 TE Policy data but can still maintain data synchronization.

[0065] S302: The BGP component of each controller determines whether to issue a policy issuance instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the policy issuance instruction.

[0066] The BGP component of each controller stores BGP neighbor information, which includes the identifier of the RR device that establishes a BGP neighbor relationship with the controller, the IP address of the RR device, etc.

[0067] After receiving the policy delivery instruction broadcasted by the main controller, the BGP component in each controller can parse the policy delivery instruction to obtain the identifier of the RR device indicated by the policy delivery instruction, and compare the identifier of the RR device indicated by the policy delivery instruction with the identifier of the BGP neighbor stored in itself. If the RR device indicated by the policy delivery instruction is a BGP neighbor, the BGP component confirms that the policy delivery instruction is delivered to the RR device. If the identifiers of the RR device indicated by the policy delivery instruction and each BGP neighbor are different, the policy delivery instruction will not be delivered.

[0068] For example, after the policy generation component of the main controller generates a policy delivery instruction for RR device 1, the policy delivery instruction can be broadcast to Figure 2 The BGP component 1, BGP component 2 and BGP component 3 shown in the figure, after each BGP component receives the policy issuing instruction, it first determines whether the RR device indicated by the policy issuing instruction is its own BGP neighbor. BGP component 1 confirms that the RR device 1 indicated by the policy issuing instruction is its own BGP neighbor, then determines to issue the policy issuing instruction to RR device 1, and the other BGP components do not issue instructions.

[0069] 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.

[0070] If the RR device indicated by the policy delivery instruction is a BGP neighbor of the current controller, the BGP component in the current controller may send the policy delivery instruction to the RR device indicated by the policy delivery instruction through the unified IP address of the main controller.

[0071] When issuing instructions, the BGP component may convert the policy issuing instructions into a BGP extended protocol and send the instructions to the RR device that establishes a BGP connection with the controller to which the BGP component belongs.

[0072] In one possible implementation, each BGP component can establish a connection with an RR device group, which includes a master RR device and a backup RR device. When sending a policy issuance instruction, the BGP component can send the policy issuance instruction to the master RR device. After receiving the policy issuance instruction, the master RR device issues the instruction and synchronizes the instruction with the backup RR device. In another implementation, the master RR device and the backup RR device can also be connected to different controllers. When the master RR device operates normally, the controller sends the policy of the node device managed by the RR device to the master RR device. When the master RR device fails, the policy is sent to the backup RR device.

[0073] The instruction identifier is unique and incremented for each RR device. Therefore, after receiving the policy issuance instruction, the RR device can determine whether to perform a full data update based on the instruction identifier in the policy issuance instruction. If the RR device determines that the difference between the instruction identifier of the policy issuance instruction and the identifier of the latest policy issuance instruction saved by itself is within the preset interval, it means that the RR device does not need to perform a full data update. If the difference between the instruction identifier of the policy issuance instruction and the identifier of the latest policy issuance instruction saved by itself is not within the preset interval, it means that the RR device needs to perform a full data update.

[0074] At the same time, after the RR device receives the policy issuance instruction, if the instruction identifier in the policy issuance instruction is greater than the instruction identifier of the latest policy issuance instruction saved by the RR device itself, the RR device can execute the policy issuance instruction to update the local policy table. If the instruction identifier in the policy issuance instruction is equal to the instruction identifier of the latest policy issuance instruction saved by the RR device itself, the local policy table can be kept unchanged.

[0075] In an embodiment of the present application, a network system includes: a controller cluster and at least one RR device, wherein the controller cluster is deployed with a distributed cache for storing policy publications, wherein the controller cluster includes a master controller and at least one slave controller, wherein each controller includes a policy generation component and a BGP component, wherein each RR device is communicatively connected to a controller in the controller cluster, wherein the policy generation component of the master controller generates a policy issuance instruction according to user business requirements, stores the policy issuance instruction in a policy publication, and broadcasts the policy issuance instruction to the BGP components of each controller in the controller cluster, wherein the BGP components of each controller determine whether to issue a policy issuance instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the policy issuance instruction, and if so, sends the policy issuance instruction to the connected RR device through the virtual IP address of the master controller.

[0076] Each RR device only establishes a BGP neighbor relationship with one controller in the controller cluster, and the controller implements the command issuance of the connected RR device based on the BGP protocol. The RR device does not need to establish a BGP neighbor relationship with each controller, and each controller in the controller cluster does not need to store the data of all RR devices. This not only reduces the number of BGP neighbors on the RR device side and the controller side, but also reduces the number of SRv6 TE Policies carried by the BGP component in each controller. In addition, the RR device communicates with the controller cluster through a virtual IP address, and does not need to perceive which specific controller in the cluster it is connected to, further improving the security and reliability of controller cluster communication.

[0077] The following is a further description of determining whether to issue a policy issuing instruction according to the BGP neighbor information of each BGP component and the RR device indicated by the policy issuing instruction. The above step S302 includes:

[0078] 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.

[0079] The BGP component can compare the device identifier of the RR device indicated by the policy delivery instruction with the device identifier of the RR device in the BGP neighbor information stored in itself. If the identifiers are consistent, the RR device connected by the identifier is used as the target RR device, and the policy delivery instruction is sent to the target RR device.

[0080] In the embodiment of the present application, when a controller fails, the controller cluster can also perform a failover on the failed controller, and connect the RR device connected to the failed controller to other normally operating controllers to ensure the stability of the RR device in acquiring data, such as Figure 4 As shown, the method of the present application also includes:

[0081] S401. The main controller determines a faulty controller based on monitoring information of each controller.

[0082] In the first implementation method, each controller can periodically send monitoring messages to the main controller. The monitoring messages are used to indicate the current load condition and operating status of the controller. If the main controller does not receive the monitoring message from the controller within a preset period of time, or the monitoring message from the controller indicates that the controller is currently operating abnormally, the controller can be determined as a faulty controller.

[0083] In the second implementation manner, the monitoring process may also periodically obtain monitoring messages of the master controller and each slave controller, and determine the faulty controller based on the monitoring messages.

[0084] It should be noted that the faulty controller may be a master controller or a slave controller, and this application does not impose any limitation thereto.

[0085] S402: If the failed controller is the master controller, each slave controller elects a new master controller and uses the unified IP address as the IP address of the new master controller.

[0086] If the master controller fails, the slave controllers can elect a new master controller and set the IP of the new master controller to the unified IP address of the controller cluster. The new master controller receives the request message from the RR device side and manages and monitors the slave controllers.

[0087] S403. If the faulty 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 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 faulty controller according to the takeover instruction.

[0088] When a slave controller fails, the master 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 master controller can obtain the load status of each controller based on monitoring messages, or each controller can regularly update the load information to the policy release. After the master controller monitors the failed controller, it can obtain the load status of each controller from the policy release.

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

[0090] Furthermore, the target slave controller establishes a connection with the RR device connected to the faulty controller according to the takeover instruction, such as Figure 5 As shown, including:

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

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

[0093] S502: The target slave controller obtains the current policy issuing instruction of the RR device connected to the failed controller from the policy issuing table according to the takeover instruction, and sends the current policy issuing instruction to the RR device.

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

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

[0096] The embodiment of the present application can ensure the accuracy of the policy data obtained by the RR device by performing fault detection on each controller and switching the RR device connected to the faulty controller, and each controller can obtain the latest policy issuance instructions of the RR device from the policy issuance without having to store a large amount of data in each controller.

[0097] After receiving the policy delivery instruction, the RR device can determine whether there is missing data based on the ID in the policy delivery instruction, and then determine whether a full data update is required. When a full data update is performed. The distributed cache stores a full policy table, such as Figure 6 As shown, the policy delivery method on the controller cluster side also includes:

[0098] S601. Any controller connected to the RR device receives a full policy synchronization request from the RR device connected to itself.

[0099] The full policy synchronization request may include the RR device identifier. After the load balancer in the main controller receives the full policy synchronization request, it may determine the controller connected to the RR device based on the RR device identifier and send the full policy synchronization request to the controller connected to the RR device.

[0100] S602. Any controller sends the full policy table to the connected RR device via a unified IP address.

[0101] The policy table stores the full policy table of each RR device. After receiving the full policy synchronization request, the controller connected to the RR device can obtain the full policy table of the RR device from the distributed cache and send the full policy table to the BGP component. The BGP component converts the full policy table into a BGP protocol message and sends it to the RR device through a unified IP address.

[0102] The following is a further description of the policy delivery method of this application from the RR device side, such as Figure 7 As shown in the figure, the policy delivery method on the RR device side includes:

[0103] S701: Receive a policy delivery instruction sent by a controller cluster, and update a local policy table according to the policy delivery instruction.

[0104] The policy delivery instruction may be a BGP protocol message. The controller establishes a BGP connection with the RR device and communicates through the BGP protocol.

[0105] The RR device can receive policy delivery instructions from the controller in the controller cluster that has established a BGP connection with the RR device. The controller in the controller cluster that is connected to the RR device sends policy delivery instructions to the RR device through the virtual IP address. After the RR device receives the policy delivery instructions sent by the virtual IP address, it can add, change, or delete the local policy table in the RR device based on the policy delivery instructions.

[0106] S702: Determine whether to perform a full policy update based on the instruction identifier of the policy-issued instruction and the instruction identifier of the previous policy-issued instruction.

[0107] The policy delivery instruction has a unique and incrementing instruction identification ID for each RR device, so the RR device can determine whether there is any missing data during the data synchronization process based on the policy delivery instruction. Even if the RR device is disconnected from the controller and then reconnected, the RR device can determine whether there is any missing data based on the ID of the policy delivery instruction sent by the controller. If so, the RR device can initiate a full policy synchronization request to the controller to update the full policy table.

[0108] Specifically, the RR device can compare the ID of the currently received policy delivery instruction with the ID of the last received policy delivery instruction. If the difference between the ID of the last policy delivery instruction and the ID of the currently received policy delivery instruction is less than or equal to 1, it means that data synchronization is normal. At this time, there is no need to update the full policy table. The RR device continues to maintain connection with the controller and receive policy delivery instructions issued by the controller. If the difference is greater than 1, it means that there are omissions in data synchronization. At this time, the RR device can initiate a full data synchronization request to the controller to perform a full policy update.

[0109] S703: If yes, send a full policy synchronization request to the controller cluster to obtain the full policy table of the RR device, and update the local policy table according to the full policy table.

[0110] 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 use the full policy table as the local policy table of the RR device.

[0111] It should be noted that two RR devices can form a device group, which is connected to the controller. The device group includes a primary RR device and a backup RR device. After the primary RR device completes the update of the current policy, it can synchronize data with the backup RR device. The backup RR device is used to issue policies when the primary RR device fails.

[0112] In the embodiment of the present application, the RR device communicates with the controller cluster through a virtual IP address and receives the policy delivery instructions sent by the controller cluster. The RR device does not need to establish connections 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. In addition, the RR device compares the currently received policy delivery instructions with the last policy delivery instructions saved by itself to determine whether to perform a full update. Even if the RR device is disconnected from the controller and then reconnected, it can determine whether to perform a full data update based on the latest received policy delivery instructions. Compared with the method of fully updating data as long as the connection is reconnected in the prior art, the method of the present application reduces the frequency of fully refreshing SRv6 TE Policy data, thereby reducing the load pressure of the RR device and improving the performance of the RR device.

[0113] When the controller fails, Figure 8 As shown, the method on the RR device side also includes:

[0114] S801. If a controller to which the RR device is connected fails, the local policy table and the last processed policy delivery instruction are retained.

[0115] The RR device maintains a BGP connection with the controller. If the RR device is disconnected from the controller for longer than the preset time threshold, the RR device can determine that the currently connected controller has failed. At this time, the RR device can retain the local policy table and the last processed policy issuance instruction, and send a connection establishment request to the unified IP address of the controller cluster.

[0116] The RR device can use the BGP protocol to send a connection establishment request to the unified IP address, such as initiating a TCP connection. After the load balancer in the controller cluster passes the load, the RR device can establish a TCP connection with any controller in the controller cluster.

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

[0118] In the second implementation, the controller cluster may also send a BGP connection request to the RR device after establishing a TCP connection, so as to establish a BGP neighbor relationship with the RR device.

[0119] S802: Receive a BGP connection request sent by a 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.

[0120] The new controller is a normal controller. The new controller in the controller cluster sends a BGP connection request to the RR device through a unified IP address. After receiving the BGP connection request, the RR device establishes a BGP neighbor relationship with the new controller. The IP address in the BGP neighbor information of the controller stored in the RR device is the unified IP address of the controller cluster.

[0121] S803: Receive the current policy issuing instruction sent by the new controller, and update the local policy table according to the current policy issuing instruction.

[0122] After the new controller establishes a BGP connection with the RR device, it can issue a policy issuance instruction to the RR device. After receiving the policy issuance instruction, the RR device updates the local policy table, such as adding, deleting, and changing the local policy table in the RR device. At the same time, the policy issuance instruction also includes an instruction identifier. The RR device can also determine whether it needs to request a full policy table from the controller based on the instruction identifier in the policy issuance instruction. The process of requesting a full policy table is shown in the above steps S701-S703, and this application will not be repeated here.

[0123] Next, combine Fig. 9 The system interaction logic diagram further illustrates the policy issuance method of this application.

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

[0125] The RR device receives the policy delivery instruction through the BGP protocol process. After receiving the policy delivery instruction, it updates the SRv6 TE Policy table based on the policy delivery instruction and determines whether a full data update is required. If so, it sends a full policy synchronization request to the virtual IP address to achieve data synchronization.

[0126] Fig.10 A structural schematic diagram of a controller provided in an embodiment of the present application is shown. The controller may be an electronic device, which 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 delivery method such as that in the embodiment, the processor 1001 communicates with the storage medium 1002 via the bus 1003, and the processor 1001 executes the machine-readable instructions, and the processor 1001 executes the preamble of the method item to execute the steps in the above-mentioned policy delivery method.

[0127] An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. The computer program is executed when a processor is running, and the processor executes the steps in the above-mentioned policy delivery method.

[0128] In the embodiment of the present application, the computer program can also execute other machine-readable instructions when run by the processor to execute other methods described in the embodiment. For the specific execution method steps and principles, please refer to the description of the embodiment, which will not be repeated here.

[0129] In the embodiments provided in the present application, it should be understood that the disclosed method can be implemented in other ways. The system embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interface, indirect coupling or communication connection of the system or unit, which can be electrical, mechanical or other forms.

[0130] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0132] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0133] It should be noted that similar numbers and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are only used to distinguish the description and are not to be understood as indicating or implying relative importance.

[0134] Finally, it should be noted that the above-described embodiments are only specific implementation methods of the present application, which are used to illustrate the technical solutions of the present application, rather than to limit them. The protection scope of the present application is not limited thereto. Although the present application is described in detail with reference to the above-mentioned embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-mentioned embodiments within the technical scope disclosed in the present application, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application. They should all be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.

Claims

1. A policy delivery method, characterized in that: A controller cluster applied to a network system, the network system further comprising at least one RR device, the controller cluster being deployed with a distributed cache for storing policies, the controller cluster comprising a master controller and at least one slave controller, each controller comprising a policy generation component and a BGP component, each RR device being communicatively connected to a controller in the controller cluster, the method comprising: The policy generation component of the main controller generates a policy issuance instruction according to user service requirements, stores the policy issuance instruction in the policy issuance table, and broadcasts the policy issuance instruction to the BGP components of each controller in the controller cluster; The BGP component of each controller determines whether to issue the policy issuing instruction according to the BGP neighbor information and the RR device indicated by the policy issuing instruction; If so, the policy issuing 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 updates the local policy table according to the instruction identifier in the policy issuing instruction.

2. The method according to claim 1, characterized in that The determining, according to the BGP neighbor information and the RR device indicated by the policy issuing instruction, whether to issue the policy issuing instruction comprises: 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.

3. The method according to claim 1, characterized in that The method further comprises: The main controller determines the faulty controller according to the monitoring information of each controller; If the faulty controller is the master controller, each of the slave controllers elects a new master controller, and uses the unified IP address as the IP address of the new master controller; If the faulty 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 instruction to the target slave controller, so that the target slave controller establishes a connection with the RR device connected to the faulty controller according to the takeover instruction.

4. The method according to claim 3, characterized in that The target slave controller establishes a connection with the RR device connected to the faulty controller according to the takeover instruction, including: The target slave controller sends a BGP connection request to the RR device connected to the faulty controller through the unified IP address, and establishes a BGP connection with the RR device connected to the faulty controller; The target slave controller obtains the current policy issuing instruction of the RR device connected to the faulty controller from the policy issuing table according to the takeover instruction, and sends the current policy issuing instruction to the RR device.

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

6. A policy delivery method, characterized in that: An RR device applied to a network system, the network system further comprising a controller cluster, the RR device being communicatively connected to a controller in the controller cluster, the method comprising: Receive the policy delivery instruction sent by the controller cluster, and update the local policy table according to the policy delivery instruction; Determine whether to perform a full policy update based on the instruction identifier of the instruction issued by the policy and the instruction identifier of the instruction issued by the previous policy; If so, a full policy synchronization request is sent to the controller cluster to obtain the full policy table of the 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 comprises: If the controller to which the RR device is connected fails, the local policy table and the last processed policy delivery instruction are retained; 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-faulty controller; Receive the current policy issuing instruction sent by the new controller, and update the local policy table according to the current policy issuing instruction.

8. A controller, characterized in that: When the controller is running, it is used to execute the steps executed by the controller in the policy delivery method according to any one of claims 1 to 7.

9. An RR device, characterized in that: When the RR device is running, it is used to execute the steps executed by the RR device in the policy delivery method according to any one of claims 1 to 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 is deployed with a distributed cache for storing policies, the controller cluster includes multiple controllers as described in claim 8, and each of the RR devices is communicatively connected to a controller in the controller cluster.

Images