Deep packet inspection of network devices

Abstract

Embodiments of the present disclosure relate to deep packet inspection of network devices. Provided herein are load balancing operations between network devices for performing DPI operations. Network devices of a virtualized network device arrangement can load balance network traffic by exchanging data packets for DPI operations over network links between the network devices. Further, the network devices can employ specialized CPUs to offload the DPI operations. In this way, the current technology can enable the preservation of pre-existing networking routes or deterministic routes to be performed on the fly by enabling DPI to be performed without constraining network traffic flows to a specified route.

Description

Background Technology

[0001] This invention generally relates to techniques for performing deep packet inspection. More specifically, this disclosure relates to techniques that enable network devices (e.g., network switches) to load balance network traffic while performing deep packet inspection (DPI).

[0002] This section is intended to introduce the reader to various aspects of the field that may relate to the aspects of the present technology described below and / or claimed. It is believed that this discussion will help provide the reader with background information to facilitate a better understanding of the various aspects of this disclosure. Accordingly, it should be understood that these statements should be read in this context, rather than as an admission of prior art.

[0003] The system may include network devices that enable network traffic to be transmitted between source and endpoint devices. When routing packets, these network devices may perform certain processing operations, such as bandwidth management, security operations, load balancing, and DPI (Deep Packet Inspection). For example, a network device may employ an engine to perform deep packet inspection to analyze the content of the traffic while also load balancing it. While load balancing can make the network more efficient overall in terms of its resource consumption, DPI can handle packets from both directions of traffic (e.g., from and to endpoint devices). Forcing traffic flow through network devices may undermine the benefits of load balancing. Attached Figure Description

[0004] These and other features, aspects, and advantages of this disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings, wherein the same characters throughout the drawings denote the same parts, wherein:

[0005] Figure 1 This is a schematic diagram illustrating a system comprising a first data forwarder having a first deep packet inspection (DPI) engine and a second data forwarder having a second DPI engine, according to various aspects of this disclosure;

[0006] Figure 2 This illustrates various aspects according to this disclosure. Figure 1 A schematic diagram illustrating how the system routes one or more data packets at the first, second, and third time points;

[0007] Figure 3 This illustrates various aspects according to this disclosure. Figure 1 A schematic diagram of the first and second data packet streams within the system;

[0008] Figure 4 This is a flowchart illustrating a process for directing a copy of a data group to a target DPI engine according to various aspects of this disclosure;

[0009] Figure 5 This is a flowchart illustrating a process for routing copies of data packets between data forwarders for DPI according to various aspects of this disclosure;

[0010] Figure 6 This illustrates various aspects according to this disclosure. Figure 4 The flowchart of the process includes a process for stopping the copy of the bootstrap data group based on the target DPI engine becoming unusable; and

[0011] Figure 7 This is a schematic diagram illustrating a computer-readable medium storing computer-readable instructions for DPI boot according to various aspects of this disclosure. Detailed Implementation

[0012] One or more specific embodiments of this disclosure will be described below. To provide a concise description of these embodiments, not all features of an actual implementation may be described in the specification. It should be understood that in the development of any such actual implementation, as in any engineering or design project, multiple implementation-specific decisions must be made to achieve the developer's specific goals, such as conforming to system-related and business-related constraints, which can vary from one implementation to another. Furthermore, it should be understood that such development work may be complex and time-consuming, but will still be a routine task of design, fabrication, and manufacturing for those skilled in the art who benefit from this disclosure.

[0013] When describing elements of various embodiments of this disclosure, the articles “a,” “an,” “the,” and “the” are intended to mean the presence of one or more elements among the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements may be present in addition to the listed elements.

[0014] The system can use network devices (e.g., network switches, data repeaters, network components) to perform deep packet inspection (DPI) on network traffic (e.g., data packets) received at or transmitted from network devices on a communication network. The DPI engine associated with a network device can perform DPI based on the reception of traffic flows in both directions. Sometimes, network traffic from a client device can flow to the server via a first network device, and response traffic from the server can flow to the client device via a second network device, thus preventing DPI from being performed.

[0015] To enable DPI, flow anchoring (e.g., session anchoring) can be used. Flow anchoring forces network traffic flows through specific network devices or specific combinations of network devices to enable DPI in both directions of the flow. However, adopting flow anchoring can be time-consuming and increase computational resource utilization because the system can bypass the advantages of an infrastructure that supports asymmetric traffic forwarding and load balancing.

[0016] Accordingly, this disclosure generally relates to techniques that enable virtualized (e.g., Virtualized Switching Extensions (VSX)) network device arrangements to freely load balance network traffic while performing DPI. For example, a virtualized network device arrangement may include multiple network devices that operate as a single network device and / or may be configured with an active-standby setup (e.g., a network device performs a task while other network devices are idle). More specifically, this disclosure relates to deterministically routing network packet flows between electronic devices across virtualized network device arrangements to provide load balancing. In practice, network devices in a virtualized network device arrangement can load balance network traffic. By employing network links (e.g., dedicated channels, intra-switch links) between network devices, network devices can exchange data packets and perform DPI while maintaining network routing or deterministic network routing operations, allowing DPI to occur without constraining network traffic flows to a specified route.

[0017] For detailed explanation, the system may include one or more network switches as network devices, such as a first network switch and a second network switch. It should be noted that the techniques described herein with respect to the first network switch are merely exemplary and the same techniques described herein can be implemented by the second network switch or any other suitable network switch included in the system. The first network switch may be coupled to the second network switch via a network link (e.g., a dedicated channel enabled via a communication link) to enable a virtualized (e.g., VSX) switch pair. The virtualized switch pair may be presented as a cluster of network switches (e.g., a single virtual switch). Furthermore, the network link may be used to transmit replicated packets from network traffic flows to enable DPI.

[0018] For example, the first network switch can determine that DPI will be performed and can generate copies of data packets. The first network switch can determine whether to send copies of data packets to a remote DPI engine (via a network link) or a local DPI engine based on one or more bootstrap features (e.g., one or more DPI bootstrap features). The first network switch can determine the bootstrap features based on symmetric hashing, policy lookup table functionality, or any other suitable load balancing mechanism.

[0019] In some systems, network devices may lack the computational resources to support a DPI engine. Therefore, the system can utilize an offloaded DPI engine at a network device located at the network's aggregation layer (e.g., a network switch). For example, the network device can use a dedicated central processing unit (CPU) that includes the corresponding DPI engine (e.g., on its associated local CPU or a remote CPU of a separate network device) to perform DPI.

[0020] The corresponding bootstrapping engine can perform complementary routing so that network traffic in both directions can reach the same target DPI engine. In this way, the system can enable DPI operation without constraining routing within the network device layout, which can increase the availability of computing resources and system efficiency.

[0021] With this in mind, Figure 1 This is a schematic diagram illustrating a system 10 including a first data forwarder 12 having a first DPI engine 14 and a second data forwarder 16 having a second DPI engine 18, according to various aspects of this disclosure. The first data forwarder 12 and the second data forwarder 16 can receive and route (e.g., direct or select paths for) network traffic such as data packets between a first electronic device 20 and a second electronic device 22. For example, the first data forwarder 12 and the second data forwarder 16 can include or correspond to any suitable network device or network component, such as a network switch. Furthermore, it should be noted that although in Figure 1 The first data forwarder 12 and the second data forwarder 16 are shown, but the system 10 may include any appropriate number of data forwarders with corresponding DPI engines to perform the techniques described herein.

