CN111786843A

CN111786843A - Traffic collection method, traffic collection device, network equipment and storage medium

Info

Publication number: CN111786843A
Application number: CN201910272723.XA
Authority: CN
Inventors: 毕以峰
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2019-04-04
Filing date: 2019-04-04
Publication date: 2020-10-16
Anticipated expiration: 2039-04-04
Also published as: CN111786843B; WO2020199780A1

Abstract

The embodiment of the invention provides a traffic collection method, a traffic collection device, network equipment and a storage medium, wherein target traffic collection aiming at the incoming direction of an original collection object is converted into target traffic collection aiming at the outgoing direction of a target collection object, and in order to collect the target traffic of the outgoing direction of the target collection object, only the forwarding equipment connected with the target collection object needs to collect the incoming traffic of the target traffic. So, carry out the in-process of going into to target flow collection to a certain collection object, need not to correspond the switch and all gather the flow of its all ports, reduced the processing burden of switch, promoted the efficiency that flow was gathered. Meanwhile, when the incoming target flow is collected aiming at a certain collection object, the flow direction of the flow to be collected of the forwarding equipment is appointed, so that even if the target flow is forwarded on the forwarding equipment for multiple times, the repeated collection of the forwarding equipment cannot be caused, and the multiple collection and the mistaken collection of the flow are avoided.

Description

Traffic collection method, traffic collection device, network equipment and storage medium

Technical Field

The present invention relates to the field of communications, and in particular, to a method and an apparatus for collecting traffic, a network device, and a storage medium.

Background

Because operators have a need to collect and monitor traffic, there is a need to collect traffic as needed in the network. However, in the related traffic collection scheme, there is a problem that: when the traffic to be collected is incoming traffic with respect to a VNF (Network Function Virtualization), the traffic is outgoing traffic with respect to a switch attached to the VNF. Therefore, theoretically, only the switch needs to collect the outgoing traffic on the port corresponding to the VNF interface on the switch. However, limited by the capability of the switch chip, the switch cannot bind the flow characteristic collection policy of the outgoing flow to a specific port, so when the switch collects the outgoing flow of a certain port, the flow collection action will take effect globally, that is, the flow collected by any port on the switch is collected and then filtered according to the flow characteristic collection policy. This necessarily results in an increase in the processing load on the switch, while reducing the efficiency with which the switch performs traffic collection.

Disclosure of Invention

The embodiment of the invention provides a traffic collection method, a traffic collection device, network equipment and a storage medium, and mainly solves the technical problems that: in the related traffic collection scheme, when incoming traffic is collected at a certain interface of a certain network element, the switch responsible for traffic collection has the problems of large processing burden and low efficiency.

In order to solve the above technical problem, an embodiment of the present invention provides a traffic collection method, including:

determining a target acquisition object corresponding to an original acquisition object according to the network topological relation, wherein the original acquisition object is an object for which the in-direction target flow needs to be acquired, the flow direction of the target flow is in the out direction relative to the target acquisition object, and the target acquisition object is an object supporting the acquisition of the out-direction target flow;

and acquiring the incoming target flow of the forwarding equipment connected with the target acquisition object.

An embodiment of the present invention further provides a flow collecting device, including:

the object determining unit is used for determining a target acquisition object corresponding to an original acquisition object according to the network topological relation, wherein the original acquisition object is an object for which the inflow target flow is required to be acquired, the flow direction of the target flow is the outflow direction relative to the target acquisition object, and the target acquisition object is an object supporting the target flow of the acquisition outflow direction;

and the acquisition control unit is used for acquiring the incoming target flow of the forwarding equipment connected with the target acquisition object.

The embodiment of the invention also provides network equipment, which comprises a processor, a memory and a communication bus;

the communication bus is used for realizing connection communication between the processor and the memory;

the processor is used for executing one or more programs stored in the memory to realize the steps of the flow collection method.

Embodiments of the present invention further provide a storage medium, where one or more programs are stored, and the one or more programs may be executed by one or more processors to implement the steps of the traffic collection method described above.

The invention has the beneficial effects that:

according to the traffic collection method, the traffic collection device, the network equipment and the storage medium provided by the embodiment of the invention, when the target traffic collection required to be performed on a certain collection object is determined, the collection object can be used as an original collection object, and a target collection object corresponding to the original collection object is determined according to the network topological relation. The target collection object and the original collection object are both transmitted with the same target flow, in other words, the upward flow of the target collection object and the upward flow of the original collection object are the same flow. Therefore, the target flow collection aiming at the incoming direction of the original collection object can be converted into the target flow collection aiming at the outgoing direction of the target collection object, the target flow collection aiming at the outgoing direction of the target collection object is collected, and the target flow collection aiming at the incoming direction of the original collection object is completed. In order to collect the outgoing target traffic of the target collection object, only the forwarding device connected with the target collection object needs to collect the incoming traffic of the target traffic. So, carry out the in-process of going into to target flow collection to a certain collection object, need not to correspond the switch and all gather the flow of its all ports, reduced the processing burden of switch, promoted the efficiency that flow was gathered.

Meanwhile, in the traffic collection scheme provided by this embodiment, when incoming target traffic collection is performed on a certain collection object, the flow direction of traffic to be collected by the forwarding device is specified, so that even if the target traffic is forwarded on the forwarding device for multiple times, multiple collection of the forwarding device is not caused, and multiple collection and erroneous collection of traffic are avoided.

Additional features and corresponding advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.

Drawings

Fig. 1 is a schematic diagram illustrating a logical relationship between a controller and a switch in an SDN network according to an embodiment of the present invention;

FIG. 2 is a flow chart illustrating flow acquisition in the related art;

fig. 3 is a flowchart of a traffic collection method according to an embodiment of the present invention;

fig. 4 is a schematic flow diagram of traffic flows between VNFs in an SDN network according to an embodiment of the present invention;

fig. 5 is a flowchart illustrating that the NFVO collects outbound target traffic for a target collection object according to a first embodiment of the present invention;

fig. 6 is a flowchart of a traffic collection method according to a second embodiment of the present invention;

fig. 7 is a flowchart of a flow collection process according to a second embodiment of the present invention;

fig. 8 is a schematic flow diagram of target traffic between VNF1 and VNF2 shown in example 2 of the third embodiment of the present invention;

fig. 9 is a flowchart of a flow interaction process in a third example 2 of the present invention;

fig. 10 is a schematic flow diagram of traffic flows among network elements in an SDN network shown in third example 3 of the present invention;

fig. 11 is a schematic flow diagram of target traffic between ER and VNF1 shown in example 3 of the third embodiment of the present invention;

fig. 12 is a flowchart of an interaction of a flow collection process provided in the third example 3 of the present invention;

fig. 13 is a flowchart illustrating a flow interaction of migration of a traffic collection policy along with a VM, according to a fourth example 4 of the present invention;

