Failure detection and seamless traffic switchover using a VPN system

Example implementation relates to a method of failure detection and seamless traffic switchover in a VPN system. A cluster of nodes exchange heartbeat messages to detect a failure at a first node in the cluster. When failure is detected at the first node, a master node transmits a failover message to a network end node connected to the first node. The failover message includes a list of active nodes to which traffic may be routed. The network end node updates its routing table based on the failover message and switches the traffic to a second node in the cluster of nodes.

BACKGROUND

A Virtual Private Network (VPN) allow users to establish secure, private communications channels over unsecured public networks such as the Internet. A VPN connection is formed by securing communications between two or more networks or network elements by encrypting or encapsulating transmissions between the networks or network elements.

A VPN system manages the VPN connections. The VPN connections are also referred to as VPN tunnels. Networking devices may be employed to establish and configure these VPN tunnels. The VPN system authenticates devices initiating communication, assigns VPN tunnels to requesting devices and manages traffic received at the network devices in the VPN system. Using the VPN system enables information to be exchanged securely between geographically dispersed sites without obtaining dedicated resources through the network.

DETAILED DESCRIPTION

The terminology used herein is for the purpose of describing example embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “plurality,” as used herein, is defined as two, or more than two. It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context indicates otherwise. As used herein, the term “includes” means includes but not limited to, the term “including” means including but not limited to. The term “based on” means based at least in part on.

Through the disclosure, the terms “route table” and “routing table” have been used interchangeably.

The network deployments of a large organizations may include multiple users (or at least multiple client devices) at multiple physical or geographical sites. Access to secure resources of the organization may be through a Virtual Private Network (VPN) system. The client devices from multiple physical sites may be connected to Access Points (AP) or branch gateway (BG) which communicate with a VPN system that provides access to secure resources of the organization. The VPN system may have a cluster of nodes which provide communication connection between the AP/BG and the secure resources of the organization.

The VPN system ensures that the service to the client devices is seamless in case of failure of a link or a node in the VPN system. On detection of failure of a node or link, the AP/BG connected to the client device switches to an active node or active link and the communication continues.

Currently, the detection of failure is done by sending keep alive packets or messages from each AP/BG to the nodes in the VPN system. A failure of node or link may detected when there is no acknowledgement from the node to which the keep alive message was sent. In some cases, a pre-configured time period may be defined for receiving the acknowledgment. In addition, the keep alive messages may be sent multiple times. Any AP/BG detecting failure of node or link may report the failure to AP/BG which uses the node or link for routing traffic. When the AP/BG receives a node or link failure, the routing table of the AP/BG is updated and traffic is routed through an alternate route. In addition, the exchange of keep alive messages sent by each AP/BG to the VPN nodes results in the consumption of additional bandwidth.

The detection of node or link failure may take time based on the number of times the keep alive message is sent before detecting failure or the pre-configured time. The detection of failure using keep alive messages may take anywhere between 8 to 30 seconds depending and may cause service disruption for client devices. For example, voice calls may get affected for a short period until the switching to the alternate route take place. To prevent service disruptions and provide a seamless user experience, the detection of failure and switchover to alternate route should happen in a quick and efficient manner.

An example implementation relates to a method of failure detection and seamless traffic switchover in a VPN system. A cluster of nodes exchange heartbeat messages between each other to detect a failure at a node in the cluster. When a failure is detected at a first node in the cluster, a master node transmits a failover message to a network end node connected to the first node. The failover message includes a list of active nodes to which traffic may be routed. The network end node updates its routing table based on the failover messages and switches the traffic to a second node in the cluster of nodes.

FIG.1illustrates one example of a network configuration that may be implemented for an organization, such as a business, educational institution, governmental entity, healthcare facility or other organization.FIG.1illustrates a wide area network (WAN) which may extend across multiple network sites (e.g. geographical, logical). Sites of the WAN are interconnected so that client devices at one site can access resources at another site. In some topologies, many services and secure resources are installed at core sites (e.g. datacenters, headquarters), and many branch sites (e.g. regional offices, retail stores) connect the client devices (e.g. laptops, smartphones, internet of things devices) to the WAN. These types of topologies are often used by enterprises in establishing their corporate network.

Client devices (not shown) in multiple locations may be connected using network end nodes102(AP or BG) via subnets S1-S9. Examples of client devices may include: desktop computers, laptop computers, tablet computers, e-readers, netbook computers, televisions and similar monitors (e.g., smart TVs), content receivers, set-top boxes, personal digital assistants (PDAs), mobile phones, smart phones, smart terminals, dumb terminals, virtual terminals, video game consoles, virtual assistants, Internet of Things (IOT) devices, and the like.

