WO2023213164A1 - 流量采集规则的配置方法及其系统、存储介质 - Google Patents

流量采集规则的配置方法及其系统、存储介质 Download PDF

Info

Publication number
WO2023213164A1
WO2023213164A1 PCT/CN2023/086326 CN2023086326W WO2023213164A1 WO 2023213164 A1 WO2023213164 A1 WO 2023213164A1 CN 2023086326 W CN2023086326 W CN 2023086326W WO 2023213164 A1 WO2023213164 A1 WO 2023213164A1
Authority
WO
WIPO (PCT)
Prior art keywords
message object
source port
traffic collection
information
rule
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2023/086326
Other languages
English (en)
French (fr)
Inventor
毕以峰
杨帆
许多
陆华兴
李立平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of WO2023213164A1 publication Critical patent/WO2023213164A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0889—Techniques to speed-up the configuration process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/10—Packet switching elements characterised by the switching fabric construction
    • H04L49/111—Switch interfaces, e.g. port details

Definitions

  • This application relates to but is not limited to the field of data processing, and in particular, to a configuration method of traffic collection rules, its system, and storage media.
  • Network Function Virtualization Infrastructure is a cloud data center that includes servers, virtualization hypervisors, operating systems, virtual machines, virtual switches and network resources, and can utilize general-purpose hardware and virtualization technologies , through software and hardware decoupling and functional abstraction, it reduces the dependence of network equipment functions on dedicated hardware. It not only reduces the cost of hardware equipment, but also has the advantages of flexible sharing of resources and rapid development and deployment of new services. It is widely used by major operators use.
  • traffic collection rules are usually configured on the switching equipment of the NFVI system, so that the switching equipment collects traffic from the source port according to the traffic collection rules, and then outputs the collected traffic from the destination port to traffic analysis. equipment.
  • the current approach is to configure a traffic collection rule for each source port separately. When there are many source ports, it takes a lot of time and cost, and the configuration efficiency is low.
  • Embodiments of this application provide a configuration method of traffic collection rules, its system, and storage medium.
  • embodiments of the present application provide a method for configuring traffic collection rules, including: obtaining a first message object, where the first message object includes at least two source port information; obtaining the information related to the first message object.
  • the corresponding traffic collection rule is configured to the source port corresponding to each source port information recorded in the first message object.
  • embodiments of the present application provide an NFVI system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the computer program, it implements the following steps: On the one hand, the configuration method of traffic collection rules.
  • embodiments of the present application provide a computer-readable storage medium that stores computer-executable instructions.
  • the computer-executable instructions are used to execute the configuration method of traffic collection rules as described in the first aspect.
  • Figure 1 is a schematic framework diagram of an NFVI system provided by an embodiment of the present application.
  • Figure 2 is a flow chart of a method for configuring traffic collection rules provided by another embodiment of the present application.
  • Figure 3 is a flow chart for generating traffic collection rules provided by another embodiment of the present application.
  • Figure 4 is a flow chart for generating traffic collection rules provided by another embodiment of the present application.
  • Figure 5 is a flow chart for obtaining a fourth message object provided by another embodiment of the present application.
  • Figure 6 is a flow chart of Example 1 provided by another embodiment of the present application.
  • Figure 7 is a flow chart for generating traffic collection rules provided by another embodiment of the present application.
  • Figure 8 is a flow chart of Example 2 provided by another embodiment of the present application.
  • Figure 9 is a flow chart of Example 3 provided by another embodiment of the present application.
  • Figure 10 is a flow chart of Example 4 provided by another embodiment of the present application.
  • Figure 11 is a flow chart for updating destination port information provided by another embodiment of the present application.
  • Figure 12 is a flow chart of an update source port provided by another embodiment of the present application.
  • Figure 13 is a flow chart of Example 5 provided by another embodiment of the present application.
  • Figure 14 is a flow chart of Example 6 provided by another embodiment of the present application.
  • Figure 15 is a device diagram of an NFVI system provided by another embodiment of the present application.
  • the configuration method of traffic collection rules includes: obtaining a first message object, where the first message object includes at least two source port information; obtaining and The traffic collection rule corresponding to the first message object is configured to the source port corresponding to each source port information recorded in the first message object.
  • the source ports that need to be deployed with the same traffic collection rules can be recorded in the first message object, and then the traffic collection rules can be configured and deployed for the first message object, so that the traffic collection rules can be deployed at the same time to at least two source ports, which reduces the number of configurations of traffic collection rules, reduces the probability of errors in traffic collection rules, and effectively improves the configuration efficiency of traffic collection rules.
  • Figure 1 is the NFVI system architecture under the Software Defined Network (SDN) network.
  • the NFVI system also includes NFV Management and Orchestration (MANO) 110, MANO110 and NFVI
  • the system's virtualized infrastructure manager (Virtualized Infrastructure Manager, VIM) 120 communication connection, MANO110 and VIM120 can be set up with a graphical user interface (Graphical User Interface, GUI), and the configuration of each message object is completed through the GUI.
  • the NFVI system also includes a control plane controller (SDN controller, SDNC) 130. SDNC 130 communicates with VIM120.
  • the orchestration strategy of traffic collection rules can be issued through MANO110 and delivered to SDNC130 through VIM120.
  • the NFVI system also includes a data center gateway (Data Center Gateway, DC GW) 140.
  • the DC GW140 is used to connect to the external network.
  • the DC GW140 is connected to the user plane network element (User Plane Function, UPF) through the backbone (SPINE) switch 150 and the Leaf switch.
  • UPF User Plane Function
  • SPINE backbone
  • DC GW140 can be connected to multiple leaf node (Leaf) switches.
  • Leaf switch is connected to a first Leaf switch 161, a second Leaf switch 162, and a third Leaf switch 163. Each Leaf switch is connected to multiple leaf switches.
  • UPF can be in any form, such as virtual machine (Virtual Manufacturing, VM), bare metal server (Bare Metel, BM) or container (Container, CM), etc.
  • the NFVI system also includes a Mirror Aggregation Switch (MAS) 180.
  • the SDNC 130 generates traffic collection rules after obtaining the orchestration policy, translates the traffic collection rules into commands that can be recognized by switches and routers, and configures them into DC GW140 or MAS180.
  • DC GW140 filters the flows from the VM port according to the traffic collection rules, and the matching flows are prepared to be copied and sent to MAS180, where they are aggregated and redistributed, or passed through the optical splitter on the way to MAS180 and DC GW140. After being collected again, it is sent to the flow analysis device 190.
  • Figure 2 is a flow chart of a configuration method of traffic collection rules provided by an embodiment of the present application.
  • the configuration method of traffic collection rules includes but is not limited to step S110 and step S120.
  • Step S210 Obtain a first message object.
  • the first message object includes at least two source port information.
  • the source port is the port for which traffic collection rules need to be deployed. Traffic is mirrored from the source port according to the traffic collection rules, and the mirrored traffic is output to the traffic analysis device through the destination port.
  • the source port can be a physical server port or a virtual machine. ports, DC GW access ports to the external network, and other ports that can generate data flows.
  • the embodiment of this application does not limit the specific hardware device to which the source port belongs. It is worth noting that the source port information may be the location information or IP address of the source port. The embodiment of the present application does not limit the specific form of the source port information, as long as it can uniquely identify the source port.
  • the first message object can be a mirror source end-point group (TAP Source End-Point-Group, TSG), or other types of message objects. It can record at least two source port information.
  • TSG is used as an example of the first message object, which does not limit the technical solution of this application.
  • SDNC can obtain multiple source port information by parsing TAPflow once.
  • the configuration of TAPflow can obtain the rule configuration instructions for multiple source ports, so that the flow matching rules can be applied to at least two source ports, which can effectively reduce the number of TAPflow configurations and effectively improve the configuration efficiency.
  • due to the reduction of the number of TAPflow configurations it can also reduce the probability of system errors caused by TAPflow configuration errors and improve the stability of the system.
  • TSG can be configured through the GUI of MANO or VIM and sent to SDNC for application.
  • GUI GUI
  • VIM virtual network interface
  • SDNC Secure Digital Network
  • Step S220 Obtain the traffic collection rule corresponding to the first message object, and configure the traffic collection rule to the source port corresponding to each source port information recorded in the first message object.
  • the TSG in order to generate a TAPflow corresponding to a TSG, the TSG can be recorded in it as TAPflow information.
  • the TSG identity ID
  • the SDNC parses the TAPflow, the TSG The ID matches the corresponding TSG, and then at least two source port information is parsed from the TSG, so as to Generate flow matching rules for source ports corresponding to each source port information.
  • SDNC can obtain rule configuration instructions for multiple source ports by parsing one TAPflow, thereby enabling rule configuration instructions to be issued to multiple source ports at the same time and improving source port configuration efficiency.
  • the obtained multiple rule configuration instructions can also be sent in batches, or the source ports with failed configuration can be retransmitted and verified after being issued.
  • those skilled in the art are familiar with how to generate rule configuration instructions in SDNC, and will not go into details here.
  • step S220 shown in Figure 2 also includes but is not limited to the following steps:
  • Step S310 Generate rule configuration instructions belonging to each source port according to the traffic collection rules
  • Step S320 Deploy the rule configuration instructions to the corresponding source port.
  • the SDNC obtains the TAPflow, it obtains the rule configuration instructions that can be recognized and executed by the MAS or DC GW through translation, such as being translated into the Netconf protocol configuration of the switch.
  • This application implements The specific form of the rule configuration instructions is not too limited.
  • TSG and TAPflow can be obtained through VIM, rule configuration instructions can be directly generated through VIM, and flow matching rules can be delivered to Leaf and DC GW. This It is a technology well known to those skilled in the art and will not be described in detail here.
  • step S220 shown in Figure 2 also includes but is not limited to the following steps:
  • Step S410 obtain a second message object.
  • the second message object includes flow matching rules.
  • the flow matching rules are used to match the target data flow from the data flow of the source port;
  • Step S420 obtain a third message object.
  • the third message object includes destination port information.
  • the destination port information belongs to the destination port.
  • the destination port is set to output the traffic collected from the target data flow;
  • Step S430 Obtain traffic collection rules, which include flow matching rules, destination port information, and at least two source port information.
  • the second message object can be a common flow filter (Flowclassifier), and the flow matching rule can be common five-tuple information, or other matching strategies, which can be used to match the data flow from the source port. It suffices to export the target data stream, and this is not limited in the embodiments of this application.
  • Flowclassifier flow filter
  • the flow matching rule can be common five-tuple information, or other matching strategies, which can be used to match the data flow from the source port. It suffices to export the target data stream, and this is not limited in the embodiments of this application.
  • the third message object may be a mirror collection service (TAPservice), and the destination port information recorded in the TAPservice may be the location information of the destination port, such as port name, IP address, etc.
  • TAPservice mirror collection service
  • the embodiment of the present application does not include the destination port information.
  • the specific type is not limited.
  • the orchestration interfaces of TSG, TAPservice and Flowclassifier can be provided by SDNC, and each message object can be configured by VIM or MANO.
  • the embodiment of this application does not specify the order of configuration of the above three message objects. There are many restrictions and can be adjusted according to actual needs. It can be understood that after creating a TAPflow, you can perform a dependency check on the associated TSG, TAPservice, and Flowclassifier. If the associated TSG, TAPservice, and Flowclassifier are all created, you can combine the information of each message object to obtain the TAPflow.
  • the message object If at least one is detected If the message object has not been created, it can be re-checked according to the set waiting mechanism, or alarm information can be generated to ensure that the port configuration can be completed normally.
  • Dependency checking is a technology well known to those skilled in the art, and will not be described in detail here.
  • multiple rule configuration instructions can be obtained through SDNC translation.
  • the location information of source port 1 and source port 2 can be obtained by parsing TSG, and the location of the destination port can be determined by parsing TAPservice. information, obtain the five-tuple information by parsing the Flowclassifier, and synthesize the traffic collection rules, then You can obtain rule configuration instruction 1 and rule configuration instruction 2 through SDNC for traffic collection and translation.
  • Traffic collection rule 1 includes the location information of source port 1, destination port location information and quintuple information
  • traffic collection rule 2 includes the source port. 2 location information, destination port location information and quintuple information.
  • the first message object includes a first message object identifier and a first list.
  • the first list records at least two source port information.
  • the second message object also includes a second message object identifier.
  • the third message object also includes a third message object identifier.
  • step S430 shown in Figure 4 also includes but is not limited to the following steps:
  • Step S510 Obtain a fourth message object.
  • the fourth message object includes a traffic collection rule.
  • the traffic collection rule records a first message object identifier, a second message object identifier, and a third message object identifier.
  • first message object identifier, the second message object identifier and the third message object identifier may be respective IDs, that is, the first message object identifier may be the TSG ID, the second message object identifier may be the Flowclassifier ID, and the third message object identifier may be the Flowclassifier ID.
  • the third message object identifier may be the TAPservice ID, or of course, may also be other identification information, which is not limited in the embodiment of this application.
  • the embodiment of the present application records at least two source port information in the TSG through the first list, which is conducive to simplifying the structure of the message object when the TSG is also configured with a TSG ID. Of course, it can also be recorded in other forms. At least two source port information, which is not limited in the embodiment of this application.
  • TSG, TAPservice and Flowclassifier are not necessarily newly created, but can also be created in advance and saved in the database.
  • the fourth message object is the TAPflow described in the above embodiment. For example, when configuring TAPflow, write the required TSG ID, TAPservice ID and Flowclassifier ID. After SDNC obtains TAPflow, the TSG, TAPservice and Flowclassifier of this deployment strategy are matched by identification. By parsing out the first list, further results can be obtained. At least two source port information to complete subsequent configuration.
  • Example 1 is provided below.
  • the first message object is TSG
  • the second message object is Flowclassifier
  • the third message object is TAPservice
  • the fourth message object is TAPflow.
  • the networking form of the NFVI system is SDN networking
  • the switch or router is a Leaf switch or DC GW as an example.
  • Step S611 configure the Flowclassifier from the GUI of MANO or VIM, where the Flowclassifier ID and five-tuple information are recorded in the Flowclassifier;
  • Step S612 VIM passes Flowclassifier to SDNC;
  • Step S621 configure the TAPservice from the GUI of MANO or VIM, where the TAPservice ID and target port information are recorded in the TAPservice;
  • Step S622 VIM passes the TAPservice to SDNC;
  • Step S631 configure the TSG from the GUI of MANO or VIM, where the TSG includes a TSG ID and a source port list, and the source port list includes location information of at least two source ports;
  • Step S632 VIM transfers the TSG to SDNC
  • Step S641 configure TAPflow from the GUI of MANO or VIM, where TSG ID, TAPservice ID and Flowclassifier ID are recorded in TAPflow;
  • Step S642 VIM passes TAPflow to SDNC
  • Step S643 SDNC parses the TAPflow, obtains the TSG based on the obtained TSG ID, and parses the source port list from the TSG; obtains the TAPservice based on the TAPservice ID, and parses the location information of the destination port from the TAPservice; Obtain the Flowclassifier according to the Flowclassifier ID, and parse the five-tuple information from the Flowclassifier;
  • Step S644 SDNC translates the information obtained in step S643 into rule configuration instructions for each source port, and issues the rule configuration instructions to the GC DW or Leaf switch to configure traffic collection rules for the source port;
  • Step S651 configure the update information of the TSG from the GUI of MANO or VIM, where the update information of the TSG records the location information of the source port for adding or deleting traffic collection rules;
  • Step S652 VIM transfers the TSG update information to SDNC;
  • Step S661 VIM reversely checks the associated TAPflow and Flowclassifier through the TSG ID, triggering the add/deletion process;
  • Step S662 SDNC generates access control technology (Access Control Lists, ACL) policies for the source ports involved in addition/deletion, and delivers them to the corresponding source ports to complete the update of traffic collection rules.
  • ACL Access Control Lists
  • the first message object includes a first message object identifier and a first list.
  • the first list records at least two source port information.
  • Step S220 shown in Figure 2 also includes but is not limited to the following steps: :
  • Step S710 obtain a third message object.
  • the third message object includes destination port information and a third message object identifier.
  • the destination port information belongs to the destination port, and the destination port is set to output the traffic collected from the target data flow;
  • Step S720 obtain a fourth message object.
  • the fourth message object includes a traffic collection rule.
  • the traffic collection rule is encapsulated with five-tuple information.
  • the traffic collection rule also includes a first message object identifier and a third message object identifier.
  • the five-tuple information is Match the target data flow from the data flow of the source port.
  • the embodiment of this application encapsulates the five-tuple information in TAPflow, omitting the Flowclassifier message object, which can reduce the number of message objects and save message object overhead.
  • the content recorded in TAPflow includes quintuple information, TSG ID and TAPservice ID.
  • Example 2 is provided below.
  • the first message object is TSG
  • the third message object is TDG
  • the fourth message object is TAPflow.
  • the networking form of the NFVI system For SDN networking, the switch or router takes a Leaf switch or DC GW as an example. Referring to Figure 8, Example 2 of the embodiment of this application includes but is not limited to the following steps:
  • Step S811 configure the TAPservice from the GUI of MANO or VIM, where the TAPservice ID and target port information are recorded in the TAPservice;
  • Step S812 VIM passes the TAPservice to SDNC;
  • Step S821 configure the TSG from the GUI of MANO or VIM, where the TSG includes a TSG ID and a source port list, and the source port list includes location information of at least two source ports;
  • Step S822 VIM transfers the TSG to SDNC
  • Step S831 configure TAPflow from the GUI of MANO or VIM, where quintuple information is encapsulated in TAPflow, and TSG ID and TAPservice ID are recorded;
  • Step S832 VIM passes TAPflow to SDNC
  • Step S833 SDNC parses the TAPflow, obtains the five-tuple information, TSG ID and TAPservice ID, obtains the TSG based on the obtained TSG ID, and parses the source port list from the TSG; obtains the TAPservice based on the TAPservice ID, and parses the location of the destination port from the TAPservice information;
  • Step S834 SDNC translates the information obtained in step S833 into rule configuration instructions for each source port, and issues the rule configuration instructions to the GC DW or Leaf switch to configure traffic collection rules for the source port;
  • Step S841 configure the update information of the TSG from the GUI of MANO or VIM, where the update information of the TSG records the location information of the source port for adding or deleting traffic collection rules;
  • Step S842 VIM transfers the TSG update information to SDNC;
  • Step S851 VIM checks the associated TAPflow and five-tuple information through the TSG ID to trigger the add/deletion process;
  • Step S852 SDNC generates an ACL policy for the source port involved in addition/deletion, and delivers it to the corresponding source port to complete the update of the traffic collection rules.
  • the third message object further includes a second list, and the second list records at least two destination port information.
  • the group setting of the source port is realized by introducing TSG, and the traffic collection rule can not only be applied to multiple source ports, but also the target traffic collected by the source port can be output to multiple destinations.
  • the Tapservice in the above embodiment can be replaced by the mirroring destination end-point group (TDG) as the third message object, and at least two messages are recorded in the TDG in the form of a second list. Individual destination port information can further improve the configuration efficiency of traffic collection rules.
  • TDG mirroring destination end-point group
  • the second list can be parsed from the TDG to obtain multiple destination port information.
  • the obtained first list records There are at least two source port information. Taking 2 source port information and 2 destination port information as an example, after translating the traffic collection rules, two rule configuration instructions can be obtained. Among them, rule configuration instruction 1 includes the location information of source port 1. , quintuple information and the location information of the 2 destination ports. Rule configuration instruction 2 includes the location information of source port 2, quintuple information and the location information of the 2 destination ports.
  • rule configuration instruction 1 configure the rule After the command is configured to source port 1 through DC GW, the traffic collected from source port 1 based on the five-tuple information is simultaneously output to destination port 1 and destination port 2 to the corresponding traffic analysis device.
  • TDG and TSG can realize batch port configuration of rule configuration instructions, effectively improving the configuration efficiency of rule configuration instructions.
  • Example 3 and Example 4 are provided below.
  • Example 3 In this example, the first message object is TSG, the second message object is Flowclassifier, the third message object is TDG, and the fourth message object is TAPflow.
  • the networking form of the NFVI system is SDN networking, switch or router. Taking a Leaf switch or DC GW as an example, referring to Figure 9, Example 3 of the embodiment of this application includes but is not limited to the following steps:
  • Step S911 configure the Flowclassifier from the GUI of MANO or VIM, where the Flowclassifier ID and five-tuple information are recorded in the Flowclassifier;
  • Step S912 VIM passes Flowclassifier to SDNC;
  • Step S921 configure TDG from the GUI of MANO or VIM, where the TDG ID and target port list are recorded in the TDG, and the target port list records the location information of at least two target ports;
  • Step S922 VIM transfers TDG to SDNC
  • Step S931 configure the TSG from the GUI of MANO or VIM, where the TSG includes a TSG ID and a source port list, and the source port list includes location information of at least two source ports;
  • Step S932 VIM transfers the TSG to SDNC
  • Step S941 Configure TAPflow from the GUI of MANO or VIM, where TSG ID and TDG ID are recorded in TAPflow. and Flowclassifier ID;
  • Step S942 VIM passes TAPflow to SDNC
  • Step S943 SDNC parses the TAPflow, obtains the TSG based on the obtained TSG ID, and parses the source port list from the TSG; obtains the TDG based on the TDG ID, and parses the destination port list from the TDG; obtains the Flowclassifier based on the Flowclassifier ID, and parses the quintuple from the Flowclassifier group information;
  • Step S944 SDNC converts the traffic collection rules into rule configuration instructions for each source port, and issues the rule configuration instructions to the GC DW or Leaf switch to configure traffic collection rules for the source port;
  • Step S951 configure the update information of TDG from the GUI of MANO or VIM, where the location information of the added or deleted destination port is recorded in the update information of TDG;
  • Step S952 VIM transmits the TDG update information to SDNC;
  • Step S961 VIM reversely checks the associated TAPflow and Flowclassifier through the TSG ID, triggering the add/deletion process;
  • Step S962 SDNC completes the update of traffic collection rules for the source port involving the added/deleted destination port
  • Step S971 configure the update information of the TSG from the GUI of MANO or VIM, where the update information of the TSG records the location information of the source port for adding or deleting traffic collection rules;
  • Step S972 VIM transfers the TSG update information to SDNC
  • Step S981 VIM reversely checks the associated TAPflow and Flowclassifier through the TSG ID, triggering the add/deletion process;
  • Step S982 SDNC generates an ACL policy for the source port involved in addition/deletion, and delivers it to the corresponding source port to complete the update of the traffic collection rules.
  • Example 4 the first message object is TSG, the third message object is TDG, and the fourth message object is TAPflow.
  • the networking form of the NFVI system is SDN networking, and the switch or router is a Leaf switch or DC GW.
  • Example 4 of the embodiment of this application includes but is not limited to the following steps:
  • Step S1011 configure TDG from the GUI of MANO or VIM, where the TDG ID and target port list are recorded in the TDG, and the target port list records the location information of at least two target ports;
  • Step S1012 VIM transfers TDG to SDNC
  • Step S1021 configure the TSG from the GUI of MANO or VIM, where the TSG includes a TSG ID and a source port list, and the source port list includes the location information of at least two source ports;
  • Step S1022 VIM transfers the TSG to SDNC
  • Step S1031 configure TAPflow from the GUI of MANO or VIM, where TSG ID, TDG ID and quintuple information are recorded in TAPflow;
  • Step S1032 VIM passes TAPflow to SDNC
  • Step S1033 SDNC parses the TAPflow, parses out the five-tuple information, TSG ID and TAPservice ID from the TAPflow, obtains the TSG based on the obtained TSG ID, and parses the source port list from the TSG; obtains the TDG based on the TDG ID, and parses the destination from the TDG port list;
  • Step S1034 SDNC translates the information obtained in step S1033 into rule configuration instructions for each source port, and issues the rule configuration instructions to the GC DW or Leaf switch to configure traffic collection rules for the source port;
  • Step S1041 configure the update information of TDG from the GUI of MANO or VIM, where the location information of the added or deleted destination port is recorded in the update information of TDG;
  • Step S1042 VIM passes the TDG update information to SDNC;
  • Step S1051 VIM checks the associated TAPflow and five-tuple information through the TSG ID to trigger the add/deletion process;
  • Step S1052 SDNC completes the update of traffic collection rules for the source port involving the added/deleted destination port
  • Step S1061 configure the update information of the TSG from the GUI of MANO or VIM, where the update information of the TSG records the location information of the source port for adding or deleting traffic collection rules;
  • Step S1062 VIM transfers the TSG update information to SDNC;
  • Step S1071 VIM checks the associated TAPflow and five-tuple information through the TSG ID to trigger the add/deletion process;
  • Step S1072 SDNC generates an ACL policy for the source port involved in addition/deletion, and delivers it to the corresponding source port to complete the update of traffic collection rules.
  • step S220 shown in Figure 2 is executed, the following steps are included but are not limited to:
  • Step S1110 obtain the destination port update information, and update the destination port information recorded in the third message object according to the destination port update information;
  • Step S1120 Update the updated destination port information to the source port where traffic collection rules are deployed.
  • the TDG list is omitted or added by mistake.
  • Destination port information another example is that the user adjusts the output port of the collected traffic according to actual needs; another example is that the user increases or decreases the number of destination ports according to actual needs; of course it can also be other destination port information recorded in the TDG that needs to be updated scenario, the embodiments of this application do not limit this
  • the source port update information in the TDG in order to update the destination port information in the TDG, you can configure the source port update information through MANO or VIM.
  • SDNC receives the destination port update information, it can check the associated TAPflow based on the TDG ID of the TDG to which the destination port belongs. , compare the destination port information recorded in the associated TAPflow with the destination port update information, and update the changed destination port information to the source port corresponding to the TAPflow through the configuration instructions of the MAS switch, thereby changing the destination port corresponding to the source port.
  • the port is sufficient.
  • the specific configuration process is a technique well known to those skilled in the art and will not be described in detail here.
  • step S220 shown in Figure 2 is executed, the following steps are included but are not limited to:
  • Step S1210 obtain the source port update information, and update the source port information recorded in the first message object according to the source port update information;
  • Step S1220 Remove the traffic collection rule from the source port corresponding to the deleted source port information in the first message object, and/or deploy the traffic collection rule to the new source port information in the first message object. The corresponding source port.
  • the TSG list is omitted or added by mistake.
  • Source port information for another example, in the scenario of network expansion, new source port information needs to be added to the original TSG; for another example, if the network is scaled down after the peak moment, the source port information needs to be deleted from the original TSG;
  • the embodiment of this application does not limit the scenario of updating the source port information recorded in the TSG.
  • the SDNC receives the source port update information, it can check the associated TAPflow based on the TSG ID of the TSG to which the source port belongs. , according to the comparison between the source port information recorded in the associated TAPflow and the source port information in the source port update information, for the deleted source port, the corresponding traffic collection rules can be deleted by issuing an ACL policy to DC GW. For new For the added source port, rule configuration instructions can be generated according to the principles of the above embodiments and sent to the DC GW to complete the port configuration, which will not be described in detail here.
  • steps S651 to S662 in the example shown in FIG. 6 or refer to steps S841 to S852 in the embodiment shown in FIG. 8 , or refer to the steps shown in FIG. 9
  • steps S971 to S982 of the embodiment shown in FIG. 10 or refer to steps S1061 to S1072 of the embodiment shown in FIG. 10 .
  • NFVI system based on SDN networking.
  • the NFVI system can also be a non-SDN networking.
  • two examples are provided below for illustrative purposes. illustrate:
  • Example 5 the first message object is TSG, the second message object is Flowclassifier, the third message object is TDG, and the fourth message object is TAPflow.
  • the networking form of the NFVI system is non-SDN networking, and the switch or The router takes a Leaf switch or DC GW as an example. Referring to Figure 13, Example 5 of the embodiment of this application includes but is not limited to the following steps:
  • Step S1311 configure the Flowclassifier from the GUI of MANO or VIM, where the Flowclassifier ID and five-tuple information are recorded in the Flowclassifier;
  • Step S1321 configure TDG from the GUI of MANO or VIM, where the TDG ID and target port list are recorded in the TDG, and the target port list records the location information of at least two target ports;
  • Step S1331 configure the TSG from the GUI of MANO or VIM, where the TSG includes a TSG ID and a source port list, and the source port list includes location information of at least two source ports;
  • Step S1341 configure TAPflow from the GUI of MANO or VIM, where TSG ID, TDG ID and Flowclassifier ID are recorded in TAPflow;
  • Step S1342 VIM parses the TAPflow, obtains the TSG based on the obtained TSG ID, and parses the source port list from the TSG; obtains the TDG based on the TDG ID, and parses the destination port list from the TDG; obtains the Flowclassifier based on the Flowclassifier ID, and parses the quintuple from the Flowclassifier Group information, and the above information is generated through the Neutron component to generate rule configuration instructions, and is directly delivered to the Leaf switch or DC GW to complete the source port configuration.
  • Example 6 the first message object is TSG, the third message object is TDG, and the fourth message object is TAPflow.
  • the networking form of the NFVI system is non-SDN networking, and the switch or router is a Leaf switch or DC GW.
  • Example 6 of the embodiment of this application includes but is not limited to the following steps:
  • Step S1411 configure TDG from the GUI of MANO or VIM, where the TDG ID and target port list are recorded in the TDG, and the target port list records the location information of at least two target ports;
  • Step S1421 configure the TSG from the GUI of MANO or VIM, where the TSG includes a TSG ID and a source port list, and the source port list includes the location information of at least two source ports;
  • Step S1431 configure TAPflow from the GUI of MANO or VIM, where TSG ID, TDG ID and quintuple information are recorded in TAPflow;
  • Step S1432 VIM parses TAPflow, obtains the five-tuple information, obtains the TSG based on the obtained TSG ID, and parses the source port list from the TSG; obtains the TDG based on the TDG ID, parses the destination port list from the TDG, and parses the above information
  • the Neutron component generates rule configuration instructions and sends them directly to the Leaf switch or DC GW to complete the source port configuration.
  • the NFVI system 1500 includes: a memory 1510, a processor 1520, and a computer program stored on the memory 1510 and executable on the processor 1520.
  • the processor 1520 and the memory 1510 may be connected through a bus or other means.
  • the non-transitory software programs and instructions required to implement the configuration method of traffic collection rules in the above embodiment are stored in the memory 1510.
  • the configuration method of traffic collection rules in the above embodiment is executed, for example, Execute the above-described method steps S210 to S220 in Figure 2, method steps S310 to S330 in Figure 3, method steps S410 to S430 in Figure 4, method step S510 in Figure 5, and the method in Figure 6 Steps S611 to step S662, method steps S710 to step S720 in Figure 7, method steps S811 to step S852 in Figure 8, method steps S911 to step S982 in Figure 9, method steps S1011 to step S1072 in Figure 10, The method steps S1110 to S1120 in Figure 11, the method steps S1210 to S1220 in Figure 12, the method steps S1311 to S1342 in Figure 13, and the method steps S1411 to S1442 in Figure 14.
  • the device embodiments described above are only illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place, or they may be separated into multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiments of the present application.
  • an embodiment of the present application also provides a computer-readable storage medium that stores computer-executable instructions, and the computer-executable instructions are executed by a processor or controller, for example, by the above-mentioned Execution by a processor in the NFVI system embodiment can cause the processor to execute the configuration method of the traffic collection rules in the above embodiment, for example, execute the above-described method steps S210 to S220 in Figure 2, and steps S220 in Figure 3 Method steps S310 to step S330, method steps S410 to step S430 in Figure 4, method step S510 in Figure 5, method steps S611 to step S662 in Figure 6, method steps S710 to step S720 in Figure 7, Figure 8
  • Embodiments of the present application include: obtaining a first message object, the first message object including at least two source port information; obtaining a traffic collection rule corresponding to the first message object, and configuring the traffic collection rule to the The source port corresponding to each source port information recorded in the first message object.
  • the source ports that need to be deployed with the same traffic collection rules can be recorded in the first message object, and then the traffic collection rules can be configured and deployed for the first message object, so that the traffic collection rules can be deployed at the same time to at least two source ports, which reduces the number of configurations of traffic collection rules, reduces the probability of errors in traffic collection rules, and effectively improves the configuration efficiency of traffic collection rules.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, disk storage or other magnetic storage device, or any other medium that can be used to store the desired information and can be accessed by a computer.
  • 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 may include any information delivery media .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了一种流量采集规则的配置方法及其系统、存储介质，流量采集规则的配置方法包括：获取第一消息对象，所述第一消息对象包括至少两个源端口信息(S210)；获取与所述第一消息对象所对应的流量采集规则，将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口(S220)。

