WO2016000648A1

WO2016000648A1 - Controlling virtual edge port aggregator

Info

Publication number: WO2016000648A1
Application number: PCT/CN2015/083240
Authority: WO
Inventors: Xinmin Liu
Original assignee: Hangzhou H3C Technologies Co., Ltd.
Priority date: 2014-07-03
Filing date: 2015-07-03
Publication date: 2016-01-07
Also published as: CN105227499B; CN105227499A

Abstract

A virtual edge port aggregator (VEPA) controller set in an edge virtual bridging (EVB) network detects a virtual machine (VM) is newly established on a VEPA controlled by the VEPA controller, and determine a network security policy corresponding to the VM according to service information of the VM. The VEPA controller determines an access switch corresponding to the VEPA according to obtained connection relations between VEPAs controlled by the VEPA controller and access switches. The VEPA controller sends the network security policy to the access switch to enable the access switch to forward data packets received from the VM according to the network security policy.

Description

CONTROLLING VIRTUAL EDGE PORT AGGREGATOR

Background

Virtualization techniques for data centers include network virtualization, storage virtualization and server virtualization. In server virtualization, a physical server is virtualized into plural virtual machines (VM) using specialized virtualization software (e.g., VMware) . The VMs are independent from each other, and each has its own operating system, applications and virtual hardware.

Technical standards for Edge Virtual Bridging (EVB) are defined in Institute of Electrical and Electronics Engineers (IEEE) 802.1Qbg. The EVB techniques include EVB for switches and EVB for stations. EVB for stations is applicable to servers in data centers, and is implemented by virtual switches in the servers to simplify traffic forwarding procedures of virtualized servers. EVB techniques performs centralized control over virtualized servers in aspects including network switching, traffic management and policy issuance, and implement automatic migration of network management and policies when a VM migrates to another data center.

Brief Description of the Drawings

Features of the present disclosure are illustrated by way of example and not limited in the following figures, in which like numerals indicate like elements, in which:

FIG. 1 is a schematic diagram illustrating a network to which a VEPA control mechanism is applied in accordance with examples of the present disclosure；

FIG. 2 is a flowchart illustrating a VEPA control process in accordance with examples of the present disclosure；

FIG. 3 is a flowchart illustrating a VEPA control process in accordance with examples of the present disclosure；

FIG. 4 is a schematic diagram illustrating a structure in which a VEPA controller obtains connection relations between VEPAs and access switches in accordance with examples of the present disclosure；

FIG. 5 is a schematic diagram illustrating VEPA controllers in a cluster mode in accordance with examples of the present disclosure；

FIG. 6 is a schematic diagram illustrating modules of a VEPA controller in accordance with examples of the present disclosure；

FIG. 7 is a schematic diagram illustrating modules of a VEPA controller in accordance with examples of the present disclosure.

Detailed Descriptions

For simplicity and illustrative purposes, the present disclosure is described by referring mainly to an example thereof. But not all examples are shown. Indeed, the technical mechanism may be embodied in many different forms and should not be construed as limited to the examples set forth herein. Rather, these examples are provided so that this disclosure will satisfy applicable legal requirements. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be readily apparent however, that the present disclosure may be practiced without limitation to these specific details. In other instances, some methods and structures have not been described in detail so as not to unnecessarily obscure the present disclosure. 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. Quantities of an element, unless specifically mentioned, may be one or a plurality of, or at least one.

Virtual switches supporting EVB may include virtual edge bridges (VEB) and virtual edge port aggregators (VEPA) . A VEPA forwards all network traffic generated by VMs in a server to a physical edge switch connected to the server for processing. That is, traffic exchanged between VMs located in the same server is also forwarded by an edge switch to destination VMs according to a forwarding table.

IEEE 802.1Qbg defines a control mechanism for VEPA. The control mechanism defines an application model including four roles, i.e., virtualized server cluster, virtual machine manager (VMM) , edge access switch and virtual station interface (VSI) manager. A VEPA reports the network state of a VM to an edge access switch through standard VSI discovery and configuration protocol (VDP) sessions. Each VM is mapped to a VSI in the network.