[0022] One or more devices shown in System 10 (e.g., first data repeater 12, second data repeater 16, first electronic device 20, second electronic device 22) may include or may be any suitable computing device that can utilize data storage devices and / or memory. Such computing devices may include servers, desktop computers, laptop computers, tablet computers, cellular devices, wearable devices, and / or other computing devices. The first CPU 26 and / or the second CPU 30 may be housed in a dedicated computing device (not depicted) and therefore may have access to a storage device / memory separate from the storage device / memory of the one or more devices. In some cases, CPUs (e.g., first CPU 26, second CPU 30) are included in data repeaters (e.g., first CPU 26 in first data repeater 12, second CPU 30 in second data repeater 16) to extend the processing power of the respective data repeater and thus have access to the storage device / memory of that respective data repeater. The storage device / memory may include any suitable article of manufacture suitable for storing data and / or executable instructions. For example, the storage device / memory may include instructions that enable DPI execution when executed by the processing circuitry of the first CPU 26. The storage device / memory may include storage devices such as non-volatile memory fast (NVMe) devices, hard disk drives (HDDs), solid-state drives (SSDs), optical drives, another type of storage device, flash memory, read-only memory (ROM), or any combination thereof. The storage device / memory may include memory that can include any suitable memory device, such as dual data rate type 5 (DDR5) synchronous dynamic random access memory (SDRAM), dual data rate type 4 (DDR4) SDRAM, low power dual data rate (LPDDR) SDRAM, another suitable type of memory device, or any combination thereof.

[0023] First data repeater 12 and second data repeater 16 can be coupled via a dedicated channel 24. For example, dedicated channel 24 can operate based on a communication link 25 (e.g., an intralink within a switch). Communication link 25 can be a hardware-based physical or wireless communication coupling between one or more data repeaters, enabling mutual communication and exchange of data between the one or more data repeaters. For example, data received via communication link 25 can bypass one or more security authentication operations, or other processing operations, to enable more efficient mutual communication between the respective data repeaters, consuming fewer computational resources and / or experiencing reduced latency in such communication. Dedicated channel 24 operating based on communication link 25 can correspond to a higher computational level than the physical layer (e.g., Layer 1 of the Open Systems Interconnection (OSI) model or other similar networking communication models) that communication link 25 may be associated with. For example, dedicated channel 24 can correspond to communication operations occurring at the data link layer (e.g., Layer 2 of the OSI model) and / or the network layer (e.g., Layer 3 of the OSI model). Communication via dedicated channel 24 can involve processing and data packetization operations occurring at layers above the physical layer.

[0024] As another example, the dedicated channel 24 can operate using protocols such as Virtual Extensible Local Area Network (VxLAN) or Layer 2 Generic Routing Encapsulation (L2GRE). VxLAN and L2GRE protocols enable the encapsulation of network traffic at the data link layer and the transport of the encapsulated network above the physical layer. The dedicated channel 24 allows the first data forwarder 12 and the second data forwarder 16 to employ a dedicated Internet Protocol (IP) address space on internal processes used for packet transmission (e.g., using computing resources within the environment of system 10, without involving external systems). In effect, the first data forwarder 12 and the second data forwarder 16 can use the dedicated channel 24 to transmit copies of data packets to each other for each other at the DPI.

[0025] Furthermore, dedicated channel 24 enables the first data forwarder 12 and the second data forwarder 16 to operate as a virtualization pair (e.g., a virtualized (e.g., VSX) switch pair (e.g., a network switch cluster)). For example, a virtualization pair may include multiple data forwarders that operate as a single data forwarder and / or may be configured with an active-standby setup (e.g., a data forwarder performs a task while other data forwarders are idle). In this way, the first data forwarder 12 and the second data forwarder 16 can operate (e.g., function) as a single virtual forwarder (e.g., a single virtual network device) within a virtualized environment. For example, dedicated channel 24 enables the first data forwarder 12 and the second data forwarder 16 to perform features such as load balancing while presenting a unified interface for the first electronic device 20 and the second electronic device 22.

[0026] The first data forwarder 12 can be communicatively coupled to a first CPU 26, which includes a first DPI engine 14 and a first boot engine 28. Further, the second data forwarder 16 can be communicatively coupled to a second CPU 30, which includes a second DPI engine 18 and a second boot engine 32. It should be noted that the first DPI engine 14 can be integrated into the first data forwarder 12 as hardware (e.g., a hardware component) or software (e.g., embedded in a software application). Additionally, it should be noted that the second DPI engine 18 can be integrated into the second data forwarder 16 as hardware or software. In some systems, the first data forwarder 12 may include the first CPU 26. In some systems, the second data forwarder 16 may include the second CPU 30. In some systems, the first data forwarder 12 may be decoupled from the first CPU 26. Therefore, the first data forwarder 12 can be coupled to the first CPU 26, enabling the first CPU 26 to operate as a dedicated processing circuitry device for the first data forwarder 12. Furthermore, in some systems, the second data forwarder 16 can be decoupled from the second CPU 30. Therefore, the second data forwarder 16 can be coupled to the second CPU 30, enabling the second CPU 30 to operate as a dedicated processing circuitry device for the second data forwarder 16. The first data forwarder 12 can employ a first DPI engine 14 to perform DPI on one or more data packets received at the first data forwarder 12 (e.g., from the first electronic device 20 and / or the second electronic device 22). Additionally, the second data forwarder 16 can employ a second DPI engine 18 to perform DPI on one or more data packets received at the second data forwarder 16 (e.g., from the first electronic device 20 and / or the second electronic device 22). The first CPU 26 and the second CPU 30 can enable the offloading of DPI operations from the first data forwarder 12 and the second data forwarder 16, which can hopefully allow a relatively larger amount of computing resources to be used by other operations of the first data forwarder 12 and / or the second data forwarder 16. The first CPU 26 and the second CPU 30 enable the first data forwarder 12 and / or the second data forwarder 16 to offload DPI operations by transferring DPI operations (such as tasks that inspect and analyze one or more data packets) to each other.For example, the first CPU 26 may be coupled to the first data forwarder 12, such that the first CPU 26 performs computational tasks associated with DPI operations (e.g., inspection, analysis) in response to instructions received from the first data forwarder 12 and / or in response to one or more data packets received from the first data forwarder 12 or the second data forwarder 16, independent of instructions from the respective data forwarder (e.g., the first CPU 26 may be programmed to automatically perform DPI via the DPI engine in response to receiving a copy of one or more data packets from either data forwarder, without further enabling instructions). The second CPU 30 may provide similar offloading and DPI startup as described in the example with respect to the first CPU 26.

[0027] As an example, the first data forwarder 12 and / or the second data forwarder 16 may determine that DPI will be performed based on characteristic data such as flow missing (e.g., the received data packet does not match an existing entry) in the flow table lookup and / or flow attributes of the data packet indicating that DPI is in progress. The first DPI engine 14 and / or the second DPI engine 18 may perform DPI based on the reception of the traffic flow in both directions (e.g., the flow from the first electronic device 20 to the second electronic device 22 and the flow from the second electronic device 22 to the first electronic device 20).

[0028] Therefore, the first data repeater 12 may employ a first bootstrapping engine 28 and / or the second data repeater 16 may employ a second bootstrapping engine 32 to enable the reception of traffic flows in both directions. For example, the first bootstrapping engine 28 may include software executed by the first data repeater 12 to identify (e.g., determine) the target DPI engine (e.g., the first DPI engine 14 or the second DPI engine 18) for the DPI of the received data packets. Further, the second bootstrapping engine 32 may include software executed by the second data repeater 16 to identify the target DPI engine for the received data packets.

