CN112367256A

CN112367256A - Creation method, apparatus and storage medium

Info

Publication number: CN112367256A
Application number: CN202011101936.5A
Authority: CN
Inventors: 王立坤
Original assignee: Sangfor Technologies Co Ltd
Current assignee: Sangfor Technologies Co Ltd
Priority date: 2020-10-15
Filing date: 2020-10-15
Publication date: 2021-02-12
Anticipated expiration: 2040-10-15
Also published as: CN112367256B

Abstract

The embodiment of the application provides a creating method, creating equipment and a storage medium, wherein the method comprises the following steps: aiming at each virtual routing VR in the virtual network environment, obtaining identification information of each VR; obtaining identification information of an address pool to be created for each VR; allocating network addresses to each address pool, wherein the network addresses are at least one of internet protocol address (IP) prefixes, address fields and IP addresses; creating address pools of the VRs according to the identification information of the address pools and the network addresses allocated to the address pools, wherein the network addresses in the address pools created for any two VRs in each VR can be different or at least partially the same; and correspondingly storing the identification information of each VR and the address pool created for each VR.

Description

Creation method, apparatus and storage medium

Technical Field

The present application relates to communication technologies in a virtual network environment, and in particular, to a method, an apparatus, and a storage medium for creating an address pool.

Background

The rise of cloud computing promotes the rapid development of a network virtualization technology, and the development of the network virtualization technology provides powerful support for the application of network virtualization. The IPv6 network protocol is a next generation network protocol that may be applied to network virtualization technologies due to its potential advantages. As a Dynamic Host Configuration Protocol, the DHCPv6(Dynamic Host Configuration Protocol for IPv6) Protocol may configure an Internet Protocol (IP) address, an IP prefix, and/or other Configuration information required by an IPv6 Virtual Host (VM) operating on a Virtual IPv6 network. In order to realize normal communication of the virtual IPv6 network, different IP addresses need to be allocated to each VM, and if the number of the IP addresses allocated to the VMs is large, the IPv6 address resources may be greatly occupied by the VMs, so that the number of the IP addresses that can be allocated to other network elements, such as servers, that need to use the IP addresses in the virtual IPv6 network is reduced.

It will be appreciated that if there is only one VR in the virtual IPv6 network (single VR scenario), that VR may do the aforementioned allocation of information for the VMs under it and may need to allocate different IP addresses for different VMs. If there are two or more VRs in the virtual IPv6 network (multi-VR scenario), each VR needs to assign a different IP address to the VM below it, and the IP addresses assigned to VMs by all VRs need to be different. It can be seen that the above problem exists in both single VR and multi-VR scenarios. Compared with the occupation situation of single VR, the situation that the IP resources are occupied in the multi-VR scene is particularly obvious. Therefore, how to solve the technical problem that the IP address resources are occupied by the VM becomes an urgent solution.

Disclosure of Invention

In order to solve the existing technical problem, embodiments of the present application provide a creating method, an apparatus, and a storage medium.

The technical scheme of the embodiment of the application is realized as follows:

the embodiment of the application provides a creating method, which comprises the following steps:

for each Virtual Route (VR) in the virtual network environment,

obtaining identification information of each VR;

obtaining identification information of an address pool to be created for each VR;

allocating network addresses to each address pool, wherein the network addresses are at least one of internet protocol address (IP) prefixes, address fields and IP addresses;

creating address pools of the VRs according to the identification information of the address pools and the network addresses allocated to the address pools, wherein the network addresses in the address pools created for any two VRs in each VR can be different or at least partially the same;

and correspondingly storing the identification information of each VR and the address pool created for each VR.

In the foregoing solution, for any one of the VRs, the method further includes:

obtaining identification information of each address pool to be created for the arbitrary VR, wherein the identification information of each address pool is different;

respectively allocating network addresses to the address pools, wherein the network addresses allocated to the address pools are different;

establishing each address pool under the arbitrary VR according to the identification information of each address pool and the network address allocated to each address pool;

and correspondingly storing the identification information of the arbitrary VR and each address pool established for the arbitrary VR.

In the foregoing solution, for any one of the address pools, the allocating network addresses to the any address pool includes:

obtaining identification information of an address to be allocated, wherein the identification information at least indicates a prefix or a network segment to which a network address to be allocated belongs to the arbitrary address pool;

obtaining address identifiers of other address pools created for the arbitrary VR, wherein the address identifiers at least indicate prefixes or network segments of network addresses distributed for the other address pools;

judging whether the identification information of the address to be allocated is the same as the address identification of the other address pools;

and under the condition that the network addresses are judged to be different, allocating the prefix indicated by the identification information or the network address of the network segment to the arbitrary address pool.

In the above scheme, the method further comprises:

in the case where it is judged to be the same,

obtaining the identifiers of the other address pools, the address identifiers of which are the same as the identifier information;

obtaining a target network address, wherein the target network address is a prefix indicated by the identification information or a network address of a network segment which the target network address belongs to in other address pools of the identification;

and allocating a free network address different from the target network address to the arbitrary address pool.

In the foregoing solution, there exists at least one virtual host (VM) under each VR, and after creating the address pool of each VR, the method further includes:

and binding network addresses for any VM under any VR according to an address pool created for any VR in the VRs.

In the foregoing solution, the binding a network address for any VM under any VR according to an address pool created for any VR in the VRs includes:

determining that no leased IP address exists in the address pool, and binding the IP address with the any VM; and/or determining that no leased IP prefix or address field exists in the address pool, and binding the IP prefix or address field with the arbitrary VM;