In a virtualization network, optimization of VEPA forwarding process is generally carried out on the basis of distributed virtual switches (DVS) . Specifically, vSwitches in multiple hosts are controlled in a centralized manner, which forms a distributed VEPA control mechanism. A DVS manager is set up between a network manager system (NMS) and a VMM for controlling VEPAs. A VEPA performs VDP communications with an edge access switch to report that the VMs are active. The NMS issues configuration information about network security policies for VMs to the edge access switch. The VEPA sends data packets from a VM to the edge access switch, and the edge access switch forwards the data packets according to network security policies configured in the edge access switch for the VM. Various examples of the present disclosure provide a VEPA control mechanism. As shown in FIG. 1, a VEPA controller is deployed in an EVB network. The VEPA controller is capable of communicating with VEPAs, the VMM and the edge access switch. As such no VDP communication is performed between the VEPA and the access switch, and network security policies of VMs are no longer issued by the NMS to the access switch, but are implemented by the VEPA controller. This mechanism greatly simplifies the VEPA control mechanism, and improves operating efficiency of the network.

The VEPA controller and the VEPA form a distributed vSwitch which has a structure similar to that of a common distributed vSwitch. The distributed vSwitch may adopt 802.1Qbg as the protocol for the forwarding plane, protocols including the software defined network (SDN) protocol and the network configuration (NetConf) protocol as the protocol for the control plane. The SDN protocol may be the Openflow protocol, or the like.

FIG. 2 is a flowchart illustrating a VEPA control process in accordance with examples of the present disclosure. The method may include the following procedures.

At block S21, a VEPA controller in an EVB network may detect a VM is newly established in a VEPA controlled by the VEPA controller, and determine a network security policy corresponding to the VM according to service information of the VM.

At block S22, the VEPA controller may obtain connection relations between VEPAs controlled by the VEPA controller and access switches, and determine an access switch corresponding to the VEPA. The connection relations may specify the access switch with which each VEPA is connected to. In an example, a VEPA is connected to a port of an access switch and forwards network traffic generated by VMs to the access switch, the connection relation may specify a relation which associates the VEPA with the access switch.

At block S23, the VEPA controller may send the network security policy and the address of the VM to the access switch so that the access switch may forward data packets from the VM according to the network security policy.

In an example, the VEPA controller may detect a newly established VM in any VEPA controlled by the VEPA controller at block S21 according to the method as shown in FIG. 3.

In an example, the detection may be triggered by the first data packet of a flow, and may be as follows.

At block S31, a VEPA may receive a data packet sent by a VM connected to the VEPA through a virtual port (vPort) of the VEPA, search a flow table in the VEPA for a flow table entry corresponding to the data packet. If no flow table entry corresponding to the data packet is found, the VEPA determines the data packet is the first data packet of a flow, and sends the first data packet to the VEPA controller. The VM connected to the VEPA refers to a VM directly connected to the vPort of the VEPA. Such VM is generally located in the same physical device with the VEPA.

If the data packet is not the first packet of a flow, the VEPA may find a flow table entry corresponding to the data packet in the flow table, and send the data packet to an access switch according to the flow table entry. The origin and content of a flow table entry is described in block S32.

At block S32, the VEPA controller may receive the first data packet sent by the VEPA, return a flow table entry to the VEPA. The flow table entry may include a condition of “from vPort” and an action of “send to access switch” . The VEPA controller may also search a VM list corresponding to the VEPA stored in the VEPA controller for the source address of the first data packet, perform procedures in blocks S33 to S34 if the source address is not found in the VM list, or terminate the process if the source address is found in the VM list.

After receiving the flow table entry sent by the VEPA controller, the VEPA may send the first data packet to the access switch according to the flow table entry.

At block S33, the VEPA controller may determine the VM that sent the first data packet is a VM newly established on the VEPA.

