CN108965000B

CN108965000B - Private cloud SDN drainage implementation method

Info

Publication number: CN108965000B
Application number: CN201810762149.1A
Authority: CN
Inventors: 刘佳; 范渊; 吴永越; 郑学新; 刘韬
Original assignee: Chengdu DBAPPSecurity Co Ltd
Current assignee: Chengdu DBAPPSecurity Co Ltd
Priority date: 2018-07-12
Filing date: 2018-07-12
Publication date: 2021-06-01
Anticipated expiration: 2038-07-12
Also published as: CN108965000A

Abstract

The invention discloses a private cloud SDN drainage implementation method, which is implemented based on a private cloud system of an SDN controller, a Bridge and physical hosts which are sequentially connected, wherein the number of the physical hosts is multiple, each physical host comprises an OVS and multiple VNFs connected with the OVS, and each OVS is respectively connected with the Bridge; the method comprises the steps of firstly starting an SDN controller and an OVS (virtual network system) and constructing a VNF (virtual network function), discovering and initializing topology in an SDN controller service program, sensing the network interface state and the MAC (media access control) address of the VNF, calculating and issuing an access rule and a drainage rule by matching with a routing address configured at a user side, and realizing the receiving and sending of user data messages and automatic drainage of private cloud processing. The invention completes the work needing coordination between VNF instances in the private cloud network, and forms a flexible service chain according to the user requirements, thereby realizing that the user flow automatically passes through a plurality of NFV nodes according to the user-defined rule.

Description

Private cloud SDN drainage implementation method

Technical Field

The invention relates to the technical field of network communication, in particular to a private cloud SDN drainage implementation method.

Background

The traditional network forwarding model mainly comprises two-layer forwarding completed by a switch and three-layer forwarding completed by a router. The advantage of two-layer forwarding is that the forwarding rule is simple, and the two-layer header address MAC does not change due to the change of the host position, so the self-learning-based switch basically does not need to be configured, and the management is very convenient. The switch is easy to implement in a hardware chip, thereby achieving very high forwarding performance. However, the two-layer forwarding model also has obvious disadvantages, for example, MAC addresses cannot be aggregated, so that the extensibility is very weak when hosts are increased, complicated user policies cannot be configured, and a large number of broadcast messages in the two-layer network also cause difficulty in forming a large-scale network.

And the three-layer forwarding model forwards the message according to the IP address in the message. The IP addresses can be aggregated, so that a large-scale network is formed, and the problem of expansibility of a two-layer switching network is solved. However, the configuration of three-layer forwarding is complex, and the IP address usually identifies the location of the host in the network topology, which makes it difficult to implement automatic reconfiguration when the host location is migrated.

In a private cloud network, most of network solutions provided by manufacturers at present are still based on a traditional two-layer or three-layer network model, so that network management configuration of users is complex and flexible user requirements are difficult to realize. SDN is a new network model that appears recently, and is currently mainly applied to large data centers to complete some network automation works. The method is a new application of an SDN networking model in a private cloud network, specially solves the drainage problem in the private cloud network, and enables the configuration of a user to be relatively simple and highly automated on the premise of ensuring the flexibility of a drainage strategy. The principle is to match the data flow by user-defined rules, modify the packet MAC address and forward to the corresponding interface.

In the prior art, policy routing drainage is adopted, one or more routing routers are introduced into a network, and forwarding is performed according to forwarding bases such as 'source IP, port' and the like of data messages, rather than forwarding based on destination IP addresses of traditional routes, but a large number of policy routing rules need to be manually configured on the routers.

In addition, the OpenDayLight SFC function is provided, OpenDayLight is a project of a power controller, an application scenario of the SFC drainage function provided by the OpenDayLight is a large-scale data center, a scheme is complex, performance loss is large when a network scale is small, and the OpenDayLight is not suitable for a miniaturized private cloud scenario.

Disclosure of Invention