Description

流量采集规则的配置方法及其系统、存储介质
相关申请的交叉引用
本申请基于申请号为202210486173.3、申请日为2022年05月06日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及但不限于数据处理领域，尤其涉及一种流量采集规则的配置方法及其系统、存储介质。
背景技术
网络功能虚拟化基础设施(Network Function Virtualization Infrastructure，NFVI)是一种包含服务器、虚拟化管理程序、操作系统、虚机、虚拟交换机和网络资源的云数据中心，能够利用通用性硬件和虚拟化技术，通过软硬件解耦和功能抽象，减少网络设备功能对专用硬件的依赖，不仅降低了硬件设备的成本，还具有资源灵活共享、新业务的快速开发和部署等优势，被各大运营商广泛使用。
为了满足运营商的流量采集和监控需求，通常会在NFVI系统的交换设备配置流量采集规则，使得交换设备根据流量采集规则从源端口采集流量，再将采集到的流量从目的端口输出至流量分析设备。目前的做法是为每个源端口单独配置一个流量采集规则，在源端口较多的情况下需要耗费大量的时间成本，配置效率较低。
发明内容
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
本申请实施例提供了一种流量采集规则的配置方法及其系统、存储介质。
第一方面，本申请实施例提供了一种流量采集规则的配置方法，包括：获取第一消息对象，所述第一消息对象包括至少两个源端口信息；获取与所述第一消息对象所对应的流量采集规则，将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口。
第二方面，本申请实施例提供了一种NFVI系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面所述的流量采集规则的配置方法。
第三方面，本申请实施例提供了一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如第一方面所述的流量采集规则的配置方法。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本申请技术方案的进一步理解，并且构成说明书的一部分，与本申请的实施例一起用于解释本申请的技术方案，并不构成对本申请技术方案的限制。
图1是本申请一个实施例提供的NFVI系统的框架示意图；
图2是本申请另一个实施例提供的流量采集规则的配置方法的流程图；
图3是本申请另一个实施例提供的生成流量采集规则的流程图；
图4是本申请另一个实施例提供的生成流量采集规则的流程图；
图5是本申请另一个实施例提供的获取第四消息对象的流程图；
图6是本申请另一个实施例提供的示例一的流程图；
图7是本申请另一个实施例提供的生成流量采集规则的流程图；
图8是本申请另一个实施例提供的示例二的流程图；
图9是本申请另一个实施例提供的示例三的流程图；
图10是本申请另一个实施例提供的示例四的流程图；
图11是本申请另一个实施例提供的更新目的端口信息的流程图；
图12是本申请另一个实施例提供的更新源端口的流程图；
图13是本申请另一个实施例提供的示例五的流程图；
图14是本申请另一个实施例提供的示例六的流程图；
图15是本申请另一个实施例提供的NFVI系统的装置图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书、权利要求书或上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
本申请提供了一种流量采集规则的配置方法及其系统、存储介质，流量采集规则的配置方法包括：获取第一消息对象，所述第一消息对象包括至少两个源端口信息；获取与所述第一消息对象所对应的流量采集规则，将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口。根据本申请实施例的技术方案，能够将需要部署相同流量采集规则的源端口记载在第一消息对象中，再针对第一消息对象进行流量采集规则的配置和部署，使得流量采集规则能够同时部署到至少两个源端口，减少了流量采集规则的配置次数，降低了流量采集规则出错的概率，有效提高了流量采集规则的配置效率。
如图1所示，图1是软件定义网络(Software Defined Network，SDN)组网下的NFVI系统架构，在NFVI系统之上还包括NFV管理和编排(Management and Orchestration，MANO)110，MANO110与NFVI系统的虚拟化基础设施管理(Virtualized Infrastructure Manager，VIM)120通信连接，MANO110和VIM120中可以设置图形用户界面(Graphical User Interface，GUI)，通过GUI完成各个消息对象的配置。NFVI系统还包括控制面控制器(SDN controller，SDNC)130，SDNC130与VIM120通信连接，流量采集规则的编排策略可以通过MANO110下发，经过VIM120的传递到达SDNC130。NFVI系统还包括数据中心网关(Data Center Gateway，DC GW)140，DC GW140用于对接外网，DC GW140通过骨干(SPINE)交换机150和Leaf交换机与用户面网元(User Plane Function，UPF)连接，DC GW140可以连接多个叶节点(Leaf)交换机，例如图1中所示，DC GW140连接有第一Leaf交换机161、第二Leaf交换机162和第三Leaf交换机163，每个Leaf交换机连接有多个UPF，UPF可以是任意形式，例如虚机 (Virtual Manufacturing，VM)、裸金属服务器(Bare Metel，BM)或者容器(Container，CM)等。NFVI系统还包括镜像汇聚交换机(Mirror Aggregation Switch，MAS)180，SDNC130在获取到编排策略后生成流量采集规则，将流量采集规则转译为交换机和路由器能够识别的命令，并配置到DC GW140或MAS180中，DC GW140根据流量采集规则从VM的端口的流进行过滤，匹配中的流准备复制后送入MAS180，在该MAS180进行汇聚重分发，或者是在送往MAS180和DC GW140的途中，经过分光器再次采集后，送往流量分析设备190。
需要说明的是，上述NFVI系统的架构是为了便于后续阐述本申请技术原理而提出的一个示例，NFVI系统中每个网元的硬件选取和工作原理为本领域技术人员熟知的技术，本申请并不涉及硬件结构的改进，后续不重复赘述。
以下以图1所示的NFVI系统为例，对本申请各实施例的技术方案进行进一步说明。
如图2所示，图2是本申请一个实施例提供的一种流量采集规则的配置方法的流程图，流量采集规则的配置方法包括但不限于有步骤S110和步骤S120。
步骤S210，获取第一消息对象，第一消息对象包括至少两个源端口信息。
需要说明的是，源端口为需要部署流量采集规则的端口，根据流量采集规则从源端口进行流量镜像，并将镜像流量经过目的端口输出至流量分析设备，源端口可以是物理服务器端口、虚机端口、DC GW接入外网的端口等能够产生数据流的端口，本申请实施例对源端口所归属的具体硬件设备不作限定。值得注意的是，源端口信息可以是源端口的位置信息或者IP地址，本申请实施例对源端口信息的具体形式不作限定，能够唯一标识源端口即可。
值得注意的是，第一消息对象可以是镜像源端点组(TAP Source End-Point-Group，TSG)，也可以是其他类型的消息对象，能够记载至少两个源端口信息即可，为了叙述简便，在本申请后续实施例的叙述过程中以TSG作为第一消息对象的示例，这并不会对本申请的技术方案造成限定。
值得注意的是，在SDN组网的NFVI系统中，需要通过解析流量采集规则(TAPflow)得到源端口信息和流匹配规则，再生成针对源端口的规则配置指令下发至MAS或DC GW完成端口配置，当有N(N≥2)个源端口需要部署流量采集规则，无论各个源端口需要部署的流匹配规则是否相同，均需要配置N个TAPflow，并且重复循环N次消息对象解析和规则配置指令部署，配置效率非常低下；而本申请实施例通过TSG记载多个源端口的源端口信息，并将TSG配置至TAPflow中，SDNC对TAPflow进行一次解析即可得到多个源端口信息，通过一次TAPflow的配置即可得到多个源端口的规则配置指令，使得流匹配规则能够应用到至少两个源端口中，能够有效减少TAPflow的配置次数，有效提高配置效率，并且，由于TAPflow的配置次数减少，还可以降低TAPflow配置错误而导致系统出错的概率，提高了系统的稳定性。
值得注意的是，TSG可以通过MANO或者VIM的GUI进行配置，并下发到SDNC中进行应用，在已知需要记载至少两个源端口信息的前提下，本领域技术人员熟知如何进行消息对象配置，在此不多做赘述。
步骤S220，获取与第一消息对象所对应的流量采集规则，将流量采集规则配置至第一消息对象所记载的各个源端口信息所对应的源端口。
值得注意的是，为了生成与TSG所对应的TAPflow，可以将TSG作为TAPflow的信息记载在其中，例如可以在TAPflow中记载TSG身份标识(Identity，ID)，在SDNC对TAPflow进行解析时，通过TSG ID匹配出对应的TSG，再从TSG中解析出至少两个源端口信息，从而 生成与各个源端口信息所对应的源端口的流匹配规则。
可以理解的是，通过在TAPflow中引入TSG，使得SDNC解析一个TAPflow即可得到多个源端口的规则配置指令，从而实现同时向多个源端口下发规则配置指令，提高源端口的配置效率。当然，若出于NFVI系统的实际并发能力考虑，也可以将得到的多个规则配置指令分批发送，也可以在下发后对配置失败的源端口进行重传校验，在具备记载有TSG的TAPflow的前提下，本领域技术人员熟知如何在SDNC中进行规则配置指令的生成，在此不再赘述。
另外，参照图3，在一实施例中，图2所示的步骤S220还包括但不限于有以下步骤：
步骤S310，根据流量采集规则生成归属于各个源端口的规则配置指令；
步骤S320，将规则配置指令部署至所对应的源端口。
需要说明的是，在SDN组网的NFVI系统中，SDNC获取到TAPflow之后，通过转译得到可被MAS或者DC GW识别和执行的规则配置指令，例如转译成交换机的Netconf协议配置，本申请实施例对规则配置指令的具体形式不作过多限定。当然，本申请实施例的技术方案也可以应用到非SDN组网的NFVI系统，可以通过VIM获取TSG和TAPflow，通过VIM直接生成规则配置指令，将流匹配规则下发到Leaf和DC GW，这是本领域技术人员熟知的技术，在此不多赘述。
另外，参照图4，在一实施例中，图2所示的步骤S220还包括但不限于有以下步骤：
步骤S410，获取第二消息对象，第二消息对象包括流匹配规则，流匹配规则用于从源端口的数据流中匹配出目标数据流；
步骤S420，获取第三消息对象，第三消息对象包括目的端口信息，目的端口信息归属于目的端口，目的端口被设置为输出从目标数据流采集到的流量；
步骤S430，获取流量采集规则，流量采集规则包括流匹配规则、目的端口信息和至少两个源端口信息。
需要说明的是，第二消息对象可以是常见的流过滤器(Flowclassifier)，流匹配规则可以是常见的五元组信息，也可以是其他匹配策略，能够用于从源端口的数据流中匹配出目标数据流即可，本申请实施例对此不多做限定。
需要说明的是，第三消息对象可以是镜像采集服务(TAPservice)，TAPservice中记载的目的端口信息可以是目的端口的位置信息，例如端口名称、IP地址等，本申请实施例对目的端口信息的具体类型不作限定。
需要说明的是，在NFVI系统中，可以由SDNC提供TSG、TAPservice和Flowclassifier的编排接口，由VIM或者MANO进行各个消息对象的配置，本申请实施例对上述3个消息对象的配置先后顺序不作过多限定，根据实际需求调整即可。可以理解的是，创建TAPflow后，可以对关联的TSG、TAPservice和Flowclassifier进行依赖检查，若关联的TSG、TAPservice和Flowclassifier都创建完成，则可以组合各个消息对象的信息得到TAPflow，若检测到至少一个消息对象没有完成创建，可以根据设定好的等待机制进行重新检测，或者生成告警信息，以确保端口配置能够正常完成，依赖检查是本领域技术人员熟知的技术，在此不多做赘述。
需要说明的是，在组合得到流量采集规则之后，可以通过SDNC的转译得到多个规则配置指令，例如，通过解析TSG得到源端口1和源端口2的位置信息，通过解析TAPservice确定目的端口的位置信息，通过解析Flowclassifier得到五元组信息，合成流量采集规则后，则 可以通过SDNC对流量采集转译得到规则配置指令1和规则配置指令2，其中，流量采集规则1包括源端口1的位置信息、目的端口的位置信息和五元组信息，流量采集规则2包括源端口2的位置信息、目的端口的位置信息和五元组信息。
另外，在一实施例中，第一消息对象包括第一消息对象标识和第一列表，第一列表记载有至少两个源端口信息，第二消息对象还包括第二消息对象标识，第三消息对象还包括第三消息对象标识，参照图5，图4所示的步骤S430还包括但不限于有以下步骤：
步骤S510，获取第四消息对象，第四消息对象包括流量采集规则，流量采集规则记载有第一消息对象标识、第二消息对象标识和第三消息对象标识。
需要说明的是，第一消息对象标识、第二消息对象标识和第三消息对象标识可以是各自的ID，即第一消息对象标识可以是TSG ID，第二消息对象标识可以是Flowclassifier ID，第三消息对象标识可以是TAPservice ID，当然，也可以是其他标识信息，本申请实施例对此不多作限定。
需要说明的是，本申请实施例通过第一列表在TSG中记载至少两个源端口信息，有利于在TSG还配置有TSG ID的情况下简化消息对象的结构，当然，也可以通过其他形式记载至少两个源端口信息，本申请实施例对此不多做限定。
需要说明的是，TSG、TAPservice和Flowclassifier并不一定是新创建的，还可以是在先创建并保存在数据库中,根据上述实施例的描述，第四消息对象以上述实施例所述的TAPflow为例，在配置TAPflow时写入需要的TSG ID、TAPservice ID和Flowclassifier ID，在SDNC获取到TAPflow之后通过标识匹配出本次部署策略的TSG、TAPservice和Flowclassifier，通过解析出第一列表可以进一步得出至少两个源端口信息，从而完成后续的配置。
为了更好地阐述本申请实施例的技术方案，以下提出示例一，在本示例中，第一消息对象为TSG，第二消息对象为Flowclassifier，第三消息对象为TAPservice，第四消息对象为TAPflow，NFVI系统的组网形式为SDN组网，交换机或路由器以Leaf交换机或DC GW为例，参照图6，本申请实施例的示例一包括但不限于有以下步骤：
步骤S611，从MANO或VIM的GUI配置Flowclassifier，其中，Flowclassifier中记载有Flowclassifier ID和五元组信息；
步骤S612，VIM将Flowclassifier传递给SDNC；
步骤S621，从MANO或VIM的GUI配置TAPservice，其中，TAPservice中记载有TAPservice ID和目标端口信息；
步骤S622，VIM将TAPservice传递给SDNC；
步骤S631，从MANO或VIM的GUI配置TSG，其中，TSG包括TSG ID和源端口列表，源端口列表包括至少两个源端口的位置信息；
步骤S632，VIM将TSG传递给SDNC；
步骤S641，从MANO或VIM的GUI配置TAPflow，其中，TAPflow中记载有TSG ID、TAPservice ID和Flowclassifier ID；
步骤S642，VIM将TAPflow传递给SDNC；
步骤S643，SDNC解析TAPflow，根据得到的TSG ID获取TSG，并从TSG解析出源端口列表；根据TAPservice ID获取TAPservice，从TAPservice解析出目的端口的位置信息；根 据Flowclassifier ID获取Flowclassifier，从Flowclassifier解析出五元组信息；
步骤S644，SDNC根据步骤S643得到的信息转译为每个源端口的规则配置指令，将规则配置指令下发给GC DW或者Leaf交换机为源端口配置流量采集规则；
步骤S651，从MANO或VIM的GUI配置TSG的更新信息，其中，TSG的更新信息中记载有增加或者删除流量采集规则的源端口的位置信息；
步骤S652，VIM将TSG的更新信息传递给SDNC；
步骤S661，VIM通过TSG ID进行反查关联的TAPflow以及Flowclassifier，触发添加/删除流程；
步骤S662，SDNC针对涉及增加/删除的源端口生成访问控制技术(Access Control Lists，ACL)策略，并下发到对应的源端口完成流量采集规则的更新。
另外，在一实施例中，第一消息对象包括第一消息对象标识和第一列表，第一列表记载有至少两个源端口信息，图2所示的步骤S220还包括但不限于有以下步骤：
步骤S710，获取第三消息对象，第三消息对象包括目的端口信息和第三消息对象标识，目的端口信息归属于目的端口，目的端口被设置为输出从目标数据流采集到的流量；
步骤S720，获取第四消息对象，第四消息对象包括流量采集规则，流量采集规则封装有五元组信息，流量采集规则还包括第一消息对象标识和第三消息对象标识，五元组信息用于从源端口的数据流中匹配出目标数据流。
需要说明的是，与图4和图5所示的实施例不同，本申请实施例将五元组信息封装在TAPflow中，省去了Flowclassifier消息对象，能有减少消息对象数量，节约消息对象开销。可以理解的是，在本申请实施例中，TAPflow记载的内容包括五元组信息、TSG ID和TAPservice ID，通过对TAPflow的解析能够获取到TSG中记载的源端口信息和TAPservice中记载的目的端口信息，从而生成规则配置指令，具体流程和原理与图4和图5所示实施例类似，在此不重复赘述。
为了更好地阐述本申请实施例的技术方案，以下提出示例二，在本示例中，第一消息对象为TSG，第三消息对象为TDG，第四消息对象为TAPflow，NFVI系统的组网形式为SDN组网，交换机或路由器以Leaf交换机或DC GW为例，参照图8，本申请实施例的示例二包括但不限于有以下步骤：
步骤S811，从MANO或VIM的GUI配置TAPservice，其中，TAPservice中记载有TAPservice ID和目标端口信息；
步骤S812，VIM将TAPservice传递给SDNC；
步骤S821，从MANO或VIM的GUI配置TSG，其中，TSG包括TSG ID和源端口列表，源端口列表包括至少两个源端口的位置信息；
步骤S822，VIM将TSG传递给SDNC；
步骤S831，从MANO或VIM的GUI配置TAPflow，其中，TAPflow中封装有五元组信息，并记载有TSG ID和TAPservice ID；
步骤S832，VIM将TAPflow传递给SDNC；
步骤S833，SDNC解析TAPflow，得到五元组信息、TSG ID和TAPservice ID，根据得到的TSG ID获取TSG，并从TSG解析出源端口列表；根据TAPservice ID获取TAPservice，从TAPservice解析出目的端口的位置信息；
步骤S834，SDNC根据步骤S833得到的信息转译为每个源端口的规则配置指令，将规则配置指令下发给GC DW或者Leaf交换机为源端口配置流量采集规则；
步骤S841，从MANO或VIM的GUI配置TSG的更新信息，其中，TSG的更新信息中记载有增加或者删除流量采集规则的源端口的位置信息；
步骤S842，VIM将TSG的更新信息传递给SDNC；
步骤S851，VIM通过TSG ID进行反查关联的TAPflow以及五元组信息，触发添加/删除流程；
步骤S852，SDNC针对涉及增加/删除的源端口生成ACL策略，并下发到对应的源端口完成流量采集规则的更新。
另外，在一实施例中，第三消息对象还包括第二列表，第二列表记载有至少两个目的端口信息。
需要说明的是，在上述实施例中，通过引入TSG实现了源端口的分组设置，而流量采集规则中不仅可以应用于多个源端口，还可以将源端口采集到的目标流量输出至多个目的端口，在这种情况下，可以以镜像目的端点组(TAP Destination End-point-group，TDG)取代上述实施例中的Tapservice作为第三消息对象，在TDG中以第二列表的形式记载至少两个目的端口信息，能够进一步提高流量采集规则的配置效率。
需要说明的是，在以TDG作为第三消息对象的情况下，可以从TDG解析出第二列表，从而得到多个目的端口信息，再结合上述实施例中的叙述，得到的第一列表中记载有至少两个源端口信息，以2个源端口信息和2个目的端口信息为例，对流量采集规则转译后可以得到两个规则配置指令，其中，规则配置指令1包括源端口1的位置信息、五元组信息和2个目的端口的位置信息，规则配置指令2包括源端口2的位置信息、五元组信息和2个目的端口的位置信息，以规则配置指令1为例，将规则配置指令通过DC GW配置到源端口1后，根据五元组信息从源端口1采集到的流量同时目的端口1和目的端口2输出至对应的流量分析设备。通过TDG和TSG能够实现规则配置指令的批量端口配置，有效提高规则配置指令的配置效率。
为了更好地阐述本申请实施例的技术方案，以下提出示例三和示例四。
示例三，在本示例中，第一消息对象为TSG，第二消息对象为Flowclassifier，第三消息对象为TDG，第四消息对象为TAPflow，NFVI系统的组网形式为SDN组网，交换机或路由器以Leaf交换机或DC GW为例，参照图9，本申请实施例的示例三包括但不限于有以下步骤：
步骤S911，从MANO或VIM的GUI配置Flowclassifier，其中，Flowclassifier中记载有Flowclassifier ID和五元组信息；
步骤S912，VIM将Flowclassifier传递给SDNC；
步骤S921，从MANO或VIM的GUI配置TDG，其中，TDG中记载有TDG ID和目标端口列表，目标端口列表中记载有至少两个目标端口的位置信息；
步骤S922，VIM将TDG传递给SDNC；
步骤S931，从MANO或VIM的GUI配置TSG，其中，TSG包括TSG ID和源端口列表，源端口列表包括至少两个源端口的位置信息；
步骤S932，VIM将TSG传递给SDNC；
步骤S941，从MANO或VIM的GUI配置TAPflow，其中，TAPflow中记载有TSG ID、TDG ID 和Flowclassifier ID；
步骤S942，VIM将TAPflow传递给SDNC；
步骤S943，SDNC解析TAPflow，根据得到的TSG ID获取TSG，并从TSG解析出源端口列表；根据TDG ID获取TDG，从TDG解析出目的端口列表；根据Flowclassifier ID获取Flowclassifier，从Flowclassifier解析出五元组信息；
步骤S944，SDNC将流量采集规则转换为每个源端口的规则配置指令，将规则配置指令下发给GC DW或者Leaf交换机为源端口配置流量采集规则；
步骤S951，从MANO或VIM的GUI配置TDG的更新信息，其中，TDG的更新信息中记载有增加或者删除的目的端口的位置信息；
步骤S952，VIM将TDG的更新信息传递给SDNC；
步骤S961，VIM通过TSG ID进行反查关联的TAPflow以及Flowclassifier，触发添加/删除流程；
步骤S962，SDNC针对涉及增加/删除的目的端口的源端口完成流量采集规则的更新；
步骤S971，从MANO或VIM的GUI配置TSG的更新信息，其中，TSG的更新信息中记载有增加或者删除流量采集规则的源端口的位置信息；
步骤S972，VIM将TSG的更新信息传递给SDNC；
步骤S981，VIM通过TSG ID进行反查关联的TAPflow以及Flowclassifier，触发添加/删除流程；
步骤S982，SDNC针对涉及增加/删除的源端口生成ACL策略，并下发到对应的源端口完成流量采集规则的更新。
示例四，在本示例中，第一消息对象为TSG，第三消息对象为TDG，第四消息对象为TAPflow，NFVI系统的组网形式为SDN组网，交换机或路由器以Leaf交换机或DC GW为例，参照图10，本申请实施例的示例四包括但不限于有以下步骤：
步骤S1011，从MANO或VIM的GUI配置TDG，其中，TDG中记载有TDG ID和目标端口列表，目标端口列表中记载有至少两个目标端口的位置信息；
步骤S1012，VIM将TDG传递给SDNC；
步骤S1021，从MANO或VIM的GUI配置TSG，其中，TSG包括TSG ID和源端口列表，源端口列表包括至少两个源端口的位置信息；
步骤S1022，VIM将TSG传递给SDNC；
步骤S1031，从MANO或VIM的GUI配置TAPflow，其中，TAPflow中记载有TSG ID、TDG ID和五元组信息；
步骤S1032，VIM将TAPflow传递给SDNC；
步骤S1033，SDNC解析TAPflow，从TAPflow解析出五元组信息、TSG ID和TAPservice ID，根据得到的TSG ID获取TSG，并从TSG解析出源端口列表；根据TDG ID获取TDG，从TDG解析出目的端口列表；
步骤S1034，SDNC将步骤S1033得到的信息转译为每个源端口的规则配置指令，将规则配置指令下发给GC DW或者Leaf交换机为源端口配置流量采集规则；
步骤S1041，从MANO或VIM的GUI配置TDG的更新信息，其中，TDG的更新信息中记载有增加或者删除的目的端口的位置信息；
步骤S1042，VIM将TDG的更新信息传递给SDNC；
步骤S1051，VIM通过TSG ID进行反查关联的TAPflow以及五元组信息，触发添加/删除流程；
步骤S1052，SDNC针对涉及增加/删除的目的端口的源端口完成流量采集规则的更新；
步骤S1061，从MANO或VIM的GUI配置TSG的更新信息，其中，TSG的更新信息中记载有增加或者删除流量采集规则的源端口的位置信息；
步骤S1062，VIM将TSG的更新信息传递给SDNC；
步骤S1071，VIM通过TSG ID进行反查关联的TAPflow以及五元组信息，触发添加/删除流程；
步骤S1072，SDNC针对涉及增加/删除的源端口生成ACL策略，并下发到对应的源端口完成流量采集规则的更新。
另外，在一实施例中，参照图11，在执行完图2所示的步骤S220之后，还包括但不限于有以下步骤：
步骤S1110，获取目的端口更新信息，根据目的端口更新信息更新第三消息对象所记载的目的端口信息；
步骤S1120，将更新后的目的端口信息更新至部署有流量采集规则的源端口。
需要说明的是，在完成流量采集规则的配置后，在一些场景下还需要对TDG的列表中记载的目的端口信息进行增加或者删除，例如，由于误操作导致TDG的列表中遗漏或者误增加了目的端口信息；又如，用户根据实际需求调整采集到的流量的输出端口；又如，用户根据实际需求增加或者减少目的端口的数量；当然也可以是其他需要更新TDG中所记载的目的端口信息的场景，本申请实施例对此不多做限定
需要说明的是，为了更新TDG中的目的端口信息，可以通过MANO或者VIM配置源端口更新信息，当SDNC收到目的端口更新信息，可以根据目的端口所归属的TDG的TDG ID反查关联的TAPflow，根据关联的TAPflow中记载的目的端口信息和目的端口更新信息进行比对，将发生变更的目的端口信息通过MAS交换机的配置指令更新到TAPflow所对应的源端口，从而变更源端口所对应的目的端口即可，具体配置过程为本领域技术人员熟知的技术，在此不多做赘述。
需要说明的是，针对更新TDG中目的端口信息的示例可以参考图9所示示例的步骤S951至步骤S962，或者，参考图10所示实施例的步骤S1041至步骤S1052。
另外，在一实施例中，参照图12，在执行完图2所示的步骤S220之后，还包括但不限于有以下步骤：
步骤S1210，获取源端口更新信息，根据源端口更新信息更新第一消息对象所记载的源端口信息；
步骤S1220，将流量采集规则从第一消息对象中被删除的源端口信息所对应的源端口中移除，和/或，将流量采集规则部署至第一消息对象中新增的源端口信息所对应的源端口。
需要说明的是，在完成流量采集规则的配置后，在一些场景下还需要对TSG的列表中记载的源端口信息进行增加或者删除，例如，由于误操作导致TSG的列表中遗漏或者误增加了源端口信息；又如，在网络扩容的场景下，需要在原有的TSG中增加新的源端口信息；又如，网络过了峰值时刻进行缩容，需要在原有的TSG中删除源端口信息；当然也可以是其他需要 更新TSG中所记载的源端口信息的场景，本申请实施例对此不多做限定。
需要说明的是，为了更新TSG中的源端口信息，可以通过MANO或者VIM配置源端口更新信息，当SDNC收到源端口更新信息，可以根据源端口所归属的TSG的TSG ID反查关联的TAPflow，根据关联的TAPflow中记载的源端口信息和源端口更新信息中的源端口信息进行比对，对于被删除的源端口，可以通过向DC GW下发ACL策略删除对应的流量采集规则，对于新增的源端口，可以根据上述实施例的原理生成规则配置指令，并下发至DC GW完成端口配置，在此不多做赘述。
需要说明的是，针对更新TSG中源端口信息的示例可以参考图6所示示例的步骤S651至步骤S662，或者，参考图8所示实施例的步骤S841至步骤S852，或者，参考图9所示实施例的步骤S971至步骤S982，或者，参考图10所示实施例的步骤S1061至步骤S1072。
另外，上述实施例均以SDN组网的NFVI系统进行阐述，NFVI系统还可以是非SDN组网，针对本申请实施例的技术方案应用到非SDN组网的场景，以下提出两个示例进行示例性说明：
示例五，在本示例中，第一消息对象为TSG，第二消息对象为Flowclassifier，第三消息对象为TDG，第四消息对象为TAPflow，NFVI系统的组网形式为非SDN组网，交换机或路由器以Leaf交换机或DC GW为例，参照图13，本申请实施例的示例五包括但不限于有以下步骤：
步骤S1311，从MANO或VIM的GUI配置Flowclassifier，其中，Flowclassifier中记载有Flowclassifier ID和五元组信息；
步骤S1321，从MANO或VIM的GUI配置TDG，其中，TDG中记载有TDG ID和目标端口列表，目标端口列表中记载有至少两个目标端口的位置信息；
步骤S1331，从MANO或VIM的GUI配置TSG，其中，TSG包括TSG ID和源端口列表，源端口列表包括至少两个源端口的位置信息；
步骤S1341，从MANO或VIM的GUI配置TAPflow，其中，TAPflow中记载有TSG ID、TDG ID和Flowclassifier ID；
步骤S1342，VIM解析TAPflow，根据得到的TSG ID获取TSG，并从TSG解析出源端口列表；根据TDG ID获取TDG，从TDG解析出目的端口列表；根据Flowclassifier ID获取Flowclassifier，从Flowclassifier解析出五元组信息，并将上述信息通过Neutron组件生成规则配置指令，直接下发到Leaf交换器或者DC GW完成源端口的配置。
示例六，在本示例中，第一消息对象为TSG，第三消息对象为TDG，第四消息对象为TAPflow，NFVI系统的组网形式为非SDN组网，交换机或路由器以Leaf交换机或DC GW为例，参照图14，本申请实施例的示例六包括但不限于有以下步骤：
步骤S1411，从MANO或VIM的GUI配置TDG，其中，TDG中记载有TDG ID和目标端口列表，目标端口列表中记载有至少两个目标端口的位置信息；
步骤S1421，从MANO或VIM的GUI配置TSG，其中，TSG包括TSG ID和源端口列表，源端口列表包括至少两个源端口的位置信息；
步骤S1431，从MANO或VIM的GUI配置TAPflow，其中，TAPflow中记载有TSG ID、TDG ID和五元组信息；
步骤S1432，VIM解析TAPflow，得到五元组信息，根据得到的TSG ID获取TSG，并从TSG解析出源端口列表；根据TDG ID获取TDG，从TDG解析出目的端口列表，并将上述信息 通过Neutron组件生成规则配置指令，直接下发到Leaf交换器或者DC GW完成源端口的配置。
另外，参照图15，本申请的一个实施例还提供了一种NVVI系统，该NFVI系统1500包括：存储器1510、处理器1520及存储在存储器1510上并可在处理器1520上运行的计算机程序。
处理器1520和存储器1510可以通过总线或者其他方式连接。
实现上述实施例的流量采集规则的配置方法所需的非暂态软件程序以及指令存储在存储器1510中，当被处理器1520执行时，执行上述实施例中的流量采集规则的配置方法，例如，执行以上描述的图2中的方法步骤S210至步骤S220、图3中的方法步骤S310至步骤S330、图4中的方法步骤S410至步骤S430、图5中的方法步骤S510、图6中的方法步骤S611至步骤S662、图7中的方法步骤S710至步骤S720，图8中的方法步骤S811至步骤S852、图9中的方法步骤S911至步骤S982、图10中的方法步骤S1011至步骤S1072、图11中的方法步骤S1110至步骤S1120、图12中的方法步骤S1210至步骤S1220、图13中的方法步骤S1311至步骤S1342、图14中的方法步骤S1411至步骤S1442。
以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分别到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请实施例方案的目的。
此外，本申请的一个实施例还提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被一个处理器或控制器执行，例如，被上述NFVI系统实施例中的一个处理器执行，可使得上述处理器执行上述实施例中的流量采集规则的配置方法，例如，执行以上描述的图2中的方法步骤S210至步骤S220、图3中的方法步骤S310至步骤S330、图4中的方法步骤S410至步骤S430、图5中的方法步骤S510、图6中的方法步骤S611至步骤S662、图7中的方法步骤S710至步骤S720，图8中的方法步骤S811至步骤S852、图9中的方法步骤S911至步骤S982、图10中的方法步骤S1011至步骤S1072、图11中的方法步骤S1110至步骤S1120、图12中的方法步骤S1210至步骤S1220、图13中的方法步骤S1311至步骤S1342、图14中的方法步骤S1411至步骤S1442。
本申请实施例包括：获取第一消息对象，所述第一消息对象包括至少两个源端口信息；获取与所述第一消息对象所对应的流量采集规则，将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口。根据本申请实施例的技术方案，能够将需要部署相同流量采集规则的源端口记载在第一消息对象中，再针对第一消息对象进行流量采集规则的配置和部署，使得流量采集规则能够同时部署到至少两个源端口，减少了流量采集规则的配置次数，降低了流量采集规则出错的概率，有效提高了流量采集规则的配置效率。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分别在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、 数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
以上是对本申请的若干实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请本质的前提下还可作出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (10)

  1. 一种流量采集规则的配置方法，包括：
    获取第一消息对象，所述第一消息对象包括至少两个源端口信息；
    获取与所述第一消息对象所对应的流量采集规则，将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口。
  2. 根据权利要求1所述的方法，其中，所述将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口，包括：
    根据所述流量采集规则生成归属于各个所述源端口的规则配置指令；
    将所述规则配置指令部署至所对应的所述源端口。
  3. 根据权利要求1所述的方法，其中，所述获取与所述第一消息对象所对应的流量采集规则，包括：
    获取第二消息对象，所述第二消息对象包括流匹配规则，所述流匹配规则用于从所述源端口的数据流中匹配出目标数据流；
    获取第三消息对象，所述第三消息对象包括目的端口信息，所述目的端口信息归属于目的端口，所述目的端口被设置为输出从所述目标数据流采集到的流量；
    获取所述流量采集规则，所述流量采集规则包括流匹配规则、所述目的端口信息和所述至少两个源端口信息。
  4. 根据权利要求3所述的方法，其中，所述第一消息对象包括第一消息对象标识和第一列表，所述第一列表记载有所述至少两个源端口信息，所述第二消息对象还包括第二消息对象标识，所述第三消息对象还包括第三消息对象标识，所述获取所述流量采集规则，包括：
    获取第四消息对象，所述第四消息对象包括所述流量采集规则，所述流量采集规则记载有所述第一消息对象标识、所述第二消息对象标识和所述第三消息对象标识。
  5. 根据权利要求1所述的方法，其中，所述第一消息对象包括第一消息对象标识和第一列表，所述第一列表记载有所述至少两个源端口信息，所述获取与所述第一消息对象所对应的流量采集规则，包括：
    获取第三消息对象，所述第三消息对象包括目的端口信息和第三消息对象标识，所述目的端口信息归属于目的端口，所述目的端口被设置为输出从目标数据流采集到的流量；
    获取第四消息对象，所述第四消息对象包括所述流量采集规则，所述流量采集规则封装有流匹配规则，所述流量采集规则还包括所述第一消息对象标识和所述第三消息对象标识，所述流匹配规则用于从所述源端口的数据流中匹配出目标数据流。
  6. 根据权利要求3至5任意一项所述的方法，其中：所述第三消息对象还包括第二列表，所述第二列表记载有至少两个目的端口信息。
  7. 根据权利要求6所述的方法，其中，在所述将所述流量采集规则配置至所述第一消息对象所记载的各个源端口信息所对应的源端口之后，所述方法还包括：
    获取目的端口更新信息，根据所述目的端口更新信息更新所述第三消息对象所记载的目的端口信息；
    将更新后的目的端口信息更新至部署有所述流量采集规则的源端口。
  8. 根据权利要求1所述的方法，其中，在所述将所述流量采集规则配置至所述第一消息 对象所记载的各个源端口信息所对应的源端口之后，所述方法还包括：
    获取源端口更新信息，根据所述源端口更新信息更新所述第一消息对象所记载的源端口信息；
    将所述流量采集规则从所述第一消息对象中被删除的源端口信息所对应的源端口中移除，和/或，将所述流量采集规则部署至所述第一消息对象中新增的源端口信息所对应的源端口。
  9. 一种网络功能虚拟化基础设施NFVI系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至8任意一项所述的流量采集规则的配置方法。
  10. 一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令用于执行如权利要求1至8中任意一项所述的流量采集规则的配置方法。