In an example, the network end nodes102may be APs or a branch gateway. The branch gateway device may be a router, a digital-to-analog modem, a cable modem, a Digital Subscriber Line (DSL) modem, or some other network device configured to communicate to the network106. These network end nodes102may be in communication with a network106. The network end nodes102may be present at different remote locations. For example, the APs may be in a satellite office or on different floors in a building.

A group of these APs at a remote location may be combined to form AP groups (104-1and104-2). Similarly a group of branch gateways form the BG Group104-3. The network106may be a public or private network, such as the Internet, or other communication network to allow connectivity among the various groups104-1,104-2and104-3as well as access to resources of organization via subnets X1-X6.

The network end nodes102communicate with the secure resources112using VPN connections over the network106. The VPN connections are established between the network end nodes102and a node within a cluster of nodes108.FIG.1shows two different clusters, cluster110-1with nodes108(1-4)and cluster110-2with nodes108(5-8). Hereinafter, the nodes in any cluster are commonly referred as node(s)108and specific nodes in the cluster are referred by their number. Hereinafter, the clusters110-1and110-2are commonly referred as cluster110. The cluster of nodes108and the secure resources112form the VPN system100.

The nodes108in the cluster110may be any networking devices used for establishing and configuring the VPN connections over the network106. In an example, the nodes108may be a router device or a VPN concentrator (VPNC). The flow of traffic in the WAN may be based on a routing table configured for the network end nodes (AP groups104-1,104-2, and104-3) by a network manager of the WAN. In some cases, a cloud system coupled to WAN may be used for defining the route path.

InFIG.1,112represents a secure resources112(e.g. data center) of an organization or a network which is accessible via the cluster of nodes108of a VPN system100.

The network end nodes102provide access to internet to all the client devices and forward traffic received from client devices via subnets S1-S9to the nodes108. The client devices may access data present in data center of the organization via subnets X1to X6. For example, a client device connected to AP1may be requesting data from a server present in the data center via the subnet X1. The traffic from access points and branch gateways may reach the subnets X1to X6using multiple routes in the VPN system100. For example, inFIG.1traffic from the AP1may be routed via node108-1, or node108-2, or node108-3, or node108-4in the cluster110-1. The route is defined for each of the network end nodes in the WAN using a routing table. The routing table for each network end node102is pre-configured.

The routing table defines the communication path of each network end node102to different subnet (X1-X6) via nodes108in a cluster(s)110. The cluster110chosen for communication and a specific node108via which the traffic from the network end node102is routed is defined based on cost. For example, to reach X1from an AP1, the first preferred route is via the cluster110-1and node108-1with a cost factor of 10, followed by node108-2with cost factor of 11. The table-1 below shows the order of the preferred nodes108along with a cost factor associated with each node for the different network end nodes102(of AP group1(104-1) and AP group2(104-2)) ofFIG.1to reach subnet X1.

The client devices communicating via AP group1(104-1) and AP group2(104-2) are routed via the cluster110-1. The client devices connected to the BG group104-3may be routed to X4via cluster110-2. The table 2 below shows the order of the preferred nodes108along with a cost factor associated with each node for the different network end nodes (BG devices in BG group104-3) ofFIG.1to reach subnet X4.

The cluster preference of the network end nodes102is shown in the table 3 below.

In the cluster110-1, traffic from network end nodes102are routed via nodes108-1,108-3,108-3and108-4. The node108-2may be a master node which communicates messages with all the network end nodes102. Each cluster (110-1and110-2) of nodes108may have its own master node. The nodes108in the cluster110exchange heartbeat messages with other nodes108in the cluster. When a predetermined number of heartbeat messages from a node108are missing, a node failure is detected. On detecting node failure, the master node108-2may send a failover message with a list of active nodes in the cluster110-1. More details related to the failure detection and switchover are explained in conjunction withFIGS.4-6.

FIG.2illustrates component of a master node108, in a cluster of nodes108of the VPN system100, in accordance with embodiments of the present disclosure. As any of the nodes108may be considered as master node, the master node is referenced by108.