In this disclosure, a VM established on a VEPA refers to a VM established in a physical device where the VEPA locates.

In this regard, the VEPA controller may add the address of the VM (i.e., the source address of the first data packet) and other information into a VM list of the VEPA stored in the VEPA controller. The other information may include information of services supported by the VM or the like.

At block S34, the VEPA controller may judge whether the address of the VM is found in a VM list of another VEPA (i.e., not the VEPA that sent the first data packet) stored in the VEPA controller. If the VM is in a VM list of another VEPA, the VEPA controller may determine the VM has migrated to the VEPA that sent the first data packet, and delete the address of VM from the VM list of the another VEPA.

For example, supposing the VEPA that sent the first data packet is a first VEPA, the VEPA finds the source address of the first data packet in a VM list of a second VEPA stored in the VEPA controller. This means the VM corresponding to the source address of the first data packet has migrated from the second VEPA to the first VEPA, thus the address of the VM is deleted from the VM list of the second VEPA.

The VM migrating from the second VEPA to the first VEPA is equivalent to the VM is deleted from the second VEPA and is newly established in the first VEPA.

According to this detection method, the VEPA controller can obtain information about states of a VM, e.g., establishment, migration, deletion or the like, through communication with the VEPA. As such, the VEPA does not have to perform VDP communications with the access switch, thus the interaction process is simplified.

In an example, the detection may be implemented at a VMM, and may be as follows.

Since establishment and deletion of VMs are implemented by the VMM, the VMM may send a VM establishment message to the VEPA controller after establishing a VM on a VEPA. The VM establishment message may include: an address of the VM, information of services supported by the VM, an address of the VEPA to which the VM is connected, and the like. The VEPA controller may receive the VM establishment message, add information such as the address of the VM, the information of services supported by the VM, etc. obtained from the message into a VM list corresponding to the VEPA identified by the address of the VEPA in the message.

Accordingly, when the VMM has deleted a VM, the VMM may send a VM deletion message to the VEPA controller. The VM deletion message may include: an address of the VM, an address of a VEPA to which the VM is connected. The VEPA controller may receive the VM deletion message, and delete information of the VM identified by the VM address in the message from a VM list corresponding to the VEPA identified by the VEPA address in the message.

In an example, a relation which associates service information with a network security policy may be stored in advance in the VEPA at block S21. The service information may be a service type or a service template or the like. As such, after detecting a VM is newly established on a VEPA controlled by the VEPA controller, the VEPA controller can search the relation for a network security policy corresponding to the VM according to service information of the VM, and send the network security policy to the access switch corresponding to the VM. According to the examples, the VEPA controller may perform unified control over VEPAs and access switches, which reduces communicating parties, simplifies the message interaction process, and greatly improves the operating efficiency of the network.

In an example, at block S22, the VEPA controller may obtain the connection relations between the VEPAs and the access switches according to the following methods.

In an example, an administrator or the like may configure the connection relations between the VEPAs and the access switches in the VEPA controller in advance. The VEPA controller can thus obtain the connection relations from a pre-configured file.

A connection relation between a VEPA and an access switch may include: an address of the VEPA, an address of the access switch, an identify of a port on the access switch through which the VEPA is connected to the access switch.

In another example, the VEPA controller may automatically discover the connection relations between the VEPAs controlled by the VEPA controller and the access switches through a pre-defined mechanism, such as the Link Layer Discovery Protocol (LLDP) . In an example, the discovery process may be as follows.

Procedure a: LLDP functions are enabled in advance at ports on VEPAs which connect to access switches and ports on access switches which connect to VEPAs, and a flow table entry is pre-configured in each VEPA and each access switch.

The flow table entry may include a condition being “LLDP packet received” and an action being “send to VEPA controller” .

Procedure b, each VEPA and each access switch may automatically send LLDP packets through respective ports that have enabled LLDP functions after startup.