[0029] As an example, the first data forwarder 12 and the second data forwarder 16 may store one or more policies, one or more predetermined rules, and / or instructions for real-time data analysis. These instructions can provide directives on what actions the first data forwarder 12 and the second data forwarder 16 will take based on a set of conditions. In practice, for example, the first data forwarder 12 and the second data forwarder 16 may include policies, which may be a set of rules (e.g., defined rules) or guidelines defining how the first data forwarder 12 and the second data forwarder 16 can operate and / or perform certain behaviors for guiding data packets. For example, the first bootstrapping engine 28 and / or the second bootstrapping engine 32 may access the policy instructions and operate according to those instructions to bootstrap copies of data packets to the target DPI engine.

[0030] The first bootstrap engine 28 and the second bootstrap engine 32 can identify the target DPI engine based on symmetric hashing, a policy table lookup function, or another suitable load distribution mechanism. In this way, the first data forwarder 12 can determine whether to transmit a copy of one or more received data packets to a first CPU 26 (e.g., a local CPU coupled thereto) having the first DPI engine 14 to perform DPI. Alternatively, the first data forwarder 12 can determine whether to transmit a copy of one or more data packets to a second CPU 30 (e.g., a remote CPU) having the second DPI engine 18 via a dedicated channel 24 to perform DPI. It should be noted that the second data forwarder 16 or any other suitable data forwarder included in system 10 can perform the operations described herein with respect to the first data forwarder 12. Reference will be made below. Figures 2 to 4 To describe additional details about the engine that identifies the target DPI.

[0031] In practice, as will be described in further detail below, the first data forwarder 12 and the second data forwarder 16 can transmit copies of corresponding data packets via dedicated channel 24 to enable DPI. Specifically, the first data forwarder 12 can transmit one or more received data packets to the second data forwarder 16 via dedicated channel 24 for DPI. The second data forwarder 16 can also transmit one or more received data packets to the first data forwarder 12 via dedicated channel 24 for DPI. Thus, the first data forwarder 12 and the second data forwarder 16 can use dedicated channel 24 to deterministically route copies of network traffic for DPI. Furthermore, the first data forwarder 12 and / or the second data forwarder 16 can load balance network traffic and offload DPI operations to reduce the utilization of computing resources and minimize overload on the first CPU 26 and the second CPU 30.

[0032] Figure 2 This illustrates various aspects according to this disclosure. Figure 1 A schematic diagram of system 10 routing network services such as one or more data packets at first time 50, second time 52, and third time 54. In practice, as... Figure 2As shown, system 10 can adjust the routing of one or more data packets between first electronic device 20 and second electronic device 22 at different times. System 10 can do this as part of deterministic network routing, such as load balancing operations that change the routing of network traffic through network components in response to changes in source devices, endpoint devices, bandwidth usage, security changes, etc. Deterministic network routing can be performed in one or both directions of network traffic. When the routing of network traffic is changed, the path taken by data forwarders such as data forwarder 12 and / or data forwarder 16 can change over time. By using the system and method described herein, deterministic network routing that changes the routing of network traffic can be performed without affecting the DPI, because copies of network traffic packets can be routed to the device hosting the DPI, regardless of the literal path routed through the device.

[0033] In the example shown, data forwarder 16 hosts DPI. That is, data forwarder 16 performs DPI and / or is coupled to a DPI engine that performs DPI via providing data packets from data forwarder 16. The systems and methods described herein can enable data forwarder 16 to be provided with two-way copies of network traffic for DPI. It should be understood that data forwarder 12 and / or data forwarder 16 can perform DPI at different times. Data forwarder 12 and data forwarder 16 can alternatively perform DPI for subsequent packets of network traffic. For example, in a corresponding network traffic, a first packet may be followed by a second packet, and then a third packet. First data forwarder 12 can perform DPI for the first and third packets, but not for the second packet. Second data forwarder 16 can perform DPI for the second packet but not for the first and third packets. Bootstrap engine 28 and / or bootstrap engine 32 can route copies of packets locally or remotely in response to processing of packet header data, as described herein. Figure 3 As described in detail.

[0034] For example, at a first time 50, the first electronic device 20 may generate a first network service (e.g., a forward flow, uplink network service, client-to-server network service) and transmit the first network service to a first data repeater 12 for transmission to the second electronic device 22 in a first direction 56a. Additionally, the second electronic device 22 may generate a second network service (e.g., a reverse flow, downlink network service, server-to-client network service) in response to receiving the first network service. The second data repeater 16 may transmit the second network service to a second data repeater 16 for transmission to the first electronic device 20 in a second direction 58a. As described herein, the first and second network services are used for illustrative purposes, and it should be understood that both the first and second network services may be associated with the same or different communications or exchanges.

[0035] The first data forwarder 12 can receive a first network service and determine that a Direct PI (DPI) will be performed on the first network service. For example, the first data forwarder 12 can determine that a DPI will be performed based on a flow table lookup for a missing flow or the flow attributes of a first data packet indicating that a DPI is in progress. Figure 2 As shown, the first data forwarder 12 can host DPIs for both the first and second network services. Therefore, the second data forwarder 16 can generate a copy of the second network service and route that copy to the first data forwarder 12 for the DPI via dedicated channel 24. For example, see below for reference... Figure 3 As described in further detail, the second data repeater 16 can determine the bootstrap characteristics of the second network service to... Figure 1 The first DPI engine 14 is identified as the target DPI engine. In this way, the second data forwarder 16, which acts as a DPI host (e.g., the target DPI engine), can perform DPI on both the first direction 56a of the first network service and the second direction 58a of the second network service.

[0036] In practice, the DPI host can perform DPI based on the received replicated data of both the first direction 56a of the first network service and the second direction 58a of the second network service replica. In this way, the first direction 56a of the first network service and the second direction 58a replica of the second network service can be transmitted to the same DPI engine of the DPI host. Furthermore, a symmetric value associated with the first direction 56a of the first network service and the second direction 58b of the second network service can be used to identify the first data forwarder 12 or the second data forwarder 16 assigned to the first network service and the second network service.

[0037] As another example, at a second time 52, the first electronic device 20 may transmit a first network service to a first data repeater 12 for transmission to the second electronic device 22 in a first direction 56b. Additionally, the second electronic device 22 may transmit a second network service to the first data repeater 12 for transmission to the first electronic device 20 in a second direction 58b (e.g., in response to receiving the first network service). The first data repeater 12 may receive the first and second network services and determine whether to perform a Directional Interaction (DPI) on the first and second network services.

[0038] At the second time point, the second data forwarder 16 can host the DPI for the first network service and the second network service. Therefore, the first data forwarder 12 can generate a first copy of the first network service and a second copy of the second network service. The first data forwarder 12 can route the first and second copies to the second data forwarder 16 via dedicated channel 24. The second data forwarder 16 can perform the DPI on both the first direction 56b of the first copy of the first network service and the second direction 58b of the second copy of the second network service.

[0039] As another example, at a third time 54, the first electronic device 20 may transmit a first network service to a second data repeater 16 for transmission to the second electronic device 22 in a first direction 56c. Additionally, the second electronic device 22 may transmit a second network service to the second data repeater 16 for transmission to the first electronic device 20 in a second direction 58c (e.g., in response to receiving the first network service). The second data repeater 16 may receive the first and second network services and determine whether to perform a DPI (Distributed Processing Interaction) on the first and second network services.