The nodes108in the cluster110-1may be any networking device. In an example, the networking device may be a VPNC and the cluster of nodes108may be a cluster of VPNCs. The nodes108manage the VPN connection between multiple network end nodes102and the node108. The nodes108authenticate the client devices requesting access to protected resources112of the organization and establish the VPN connections with the network end nodes102. The VPN connection is established between the network end node and node102using a Protocol Security (IPsec) connection or a Secure Sockets Layer (SSL) connection. However, other forms of VPN connections may be employed.

As shown, inFIG.1, one of the nodes108-2,108-6in each cluster110may be assigned as device designed gateway for the cluster and communicates messages between the cluster of nodes108and the network end nodes102. The device designed gateway may be referred to as a master node108. Although inFIG.1, the node108-2is the master node in the cluster110-1and the node108-6is the master node in the cluster110-2, it should be noted that any node in the cluster may be the master node108. In addition, one of the other nodes may be assigned as a standby for the master node108.

The master node108includes a processor(s)202, a VPN database204, and a machine-readable medium206. The processor202may be configured for establishing and managing VPN connections.

In a multi-link VPN system100deployment, the VPN connections may include multiple VPN tunnels between the network end nodes102and nodes108in the cluster110. The information of the active VPN tunnels may be maintained in the VPN database204.

The processor202may be configured to execute instructions (i.e. programming or software code) stored in the machine-readable medium206to perform the functions at a master node108as described herein. For example, the machine-readable medium206may include instructions208to exchange heartbeat message among the nodes in the cluster110to detect a failure of a first node108-1in the cluster110-1. When a failure is detected at the first node108-1, the instructions210may be executed which causes the processor202to transmit a failover message to the network end nodes102connected to the first node108-1. AlthoughFIG.2shows only two instructions, it should be understood that several instructions may be stored in the machine-readable medium206.

The routing tables for the network end nodes102are pre-defined by a management device in the WAN of the organization or by a cloud system coupled to the WAN. The routing is defined based on the location of the network end nodes102and cost factor associated with each node108. The failover message is sent directly to the network end nodes102from the master node108. This means that the VPN system updates the route table defined for the network device without involving communication with the cloud system or management device.

FIG.3is a block diagram of a network end node(s)102having a processor302operably coupled to a machine readable medium304storing executable program instructions, in accordance with embodiments of the present disclosure. In an example, the network end node102may be an access point as shown in AP group104-1and104-2(as shown inFIG.1) or a branch gateway device as shown in BG group104-3(as shown inFIG.1).

The network end node102forwards the traffic received from client devices to the nodes102to a node108of the WAN using a VPN tunnel. The network end node102includes a processor(s)302configured to execute instructions (i.e. programming or software code) stored in the machine-readable medium304to perform the functions at the network end node102as described herein. In case of a failure of a first node108-1, the master node108-2of the cluster of nodes may send a failover message to the network end node102connected to the first node108-1.

On receiving the failover message, the instructions306may be executed, which causes the processor302to update a routing table of the network end node102based on the failover message. The failover is message includes a list of active nodes in the cluster of nodes108. The network end nodes102deactivates the route towards the first node108-1in the routing table.

When the routing table is updated the instructions308may be executed, which cause the processor302to switch the route of traffic to a second node108-2based on the updated routing table.

AlthoughFIG.3shows only two instructions, it should be understood that several instructions may be stored in the machine-readable medium304of the network end node102. In additions, the network end nodes102may include additional hardware device and software for communication with the client devices and nodes108, which are not shown in theFIG.3.

Referring now toFIG.4, it depicts the operation of the VPN system100in case of a node failure. In an example, the network end node102may be a branch gateway or an access point forwarding traffic received from the client devices connected via subnets S1-S9.

When the node108-2does not receive heartbeat messages from node108-1, the node108-2detects failure of node108-1. The master node108-2provides a failover message to the network end node102. The failover message includes a list of nodes alive in the cluster110-1to which the traffic from the network end node102may be routed. The network end node102can update its routing table based on the failover message. The network end node may de-activate the route associated with node108-1and switch the route of traffic to a next route108-2in the updated routing table.

FIG.4shows the initial route table406and the final route table406of the network end point102. In the initial route table406, the node108-1is the active node with which a link is established (indicated by bold text). In the updated route table408, the node108-1is de-activated (indicated by strikethrough) and the next route in the route table is selected as the active node (indicated by bold text). The traffic from the network end node102is switched to node108-2as indicated in by the switched route (404).