The invention aims to provide a private cloud SDN drainage implementation method, which comprises the steps of starting an SDN controller and an OVS, constructing a VNF, discovering and initializing topology in a service program of the SDN controller, sensing a network interface state and an MAC address of the VNF, and realizing private cloud processing of user data receiving and sending and automatic drainage data by matching with routing address calculation and issuing access rules and drainage rules configured on a user side.

The invention is realized by the following technical scheme: a private cloud SDN drainage implementation method is implemented based on a private cloud system of an SDN controller, a Bridge and physical hosts which are sequentially connected, wherein the number of the physical hosts is multiple, each physical host comprises an OVS and multiple VNFs connected with the OVS, and each OVS is respectively connected with the Bridge, and the method specifically comprises the following steps:

step F1: starting an SDN controller and an OVS connected with Bridge;

step F2: constructing and starting a VNF;

step F3: topology discovery and initialization are carried out in an SDN controller service program, and the state of a network interface and an MAC address of a VNF are sensed;

step F4: configuring a user side route;

step F5: calculating and issuing an access rule;

step F6: calculating and issuing a drainage rule;

step F7: and the private cloud finishes receiving and sending the user data message.

Further, in order to better implement the present invention, the step F1 specifically includes the following steps:

step F11: start Bridge and each OVS;

step F12: and starting the SDN controller to realize that the OVS of the SDN controller and each physical host is interconnected through Bridge.

Further, in order to better implement the present invention, the step F2 specifically includes the following steps:

step F21: initiating a plurality of VNFs connected to the OVS;

step F22: and setting the network card MAC address of the VNF according to the uniform planning of the private cloud system.

Further, in order to better implement the present invention, the step F3 specifically includes the following steps:

step F31: according to the strong correlation between the MAC address of the OVS interface and the MAC address of the VNF interface, the SDN controller scans each OVS interface and selects an Uplink interface;

step F32: the SDN controller checks and records the MAC address on the Uplink interface;

step F33: calculating the MAC address of each VNF interface connected with the OVS by the SDN controller, thereby forming a network topology map for carrying out drainage rule calculation; the network topological graph is a tree structure with root nodes, the Bridge is taken as a main trunk in the tree structure, the OVS is the branch and leaf nodes of the Bridge, and the VNF is the branch and leaf nodes of the OVS.

Further, in order to better implement the present invention, the step F4 specifically includes the following steps:

step F41: the SDN controller senses the MAC address and the IP address of a Router interface connected with the Bridge;

step F42: and the user performs routing configuration to help the private cloud network calculate the access rule.

Further, in order to better implement the present invention, the step F5 specifically includes the following steps:

step F51: the SDN controller issues a flow table rule A to all OVSs according to an Openflow protocol, wherein the content of the flow table rule A is to transmit a received neighbor learning request message to the SDN controller;

step F52: after receiving a neighbor learning request message sent by a Router or a VNF, the OVS sends the neighbor learning request message to the SDN controller;

step F53: after receiving the neighbor learning request message, the SDN controller constructs a neighbor learning response message by combining the MAC address of the OVS receiving the neighbor learning request message; the MAC address encapsulated in the neighbor learning response message is the MAC address of the OVS receiving the neighbor learning request message; if a plurality of OVSs receive the same neighbor learning request message, the SDN controller selects the MAC address of one OVS according to a load balancing principle to package a neighbor learning response message;

step F54: according to the Openflow protocol, the SDN controller issues a flow table rule B to the OVS that receives the neighbor learning request message in step F52, where the content of the flow table rule B is to forward a neighbor learning response message issued by the SDN controller to the OVS that receives the neighbor learning request message;

step F55: the SDN controller sends the neighbor learning response message constructed in step F53 to the OVS that received the neighbor learning request message in step F52 according to the Openflow protocol;

step F56: the OVS forwards a neighbor learning response message issued by the SDN controller to a Router or a VNF initiating the request;

step F57: the Router or VNF that receives the neighbor learning response packet constructed by the SDN controller learns the MAC address of the OVS interface that receives the neighbor learning request packet in step F53.

