System and method for achieving seamless failover in branch deployment

Abstract

The present disclosure relates to systems and methods for achieving seamless failover in a branch deployment. A clustering solution and a Virtual Router Redundancy Protocol (VRRP) platform are provided for a branch deployment of at least a first gateway and a second gateway. The VRRP platform can be associated with a VRRP Internet Protocol (IP) address and the first gateway can be configured as a VRRP master. The clustering solution can be utilized to determine a change in the operational state of the first gateway. The clustering solution can be utilized to configure the second gateway as a new VRRP master. Network traffic associated with the VRRP Internet Protocol (IP) address can be received. The second gateway can be caused to forward network traffic.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to improving performance of networks, wired and wireless. More specifically, embodiments of the present disclosure relate to ensuring continuity of wireless traffic when a branch gateway forwarding a client's transmission enters an inactive state. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] According to one or more different embodiments, the present disclosure is described in detail with reference to the following drawings. These drawings are provided for illustration purposes only and depict only typical or example embodiments.

[0003] Figure 1 is a block diagram of an exemplary network environment according to an embodiment of the present disclosure.

[0004] Figure 2 is a block diagram of a cluster solution according to an embodiment of the present disclosure.

[0005] Figure 3 is a sequence diagram illustrating exemplary network communication exchanges involved during failure detection of an active user anchor gateway (A-UAG) according to an embodiment of the present disclosure.

[0006] Figure 4A-4B is a sequence diagram illustrating exemplary network communication exchanges involved when the A-UAG and VRRP hosts are respectively different and the same according to an embodiment of the present disclosure.

[0007] Figure 5 A set of executable instructions stored in a machine-readable storage medium is depicted that, when executed, causes one or more hardware processors to perform an illustrative method for providing seamless failover in accordance with an embodiment of the present disclosure.

[0008] Figure 6 are example computing components that can be used to implement various features of the embodiments described in this disclosure.

[0009] In all drawings, the same reference numerals denote similar, but not necessarily identical, elements. The drawings are not necessarily drawn to scale, and the dimensions of certain parts may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0010] Conventionally, a branch deployment of two or more gateways can utilize Virtual Router Redundancy Protocol (VRRP) to provide automatic assignment of available Internet Protocol (IP) routers to participating hosts (e.g., client devices). VRRP is designed to improve the availability and reliability of routing paths via automatic default gateway selection on IP subnets.

[0011] The VRRP protocol achieves this by creating a virtual router, which is an abstract representation of multiple routers (i.e., a primary / active router and a secondary / backup router) as a group. The virtual router that implements the VRRP protocol is assigned as the default gateway for participating hosts instead of the physical router. If the physical router that is routing packets on behalf of the virtual router fails, another physical router is selected to automatically replace it. The physical router that is forwarding packets at any given time is called the primary / active router. VRRP can be used on Ethernet, MPLS, and Token Ring networks with Internet Protocol version 4 (IPv4) as well as IPv6.

[0012] In VRRP, failure to receive multicast packets (i.e., keep-alive packets) from the primary / active router for a period of time exceeding three times the advertisement timer causes the secondary / backup router to assume that the primary / active router has failed. An election process is initiated to elect the next primary / active router from the secondary / backup routers. Generally speaking, the advertisement timer can be defaulted to 1 second, and the failover period can be 3 seconds.

[0013] For critical / time-sensitive applications, the failover period may be unacceptably long. Furthermore, VRRP does not share client sessions and state between gateways, and thus does not perform failover seamlessly (e.g., without excessive delays in failover and / or without requiring reauthentication / reauthorization of sessions and state). Therefore, an improved failover mechanism beyond that provided by VRRP is desired.

[0014] A branch deployment of a gateway usually has two gateways, which are connected at Layer 2. Typically, VRRP provides a virtual IP address of the default gateway to the access point. Clients connected to the access point can use the virtual IP address of the default gateway, and the access point can direct client traffic to the virtual IP address. When the gateway configured as the VRRP master becomes inactive (e.g., device failure), the gateway configured as the VRRP backup can forward client traffic instead of the gateway configured as the VRRP master. In the VRRP protocol, the VRRP backup detects the failure of the VRRP master based on the failure to receive a keep-alive packet sent by the VRRP master to the VRRP backup. Failure detection requires a time in seconds (e.g., 3 seconds). Since failover (e.g., switching) between the VRRP master and the VRRP backup may adversely affect time-sensitive client traffic, the detection time may be unacceptable. In addition, VRRP does not share client session information between the VRRP master and the VRRP backup, and some critical client traffic (e.g., Voice over Internet Protocol (VoIP)) may be lost during failover. Therefore, VRRP alone is not sufficient to provide seamless failover for clients.