In a multi-link scenario, where the VPN system100may support multiple uplinks (i.e. multiple VPN tunnels) to the same node108, the failover message may include the state (down) of an active link. The message may indicate to the network end node102that the current uplink being used is down. For example, when a current uplink of the first node108-1is down, the route of traffic is shifted to a next uplink corresponding to a second tunnel of the first node108-2. The current uplink is de-activated in the routing table based on the failover message.

AlthoughFIG.4describes the operation of the VPN system with respect to nodes of cluster110-1, it should be noted that the same operations can be performed in case of a failure of a node in cluster110-2.

FIG.5is a flow diagram depicting a method500of detecting failure and performing seamless failover in the VPN system100, in accordance with examples of the present disclosure. The seamless failover includes detection of the failure and switchover of the traffic from the failed node to an alternate node.

In some implementations, the method500may include more or fewer blocks than are shown. In some implementations, one or more of the blocks of a method500may, at certain times, be ongoing and/or may repeat. In some implementations, blocks of the method500may be combined.

The method500shown inFIG.5may be implemented in the form of executable instructions stored on a machine-readable medium206and executed by a processing circuitry (e.g. such as processor202) and/or in the form of electronic circuitry in the master node108in the cluster of nodes108.

The method500may start in block502, with heartbeat messages being exchanged between the nodes in the cluster to detect failure at a node in the cluster of nodes108. Each cluster110may include a limited number of nodes108leading to fewer number of heartbeat messages being exchanged to detect a failure of a node108or a link to the node.

At block504, the method500includes determining if there is a failure of a node108in the cluster of nodes.

In case multi-link VPN deployments where each node108may have multiple uplinks, the heartbeats messages may be used to detected the failure of an uplink on a node108.

At block506, in response to detecting the failure of a first node108-1, the master node108-2sends a failover message to a connected network end node102. The failover message includes a list of active nodes in the cluster110-1of nodes108.

In case of failure of an uplink at the first node108-1, the failover message may be includes the state of the active link.

FIG.6is a flow diagram depicting a method600for switching route at a network end node102of the VPN system100for a seamless traffic switchover, in accordance with examples of the present disclosure.

In some implementations, the method600may include more or fewer blocks than are shown. In some implementations, blocks of the method600may be combined.

The method600shown inFIG.6may be implemented in the form of executable instructions stored on a machine-readable medium404and executed by a processing circuitry (e.g. such as processor402) and/or in the form of electronic circuitry in the network end node102.

The method602may start in block602, with the network end node102receiving the failover message. The failover message includes a list of active nodes108in the cluster of nodes108. In cases, where the VPN system100supports multiple links to the same node, the failover message may include state of an active uplink. The message may indicate to the network end node102that the current uplink being used is down.

At block604, the network end node102updates the routing table based on the failover message.FIG.4shows the initial route table406and the updated route table408after receiving the failover message at the network end node108. The current route of traffic through node108-1is deactivated. In cases where the failover message is related to the state of current uplink, the network end node102may de-activate the route of the current uplink in its routing table.

At block604, the network end node102switches the route of traffic to the second node108-2in the cluster110of nodes108. In the multi-link scenario, when a current uplink of the first node108-1is down, the route of traffic is shifted to a next uplink corresponding to a second tunnel of the first node108-2. The current uplink is de-activated in the routing table based on the failover message.

In comparison to current failover mechanisms using keep alive messages, the methods500and600may be performed for fast failure detection and seamless traffic switchover within a second or a sub-second. This allows time critical application such as voice calls to continue to function seamlessly in the event of a node108failure or an uplink failure.

The features of the present disclosure can be implemented using a variety of specific devices that contain a variety of different technologies and characteristics. As an example, features that include instructions to be executed by processing circuitry may store the instructions in a cache of the processor circuitry, in random access memory (RAM), in hard drive, in a removable drive (e.g. CD-ROM), in a field programmable gate array (FPGA), in read only memory (ROM), or in any other non-transitory, computer-readable medium, as is appropriate to the specific device and the specific example implementation. As would be clear to a person having ordinary skill in the art, the features of the present disclosure are not altered by the technology, whether known or as yet unknown, and the characteristics of specific devices the features are implemented on. Any modifications or alterations that would be required to implement the features of the present disclosure on a specific device or in a specific example would be obvious to a person having ordinary skill in the relevant art.

Phrases and parentheticals beginning with “e.g.” or “i.e.” are used to provide examples merely for the purpose of clarity. It is not intended that the disclosure be limited by the examples provided in these phrases and parentheticals. The scope and understanding of this disclosure may include certain examples that are not disclosed in such phrases and parentheticals.