fig. 14 is a flowchart illustrating a flow interaction of a flow collection process in a VM pop-up scene according to a fourth example 5 of the present invention;

fig. 15 is a flowchart illustrating a flow interaction of traffic collection management in a VNF capacity reduction scenario according to a fourth example 6 of the present invention;

fig. 16 is a flowchart illustrating a flow collection process in a scenario where a VM deploying a VNF is a cluster according to a fourth example 7 of the present invention;

fig. 17 is a schematic structural diagram of a flow rate acquisition device according to a fifth embodiment of the present invention;

fig. 18 is a schematic diagram of a hardware structure of a network device according to a sixth embodiment of the present invention.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention are described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

The first embodiment is as follows:

NFVI (Network Function virtualization Infrastructure) is a set of resources used to host and connect virtual functions. Specifically, NFVI is a cloud data center that contains servers, virtualization hypervisors, operating systems, virtual machines, virtual switches, and network resources. NFV uses generic hardware such as x86 and virtualization technology to carry very versatile software processing, thereby reducing the cost of expensive network equipment. The NFV can decouple software and hardware and abstract functions, so that the functions of network equipment do not depend on special hardware any more, resources can be shared fully and flexibly, rapid development and deployment of new services are realized, and automatic deployment, elastic expansion, fault isolation, self-healing and the like are carried out based on actual service requirements.

One of the Network virtualization schemes in NFVI is implemented by an SDN (Software Defined Network) technology, which is also a hot spot technology of current communication field research. The SDN includes two parts, namely a Controller (C) of a control plane and a Switch (SW or S) of a forwarding plane. According to the definition OF the current SDN technology, a control instruction is issued between a Controller and a Switch through an OPENFLOW (OF for short) protocol to instruct forwarding OF a data stream on the Switch. For a schematic of the logic principle, reference is made to fig. 1.

On top of NFVI, there is NFV management and orchestration (MANO), whose architecture is composed of NFVO (network function virtualization editor), VNF management (VNFManager), VIM (virtualized infrastructure management). The NFVO is responsible for managing and maintaining data storage, reference points (referencepoints) and interfaces, so that each component constituting a service can exchange data, and thus, the operations of the NFVI and the VNF are orchestrated and coordinated. There are many alternative types of VIMs and different implementations of VNFM. According to the mainstream solution in the industry, VIM chooses Openstack-based functional enhancements more, please continue to refer to fig. 1.

VNFs are deployed in NFVI, such as network elements of a vppc (virtualized evolved Packet Core) of a mobile Core network, xGW (x Gateway ), MME (Mobility management entity), PCRF (Policy and Charging Rules Function), AAA (Authentication, Authorization, Accounting, Authentication Authorization and Charging), and the like, which may be deployed in a virtual machine form on a virtual machine of NFVI. Interfaces between different VNFs exist in a logical form, and are opened through an SDN network. For example, xGW is the Gx interface between PCRF, as shown by dashed line 1 (thin dashed line) in the figure, and traffic on the interface is forwarded through switch a under the control of SDN controller 10; for another example, the traffic on the S6 interface between xGW and AAA is forwarded in a level one by one through switch a, switch C, and switch B, as shown by the dashed line 2 (bold dashed line) in the figure.

In order to meet the requirement of the operator to collect and monitor traffic, the traffic needs to be collected from the network as required, and assuming that the current traffic needs to be collected is the outgoing traffic on the logical interface 1 of VNF1 in fig. 1, the current traffic collection scheme is shown in fig. 2:

s201: the NFVO receives a flow mirror strategy configured by a tenant;

s202: the NFVO queries the VNFM for a target Virtual Machine (VM) deploying the VNF 1;

s203: NFVO inquires a port UUID (port Universal unique Identifier) of an SDN network accessed by a target VM from VIM;

s204: NFVO sends flow collection strategy to VIM;

NFVO may send the traffic collection policy to the VIM by calling a TAAS (TAP as a Service, also referred to as TAPaaS) interface of the VIM. And binding a port UUID of the SDN network accessed by the target VM in the flow collection strategy sent to the VIM.

S205: the VIM sends a flow acquisition strategy to the SDN controller;

in the scenario shown in fig. 2, the VIM may send the traffic collection policy by invoking a northbound interface of the SDN controller.

S206: and the SDN controller issues the flow acquisition instruction to the switch A to which the target virtual machine is attached.

The direction of flow is described here: the flow direction is relative, for the VNF, there are an outgoing flow and an incoming flow, and the ports of the corresponding switch are the incoming flow and the outgoing flow, respectively, that is, the outgoing flow of the VNF interface is actually the incoming flow of the switch end to which the target virtual machine deploying the VNF is connected; the inbound flow of the VNF interface is actually the outbound flow of the switch side to which the target virtual machine deploying the VNF is connected.

Therefore, the tenant wants to collect the outgoing traffic on VNF1 logical interface 1, and in fact, it is the incoming flow of P1 port that is collected by switch a. Therefore, it can be understood that the SDN controller may convert the received traffic collection policy to obtain a traffic collection indication: in the flow acquisition indication, the target flow to be acquired is changed from the outgoing flow of the target virtual machine to the incoming flow of the switch port accessed by the target virtual machine.

S207: the switch A executes the traffic collection operation and sends the collected traffic to the destination.

In the scheme shown in fig. 2, the traffic collection policy configured by the tenant on the NFVO is issued from the VNFM, and the traffic collection policy reaches the SDN controller through the delivery of the VIM (S201-S205), and the SDN controller issues the traffic collection policy to the corresponding switch (S206). In general, a traffic collection policy injected by an upper layer to an SDN controller includes traffic collection characteristics (including port UUID of a target virtual machine, quintuple information of a flow, and direction of the flow). The switch accessed by the target virtual machine filters the traffic on the switch according to the traffic collection characteristics, and the matched traffic is sent to the destination end through a special channel for traffic collection after being prepared for copying (S207). In the related traffic collection scheme, the collected traffic may be sent to the destination end through a VLAN (Virtual local Area Network) channel, a VxLAN (Virtual Extensible LAN) channel, or a GRE (Generic Routing Encapsulation) channel, and the destination end analyzes the traffic, or the destination end serves as a relay station, and sends the received traffic to another second-level destination end after preprocessing the received traffic.

In the above example, because the target traffic that the tenant needs to collect is an outgoing flow with respect to VNF1, and thus is an incoming flow with respect to the corresponding switch, the switch can directly collect. However, if the target traffic that the tenant wants to collect is an incoming flow of a certain VNF, the target traffic is an outgoing flow with respect to a switch port corresponding to the VNF, and in the related traffic collection scheme, because the processing capability of the switch chip is limited, when the switch collects an outgoing flow of a certain port of the switch, the traffic characteristics of the outgoing flow cannot be bound to the port, the traffic collection action can only take effect globally on the switch, that is, the traffic collected from any port of the switch is collected, and then the filtering is performed according to the traffic collection policy received by the switch, so as to obtain the target traffic. This results in inefficient and burdensome collection of the outgoing flows at the switch's own ports. Meanwhile, if a flow is forwarded twice or more times back and forth at different ports on the switch, the flow which should be collected once will be collected many times, which causes unnecessary burden and impact on the flow destination and the transmission link.