[0040] Thus, the second data forwarder 16 can generate a first copy of the first network service and a second copy of the second network service. Because the second data forwarder 16 is a host DPI, it can provide the first and second copies to the second DPI engine 18 (e.g., the associated DPI engine of its own second CPU 30) to perform DPI. The second data forwarder 16 can perform DPI based on the first copy of the first direction 56c of the first network service and the second copy of the second direction 58c of the second network service. It should be noted that this document regarding... Figure 2 The described technique is merely exemplary and the same technique can be performed via any appropriate number of data forwarders and various different routes. For example, the first data forwarder 12 can be a host DPI and receive copies of the first network traffic and the second network traffic in both directions.

[0041] Considering the foregoing, Figure 3This illustrates various aspects according to this disclosure. Figure 1 A schematic diagram of the first data packet stream 70 and the second data packet stream 72 within system 10. As described herein, system 10 may include any suitable data forwarder (e.g., first data forwarder 12, second data forwarder 16) to route data between the first electronic device 20 and the second electronic device 22. For example, system 10 may include a first network switch 74 and a second network switch 76, which may be presented as a network switch cluster 78 (e.g., a single virtual switch). It should be noted that the first network switch 74 and the second network switch 76 may include those described herein. Figure 1 The first data repeater 12 and the second data repeater 16 may contain any appropriate components (e.g., software and / or hardware) and functions as described.

[0042] In practice, the first network switch 74 can use the first CPU 26 with the first DPI engine 14 and the first boot engine 28. Additionally, the second network switch 76 can use the second CPU 30 with the second DPI engine 18 and the second boot engine 32. For the first data packet stream 70, the first electronic device 20 can generate the first data packet and transmit it to the second network switch 76 for transmission to the second electronic device 22. As an example, the first data packet may include a 5-tuple comprising a source Internet Protocol (IP) address (src.ip) (e.g., the sender's), a destination IP address (dst.ip) (e.g., the receiver's), a source port (src.l4port), a destination port (dst.l4port), and an IP protocol (ip.protocol) (e.g., the protocol type used for communication). Further, the first data packet structure may include a header (e.g., which may include a 5-tuple) and a payload.

[0043] The second network switch 76 can receive the first data packet and determine whether to perform DPI on the first data packet. The second network switch 76 can determine whether DPI is being performed based on flow table lookups (e.g., missing flow, service type, policy, predefined software rules or instructions), or analysis of the first data packet flow 70 (e.g., flow attributes indicating DPI is in progress). As an example, the second network switch 76 can check its flow table (e.g., stored at the second network switch 76) to determine if existing entries in the flow table match the characteristics of the first data packet. For example, characteristics may include the contents of the packet header (e.g., a 5-tuple) of the first data packet. If the second network switch 76 does not find a matching entry, it can determine that the first data packet flow 70 (e.g., the first data packet) does not belong to an established (e.g., known) flow. Therefore, the second network switch 76 can determine to perform DPI on the first data packet (e.g., to enable checks on the header and payload of the first data packet). As another example, the service type can indicate whether the first data packet is associated with a Virtual Local Area Network (VLAN), a port, or a role that has been established (e.g., set up) by System 10 for DPI.

[0044] To prevent network traffic interruption, the second network switch 76 can generate a copy of the first data packet 84 for the DPI. The first data packet stream 70 can flow uninterruptedly through input ports and output ports, enabling system 10 to maintain network performance and / or deterministic routing from load balancing algorithms. The second network switch 76 can employ a second bootstrapping engine 32 to determine the bootstrapping characteristics 80 of the first data packet (e.g., DPI bootstrapping characteristics). Bootstrapping characteristics can be associated with a target DPI engine (e.g., first DPI engine 14 or second DPI engine 18). For example, the first bootstrapping characteristic can be associated with first DPI engine 14 and the second bootstrapping characteristic can be associated with second DPI engine 18. To identify the bootstrapping characteristics, the second network switch 76 can employ the second bootstrapping engine 32 to determine a symmetric hash value (e.g., receive-side scaling (RSS) symmetric hash value) associated with the first data packet. As an example, the symmetric hash value can be used as an index for a bootstrapping policy indicating which network switch will host the DPI for the associated packet.

[0045] The second network switch 76 can employ the second bootstrap engine 32 to apply a hash function to the content of the first data packet, such as the packet header (e.g., including a 5-tuple containing the source IP address, destination IP address, source port, destination port, and IP protocol), to obtain (e.g., generate, provide) a symmetric hash value. The same symmetric hash value for both forward / uplink (e.g., source to destination) and backward / downlink (e.g., destination to source) packet transmissions can be used as an index for determining DPI policy allocation. For example, the symmetric hash value can include a mask on the last bit (e.g., the last bit value) of the symmetric hash value. The mask on the last bit of the symmetric hash value can include 1, which may be associated with a first bootstrap feature, or 0, which may be associated with a second bootstrap feature. In this way, the second bootstrap engine 32 enables the second network switch 76 to identify whether the symmetric hash value includes the first feature or the second feature based on the last bit. Furthermore, the second bootstrap engine 32 can bootstrap a copy of the first data packet 84 to the first DPI engine 14 or the second DPI engine 18 based on whether the symmetric hash value includes the first feature or the second feature. Sometimes, the second bootstrap engine 32 can extract metadata from the first data block and generate a hash based on that metadata. The second bootstrap engine can determine the bootstrap characteristics based on the hash. The bootstrap characteristics can be adjusted when additional bootstrap engines are available. For example, when two DPI engines are available, a single bit can be used to determine the target DPI engine, one indicated by "0" and the other by "1". However, when four DPI engines are available, the bootstrap characteristics can be adjusted to the last two bits of a symmetric hash, such that each of the four DPI engines can be represented, one by "00", the second by "01", the third by "10", and the fourth by "11".

[0046] As an example, the second boot engine 32 can perform a corresponding policy lookup 82 (e.g., a policy lookup function) in a corresponding policy lookup table (e.g., stored at the second network switch 76) based on a symmetric hash value. For example, the last bit of the symmetric hash value can correspond to a target value associated with a target DPI engine in the corresponding policy lookup table. The corresponding policy lookup table can indicate that for entries with a symmetric hash value ending in 1 (e.g., a target value of 1), the first network switch 74 and / or the second network switch 76 can be configured to mirror data packets to a remote mirroring session via dedicated channel 24. The corresponding policy lookup table can also indicate that for entries with a symmetric hash value ending in 0 (e.g., a target value of 0), data packets can be transmitted to a local CPU (e.g., a dedicated local CPU associated with the first network switch 74 or the second network switch 76). As an example, a last bit of 1 can be associated with an even-numbered session and a last bit of 0 can be associated with an odd-numbered session.

[0047] exist Figure 3 In the example shown, the second bootstrap engine 32 can perform a symmetric hash on the first data packet and determine that the last bit of the symmetric hash value is 1. Therefore, the second bootstrap engine 32 can determine that the bootstrap characteristic 80 of the first data packet is a first bootstrap characteristic associated with the first network switch 74, thereby indicating that the first network switch 74 is assigned the host DPI to the associated data packet. Therefore, the second network switch 76 can be configured to mirror the first data packet to a remote mirroring session via a dedicated channel 24. That is, the second network switch 76 can identify the first DPI engine 14 of the first network switch 74 as the target DPI engine for performing DPI on the first data packet. Therefore, the second network switch 76 can transmit a copy of the first data packet 84 to the first DPI engine 14 of the first network switch 74 via the dedicated channel 24. As another example, the second bootstrap engine 32 can identify a match between the bootstrap characteristic and a value in the flow lookup table of the second network switch 76 and identify the target DPI engine associated with the value in the flow lookup table as the target DPI engine.