PCT/CN2023/086326 2022-05-06 2023-04-04 流量采集规则的配置方法及其系统、存储介质 Ceased WO2023213164A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210486173.3A CN117061459A (zh) 2022-05-06 2022-05-06 流量采集规则的配置方法及其系统、存储介质
CN202210486173.3 2022-05-06

Publications (1)

Publication Number Publication Date
WO2023213164A1 true WO2023213164A1 (zh) 2023-11-09

Family

ID=88646230

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/086326 Ceased WO2023213164A1 (zh) 2022-05-06 2023-04-04 流量采集规则的配置方法及其系统、存储介质

Country Status (2)

Country Link
CN (1) CN117061459A (zh)
WO (1) WO2023213164A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119882521A (zh) * 2024-12-11 2025-04-25 曙光网络科技有限公司 工业流量的收集方法、装置、计算机设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019072165A1 (zh) * 2017-10-09 2019-04-18 中兴通讯股份有限公司 虚拟化流镜像策略自动化管理方法及设备、存储介质
CN112787949A (zh) * 2020-09-17 2021-05-11 中兴通讯股份有限公司 流量采集和输送管理方法、控制装置及存储介质
CN113518045A (zh) * 2020-04-10 2021-10-19 中国移动通信有限公司研究院 一种流量采集配置方法、流量采集方法及设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019072165A1 (zh) * 2017-10-09 2019-04-18 中兴通讯股份有限公司 虚拟化流镜像策略自动化管理方法及设备、存储介质
CN113518045A (zh) * 2020-04-10 2021-10-19 中国移动通信有限公司研究院 一种流量采集配置方法、流量采集方法及设备
CN112787949A (zh) * 2020-09-17 2021-05-11 中兴通讯股份有限公司 流量采集和输送管理方法、控制装置及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119882521A (zh) * 2024-12-11 2025-04-25 曙光网络科技有限公司 工业流量的收集方法、装置、计算机设备和存储介质