Further, in order to better implement the present invention, the step F6 specifically includes the following steps:

step F61: when the flow guiding rule is calculated, the SDN controller inputs a flow guiding rule D configured by a user and the network topological graph maintained in the step F3, and a user data message enters a private cloud through a Router;

step F62: the SDN controller analyzes a user configured flow guiding rule D to obtain a field to be matched and an equipment path through which a user data message passes;

step F63: the SDN controller calculates a flow table rule C for each OVS on a path, and each OVS generates a flow table rule correspondingly once in an equipment path; the flow table rule comprises message matching content, MAC addresses of a next device interface on a path and an MAC address rewriting rule; the reason for rewriting the MAC address is that the OVS is to adapt to the packet receiving and transmitting principles of VNF and Bridge connected with the OVS;

step F64: the SDN controller issues the flow table rule to a corresponding OVS on the path according to an Openflow protocol, and guides forwarding and rewriting of the user data message;

step F65: at this time, the Router has learned the MAC address of the OVS that received the neighbor learning request message in step F52, and forwards the user data message to the OVS;

step F66: the OVS that receives the user data packet sent by the Router performs matching, rewriting and forwarding of the user data packet according to the flow table rule correspondingly issued in step F64;

step F67: when a user changes a drainage strategy, the SDN controller automatically recalculates and issues all drainage rules; when a certain VNF node is migrated, the network topology graph is dynamically changed, and the SDN controller automatically recalculates and issues all the drainage rules.

Further, in order to better implement the present invention, the step F7 specifically includes the following steps: and after completing the matching, rewriting and forwarding of the user data message, the private cloud returns the user data message to the Router.

The working principle is as follows:

the method comprises the following steps that 1, Bridge is connected with a plurality of physical hosts, each physical host is correspondingly provided with one OVS, each OVS is respectively connected with the Bridge, and the Bridge and each OVS are started; and the SDN controller is connected with the Bridge, starts the SDN controller, and realizes interconnection of the OVS of the SDN controller and each physical host through the Bridge.

2. Each OVS is connected with a plurality of VNFs, and the VNFs are started; and setting the network card MAC address of the VNF according to the uniform planning of the private cloud system.

3. The OVS and the VNF are provided with a plurality of interfaces, and according to the strong correlation between the MAC address of the OVS interface and the MAC address of the VNF interface, the SDN controller scans each OVS interface and selects an Uplink interface; the SDN controller checks and records the MAC address on the Uplink interface; and calculating the MAC address of each VNF interface connected with the OVS by the SDN controller, thereby forming a network topology map for carrying out drainage rule calculation.

Sensing the MAC address and the IP address of a Router interface connected with the Bridge by the SDN controller; and the user performs routing configuration to help the private cloud network calculate the access rule.

And 5, the SDN controller issues flow table rules A to all OVSs, after receiving neighbor learning request messages sent by a Router or a VNF, the OVS sends the neighbor learning request messages to the SDN controller, the SDN controller constructs neighbor learning response messages and returns the neighbor learning response messages to the OVS and the Router, and the Router learns the MAC address of the OVS.

And 6, the SDN controller obtains fields to be matched and a device path through which the user data message passes according to a flow table rule D input by a user and a network topological graph, the SDN controller calculates a corresponding flow table rule for each OVS on the path and issues the flow table rule to the corresponding OVS, and the OVS performs matching, rewriting and forwarding on the user data message according to the issued flow table rule.

7. And finally, returning the user data message to the Router.

Compared with the prior art, the invention has the following advantages and beneficial effects:

VNF instances in the private cloud network need to be coordinated, according to user requirements, the method and the system form a flexible service chain, and user traffic automatically passes through a plurality of NFV nodes according to custom rules.

Drawings

FIG. 1 is a flow chart of the present invention;

fig. 2 is a data flow topology diagram.

Detailed Description