or acquiring a target prefix or a target network segment, and binding the IP prefix or the address segment which does not have a lease and has the target prefix or the target network segment in the address pool with the arbitrary VM; and/or binding the IP address which does not have the lease and has the target prefix or the target network segment in the address pool with the arbitrary VM.

In the above scheme, the arbitrary VM may be assigned with a target IP, where the target IP is an IP address that does not have a lease conflict with leases generated when other VMs under the arbitrary VR are assigned with IP addresses in the network addresses bound for the arbitrary VM.

An embodiment of the present application further provides a creating apparatus, including:

a first obtaining unit, configured to obtain, for each VR in a virtual network environment, identification information of each VR;

a second obtaining unit, configured to obtain identification information of an address pool to be created for each VR;

the allocation unit is used for allocating network addresses to each address pool, wherein the network addresses are at least one of IP prefixes, address fields and IP addresses;

a creating unit, configured to create address pools of the VRs according to the identification information of the address pools and network addresses allocated to the address pools, where the network addresses in the address pools created for any two VRs in each VR may be different or at least partially the same;

and the storage unit is used for correspondingly storing the identification information of each VR and the address pool created for each VR.

In the above scheme, for any one of the VRs,

the second obtaining unit is configured to obtain identification information of each address pool created for the VR, where the identification information of each address pool is different;

the allocation unit is configured to allocate network addresses to the address pools, where the network addresses allocated to the address pools are different;

the creating unit is configured to create each address pool under the arbitrary VR according to the identification information of each address pool and the network address allocated to each address pool;

correspondingly, the storage unit is configured to correspondingly store the identification information of the arbitrary VR and each address pool created for the arbitrary VR.

Embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the creating method according to the embodiments of the present application.

The embodiment of the present application further provides a creating device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the program, the steps of the creating method according to the embodiment of the present application are implemented.

The embodiment of the application provides a creating method, creating equipment and a storage medium, wherein the method comprises the following steps: for each VR in the virtual network environment, obtaining identification information of each VR; obtaining identification information of an address pool to be created for each VR; allocating network addresses to each address pool, wherein the network addresses are at least one of IP prefixes, address fields and IP addresses; creating address pools of the VRs according to the identification information of the address pools and the network addresses allocated to the address pools, wherein the network addresses in the address pools created for any two VRs in each VR can be different or at least partially the same; and correspondingly storing the identification information of each VR and the address pool created for each VR.

In the embodiment of the application, because the identification information of each VR and the address pool created for each VR are correspondingly stored, i.e. the identification of the VR is taken into account, partial same IP addresses or all same IP addresses can be allocated to the address pools of different VRs, and the situation that IP resources are occupied in a multi-VR scene can be greatly reduced.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

Fig. 1 is a first schematic flow chart of an implementation of a creating method according to an embodiment of the present application;

fig. 2 is a schematic flow chart illustrating an implementation process of a creating method according to an embodiment of the present application;

fig. 3 is a schematic flow chart illustrating an implementation of a creating method according to an embodiment of the present application;

fig. 4 is a schematic view of a scenario of a virtual IPv6 network according to an embodiment of the present application;

fig. 5 is a schematic flow chart of an implementation of the creating method according to the embodiment of the present application;

fig. 6 is a schematic flow chart of an implementation of the creating method according to the embodiment of the present application;

fig. 7 is a schematic flowchart sixth of an implementation flow of a creating method according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a component structure of a creating device according to an embodiment of the present application;

fig. 9 is a schematic diagram of a hardware structure of a creating apparatus according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions in the embodiments of the present application will be described clearly and completely with reference to the accompanying drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application. In the present application, the embodiments and features of the embodiments may be arbitrarily combined with each other without conflict. The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.

Before describing the technical scheme of the embodiment of the present application, technical terms that may be used are described:

1) IPv6(Internet Protocol Version 6): the Version 6 of IP is a next generation IP protocol, and can be used as a substitute protocol or a supplement protocol of IPv4, compared with the current IP protocol (IPv4) Version of IPv 6.

2) Virtual routing (VR, Virtual Router): the functionality of a router may be implemented in a network virtualization environment.

3) Virtual host (VM): a virtualized host in a network virtualization environment.

4) Network Function Virtualization (NFV) technology is a software implementation for implementing Network elements by using Virtualization technology, where the Network elements may be servers, VMs, VRs, etc. These network software are used in virtualized network environments with substantially the same functionality and effect as used in non-virtual network environments, such as real network environments.

5) IP (address) prefix: the first few bits of the IP address designation. Illustratively, the IP address is 202.202.202.5, and the IP address may be 202, 202.202, or 202.202.202.

6) An IP address segment (network segment) is a value range of an IP address. Illustratively, 202.202.202.0-202.202.202.9 are IP network segments.

7) Iterators (iterators), also called cursors (cursors), are software design models of programming, interfaces that can be accessed over containers (containers, such as linked lists or arrays) without concern for the contents of the containers. In the embodiment of the present application, the iterator is utilized to traverse the list, for example, traverse the global address pool referred to in the following embodiments of the present application.

In the related art, there may be a situation in which IP resources are greatly occupied by VMs in a single VR scene and in a multi VR scene. However, due to the limited number of VMs in a single VR, the problem that IP resources are greatly occupied is particularly significant in a multi-VR scenario. The embodiment of the application provides a problem that IP resources are greatly occupied by VM in a multi-VR scene, and certainly, a problem that IP resources are occupied in a single-VR scene can be solved. The scheme provided by the embodiment of the application is specifically as follows:

the application provides a method for creating an address pool, which can be applied to a server or a router. Since the embodiment of the application is directed to describing a multi-VR scenario of a virtual IPv6 network, the server may be a server virtualized in a virtual network environment as a virtual network environment; the router may be a VR virtualized in a virtual network environment.

The embodiment of the present application provides a first embodiment of a creating method, as shown in fig. 1, the method includes:

s101: aiming at each virtual routing VR in the virtual network environment, obtaining identification information of each VR;

in this step, the identification information of each VR is obtained by receiving the identification information of each VR input by the maintenance person. The identification information of the VR may be information for identifying the uniqueness of the VR in the virtual IPv6 network, such as the name of the VR. The identification information of the VR may be a combination of at least one of a number, a character, a letter, and a chinese character.

S102: obtaining identification information of an address pool to be created for each VR;

in this step, identification information of the address pool to be created is obtained by receiving identification information of the address pool to be created, which is input for each VR by a maintenance person. The identification information of the address pool may be information for identifying uniqueness of each address pool in the virtual IPv6 network, such as a name of the address pool. The identification information of the address pool may be a combination of at least one of numbers, characters, letters, and chinese characters.

S103: allocating network addresses to each address pool, wherein the network addresses comprise IP prefixes, address fields and/or IP addresses;

it is understood that the address pool may be used only for storing at least two IP addresses, only for storing IP prefixes, and only for storing address segments. Of course, it can also be used to store at least two kinds of information of IP address, address field, and IP prefix. When the address pool stores IP addresses, an appropriate IP address can be selected from the address pool and allocated to a VM under the VR to which the address pool belongs. When an IP prefix or an address field exists in the address pool, the prefix of the IP address assigned to the VM under the VR to which the address pool belongs needs to be the same as the prefix stored in the address pool, or the IP address assigned to the VM under the VR to which the address pool belongs needs to be located in the address field indicated by the address pool. The allocation of network addresses to the respective address pools is equivalent to allocating the address pools with information such as IP addresses, address fields, and/or IP prefixes that can be stored in the address pools.

In practical applications, it is preferable that the network address is an IP address, that is, it is preferable that an address pool is used for storing the IP address, so that it is easy to allocate the IP address of the VM under the VR to which the address pool belongs.

S104: creating address pools of the VRs according to the identification information of the address pools and the network addresses allocated to the address pools, wherein the network addresses in the address pools created for any two VRs in each VR can be different or at least partially the same;

in this step, the address pool of each VR is created according to the identification information of the address pool under each VR and the network address allocated to each address pool. The initial state of the address pool may be considered as empty, after the creation is completed, the address pool stores information such as an IP address and/or an IP prefix allocated to the address pool, and the address pool also has an identifier of the address pool, and it can be known which address pool is in the virtual IPv6 network through the identifier information. The purpose of the IP addresses in the address pool in the embodiment of the present application is to be subsequently assignable to the VM for use by the VM.

S105: and correspondingly storing the identification information of each VR and the address pool created for each VR.

In this step, the identification information of each VR and the address pool created for each VR are stored correspondingly. For example, assuming that the name of the VR and the name of the address pool are regarded as the respective identification information, the name of VR1, the name of the address pool under VR1, and the information stored in the address pool under VR1 having the name are recorded correspondingly. And correspondingly storing the name of VR2, the name of an address pool under VR2 and the network address stored in the address pool with the name under VR 2. This storage amounts to specifying the pool of addresses where each network address is located, and the VR where it is located. When an IP address is subsequently allocated to a VM under a certain VR, the VM may be allocated with an IP address according to the identifier of the VR to which the VM belongs and the identifier of the address pool, that is, the VM belongs to which VR and which address pool. If the VR identifier and the identifier of the address pool are regarded as a part of the content allocated as the address, and the network address in the address pool is regarded as another part of the content allocated as the address, the set of the two parts of the content can be regarded as the unique identification information of the VM under the virtual IPv6 network. Considering that the identification information of different VRs is different and the identification information of different address pools is different, even if the IP addresses allocated to the VMs are the same, the set of the two parts of content is unique under the virtual IPv6 network, which is equivalent to that under the virtual IPv6 network, each VM is identified by the set of the three information, i.e. the identification of the VR and address pool to which the VM belongs and the IP address, and the set of the three information of each VM is unique in the virtual IPv6 network, and the VM can normally communicate in the virtual IPv6 network by using the unique identification of itself. Thus, VMs under different VRs can use the same IP address. Based on this, in S104, in the solution for creating the address pools for different VRs, at least part of the same IP addresses may be allocated to the address pools of different VRs, or all of different IP addresses may be allocated to the address pools of different VRs. That is, according to the schemes of S101 to S105, since the identification information of each VR and the address pool created for each VR are correspondingly stored, that is, the identification of the VR is taken into account, partial same IP addresses or all same IP addresses can be allocated to the address pools of different VRs, and the situation that IP resources are occupied in a multi-VR scene can be greatly reduced. In addition, the VMs under the VRs can normally communicate in the virtual IPv6 network by using the unique identification information allocated to the VMs, and the normal communication of the VMs is not influenced.

In the foregoing multi-VR scenario, in S101 and S102, to distinguish different VRs, the identifiers of different VRs need to be different. The identification information of the address pools under different VRs may be the same or different, preferably different.

It is to be understood that the foregoing scheme is a scheme of address pool creation and storage for individual VRs for a multi-VR scenario. In practical applications, the number of address pools under each VR may be one, or may be two or more. Under the condition of two addresses, the IP addresses in different address pools need to be different, so that the problem that the same IP address is used by different VMs of the same VR and conflicts is solved. How to avoid the conflict of the IP addresses stored for different address pools under the same VR needs to refer to the scheme shown in fig. 2. As shown in fig. 2, for any one of the VRs, the method includes:

s201: obtaining identification information of each address pool to be created for the arbitrary VR, wherein the identification information of each address pool is different;

in this step, the identification information is obtained by receiving identification information of an address pool to be created for the arbitrary VR input by a maintenance person. Here, different identification information needs to be input for all the address pools to be created under the same VR to avoid confusion.

S202: respectively allocating network addresses to the address pools, wherein the network addresses allocated to the address pools are different;

in this step, the available network addresses in the virtual IPv6 network are grouped, and each group is assigned to a corresponding address pool. It will be appreciated that the network addresses stored in each address pool are different, since the available network addresses are different, as well as the network addresses assigned to each packet. That is, in the embodiment of the present application, the network addresses stored in all the address pools under the same VR are different, so as to avoid the occurrence of the situation that the plurality of VMs under the same VR cannot perform normal communication because they use the same network address.

S203: establishing each address pool under the arbitrary VR according to the identification information of each address pool and the network address allocated to each address pool;

in this step, the initial state of the address pool may be considered as empty, after the creation is completed, the address pool stores information such as an IP address and/or an IP prefix allocated to the address pool, and meanwhile, the address pool may also know which address pool is under the arbitrary VR through the identification information. Namely, the created address pool can not only know the address information stored in the address pool, but also know which address pool the address pool belongs to.

S204: and correspondingly storing the identification information of the arbitrary VR and each address pool established for the arbitrary VR.

In this step, for example, assuming that the name of the VR and the name of the address pool are regarded as the respective identification information, the name of the VR1, the name of the address pool 1 in the VR1, and the information stored in the address pool 1 are correspondingly stored or recorded. And correspondingly storing or recording the name of the VR1, the name of the address pool 2 under the VR1 and the network address stored in the address pool 2. In addition, the name of the address pool 1 under the VR1 and the network address stored in the address pool 1 can be correspondingly stored or recorded, the name of the address pool 2 under the VR1 and the network address stored in the address pool 2 can be correspondingly stored or recorded, and then the address pools are identified as the address pool under the VR1 on the basis of the stored contents.

The schemes of S201 to S204 are schemes of creating and storing each address pool under each VR in a multi-VR scenario and a single VR scenario. Network addresses in different address pools under the same VR are different, different VMs under the same VR are prevented from using different IP addresses to communicate, the problem of network conflict is avoided, and normal communication of the VMs under the same VR can be guaranteed.

In a scheme that multiple address pools need to be created for the same VR, please refer to the scheme shown in fig. 3 for how to ensure that information stored in an address pool does not conflict with information stored in other address pools in the VR for any one of the address pools in the same VR. The scheme shown in fig. 3 can also be regarded as a further description of the scheme for allocating network addresses for the arbitrary address pool at S202 in fig. 2:

s301: obtaining identification information of an address to be allocated, wherein the identification information at least indicates a prefix or a network segment to which a network address to be allocated belongs to the arbitrary address pool;

in this step, a certain IP prefix or a segment to which the IP prefix belongs may be reserved for each VR, and/or a certain number of IP addresses may be reserved for each VR. This information may be allocated to a pool of addresses that is subsequently created for each VR. When an address pool is created in the arbitrary VR and a next address pool (a subsequent current address pool) needs to be created through S301 to S305, it is necessary to read a prefix of an IP address or an IP network segment that has not been allocated in the above information reserved for the arbitrary VR.

S302: obtaining address identifiers of other address pools created for the arbitrary VR, wherein the address identifiers at least indicate prefixes (address prefixes) of network addresses allocated to the other address pools or network segments to which the address identifiers belong;

in S302, address prefixes or network segments of other address pools of the arbitrary VR are read.

S303: judging whether the identification information of the address to be allocated is the same as the address identification of the other address pools;

if not, executing S304;

if the two are determined to be the same, S305 is executed;

in this step, it is determined whether the address prefix pre-allocated in the current address pool or the network segment to which the address prefix pre-allocated in the current address pool belongs is the same as the address prefixes or the network segments to which the address prefixes in other address pools or the network segments to which the address.

S304: and allocating the prefix indicated by the identification information or the network address of the network segment to the arbitrary address pool.

In this step, when the network addresses are judged to be different, the network addresses having the address prefixes pre-allocated to the current address pool or the network segments to which the address prefixes belong in the virtual IPv6 network are allocated to the current address pool.

S305: obtaining the identifiers of the other address pools, the address identifiers of which are the same as the identifier information; obtaining a target network address, wherein the target network address is a prefix indicated by the identification information or a network address of a network segment which the target network address belongs to in other address pools of the identification; and allocating a free network address different from the target network address to the arbitrary address pool.

In this step, under the condition that the addresses are the same, reading the address prefix pre-allocated for the current address pool or the identifier, such as the name, of other address pools having the same address prefix or the same network segment as the network segment to which the addresses belong, reading the content stored in the address pool having the name, and taking the content as the target network address. And allocating network addresses which have address prefixes or network segments pre-allocated for the current address pool and are different from the target network address in the virtual IPv6 network to the current address pool. Therefore, the information stored in the current address pool under the same VR is guaranteed not to conflict with the information stored in other address pools under the same VR, and normal communication of subsequent VMs can be facilitated.

In some embodiments, at least one virtual host VM exists under each VR, and after creating the address pool of each VR or storing the identification information of each VR and the address pool created for each VR correspondingly, the method further includes: and binding network addresses, specifically address prefixes or address network segments, for any VM under any VR according to the address pool created for any VR in the VRs. When the IP address is subsequently allocated to a certain VM under a certain VR, an IP address is selected from the addresses bound for the VM and allocated to the VM.