Also Published As

Publication number Publication date
CN117061459A (zh) 2023-11-14

Similar Documents

Publication Publication Date Title
CN114884773B (zh) 用于在覆盖网络中确定数据流路径的系统和方法
US20210152443A1 (en) Technologies for annotating process and user information for network flows
US10911331B2 (en) Service configuration method and apparatus for network service
US10091073B2 (en) Large-scale passive network monitoring using multiple tiers of ordinary network switches
US12411799B2 (en) Transaction based remote direct memory access
WO2017008578A1 (zh) 网络功能虚拟化架构中数据检查的方法和装置
US20230328160A1 (en) Method, device, system, and storage medium for message processing
CN107133231B (zh) 一种数据获取方法和装置
CN110912731A (zh) 基于nfv采用dpi技术实现业务识别和拓扑分析的系统和方法
CN109213566B (zh) 一种虚拟机迁移的方法、装置和设备
CN114513419A (zh) 安全策略配置方法及系统
WO2023213164A1 (zh) 流量采集规则的配置方法及其系统、存储介质
WO2015027401A1 (zh) 报文处理方法、设备及系统
RU2584471C1 (ru) УСТРОЙСТВО ДЛЯ ПРИЕМА И ПЕРЕДАЧИ ДАННЫХ С ВОЗМОЖНОСТЬЮ ОСУЩЕСТВЛЕНИЯ ВЗАИМОДЕЙСТВИЯ С OpenFlow КОНТРОЛЛЕРОМ
US11860724B2 (en) Method and system for facilitating a self-healing network
CN110971540B (zh) 一种数据信息的传输方法、装置、交换机及控制器
CN114095383B (zh) 网络流量采样方法、系统和电子设备
US10693705B2 (en) Show command service aka CLI relay
CN111404712B (zh) 一种nfv网元部署系统、方法、装置、介质和设备
US20260006445A1 (en) Function Orchestration Method, Device and Storage Medium
CN112714017A (zh) 一种配置下发方法及装置
US20230283624A1 (en) Method, apparatus, and system for determining data flow information
WO2024199223A1 (zh) 设备接入位置的获取方法及装置
US10567507B2 (en) Message processing method and apparatus, and message processing system
CN118802563A (zh) 动态网络拓扑发现方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23799151

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23799151

Country of ref document: EP

Kind code of ref document: A1