In order to solve the above problem, the present embodiment provides a traffic collection method, please refer to the flow chart of the traffic collection method shown in fig. 3:

s302: and determining a target acquisition object corresponding to the original acquisition object according to the network topological relation.

In this embodiment, the original collection object refers to an object that is specified by a tenant or an operator and needs to be subjected to inbound target traffic collection. It should be noted that, in the related art, when acquiring outgoing traffic of a VNF interface, a corresponding switch may directly acquire target traffic at a corresponding port of the switch, and the problems of large processing load and low efficiency as in acquiring incoming traffic of the VNF interface are not caused, so in this embodiment, an original acquisition object refers to an object for which incoming traffic acquisition needs to be performed, that is, target traffic; when flowing through the switch port connected to the original collection object, it is an outgoing flow, for example, assuming that in the example corresponding to fig. 1, the tenant requires an incoming flow of the logical interface 2 of the collection VNF1, then the logical interface 2 of the VNF1 is the original collection object. If the tenant requires the acquisition to be the inbound flow of VNF3 logical interface 3, then logical interface 3 of VNF3 is the original acquisition object.

The target collection object is an object that supports collection of the aforementioned target traffic, because the aforementioned target traffic is an outgoing flow when flowing through the target collection object, that is, an incoming flow when flowing through the switch port connected to the target collection object, the switch can directly realize collection of the target traffic with relatively high collection efficiency and relatively low collection burden, and for this case, the target collection object is considered to be an object that supports collection of the outgoing target traffic in this embodiment. It should be understood that the tenant or operator requires that the target traffic of the collection flow from the port of the first switch to the original collection object, and at the same time, the target traffic also flows from the target collection object to the second switch. Although the target flow rate has different flow directions in the original acquisition object and the target acquisition object, the same flow essentially flows through the original acquisition object and the target acquisition object. Therefore, when the tenant or the operator requires to collect the incoming target traffic of the original collection object, that is, the tenant or the operator requires to collect the outgoing target traffic which is not suitable for the first switch, the tenant or the operator can collect the outgoing traffic of the target collection object instead, that is, the second switch collects the incoming target traffic on the port of the second switch, so that the collection requirements of the tenant or the operator are completed with smaller collection processing burden and higher collection efficiency.

In this embodiment, a target acquisition object corresponding to an original acquisition object may be determined according to a network topology, because it may be determined according to the network topology that traffic flowing through an interface of which network element and a interface of another network element are the same traffic, or traffic of traffic on which network element and a traffic flowing through an interface of another network element are the same traffic, or traffic of traffic on which network element and a traffic flowing through another network element are the same traffic, a target acquisition object corresponding to the original acquisition object may be determined according to the network topology.

Generally, when an operator performs network planning, a mapping relationship between each original acquisition object and each target acquisition object may be determined according to a planned network topology, and for the mapping relationship between the original acquisition object and the target acquisition object planned by the operator, this embodiment is referred to as a "communication relationship map". Therefore, in some examples of this embodiment, a target acquisition object corresponding to an original acquisition object may be determined from a communication relationship map of communication of each network element in the SDN network.

For example, fig. 4 shows a traffic flow diagram between VNFs in an SDN network: there is bidirectional flow of traffic between interface 1 of VNF1 and interface 1 of VNF 2; there is bidirectional flow of traffic between interface 2 of VNF1 and interface 2 of VNF 3; there is bidirectional flow of traffic between interface 3 of VNF1 and interface 3 of VNF 4; there is a bidirectional flow of traffic between interface 4 of VNF2 and interface 4 of VNF 4. Table 1 shows a communication relationship map in the SDN network in fig. 4:

TABLE 1

Original collection object	Target collection object
		<VNF1, interface 1>	<VNF2, interface 1>
<VNF1, interface 2>	<VNF3, interface 2>
		<VNF1, interface 3>	<VNF4, interface 3>
<VNF2, interface 1>	<VNF1, interface 1>
		<VNF2, interface 4>	<VNF4, interface 4>
<VNF3, interface 2>	<VNF1, interface 2>
		<VNF4, interface 3>	<VNF1, interface 3>
<VNF4, interface 4>	<VNF2, interface 4>

It is assumed that when a tenant or an operator indicates to collect a target traffic to which a certain original collection object in table 1 enters, a target collection object corresponding to the original collection object may be determined according to the traffic relation map shown in table 1.

S304: and acquiring the incoming target flow of forwarding equipment connected with the target acquisition object.

After the target acquisition object corresponding to the original acquisition object is determined, the target acquisition object can be subjected to the acquisition of the outgoing target flow. It is needless to say that the process of acquiring the outgoing target traffic of the target acquisition object actually acquires the incoming target traffic of the forwarding device connected to the target acquisition object. For example, if the target collection object is connected to the forwarding device through the port 4 of the forwarding device, the forwarding device can collect the incoming traffic of the port 4, so as to collect the outgoing traffic of the target collection object to the target traffic, that is, to collect the incoming traffic of the original collection object to the target traffic.

In this embodiment, the forwarding device may be a switch or a DC GW (data center gateway), and the traffic collection method may be executed by the NFVO or implemented by the SDN controller. The following description will first describe a case where the NFVO implements the traffic collection method:

the NFVO may obtain and store a communication relationship map of each network element in the SDN network in advance, for example, an operator may input the communication relationship map into the NFVO, so that when the NFVO needs to query a target acquisition object corresponding to a certain original acquisition object, the NFVO may determine the corresponding target acquisition object directly according to the communication relationship map stored by the NFVO and the query of the original acquisition object.

For example, the NFVO may determine the original collection object according to the flow mirroring policy input by the tenant or the operator, and then query the target collection object. In the flow mirroring policy configured by the tenant or the operator, several information such as a VNF index, an interface name, and a flow direction may be included. After receiving a flow mirroring policy, the NFVO may determine, according to a flow direction therein, a flow direction of target traffic to be acquired with respect to an interface specified by a VNF specified in the flow mirroring policy, and if the flow direction specifies that the target flow direction is an incoming direction with respect to the specified interface of the VNF, the NFVO may determine that an acquisition object specified by a current tenant is an original acquisition object, and then, the NFVO determines a corresponding target acquisition object according to a communication relationship map stored by the NFVO. After the target acquisition object is determined, the NFVO issues a traffic acquisition strategy to the SDN controller, wherein the traffic acquisition strategy comprises information indicating the target acquisition object and information indicating the flow direction of target traffic.