In some embodiments, the specific implementation manner of binding the network address for any VM under any VR according to the address pool created for any VR in the VRs includes any one of the following:

first, in a case where an address pool created for the arbitrary VR is used only for storing IP addresses, it is determined that no lease IP address exists in the address pool, and the IP address is bound to the arbitrary VM; and under the condition that an address pool created for the arbitrary VR is only used for storing IP prefixes or address fields, determining that no leased IP prefixes or address fields exist in the address pool, and binding the IP prefixes or address fields with the arbitrary VM.

Secondly, acquiring a target prefix or a target network segment, and binding an IP prefix or an address segment which does not have a lease and has the target prefix or the target network segment in an address pool established for the arbitrary VR with the arbitrary VM; and/or binding an IP address which has no lease and has the target prefix or the target network segment in an address pool created for the arbitrary VR with the arbitrary VM. The target prefix or target network segment may be an IP prefix or address segment specified by the VM requesting allocation of an IP address.

The binding scheme can conveniently realize the subsequent allocation of IP addresses for a certain VM under a certain VR.

In practical application, if an IP address changes from idle to non-idle state, that is, the IP address will be allocated to a certain VM for use, a lease corresponding to the IP address is generated, and the lease at least records information of the duration of the IP address being used, the VM to which the IP address is allocated for use, and the like. Therefore, in the foregoing solution, an IP address without a lease can be regarded as an IP address in an idle state that has not been allocated, and an IP prefix or an address field without a lease can be regarded as an IP prefix or an address field in an idle state that has not been allocated, so that the binding of an idle network address with the arbitrary VM can be realized.

In some embodiments, the arbitrary VM may be assigned a target IP that is an IP address that does not have a lease conflict with leases generated when other VMs under the arbitrary VR are assigned IP addresses in the network addresses bound for the arbitrary VM. That is, in the scheme of IP allocation for a VM, it is ensured that an idle IP can be allocated to the VM based on detection of whether lease conflict exists for leases of IP addresses, so that different VMs under the same VR use different IPs to avoid IP conflict of different VMs under the same VR.

The present application will be described in further detail with reference to the embodiments shown in fig. 4 to 7.

Taking the virtual IPv6 network shown in fig. 4 as an example, in the virtual IPv6 network, at least two VRs are included, where VM1 and VM2 exist under VR 1; VM 3 and VM 4 exist under VR 2. The DVR is a distributed route in a virtual IPv6 network; the DVS is a distributed switch in a virtual IPv6 network. Each VR in the virtual IPv6 network can configure information such as IP, address, IP prefix, etc. for the VM existing under it according to the DHCPv6 protocol. Prior to configuration of the foregoing information, a server, such as a server, in a virtual IPv6 network may perform the creation of address pools for individual VRs. It is to be understood that since the virtual network is a virtual IPv6 network, the IP addresses subsequently involved are all IPv6 addresses.

In the application scenario, the identifier of the VR is taken as the name of the VR, the identifier of the address pool is taken as the name of the address pool,

the flow of creation is shown in figure 5,

taking VR1 as an example to create the 3 rd address pool,

the server receives the name of the address pool to be created (3 rd address pool of VR1) and the name of the VR to which the address pool to be created belongs (namely the name of VR1) input by a maintenance person, and detects whether the two input names are legal. It will be appreciated that a name may be embodied in the form of at least one of a number, a letter, a character, or a combination of at least two thereof, and that the detection of legitimacy is the detection of compliance of the name with a predetermined naming convention, e.g., the predetermined naming convention may include that the name of the VR needs to be named using a combination of a number and a letter. If the detection shows that both the number and the letter exist in the VR1 name, the name is considered to be in accordance with the naming rule, and the validity detection is passed. And under the condition that the validity detection of the address pool name and the VR name is passed, judging whether an address pool which is the same as the name of VR1 and the name of the 3 rd address pool of VR1 exists in the global address pool or not. And if one fails in the validity detection of the address pool name and the VR name, ending the process. If an address pool identical to the name of VR1 and the name of VR 1's 3 rd address pool exists in the global address pool, it is indicated that VR1 has created an address pool for the name, the names of the address pools are repeated, and the process ends. If there is no address pool in the global address pool that is the same as the name of VR1 and the name of VR 1's 3 rd address pool, it means that VR1 has not created an address pool for the name, which can be used as the name of an address pool under VR 1.

The global address pool records a corresponding relationship between the name of the VR with the created address pool and the name of the created address pool under the VR. On this basis, information such as IP addresses, prefixes, and the like in each address pool created under each VR can also be recorded.

In the case where the name of the address pool (3 rd address pool of VR1) input by the maintenance person is usable, the number of address pools that have been created under VR1 to which the address pool belongs is calculated. This number may be obtained from the global address pool, and if the calculated number is greater than or equal to the set first threshold, indicating that the number of address pools created under VR1 has exceeded the limit, the process ends. And if the calculated number is smaller than the set first threshold, the number of the created address pools under VR1 is not over-limited, the name of VR1 and the name of the 3 rd address pool of VR1 input by maintenance personnel are used as the name of a new address pool to be created for VR1, and the name of VR1 and the name of the 3 rd address pool of VR1 are added into the global address pool. It is understood that within the same VR, such as VR1, different address pools may be uniquely represented by respective names. In a multi-VR scenario, the name of the address pool needs to be combined with the VR name to which the address pool belongs to serve as a unique identifier of the address pool in the virtual IPv6 network.