[0048] As described herein, performing DPI can involve both directions of network traffic transmitted between the first electronic device 20 and the second electronic device 22. Therefore, in Figure 3In the example shown, the second electronic device 22 can generate a second data packet stream 72 based on the first data packet stream 70. The second electronic device 22 can transmit the second data packets of the second data packet stream 72 to a first network switch 74 for transmission to the first electronic device 20. The first network switch 74 can determine that a Direct PI (DPI) will be performed on the second data packets. Furthermore, the first network switch 74 can generate a copy of the second data packets for the DPI (e.g., based on stream missing or attributes indicating that a DPI is in progress).

[0049] The first network switch 74 may employ the first boot engine 28 to determine the boot characteristics 86 (e.g., DPI boot characteristics) of the second data packet. It should be noted that the first boot engine 28 may determine the boot characteristics 86 in a manner similar to that described above with respect to the second boot engine 32. For example, the first boot engine 28 may also perform a symmetric hash of the second data packet and employ a corresponding policy lookup 88 in a corresponding policy lookup table (e.g., stored at the first network switch 74). The corresponding policy lookup table may indicate that for entries with a symmetric hash value ending in 1, the data packet can be transmitted to the local CPU. For some packets, the corresponding policy lookup table may also indicate that for entries with a symmetric hash value ending in 0, the network switch can be configured to mirror the data packet to a remote mirroring session via dedicated channel 24.

[0050] It should be noted that the index provided by executing a symmetric hash function can be the same for the first and second data packets, even if the header values ​​of the first and second data packets are reversed. For example, even if the source address, destination address, source port, and destination port in each data packet are reversed, the symmetric hash value of the first data packet will be the same as the symmetric hash value of the second data packet. Furthermore, it should be noted that due to the order of the data packets and the indication from the result of the symmetric hash, similar routing may occur if an additional network switch receives and processes data packets from the first data packet stream 70 and / or the second data packet stream 72. Additionally, it should be noted that the symmetric hash values ​​for the first data packet (e.g., an uplink data packet) and the second data packet (e.g., a downlink data packet) can be common hash values.

[0051] In this way, symmetrically hashing the first and second data packets ensures that the target DPI engine (e.g., the first DPI engine 14) can perform DPI. That is, the bootstrap characteristic 80 of the first data packet can be symmetrical (e.g., common) with the bootstrap characteristic 86 of the second data packet. Accordingly, the first bootstrap engine 28 can bootstrap a copy of the first data packet and the second bootstrap engine 32 can bootstrap a copy of the second data packet to the same target DPI, thereby enabling DPI in both directions of network traffic flows (e.g., the first data packet flow 70 and the second data packet flow 72).

[0052] exist Figure 3 In the example shown, the first bootstrap engine 28 can perform a symmetric hash on the second data packet and determine that the last bit of the symmetric hash value is also 1. Therefore, the first bootstrap engine 28 can identify the first DPI engine 14 (e.g., its own associated local CPU) as the target DPI engine for performing DPI on the second data packet. Therefore, the first network switch 74 can generate a copy of the second data packet 90 to provide a copy of the second data packet to the first DPI engine 14.

[0053] It should be noted that, sometimes, instead of symmetric hashing, the first bootstrap engine 28 and the second bootstrap engine 32 can load balance network traffic based on a per-client basis (e.g., IP address), a per-VLAN basis, or a per-virtual route and forward (VRF) basis. Alternatively, the first bootstrap engine 28 and the second bootstrap engine 32 can perform policy lookups based on the distribution properties of the first and second data packets (e.g., instead of symmetric hash values).

[0054] Additionally or alternatively, the first network switch 74 and the second network switch 76 may use dedicated channel 24 to synchronize flow attributes. For example, the second DPI engine 18 may perform DPI on one or more data packets and identify attributes associated with one or more data packets. A policy lookup table may indicate that an application associated with one or more data packets (e.g., based on flow attribute identification) is blocked. Therefore, the first network switch 74 and / or the second network switch 76 may drop one or more data packets associated with that application to enable blocking of that application.

[0055] However, in order for the first network switch 74 to identify that an application is blocked, the second network switch 76 can synchronize flow attributes with the first network switch 74 via dedicated channel 24. That is, the second network switch 76 can provide information in a policy lookup table indicating that the application is blocked to enable synchronization between the first network switch 74 and the second network switch 76. It should be noted that the first network switch 74 and the second network switch 76 can perform flow attribute synchronization continuously (e.g., on an ongoing basis, periodically, at regular intervals).

[0056] It should be noted that this article is about Figure 3 The described technology can continue to be used for any number of data packets received and transmitted by the first electronic device 20 and the second electronic device 22. However, when the first network switch 74 and / or the second network switch 76 analyze the characteristics of the first data packet stream 70 and the second data packet stream 72, the first network switch 74 and / or the second network switch 76 can determine that enough data packets have been examined to gather sufficient information. That is, the first network switch 74 and / or the second network switch 76 can have sufficient information regarding monitoring, security, and / or policy enforcement. Therefore, the first network switch 74 and / or the second network switch 76 can determine that additional data packets are no longer useful (e.g., not being used). Therefore, the first network switch 74 and / or the second network switch 76 can stop routing any additional data packets to the target DPI engine in response to identifying that the additional data packets are no longer useful. It should also be noted that although the example shown provides network switches (e.g., the first network switch 74 and the second network switch 76), any suitable data forwarding components can be adopted in conjunction with the current technology.

[0057] Furthermore, as will be referred to below. Figure 6 As described in further detail, if the first network switch 74 or the second network switch 76 suspends operation, another network switch can detect the suspended operation. Furthermore, the network switch that is not suspended (e.g., the first network switch 74 or the second network switch 76) can suspend a policy that causes the first and second data packets to be routed to (e.g., the active DPI engine of the non-suspended switch). For example, if the first network switch 74 suspends operation, the second network switch 76 can detect the suspended operation. The second network switch 76 can then suspend a policy that causes both the first and second data packets to be routed to its second DPI engine 18.

[0058] To describe the boot process in detail Figure 4This is a flowchart illustrating a process 110 for routing copies of data packets to a target DPI engine according to various aspects of the present invention. As described herein, a first data forwarder 12 (e.g., or a first network switch 74) and / or a second data forwarder 16 (e.g., or a second network switch 76) may route corresponding copies of data packets to the target DPI engine. Therefore, it should be noted that the first data forwarder 12 and / or the second data forwarder 16 may each perform the process 110 described herein.

[0059] Process 110 begins by receiving a data packet (box 112) from a data source (e.g., at the first data repeater 12 or the second data repeater 16) for transmission to the data destination. For example, the data source could be a first electronic device 20 or a second electronic device 22. The data packet could be a corresponding packet for network traffic. As another example, the data packet could be associated with a request to an initiating application (e.g., a software application) and / or a request to access a database to read or write database-related data. The data packet can be received at an incoming port (e.g., at the first data repeater 12 or the second data repeater 16).

[0060] Determine whether to perform DPI on the data packet (box 114). This determination may be based on a flow missing in a flow table lookup or on flow attributes, service types, and / or policies indicating that DPI is in progress. A flow missing may occur when a flow table lookup is performed (e.g., by a first data forwarder 12 or a second data forwarder 16 that received the data packet) and the data packet does not match a flow entry in the flow table during the lookup. Flow attributes indicating that DPI is in progress may be associated with a flag or marker in a flow entry in the flow table that indicates that DPI is currently being used to inspect the data packet or data packet flow. Further, the service type may indicate that the data packet is associated with a part or role set by the system 10 for DPI (e.g., in one or more policies).