[0015] An improved method derived from computer technology overcomes the above and other disadvantages associated with traditional methods particularly found in the field of computer technology. Based on computer technology, the disclosed technology can provide an improved technology that significantly reduces delays in failover. In addition, the disclosed technology can share client sessions and states between gateways so that no client traffic is lost during failover.

[0016] Figure 1 1 is a block diagram 100 of an exemplary network environment according to an embodiment of the present disclosure. Block diagram 100 illustrates traffic flows between multiple client devices, access points, and gateways (e.g., branch gateways). Gateways 114, 116 may include a gateway cluster 122 within communication network 100. Figure 1 , both access points 110 and 112 may be within the control range of the gateway cluster 122 .

[0017] The gateway cluster 122 may provide a redundancy protocol (e.g., VRRP) between its gateways 114, 116. The active gateway 114 may serve as a primary gateway for the access points 110, 112 and the clients (e.g., client devices) 102, 104, 106, 108. The active gateway 114 may store client sessions and states. If the active gateway 114 becomes inactive, the standby gateway 116 serves as a backup gateway. The standby gateway 116 may communicate with the active gateway 114 to store backup copies of the client sessions and states of the clients 102, 104, 106, 108. In a redundancy protocol, the gateway cluster 122 may provide the access points 110, 112 and the clients 102, 104, 106, 108 with a single Internet Protocol (IP) address to communicate with the gateway cluster 122. When the active gateway 114 is operational, client traffic transmitted using the IP address will arrive at the active gateway 114. If the active gateway 114 becomes inactive (e.g., fails, is offline, is placed in a suspended state, is placed in a disabled state, etc.), at least one of the clustering solutions 118, 120 of the gateways 114, 116 may configure the standby gateway 116 to take over (e.g., failover or switchover) the forwarding of client traffic previously forwarded through the active gateway 114. Figure 3 Provides further details about failover.

