Cloud flow collection method and device based on SRV6 and readable storage medium
By constructing SRv6 service packets in the cloud for traffic mirroring, the problem of difficult traffic policy switching during cloud host switching is solved, enabling traffic collection in an environment without an SDN controller, reducing costs and ensuring the continuity of collection.
Patent Information
- Application Number
- CN202410876135.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-01
- Publication Date
- 2026-01-06
AI Technical Summary
Existing technologies face difficulties in switching traffic policies when collecting traffic in the cloud and when switching cloud hosts. Furthermore, they cannot collect traffic in network environments without an SDN controller, resulting in the inability to continuously collect traffic.
A cloud traffic collection method based on SRv6 is adopted. By constructing SRv6 service packets containing optical splitting instruction information, and utilizing the programmability of SRv6 to perform traffic mirroring operations on VNF, cloud traffic collection is achieved.
Implementing traffic mirroring in network environments without an SDN controller reduces costs and ensures the continuity and reliability of traffic collection.
Smart Images
Figure CN121283907A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of Internet technology, and in particular to a cloud traffic collection method, apparatus and readable storage medium based on SRV6. Background Technology
[0002] For optical splitting of physical equipment, traffic information is generally collected by optical splitters at the uplink of the physical machine. With the development of science and technology, cloud computing platform servers are becoming larger and larger, network equipment is becoming more and more numerous, and network traffic contains a large amount of important and valuable information.
[0003] Therefore, it is necessary to monitor network traffic so that when network traffic suddenly increases, the device or link experiencing the surge in traffic can be located in a timely manner.
[0004] However, for systems deployed in the cloud, there is a problem that traffic policies are difficult to switch when cloud hosts are switched, resulting in traffic not being able to be continuously collected. Summary of the Invention
[0005] The technical problem to be solved by this application is to address the above-mentioned shortcomings of the prior art by providing a cloud traffic collection method, device and readable storage medium based on SRV6, so as to solve the problems existing in the prior art.
[0006] Firstly, this application provides a cloud traffic collection method based on SRV6, the method being applied to the server side, the method comprising:
[0007] S1. On the i-th VNF, construct an SRv6 service message. The SRv6 service message contains the splitting instruction information corresponding to the i-th VNF. The splitting instruction information contains the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, where i is a positive integer greater than or equal to 1.
[0008] S2. When forwarding SRv6 service packets on the i-th VNF, based on the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, a traffic mirroring operation is performed on the N-th hop where the light needs to be split in order to collect cloud traffic.
[0009] In some embodiments, S1 includes:
[0010] Construct a monitor operation in the segment list of the Nth hop that requires spectral splitting. The monitor operation contains the spectral splitting instruction information corresponding to the i-th VNF, where N is a positive integer greater than or equal to 1.
[0011] The tunnel start address corresponding to the i-th VNF is the loopback address of the i-th leaf corresponding to the i-th VNF;
[0012] The tunnel termination address corresponding to the i-th VNF is the uplink port address of the spine corresponding to the i-th leaf;
[0013] The port corresponding to the i-th VNF that is split is the downlink port of the i-th leaf.
[0014] In some embodiments, in S2, based on the tunnel start address, tunnel end address, and splitting port information corresponding to the i-th VNF, a traffic mirroring operation is performed at the N-th hop where splitting is required, including:
[0015] Traffic is mirrored on the downlink port of the i-th leaf and imported into an SRv6 BE tunnel that starts with the i-th leaf and ends with the uplink port of the spine corresponding to the i-th leaf to achieve traffic mirroring.
[0016] In some embodiments, it also includes:
[0017] S3. In response to detecting that the i-th VNF is unavailable, switch from the i-th VNF to the (i+1)-th VNF that is in an available state.
[0018] In some embodiments, it also includes:
[0019] S4. After switching from the i-th VNF to the (i+1)-th VNF, an SRv6 service message is constructed on the (i+1)-th VNF. The SRv6 service message contains the optical splitting instruction information corresponding to the (i+1)-th VNF. The optical splitting instruction information contains the tunnel start address, tunnel end address, and optical splitting port information corresponding to the (i+1)-th VNF.
[0020] S5. When forwarding SRv6 service packets on the (i+1)th VNF, based on the tunnel start address, tunnel end address and split port information corresponding to the (i+1)th VNF, perform traffic mirroring operation on the Nth hop where splitting is required to collect cloud traffic.
[0021] In some embodiments, S4 includes:
[0022] A monitor operation is constructed in the segment list of the Nth hop that requires spectral splitting. The monitor operation contains the spectral splitting instruction information corresponding to the (i+1)th VNF, wherein:
[0023] The tunnel start address corresponding to the (i+1)th VNF is the loopback address of the (i+1)th leaf corresponding to the (i+1)th VNF;
[0024] The tunnel termination address corresponding to the (i+1)th VNF is the uplink port address of the spine corresponding to the (i+1)th leaf;
[0025] The port corresponding to the (i+1)th VNF that is split is the downlink port of the (i+1)th leaf.
[0026] In some embodiments, in S5, based on the tunnel start address, tunnel end address, and splitting port information corresponding to the (i+1)th VNF, a traffic mirroring operation is performed at the Nth hop where splitting is required, including:
[0027] Traffic is mirrored on the downlink port of the (i+1)th leaf and imported into an SRv6 BE tunnel that starts at the (i+1)th leaf and ends at the uplink port of the spine corresponding to the (i+1)th leaf to achieve traffic mirroring.
[0028] Secondly, this application provides a cloud traffic collection device based on SRV6, the device being applied to a server, the device comprising:
[0029] The message construction module is configured to construct an SRv6 service message on the i-th VNF. The SRv6 service message contains the splitting instruction information corresponding to the i-th VNF. The splitting instruction information contains the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, where i is a positive integer greater than or equal to 1.
[0030] The message forwarding module is configured to perform a traffic mirroring operation at the Nth hop where optical splitting is required, based on the tunnel start address, tunnel end address, and split port information corresponding to the i-th VNF, when forwarding SRv6 service messages on the i-th VNF, in order to collect cloud traffic.
[0031] Thirdly, this application provides a cloud traffic acquisition device based on SRV6, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to implement the cloud traffic acquisition method based on SRV6 described in the first aspect.
[0032] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the SRV6-based cloud traffic collection method described in the first aspect.
[0033] This application provides an SRV6-based cloud traffic acquisition method, apparatus, and readable storage medium. Specifically, on the i-th VNF, an SRv6 service packet is constructed. This SRv6 service packet contains splitting instruction information corresponding to the i-th VNF. The splitting instruction information includes the tunnel start address, tunnel end address, and split port information corresponding to the i-th VNF, where i is a positive integer greater than or equal to 1. When forwarding the SRv6 service packet on the i-th VNF, based on the tunnel start address, tunnel end address, and split port information corresponding to the i-th VNF, a traffic mirroring operation is performed at the N-th hop where splitting is required to acquire cloud traffic. By constructing an SRv6 service packet that instructs on the traffic mirroring operation, this application enables traffic mirroring in a network environment without an SDN controller, thereby achieving cloud traffic acquisition. Compared to existing technologies, this significantly reduces costs because it eliminates the need for an SDN controller. Attached Figure Description
[0034] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.
[0035] Figure 1 This is a schematic diagram of a cloud-based optical splitting architecture in existing technologies;
[0036] Figure 2 A schematic diagram of a cloud traffic collection method based on SRV6 provided in an embodiment of this application;
[0037] Figure 3 A schematic diagram of an SRv6 service message provided in an embodiment of this application;
[0038] Figure 4 Another schematic diagram of the cloud traffic collection method based on SRV6 provided in the embodiments of this application;
[0039] Figure 5 A schematic diagram of the structure of a cloud traffic acquisition device based on SRV6 provided in this application embodiment;
[0040] Figure 6 A schematic diagram of another cloud traffic acquisition device based on SRV6 provided in this application embodiment.
[0041] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation
[0042] To enable those skilled in the art to better understand the technical solution of this application, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.
[0043] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining this application and are not intended to limit this application.
[0044] It is understood that, without conflict, the various embodiments and features in the embodiments of this application can be combined with each other.
[0045] It is understood that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, while parts unrelated to this application are not shown in the drawings.
[0046] It is understood that each unit or module involved in the embodiments of this application may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units or modules may be integrated into one entity structure.
[0047] It is understood that the terms "first," "second," etc., used in the embodiments of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.
[0048] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this application may occur in a different order than those marked in the accompanying drawings.
[0049] It is understood that the flowcharts and block diagrams of this application illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of this application. Each block in a flowchart or block diagram may represent a unit, module, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagrams and flowcharts may be implemented using a hardware-based system to implement the specified function, or using a combination of hardware and computer instructions.
[0050] It is understood that the units and modules involved in the embodiments of this application can be implemented by software or by hardware. For example, the units and modules can be located in the processor.
[0051] For optical splitting of physical devices, traffic information is usually collected through optical splitters at the uplink of the physical device. However, for systems deployed in the cloud, there is a problem that traffic policies are difficult to switch when the cloud host is switched, resulting in traffic not being continuously collected.
[0052] In existing technologies, a traffic mirroring method on a cloud platform can be used to collect full packet data of cloud-native traffic in real time, including all data in the packet header and body. This facilitates the location of the time of a fault or security incident, while also meeting the auditing needs of security departments or security compliance agencies.
[0053] However, the above method has the following problems:
[0054] 1. Inability to achieve accurate traffic collection: The collection methods proposed by existing technologies collect all uplink traffic of cloud hosts. This approach may result in the collection of some unwanted traffic (such as classified traffic), which reduces network security.
[0055] 2. Difficulty in switching traffic policies when cloud hosts fail: When a cloud host fails, the system will switch to another cloud host to ensure business availability. However, traditional traffic collection solutions can only manually migrate the collection policy to the new cloud host's online link. If an SDN (Software-Defined Networking) controller is used, both the cloud host and the uplink routing device must be controlled by the controller, and the two controllers must be able to synchronize information, which limits the scope of this solution.
[0056] Based on the above problems, this invention proposes a cloud traffic collection method based on SRv6, which can solve the problem of difficulty in switching traffic policies when cloud hosts switch over. It proposes a new method to complete traffic collection, realizing the collection of east-west and north-south traffic of cloud hosts without the need for a controller.
[0057] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.
[0058] To improve the utilization of computing and storage resources, all data centers began adopting virtualization technology. A large number of virtual machines (VMs) appeared on the network. At the same time, microservice architecture became popular, and many software programs began to decouple functions, turning a single service into multiple services deployed on different VMs, significantly increasing traffic between VMs.
[0059] Traffic between virtual machines primarily includes east-west traffic and north-south traffic. In network architecture, clients are typically placed at the top and servers at the bottom. On a map, north is at the top and south at the bottom, so traffic from client to server is north-south traffic, i.e., traffic between client and server. Servers, because they belong to the same role, are drawn in the same logical group. On a map, west is on the left and east is on the right. Therefore, within a data center or between data centers, traffic between servers (between peer devices) is east-west traffic, i.e., server-server traffic.
[0060] East-west traffic is essentially a type of "internal traffic." This significant increase in data traffic has caused considerable problems for traditional three-tier architectures—because communication between servers needs to pass through access switches, aggregation switches, and core switches. This means that the workload of core and aggregation switches is constantly increasing. To support large-scale networks, the highest-performance aggregation and core layer devices are required. Such devices are costly and very expensive.
[0061] Based on this, network engineers proposed the "Spine-Leaf network architecture," also known as a leaf-spine network (sometimes called a spine-leaf network). "Spine" refers to the spine, and "leaf" refers to the leaf. Like the fat tree structure, the leaf-spine network architecture belongs to the CLOS network model. Compared to the traditional three-layer architecture of networks, the leaf-spine network is flattened into a two-layer architecture.
[0062] Specifically, a leaf switch is equivalent to an access switch in a traditional Layer 3 architecture, acting as a TOR (Top Of Rack) to directly connect to physical servers. Above the leaf switches is a Layer 3 network, and below are independent L2 broadcast domains. If servers connected to two leaf switches need to communicate, they must be forwarded through a spine switch. A spine switch is equivalent to a core switch. Multiple paths are dynamically selected between leaf and spine switches using ECMP (Equal Cost Multi Path). The number of downlink ports on a spine switch determines the number of leaf switches, while the number of uplink ports on a leaf switch determines the number of spine switches. Together, they determine the size of the leaf-spine network.
[0063] Compared to the traditional three-layer architecture, leaf-spine networks have the following advantages:
[0064] 1. High bandwidth utilization
[0065] The uplink of each leaf switch operates in a load-balanced manner, making full use of the bandwidth.
[0066] 2. Network latency is predictable.
[0067] In the above model, the number of connection paths between leaf switches is determined, and each path only needs to pass through one spine switch, so the east-west network latency is predictable.
[0068] 3. Good scalability
[0069] When bandwidth is insufficient, increasing the number of spine switches can horizontally expand bandwidth. When the number of servers increases, increasing the number of spine switches can also expand the data center's scale. In short, planning and expansion are very convenient.
[0070] 4. Reduce the requirements for the switch
[0071] North-south traffic can exit through leaf nodes or ridge nodes. East-west traffic is distributed across multiple paths. This eliminates the need for expensive, high-performance, high-bandwidth switches.
[0072] 5. High security and availability
[0073] Traditional networks use the STP protocol, which requires reconvergence when a device fails, impacting network performance or even causing a complete breakdown. In a leaf-spine architecture, when a device fails, reconvergence is unnecessary; traffic continues to flow along other normal paths, network connectivity remains unaffected, and bandwidth is reduced only by one path, resulting in a negligible performance impact.
[0074] Figure 1 A schematic diagram of a cloud-based optical splitting architecture in existing technologies, such as... Figure 1 As shown, the architecture mainly includes DC-GW (Data Center-Gateway), acquisition server, Spine, Leaf, virtual switch (vswitch), VNF (Virtual Network Function), GRE (General Routing Encapsulation) tunnel, etc.
[0075] In this context, the DC-GW is typically a router that enables Layer 3 network communication, i.e., cross-VLAN communication. The DC-GW is used to configure a gateway; traffic from a local area network (LAN) is routed to the router gateway to enable outbound traffic.
[0076] Virtual network functions (VNFs) are network functions that operate in a virtual environment. VNFs separate network functions from dedicated hardware, thereby saving potential capital and operating expenses.
[0077] GRE encapsulates data packets from certain network layer protocols (such as IP and IPX), enabling these encapsulated packets to be transmitted over another network layer protocol (such as IP). Furthermore, the GRE protocol can also serve as a Layer 3 tunneling protocol in VPNs, connecting two different networks and providing a transparent channel for data transmission.
[0078] refer to Figure 1 In existing technologies, when collecting cloud traffic, the system (server side) to be split needs to perform port mirroring on the downlink port of the leaf1 node on VNF1, mirroring all uplink traffic on VNF1 to the GRE tunnel. The GRE tunnel terminates between Spine and DC-GW, and at the same time, the link between Spine and DC-GW is split to collect traffic.
[0079] Since the mirroring policy needs to be configured on the leaf, the above process needs to be implemented in a network environment with an SDN controller.
[0080] However, when VNF1 fails, to ensure system availability, the cloud will automatically switch the system to VNF2. This requires revoking the mirroring policy on leaf1 and configuring the same mirroring policy on leaf2. However, this cannot be done in a network environment without an SDN controller. In other words, VNF switching requires the network environment of the switched-off VNF to have an SDN controller.
[0081] Based on this, this application uses SRv6 to construct a monitor operation to indicate tunnel information during the optical splitting process, thereby enabling the collection of east-west and north-south traffic of cloud hosts in the absence of an SDN controller in the network environment.
[0082] It should be noted that all routing nodes in the network of this application support SRv6, and the locator (an IPv6 addressing tool) of the routing node and the correspondence between the locator and the loopback local loopback interface are known.
[0083] Figure 2 A schematic diagram of the cloud traffic collection method based on SRV6 provided in the embodiments of this application is shown below. Figure 2 As shown, this application provides a cloud traffic collection method based on SRV6. The method is applied to the server side and includes S1-S2, as follows:
[0084] S1. On the i-th VNF, construct an SRv6 service message. The SRv6 service message contains the splitting instruction information corresponding to the i-th VNF. The splitting instruction information contains the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, where i is a positive integer greater than or equal to 1.
[0085] In some embodiments, S1 includes: constructing a monitor operation in the segment list of the Nth hop that needs to be split, wherein the monitor operation contains splitting instruction information corresponding to the i-th VNF, and N is a positive integer greater than or equal to 1, wherein: the tunnel start address corresponding to the i-th VNF is the loopback address of the i-th leaf corresponding to the i-th VNF; the tunnel end address corresponding to the i-th VNF is the uplink port address of the spine corresponding to the i-th leaf; and the port to be split corresponding to the i-th VNF is the downlink port of the i-th leaf.
[0086] In this step, SRv6 (Segment Routing IPv6) can be simply explained as SR (Segment Routing) + IPv6. It is a next-generation IP bearer protocol that utilizes existing IPv6 forwarding technology and enables network programmability through flexible IPv6 extension headers. SRv6 simplifies network protocol types, possesses excellent scalability and programmability, can meet the diverse needs of more new services, and provides high reliability.
[0087] Specifically, SR technology segments the path and sorts and combines the paths at the starting node (Segment List) to determine the travel route. SR technology combines segments representing different functions, enabling path programming to meet the service quality requirements of different paths.
[0088] This application utilizes the programmability of SRv6 to define a monitor operation in a function, which can perform traffic mirroring operation after reaching a specified router.
[0089] Specifically, this application constructs SRv6 service packets on the server side (VNF in the diagram) according to the normal forwarding path, and only constructs monitor operations in the segment list of the Nth hop that needs to be split. The tunnel start address is the loopback address of the leaf in the diagram, the tunnel end address is the uplink port address of the spine, and the port to be split is the downlink port of the leaf.
[0090] When N=1, the first hop is from VNF to vswitch; when N=2, the second hop is from vswitch to Leaf, and so on.
[0091] In this application, references Figure 1 In this application, the optical splitting is implemented in the leaf node, so the value of N can be set to 2, that is, the traffic is mirrored on the downlink port of the leaf.
[0092] Figure 3 This is a schematic diagram of an SRv6 service message provided in an embodiment of this application, as shown below. Figure 3 As shown, sourceaddress is the source address of the message (i.e., the server address), destination address is the destination address of the device under test, segment list is the segment list, i.e., an ordered list of segments in the message forwarding path, and payload is the effective payload, i.e., the actual effective business data part contained in the data packet or message.
[0093] The number of entries in the segment list can be customized. A segment list contains two parts: locator and function. The locator defines which device to go to next. During the forwarding process, it will be forwarded in the order from segment[n] to segment[0]. The function defines the action on this router (if there is no special definition, it will be forwarded normally).
[0094] In this application, a monitor operation is defined for a function, and the function field carries three parameters: the tunnel start address (BEB), the tunnel end address (BEE), and the port to which the light is split.
[0095] S2. When forwarding SRv6 service packets on the i-th VNF, based on the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, a traffic mirroring operation is performed on the N-th hop where the light needs to be split in order to collect cloud traffic.
[0096] In some embodiments, in S2, based on the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, a traffic mirroring operation is performed at the N-th hop where the light needs to be split, including: mirroring the traffic at the downlink port of the i-th leaf and importing it into the SRv6 BE tunnel that starts at the i-th leaf and ends at the uplink port of the spine corresponding to the i-th leaf to achieve traffic mirroring.
[0097] Specifically, assuming that traffic mirroring is performed on the Nth hop router, the forwarding of data packets is no different from that of ordinary packets in the first N-1 hops. In the Nth hop, in addition to forwarding, the data packets will also perform a monitor operation, that is, mirror the traffic on the leaf downlink port and import it into the SRv6 BE tunnel that starts with leaf and ends with the spine uplink port, thereby realizing traffic mirroring.
[0098] Figure 4 Another schematic diagram of the cloud traffic collection method based on SRV6 provided in the embodiments of this application is shown below. Figure 4 As shown, in some embodiments, the method further includes: S3, in response to detecting that the i-th VNF is unavailable, switching from the i-th VNF to the (i+1)-th VNF that is in an available state. For example, when VNF1 fails, in order to ensure system availability, the cloud automatically switches the system to VNF2.
[0099] refer to Figure 4 In some embodiments, it also includes:
[0100] S4. After switching from the i-th VNF to the (i+1)-th VNF, an SRv6 service message is constructed on the (i+1)-th VNF. The SRv6 service message contains the optical splitting instruction information corresponding to the (i+1)-th VNF. The optical splitting instruction information contains the tunnel start address, tunnel end address, and optical splitting port information corresponding to the (i+1)-th VNF.
[0101] In some embodiments, S4 includes: constructing a monitor operation in the segment list of the Nth hop that needs to be split, the monitor operation containing splitting instruction information corresponding to the (i+1)th VNF, wherein: the tunnel start address corresponding to the (i+1)th VNF is the loopback address of the (i+1)th leaf corresponding to the (i+1)th VNF; the tunnel end address corresponding to the (i+1)th VNF is the uplink port address of the spine corresponding to the (i+1)th leaf; and the port to be split corresponding to the (i+1)th VNF is the downlink port of the (i+1)th leaf.
[0102] It is understood that the spine corresponding to the (i+1)th leaf and the spine corresponding to the ith leaf can be the same spine or different spines, and this application does not impose any restrictions on this.
[0103] S5. When forwarding SRv6 service packets on the (i+1)th VNF, based on the tunnel start address, tunnel end address and split port information corresponding to the (i+1)th VNF, perform traffic mirroring operation on the Nth hop where splitting is required to collect cloud traffic.
[0104] In some embodiments, in S5, based on the tunnel start address, tunnel end address, and splitting port information corresponding to the (i+1)th VNF, a traffic mirroring operation is performed at the Nth hop where splitting is required, including:
[0105] Traffic is mirrored on the downlink port of the (i+1)th leaf and imported into an SRv6 BE tunnel that starts at the (i+1)th leaf and ends at the uplink port of the spine corresponding to the (i+1)th leaf to achieve traffic mirroring.
[0106] In this application, before VNF switching, the server-side mirroring policy is configured on the i-th leaf (e.g., leaf1), but not on the (i+1)-th leaf (e.g., leaf2). After VNF switching, since the same mirroring policy is not configured on the (i+1)-th leaf (e.g., leaf2), based on the traditional method, the server cannot perform traffic mirroring operations in a network environment without an SDN controller, and therefore cannot perform traffic collection.
[0107] This application constructs an SRv6 service message that instructs on traffic mirroring operations. Specifically, it mirrors traffic on the downlink port of the (i+1)th leaf and imports it into an SRv6 BE tunnel that starts at the (i+1)th leaf and ends at the uplink port of the corresponding spine of the (i+1)th leaf. Therefore, this application enables traffic mirroring in network environments without an SDN controller, thereby achieving cloud traffic collection. Compared to existing technologies, this significantly reduces costs as it eliminates the need for an SDN controller.
[0108] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.
[0109] Figure 5 A schematic diagram of a cloud traffic acquisition device based on SRV6 provided in this application embodiment is shown below. Figure 5 As shown, this application provides a cloud traffic collection device based on SRV6. The device is applied to the server side and includes:
[0110] The message construction module 11 is configured to construct an SRv6 service message on the i-th VNF. The SRv6 service message contains the splitting instruction information corresponding to the i-th VNF. The splitting instruction information contains the tunnel start address, tunnel end address and split port information corresponding to the i-th VNF, where i is a positive integer greater than or equal to 1.
[0111] The message forwarding module 12 is configured to perform a traffic mirroring operation at the Nth hop where the optical splitting is required, based on the tunnel start address, tunnel end address and the optical splitting port information corresponding to the i-th VNF, when forwarding SRv6 service messages on the i-th VNF, in order to collect cloud traffic.
[0112] Regarding the limitations on the SRV6-based cloud traffic acquisition device, please refer to the limitations on the SRV6-based cloud traffic acquisition method in the above embodiments of this application, which will not be repeated here.
[0113] Figure 6 Another schematic diagram of the cloud traffic acquisition device based on SRV6 provided in the embodiments of this application is shown below. Figure 6 As shown, in some embodiments, this application provides a cloud traffic acquisition device based on SRV6, including a memory 22 and a processor 21. The memory stores a computer program, and the processor is configured to run the computer program to execute the cloud traffic acquisition method based on SRV6 in the above embodiments of this application.
[0114] The memory is connected to the processor. The memory can be flash memory, read-only memory or other types of memory. The processor can be a central processing unit or a microcontroller.
[0115] In some embodiments, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the SRV6-based cloud traffic collection method in the above embodiments of this application.
[0116] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.
[0117] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of this application, and this application is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this application, and these modifications and improvements are also considered to be within the scope of protection of this application.
Claims
1. A SRV6-based traffic collection method on a cloud, characterized in that, The method is applied to a server side, and the method comprises: S1, constructing an SRv6 service packet on an i-th VNF, wherein the SRv6 service packet contains light splitting instruction information corresponding to the i-th VNF, the light splitting instruction information contains a tunnel starting address, a tunnel ending address and a split port information corresponding to the i-th VNF, wherein i is a positive integer greater than or equal to 1; S2, when forwarding the SRv6 service packet on the i-th VNF, performing a flow mirroring operation on an N-th hop requiring light splitting according to the tunnel starting address, the tunnel ending address and the split port information corresponding to the i-th VNF to perform cloud flow collection. 2.The SRV6-based traffic collection method on a cloud according to claim 1, wherein, S1, comprising: constructing a monitor operation in a segment list of the N-th hop requiring light splitting, wherein the monitor operation contains light splitting instruction information corresponding to the i-th VNF, and N is a positive integer greater than or equal to 1, wherein: the tunnel starting address corresponding to the i-th VNF is a loopback address of an i-th leaf corresponding to the i-th VNF; the tunnel ending address corresponding to the i-th VNF is an uplink port address of a spine corresponding to the i-th leaf; the split port corresponding to the i-th VNF is a downlink port of the i-th leaf. 3.The SRV6-based traffic collection method on cloud according to claim 2, wherein, In S2, the flow mirroring operation is performed on the N-th hop requiring light splitting according to the tunnel starting address, the tunnel ending address and the split port information corresponding to the i-th VNF, comprising: mirroring the flow on the downlink port of the i-th leaf and importing the flow into an SRv6 BE tunnel starting from the i-th leaf and ending at the uplink port of the spine corresponding to the i-th leaf to realize flow mirroring. 4.The SRV6-based traffic collection method on cloud according to any one of claims 1-3, wherein, Further comprising: S3, switching from the i-th VNF to an i+1-th VNF in an available state in response to detecting that the i-th VNF is unavailable. 5.The SRV6-based traffic collection method on cloud according to claim 4, characterized in that, Further comprising: S4, after switching from the i-th VNF to the i+1-th VNF, constructing an SRv6 service packet on the i+1-th VNF, wherein the SRv6 service packet contains light splitting instruction information corresponding to the i+1-th VNF, and the light splitting instruction information contains a tunnel starting address, a tunnel ending address and a split port information corresponding to the i+1-th VNF; S5, when forwarding the SRv6 service packet on the i+1-th VNF, performing a flow mirroring operation on an N-th hop requiring light splitting according to the tunnel starting address, the tunnel ending address and the split port information corresponding to the i+1-th VNF to perform cloud flow collection. 6.The SRV6-based traffic collection method on a cloud according to claim 5, wherein, S4, comprising: constructing a monitor operation in a segment list of the N-th hop requiring light splitting, wherein the monitor operation contains light splitting instruction information corresponding to the i+1-th VNF, wherein: the tunnel starting address corresponding to the i+1-th VNF is a loopback address of an i+1-th leaf corresponding to the i+1-th VNF; the tunnel ending address corresponding to the i+1-th VNF is an uplink port address of a spine corresponding to the i+1-th leaf; the split port corresponding to the i+1-th VNF is a downlink port of the i+1-th leaf. The split optical port corresponding to the i+1th VNF is a downlink port of the i+1th leaf. 7.The SRV6-based traffic collection method on cloud according to claim 6, characterized in that, In S5, according to the tunnel starting address, the tunnel ending address and the split optical port information corresponding to the i+1th VNF, flow mirroring operation is performed at the Nth hop requiring splitting, including: The downlink port of the i+1th leaf mirrors the flow and is imported into an SRv6 BE tunnel starting from the i+1th leaf and ending at the uplink port of the spine corresponding to the i+1th leaf to realize flow mirroring. 8.A SRV6-based on-cloud traffic collection device, characterized in that, The device is applied to a server end, and the device comprises: A packet construction module is configured to construct an SRv6 service packet on the ith VNF, wherein the SRv6 service packet contains split instruction information corresponding to the ith VNF, and the split instruction information contains a tunnel starting address, a tunnel ending address and split optical port information corresponding to the ith VNF, wherein i is a positive integer greater than or equal to 1. A packet forwarding module is configured to, when forwarding the SRv6 service packet on the ith VNF, perform flow mirroring operation at the Nth hop requiring splitting according to the tunnel starting address, the tunnel ending address and the split optical port information corresponding to the ith VNF to collect flow on the cloud. 9.A SRV6-based on-cloud traffic collection device, characterized in that, The computer readable storage medium stores a computer program, and the processor is configured to execute the computer program to implement the SRV6-based cloud flow collection method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the processor is configured to execute the computer program to implement the SRV6-based cloud flow collection method according to any one of claims 1-7.