[0061] In response to determining that DPI should be performed on a data packet, a copy of the data packet is generated (Box 116). In this way, network traffic flows (e.g., including data packets) can continue uninterrupted. For example, network traffic flows can continue initiated routes without interruption. In effect, the original data packet can be forwarded (e.g., policy-based) while a copy of the data packet is retained for the DPI. In this way, network traffic flows can continue while DPI is performed on the copy of the data packet. Further, DPI bootstrapping characteristics of the data packet are determined (Box 118). DPI bootstrapping characteristics can be determined based on a symmetric hash value identifying the data packet, using policy lookup table functionality, on a per-client basis, a per-VLAN basis, a per-VRF basis, and / or any other appropriate load balancing mechanism. A per-client basis can be associated with a specific client (e.g., user, device, and / or endpoint). A per-VLAN basis can be associated with the VLAN to which the network service belongs. A per-VRF basis can be associated with an isolation routing table that allows multiple virtual networks to coexist on the same physical infrastructure. Therefore, the policy lookup table function can be applied independently on each virtual network within the VRF.

[0062] For example, a symmetric hash value may include the last bit of a 0 that can be associated with a first bootstrap feature, or the last bit of a 1 that can be associated with a second bootstrap feature. Furthermore, the first bootstrap feature may be associated with a first DPI engine (e.g., a DPI engine local to the first data forwarding component and remote from the second data forwarding component), and the second bootstrap feature may be associated with a second DPI engine (e.g., a DPI engine local to the second data forwarding component and remote from the first data forwarding component).

[0063] Therefore, after determining the bootstrap feature, the target DPI engine for performing the DPI is identified from among multiple DPI engines (box 120). For example, the bootstrap feature can be determined to be a first bootstrap feature. Therefore, the first DPI engine 14 can be determined to be the target DPI engine. As another example, the bootstrap feature can be determined to be a second bootstrap feature. Thus, the second DPI engine 18 can be determined to be the target DPI engine.

[0064] A copy of the data packet is routed to the target DPI engine (box 122). When a copy of the data packet is to be routed to a DPI engine local to the bootstrap engine that received the data packet, the data packet may be routed to the DPI engine via a local connection (e.g., a dedicated channel to the local DPI engine that enables data packet transport). When a copy of the data packet is to be routed to a DPI engine remote from the bootstrap engine that received the data packet, the data packet may be routed to the target DPI engine via dedicated channel 24. In this way, the target DPI engine can perform DPI on the copy of the data packet. For example, the target DPI engine can analyze the contents of the data packet, such as the header, to examine the data packet. By analyzing the contents, for example, which application is being requested for the connection in the data packet can be determined.

[0065] Furthermore, data packets can be sent to the data destination (box 124). For example, data packets can be sent to the data destination via an incoming port (e.g., the incoming port of the first data repeater 12 or the second data repeater 16). Sending data packets to the data destination can occur at a time frame that at least partially overlaps with the execution of DPI (e.g., by the target DPI engine). In some cases, data packets are held until DPI is complete, and at this point, data packets are sent to the data destination.

[0066] As an example, Figure 4 The operation can be implemented in a system with one or more forwarding devices (e.g., network switches). Figure 5 The operation of two data repeater devices (e.g., first data repeater 12 and second data repeater 16) is shown to transmit copies of data packets to each other for DPI.

[0067] Figure 5 This is a flowchart illustrating a process 140 for a first data forwarder 12 to route a copy of a first set of data packets to a second data forwarder 16 for DPI (Data Point Instructions for Import), and for the second data forwarder 16 to route a copy of a second set of data packets to the first data forwarder 12 for DPI. As described herein, the first data forwarder 12 may include a first DPI engine 14 to perform DPI on one or more data packets received at the first data forwarder 12. Additionally, the second data forwarder 16 may include a second DPI engine 18 to perform DPI on one or more data packets received at the second data forwarder 16. The first data forwarder 12 and the second data forwarder 16 are used herein for illustrative purposes, and it should be understood that similar operations may be performed by one or more other network devices as described herein.

[0068] First data repeater 12 receives a first set of packets (e.g., a first set of one or more packets) (box 142). For example, first data repeater 12 can receive packets from... Figure 1 The first electronic device 20 receives the first packet set. The first data repeater 12 can receive the first packet set at its input port.

[0069] In addition, the second data repeater 16 receives a second set of packets (box 144). For example, the second data repeater 16 can receive packets from... Figure 1 The second electronic device 22 receives the second packet set. The second data repeater 16 can receive the second packet set at its input port.

[0070] First data forwarder 12 identifies a first characteristic associated with the first packet set (box 146). For example, first data forwarder 12 can perform a symmetric hash of each packet in the first packet set by hashing the packet header data from each packet in the first packet set to identify a symmetric hash value. The packet header may include the source IP address, destination IP address, source port, destination port, and IP protocol (e.g., a 5-tuple) of the first packet set. As an example, the symmetric hash value may include the last bit of a 0 or the last bit of a 1. Further, the symmetric hash value may be identified as a first characteristic. First data forwarder 12 may use the last bit of the symmetric hash value (e.g., at box 150) as the first characteristic to determine whether to retain a copy of the data packet or to send a copy of the data packet to second data forwarder 16.

[0071] Furthermore, the second data forwarder 16 identifies a second characteristic associated with the set of packets in the second data set (box 148). For example, the second data forwarder 16 can perform a symmetric hash of each data packet in the second data packet set by hashing the data in the packet header of each data packet in the second data packet set to identify a symmetric hash value. The symmetric hash value can be identified as a second characteristic. The second data forwarder 16 can use the last bit of the symmetric hash value (e.g., at box 154) as the second characteristic to determine whether to retain a copy of the data packet or to send a copy of the data packet to the first data forwarder 12.

[0072] For detailed description, the first data forwarder 12 and the second data forwarder 16 can determine whether to retain a copy of the data packets or to transmit them to another data forwarder based on one or more policy indications. The first data forwarder 12 can reference policy indications (e.g., software-based rules or instructions) that cause it to route a copy of the first set of data packets having a first characteristic to the second DPI engine 18. Additionally, the second data forwarder 16 references policy indications that cause it to route a copy of the second set of data packets having a second characteristic to the first engine.

[0073] Therefore, the first data forwarder 12 transmits a copy of the first packet set to the second data forwarder 16 or retains that copy (e.g., via dedicated channel 24) based on a first characteristic (box 150). For example, the first characteristic may be associated with a first DPI engine 14 of the first data forwarder 12 (e.g., its own DPI engine) or a second DPI engine 18 of the second data forwarder 16 (e.g., a remote DPI engine). If the first characteristic is associated with the first DPI engine 14, the first data forwarder 12 can retrain the first packet set. If the first characteristic is associated with the second DPI engine 18, the first data forwarder 12 can transmit a copy of the first packet set to the second data forwarder 16. The first data forwarder 12 may transmit a copy of the first data packet set via a remote mirroring channel established over dedicated channel 24. Dedicated channel 24 may operate based on switch intralink 25. Dedicated channel 24 can provide a dedicated IP address space over internal processes for packet transmission.

[0074] The second data forwarder 16 performs DPI based on a copy of the first packet set (box 152). The second data forwarder 16 can perform DPI by analyzing the contents of the first data packet set. The second data forwarder 16 can analyze the data and header contents of the first data packet set to identify information associated with the first data packet set. For example, this information may include application type, protocol, and / or security rules.