After receiving the traffic collection policy, the SDN controller converts a collection instruction in the new traffic collection policy, because the new traffic collection policy indicates target traffic collection for outgoing of a target collection object, but in fact, it is a forwarding device that performs traffic collection, so the SDN controller converts an instruction for collecting target collection object outgoing of target traffic into an instruction for collecting incoming target traffic of a port connected to the target collection object on the forwarding device. After the conversion is completed, the SDN controller sends the converted flow acquisition instruction to the forwarding equipment, so that the forwarding equipment realizes the acquisition of the incoming target flow according to the flow acquisition instruction, and transmits the acquired target flow to a destination terminal.

Of course, it can be understood by those skilled in the art that if the NFVO determines that the flow mirroring policy requires collecting outgoing traffic for a certain collection object, the target traffic is incoming target traffic with respect to a port of a forwarding device connected to the target collection object, and in this case, the NFVO may directly collect incoming target traffic by notifying a corresponding forwarding device (see fig. 2 for specific flow, which is not described herein again), and it is not necessary to use the collection object in the flow mirroring policy as an original collection object.

The following describes a process of acquiring the outbound target traffic of the NFVO with respect to the target acquisition object by combining several original acquisition objects and the target acquisition object:

scenario 1: assuming that the original acquisition object is the first interface of the first VNF in DC (data center) (e.g., < VNF1, interface 1> in table 1), the target acquisition object determined by NFVO is the second interface of the second VNF (e.g., < VNF2, interface 1> in table 1), see fig. 5:

s502: the NFVO determines the target virtual machine to deploy the second VNF.

It is understood that the second VNF may be deployed on only one Virtual Machine (VM), in which case the target virtual machine queried by the NFVO is one. If the second VNF is deployed on two or more virtual machines, there are naturally many target virtual machines, and the query result obtained by the NFVO is a virtual machine list, where the virtual machine list includes indication information of each virtual machine on which the second VNF is deployed.

Optionally, the NFVO may query the VNFM for a virtual machine deployed by the second VNF, and after receiving the query request of the NFVO, the VNFM feeds back a query result as a response to the NFVO.

S504: and the NFVO determines an access port UUID of the target virtual machine accessing the SDN network.

After querying the target virtual machine, the NFVO determines a port UUID of the target virtual machine accessing the SDN network, and in this embodiment, the NFVO may query the VIM for the port UUID of the port corresponding to the target virtual machine. In this embodiment, a port through which the target virtual machine accesses the SDN network is referred to as an "access port". It should be noted that when the second VNF is deployed on multiple virtual machines, these virtual machines are also typically accessed into the SDN network through different ports, and therefore, in this case, the NFVO may query multiple access port UUIDs corresponding to different target virtual machines from the VIM, so that it is likely that a port list is fed back to the NFVO by the VIM. If there is only one target virtual machine, there is naturally only one access port UUID corresponding to the target virtual machine, in which case, the only one port UUID fed back by the VIM according to the query request of the NFVO is the port UUID.

S506: and the NFVO sends a flow collection strategy to the SDN controller.

After determining the UUIDs of the target virtual machine and the access port, the NFVO may send a traffic collection policy to the SDN controller, where the traffic collection policy may include the following information:

a list of target virtual machines for at least one target virtual machine in the list of target virtual machines;

the flow direction of the target traffic to be collected on the target virtual machine;

UUID of access port.

The traffic collection policy sent to the SDN controller can instruct the SDN controller to control a forwarding device to which the target virtual machine is accessed to collect ingress traffic of a target port, where a "target port" refers to a port on the forwarding device to which the target virtual machine is accessed.

After the SDN controller receives the traffic collection policy, the processing method in the related art is basically the same, and details are not repeated here.

Scenario 2: in this example, after the NFVO determines that the target collection object corresponds to the original collection object, the traffic collection policy may be directly sent to the SDN controller without querying the port UUID of the access port and the target virtual machine, assuming that the original collection object is the first interface of the first VNF inside the DC, and the target collection object is the second network element outside the DC.

In this case, a traffic collection policy sent by the NFVO to the SDN controller may instruct the SDN controller to control a forwarding device accessed by the second network element to collect ingress traffic of a target port, where the target port in scenario 2 is a port on the forwarding device for the second network element to access. The traffic collection policy sent by the NFVO to the SDN controller may include the following information:

network element indication information, where the network element indication information is used to indicate information of a second network element, that is, to indicate to the SDN controller that an object to which the current acquisition target traffic is directed is the second network element;

the flow direction of the target traffic to be collected on the second network element.

According to the traffic collection method provided by the embodiment, when it is determined that the incoming traffic collection of the original collection object is required, the process of the incoming traffic collection of the original collection object can be transferred to the outgoing traffic collection of the target collection object according to the network topology relation, and by the way, forwarding devices such as a switch do not need to perform outgoing traffic collection on ports of the switch, the collection burden of the switch in traffic collection is reduced, and meanwhile, the traffic collection efficiency is improved.

Example two:

before describing the flow of the flow acquisition method in this scenario, it should be noted that the scenario in which the SDN controller executes the flow acquisition method is mainly a case where an original acquisition object is a first Host in a DC and a target acquisition object is a second Host in the DC. Please refer to the flowchart shown in fig. 6:

s602: and the SDN controller determines a target acquisition object corresponding to the first Host according to a pre-stored communication relation map.

In this embodiment, a communication relationship map between network elements in the network is stored in advance in the SDN controller, and when the SDN controller determines that an incoming target traffic acquisition needs to be performed for a certain network element at present, the SDN controller may use the network element as an original acquisition object and perform query in the communication relationship map according to the original acquisition object, so as to determine a target acquisition object corresponding to the original acquisition object, where the original acquisition object is taken as a first Host, and the SDN controller may determine, according to the communication relationship map, that a target acquisition object corresponding to the first Hsot is a second Host.

In this embodiment, the Host is a physical server Host, or a virtual machine Host, or a router, or a switch, or any other three-layer device, as long as the device is uniformly managed in the SDN network.

S604: and the SDN controller sends a flow acquisition instruction to the inquired forwarding equipment accessed by the second Host.

After determining the second Host, the SDN controller may further determine a forwarding device connected to the second Host, where the forwarding device may be a switch or a DC GW. Subsequently, the SDN controller sends a traffic collection instruction to the forwarding device, which can instruct the forwarding device to collect ingress traffic of a target port, where the target port is a port on the forwarding device for a second Host to access.

This scenario is further illustrated below in example 1, see fig. 7:

s701: and the SDN controller receives a communication relation map between hosts in the SDN network.

The network operation and maintenance personnel can input the communication relationship map to the SDN controller directly from an interactive interface of the SDN controller or input the communication relationship map through a command line of the SDN controller. Table 2 shows a communication relationship map between hosts:

TABLE 2

Original collection object	Target collection object
		Host1	Host2
Host2	Host1
		Host3	Host4
Host4	Host3

S702: the SDN controller receives a configured flow mirroring policy.

For example, if a tenant or an operator requires to collect incoming traffic of logical interface 1 on Host1, the SDN controller should cooperate with other network elements to copy target traffic to be collected and then transmit the target traffic to a destination.

S703: and the SDN controller queries a target acquisition object corresponding to the Host1 as Host 2.

After receiving the flow mirroring policy, the SDN controller may determine, according to the flow mirroring policy, that it is required that the acquired target traffic is inbound with respect to the Host1, so that it is inconvenient for a switch connected to the Host1 to acquire, and therefore, the SDN controller may use the Host1 as an original acquisition object, then query a communication relationship map for a target acquisition object corresponding to the Host1, and know from the communication relationship map shown in table 2 that the target acquisition object corresponding to the Host1 is the Host 2.

S704: and the SDN controller issues the traffic acquisition instruction to the switch affiliated to the Host 2.

The flow acquisition instruction sent by the SDN controller indicates the switch to which the Host2 is attached, and the switch B causes the switch B to acquire the ingress flow of the target port.

S705: and the switch B executes the traffic collection operation and sends the collected incoming target traffic to the destination terminal.

In this embodiment, the switch may send the acquired target traffic to the destination through any one of the VLAN channel, the VxLAN channel, and the GRE channel.

The traffic collection method provided by this embodiment is mainly based on a communication scenario between different hosts inside the DC, and not only can reduce the burden of the switch on traffic collection and improve the efficiency of traffic collection, but also the scheme is free from the limitations on NFVO and VIM.

Example three:

in order to make the advantages and details of the foregoing traffic collection method more clear to those skilled in the art, the present embodiment will explain the traffic collection method provided in the foregoing embodiment with reference to more examples:

example 2:

the present example will continue to describe the traffic collection method based on scenario 1 of the embodiment, please refer to fig. 4 in combination with fig. 8 and fig. 9, where fig. 8 shows a schematic flow diagram of the target traffic between VNF1 and VNF2, and fig. 9 shows an interaction flow diagram of traffic collection:

s901: the NFVO receives a communication relation map between VNFs in the SDN network.

The operation and maintenance personnel of the tenant or the operator can inject a map of the interconnection relationship between the VNF and the VNF into the NFVO, and a specific communication relationship map is shown in table 1.

According to the communication relation map, the NFVO can inquire the key value pair of the target collection object by inputting the key value pair of the original collection object, namely, the network element and the interface. For example, if the inbound traffic on interface 1 of VNF1 is to be collected, but it is inconvenient to collect, it may be possible to query < VNF2, interface 1> by inputting a communication relationship map shown in < VNF1, interface 1> lookup table 1, in this case, interface 1 of VNF2 is the target collection object, and the collection requirement of the tenant or the operator for collecting the inbound traffic on interface 1 of VNF1 can be met by collecting the outbound traffic on interface 1 of VNF 2.

S902: the NFVO receives a flow mirror strategy configured by a tenant or operation and maintenance personnel;

for example, assume in this example that a tenant or operation and maintenance person is required to collect inbound traffic for interface 1 on VNF1 through the flow mirroring policy.

S903: the NFVO inquires and determines a target acquisition object through a communication relation map;

the NFVO may query that the target collection object is < VNF2, interface 1> from the communication relationship map according to < VNF1, interface 1>, so the NFVO determines that traffic of VNF2 interface 1 needs to be collected, and determines that outgoing traffic of VNF2 interface 1 needs to be collected at the same time.

S904: the NFVO queries the VNFM for a target virtual machine deploying the VNF 2;

s905: NFVO inquires a port UUID of an SDN network accessed by a target VM from VIM;

it is understood that the port UUID corresponding to the target virtual machine queried by the NFVO according to VNF2 may be a UUID list including a plurality of port UUIDs.

S906: NFVO sends flow collection strategy to VIM;

alternatively, NFVO may send the traffic collection policy to the VIM by calling the TAAS interface of the VIM. It should be understood that, in the traffic collection policy, the NFVO has replaced the collection object with the target collection object, specifies a flow direction of target traffic to be collected, and also binds a port UUID of an SDN network accessed by the target VM.

S907: the VIM sends a flow acquisition strategy to the SDN controller;

the VIM sends the traffic collection policy by invoking a northbound interface of the SDN controller.

S908: the SDN controller issues a flow acquisition instruction to a switch B to which a target virtual machine is attached;

it can be understood that the tenant wants to collect the incoming traffic on VNF1 logical interface 1, and in fact, the incoming traffic of P4 port is collected by switch B. After receiving the traffic collection policy, the SDN controller converts the traffic collection policy to obtain a traffic collection instruction: in the flow acquisition indication, the target flow to be acquired is changed from the outgoing flow of the target virtual machine to the incoming flow of the switch port accessed by the target virtual machine.

S909: and the switch B executes the traffic collection operation and sends the collected traffic to the destination terminal.

And the switch B acquires the flow according to the corresponding strategy and transmits the acquired flow to a remote destination end through the tunnel.

Example 3:

in this embodiment, a method for acquiring traffic is described based on a scenario 1 of an embodiment, please refer to fig. 10 to 12, where fig. 10 shows a schematic flow diagram of traffic between network elements in an SDN network, fig. 11 shows a schematic flow diagram of target traffic between an ER (External Router) and a VNF1, and fig. 12 shows a flow interaction diagram of traffic acquisition:

as can be seen from fig. 11, VNF1, VNF2, and VNF3 are included in the SDN network, along with ER. As can be seen in fig. 10, there is a bidirectional flow of traffic between interface 1 of VNF1 and interface 1 of VNF 2; there is bidirectional flow of traffic between interface 2 of VNF1 and interface 2 of VNF 3; there is a bidirectional flow of traffic between interface 5 of VNF1 and interface 5 of ER. Table 3 shows a communication relationship map in the SDN network in fig. 10:

TABLE 3

S1201: the NFVO receives a communication relationship map of the SDN network.

The operation and maintenance personnel of the tenant or the operator can inject a communication relationship map into the NFVO, and the specific communication relationship map is shown in table 3. The communication relation map comprises communication connection relations among VNFs in the SDN network and between the VNFs and a DC external network.

S1202: the NFVO receives a flow mirror strategy configured by a tenant or operation and maintenance personnel;

for example, assume in this example that a tenant or operation and maintenance person is required to collect inbound traffic for interface 5 on VNF1 through the flow mirroring policy.

S1203: the NFVO inquires and determines a target acquisition object through a communication relation map;