It can be appreciated that to identify the uniqueness of individual VRs in a virtual IPv6 network, the name of each VR needs to be different. Under the condition that the values of the names of the VRs are different, the values of the address pools under different VRs can be the same or different, preferably different.

The server may allocate an IP address and an IP prefix to a 3 rd address pool (current address pool) under VR1, where the allocation process is: the method comprises the steps that a server side obtains idle IP addresses in a virtual IPv6 network when a 3 rd address pool of VR1 is created, prefixes of the idle IP addresses are read, prefixes of other address pools of the VR1, such as the prefixes of the 1 st address pool and the 2 nd address pool, are searched from a global address pool, whether the read prefixes are the same as the prefixes searched in the global address pool or not is judged, and under the condition that the read prefixes are not the same as the prefixes searched in the global address pool, the read address prefixes can be distributed to a current address pool, and the IP addresses with the address prefixes can be distributed to the current address pool. At this time, the current address pool may store the allocated address prefix and the allocated IP address, the name of the current address pool and the name of the VR to which the current address pool belongs may be used for identification in the virtual IPv6 network of the current address pool, and the current address pool is created successfully. And if the prefixes found in the global address pool are the same as the read address prefixes, allocating prefixes, which are different from the prefixes found in the global address pool, in the virtual IPv6 network to the current address pool, and allocating the free IP address with the prefixes to the current address pool.

The foregoing scheme of searching for prefixes or IP addresses of other address pools of the VR1, such as the 1 st address pool and the 2 nd address pool, from the global address pool and determining whether the found prefixes or IP addresses are the same as the prefixes or IP addresses of the current address pool may be regarded as a collision detection scheme. The significance of the prefix conflict detection scheme in the application scenario is as follows: to avoid address conflicts that may result from using the same IP address under the same VR, different address pools under the same VR may be allocated with different prefixes and different IP addresses. This avoids both prefix collisions and IP collisions that result from different address pools under the same VR having the same IP.

It can be understood that, in the creation scheme in the embodiment of the present application, it is only necessary to detect whether there is a prefix conflict or an IP address conflict between address pools under the same VR, and it is not necessary to detect whether there is a prefix conflict or an IP address conflict between address pools under different VRs. Since the name of the address pool needs to be combined with the name of the VR to which the address pool belongs to serve as the unique identifier of the address pool in the virtual IPv6 network, in the embodiment of the present application, at least part of the same IP address may be allocated to address pools of different VRs, or all different IP addresses may be allocated to address pools of different VRs. Under the condition that partial same IP addresses or all same IP addresses are allocated to address pools of different VRs, the condition that IP resources are occupied under the multi-VR scene can be greatly reduced.

The foregoing collision detection scheme may also be implemented in the following manner:

the global address pool records the names of the VRs created with the address pools, the names of the created address pools, and information such as IP prefixes and IP addresses stored in the address pools. With these contents of the global address pool records, collision detection is performed. As shown in fig. 6, the server side uses the obtained first prefix iterator to traverse the IP prefixes and the IP addresses recorded in the global address pool one by one. And traversing the IP prefix and the IP address pre-allocated to the current address pool one by using the acquired second iterator, comparing the results of the traversal of the IP prefix and the IP address each time, and comparing whether the IP addresses traversed each time are the same, whether the IP prefixes are the same and whether the VR names are the same. And if any comparison result is different, traversing the next IP prefix and the next IP address, repeating the process until all the IP prefixes and all the addresses are traversed, or traversing the result that the IP prefix, the IP address and the VR name are the same, and ending the process.

It will be appreciated that, assuming that an IP address pre-assigned to the current address pool is IP1, using the traversal and comparison scheme described above, a search is made to see if there is a record in the global address pool that corresponds to the IP address, the prefix of the IP address, and the name of the VR (VR1) to which the current address pool belongs. I.e. whether there is an IP address in the global address pool that is the same as the IP1, an address prefix that is the same as the prefix of the IP1, and a VR name that is the same as the name of VR 1. If none of the three exist, indicating that the conflict detection passed, prefixes of IP1, IP1 may be assigned to the current address pool. If prefixes of IP1 or IP1 exist in other address pools under VR1 in the global address pool, collision detection is not passed, and prefixes in other address pools that are idle in the virtual IPv6 network and are different from those under VR1 are allocated to the current address pool.

By using the scheme, different prefixes and different IP addresses can be allocated to different address pools under the same VR. This avoids both prefix collisions and IP collisions that result from different address pools under the same VR having the same IP.

In the case where the 3 rd address pool (current address pool) of the VR1 is created, allocation of IP addresses may be made for the VM1 or VM2 under the VR 1. Before address allocation is carried out for the VMs, address prefix binding can be carried out for each VM, so that a prefix is selected for the VM from the address prefixes of the binding, and an IP address with the prefix is allocated.

The binding process of the address prefix is as follows:

as shown in fig. 7, VM1 under VR1 requests VR1 to obtain the address prefix it needs from the 3 rd address pool under VR1, assuming the address prefix is 202.202.202. The VR1 receives the request, parses out the name of the 3 rd address pool and the name of the VR1 carried in the request. The server side searches whether a 3 rd address pool of VR1 exists in the global address pool according to the two names. If so, it is determined whether the number of bound prefixes of the address pool exceeds a second threshold. That is, it is determined whether the number of bound prefixes of the address pool exceeds the limit, and if the number of bound prefixes exceeds the limit, the address prefixes cannot be bound for the VM1, and the process is ended. If the limit is not exceeded, the binding of the prefix may be done for VM 1. And judging whether the 3 rd address pool of the VR1 has the address prefix which the VM1 expects to bind, and if not, ending the process. If so, determining the IP addresses with the address prefixes in the 3 rd address pool, judging whether leases exist in the (IP) addresses, if so, indicating that the IP addresses are allocated, and binding the IP addresses without the leases and the address prefixes required by the VM1 with the VM 1. At a technical level, binding corresponds to recording the name of the VM1, the address prefix of the binding, and the IP address of the binding in the global address pool.