[0018] Figure 2 is a block diagram 200 of a cluster solution 202 according to an embodiment of the present disclosure. The cluster solution 202 may be similar to Figure 1 The cluster solution 202 may include an operation state module 204, a session synchronization module 206, a control transmission module 208, and a VRRP module 210. The cluster solution 202 may provide various functions related to providing seamless failover between two or more gateways. As a function, the cluster solution 202 may determine an active gateway (e.g., Figure 1 The cluster solution 202 can synchronize the active gateway and the standby gateway (e.g., Figure 1The cluster solution 202 may be configured to communicate with and maintain client sessions and states between active and standby gateways 116). As yet another function, the cluster solution 202 may switch control back and forth between the active gateway and the standby gateway (e.g., perform failover / conversion). In some embodiments, the cluster solution 202 may leverage or otherwise overlay an existing VRRP protocol through interaction with the VRRP module 210. In some embodiments, the cluster solution 202 may be implemented in each of the active and standby gateways to control the operation of the gateways. Depending on whether the gateway is configured as an active gateway or a standby gateway, the cluster solution 202 executed in each gateway may perform different functions to communicate with each other to establish seamless failover between gateways. The modules in this figure and all figures herein are exemplary only, and other embodiments may include additional, fewer, integrated, or different components. Some modules may not be shown to avoid obscuring the relevant details.

[0019] In some embodiments, the various modules and / or applications described herein may be implemented in part or in whole as software, hardware, or any combination thereof. Typically, as discussed herein, modules and / or applications may be associated with software, hardware, or any combination thereof. In some embodiments, one or more functions, tasks, and / or operations of modules and / or applications may be performed or executed by software routines, software processes, hardware, and / or any combination thereof. In some cases, the various modules and / or applications described herein may be implemented in part or in whole as software running on one or more computing devices or systems, such as software running on a network computing device or on a server. For example, one or more modules and / or applications described herein, or at least a portion thereof, may be implemented as or implemented within an application (e.g., app), a program, or a small application, etc. running on a network computing device or system. A network computing device or system may be one or more hubs, repeaters, bridges, switches, routers, gateways, routers, etc. In another example, one or more modules and / or applications, or at least a portion thereof, may be implemented using one or more computing devices or systems including one or more servers such as a network server or a cloud server. It should be understood that there may be many variations or other possibilities.

[0020] The operational status module 204 can be configured to detect active gateways (e.g., Figure 1 For cluster solution 202 executed on an active gateway, the operational status module 204 may be configured to provide a backup gateway (e.g., Figure 1 The cluster heartbeat can be from a gateway (e.g., Figure 1 active gateway 114) to other gateways (e.g., Figure 1 The operation status module 204 may provide a cluster heartbeat periodically, aperiodically, synchronously, or asynchronously. The rate of cluster heartbeats provided by the operation status module 204 may be much greater (e.g., more frequent) than the rate of keep-alive packets provided according to a conventional VRRP protocol. For example, cluster heartbeats may be provided at intervals of 1 millisecond to 1000 milliseconds, which is much shorter than the VRRP keep-alive packets provided at intervals of 1 second. The greatly increased cluster heartbeat rate may ensure that other gateways may quickly determine the operation status of the gateway without having to wait a long time to receive keep-alive packets from the gateway according to a conventional VRRP protocol.

[0021] For the cluster solution 202 executed on the standby gateway, the operational status module 204 can monitor the cluster heartbeats from the active gateway. When the operational status module 204 does not receive one or more cluster heartbeats from the active gateway, the operational status module 204 can determine that the active gateway is in an inactive state. The inactive state can be caused by a variety of reasons, including the active gateway failing, being offline, being placed in a suspended state, being placed in a disabled state, etc. Upon determining the inactive state of the active gateway, the standby gateway can notify the control switching module 208 that the standby gateway needs to be configured as a new VRRP master. Figure 3 More details are provided regarding the operating status module 204 .

[0022] The session synchronization module 206 can be configured to synchronize the client session and the state visible to one of the gateways to the other gateway. Figure 1 The client session and state of the active gateway 114) is compared with the standby gateway (e.g., Figure 1 The backup gateway 116) can be synchronized by the client (for example, Figure 1Examples of sessions opened and used by clients 102, 104, 106, 108) include, but are not limited to, HTTP sessions, FTP sessions, Real-time Transport Protocol (RTP) sessions, Simple Mail Transfer Protocol (SMTP) sessions, Domain Name System (DNS) sessions, Transmission Control Protocol / Internet Protocol (TCP / IP) sessions, etc. Examples of states that can be maintained for a standby gateway may include, for example, L2 and L3 user information, authentication / accounting keys, and IDs. Typically, a client may time out each of its client sessions and / or states, and when the active gateway enters an inactive state, the client session and / or state may be lost. In such instances, traditional technologies such as VRRP may cause some client services to be lost, requiring the client to go through a reauthentication process again. In contrast, the disclosed technology synchronizes such client sessions and states between the active gateway and the standby gateway so that the standby gateway can be aware of the client sessions and states. Therefore, the standby gateway can seamlessly assume the role of the active gateway and client services.

[0023] For cluster solutions 202 executed on active gateways, session synchronization module 206 may be configured to provide client sessions and the status of the active gateway to the standby gateway. For cluster solutions 202 executed on standby gateways, session synchronization module 206 may receive or monitor client sessions and status from the active gateway and maintain client sessions and status. In some embodiments, some or all of the client sessions and status may be synchronized between the two gateways. In some other embodiments, some of the client sessions and status may be selectively synchronized based on their importance or criticality.

[0024] The control transfer module 208 may be configured to transfer control from one gateway to another. For example, the control transfer module 208 may transfer control from an active gateway to a standby gateway, or vice versa. In some embodiments, the control transfer module 208 may implement control transfer by driving the VRRP state of the standby gateway. As described with respect to the cluster solution 202, the cluster solution 202 may be superimposed on the traditional VRRP to supplement, replace, modify, or control some or all of the functions and features of the traditional VRRP. For example, the operation state module 204 of the cluster solution 202 may replace the keep-alive packets of the traditional VRRP with the above-mentioned cluster heartbeat. As another example, the control transfer module 208 of the cluster solution may drive / modify the VRRP state of the traditional VRRP. The control transfer module 208 may enable the standby gateway to become a new VRRP master within a time range of 1 millisecond to 1000 milliseconds by driving the VRRP state in response to determining that the active gateway has become inactive. In some embodiments, the control transfer module 208 executed on the standby gateway may enable the standby gateway to become a new VRRP master.

[0025] VRRP module 210 may be configured to provide some or all of the functionality of conventional VRRP. VRRP module 210 may be configured to execute on one or more gateways themselves. For example, an active gateway (e.g., Figure 1 The active gateway 114) can be configured as a VRRP master, and the backup gateway (e.g., Figure 1 The backup gateway 116 of the VRRP module 210 can be configured as a VRRP backup. In addition, the VRRP module 210 is different from the traditional VRRP in that the VRRP states of the VRRP master and VRRP backup are driven by the cluster solution 202 superimposed on the VRRP module 210. In other words, the cluster solution 202 can realize the configuration of the gateway as a VRRP master or a VRRP member.

[0026] like Figure 2 As shown in FIG. 2 , the cluster solution 202 may be configured to communicate with a data store 212. The data store 212 may be configured to store and maintain various types of data to support the functionality of the cluster solution 202. For example, the data store 212 may store and maintain timestamps associated with cluster heartbeats, operational states of gateways, client traffic, client sessions and states, VRRP states, etc. for the operational state module 204, the session synchronization module 206, the control transmission module 208, and the VRRP module 210.

[0027] Figure 3 3 is a sequence diagram 300 illustrating exemplary network communication exchanges involved during failure detection of an active user-anchored gateway (A-UAG) according to an embodiment of the present disclosure. Figure 2 The cluster solution 202 can configure the first gateway 302 as a leader gateway. The first gateway 302 can be connected to Figure 1 The cluster solution 202 can also configure the second gateway 304 as a gateway cluster (e.g., Figure 1 The second gateway 304 can be connected to the member gateway of the gateway cluster 122. Figure 1 The leader gateway (i.e., the first gateway 302) may publish a bucket map. The bucket map may be published to an access point (e.g., Figure 1 The bucket mapping may designate the first / leader gateway 302 as an A-UAG and the second / member gateway 304 as a standby user anchor gateway (S-UAG), thereby directing client traffic to the first / leader gateway 302.

[0028] The cluster solution may listen for the creation of an instance of VRRP for a virtual local area network (VLAN) 306. Upon detecting the creation, the cluster solution 202 may publish information where the first / leader gateway 302 is configured as a VRRP master gateway 308 and the second / member gateway 304 is configured as a VRRP backup 310. In addition, the VRRP Internet Protocol (IP) address may be configured to always be owned by the first / leader gateway 302. Information about the VRRP configuration, including the VRRP IP address, may be provided to the access point (e.g., Figure 1 access points 110, 112) and clients (e.g., Figure 1 102, 104, 106, 108), and then to the gateway cluster (e.g., Figure 1 In some embodiments, the client may obtain a VRRP IP address from a Dynamic Host Configuration Protocol (DHCP) server running on the first / leader gateway 302 or the second / member gateway 304. A default gateway may be associated with the VRRP IP, which may always be owned by the first / leader gateway 302.

[0029] The first / leader gateway 302 may synchronize client sessions and states 314 with the second / member gateway 304. In addition, the second / member gateway 304 may receive a heartbeat 316 from the first / leader gateway 302. During operation of the gateway cluster, the first / leader gateway 302 may become inactive and stop providing its heartbeat to the second / member gateway 304. When the second / member gateway 304 fails to receive a heartbeat 318 from the first / leader gateway 302, the second / member gateway 304 may be configured as a new VRRP master 320. The process of detecting the inactive operational state of the first / leader gateway 302 and configuring the second / member gateway 304 to forward client traffic may be completed in less than one second. In addition, since the client sessions and states are synchronized between the two gateways 302, 304, failover / transfer may be seamless without any client experiencing significant delays or loss of network traffic.

[0030] After a period of time, the first / leader gateway 302 may become active again 322. When the first / leader gateway 302 becomes active again, the cluster leader election algorithm may ensure that the gateway designated as the A-UAG is again configured as the VRRP master. Here, the first / leader gateway 302 is the A-UAG, and therefore, the first / leader gateway 302 is elected as the VRRP master 324. Similarly, the second / member gateway 304 becomes the VRRP backup again 326. Future client traffic may again be received by the first / leader gateway 302.

[0031] Figure 3 The configuration described in can improve the forwarding of client traffic in a VRRP master-standby model by eliminating unnecessary hops (e.g., east-west traffic). For example, in the case where the A-UAG is different from the VRRP master, the received client traffic may have undesirable additional hops. FIG. 4A to FIG. 4B are sequence diagrams 400 , 450 illustrating exemplary network communication exchanges involved when the A-UAG and VRRP hosts are respectively different and the same according to an embodiment of the present disclosure.

[0032] Figure 4A shows the undesirable additional hops when the A-UAG and VRRP hosts are not the same. Figure 2 and Figure 3 As mentioned above, due to cluster solutions (e.g. Figure 2 The cluster solution 202) can affect VRRP host election in the same way as A-UAG, and therefore, is provided as Figure 4B Comparison example of the scene Figure 4A The scenario can prevent the VRRP master and A-UAG from being the same, where the VRRP master and A-UAG are configured the same. In the timing diagram 400, the first gateway 406 is configured as an A-UAG and a VRRP backup. In addition, the second gateway 408 is configured as an S-UAG and a VRRP master. Figure 4A , the first gateway 406 publishes the bucket mapping 410 to the access point 404, which directs the client traffic to the first gateway 406. A DHCP server running on the first gateway 406 or the second gateway 408 can provide the client 402 with a VRRP IP address.

[0033] Client 402 can use the VRRP IP address as the destination IP address to reach the gateway cluster (e.g., Figure 1 The client 402 provides client traffic 414 destined for the VRRP master to the access point 404. The access point 404 receives the client traffic and forwards the client traffic to the first gateway 406 as a VRRP backup based on the bucket mapping 410 that directs the incoming client traffic to the A-UAG 406. Figure 4A In the configuration of , since the second gateway 408 is configured as a VRRP master, the first gateway 406 forwards the client traffic to the second gateway 408. This forwarding is an undesirable additional hop 418 for the client traffic. Figure 4A In the scenario of , because the A-UAG and VRRP hosts are not the same, the client traffic experiences an additional hop 418 to reach its default gateway (i.e., the second gateway 408) from the first gateway (i.e., A-UAG). The additional hop 418 may result in increased latency for time-sensitive applications.

[0034] Figure 4B 450, a first gateway 456 is configured as an A-UAG and a VRRP master. Additionally, a second gateway 458 is configured as an S-UAG and a VRRP backup. In some embodiments, the cluster leader may publish bucket mappings in such a way that all buckets (e.g., indices associated with gateways that direct incoming client traffic) reference the cluster leader as the A-UAG to ensure that all client traffic reaches the cluster leader. For example, in Figure 4B In the example, the first gateway 456 is the cloud leader and is configured as an A-UAG. At the same time, the cluster leader can also affect the VRRP state of the first gateway 456 and the second gateway 458 to ensure that the cluster leader (i.e., the first gateway 456) is the VRRP master and the non-leader gateway (i.e., the second gateway 458) becomes the VRRP backup. The DHCP server running on the first gateway 456 or the second gateway 458 can provide the VRRP IP address to the client 452. The gateway cluster can be deployed in active-standby or one-to-one redundant mode.

[0035] Client 452 can use the VRRP IP address as a way to reach the gateway cluster (e.g., Figure 1 The client 452 provides client traffic 464 with the VRRP master as the destination to the access point 454. The access point 454 receives the client traffic and forwards the client traffic to the first gateway 456 which is the VRRP master based on the bucket mapping that directs the incoming client traffic to the A-UAG 456. Figure 4B In the configuration of , since the first gateway 456 is configured as a VRRP host in addition to being configured as an A-UAG, the first gateway 456 does not need to forward the client service to the second gateway 458. Therefore, Figure 4A The undesirable additional jump 418 in the scenario shown in Figure 4B Removed from the scene shown in .

[0036] The second gateway 458 can detect that the first gateway 456 has become inactive 468 based on the cluster heartbeat. Upon detecting such an event, the second gateway 458 can trigger the client service to switch from the first gateway 456 to the second gateway 458 and become the new VRRP host 470. In some embodiments, the second gateway 458 (i.e., S-UAG) can trigger the client service switching by sending a node list, an active node list to the access point 454. Since the node list does not contain the first gateway 456 (i.e., A-UAG), the access point 454 can determine that A-UAG 456 is inactive. The access point 454 can then direct the client service to the S-UAG 458 in the bucket mapping. Since the client session is synchronized from the first gateway 456 to the second gateway 458, the switch is seamless throughout the scenario.

[0037] When the first gateway 456 becomes operational again, the cluster leader election algorithm can ensure that the A-UAG election again effects the re-election of the first gateway 456 as the VRRP master.

[0038] Figure 5 Depicted is a computing component 500 that includes one or more hardware processors 502 and a machine-readable storage medium 504 storing a set of machine-readable / machine-executable instructions that, when executed, cause the hardware processor 502 to perform an illustrative method for combining feature values ​​according to an example embodiment of the present invention. The computing component 500 may be, for example, Figure 6 The computing system 600 depicted in FIG. 1 , or another computing device described herein. The hardware processor 502 may include, for example, Figure 6 The processor 604 depicted in , or any other processing unit described herein. The machine-readable storage medium 504 may include a main memory 606, a read-only memory (ROM) 608, a storage 610, or any other suitable machine-readable storage medium described herein.

[0039] At block 506, in an example embodiment, instructions may be executed by the hardware processor 502 to provide a cluster solution and a Virtual Router Redundancy Protocol (VRRP) platform for a branch deployment of at least a first gateway and a second gateway. The VRRP platform may be associated with a VRRP Internet Protocol (IP) address and the first gateway may be configured as a VRRP master.

[0040] At block 508 , in an example embodiment, instructions may be executed by the hardware processor 502 to determine a change in an operational state of the first gateway utilizing a clustering solution.

[0041] At block 510 , in an example embodiment, instructions may be executed by the hardware processor 502 to enable a second gateway to be configured as a new VRRP master utilizing a clustering solution.

[0042] At block 512, in an example embodiment, the hardware processor 502 may execute instructions to receive network traffic associated with a VRRP Internet Protocol (IP) address.

[0043] At block 514, in an example embodiment, the hardware processor 502 may execute instructions to cause the second gateway to forward the network traffic.

[0044] Figure 6 A block diagram of an example computer system 600 is depicted in which various embodiments described herein may be implemented. Computer system 600 includes a bus 602 or other communication mechanism for communicating information, one or more hardware processors 604 coupled to bus 602 for processing information. Hardware processor 604 may be, for example, one or more general purpose microprocessors.

[0045] The computer system 600 also includes a main memory 606, such as a random access memory (RAM), cache, and / or other dynamic storage device, coupled to the bus 602 for storing information and instructions to be executed by the processor 604. The memory 606 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 604. These instructions, when stored in a storage medium accessible to the processor 604, make the computer system 600 a special-purpose machine that is customized to perform the operations specified in the instructions.

[0046] The computer system 600 also includes a read only memory (ROM) 608 or other static storage device coupled to the bus 602 for storing static information and instructions for the processor 604. A storage device 610, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), is provided and coupled to the bus 602 for storing information and instructions.

[0047] The computer system 600 may be coupled to a display 612, such as a liquid crystal display (LCD) (or touch screen), via the bus 602 for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to the bus 602 for communicating information and command selections to the processor 604. Another type of user input device is a cursor control 616, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 604 and for controlling cursor movement on the display 612. In some embodiments, the same direction information and command selections as the cursor control may be implemented without a cursor via receiving touches on a touch screen.

[0048] The computing system 600 may include a user interface module for implementing a GUI, which may be stored in a mass storage device as executable software code executed by a computing device. By way of example, this module and other modules may include components such as software components, object-oriented software components, class components, and task components, procedures, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0049] Any of the foregoing engines or modules may be embodied as a computing component of the computing system 600. For example, Figure 2 The cluster solution 202 , the operation state module 204 , the session synchronization module 204 , the control switching module 206 , and the VRRP module 210 may be embodied as computing components of the computing system 600 .

[0050] In general, as used herein, the terms "component", "engine", "system", "database", "data storage", etc. may refer to logic contained in hardware or firmware, or to a collection of software instructions written in a programming language such as Java, C or C++, which may have entry points and exit points. Software components may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as BASIC, Perl or Python. It will be appreciated that software components may be called from other components or from themselves, and / or may be called in response to detected events or interrupts. Software components configured for execution on a computing device may be provided on a computer-readable medium such as an optical disc, digital video disc, flash drive, disk, or any other tangible medium, or as a digital download (and may be initially stored in a compressed or installable format, requiring installation, decompression or decryption before execution). Such software code may be stored in part or in whole on a memory device of the executing computing device for execution by the computing device. Software instructions may be embedded in firmware such as an EPROM. It will also be appreciated that hardware components may include connected logic units such as gates and flip-flops, and / or may include programmable units such as programmable gate arrays or processors.

[0051] The computer system 600 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that are combined with the computer system to enable the computer system 600 or be programmed as a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 600 in response to the processor 604 executing one or more sequences of one or more instructions contained in the main memory 606. Such instructions may be read into the main memory 606 from another storage medium such as the storage device 610. Execution of the sequences of instructions contained in the main memory 606 causes the processor 604 to perform the processing steps described herein. In alternative embodiments, hardwired circuits may be used in place of or in combination with software instructions.

[0052] As used herein, the term "non-transitory media" and similar terms refer to any media that stores data and / or instructions that cause a machine to operate in a particular manner. Such non-transitory media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 610. Volatile media include dynamic memory, such as main memory 606. Common forms of non-transitory media include, for example, floppy disks, diskettes, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassettes, and network versions thereof.

[0053] Non-transitory media are distinct from transmission media but may be used in conjunction with transmission media. Transmission media participate in the transmission of information between non-transitory media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up bus 602. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0054] Computer system 600 also includes a communication interface 618 coupled to bus 602. Network interface 618 provides a bidirectional data communication coupling to one or more network links connected to one or more local networks. For example, communication interface 618 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, network interface 618 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or a WAN component that communicates with a WAN). Wireless links can also be implemented. In any such implementation, network interface 618 sends and receives electrical, electromagnetic, or optical signals carrying digital data streams representing various types of information.

[0055] A network link typically provides data communication to other data devices through one or more networks. For example, a network link can provide a connection to a host or data equipment operated by an Internet Service Provider (ISP) through a local network. The ISP, in turn, provides data communication services through the global packet data communication network now commonly referred to as the "Internet." Both the local network and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link and through the communication interface 618 are example forms of transmission media that carry digital data into and out of the computer system 600.

[0056] Computer system 600 can send messages and receive data, including program code, through the network, network link and communication interface 618. In the Internet example, a server can send the requested code for an application through the Internet, ISP, local network and communication interface 618.

[0057] The received code may be executed by processor 604 as it is received, and / or stored in storage device 610 or other non-volatile storage for later execution.

[0058] Each of the processes, methods, and algorithms described in the foregoing sections may be embodied in a code component executed by one or more computer systems or computer processors including computer hardware, and fully or partially automated by the code component. One or more computer systems or computer processors may also operate to support the performance of related operations in a "cloud computing" environment or as "software as a service" (SaaS). The processes and algorithms may be implemented in part or in whole in a dedicated circuit. The various features and processes described above may be used independently of each other, or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of the present disclosure, and certain methods or process blocks may be omitted in some embodiments. The methods and processes described herein are also not limited to any particular order, and the boxes or states associated therewith may be executed in other appropriate orders, or may be executed in parallel, or in some other ways. Blocks or states may be added to or removed from the disclosed example embodiments. The performance of a particular operation or process may be distributed between computer systems or computer processors, not only residing in a single machine, but also deployed on multiple machines.

[0059] As used herein, circuits can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms can be implemented to form circuits. In an embodiment, the various circuits described herein can be implemented as discrete circuits, or the functions and features described can be partially or completely shared between one or more circuits. Although various features or functional elements can be described or claimed separately as separate circuits, these features and functions can be shared between one or more common circuits, and such descriptions should not require or imply that separate circuits are needed to implement such features or functions. In the case where the circuit is implemented in whole or in part using software, such software can be implemented as operating together with a computing or processing system such as a computer system 600 that can perform the functions described therein.

[0060] As used herein, the term "or" may be interpreted as inclusive or exclusive. In addition, descriptions of resources, operations, or structures in the singular should not be understood to exclude the plural. Unless otherwise specifically stated, conditional language such as "can," "might," "may," or "could," or otherwise understood in the context of use, is generally intended to convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not include implementation of the certain features, elements, and / or steps.

[0061] Unless expressly stated otherwise, the terms and phrases used in this document and variations thereof should be interpreted as open ended and not restrictive. Adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning should not be interpreted as limiting the items described to a given time period or to items available at a given time, but should be interpreted as including conventional, traditional, normal, or standard technology available or known at any time now or in the future. In some examples, the presence of broad words and phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be interpreted to mean that a narrower situation is intended or required in instances where such broad phrases may not be present.

[0062] In this disclosure, unless the context clearly indicates otherwise, the use of singular terms is also intended to include the plural forms. In addition, when used in this disclosure, the terms "comprises," "comprising," "containing," "covering," "having," or "having" specify the presence of stated elements, but do not exclude the presence or addition of other elements.

Claims

1. A method comprising: providing a cluster including a first gateway and a second gateway, the first gateway and the second gateway applying a Virtual Router Redundancy Protocol (VRRP) and implemented on one or more computers, wherein the first gateway is initially a VRRP leader gateway and the second gateway is initially a VRRP backup gateway, and wherein the cluster including the first gateway and the second gateway is associated with a VRRP Internet Protocol (IP) address; receiving, by the second gateway from the first gateway, gateway state information of a gateway state of the first gateway and client session information of a client session using the VRRP IP address, thereby synchronizing the gateway state and the client session between the first gateway and the second gateway, wherein the gateway state includes authentication information; receiving, by the second gateway, a keep-alive message of the VRRP and a heartbeat message from the first gateway, the heartbeat message indicating whether the first gateway is operational, wherein the heartbeat message is different from the keep-alive message of the VRRP and an interval between the heartbeat messages is smaller than an interval between the keep-alive messages of the VRRP; determining, by the second gateway, that the first gateway is in an inactive state based on a lack of a predetermined number of heartbeat messages from the first gateway; Based on determining that the first gateway is in the inactive state, configuring the second gateway to operate as a new VRRP leader gateway; receiving, by the second gateway, network traffic associated with the VRRP IP address from a client; and The network traffic is forwarded by the second gateway based on the client session information received from the first gateway.

2. The method according to claim 1, further comprising: When serving as the VRRP leader gateway, the first gateway publishes the following information to an access point (AP), the information designating the first gateway as active and the second gateway as backup; as well as When serving as the VRRP leader gateway, the first gateway receives network traffic directed to the first gateway from the AP based on the published information, wherein the network traffic comes from the client and is addressed to the VRRP IP address.

3. The method according to claim 2, comprising: triggering a switch from the first gateway to the second gateway as the new VRRP leader gateway by sending a list of active nodes from the second gateway to the AP, wherein the list of active nodes does not include the first gateway; as well as When serving as the new VRRP leader gateway, based on the published information and the list of active nodes, the second gateway receives additional network traffic directed to the second gateway from the AP, wherein the additional network traffic comes from the client and is addressed to the VRRP IP address. 4 . The method of claim 3 , wherein the list of active nodes not including the first gateway causes the AP to determine that the first gateway has become inactive.

5. The method of claim 1, wherein configuring the second gateway as the new VRRP leader gateway takes less than one second.

6. The method of claim 1, wherein the first gateway comprises a Dynamic Host Configuration Protocol (DHCP) server, the method further comprising: The VRRP IP address is provided to the client by the DHCP server in the first gateway.

7. The method of claim 6, wherein the client is coupled to an access point (AP) via a wireless link, and the network traffic from the client is received by the AP via the wireless link.

8. A system comprising: a cluster including a first gateway and a second gateway, the first gateway and the second gateway applying a Virtual Router Redundancy Protocol (VRRP) and implemented on one or more computers, wherein the first gateway is initially a VRRP leader gateway and the second gateway is initially a VRRP backup gateway, and the cluster including the first gateway and the second gateway is associated with a VRRP Internet Protocol (IP) address; The second gateway is used to: receiving, from the first gateway, gateway state information of a gateway state of the first gateway and client session information of a client session using the VRRP IP address, thereby synchronizing the gateway state and the client session between the first gateway and the second gateway, the gateway state including authentication information; receiving, at the second gateway, a keep-alive message of the VRRP and a heartbeat message from the first gateway, the heartbeat message indicating whether the first gateway is operational, wherein the heartbeat message is different from the keep-alive message of the VRRP, and wherein an interval between the heartbeat messages is less than an interval between the keep-alive messages of the VRRP; determining, at the second gateway, that the first gateway is in an inactive state based on an absence of a predetermined number of heartbeat messages from the first gateway; Based on determining that the first gateway is in the inactive state, configuring the second gateway to operate as a new VRRP leader gateway; receiving, at the second gateway, network traffic associated with the VRRP IP address from a client device; and The network traffic is forwarded by the second gateway based on the client session information received from the first gateway.

9. The system of claim 8, wherein the first gateway, when serving as a VRRP leader gateway, is configured to: publishing information to an access point (AP) that designates the first gateway as active and the second gateway as backup; and When serving as the VRRP leader gateway, network traffic directed to the first gateway from the AP is received at the first gateway based on the published information, wherein the network traffic comes from the client device and is addressed to the VRRP IP address.

10. The system according to claim 9, wherein the second gateway is used to: triggering a switch from the first gateway to the second gateway as the new VRRP leader gateway by sending a list of active nodes from the second gateway to the AP, wherein the list of active nodes does not include the first gateway; and When serving as the new VRRP leader gateway, based on the published information and the list of active nodes, receiving at the second gateway additional network traffic directed from the AP to the first gateway, wherein the additional network traffic comes from the client and is addressed to the VRRP IP address.

11. The system of claim 8, wherein configuring the second gateway as the new VRRP leader gateway takes less than one second.

12. The system of claim 8, wherein the first gateway comprises a Dynamic Host Configuration Protocol (DHCP) server to provide the VRRP IP address to the client device, and The client device is coupled to an access point (AP) via a wireless link, and the network traffic from the client device is received by the AP via the wireless link.

13. A non-transitory computer-readable storage medium comprising instructions that, when executed, cause a system to: providing a cluster including a first gateway and a second gateway, the first gateway and the second gateway applying a Virtual Router Redundancy Protocol (VRRP) and implemented on one or more computers, wherein the first gateway is initially a VRRP leader gateway and the second gateway is initially a VRRP backup gateway, and wherein the cluster including the first gateway and the second gateway is associated with a VRRP Internet Protocol (IP) address; receiving, by the second gateway from the first gateway, gateway state information of a gateway state of the first gateway and client session information of a client session using the VRRP IP address, thereby synchronizing the gateway state and the client session between the first gateway and the second gateway, wherein the gateway state includes authentication information; receiving, by the second gateway, a keep-alive message of the VRRP and a heartbeat message from the first gateway, the heartbeat message indicating whether the first gateway is operational, wherein the heartbeat message is different from the keep-alive message of the VRRP and an interval between the heartbeat messages is smaller than an interval between the keep-alive messages of the VRRP; determining, by the second gateway, that the first gateway is in an inactive state based on a lack of a predetermined number of heartbeat messages from the first gateway; Based on determining that the first gateway is in the inactive state, configuring the second gateway to operate as a new VRRP leader gateway; receiving, by the second gateway, network traffic associated with the VRRP IP address from a client; and The network traffic is forwarded by the second gateway based on the client session information received from the first gateway.

14. The non-transitory computer-readable storage medium of claim 13, wherein the instructions, when executed, cause the system to: When serving as the VRRP leader gateway, the first gateway publishes the following information to an access point (AP), the information designating the first gateway as active and the second gateway as backup; and When serving as the VRRP leader gateway, based on the published information, network traffic directed to the first gateway from the AP is received at the first gateway, wherein the network traffic comes from the client and is addressed to the VRRP IP address.

15. The non-transitory computer-readable storage medium of claim 13, wherein configuring the second gateway as the new VRRP leader gateway takes less than one second.

16. The non-transitory computer-readable storage medium of claim 13, wherein the first gateway comprises a Dynamic Host Configuration Protocol (DHCP) server to provide the VRRP IP address to the client.

17. The non-transitory computer-readable storage medium of claim 13, wherein the client session comprises a session opened and used by the client.

Images