Using loopback interfaces of multiple TCP/IP stacks for communication between processes

• US 9,940,180 B2
• Filed: 03/31/2014
• Issued: 04/10/2018
• Est. Priority Date: 03/31/2014
• Status: Active Grant

• Current Assignee: Nicira Incorporated (Broadcom, Inc.)
• Original Assignee: Nicira Incorporated (Broadcom, Inc.)
• Inventors: Raju, Nithin B., Chandrashekhar, Ganesan
• Primary Examiner(s): Sough, S.
• Assistant Examiner(s): JORDAN, KIMBERLY L
• Application Number:
  US14/231,702
• Publication Number:
  US 20150277995A1
• Time in Patent Office: 1,471 Days
• Field of Search: 719313
• CPC Class Codes: G06F 9/544 Buffers; Shared memory; Pipes

Abstract

Multiple TCP/IP stack processors on a host. The multiple TCP/IP stack processors are provided independently of TCP/IP stack processors implemented by virtual machines on the host. The TCP/IP stack processors provide multiple different default gateway addresses for use with multiple processes. The default gateway addresses allow a service to communicate across an L3 network. Processes outside of virtual machines that utilize the TCP/IP stack processor on a first host can benefit from using their own gateway, and communicate with their peer process on a second host, regardless of whether the second host is located within the same subnet or a different subnet. The multiple TCP/IP stack processors can use separately allocated resources. Separate TCP/IP stack processors can be provided for each of multiple tenants on the host. Separate loopback interfaces of multiple TCP/IP stack processors can be used to create separate containment for separate sets of processes on a host.

Claims

1. A method of establishing communication between processes operating in a particular set of processes in a plurality of sets of processes on an electronic device, said electronic device executing multiple machines for multiple tenants, and the plurality of sets of processes comprising different sets of processes for different tenants, the method comprising:

for each particular set of processes for each tenant;

assigning a dedicated TCP/IP stack processor to the set of processes; and

providing communications between processes within the set of processes through a loopback interface of the dedicated TCP/IP stack processor,

said assigning and providing operations ensuring that different dedicated TCP/IP stacks are assigned and provided for the different sets of processes for the different tenants,

wherein at least two particular sets of processes comprise one type of process that uses the same IP address and TCP port number in each of the two particular sets of processes.

2. The method of claim 1, wherein the loopback interface comprises a range of IP addresses.

3. The method of claim 1 further comprising implementing at least two sets of processes wherein at least one type of process implemented in a first of the two sets of processes is also implemented in a second of the two sets of processes.

4. The method of claim 1 further comprising implementing at least two sets of processes wherein each type of process implemented in a first of the two sets of processes is also implemented in a second of the two sets of processes.

5. The method of claim 4, wherein each type of process implemented in the second of the two sets of processes is also implemented in the first of the two sets of processes.

6. The method of claim 1, wherein a centralized network platform communicates with each set of processes through a separate agent.

7. The method of claim 1, wherein at least one TCP/IP stack processor does not comprise an interface that sends IP packets to a virtual switch or a physical network card.

8. The method of claim 1, wherein the at least two particular sets of processes are for different tenants.

9. A non-transitory machine readable medium storing a program that when executed by at least one processing unit establishes communication between hypervisor-service processes operating in a particular set of hypervisor-service processes in a plurality of sets of hypervisor-service processes of a hypervisor, wherein multiple machines for multiple tenants run on top of the hypervisor and the plurality of sets of hypervisor-service processes comprise different sets of hypervisor-service processes for different tenants, the program comprising sets of instructions for:

for each set of hypervisor-service processes for each tenant;

assigning a dedicated TCP/IP stack processor to the set of hypervisor-service processes; and

providing communications between hypervisor-service processes within the set of hypervisor-service processes through a loopback interface of the dedicated TCP/IP stack processor,

said assigning and providing operations ensuring that different dedicated TCP/IP stacks are assigned and provided for the different sets of hypervisor-service processes for the different tenants,

wherein at least two particular sets of hypervisor-service processes comprise one type of hypervisor-service process that uses the same IP address and TCP port number in each of the two particular sets of hypervisor-service processes.

10. The non-transitory machine readable medium of claim 9, wherein the sets of hypervisor-service processes comprise two of the following processes:

a virtual machine migrator process, a virtual storage area network process, a network storage process, a fault tolerance application process, a network file system process, and a network management process.

11. The non-transitory machine readable medium of claim 9, wherein the sets of hypervisor-service processes comprise a virtual machine migration process and a network storage process.

12. The non-transitory machine readable medium of claim 9, wherein the hypervisor-service processes are processes implemented within the hypervisor that are used to provide services to the virtual machines on the host.

13. The non-transitory machine readable medium of claim 9, wherein a centralized network platform communicates with each set of hypervisor-service processes through a separate agent.

14. The non-transitory machine readable medium of claim 9, wherein at least one TCP/IP stack processor does not comprise an interface that sends IP packets to a virtual switch or a physical network card.

15. An electronic device executing multiple machines for multiple tenants that establishes communication between hypervisor-service processes operating in a particular set of hypervisor-service processes in a plurality of sets of hypervisor-service processes of a hypervisor, said plurality of sets of processes comprising different sets of processes for different tenants, the electronic device comprising:

at least one processing unit for executing instructions;

a non-transitory machine readable medium storing a program that when executed by the processing unit implements a plurality of TCP/IP stack processors on the electronic device, outside of any virtual machine that operates on top of the hypervisor, the program comprising sets of instructions for;

for each set of hypervisor-service processes for each tenant;

assigning a dedicated TCP/IP stack processor to the set of hypervisor-service processes; and

providing communications between hypervisor-service processes within the set of hypervisor-service processes through a loopback interface of the dedicated TCP/IP stack processor without configuring equivalent hypervisor-service processes implemented in the different sets of processes to use different IP addresses from each other,

said assigning and providing operations ensuring that different dedicated TCP/IP stacks are assigned and provided for the different sets of hypervisor-service processes for the different tenants,

wherein at least two particular sets of hypervisor-service processes comprise one type of hypervisor-service process that uses the same IP address and TCP port number in each of the two particular sets of hypervisor-service processes.

16. The electronic device of claim 15, wherein the electronic device implements a kernel space and a user space and all the hypervisor-service processes of at least one of the sets of hypervisor-service processes are implemented in the user space.

17. The electronic device of claim 15, wherein the electronic device implements a kernel space and a user space and all the hypervisor-service processes of at least one of the sets of hypervisor-service processes are implemented in the kernel space.

18. The electronic device of claim 15, wherein the electronic device implements a kernel space and a user space and at least a first hypervisor-service process of a particular set of hypervisor-service processes is implemented in the kernel space and at least a second hypervisor-service process of the particular set of hypervisor-service processes is implemented in the user space.

19. The electronic device of claim 15, wherein a centralized network platform communicates with each set of hypervisor-service processes through a separate agent.