the NFVO may query that the target collection object is < ER, interface 5> from the communication relationship map in table 3 according to < VNF1, interface 5>, so that the NFVO determines that traffic of the ER interface 5 needs to be collected, and determines that outgoing traffic of the ER interface 5 needs to be collected at the same time.

S1204: NFVO sends flow collection strategy to VIM;

alternatively, NFVO may send the traffic collection policy to the VIM by calling the TAAS interface of the VIM. It should be appreciated that in this traffic collection strategy, the NFVO has replaced the collection object with the target collection object, specifying the flow direction of the target traffic to be collected. In this embodiment, the traffic collection policy may not carry the UUID of the ER access interface, or may carry the UUID, but a value corresponding to the UUID is a default value.

S1205: the VIM sends a flow acquisition strategy to the SDN controller;

S1206: the SDN controller issues a flow acquisition instruction to a DC GW to which an ER is attached;

it can be understood that the tenant wants to collect the incoming traffic on VNF1 logical interface 5, and in fact, the DC GW collects the incoming traffic of P5 port. After receiving the traffic collection policy, the SDN controller converts the traffic collection policy to obtain a traffic collection instruction: in the traffic collection indication, the target traffic to be collected is changed from the outgoing flow of the ER to the incoming flow of the DC GW P5 port.

S1207: the DC GW performs traffic collection operation and transmits the collected traffic to a destination terminal.

And the DC GW acquires the incoming traffic from the P5 port according to the corresponding strategy and sends the acquired traffic to a remote destination end through a tunnel.

It should be appreciated that, by the query of S1203, it has been determined that it is the outgoing traffic of ER interface 5 that is collected. In S1206, the SDN controller maps the acquisition requirement in the flow mirroring policy to an ingress traffic of port P5 of the acquisition DC GW. It can be seen that the ingress traffic of the P5 port and the egress traffic of the ER on the DC GW are the same traffic as the ingress traffic of the VNF1 interface 5 originally required in the flow mirroring policy, so with the acquisition scheme of this example, the acquisition requirement of the tenant in the flow mirroring policy can be met.

Example four:

in this embodiment, a flow collection process in a scenario where migration of a VM deploying a VNF occurs, a flow collection process in a scenario where pop-up of a VM deploying the VNF occurs, a flow collection process in a scenario where contraction and contraction of a VM deploying the VNF occur, and a flow collection process in a scenario where a VM deploying the VNF is a cluster will be described with reference to examples:

example 4:

the present example explains the traffic collection process in the migration scenario of the VM deploying the VNF2 on the basis of example 2, please refer to fig. 13:

s1300: carrying out flow collection;

in this example, what is required to be collected in the flow mirroring policy is the collection of inbound traffic of VNF1 interface 1, which will eventually be converted into collection of inbound traffic on switch 2 port P4 for the target VM connection of VNF2, as will be understood from the introduction in example 2. This process can be referred to as introduced in example 2 and will not be described here.

S1301: the virtual machine VM2 deploying VNF2 migrates.

Deployment assumes that the virtual machine of VNF2 is VM2, which originally accessed the SDN network through port P4 of switch B, and after migration, VM2 accesses the SDN network through port P5 of switch C.

S1302: and the SDN controller receives a P5 port of the switch C and reports a port online event to the SDN controller.

The P5 port of the switch C reports a port online event to the SDN controller, and carries the port UUID of the virtual machine VM 2' of the VNF2 after the virtual machine migration, and the UUID before the migration are unchanged.

S1303: the SDN controller updates the flow acquisition strategy according to the corresponding relation between the flow acquisition strategy acquired from the VIM and the UUID;

s1304: the SDN controller sends a traffic collection strategy on a port P5 of a switch C on a new line of VM 2', and the traffic collection is collected from a P5 port of the switch C instead and is sent to a corresponding destination end.

S1305: and the SDN controller deletes the traffic collection strategy on the original online switch B port P4 of the VM 2.

Thus, port P4 of switch B no longer collects traffic.

The example explains an automatic following mechanism of the traffic collection strategy in a migration scene of the virtual machine on the target collection object side, namely, after the virtual machine on the target collection object side is migrated, the traffic collection strategy automatically follows the migration, and the traffic demand of the tenant can be ensured to be continuously met. It should be appreciated that if the migration is performed by the original acquisition object side virtual machine, for example, on the basis of example 2, the migration is performed by the virtual machine deploying the VNF1, because the target acquisition object side virtual machine is not changed, and thus the traffic acquisition location is not changed, the SDN controller does not need to adjust the location point of the traffic acquisition policy.

Example 5:

the present example explains the traffic collection process in the scenario of pop-up of VM deploying VNF2 on the basis of example 2, please refer to fig. 14:

S1401: the VNF2 is expanded, and a virtual machine VM3 is popped;

assume in this embodiment that the popped VM3 is accessed through switch C's P5 port.

S1402: the NFVO queries the VNFM for the newly popped virtual machine VM 3;

s1403: NFVO queries VIM for Port UUID of VM 3;

s1404: NFVO calls TAAS interface of VIM to issue flow collection strategy;

the traffic collection policy is for VM 3.

S1405: the VIM calls a northbound interface of the SDN controller to issue a flow collection strategy;

s1406: the SDN controller sends the flow acquisition indication to a corresponding port P5 of the switch C;

the SDN controller converts the received traffic collection policy to obtain a traffic collection instruction, and sends the traffic collection instruction to a port P5 corresponding to the switch C to which the VM3 is attached.

S1407: and the exchanger C executes the traffic collection operation and sends the collected traffic to the destination terminal.

This example illustrates a traffic collection scheme of the VNF2 on the target collection object side in a scenario of adding a virtual machine VM3 for capacity expansion, where a traffic collection policy is automatically generated and issued to the SDN controller, and the SDN controller generates a traffic collection instruction according to the traffic collection policy and sends the traffic collection instruction to a corresponding switch port, so that it can be ensured that traffic on a new virtual machine can be collected and is not lost.

Example 6:

this example will illustrate the traffic collection process in the scenario where the VM deploying the VNF2 is subjected to the contraction, please refer to fig. 15:

first, assume that the traffic collection scenario before VM scalability in this example is the traffic collection scenario after dilation in example 5, that is, the original collection object is VNF1 interface 1, the target collection object is interface 1 of VNF2, and the virtual machine deploying VNF2 includes VM2 and VM3, VM2 is accessed into the SDN network through port P4 of switch B, and VM3 is accessed into the SDM network through port P5 of switch C. The switch B and the switch C can collect the corresponding service flow.

S1501: VNF2 performs virtual machine scalping;

it is assumed here that the contraction of VNF2 is to delete virtual machine VM3 under the original switch C-port P5. Then the virtual machine VM3 under switch C port P5 will no longer exist.

S1502: NFVO calls an interface of TAAS of VIM to send a strategy deletion instruction;

s1503: the VIM calls a northbound interface of the SDN controller to send a strategy deletion instruction;