[0075] The second data repeater 16 transmits a copy of the second packet set to the first data repeater 12 or retains that copy (e.g., via dedicated channel 24) based on a second characteristic (box 154). For example, the second characteristic may be associated with a first DPI engine 14 of the first data repeater 12 or a second DPI engine 18 of the second data repeater 16. The second data repeater 16 may transmit a copy of the second packet set via a remote mirroring channel established over dedicated channel 24.

[0076] Accordingly, the first data forwarder 12 performs DPI based on the second data packet set (box 156). For example, the first data forwarder 12 may perform DPI on reserved DPI packets and / or DPI packets received from other data forwarders. The first data forwarder 12 may perform DPI based on analyzing the contents of the second data packet set. The first data forwarder 12 may analyze the data and header contents of the second data packet set to identify information associated with the second data packet set. For example, this information may include application type, protocol, and / or security rules.

[0077] Sometimes, the target DPI engine may become unavailable. For example, the target network data forwarder, including the target DPI engine, may suspend operation, crash (e.g., experience a failure or error), and / or suffer a power outage. When this occurs, for example, the first boot engine 28 or the second boot engine 32 may stop booting copies of data packets to the first DPI engine 14 or the second DPI engine 18. In light of the foregoing, Figure 6 It shows Figure 4 The document includes a flowchart of process 110 for a process 170 to stop booting copies of data packets based on a target DPI engine becoming unavailable. For discussion purposes, the first data forwarder 12 may correspond to the local data forwarder 172, and the second data forwarder 16 may correspond to the target data forwarder 174. The local data forwarder 172 may be located remotely from the target data forwarder 174 and may communicate via a dedicated channel 24.

[0078] The target DPI engine (e.g., the second DPI engine 18) of the target data forwarder 174 becomes unavailable (box 176). As described herein, the target data forwarder 174 may suspend the operation of the target DPI engine, crash, and / or lose power.

[0079] Subsequently, the local data forwarder 172 detects that the target DPI engine is unavailable (box 178). For example, the local data forwarder 172 may receive periodic health indicators (e.g., heartbeat signals, ping responses, status updates) from the target DPI engine indicating that the target DPI engine is operational. However, if the local data forwarder 172 does not receive any indication within a threshold time period, the local data forwarder 172 may determine that the target DPI engine is unavailable. As another example, the local data forwarder 172 may periodically query the target DPI engine to check whether the target DPI engine is available.

[0080] In response to determining that the target DPI engine is unavailable, local data forwarder 172 stops routing copies of data packets to the target DPI engine (box 180). For example, local data forwarder 172 may terminate (e.g., end) a remote mirroring session performed via dedicated channel 24. Thus, local data forwarder 172 may redirect copies of data packets for DPI performance.

[0081] Local data forwarder 172 routes copies of data packets to the local DPI engine (e.g., associated with local data forwarder 172) (box 182). As an example, local data forwarder 172 may adjust policy actions for a first routing characteristic (e.g., associated with even-numbered session streams) and a second routing characteristic (e.g., associated with odd-numbered session streams) of data sent to a local CPU (e.g., associated with local data forwarder) that includes the local DPI engine.

[0082] Thus, the local data forwarder 172 receives result data from the local DPI engine (box 184). For example, the result data may include result DPI analysis data associated with copies of data packets, such as application type, protocol, and / or security rules. The local data forwarder 172 may perform computational operations based on the result data, such as permitting network traffic flows to continue routing, generating reports based on or including some or all of the result data, and / or transmitting reports to another computing device to trigger operations performed by that computing device. The DPI analysis data may enable the local data forwarder 172 or downstream computing devices to perform network management operations, which may include permitting or denying access to communication networks connected between network devices, etc.

[0083] When the target data forwarder 174 becomes available (box 188), the local data forwarder 172 determines that the target DPI engine is available again (box 186). For example, the local data forwarder 172 may receive an indication from the target data forwarder 174 that the target data forwarder 174 is available again. As another example, the local data forwarder 172 may provide the target data forwarder 174 with information associated with stream attributes to enable stream attribute synchronization. Therefore, the local data forwarder 172 may determine that the target data forwarder 174 is available based on its ability to provide this information.

[0084] At box 190, local data forwarder 172 and target data forwarder 174 are synchronized to the current state of the DPI. That is, the current state of the flow of local data forwarder 172 is synchronized with that of target data forwarder 174. Flow balancing can be initiated by synchronizing the current states of the flows of local data forwarder 172 and target data forwarder 174. The synchronized current state of the DPI can be a subset of the data packets assigned to the target DPI engine of target data forwarder 174, as indicated by a first bootstrap feature, a second bootstrap feature, and / or a pre-shutdown policy (e.g., a policy before target data forwarder 174 becomes unavailable).

[0085] The target data forwarder 174 operates the Multi-Rack Link Aggregation Group (MCLAG) in an unblocking state (box 192). The MCLAG may include ports terminated on individual racks. The MCLAG can perform load balancing between its ports, such as between devices coupled to the respective ports. In practice, when the target data forwarder 174 becomes unavailable (box 176), it operates the MCLAG in a blocking state to disable active links with the target data forwarder 174, such as dedicated channel 24. Once the target data forwarder 174 becomes available again, it can re-establish its connection and rejoin the MCLAG, allowing the link to transition to an unblocking state. In this way, communication on the network remains stable and efficient even during switch failures or unavailability.

[0086] Accordingly, local data forwarder 172 and target data forwarder 174 resume routing copies of data packets to the target DPI engine (box 194). For example, local data forwarder 172 and target data forwarder 174 may employ a pre-shutdown strategy to route copies of data packets to the target DPI engine. In this way, the target DPI engine can resume DPI, wherein the target DPI engine can be determined based on the symmetric hash operation described herein.

[0087] Considering the foregoing, Figure 7A schematic diagram of a computer-readable medium 210 is shown in accordance with various aspects of this disclosure. This computer-readable medium 210 stores instructions that cause system 10 to direct copies of data packets to a target DPI engine. System 10 described herein can be any suitable computing device, such as a network device, WLAN controller, desktop computer, laptop computer, server, web server, mainframe, tablet computer, e-reader, netbook computer, mobile phone, smartphone, smart terminal, dumb terminal, virtual terminal, etc. In practice, computer-readable medium 210 stores computer-readable instructions that, when executed by one or more processors of one or more computers (e.g., the processor of system 10), cause the one or more computers to perform process 212 to direct copies of data packets to the target DPI engine.

[0088] One or more computers receive data packets (box 214). For example, one or more computers can receive data packets from sources such as... Figure 1 The first electronic device 20 or Figure 1 The second electronic device 22 receives data packets from its data source. The one or more computers may receive data packets at their incoming ports. Furthermore, the data packets may be corresponding data packets for network services.

[0089] One or more computers determine that a DPI will be performed on a data packet (box 216). For example, one or more computers may identify a DPI to be performed based on a missing flow in a flow table lookup (e.g., the received data packet does not match an existing entry). As another example, one or more computers may determine that a DPI will be performed based on the flow attributes of the data packet that indicate that a DPI is in progress. As yet another example, one or more computers may determine that a DPI will be performed based on the type of service that indicates the data packet is associated with a portion that has already been set up for a DPI by one or more computers.

[0090] One or more computers generate copies of data packets (box 218). By generating copies of data packets, network traffic flows, including the data packets, can continue uninterrupted. For example, the original data packets can be forwarded to an additional electronic device with the initiating route without interruption. Copies of data packets are maintained for DPI at the same or similar time. One or more computers determine the DPI bootstrap characteristics of the data packets (box 220). For example, one or more computers can determine the DPI bootstrap characteristics by using a symmetric hash value that identifies the data packets. One or more computers can use policy lookup table functionality to determine the DPI bootstrap characteristics. One or more computers can use policy lookup table functionality on a per-client basis, per-VLAN basis, per-VRF basis, etc.

