Citrix Systems, Inc.

Citirix Systems, Inc.

Sandhya Gopinath

Abhishek Chauhan

Henk Bots

Ramanjaneyulu Y Talla

Ranjith Nath

Jyotheesh Rao Kurma

Sandeep Kamath

Deepak Goel

Mohit Prakash Saxena

Vivekanand Rangaraman

Narendra Kataria

Mahesh Arumugam

Aakash Jain

Anil N Shetty

Josephine Suganthi

Saravana Annamalaisami

Tushar Kanekar

Mahesh Mylarappa

Shashidhara Mysore Nanjundaswamy

Ashwin Jagadish

Santosh Sahu

Janraj Cj

Jaidev Sridhar

Sathaiah Dontula

Tushar K Swain

Kaur Gurpreet

Described embodiments provide systems and methods for pushing session information to a newly joined node in a cluster of nodes. In the cluster, each node may maintain a session table of existing sessions. One or more nodes may detect a new node has joined the cluster. Each node, responsive to the detection, may apply a hash function on a tuple of each session of the existing sessions in the session table of the node to determine whether one or more existing sessions are identified to be owned by the new node as a result of the hash function. Each node, responsive to identifying that one or more sessions are to be owned by the new node, may push corresponding session information to the new node. The new node may become configured to receive a packet corresponding to the one or more sessions and to process the packet.

Systems and methods to retain existing connections so that there is no connection loss when nodes are added to a cluster for capacity or when a node is taken out from the cluster for maintenance

The present disclosure is directed to providing FTP data connections between a client and a server via a multi-core system. Both client-side and server-side data connections are allowed to be served on a core that is the same as a core that has processed the corresponding control connection using at least one of receive side scaling (RSS) filter rules and changes in port allocation logic. In a cluster where control connection and data connection can reach different nodes based on an RSS distribution, the node which has processed the control connection is also allowed to process the corresponding data connection using at least one of RSS filter rules, service registration, changes in port allocation logic and node-to-node (N2N) messages. The systems and methods discussed herein apply to active FTP, passive FTP, and active FTP with a random port in which the server initiates data connection from a non-standard FTP port.

FTP load balancing support for cluster

The present disclosure describes systems and methods for propagating port state to intermediary devices of a cluster in a static link aggregation environment. The methods and systems include a cluster comprising a plurality of intermediary devices in communication with a network device via a static link aggregation comprising aggregated ports from different intermediary devices of the cluster. A first device of the static link aggregation is configured to detect that a health of the first device is below a predetermined threshold and, responsive to the detection, identify one or more ports in the aggregated ports as down. A second device of the link aggregation is configured to, responsive to the identification, remove the ports from a distribution list for the static link aggregation. Upon detection that a health of a device is above a predetermined threshold, the first device may identify the ports as up.

Systems and methods for propagating health of a cluster node

In the present solution, when a cluster node sends an Address Resolution Protocol (ARP) request for an external internet protocol (IP), the node sends a message to all the other nodes, which are part of the Cluster Link Aggregation (CLAG) to expect an ARP reply for the IP. When a node in the cluster receives the ARP reply, the node informs the other nodes which are part of the same CLAG to update the Machine Access Control (MAC) address. Also when an ARP entry is learned/updated over a CLAG link as part of an ARP request/Gratuitous ARP, the node learning/updating the ARP entry will inform other nodes which are part of the same CLAG about the learned/updated ARP entry. Nodes in a cluster may communicate between with each other over a dedicated backplane, which may be a separate physical medium.

Systems and methods for address resolution protocol (ARP) resolution over a link aggregation of a cluster channel

The present invention is directed towards forwarding network packets in a cluster network. A predetermined identifier may be inserted into a Media Access Control (MAC) ID field of an Ethernet header of a packet to distinguish various types of traffic. Newly received packets may be identified due to the absence of the identifier. The identifier may be added to the source MAC ID field of the Ethernet header of the packet, and the packet may be distributed to cluster nodes for processing via an inter-node communication bus. Thus, received packets with the identifier in the source MAC ID field may be identified as steered for processing by an internal node of the cluster. After processing the packet, the internal node may transmit the processed packets via the inter-node bus with a destination MAC ID including the identifier.

Systems and methods for forwarding traffic in a cluster network

In the present solution, when a cluster node sends an ARP request for an external IP, the node sends a message to all the other nodes, which are part of the CLAG to expect an ARP reply for the IP. When a node in the cluster receives the ARP reply, the node informs the other nodes which are part of the same CLAG to update the MAC address. Also when an ARP entry is learned/updated over a CLAG link as part of an ARP request/Gratuitous ARP, the node learning/updating the ARP entry will inform other nodes which are part of the same CLAG about the learned/updated ARP entry. Nodes in a cluster may communicate between with each other over a dedicated backplane, which may be a separate physical medium.

Systems and methods for ARP resolution over an asynchronous cluster network

Described herein is a method and system for distributing request and responses across a multi-core system. Each core executes a packet engine that further processes data packets allocated to that core. A flow distributor executing within the multi-core system forwards client requests to a packet engine on a core that is selected based on a value generated when a hash is applied to a tuple comprising a client IP address, a client port, a server IP address and a server port identified in the request. The packet engine selects a first IP address and a first port of the core, and determines whether a hash of a tuple comprising those values identifies the selected core. A modification is then made to the client request so that the client request includes a tuple comprising the first IP address, the server IP address, the first port and the server port.