The present invention will be described in further detail with reference to examples, but the embodiments of the present invention are not limited thereto.

Example 1:

in this embodiment, a further optimization is performed on the basis of the above embodiments, as shown in fig. 1 to fig. 2, a private cloud SDN drainage implementation method is implemented based on a private cloud system of an SDN controller, a Bridge, and physical hosts that are sequentially connected, where the number of the physical hosts is multiple, each physical host includes an OVS and multiple VNFs connected to the OVS, and each OVS is respectively connected to the Bridge, and specifically includes the following steps:

step F1: starting an SDN controller and an OVS connected with Bridge;

step F2: constructing and starting a VNF;

step F4: configuring a user side route;

step F5: calculating and issuing an access rule;

step F6: calculating and issuing a drainage rule;

It should be noted that, through the above improvement, the SDN is a software-defined network model, the SDN Controller is a Controller in fig. 2, and is a centralized Controller in the SDN network, the Controller may be an SDN Controller such as OpenDayLight, Ryu, and the like, and the OpenDayLight is an opening Controller item, and the logic code of the present solution runs on a Controller framework. The OVS is OpenvSwitch, and is a mainstream software switch supporting an SDN network. The Controller is connected with the Bridge, and the OVS is provided with a plurality of OVSs which are respectively connected with the Bridge. Each of the OVSs has a plurality of VNFs connected thereto.

The method comprises the steps that firstly, all components are started, wherein the components comprise a Bridge, an SDN controller, an OVS and a VNF, the SDN controller initializes and discovers a network topology map according to the connection relation of the Bridge, the OVS and the VNF, and the SDN controller senses the MAC address and the IP address of a Router interface connected with the Bridge. The key point of the invention is that the SDN controller calculates and issues the access rule and the drainage rule, and after the private cloud finishes the matching, rewriting and forwarding of the user data message, the private cloud returns the user data message to the user side to finish the receiving and sending of the user data message.

Other parts of this embodiment are the same as those of the above embodiment, and thus are not described again.

Example 2:

in this embodiment, further optimization is performed on the basis of the above embodiment, as shown in fig. 1 to fig. 2, the step F1 specifically includes the following steps:

step F11: start Bridge and each OVS;

It should be noted that, through the above improvement, the physical host is a chassis in fig. 2, there are multiple chassis, and all OVSs deployed on the chassis are connected to Bridge. The OVS in each chasis is connected with a plurality of VNFs, the VNFs are virtual network function instances, the VNFs are diversified in function, and the VNFs can be computing nodes, Web servers and virtual firewalls.

Step F1 starts the main components needed, where the SDN Controller is the Controller in fig. 2, and may be OpenDayLight, Ryu, or the like.

Each physical host is correspondingly provided with one OVS, wherein the OVS is an abbreviation of OpenvSwitch, and OpenVSwitch is an SDN virtual switch realized by software and mainly realizes forwarding of flow table rules defined by Openflow, namely, user data message exchange is carried out by connecting with Bridge. The OVS and the Controller communicate through a southbound interface to realize network communication of a control plane.

Example 3:

in this embodiment, further optimization is performed on the basis of the above embodiment, as shown in fig. 1 to fig. 2, the step F2 specifically includes the following steps:

step F21: each OVS is connected with a plurality of VNFs, and the VNFs are started;

It should be noted that, through the above improvement, VNF refers to a specific virtual network function, provides a certain network service, is software, and is deployed in a virtual machine, a container, or a barrel-metal physical machine by using the infrastructure provided by NFVI. NFVI is a common virtualization layer in private clouds.

The main work of step F2 is to start a VNF virtual network function instance required by a user on a private cloud system, where the VNF function is very diverse, and may be a computing node, a Web server, a virtual firewall, a virtual Web firewall, or the like. When configuring the network card MAC address of the VNF, the network card MAC address needs to be planned uniformly according to the private cloud system and cannot be configured randomly.

Example 4:

in this embodiment, further optimization is performed on the basis of the above embodiment, as shown in fig. 1 to fig. 2, the step F3 specifically includes the following steps:

It should be noted that, through the above improvement, the steps of this embodiment are mainly performed in the SDN controller, and the SDN controller senses the network interface state and the MAC address of the VNF, generates and maintains a network topology diagram, and is used for performing calculation of the drainage rule.

According to the strong correlation between the MAC address of the OVS interface and the MAC address of the VNF interface, the SDN controller scans each OVS interface and selects an Uplink interface, and the SDN controller plays a role in checking and recording the MAC address on the Uplink interface.

And calculating the MAC address of the Linkup interface of each VNF according to the strong correlation of the MAC addresses of the components, thereby forming a complete network topology map for calculating the drainage rule. The network topological graph is a tree structure with root nodes, the Bridge is taken as a main trunk in the tree structure, the OVS is the branch and leaf nodes of the Bridge, and the VNF is the branch and leaf nodes of the OVS.

After the topological graph is formed, the topological state is dynamically maintained through the LLDP protocol, and when the VNF is powered on or off or migrated, the topology can be dynamically updated without manual intervention. The LLDP protocol is a link layer protocol, the kinds of network devices are increasingly diverse, and the respective configurations are complicated, and a standard information exchange platform is required in order to enable devices of different manufacturers to discover and interact respective system and configuration information in a network.

Example 5:

in this embodiment, further optimization is performed on the basis of the above embodiment, as shown in fig. 1 to fig. 2, the step F4 specifically includes the following steps:

It should be noted that, through the above improvement, Bridge is connected to Router, Bridge is a switch supporting traditional two-layer forwarding, and Router is a Router supporting traditional network three-layer forwarding. As shown in fig. 2, the private cloud includes Bridge, chasis and an SDN controller, and the Bridge is connected with the office network and the Router to form a drainage system of the SDN network of the private cloud.

The Router configured on the User side is a Router, the Router is closely related to access rule calculation in the private cloud network, the Router on the User side generally sends data to the private cloud network based on policy routing, the configuration affecting the drainage scheme is mainly an interface address of the Router, the interface address includes a MAC address and an IP address, the SDN controller needs to sense the Router interface address connected to the Bridge, as shown in fig. 2, the IP address of the User is 192.168.33.1, the IP address of the Server is 192.168.34.1, User data messages of the User and the Server are sent to the Bridge through the policy routing on the Router, and after the private cloud is processed, the User data messages are sent back to the Router.

Example 6:

in this embodiment, further optimization is performed on the basis of the above embodiment, as shown in fig. 1 to fig. 2, the step F5 specifically includes the following steps:

It should be noted that, through the above improvement, the flow table rule a and the flow table rule B are drainage rules issued by the SDN controller to the OVS, and are calculated by the SDN controller program. The drainage rules are briefly explained below:

the SDN model applies the idea of separating a network control plane from a forwarding plane, a controller is a control main body, and an OVS is a forwarding main body. The controller controls all OVSs in a centralized mode through an Openflow protocol, the OVSs are distributed on a plurality of physical hosts, and when data messages reach the OVSs, the OVSs can process and forward the data according to a flow table issued by the controller. All drainage rules herein refer to controller generated flow table rules. The flow table rule is issued to a plurality of OVSs, so that the flow table rule can really play a role of guiding data forwarding. The Controller is usually a framework that provides the basic components for implementing the application logic, but the application logic itself is programmed by the Controller user. The access rule and the flow rule calculation are user logic and need to be programmed and completed on the frame provided by the Controller.