Procedure c, an access switches may receive an LLDP packet sent by a VEPA which matches the flow table entry pre-configured in procedure a, generate a Packet-in packet. The received LLDP packet may be encapsulated into the Packet-in packet. The Packet-in packet may also include an ingress port through which the LLDP packet is received. The VEPA controller may obtain the address of the access switch (i.e., the source address of the Packet-in packet) , the ingress port on the access switch through which the LLDP packet is received after receiving the Packet-in packet. The VEPA controller may decapsulate the Packet-in packet to obtain the LLDP packet, and obtain the address of the VEPA from the source address of the LLDP packet. As such, the VEPA controller may obtain the address of the access switch, the address of the VEPA and the ingress port on the access switch that is connected to the VEPA.

Likewise, the VEPA controller may obtain connection relations between all of VEPAs controlled by the VEPA controller and access switches after receiving Packet-in packets (in which LLDP packets are encapsulated) sent by the VEPAs and the access switches (as shown in FIG. 4 which illustrates the VEPA controller obtains connection relations between VEPAs and access switches) .

In an example, the access switch may store a relation which associates the address of the VM with the network security policy at block S23 for use in subsequent forwarding process.

In an example, if the access switch determined by the VEPA controller is a Openflow switch, the Openflow switch may process the network security policy sent by the VEPA controller according to a standard Openflow protocol. If the access switch determined by the VEPA controller, the network security policy sent by the VEPA controller may be converted by a software adapter into an access control list (ACL) supported by the chip of the access switch to implement security control.

In an example, a VEPA may receive a data packet sent by a VM connected to the VEPA through a vPort, and send the data packet to an access switch connected to the VEPA. The access switch may apply the network security policy to the data packet and then forward the data packet.

The following are examples to make the VEPA send all data packets received from vPorts to the access switch.

In an example, a flow table entry may be pre-configured in the VEPA.

The flow table entry may include a condition of “data packet from vPort” and an action of “send to access switch” .

In another example, the VEPA (serving as an Openflow switch) may send an unknown packet (e.g., the first data packet of a flow) to the VEPA controller (serving as an Openflow controller) according to the Openflow protocol. After receiving the data packet, the VEPA controller may return a flow table entry to the VEPA. The flow table entry may include a condition of “data packet from vPort” and an action of “send to access switch” . The VEPA may store the flow table entry, and forward the data packet and subsequent data packets according to the flow table entry.

In an example, after receiving a data packet from the access switch, the VEPA may search a VM forwarding table stored in the VEPA for a vPort corresponding to a destination address of the data packet, and forward the data packet to a destination VM through the vPort. The VM forwarding table may include: an IP address and a MAC address of the VM, and the vPort.

In an example, after detecting deletion of a VM in a VEPA controlled by the VEPA controller, the VEPA controller may search for an access switch corresponding to the VEPA according to connection relations between VEPAs and access switches, and inform the access switch to delete the network security policy corresponding to the VM. The VEPA controller may detect the VM deletion on the VEPA in a similar manner as in block S21, and is not repeated here.

In an example, when informing the access switch to delete the network security policy of the VM, the VEPA controller may add the address of the VM into a message for deleting the network security policy to be sent to the access switch. The access switch may receive the message, and delete a relation which associates the address of the VM with the network security policy.

In an example, in case of a failure occurs in a VEPA controller, plural VEPA controllers may be deployed. The VEPA controllers may share a virtual address. One of the VEPA controllers may be elected as a main VEPA controller according to a pre-defined election scheme, and the other VEPA controller (s) may serve as backup VEPA controller (s) . The main VEPA controller may implement the procedures shown in FIG. 2 using the shared virtual address. The main VEPA controller may provide the VM list of each VEPA controlled by the main VEPA controller and connection relations between VEPAs and access switches stored in the main VEPA controller for synchronize by the backup VEPA controller (s) . When the main VEPA controller fails, one of the backup VEPA controller (s) may be elected as a new main VEPA controller according to the pre-defined election scheme.