Systems and methods for identifying a processor from a plurality of processors to provide symmetrical request and response processing

The present application is directed towards systems and methods of hunting for a hash table entry in a hash table distributed over a multi-node system. More specifically, when entries are created in an ASDR table, the owner node of the entry may replicate the entry onto a non-owner node. The replica can act as a backup of the ASDR table entry in the event the node leaves the multi-mode system. When the node returns to the multi-node system, the node may no longer have the most up to date ASDR table entries, and may hunt to find the existence of the value associated with the entry. Responsive to receiving a request for an entry that may be outdated on the node, the node sends a request down a replication chain for an updated copy of the ASDR table entry from one of the replicas. Responsive to receiving the replica copy of the entry, the node responds to the client's request for the entry.

Systems and methods for application-state distributed replication table hunting

The present application is directed towards ASDR table contract renewal. In some embodiments, a core may cache an ASDR table entry received from an owner core such that when the entry is needed again the core does not need to re-request the entry from the owner core. As storing a cached copy of the entry allows the non-owner core to use an ASDR table entry without requesting the entry from the owner core, the owner core may be unaware of an ASDR table entry's use by a non-owner core. To ensure the owner core keeps the ASDR table entry alive, which the non-owner core has cached, the non-owner core may perform contract renewal for each of its recently used cached entries. The contract renewal method may include sending a message to the owner core that indicates which cached ASDR table entries the non-owner core has recently used or accessed. Responsive to receiving the message the owner core may reset a timeout period associated with the ASDR table entry.

Systems and methods for distributed hash table contract renewal

The present disclosure is directed towards methods and systems for caching packet steering sessions for steering data packets between intermediary devices of a cluster of intermediary devices intermediary to a client and a plurality of servers. A first intermediary device receives a first data packet and determines, from a hash of a tuple of the first packet, a second intermediary device to which to steer the first packet. The first device stores, to a session for storing packet steering information, the identity of the second device and the tuple. The first device receives a second packet having a corresponding tuple that matches the tuple of the first packet and determines, based on a lookup for the session using the tuple of the second packet, that the second device is the intermediary device to which to steer the second packet. The first device steers the second packet to the second device.

Systems and methods to cache packet steering decisions for a cluster of load balancers

As cluster LAG (CLA or CLAG) is a link aggregation spread across cluster nodes, the same MAC address is to be used for a CLAG on all cluster nodes. Each node in a cluster will derive the unique MAC address for all cluster LAGs. When a cluster is formed, the cluster configuration coordinator (COO) (referred to as the 'source MAC node') will sync its MAC addresses of CLAGs to all nodes in a cluster. The same MAC address may be used for a CLA on all nodes from then onwards till the source MAC node is removed from cluster. Even if the CCO changes due to some reason, CLAG MACs will not be changed as long as a source MAC node is present in the cluster.

Systems and methods for deriving unique MAC address for a cluster

The present application is directed towards using a distributed hash table to track the use of resources and/or maintain the persistency of resources across the plurality of nodes in the multi-node system. More specifically, the systems and methods can maintain the persistency of resources across the plurality of nodes by the use of a global table. A global table may be maintained on each node. Each node's global table enables efficient storage and retrieval of distributed hash table entries. Each global table may contain a linked list of the cached distributed hash table entries that are currently stored on a node.

Systems and methods for reliable replication of an application-state, distributed replication table

While each node in a cluster of nodes sources connections with the same IP if each node allocates a port on this IP independently, there may be port clashes. Also, the return traffic is not guaranteed to hit the originating node. These issues are addressed by allocating a port in such a way that the response traffic hashes back to the originating node. A good hash is chosen such that the ports are equally divided among the nodes. When a node leaves, the other nodes take over the port range used by this node. When a node joins, the node takes back its share of ports.

Systems and methods for supporting IP ownership in a cluster

In a cluster environment, nodes participating in the cluster may generate packets with the same source IP to the same destination IP. If those packets get fragmented down stream, then reassembling this packets depends on the source IP, destination IP, protocol and the IP identifier field (IPID) of the IP packet. As the source IP, destination IP and protocol may be fixed, the IPID generation is coordinated across the nodes to support reassembly down stream and avoid tuple collision. The IPID space may be equally split among the nodes in the cluster. Each node generates IPID within its range to avoid a collision with an IPID generated from another node.

Systems and methods for generating IPID across a cluster network

The present application is directed towards sharing data link layer information of network traffic distributed across a cluster of intermediary devices. A method for sharing data link layer information across a cluster includes receiving a request packet at a first intermediary device. The first intermediary device identifies a first set of data link layer information from a data link layer of the request packet. The first intermediary device modifies the request packet for transmission on a common data backplane of the cluster to include the first set of data link layer information in the request packet. The modified request packet includes a second set of data link layer information that differs from the first set of data link layer information at the data link layer. The first intermediary device transmits the modified request packet on the common data backplane of the cluster to other devices of the cluster.

Growing community of inventors

Karnataka, India

Sandhya Gopinath