after receiving the policy deletion instruction, the SDN controller deletes the traffic collection policy from the network side.

S1504: deleting a traffic collection strategy from a switch C port P5 by the SDN controller;

after the traffic collection policy on switch C port P5 is removed, switch C will not collect incoming traffic on P5 port any more.

This example illustrates a traffic collection policy deletion under the scenario of virtual machine VM3, at the target collection object side VNF2 capacity reduction, preventing legacy spam policies.

Example 7:

in this example, a flow collection process in a scenario where a VM that deploys a VNF on a target collection object side is a cluster will be described, please refer to fig. 16:

s1600: the NFVO receives a communication relation map between VNFs in the SDN network.

In this example, it is assumed that the communication relationship map is injected into the NFVO by the tenant, however, it can be understood by those skilled in the art that the communication relationship map may also be injected into the NFVO by the operation and maintenance personnel of the operator.

S1601: the NFVO receives a stream mirror strategy;

assume in this example that the tenant requires to collect inbound traffic for VNF1 interface 1 in the flow mirroring policy.

S1602: and the NFVO determines a target acquisition object corresponding to the interface 1 of the VNF1 according to the communication relation map.

Through the communication relation map, the target acquisition object corresponding to the interface 1 of the VNF1 is determined to be the interface 1 of the VNF 2.

S1603: the NFVO queries the VNFM for a target virtual machine deploying the VNF 2;

it is assumed here that the virtual machine deploying VNF2 includes three, VM1, VM2 and VM3, where VM1 is accessed under port P4-1 of switch a, VM2 is accessed under port P4-2 of switch B, and VM3 is accessed under port P4-3 of switch C.

S1604: NFVO inquires a port UUID of an SDN network accessed by a target VM from VIM;

it is assumed here that the UUIDs of the access interfaces of VM1, VM2, and VM3 accessing the SDN network are UUID1, UUID2, and UUID3, respectively.

S1605: NFVO calls an interface of TAAS of VIM to issue a flow collection strategy;

here, the traffic collection policy indicates that outgoing traffic collection is performed on interface 1 of VNF2, and port UUIDs designated as UUID1, UUID2, and UUID3 in the traffic collection policy.

S1606: the VIM calls a northbound interface of the SDN controller to issue a flow collection strategy aiming at the three virtual machines;

s1607: the SDN controller respectively issues flow acquisition instructions to the switches to which the three target virtual machines are attached;

the SDN controller sends a traffic collection instruction aiming at the VM1 to a port P4-1 of a switch A, sends a traffic collection instruction aiming at the VM1 to a port P4-2 of a switch B, and sends a traffic collection instruction aiming at the VM3 to a port P4-3 of a switch C.

S1608: and the three switches respectively collect the flow, and the collected flow is sent to a destination end through respective VxLAN tunnels.

This example illustrates how the traffic collection process is performed when the target collection object-side VNF is deployed on the cluster VM.

Example five:

the present embodiment provides a flow rate collecting device, please refer to a schematic structural diagram of the flow rate collecting device shown in fig. 17:

the traffic collection device 170 includes an object determination unit 172 and a collection control unit 174, where the object determination unit 172 is configured to determine a target collection object corresponding to an original collection object according to a network topology relationship, and the collection control unit 174 is configured to collect incoming target traffic for a forwarding device connected to the target collection object.

The target collection object is an object that supports collection of the aforementioned target traffic, that is, when the target traffic flows through the switch port connected to the target collection object, the target collection object is an incoming flow, so that the switch can directly realize collection of the target traffic with relatively high collection efficiency and relatively low collection burden. It should be understood that the tenant or operator requires that the target traffic of the collection flow from the port of the first switch to the original collection object, and at the same time, the target traffic also flows from the target collection object to the second switch. Although the target flow rate has different flow directions in the original acquisition object and the target acquisition object, the same flow essentially flows through the original acquisition object and the target acquisition object. Therefore, when the tenant or the operator requires to collect the incoming target traffic of the original collection object, that is, the tenant or the operator requires to collect the outgoing target traffic which is not suitable for the first switch, the tenant or the operator can collect the outgoing traffic of the target collection object instead, that is, the second switch collects the incoming target traffic on the port of the second switch, so that the collection requirements of the tenant or the operator are completed with smaller collection processing burden and higher collection efficiency.

In this embodiment, the object determining unit 172 may determine the target acquisition object corresponding to an original acquisition object according to the network topology, because it may be determined according to the network topology that a traffic flowing through an interface of which network element and a traffic flowing through an interface of another network element are the same traffic, or a traffic flowing through an interface of which network element and a traffic flowing through another network element are the same traffic, the object determining unit 172 may determine the target acquisition object corresponding to the original acquisition object according to the network topology.

Generally, when an operator performs network planning, a mapping relationship between each original acquisition object and each target acquisition object may be determined according to a planned network topology, and for the mapping relationship between the original acquisition object and the target acquisition object planned by the operator, this embodiment is referred to as a "communication relationship map". Therefore, in some examples of this embodiment, the object determining unit 172 may determine, from a communication relationship map of communication of each network element in the SDN network, a target acquisition object corresponding to the original acquisition object.

After the object determining unit 172 determines the target acquisition object corresponding to the original acquisition object, the acquisition control unit 174 may perform the acquisition of the outgoing flow to the target acquisition object. It is needless to say that the process of acquiring the outgoing target traffic of the target acquisition object actually acquires the incoming target traffic of the forwarding device connected to the target acquisition object. For example, if the target collection object is connected to the forwarding device through the port 4 of the forwarding device, the forwarding device can collect the incoming traffic of the port 4, so as to collect the outgoing traffic of the target collection object to the target traffic, that is, to collect the incoming traffic of the original collection object to the target traffic.

In this embodiment, the traffic collection device 170 may be deployed on an NFVO network element, or may be deployed on an SDN controller. When the traffic collection apparatus 170 may be deployed on an NFVO network element, the function of the object determination unit 172 may be implemented by a processor of a network device that deploys the NFVO network element, and the function of the collection control unit 174 is implemented by a communication apparatus and the processor of the network device together. When the traffic collection device 170 is deployed on an SDN controller, the functions of the object determination unit 172 may be implemented by a processor deploying the SDN controller, and the functions of the collection control unit 174 are implemented by a communication device and a processor of the SDN controller.

The flow collection device that this embodiment provided, when confirming to need go into to target flow collection to former collection object, can go into to go out to flow collection to target collection object to the process of flow collection to former collection object according to the network topology relation, through this kind of way for forwarding devices such as switch needn't go out to flow collection to self port again, has reduced the collection burden that the switch carried out flow collection, has also promoted flow collection efficiency simultaneously.

Example six:

in this embodiment, the computer-readable storage medium may store a flow collection program, and the flow collection program may be used by one or more processors to execute a process for implementing any one of the flow collection methods described in the foregoing embodiments.