In an example, the VEPA controller may be extended into a cluster of VEPA controllers as shown in FIG. 5 in case of one VEPA controller may be over loaded. In this regard, plural VEPA controllers may be deployed in the network, and control over VEPAs and access switches are divided by the plural VEPA controllers. In an example, each VEPA may be configured with an address of a VEPA controller controlling the VEPA, and each VEPA controller may be configured with addresses of VEPAs and access switches controlled by the VEPA controller.

In the process shown in FIG. 2, each VEPA controller may only interact with those VEPAs and access switches whose addresses are configured in the VEPA controller. Each VEPA may interact only with a VEPA controller whose address is configured in the VEPA.

VEPA controllers within a cluster may also be backup for each other, and the mechanism is not elaborated here.

FIG. 6 is a schematic diagram illustrating modules of a VEPA controller in accordance with an example of the present disclosure. The VEPA controller may include: a network security policy searching module 61 and a network security policy sending module 62.

The network security policy searching module 61 is to detect a VM is newly established on a VEPA controlled by the VEPA controller, search for a network security policy corresponding to the VM using service information of the VM, and determine an access switch corresponding to the VEPA using connection relations between VEPAs and access switches obtained by the VEPA controller.

The network security policy sending module 62 is to send the network security policy found by the network security policy searching module 61 and the address of the VM to the access switch found, to enable the access switch to forward a data packet received from the VM according to the network security policy.

The VEPA controller may also include a network security policy deleting module (not shown) . The network security policy deleting module is to detect a VM is deleted from a VEPA controlled by the VEPA controller, determine an access switch corresponding to the VEPA according to the connection relations between the VEPAs and the access switches, and inform the access switch to delete a network security policy corresponding to the VM.

The VEPA controller may also include a connection relation obtaining module (not shown) . In an example, the connection relation obtaining module is to obtain the connection relations between the VEPAs and the access switches from a pre-configured file.

In an example, the connection relation obtaining module is to discover the connection relations between the VEPAs and the access switches controlled by the VEPA controller according to an LLDP protocol.

The VEPA controller may also include a first VM list maintaining module (not shown) . The first VM list maintaining module is to receive a first data packet sent by a VEPA controlled by the VEPA controller, search in a VM list of the VEPA stored in the VEPA controller for a source address of the first data packet. The first data packet is a data packet received by the VEPA from a VM originating the data packet and sent to the VEPA controller after the VEPA determines the first data packet is the first data packet of a flow when no flow table entry is found in a flow table stored in the VEPA. The first VM list maintaining module is to determine the VM originating the first data packet is a VM newly established on the VEPA if the source address of the first data packet is not found in the VM list, and add the VM into the VM list. The first VM list maintaining module is to judge whether the source address of the first data packet is in a VM list of a second VEPA. If the source address is found in the VM list of the second VEPA, the first VM list maintaining module is to determine the VM originating the first data packet has migrated to the VEPA that sent the first data packet, and delete the VM from the VM list of the second VEPA.

The VEPA controller may also include a second VM list maintaining module (not shown) . The second VM list maintaining module is to receive a VM establishment message sent by a VMM, identify a VM established by the VMM and a VEPA corresponding to the VM, and add the VM into a VM list of the VEPA. The second VM list maintaining module is to receive a VM deletion message sent by the VMM, identify a VM deleted by the VMM and a VEPA corresponding to the VM, and delete the VM from a VM list of the VEPA.

The VEPA controller may also include: a main/backup synchronization module (not shown) . The main/backup synchronization module is to provide a VM list of each VEPA controlled by the VEPA controller and connection relations between VEPAs controlled by the VEPA controller and access switches for synchronization by a backup VEPA controller when the VEPA controller serves as a main VEPA controller. When a failure occurs in the main VEPA controller, backup VEPA controller (s) elect a second main VEPA controller according to a pre-defined election scheme. The second main VEPA controller may perform interaction with the VEPAs and the access switches.