The step implementation method of this embodiment is that, on the SDN controller and the OVS, the request and the response of the neighbor learning packet are between the OVS and the Router/VNF. The ARP proxy is implemented by flow table rules and if it is an IPv6 network, the ND protocol proxy is implemented. The ARP protocol, namely the address resolution protocol, is a TCP/IP protocol for acquiring a physical address according to an IP address; the ND protocol is IPv6 neighbor discovery, a set of messages and procedures that determine the relationships between neighbor nodes. The method has the advantages that the neighbor protocol message request sent by the Router or the VNF to the OVS is sent to the SDN controller, the SDN controller replies the MAC address of the corresponding interface of the OVS, the butt joint of the private cloud network and the traditional network model example is achieved, data can be sent to the OVS for SDN rule processing, and the calculation and the issuing of the access rule in the private cloud network are achieved. The specific process is as follows:

and the SDN controller issues a flow table rule A to all the OVSs according to an Openflow protocol, wherein the content of the flow table rule A is to transmit the received neighbor learning request message to the SDN controller. After receiving the neighbor learning request message sent by the Router or the VNF, the OVS sends the neighbor learning request message to the SDN controller according to the flow table rule a. And after receiving the neighbor learning request message, the SDN controller constructs a neighbor learning response message by combining the MAC address of the OVS receiving the neighbor learning request message.

And if a plurality of OVSs receive the same neighbor learning request message, the SDN controller selects the MAC address of one OVS according to a load balancing principle to package the neighbor learning response message.

According to the Openflow protocol, the SDN controller issues a flow table rule B to the OVS which receives the neighbor learning request message, and the content of the flow table rule B is to forward a neighbor learning response message issued by the SDN controller to the OVS which receives the neighbor learning request message. And the SDN controller sends the constructed neighbor learning response message to the OVS receiving the neighbor learning request message according to an Openflow protocol.

And the OVS forwards the neighbor learning response message issued by the SDN controller to the Router or the VNF initiating the request. The Router or the VNF receiving the neighbor learning response message constructed by the SDN controller learns the MAC address of the OVS interface receiving the neighbor learning request message.

Example 7:

in this embodiment, further optimization is performed on the basis of the above embodiment, as shown in fig. 1 to fig. 2, the step F6 specifically includes the following steps:

step F67: when a user changes a drainage strategy, the SDN controller automatically recalculates and issues all drainage rules; when a certain VNF node is migrated, the network topology graph is dynamically changed, and the SDN controller automatically recalculates and issues all the drainage rules;

the step F7 specifically includes the following steps: and after completing the matching, rewriting and forwarding of the user data message, the private cloud returns the user data message to the Router.

It is noted that, with the above-mentioned improvements,

when calculating the drainage rules, there are two inputs: the first is the network topology maintained in step F3, and the second is the user configured drainage rule D; the network topological graph is a tree structure with root nodes, the Bridge is taken as a main trunk in the tree structure, the OVS is the branch and leaf nodes of the Bridge, and the VNF is the branch and leaf nodes of the OVS. The format of the user-configured drainage rule D is: { match certain message fields, and pass messages that meet the matching rules to certain VNFs for processing }, for example: { messages whose matching destination address is 192.168.34.1, and messages that meet the matching rules are sequentially delivered to VNF2, VNF1, VNF4, and VNF3 for processing }. The calculation of the drainage rules is to convert the drainage rules configured by the user into a plurality of flow table rules on the OVS. The SDN controller analyzes the drainage rule D configured by the user to obtain a field to be matched and a device path to be passed through, for example, as shown in fig. 2, a corresponding analysis result is: matching destination IP address 192.168.34.1, the device paths to be traversed are, in order:

OVS2- > OVS1- > VNF2- > OVS1- > VNF1- > OVS1- > OVS2- > VNF4- > OVS2- > VNF3- > OVS2, and the equipment path comprises VNF and OVS and is obtained according to a network topology map.

The device path is obtained through the analysis, a flow table rule is calculated for each OVS on the path, one flow table rule is correspondingly generated when each OVS appears once in the device path, and a certain OVS may appear in the path for multiple times, so that the flow table rule of each OVS calculated by the SDN controller may be multiple.

If there are multiple user configured drainage rules D, the SDN controller receives multiple different drainage rules, thereby generating multiple different device paths, which also results in multiple flow table rules per OVS calculated by the SDN controller.