The present embodiment further provides a network device, as shown in fig. 18: the network device 180 includes a processor 181, a memory 182, and a communication bus 183 for connecting the processor 181 and the memory 182, wherein the memory 182 may be the storage medium storing the traffic collection program. The processor 181 may read the flow rate acquisition program, compile and execute the flow that implements the flow rate acquisition method described in the foregoing embodiment:

the processor 181 is configured to determine a target acquisition object corresponding to an original acquisition object according to a network topology relationship, and acquire incoming target traffic of a forwarding device connected to the target acquisition object.

In this embodiment, the processor 181 may determine a target acquisition object corresponding to an original acquisition object according to a network topology, because it may be determined according to the network topology that a traffic flowing through an interface of which network element and a traffic flowing through an interface of another network element are the same traffic, or a traffic flowing through an interface of which network element and a traffic flowing through another network element are the same traffic, the processor 181 may determine the target acquisition object corresponding to the original acquisition object according to the network topology.

Generally, when an operator performs network planning, a mapping relationship between each original acquisition object and each target acquisition object may be determined according to a planned network topology, and for the mapping relationship between the original acquisition object and the target acquisition object planned by the operator, this embodiment is referred to as a "communication relationship map". Therefore, in some examples of this embodiment, the processor 181 may determine, from a communication relationship map of communications of network elements in the SDN network, a target acquisition object corresponding to an original acquisition object.

After the processor 181 determines the target acquisition object corresponding to the original acquisition object, the target acquisition object may be subjected to the acquisition of outgoing target traffic. It is needless to say that the process of acquiring the outgoing target traffic of the target acquisition object actually acquires the incoming target traffic of the forwarding device connected to the target acquisition object. For example, if the target collection object is connected to the forwarding device through the port 4 of the forwarding device, the forwarding device can collect the incoming traffic of the port 4, so as to collect the outgoing traffic of the target collection object to the target traffic, that is, to collect the incoming traffic of the original collection object to the target traffic.

In this embodiment, the forwarding device may be a switch or a DC GW, and the network device 180 may be an NFVO network element or an SDN controller.

The network equipment that this embodiment provided, when confirming to need to go into to target traffic collection to former collection object, can go into to flow collection to the process of target collection object to go out to flow collection according to the network topology relation with getting into to flow collection to former collection object, through this kind of way for forwarding device such as switch needn't go out to flow collection to self port again, has reduced the collection burden that the switch carries out flow collection, has also promoted flow collection efficiency simultaneously.

It will be apparent to those skilled in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software (which may be implemented in program code executable by a computing device), firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed over computer-readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media), executed by a computing device, and in some cases may perform the steps shown or described in a different order than here. The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art. Thus, the present invention is not limited to any specific combination of hardware and software.

The foregoing is a more detailed description of embodiments of the present invention, and the present invention is not to be considered limited to such descriptions. For those skilled in the art to which the invention pertains, several simple deductions or substitutions can be made without departing from the spirit of the invention, and all shall be considered as belonging to the protection scope of the invention.

Claims

1. A traffic collection method, comprising:

determining a target acquisition object corresponding to an original acquisition object according to a network topological relation, wherein the original acquisition object is an object for which an incoming target flow needs to be acquired, the flow direction of the target flow is an outgoing direction relative to the target acquisition object, and the target acquisition object is an object supporting the target flow of the acquisition outgoing direction;

2. The traffic collection method of claim 1, wherein the forwarding device is a switch or a data center gateway (DC GW).

3. The traffic collection method according to claim 1, further comprising:

if the current need of collecting the outgoing target flow aiming at a certain collection object is determined;

and collecting the incoming target flow of the forwarding equipment connected with the collection object.

4. The traffic collection method according to claim 1, wherein the determining the target collection object corresponding to the original collection object according to the network topology relationship comprises:

and determining a target acquisition object corresponding to the original acquisition object according to a pre-stored communication relation map of communication of each network element in the SDN, wherein the communication relation map is configured based on network topology planning of an operator.

5. The traffic collection method according to any one of claims 1 to 4, wherein the original collection object is a first interface of a first Virtual Network Function (VNF), the target collection object is a second interface of a second VNF, and the collecting of the incoming target traffic to the forwarding device connected to the target collection object includes:

determining a target virtual machine to deploy the second VNF;

determining a Universal Unique Identifier (UUID) of an access port of the target virtual machine accessing the SDN network;

sending a traffic collection policy to an SDN controller, where the traffic collection policy can instruct the SDN controller to control a forwarding device to which the target virtual machine is accessed to collect incoming traffic of a target port, and the target port is a port on the forwarding device to which the target virtual machine is accessed.

6. The traffic collection method according to claim 5, wherein the traffic collection policy includes the following information:

a target virtual machine list, wherein the target virtual machine list is used for at least one target virtual machine;

the flow direction of target flow to be collected on the target virtual machine;

the UUID of the access port.

7. The traffic collection method according to any one of claims 1 to 4, wherein the original collection object is a first interface of a first VNF inside a data center DC, the target collection object is a second network element outside the DC, and the collecting of the incoming target traffic of the forwarding device connected to the target collection object comprises:

sending a traffic collection policy to an SDN controller, where the traffic collection policy can instruct the SDN controller to control a forwarding device accessed by the second network element to collect incoming traffic of a target port, where the target port is a port on the forwarding device for the second network element to access.

8. The traffic collection method according to claim 7, wherein the traffic collection policy includes the following information:

network element indication information, wherein the network element indication information is used for indicating information of the second network element;

and the flow direction of the target traffic to be collected on the second network element.

9. The traffic collection method according to any one of claims 1 to 4, wherein the original collection object is a first Host, the target collection object is a second Host, and the collecting of the incoming target traffic of the forwarding device to which the target collection object is connected comprises:

and sending a flow acquisition instruction to forwarding equipment accessed by the second Host, wherein the flow acquisition instruction can instruct the forwarding equipment to acquire the incoming flow of a target port, and the target port is a port accessed by the second Host on the forwarding equipment.

10. A flow collection device, comprising:

the target acquisition unit is used for acquiring the target traffic of the target acquisition object, and determining the target acquisition object corresponding to the original acquisition object according to the network topology relation, wherein the original acquisition object is an object for which the target traffic is required to be acquired, the flow direction of the target traffic is an outgoing direction relative to the target acquisition object, and the target acquisition object is an object supporting the target traffic of the outgoing direction;

11. A network device comprising a processor, a memory, and a communication bus;

the processor is configured to execute one or more programs stored in the memory to implement the steps of the traffic collection method according to any of claims 1 to 9.

12. The network device of claim 11, wherein the network device is a network function virtualization orchestrator, NFVO, network element or an SDN controller.

13. A storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the steps of the flow collection method according to any one of claims 1 to 9.