FIG. 7 is a schematic diagram illustrating modules of a VEPA controller in accordance with an example of the present disclosure. The VEPA controller may include a processor and a non-transitory storage medium such as a memory. The non-transitory storage medium, e.g. memory, stores machine-readable instructions executable by the processor to implement the above procedures of the VEPA controller.

The VEPA controller performs centralized control so that VEPAs do not have to perform VDP interactions with access switches. Thus, redundant components and message interaction procedures are reduced. Further, fast response to VM migrations is implemented, and security control capabilities are improved.

It should be understood that in the above processes and structures, not all of the procedures and modules are necessary. Certain procedures or modules may be omitted according to the needs. The order of the procedures is not fixed, and can be adjusted according to the needs. The modules are defined based on function simply for facilitating description. In implementation, a module may be implemented by multiple modules, and functions of multiple modules may be implemented by the same module. The modules may reside in the same device or distribute in different devices. The “first” , “second” in the above descriptions are merely for distinguishing two similar objects, and have no substantial meanings.

The hardware modules according to various examples may be implemented by hardware or a hardware platform with necessary software. The software may include machine-readable instructions which are stored in a non-statutory storage medium. Thus, the examples may be embodied as software products.

In various examples, the hardware may be dedicated hardware or general-purpose hardware executing machine-readable instruction. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) ) to perform certain operations. A module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations.

The machine-readable instructions corresponding to modules may cause an operating system running in a computer to implement part or all of the operations described herein. A non-transitory computer-readable storage medium may be a storage device in an extension board inserted in the computer or a storage in an extension unit connected to the computer or a memory etc. In this example, a CPU in the extension board or the extension unit executes at least part of the operations according to the instructions based on the program codes to realize the technical scheme of any of the above examples.

The non-transitory computer-readable storage medium for providing the program codes may include floppy disk, hard drive, magneto-optical disk, compact disk (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW) , magnetic tape drive, Flash card, ROM, RAM other memory and so on. In one example, the program code may be downloaded from a server computer via a communication network.

Claims

A method of controlling virtual edge port aggregator (VEPA) , comprising:

detecting, by a VEPA controller deployed in an edge virtual bridging (EVB) network, a virtual machine (VM) newly established in a VEPA controlled by the VEPA controller, and determining a network security policy corresponding to the VM according to service information of the VM；

determining, by the VEPA controller, an access switch corresponding to the VEPA according to connection relations between VEPAs and access switches controlled by the VEPA controller；

sending, by the VEPA controller, the network security policy and an address of the VM to the access switch determined to enable the access switch to forward data packets from the VM according to the network security policy.
The method of claim 1, further comprising:

determining, by the VEPA controller, a second access switch corresponding to a second VEPA controlled by the VEPA controller according to the connection relations after detecting a second VM is deleted from the second VEPA, and informing the second access switch to delete a network security policy corresponding to the second VM.
The method of claim 1, wherein the connection relations between the VEPAs and the access switches are obtained by the VEPA controller by:

obtaining, by the VEPA controller, the connection relations from a pre-configured file； or

discovering, by the VEPA controller, the connection relations between the VEPAs and the access switches according to a Link Layer Discovery Protocol (LLDP) protocol.
The method of claim 2, further comprising:

searching, by the VEPA controller after receiving a first data packet sent by a VEPA controlled by the VEPA controller, a VM list of the VEPA stored in the VEPA controller for a source address of the first data packet, wherein the first data packet is received by the VEPA from a VM originating the first data packet and forwarded to the VEPA controller after determining the first data packet is the first data packet of a flow when no flow table entry corresponding to the first data packet is found in a flow table in the VEPA；

determining, by the VEPA controller, the VM that originating first data packet is a newly established VM on the VEPA if the source address is not found in the VM list, and adding the VM into the VM list；