[0091] After determining the DPI bootstrapping feature, one or more computers identify the target DPI engine to perform DPI among multiple DPI engines (box 222). For example, the DPI bootstrapping feature can be a first DPI bootstrapping feature or a second DPI bootstrapping feature, which is obtained based on a symmetric hash or other common attribute value between forward and backward data packet transmissions between the source and destination electronic devices. As mentioned above, in some cases, the symmetric hash can include a 5-tuple for data packets common to both the source-to-destination and destination-to-source streams. The bootstrapping feature can be the number of last bits of a particular DPI engine among multiple DPI engines to host the DPI for a packet. If the DPI bootstrapping feature is a first bootstrapping feature, one or more computers can identify the first DPI engine 14 as the target DPI engine. If the DPI bootstrapping feature is a second bootstrapping feature, one or more computers can identify the second DPI engine 18 as the target DPI engine.

[0092] Therefore, one or more computers direct a copy of the data packet to the target DPI engine (box 224). The target DPI engine can then perform DPI on the copy of the data packet. The target DPI engine can analyze the data and header content of the copy of the data packet. For example, the target DPI engine can identify information associated with application type, protocol, and / or security rules.

[0093] Further, one or more computers send data packets to the data destination (box 226). It should be noted that when performing DPI, one or more computers may send data packets to the data destination at at least partially overlapping time frames. Sometimes, one or more computers may hold data packets until DPI is complete, and at that point, send data packets to the data destination.

[0094] The techniques described herein enable data forwarders, such as network switches, to identify local CPUs with local DPI engines or remote CPUs with remote DPI engines to route network traffic to the network via network links. That is, the data forwarder can leverage the infrastructure of the system within the network to route DPI-oriented data packets, which can reduce or minimize disruption to existing network traffic. Furthermore, by employing dedicated CPUs (such as local or remote CPUs), the techniques described herein enable scalability without incurring additional utilization of computing resources. In effect, the data forwarder can offload DPI operations to local or remote CPUs, reducing the utilization of computing resources. Further, the data forwarder can dynamically adjust network traffic routing between local CPUs, remote CPUs, or any other suitable CPUs for load balancing. Because DPI is performed on network traffic, it can be performed without interrupting or canceling load balancing operations. In effect, the techniques described herein enable DPI operations without limiting routing with network switches, which can increase system efficiency.

[0095] While only certain features of this disclosure have been shown and described herein, many modifications and alterations will occur to those skilled in the art. Therefore, it will be understood that the appended claims are intended to cover all such modifications and alterations falling within the true spirit of this disclosure.

Claims

1. A network device configured as follows: Receive data packets from the data source for transmission to the data destination; Determining the depth grouping check (DPI) will be performed on the data groups; Generate a copy of the data group; Determine the DPI-guided characteristics of the data group; Based on the DPI bootstrapping characteristics of the data packets, a target DPI engine for performing the DPI is identified from a plurality of DPI engines, wherein the target DPI engine is remote from the network device and coupled to an additional network device; The copy of the data group is directed to the target DPI engine; as well as The data packet is sent to the data destination.

2. The network device of claim 1, configured to identify the target DPI engine by: Identify the match between the DPI bootstrap feature and the value in the flow lookup table of the network device; and The DPI engine associated with the value in the stream lookup table is identified as the target DPI engine.

3. The network device of claim 1, configured to determine the DPI bootstrapping characteristic of the data packet by identifying a symmetric hash associated with the data packet.

4. The network device of claim 3, wherein the symmetric hash includes a common hash value for both uplink and downlink data packets.

5. The network device of claim 3, wherein the symmetric hash comprises either a 0 as the last bit or a 1 as the last bit, the 0 indicating a first target DPI engine and the 1 indicating a second target DPI engine.

6. The network device of claim 3, wherein the symmetric hash comprises hashing data from the packet header of the data packet.

7. The network device of claim 1, configured to direct the copy of the data packet to the target DPI engine by transmitting the copy of the data packet to the additional network device via a remote mirroring channel established over a network link between the network device and the additional network device.

8. The network device of claim 1, wherein the DPI bootstrapping feature includes at least a portion of the bit value of a symmetric hash of a 5-tuple associated with the data packet.

9. The network device according to claim 1, configured as follows: The additional data packets are identified as not being used for DPI; and In response to identifying that the additional data packets are not used for DPI, stop directing the additional data packets to the target DPI engine.

10. A method comprising: Receive data packets intended for transmission to the data destination; Determining the depth grouping check (DPI) will be performed on the data groups; Generate a copy of the data group; Determine the DPI-guided characteristics of the data group; Based on the DPI bootstrapping characteristics of the data grouping, the target DPI engine for executing the DPI is identified from multiple DPI engines; The copy of the data group is directed to the target DPI engine; as well as The data packet is sent to the data destination.

11. The method of claim 10, wherein the DPI-guided characteristic of the data packet includes a common symmetry characteristic between the data packet and subsequent data packets received from the data destination for transmission to the data source.

12. The method of claim 10, further comprising determining the DPI boot characteristics by: Extract metadata from the data groups; Generate a hash from the metadata; and The DPI bootstrap characteristics are determined from the hash.

13. The method of claim 12, wherein the hash comprises a symmetric hash and the DPI bootstrap feature comprises a subset of the values ​​of the bits of the symmetric hash.

14. The method of claim 10, further comprising identifying the target DPI engine by: A policy lookup table is used to identify the match between the DPI bootstrap feature and the target value associated with the target DPI engine.

15. The method of claim 10, comprising: The target DPI engine is determined to be unavailable; as well as In response to determining that the target DPI engine is unavailable, the routing of the copy of the data group to the target DPI engine is stopped.

16. The method of claim 15, comprising: After determining that the target DPI engine is unavailable, the target DPI engine is determined to be available again. as well as In response to determining that the target DPI engine is available again: Synchronize the current state of DPI; as well as After synchronization, the copy of the data group is restored and directed to the target DPI engine.

17. One or more tangible, non-transitory computer-readable media, said one or more tangible, non-transitory computer-readable media storing instructions, said instructions, when executed by a processing circuit means, configured to cause said processing circuit means to: Receive data packets intended for transmission to the data destination; Determining the depth grouping check (DPI) will be performed on the data groups; Generate a copy of the data group; Determine the DPI-guided characteristics of the data group; Based on the DPI bootstrapping characteristics of the data grouping, the target DPI engine for executing the DPI is identified from multiple DPI engines; The copy of the data group is directed to the target DPI engine; as well as The data packet is sent to the data destination.

18. One or more tangible, non-transitory computer-readable media according to claim 17, wherein the instructions, when executed by the processing circuitry means, are configured to cause the processing circuitry means to: direct the copy of the data packet to the target DPI engine by transmitting the copy of the data packet to a network device via a network link.

19. One or more tangible, non-transitory computer-readable media according to claim 18, wherein the instructions, when executed by the processing circuitry means, are configured to cause the processing circuitry means to: guide the data packets based on a strategy.

20. One or more tangible, non-transitory computer-readable media according to claim 19, wherein the instructions, when executed by the processing circuitry means, are configured to cause the processing circuitry means to: The network device has been detected as being out of service; and In response to the detection of the suspended operation, the policy is suspended to redirect the data packets to an additional network device.

Images