The address allocation process comprises the following steps:

VM1 requests VR1 to assign an IP address, VR1 receives the request, looks up from the global address pool if there is an address binding record for VM1, based on the name of VR1 and the name of VM 1. If so, the VR1 assigns one of the IP addresses recorded in the global address pool bound for that VM1 to VM1 for use by VM1 in communicating in the virtual IPv6 network. Or, to avoid the conflict between the IP addresses allocated to the VMs under the same VR, when the IP addresses are allocated, it is determined which IP address does not have a lease in the IP addresses bound to the VM1 recorded in the global address pool, and the IP address without the lease is allocated to VM 1.

It can be understood that when an IP address is allocated to a VM for use, a lease corresponding to the IP address is generated for the IP address, and the lease in this embodiment of the present application describes information about the duration of time that the IP address can be used, which VM the IP address is allocated to for use, and which VM under which VR the VM belongs to. Because the lease is recorded with the name of the VR to which the VM to which the IP address is assigned belongs, if a certain IP address is assigned and a lease exists, the VR name information in the lease indicates to which VM under the VR the corresponding IP address is assigned. In a virtual IPv6 network, it is specified that communication data generated by a VM needs to be routed through the VR to which it belongs. The VM1 can send communication data to the VR1 to which it belongs using the IP address assigned to it, and the VR1 can determine if the VM belongs to the VM under itself by the VR name in the lease if received, and if the VR name in the lease and the name of the VR receiving the communication data remain the same, then the VM belongs to the VM under itself, which can result in accurate distribution of the communication data. The scheme for determining whether the IP address has a lease and allocating the lease according to the determination result may be regarded as a lease conflict detection scheme, and the scheme may ensure that an idle IP is allocated to the VM1, so that different VMs under the same VR use different IPs, so as to avoid IP conflicts of different VMs under the same VR, and implement normal communication of each VM in the virtual IPv6 network.

Several big advantages that exist under many VR scenes of this application embodiment are:

1) in the scheme for creating the VR address pool, the identifier of the address pool and the identifier of the VR to which the address pool belongs are used as the identifiers of the address pool in the virtual IPv6 network, so as to distinguish different address pools. The IP address differentiation is also needed in the virtual IPv6 network by combining VR identification and address pool identification. Based on this, in this embodiment of the present application, at least part of the same IP addresses may be allocated to address pools of different VRs, or all different IP addresses may be allocated to address pools of different VRs. Under the condition that partial same IP addresses or all same IP addresses are allocated to address pools of different VRs, the condition that IP resources are occupied under the multi-VR scene can be greatly reduced.

2) Because the same VR's sign is the same, so inside same VR, for each address pool under the same VR distributes different IP addresses to avoid the IP conflict of different VMs under the same VR.

An embodiment of the present application provides a creating apparatus, and as shown in fig. 8, the method includes: a first obtaining unit 1001, a second obtaining unit 1002, an assigning unit 1003, a creating unit 1004, and a storing unit 1005; wherein,

a first obtaining unit 1001, configured to obtain, for each virtual routing VR in a virtual network environment, identification information of each VR;

a second obtaining unit 1002, configured to obtain identification information of an address pool to be created for each VR;

an allocating unit 1003, configured to allocate a network address to each address pool, where the network address is at least one of an IP prefix, an address segment, and an IP address of an internet protocol address;

a creating unit 1004, configured to create address pools of the VRs according to the identification information of the address pools and the network addresses allocated to the address pools, where the network addresses in the address pools created for any two VRs in each VR may be different or at least partially the same;

a storage unit 1005, configured to correspondingly store the identification information of each VR and the address pool created for each VR.

In some embodiments, for any one of the individual VRs,

the second obtaining unit 1002 is configured to obtain identification information of each address pool created for the VR, where the identification information of each address pool is different;

the allocating unit 1003 is configured to allocate network addresses to the address pools, where the network addresses allocated to the address pools are different;

the creating unit 1004 is configured to create each address pool under the arbitrary VR according to the identification information of each address pool and the network address allocated to each address pool;

correspondingly, the storage unit 1005 is configured to correspondingly store the identification information of the arbitrary VR and each address pool created for the arbitrary VR.

In some embodiments, the allocating unit 1003 is configured to, for any one of the address pools,

In some embodiments, the allocating unit 1003 is configured to, in case that the two are determined to be the same,

and allocating a network address different from the target network address to the arbitrary address pool.

In some embodiments, the apparatus further includes a binding unit, configured to bind a network address for any VM under any VR in the VR according to an address pool created for the any VR.

In some embodiments, the binding unit is configured to determine that an IP address of a lease does not exist in the address pool, and bind the IP address with the arbitrary VM; and/or determining that no leased IP prefix or address field exists in the address pool, and binding the IP prefix or address field with the arbitrary VM;

In some embodiments, the arbitrary VM may be assigned a target IP that is an IP address that does not have a lease conflict with leases generated when other VMs under the arbitrary VR are assigned IP addresses in the network addresses bound for the arbitrary VM.