judging whether the source address of the first data packet is found in a VM list of another VEPA stored in the VEPA controller, determining the VM originating the first data packet has migrated to the VEPA that sent the first data packet if the source address of the first data packet is found in a VM list of another VEPA, and deleting the source address of the first data packet from the VM list of the another VEPA.
The method of claim 2, further comprising:

determining, by the VEPA controller, a VM established by a virtual machine manager (VMM) and a VEPA corresponding to the VM according to a VM establishment message sent by the VMM, and adding the VM into a VM list corresponding to the VEPA determined；

determining, by the VEPA controller, a VM deleted by the VMM and a VEPA corresponding to the VM according to a VM deletion message sent by the VMM, and deleting the VM from a VM list corresponding to the VEPA determined.
The method of claim 1, further comprising:

providing, by the VEPA controller which serves as a main VEPA controller, a VM list corresponding to each VEPA stored in the VEPA controller and connection relations between VEPAs and access switches obtained by the VEPA controller for synchronization by at least one backup VEPA controller so that when the VEPA controller is failed, a new main VEPA controller elected from the at least one backup VEPA controller according to a pre-defined election scheme performs interactions with the VEPAs and the access switches.
A virtual edge port aggregator (VEPA) controller, comprising a processor and a non-transitory storage medium storing machine readable instructions executable by the processor to:

detect a virtual machine (VM) is newly established on a VEPA controlled by the VEPA controller, search for a network security policy corresponding to the VM using service information of the VM, and determine an access switch corresponding to the VEPA using connection relations between VEPAs and access switches obtained by the VEPA controller； and

send the network security policy and an address of the VM to the access switch determined to enable the access switch to forward data packets from the VM according to the network security policy.
The VEPA controller of claim 7, wherein the machine readable instructions are executable by the processor to:

determine a second access switch corresponding to a second VEPA controlled by the VEPA controller according to the connection relations after detecting a second VM is deleted from the second VEPA, and informing the second access switch to delete a second network security policy corresponding to the second VM.
The VEPA controller of claim 7, wherein the machine readable instructions are executable by the processor to:

obtain the connection relations from a pre-configured file； or

discover the connection relations between the VEPAs and the access switches controlled by the VEPA controller according to a Link Layer Discovery Protocol (LLDP) protocol.
The VEPA controller of claim 8, wherein the machine readable instructions are executable by the processor to:

search, after receiving a first data packet sent by a VEPA controlled by the VEPA controller, a VM list of the VEPA stored in the VEPA controller for a source address of the first data packet, wherein the first data packet is received by the VEPA from a VM originating the first data packet and forwarded to the VEPA controller after determining the first data packet is the first data packet of a flow when no flow table entry corresponding to the first data packet is found in a flow table in the VEPA；

determine the VM that originating the first data packet is a VM newly established on the VEPA if the source address is not found in the VM list, and add the VM into the VM list；

judge whether the source address of the first data packet is found in a VM list of another VEPA stored in the VEPA controller, determine the VM originating the first data packet has migrated to the VEPA that sent the first data packet if the source address of the first data packet is found in a VM list of another VEPA, and delete the source address of the first data packet from the VM list of the another VEPA.
The VEPA controller of claim 8, wherein the machine readable instructions are executable by the processor to:

determine a VM established by a virtual machine manager (VMM) and a VEPA corresponding to the VM according to a VM establishment message sent by the VMM, and add the VM into a VM list corresponding to the VEPA determined；

determine a VM deleted by the VMM and a VEPA corresponding to the VM according to a VM deletion message sent by the VMM, and delete the VM from a VM list corresponding to the VEPA determined.
The VEPA controller of claim 7, wherein the machine readable instructions are executable by the processor to:

provide, when the VEPA controller serves as a main VEPA controller, a VM list corresponding to each VEPA stored in the VEPA controller and connection relations between VEPAs and access switches obtained by the VEPA controller for synchronization by at least one backup VEPA controller so that when the VEPA controller is failed, a new main VEPA controller elected from the at least one backup VEPA controller according to a pre-defined election scheme performs interactions with the VEPAs and the access switches.