The flow table rule contains 3 parts: firstly, the message matches the content, such as the matching destination IP address, and can match the combination of any content in the IP quintuple information and add a user data message input interface; second, MAC address of the next device interface on the path; thirdly, the MAC address is rewritten by the rules, the reason for rewriting the MAC address is that the OVS is to adapt to the packet receiving and sending principle of VNF and Bridge; for example, the device path is:

OVS2- > OVS1- > VNF2- > OVS1- > VNF1- > OVS1- > OVS2- > VNF4- > OVS2- > VNF3- > OVS2, and the content of a certain flow table rule on the OVS2 is as follows: { match the packet sent from the interface connected to VNF4, the destination IP is 192.168.34.1, after matching successfully, the packet is forwarded to the interface connected to VNF3, and the destination MAC address of the forwarded packet is rewritten to the MAC address of VNF3 }.

And the SDN controller issues the generated flow table rule to a corresponding OVS on the equipment path according to an Openflow protocol so as to guide the forwarding and rewriting of the user data message. Router has learned the MAC address of the OVS that received the neighbor learning request message, and can therefore forward the user data message to this OVS. After receiving the user data message sent by the Router, the OVS performs message matching, rewriting and forwarding according to the issued flow table rule. When the user changes the strategy of the drainage rule D, the SDN controller automatically recalculates and issues all the drainage rules; when a certain VNF node is migrated, the network topology changes dynamically, and the SDN controller automatically recalculates and issues all the drainage rules.

And after completing the matching, rewriting and forwarding of the user data message, the private cloud returns the user data message to the Router, thereby realizing the method for automatically processing the user data message by the private cloud.

The above description is only a preferred embodiment of the present invention, and is not intended to limit the present invention in any way, and all simple modifications and equivalent variations of the above embodiments according to the technical spirit of the present invention are included in the scope of the present invention.

Claims

1. A private cloud SDN drainage implementation method is realized based on a private cloud system of an SDN controller, a Bridge and physical hosts which are sequentially connected, wherein the number of the physical hosts is multiple, each physical host comprises an OVS and multiple VNFs connected with the OVS, each OVS is respectively connected with the Bridge, and the private cloud system is characterized in that: the method specifically comprises the following steps:

step F1: starting an SDN controller and an OVS connected with Bridge; the OVS is OpenvSwitch;

step F2: constructing and starting a VNF;

step F4: configuring a user side route;

step F5: calculating and issuing an access rule;

step F6: calculating and issuing a drainage rule;

step F7: the private cloud finishes receiving and sending user data messages;

the step F1 specifically includes the following steps:

step F11: start Bridge and each OVS;

step F12: starting the SDN controller to realize that the OVS of the SDN controller and each physical host is interconnected through Bridge;

the step F2 specifically includes the following steps:

step F21: initiating a plurality of VNFs connected to the OVS;

step F22: setting a network card MAC address of the VNF according to the unified planning of the private cloud system;

the step F3 specifically includes the following steps:

step F33: calculating the MAC address of each VNF interface connected with the OVS by the SDN controller, thereby forming a network topology map for carrying out drainage rule calculation; the network topological graph is a tree structure with root nodes, the Bridge is taken as a main trunk in the tree structure, the OVS is the branch and leaf nodes of the Bridge, and the VNF is the branch and leaf nodes of the OVS;

the step F4 specifically includes the following steps:

step F42: the user performs routing configuration to help the private cloud network to calculate the access rule;

the step F5 specifically includes the following steps:

step F57: the Router or VNF that receives the neighbor learning response packet constructed by the SDN controller learns the MAC address of the OVS interface that receives the neighbor learning request packet in step F53;

the step F6 specifically includes the following steps:

2. The private cloud SDN drainage implementation method according to claim 1, wherein: the step F7 specifically includes the following steps: and after completing the matching, rewriting and forwarding of the user data message, the private cloud returns the user data message to the Router.