It is understood that the first obtaining Unit 1001, the second obtaining Unit 1002, the allocating Unit 1003, and the creating Unit 1004 in the creating apparatus may be implemented by a Central Processing Unit (CPU), a Digital Signal Processor (DSP), a Micro Control Unit (MCU) or a Programmable Gate Array (FPGA) of the apparatus in practical applications. The storage unit 1005 may be implemented by the memory 62 as shown in fig. 9. In a specific implementation, the creating device may be a server virtualized in a virtual IPv6 network, and based on this, the aforementioned CPU, MCU, and FPGA may be regarded as a virtualized processing element.

It should be noted that, in the creating device according to the embodiment of the present application, because the principle of the creating device for solving the problem is similar to that of the creating method, both the implementation process and the implementation principle of the creating device can be described by referring to the implementation process and the implementation principle of the method, and repeated details are not repeated.

An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, where the computer program is configured to, when executed by a processor, perform at least the steps of the method shown in any one of fig. 1 to 7. The computer readable storage medium may be specifically a memory. The memory may be memory 62 as shown in fig. 9.

Fig. 9 is a schematic diagram of a hardware structure of a creating device according to an embodiment of the present application, and as shown in fig. 9, the creating device includes: a communication component 63 for data transmission, at least one processor 61 and a memory 62 for storing computer programs capable of running on the processor 61. The various components in the terminal are coupled together by a bus system 64. It will be appreciated that the bus system 64 is used to enable communications among the components. The bus system 64 includes a power bus, a control bus, and a status signal bus in addition to the data bus. For clarity of illustration, however, the various buses are labeled as bus system 64 in fig. 6.

Wherein the processor 61 executes the computer program to perform at least the steps of the method shown in any one of fig. 1 to 3 and 5 to 7.

It will be appreciated that the memory 62 can be either volatile memory or nonvolatile memory, and can include both volatile and nonvolatile memory. Among them, the nonvolatile Memory may be a Read Only Memory (ROM), a Programmable Read Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a magnetic random access Memory (FRAM), a Flash Memory (Flash Memory), a magnetic surface Memory, an optical disk, or a Compact Disc Read-Only Memory (CD-ROM); the magnetic surface storage may be disk storage or tape storage. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), Enhanced Synchronous Dynamic Random Access Memory (Enhanced DRAM), Synchronous Dynamic Random Access Memory (SLDRAM), Direct Memory (DRmb Access), and Random Access Memory (DRAM). The memory 62 described in embodiments herein is intended to comprise, without being limited to, these and any other suitable types of memory.

The method disclosed in the above embodiments of the present application may be applied to the processor 61, or implemented by the processor 61. The processor 61 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 61. The processor 61 described above may be a general purpose processor, a DSP, or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. The processor 61 may implement or perform the methods, steps and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium located in the memory 62, and the processor 61 reads the information in the memory 62 and performs the steps of the aforementioned method in conjunction with its hardware.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described device embodiments are merely illustrative, for example, the division of the unit is only a logical functional division, and there may be other division ways in actual implementation, such as: multiple units or components may be combined, or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the coupling, direct coupling or communication connection between the components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between the devices or units may be electrical, mechanical or other forms.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed on a plurality of network units; some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be separately regarded as one unit, or two or more units may be integrated into one unit; the integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional unit.

Those of ordinary skill in the art will understand that: all or part of the steps for implementing the method embodiments may be implemented by hardware related to program instructions, and the program may be stored in a computer readable storage medium, and when executed, the program performs the steps including the method embodiments; and the aforementioned storage medium includes: a mobile storage device, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

Alternatively, the integrated units described above in the present application may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as independent products. Based on such understanding, the technical solutions of the embodiments of the present application may be essentially implemented or portions thereof contributing to the prior art may be embodied in the form of a software product stored in a storage medium, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a removable storage device, a ROM, a RAM, a magnetic or optical disk, or various other media that can store program code.

The methods disclosed in the several method embodiments provided in the present application may be combined arbitrarily without conflict to obtain new method embodiments.

Features disclosed in several of the product embodiments provided in the present application may be combined in any combination to yield new product embodiments without conflict.

The features disclosed in the several method or apparatus embodiments provided in the present application may be combined arbitrarily, without conflict, to arrive at new method embodiments or apparatus embodiments.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of creation, the method comprising:

for each virtual routing VR in the virtual network environment,

obtaining identification information of each VR;

2. The method of claim 1, wherein for any of the VRs, the method further comprises:

3. The method according to claim 2, wherein for any one of the address pools, said allocating network addresses for the any address pool comprises:

4. The method of claim 3, further comprising:

in the case where it is judged to be the same,

5. The method of any of claims 1 to 4, wherein there is at least one virtual host VM under each VR, and after the creating of the address pool for each VR, the method further comprises:

6. The method of claim 5, wherein binding network addresses for any VM under any of the VRs based on a pool of addresses created for the any VR, comprises:

7. The method of claim 5 or 6, wherein the arbitrary VM can be assigned a target IP, and the target IP is an IP address that does not have a lease conflict with leases generated when IP addresses are assigned to other VMs under the arbitrary VR from among the network addresses bound for the arbitrary VM.

8. A creation device, comprising:

a first obtaining unit, configured to obtain, for each virtual routing VR in a virtual network environment, identification information of each VR;

the allocation unit is used for allocating network addresses to each address pool, wherein the network addresses are at least one of internet protocol address (IP) prefixes, address fields and IP addresses;

9. The apparatus of claim 8, wherein for any one of the individual VRs,

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.

11. A creation device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method of any of claims 1 to 7 are implemented when the processor executes the program.