System and method for determining network path tracking

Abstract

In one embodiment, a method includes receiving, by a network orchestrator from a user device, trace parameters. The method also includes determining, by the network orchestrator, to initiate a network path trace for an application, generating, by the network orchestrator, a filtering policy for the network path trace using the trace parameters, and assigning, by the network orchestrator, a trace identification to the network path trace. The method also includes initiating, by the network orchestrator, the network path trace within a network by transmitting the filtering policy and the trace identification to a first node of the network, and receiving, by the network orchestrator, network path trace data from a plurality of nodes of the network. The method also includes generating, by the network orchestrator, a trace report for the application using the network path trace data.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to network path tracking, and more specifically to systems and methods for determining network path tracking. BACKGROUND

[0002] Existing flow analysis engines analyze data about traffic flows traversing a network. Certain flow analysis engines do not know which network paths certain application flows will traverse. To accurately analyze network-wide flows, these flow analysis engines can push filtering policies to the entire network, which presents a challenge in scale and causes overhead for normal usage. Other flow analysis engines use flow information to simulate potential network paths of a flow based on routing and switching information received from devices, which requires users of the devices to know detailed information of the flow in advance. BRIEF DESCRIPTION OF DRAWINGS

[0003] Figure 1 An example system for determining network path tracking is shown;

[0004] Figure 2 An example user interface page for inputting tracking parameters that can be used by the system of Figure 1 is shown;

[0005] Figure 3 An example user interface page for displaying a tracking report that can be used by the system of Figure 1 is shown;

[0006] Figure 4 An example user interface page for displaying details of a tracking report of Figure 3 is shown;

[0007] Figure 5 An example method for determining network path tracking is shown; and

[0008] Figure 6 An example computer system that can be used by the systems and methods described herein is shown. DETAILED DESCRIPTION

[0009] SUMMARY

[0010] Aspects of the application are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect can be applied to any aspect, alone or in combination with features of other aspects.

[0011] According to one embodiment, a network orchestrator includes one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors. The one or more computer-readable non-transitory storage media comprise instructions that, when executed by the one or more processors, cause the network orchestrator to perform operations comprising receiving a trace parameter from a user device. The trace parameter can be associated with an application. The operations further comprise determining to initiate a network path trace for the application; generating a filtering policy for the network path trace using the trace parameter; and assigning a trace identification to the network path trace. The operations further comprise initiating the network path trace within a network by transmitting the filtering policy and the trace identification to a first node of the network, and receiving network path trace data from a plurality of nodes of the network. The plurality of nodes of the network includes the first node. The operations further comprise generating a trace report for the application using the network path trace data.

[0012] In some embodiments, the trace report includes bidirectional flow paths within the network. In certain embodiments, the trace parameter includes at least two items selected from the group of: a site identification; a virtual private network (VPN) identification; an internet protocol (IP) address of the user device; and an identification of the application. In some embodiments, the trace identification is transmitted within metadata of a packet from a first node of the network to a second node of the network; and the metadata further includes at least one item selected from the group of: an indication of a flow direction of the packet; a debugging level of the network path trace data; and a flow identification assigned by the first node. In some embodiments, the trace report further includes at least one item selected from the group of: a network path of each flow of the network path trace; network locations at which each flow experiences packet drops; metrics associated with each flow; a total number of packets associated with each flow; a total number of bytes associated with each flow; a list of the packets associated with each flow; and internal trace results associated with each of the packets.

[0013] In certain embodiments, the operations include receiving an end trace command; and in response to receiving the end trace command, transmitting a stop trace command for the network path trace to the plurality of nodes of the network. In certain embodiments, the operations include receiving the network path trace data from a trace results database located within each of the plurality of nodes of the network, and initiating a clearing process of the trace results database located within each of the plurality of nodes of the network. In some embodiments, the network path trace data includes: flow statistics of each of the plurality of nodes of the network; and internal trace results of each packet associated with each of the plurality of nodes.

[0014] According to another embodiment, a method includes receiving, by a network orchestrator from a user device, trace parameters. The trace parameters are associated with an application. The method also includes determining, by the network orchestrator, to initiate a network path trace for the application; generating, by the network orchestrator, a filter policy for the network path trace using the trace parameters; and assigning, by the network orchestrator, a trace identification to the network path trace. The method also includes initiating, by the network orchestrator, the network path trace within a network by communicating the filter policy and the trace identification to a first node of the network; and receiving, by the network orchestrator, network path trace data from a plurality of nodes of the network. The plurality of nodes of the network includes the first node. The method also includes generating, by the network orchestrator, a trace report for the application using the network path trace data.

[0015] According to yet another embodiment, one or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations, the operations comprising receiving, from a user device, trace parameters. The trace parameters can be associated with an application. The operations also include determining to initiate a network path trace for the application; generating a filter policy for the network path trace using the trace parameters; and assigning a trace identification to the network path trace. The operations also include initiating the network path trace within a network by communicating the filter policy and the trace identification to a first node of the network; and receiving network path trace data from a plurality of nodes of the network. The plurality of nodes of the network includes the first node. The operations also include generating a trace report for the application using the network path trace data.

[0016] Technical advantages of certain embodiments of the present disclosure can include one or more of the following. Certain systems and methods described herein can be used to trace application paths in one or more networks. Certain embodiments of the present disclosure include an intent-based operating system that enhances the serviceability of SD-WANs by translating end user intent to trace applications of hosts. The application can be traced from a VPN to network-wide trace of flows (e.g., unidirectional or bidirectional flows) initiated by that particular application from that particular host. The trace results can include the network path taken by each flow in each direction, packet drop counts / rates for each flow on each hop of the path, and detailed per-feature processing results for each packet in each flow based on interworking operating system (IOS) packet trace features (e.g., IOS-XE packet trace features). This single network-wide trace result can maintain most or all of the details from the user application appearance. In certain embodiments, network operators (e.g., support engineers) can use the network-wide trace results to deterministically identify network, policy, or product issues. Certain systems and methods described herein can be applicable to SD-WANs, multi-domain cross WANs, campus, or data centers.

[0017] Other technical advantages will be readily apparent to those skilled in the art from the following drawings, descriptions, and claims. Moreover, while specific advantages have been enumerated above, various embodiments can include all, some, or none of the enumerated advantages.

[0018] Example Embodiments

[0019] Troubleshooting network-wide application experiences and verifying network policies based on intent in SD-WANs is complex. For example, an application path can be influenced by different network elements such as central orchestrators, policy distributors, network edge routers, and / or connected edge routers of an underlying network (e.g., the Internet or a multiprotocol label switching (MPLS) network). As another example, an application path can be influenced by different features such as application routing policies, data policies, network address translation (NAT), Internet Protocol Security (IPSec), and / or quality of service (QoS). To enhance the serviceability of SD-WAN solutions, an intent-based operating system is disclosed that can translate end user intent to trace applications of end user devices.

[0020] Figure 1 An example system for determining network path traces is shown. Figure 2 An example user interface page for inputting trace parameters that can be used by the system of Figure 1 An example user interface page for inputting trace parameters that can be used by the system of Figure 3The diagram shows how the display can be made by Figure 1 The system uses a sample user interface page for tracking reports, and Figure 4 A diagram is shown for displaying Figure 3 A sample user interface page showing the details of the tracking report. Figure 5 An example method for determining network path tracing is shown. Figure 6 An example computer system that can be used by the systems and methods described herein is shown.

[0021] Figure 1 An example system 100 for determining network path tracing is shown. System 100, or parts thereof, may be associated with an entity, which may include any entity, such as a business or company initiating network path tracing. Components of system 100 may include any suitable combination of hardware, firmware, and software. For example, components of system 100 may use... Figure 6 One or more components of a computer system. Figure 1 System 100 includes network 110, user 120, user equipment 122, application 124, operator 130, operator equipment 132, user interface 134, orchestrator 140, node 150, uplink packet 160, downlink packet 170, tracking parameter 180, tracking identifier 182, filtering policy 184, tracking data 186, and tracking report 188.

[0022] Network 110 of system 100 is any type of network that facilitates communication between components of system 100. Network 110 can connect one or more components of system 100. One or more portions of network 110 may include ad hoc networks, intranets, extranets, VPNs, local area networks (LANs), wireless LANs (WLANs), WANs, wireless WANs (WWANs), SD-WANs, metropolitan area networks (MANs), portions of the Internet, portions of the Public Switched Telephone Network (PSTN), cellular telephone networks, DSL, 3G networks, 4G networks, 5G networks, Long Term Evolution (LTE) networks, combinations of two or more of these networks, or other suitable types of networks. Network 110 may include one or more different types of networks. Network 110 can be any communication network, such as a private network, a public network, a connection via the Internet, a mobile network, a Wi-Fi network, etc. One or more components of system 100 can communicate through network 110. Network 110 may include a core network (e.g., the Internet), a service provider access network, an Internet Service Provider (ISP) network, etc. Figure 1 In the illustrated embodiment, network 110 includes SD-WAN. SD-WAN is a virtual upper-layer network that uses tunnels to carry services over multiple underlying networks. SD-WAN can be a hybrid that leverages existing carrier services and unmanaged connections to the public internet.

[0023] A user 120 of the system 100 is any individual, group of individuals, machine, entity, etc. that interacts with a user device 122. The user 120 can utilize the user device 122 to communicate with an operator 130 over the network 110. In certain embodiments, the user 120 of the user device 122 interacts with an application 124. The application 124 is a software program that runs on the user device 122. The application 124 can be a video application, an audio application, a screen sharing application, a messaging application, a file sharing application, a whiteboard application, a call application, a web browser, an email program, a word processor, a game, a combination thereof, or any other suitable application. In certain embodiments, the user 120 can experience an issue with the application 124 and generate a complaint about performance of the application 124 using the user device 122.

[0024] The user device 122 of the system 100 represents any suitable computing component that can be used to transmit information to one or more components of the system 100 (e.g., the operator device 132). The user device 122 can be a phone (e.g., a smartphone), a laptop computer, a desktop computer, a tablet computer, a personal digital assistant, a wearable computer, a combination thereof, or any other suitable computing component. In certain embodiments, the user device 122 can have wireless network connectivity capabilities (e.g., WI-FI and / or BLUETOOTH capabilities). The user device 122 can include an interface (e.g., a screen, a graphical user interface (GUI), or a panel) that allows the user 120 to interact with the user device 122. The user device 122 can communicate with one or more components of the system 100 via the network 110. For example, the user device 122 can transmit a complaint about performance of the application 124 to the operator 130.

[0025] The operator 130 of the system 100 is any individual, group of individuals, machine, entity, etc. that interacts with an operator device 132. In certain embodiments, the operator 130 is authorized by an entity (e.g., a service provider) associated with the system 100 to communicate with an orchestrator 140. In some embodiments, the operator 130 can be requested to input an identification associated with the entity to access the orchestrator 140. The operator 130 can input information into the operator device 132. For example, the operator 130 can input information received from the user device 122 into the operator device 132.

[0026] Operator device 132 of system 100 represents any suitable computing component that can be used to process information for operator 130. Operator device 132 can be a laptop computer, a desktop computer, a phone (e.g., a smart phone), a tablet, a personal digital assistant, a wearable computer, a combination thereof, or any other suitable computing component. In certain embodiments, operator device 132 can have wireless network connectivity capabilities (e.g., WI-FI and / or BLUETOOTH capabilities). Operator device 132 can communicate with one or more components of system 100 via network 110. For example, operator device 132 can receive a complaint from user device 122 regarding performance of application 124. As another example, operator device 132 can transmit information associated with the complaint to orchestrator 140.

[0027] In certain embodiments, operator device 132 includes user interface 134 that allows operator 130 to interact with operator device 132. For example, operator 130 can receive tracking parameters 180 from user device 122 and enter tracking parameters 180 into user interface 134 of operator device 132. Tracking parameters 180 are characteristics associated with application 124 for tracking a flow path of application 124 through network 110. Tracking parameters 180 can include a site identification, a VPN identification, an Internet Protocol (IP) address of user device 122, an identification of application 124, a tracking duration, and the like. In certain embodiments, operator device 132 receives one or more tracking parameters 180 within a complaint. For example, user 120 of user device 122 can generate a complaint associated with performance of application 124 and transmit the complaint to operator device 132. Operator device 132 can then retrieve one or more tracking parameters 180 (e.g., an IP address of user device 122, an identification of application 124, and the like) from the complaint. In certain embodiments, operator 130 generates one or more tracking parameters 180, such as a tracking duration. Operator can enter one or more tracking parameters 180 into user interface 134 of operator device 132. In certain embodiments, operator device 132 transmits tracking parameters 180 to orchestrator 140. For example, operator 130 can select a launch function on user interface 134 of operator device 132 to request a network path trace for application 124 that transmits tracking parameters 180 that have been entered into user interface 134 to orchestrator 140.

[0028] Orchestrator 140 of system 100 represents any suitable computing component (e.g., controller, router, server, etc.) that can be used to initiate network path tracking of system 100. Orchestrator 140 can coordinate and / or facilitate communication between one or more components of system 100. Orchestrator 140 can receive data from and / or send data to one or more components of system 100. Orchestrator 140 can be located in any suitable location to process information of system 100. In Figure 1 In the illustrated embodiment, orchestrator 140 is located in an SD-WAN environment. In certain embodiments, orchestrator 140 functions as a central controller for network 110.

[0029] In certain embodiments, orchestrator 140 receives tracking parameters 180 from one or more components of system 100. For example, user 120 of user device 122 can experience performance issues with application 124 and communicate the complaint to operator device 132, and tracking parameters 180 can be associated with that particular application 124 that is experiencing performance issues. As another example, orchestrator 140 can receive a request from operator device 132 to validate a design of a deployment of a new site, VPN, and / or service within network 110, and tracking parameters 180 can be associated with that particular new site, VPN, and / or service. As yet another example, orchestrator 140 can receive a request from operator device 132 to periodically monitor a policy used by network 110, and tracking parameters 180 can be associated with the policy.

[0030] In certain embodiments, orchestrator 140 determines to initiate network path tracking. For example, orchestrator 140 can determine to initiate network path tracking for application 124 in response to receiving tracking parameters 180 from operator device 132. In some embodiments, orchestrator 140 assigns a tracking identification 182 to the network path tracking. Tracking identification 182 is a network-wide unique identification used by one or more components of system 100 to identify a particular network path tracking. Tracking identification 182 can be carried by one or more packets within network 110. In some embodiments, orchestrator 140 generates a filtering policy 184 for the network path tracking. Filtering policy 184 is a policy used by components of system 100 to filter packets within network 110 that belong to application 124. In certain embodiments, orchestrator 140 transforms tracking parameters 180 to generate filtering policy 184. In some embodiments, orchestrator initiates network path tracking for application 124 by communicating tracking identification 182 and / or filtering policy 184 to nodes 150.

[0031] Node 150 of system 100 represents any suitable computing component (e.g., router, switch, server, etc.) that can receive, create, process, store, and / or transmit traffic to other components within network 110. Network 110 of system 100 can include multiple nodes 150. In certain embodiments, node 150 is part of an SD-WAN architecture. In Figure 1 In the illustrated embodiment, nodes 150 include node 150a and node 150b.

[0032] Node 150a is a device (e.g., first-hop device) within the SD-WAN architecture of network 110 that is closest to user device 122. Node 150a can receive packets from and / or transmit packets to user device 122 using a LAN connection of network 110. Node 150a can receive packets from and / or transmit packets to node 150b using a WAN connection of network 110. In certain embodiments, node 150a receives information from orchestrator 140. For example, node 150a can receive tracking identification 182 and / or filtering policy 184 from orchestrator 140. Upon receiving filtering policy 184 from orchestrator 140, node 150a can activate filtering policy 184 for the network path identified by tracking identification 182.

[0033] In certain embodiments, when filtering policy 184 for the network path identified by tracking identification 182 is activated on node 150a, node 150a matches uplink packets 160 received from user device 122 with filters of filtering policy 184. Uplink packets 160 are a set of data transmitted from user device 122 to one or more components of network 110. Node 150a can search for an existing flow using the tuple of uplink packets 160 and, if no existing flow is found, create a new flow entry. Upon creating the new flow entry, a unique flow identification per tracking is assigned for the new flow. Node 150a can track the internal code path of uplink packets 160 and save the internal tracking results on node 150a using tracking identification 182, flow identification, and arrival order of uplink packets 160 as a three-level index.

[0034] When node 150a completes processing of uplink packet 160, node 150a can add metadata to the upper layer encapsulation. The metadata can include one or more of the following fields: a direction bit to mark the flow direction (e.g., 0 for upstream and 1 for downstream); a debug level to indicate a debug level for network path tracing; a flag that is reserved for future use; a flow identification assigned by node 150a to represent the flow globally; and a trace identification 182 assigned by orchestrator 140. In certain embodiments, node 150a initiates an encapsulation process to encapsulate the metadata of uplink packet 160. After encapsulating the metadata, node 150a can transmit uplink packet 160 to node 150b.

[0035] Node 150b is a remote device within the SD-WAN architecture of network 110. Node 150b can receive and / or transmit packets from devices outside of the SD-WAN architecture of network 110 using a LAN connection. Node 150b can receive and / or transmit packets from node 150a using a WAN connection of network 110. In certain embodiments, node 150b is located in a different geographic region than node 150a. For example, node 150b can be located in a first city (e.g., Beijing, San Jose, etc.) while node 150a can be located in a second city (e.g., Shanghai, New York City, etc.). Node 150b can receive uplink packet 160 from node 150a. In certain embodiments, upon receiving uplink packet 160, node 150b decapsulates the metadata, reads trace identification 182 from the decapsulated metadata, and / or searches for trace identification 182 in the trace result database. If node 150b is unable to find a match for trace identification 182 in the trace result database, node 150b can insert trace identification 182 into the trace result database. In certain embodiments, node 150b transmits a notification to orchestrator 140. The notification can include information associated with node 150b (e.g., a device identification), trace identification 182, etc. The information included in the notification can indicate to orchestrator 140 that a database record for trace identification 182 is available on node 150b. Upon receiving this notification from node 150b, orchestrator 140 can use this information to determine the external network path of the traced uplink packet 160.

[0036] Upon receiving the uplink packet 160 with the metadata added by the node 150a, the node 150b can determine to internally track the uplink packet 160. In certain embodiments, the node 150b saves the internal tracking results of the uplink packet 160 and indexes the uplink packet 160 by the tracking identification 182 and / or the flow identification. The node 150b can read the order of arrival of the uplink packet 160 from the metadata. In certain embodiments, the node 150b uses the tuple of the uplink packet 160 to search for the existing flow. If no existing flow entry is found, the node 150b can create a new flow entry. The flow entry created by the node 150b can be bidirectional such that an automatic filter for matching the existing flow entry can be created on the network domain edge interface to match downlink packets from outside the network domain. The tracking identification 182 and / or the flow identification can be saved into the flow entry opaque data.

[0037] The node 150b can receive a downlink packet 170 from a node outside the network 110 (e.g., a web server). The downlink packet 170 is a collection of data transmitted from one or more components of the network 110 (e.g., the node 150b) to the user device 122. In certain embodiments, the node 150b can use an automatic filter to determine that the downlink packet 170 matches an existing flow. In response to the determination, the node 150b can initiate tracking of the downlink packet 170. The tracking identification 182 and / or the flow identification can be obtained from the opaque data of the matching flow entry and used with the order of arrival of the downlink packet 170 to index the internal tracking results of the downlink packet 170. Once the downlink packet 170 proceeds to the upper layer encapsulation process, the tracking identification 182 and / or the flow identification can be included in the metadata field of the downlink packet 170.

[0038] The node 150b can transmit the downlink packet 170 to the node 150a with the tracking identification 182 and / or the flow identification in the metadata. The node 150b sets the direction bit in the metadata of the downlink packet 170 to downstream (e.g., 1 for downstream). When the node 150a receives the downlink packet 170 from the node 150b, the node 150a can determine that the downlink packet 170 is downlink by reading its metadata. In this way, the node 150a tracks the downlink packet 170 and saves the tracking results; no other action is needed for the downlink packet 170.

[0039] In certain embodiments, the operator 130 can issue an end trace command to the orchestrator 140 via the operator device 132 to request the orchestrator 140 to terminate the network path trace for the application 124. Upon receiving the end trace command from the operator device 132, the orchestrator 140 transmits a stop trace command to the participating nodes 150 (e.g., nodes 150a and 150b) of the network 110 that have trace result database records for the trace identification 182. In certain embodiments, the orchestrator 140 can transmit the stop trace command to the participating nodes 150 in response to determining to end the network path trace based on a configurable interval timer. Upon receiving the stop trace command, the nodes 150 can remove all filters (including the filters configured on the node 150a and the filters automatically generated on the node 150b) so that new packets are not matched and traced. The orchestrator 140 can be allowed to receive in-flight trace packets and / or a predetermined period of time to obtain internal trace results from the participating nodes 150.

[0040] In some embodiments, the filter policy 184 is configured to instruct one or more participating nodes 150 of the network 110 to terminate the network path trace for the application 124. For example, the filter policy 184 can include a parameter to initiate termination of the network path trace once the node 150a has filtered a predetermined number of packets (e.g., 1 to 250 packets) according to the filter policy 184. In response to the node 150a filtering the predetermined number of packets, the participating nodes 150 can remove all filters (including the filters configured on the node 150a and the filters automatically generated on the node 150b) so that new packets are not matched and traced.

[0041] In certain embodiments, the orchestrator 140 receives trace data 186 associated with the trace identification 182 from the nodes 150 of the network 110. The trace data 186 is data associated with the trace identification 182 received from the participating nodes 150 of the network 110. The trace data 186 can include flow statistics for each participating node 150 of the network 110, internal trace results for each packet associated with each participating node 150, etc. In certain embodiments, the orchestrator 140 can retrieve the trace data 186 from the trace result database of each participating node 150. For example, the orchestrator 140 can extract the trace data 186 associated with the trace identification 182 from the database records of the trace result database. In certain embodiments, the orchestrator 140 stores the trace data 186 on one central database for correlation and visualization.

[0042] The trace data 186 can include two parts: per-device, per-flow, with statistics of the characteristics of the flow; and per-device, per-packet, with internal processing trace results. Because the flow has a unique flow identification for each trace, the orchestrator 140 can correlate the statistics for the same flow across multiple nodes 150. The orchestrator 140 can use the last-hop send count minus the next-hop receive count to compute the underlying network drop. Because the internal trace results for each upstream packet 160 and each downstream packet 170 include the flow identification, the orchestrator 140 can correlate the internal trace results with the flow statistics and group the internal trace results by different flows as shown below. Figure 3

[0043] In certain embodiments, the orchestrator uses the trace data 186 received from the participating nodes 150 of the network 110 to generate a trace report 188. The trace report 188 is an organized collection of information showing the results of the network path trace initiated by the orchestrator 140. The trace report 188 can include information associated with the flow paths (e.g., unidirectional or bidirectional flow paths) of the applications 124 generated by the orchestrator 140. In certain embodiments, the trace report 188 includes one or more of the following: the network path for each flow of the network path trace; the network locations where each flow experiences packet drops; the metrics associated with each flow; the total number of packets associated with each flow; the total number of bytes associated with each flow; a list of packets associated with each flow; and the internal trace results associated with each packet.

[0044] In certain embodiments, the orchestrator 140 initiates a clearing process for the trace results database of the nodes 150. The orchestrator 140 can initiate the clearing process periodically, on demand, and / or upon retrieving the trace data 186 from the nodes 150. In certain embodiments, each node 150 delays clearing its trace results database until the trace data 186 is successfully transferred to the orchestrator 140, such that if the connection between the node 150 and the orchestrator 140 fails, the orchestrator 140 can still recover the trace results by scanning the trace results database of the node 150 after the connection is restored.

[0045] In operation, a user 120 of a user device 122 experiences performance issues (e.g., slow response times, poor video quality, etc.) of an application 124 (e.g., a Webex meeting). Via the user device 122, the user 120 communicates a complaint about the performance of the application 124 (see Figure 1 ​Step 1) to operator device 132. The complaint includes tracking parameters 180 such as site identification, VPN identification of user 120, IP address of user device 122, identification of application 124 experiencing performance issues, etc. Operator 130 enters tracking parameters 180 into user interface 134 of operator device 132 and requests (see Figure 1 Step 2) Orchestrator 140 initiates tracking of application 124 by selecting a launch function on user interface 134. Orchestrator 140 receives tracking parameters 180 from operator device 132 and determines to launch a network path trace for application 124. Orchestrator 140 assigns a trace identification 182 to the network path trace and generates a filter policy 184 for the network path trace using tracking parameters 180. Orchestrator 140 binds trace identification 182 to filter policy 184 and initiates (see Figure 1 Step 3) a network path trace within network 110 by communicating (see

[0046] After initiating (e.g., activating) the network path trace within network 110, node 150a receives (see Figure 1 Step 4) an upstream packet 160 from user device 122. Node 150a matches upstream packet 160 to filters of filter policy 184. Node 150a uses the tuple of upstream packet 160 to search for an existing flow. If no existing flow is found, node 150a creates a new flow entry and assigns a unique flow identification to the new flow. Node 150a traces the internal code path of upstream packet 160 and saves the trace results to a trace database stored on node 150a using the trace identification 182, the flow identification, and the order of arrival of upstream packet 160 as a three-level index.

[0047] When node 150a completes processing of upstream packet 160, node 150a adds metadata to the upper layer encapsulation of upstream packet 160. The metadata includes the following fields: direction bit, debug level, flags, flow identification, and trace identification 182. Node 150a then communicates (see Figure 1 Step 5) upstream packet 160 to node 150b. When node 150b of network 110 receives upstream packet 160, node 150b decapsulates the metadata and reads trace identification 182. Node 150b searches the trace results database for trace identification 182. If node 150b does not find a match, node 150b inserts trace identification 182 into its trace results database and communicates (see Figure 1Step 6) to orchestrator 140 of network 110. The notification includes the identity of node 150b and the trace identity 182. Orchestrator 140 uses the information in the notification to determine the network path flow for uplink packet 160.

[0048] Node 150b saves the trace results for uplink packet 160 in its trace results database and indexes the trace identity 182 and the flow identity. Node 150b reads the arrival order of uplink packet 160 from the metadata. Node 150b uses the tuple of uplink packet 160 to search for an existing flow. If no existing flow entry is found, then node 150b creates (see Figure 1 Step 7) a new flow entry. The created flow entry can be bidirectional such that an automatic filter matching the existing flow entry can be established on the network domain edge interface to match downlink packets from outside the network domain. The trace identity 182 and the flow identity are saved in the flow entry opaque data.

[0049] When downlink packet 170 arrives (see Figure 1 Step 8) at node 150b, node 150b uses the automatic filter to determine that downlink packet 170 matches the existing flow. Based on this determination, node 150b determines to trace downlink packet 170. Node 150b obtains the trace identity 182 and the flow identity from the opaque data of the matching flow entry and uses this information along with the arrival order of downlink packet 170 to index the internal trace results for downlink packet 170. Once downlink packet 170 proceeds to the upper layer encapsulation, the same trace identity 182 and flow identity are included in the metadata field.

[0050] Downlink packet 170 is transmitted (see Figure 1 Step 9) back to node 150a with the same trace identity 182 and flow identity in the metadata and with the direction bit in the metadata set to downlink. When node 150a receives downlink packet 170, node 150a determines that downlink packet 170 is in the downlink by reading the metadata. Node 150a traces (see Figure 1 Step 10) downlink packet 170 and saves the trace results in its trace results database.

[0051] Steps 4 through 10 of Figure 1 are repeated until operator 130 of operator device 132 transmits (see Figure 1 Step 11) an end trace command to orchestrator 140. Once orchestrator 140 receives the end trace command, orchestrator 140 transmits (see Figure 1Step 12) proceeds to nodes 150a, 150b, and any other nodes 150 with tracking result database records for tracking identifier 182. Upon receiving a stop tracking command, all filters (including those configured on node 150a and automatically generated on node 150b) are removed, so no new groups are matched and tracked. Orchestrator 140 retrieves data from the tracking result database of each participating node 150 (see [link to documentation]). Figure 1 Step 12) uses tracking data 186 for tracking identifier 182 and stores tracking data 186 on a central database for correlation and visualization. Orchestrator 140 uses tracking data 186 to generate tracking report 188 for application 124. Tracking report 188 includes the flow path of application 124 within network 110 (e.g., unidirectional or bidirectional flow path). Orchestrator 140 transmits tracking report 188 (see...). Figure 1 Step 13) leads to the user interface 134 of operator device 132. Orchestrator 140 initiates the tracking results database on participating node 150 (see...). Figure 1 Step 14) The cleanup process. In this way, system 100 uses orchestrator 140 to push filtering policy 184 along with tracking identifier 182 to node 150a for on-demand tracking, without needing to simulate forwarding decisions, which introduces minimal or no overhead compared to normal use.

[0052] although Figure 2 Steps 1 through 14, which occur in a specific order, are described and illustrated, but this disclosure covers steps that occur in any suitable order. Figure 1 Any appropriate steps. Furthermore, although this disclosure describes and illustrates the implementation... Figure 1 The specific components or devices used in steps 1 to 14, but this disclosure covers the execution of... Figure 1 Any suitable combination of any suitable components and devices in steps 1 to 14.

[0053] although Figure 1 A specific arrangement of network 110, user 120, user equipment 122, application 124, operator 130, operator equipment 132, user interface 134, orchestrator 140, node 150, uplink packets 160, downlink packets 170, tracking parameters 180, tracking identifiers 182, filtering policies 184, tracking data 186, and tracking reports 188 is shown. However, this disclosure covers any suitable arrangement of network 110, user 120, user equipment 122, application 124, operator 130, operator equipment 132, user interface 134, orchestrator 140, node 150, uplink packets 160, downlink packets 170, tracking parameters 180, tracking identifiers 182, filtering policies 184, tracking data 186, and tracking reports 188.

[0054] Although Figure 2 A particular number of networks 110, users 120, user devices 122, applications 124, operators 130, operator devices 132, user interfaces 134, orchestrators 140, nodes 150, uplink packets 160, downlink packets 170, trace parameters 180, trace identifiers 182, filter policies 184, trace data 186, and trace reports 188 are shown, the present disclosure contemplates any suitable number of networks 110, users 120, user devices 122, applications 124, operators 130, operator devices 132, user interfaces 134, orchestrators 140, nodes 150, uplink packets 160, downlink packets 170, trace parameters 180, trace identifiers 182, filter policies 184, trace data 186, and trace reports 188. For example, the system 100 can include more than one filter policy 184 and / or more than two nodes 150.

[0055] Figure 2 An example user interface page 200 for inputting trace parameters 180 that can be used by the system 100 is shown. In certain embodiments, the user interface page 200 is generated by the user interface 134 of the system 100. Figure 2 Figure 1 The orchestrator 140 of the system 100 can provide the user interface 134 to the operator 130 to allow the operator 130 to request network path tracing for an application (e.g., the application 124 of the system 100). The user interface page 200 includes the trace parameters 180, advanced options 210, and historical trace results 230. Figure 2 Figure 2 The user interface page 200 of the system 100 can provide the user interface 134 to the operator 130 to allow the operator 130 to request network path tracing for an application (e.g., the application 124 of the system 100). The user interface page 200 includes the trace parameters 180, advanced options 210, and historical trace results 230.

[0056] The trace parameters 180 of the user interface page 200 are characteristics associated with an application for tracing the application through the network 110. In the embodiment shown, the trace parameters 180 are included at the top of the user interface page 200. The trace parameters 180 include a site identifier (denoted as Site ID), a VPN identifier of a complaining user (denoted as VPN), an IP address of a device of the complaining user (denoted as Host IP), a destination IP address (denoted as Destination IP / FQDN), an identification of the application (denoted as Application), and a duration of the network path tracing (denoted as Trace Duration). The site identifier indicates a location of the user device 122 with respect to the network. For example, the site identifier can be a unique identifier of a site in an SD-WAN overlay network. The VPN identifier is a VPN identifier of a complaining user. While the trace duration is denoted in seconds in the embodiment shown, the trace duration can be denoted in any time increment (e.g., milliseconds, minutes, etc.). In certain embodiments, the trace duration is denoted in seconds. Figure 1 Figure 2 Figure 2 ​​​​The tracking duration can be replaced by multiple groups, such that network path tracking terminates once multiple groups entered in the user interface page 200 have been filtered according to the filtering policy. Tracking parameters 180 can be represented by numbers, letters, characters, or combinations thereof. In some embodiments, an asterisk next to a particular tracking parameter 180 (i.e., site identifier and VPN identifier) ​​indicates that the field is necessary to initiate network path tracking.

[0057] The advanced option 210 of the user interface page 200 is related to the node on the network closest to the complaining user (e.g., Figure 3 The characteristics associated with node 150a). Advanced options 210 include device identifier, source interface, protocol, source port, destination port, differential service code point (DSCP), and debug level. Debug level can include the following dropdown options: select / reset option, trace all packets, trace only dropped packets, and trace only statistics. The Feature Call Array (FIA) can be selected to trace features (in... Figure 3 This is represented as FIA tracking to track each feature entry invoked during packet processing. Packet replication capability can be selected (in...). Figure 1 (This is represented as grouped copy) to copy the input and output groups at each layer of the group.

[0058] The historical tracking results 230 on the user interface page 200 are past tracking reports generated by the network orchestrator (e.g., Figure 2 The tracking report 188). Historical tracking results 230 may include the time when each tracking report was generated, tracking parameters 180 associated with each corresponding tracking report (e.g., VPN identifier, site identifier, IP address of the complaining user's device, destination IP address, application identifier, and tracking duration). Historical tracking results 230 also include links to each listed tracking report.

[0059] Once the operator has entered the tracking parameter 180 into the user interface page 200, the operator can select the start function on the user interface page 200 (in... Figure 3 The "Start" function (represented as "Start") sends a request to the network orchestrator to initiate network path tracing for the application. In some embodiments, the operator can select a "Stop" function on the user interface page 200. Figure 3 The "stop" option (indicated by "stop") sends a termination command to the network orchestrator. Once the network orchestrator has completed network path tracing for the application based on tracing parameters 180, it can send a tracing report to the operator, as follows: Figure 4 As shown.

[0060] Figure 4 The diagram shows how the display can be made by Figure 3The system 100 uses a sample user interface page 300 of the tracking report 188. User interface page 300 includes data from... Figure 2 The user interface page 200 displays tracking parameters 180 and / or advanced options 210, and a tracking report 188 generated by the network orchestrator in response to an operator request for network path tracking associated with tracking parameters 180. Tracking report 188 on user interface page 300 summarizes the tracking results of the network path tracing. Figure 3 In the embodiment shown, the tracking report 188 includes 12 columns: global flow column, local edge column, local color column, remote edge column, remote color column, local drop rate column, WAN drop rate column, remote drop rate column, jitter column, latency column, total packets column, and total bytes column.

[0061] The first five columns of Trace Report 188 (Global Flow Column, Local Edge Column, Local Color Column, Remote Edge Column, and Remote Color Column) can be used by network operators to identify the network path for each flow in each direction. The Global Flow Column indicates the flow identifier associated with the network path tracing (e.g., Flow ID1, Flow ID87, Flow ID235, and Flow ID4213), the protocol associated with each flow identifier (e.g., Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc.), and the uplink and downlink hop counts for each flow identifier. The Local Edge Column identifies the local edge node associated with each hop of each flow (e.g., vm5, vm1, etc.), the Local Color Column identifies the network type used by the local edge node (e.g., LTE, 3g, etc.), the Remote Edge Column identifies the remote edge node associated with each hop of each flow (e.g., vm1, vm5, etc.), and the Remote Color Column identifies the network type used by the remote edge node (e.g., LTE, 3g, etc.). By interpreting these five columns, network operators can identify any asymmetric routing problems experienced by the application.

[0062] The last three columns of Tracking Report 188 (Local Drop Rate, WAN Drop Rate, and Remote Drop Rate) can be used by network operators to identify the locations in the network where specific flows suffer packet drops. The Local Drop Rate column indicates the percentage of packets dropped by local edge nodes, the WAN Drop Rate column indicates the percentage of packets dropped by the WAN (e.g., the Internet), and the Remote Drop Rate column indicates the percentage of packets dropped by remote edge nodes.

[0063] The next two columns of the tracking report 188 (jitter and latency columns) indicate the metrics for each specific stream. The jitter column indicates the jitter experienced by each stream per hop (i.e., the variation in delay of packets carrying voice or video data on the communication channel), measured in milliseconds. The latency column indicates the latency experienced by each stream per hop (i.e., the time it takes for a data packet to travel from one point to another), measured in milliseconds. While the user interface page 300 displays jitter and latency metrics in milliseconds, the user interface page 300 can also display jitter and latency metrics in any suitable unit (e.g., microseconds, seconds, etc.).

[0064] The last two columns of trace report 188 (total packets and total bytes) indicate the total number of packets and bytes associated with each flow. The total packets column indicates the total number of packets transmitted in each hop of each flow, and the total bytes column indicates the total number of bytes measured in kilobytes in each hop of each flow. Filters are available on user interface page 300 to filter flows of interest by their characteristics. After the network operator views user interface page 300 generated from flow statistics, the network operator can press the details button located next to the name of each node (e.g., vm1, vm5, etc.). Figure 4 (The text below is in the format of "details") to view the grouping details of a specific stream. Below is... Figure 4 The example grouping details are shown in the image.

[0065] Figure 4 A diagram is shown for displaying Figure 4 The tracking report 188 details are shown in sample user interface page 400. User interface page 400 includes information from... Figure 5 The user interface page 200 contains tracking parameters 180 and / or advanced options 210, and a summary is provided in [the relevant section]. Figure 1 The details of the tracking report 188 are on the user interface page 300. Figure 1 In the embodiment shown, the trace report 188 includes eight columns: flow column, input column, output column, status column, cause column, SLA category column, Fwd category column, and QoS queue column.

[0066] The flow column of trace report 188 displays a list of packets (packets 23, 36, 52, 67, 82, 95, 109, and 123) of a flow (flow identifier 87) on a selected device (vm5). The input columns of trace report 188 identify the input interface associated with each packet, while the output columns identify the output interface associated with each packet. If a packet has been dropped by the selected device, the output interface is set to none (in...). Figure 1 The "<None>" indicates the location of the packet. The status column of tracking report 188 indicates whether each packet was dropped. Figure 1 (Indicated as discarded) or forwarded (in)Figure 2 The cause column of the trace report 188 indicates the reason for the drop (e.g., tail drop), the SLA class column of the trace report 188 indicates the service level agreement (SLA) class associated with the packet, the Fwd class column of the trace report 188 indicates the priority of the packet, and the QoS queue column of the trace report 188 indicates the number of egress queues for all ports on the device.

[0067] In certain embodiments, the network operator can select a feature to view more details associated with each packet. For example, the network operator can click the "click for more details" button next to the packet 23, which displays the packet trace details (e.g., internal trace results) for the packet 23 on the right-hand side of the user interface page 400. The packet trace details can include a summary of the packet trace (e.g., ingress interface identification, egress interface identification (if applicable), status of the packet, reason for packet drop (if applicable), timestamps showing the start and stop times of the packet trace, etc.), path trace information, FIA trace information, and packet replication information. The path trace information can include the characteristics of the packet (e.g., IPv4), ingress interface identification, egress interface identification (if known), source of the packet (e.g., source IP address), destination of the packet (e.g., destination IP address), protocol used by the packet (e.g., TCP, UDP, etc.), source port associated with the packet, destination port associated with the packet, etc. By reading the internal trace results of the device, the operator can determine a code-level understanding of how the packet 23 was handled on the vm5 device. In certain embodiments, filters are available on the user interface page 400 to filter the packets according to the characteristics of the packets.

[0068] Figure 1 An example method 500 for determining network path trace for an application is shown. The method 500 begins at step 505. At step 510, a network orchestrator (e.g., the orchestrator 140 of Figure 1 receives trace parameters (e.g., the trace parameters 180) from a user device (e.g., the user device 122 of Figure 1 For example, a user can experience performance issues with an application (e.g., the application 124 of Figure 1 and transmit a complaint to an operator (e.g., the operator 130 of Figure 2 about the performance of the application via the user device. The complaint can include trace parameters, such as a site identification, a VPN identification of the user, an IP address of the user device, an identification of the application that is experiencing performance issues, etc. The operator can enter the trace parameters into a user interface (e.g., the user interface 134 of the operator device 132), and select a user interface page (e.g., the user interface page 400 of Figure 1the user interface page 200) to request that the network orchestrator initiate tracking of the application. The method 500 then moves from the step 510 to a step 515.

[0069] At the step 515 of the method 500, the network orchestrator determines to initiate network path tracking for the application that is experiencing performance issues. The network orchestrator can determine to initiate the network path tracking in response to receiving the tracking parameters from the operator device. The method 500 then moves from the step 515 to a step 520, at which the orchestrator generates a filtering policy (e.g., the filtering policy 184) for the network path tracking using the tracking parameters 180. The filtering policy instructs one or more network nodes to filter all packets received from the complaining user’s device. The method 500 then moves from the step 520 to a step 525, at which the network orchestrator assigns a tracking identification (e.g., the tracking identification 182) to the network path tracking. In certain embodiments, the network orchestrator can bind the tracking identification to the filtering policy. The method 500 then moves from the step 525 to a step 530. Figure 1

[0070] At the step 530 of the method 500, the network orchestrator initiates the network path tracking within the network by communicating the tracking identification and the filtering policy to a first node (e.g., the node 150a) of the network, which is located closest to the complaining user’s device. Upon receiving the filtering policy from the orchestrator, the first node begins filtering uplink packets (e.g., the uplink packets 160) received from the complaining user’s device. If the first node does not locate an existing flow for each uplink packet in its trace results database, the first node creates a new flow entry and assigns a unique flow identification to the new flow. The first node traces the internal code path of each uplink packet and saves the trace results using the tracking identification, the flow identification, and the arrival order of the uplink packet as a three-level index. Figure 3 Figure 4 When the first node completes processing each uplink packet 160, the first node adds metadata to an upper layer encapsulation of each uplink packet and communicates the uplink packet to a second node of the network. When the second node receives the uplink packet, the second node decapsulates the metadata, reads the tracking identification, and searches for the tracking identification in its trace results database. The method 500 then moves from the step 530 to a step 535.

[0071] At the step 535 of the method 500, the network orchestrator determines to initiate network path tracking for the application that is experiencing performance issues. The network orchestrator can determine to initiate the network path tracking in response to receiving the tracking parameters from the operator device. The method 500 then moves from the step 535 to a step 540, at which the orchestrator generates a filtering policy (e.g., the filtering policy 184) for the network path tracking using the tracking parameters 180. The filtering policy instructs one or more network nodes to filter all packets received from the complaining user’s device. The method 500 then moves from the step 540 to a step 545, at which the network orchestrator assigns a tracking identification (e.g., the tracking identification 182) to the network path tracking. In certain embodiments, the network orchestrator can bind the tracking identification to the filtering policy. The method 500 then moves from the step 545 to a step 550.

[0072] ​​In step 535 of method 500, the network orchestrator receives a notification from one or more nodes in the network. For example, if a second node does not find a match for a tracking identifier in its tracking results database, the second node inserts the tracking identifier into the tracking results database and sends a notification to the network orchestrator. The notification sent to the network orchestrator includes the second node's identifier and the tracking identifier.

[0073] The second node stores the tracking results for each uplink packet, reads the arrival order of each uplink packet from the metadata, and searches its database for existing flows. If no existing flow entry is found, the second node creates a new flow entry. The created flow entries can be bidirectional, allowing for the creation of automatic filters at the network domain edge interface that match existing flow entries to match downlink packets from outside the network domain (e.g., ...). Figure 5 (Downlink group 170). The tracking identifier and flow identifier are saved to the flow entry opaque data. Method 500 then moves from step 535 to step 540.

[0074] In step 540 of method 500, the network orchestrator determines whether an end-of-trace command has been received. For example, the network operator can do so by selecting a user interface page (e.g., Figure 5 The network orchestrator uses the stop function on the user interface page 200 to send an end-tracking command to the orchestrator. If the network orchestrator does not receive the end-tracking command, method 500 repeats steps 535 and 540 until the end-tracking command is received. Once the network orchestrator receives the end-tracking command, method 500 moves from step 540 to step 545, where the network orchestrator sends a stop-tracking command for the tracking identifier to multiple network nodes that have tracking result database records for that specific tracking identifier. Upon receiving the stop-tracking command, all filters (including filters configured on the first node and automatically generated filters on the second node) are removed, so no new packets are matched and tracked. The network orchestrator retrieves tracking data for the tracking identifier from the tracking result database of each participating network node (e.g., ...). Figure 5 (Tracking data 186). Method 500 then moves from step 545 to step 550.

[0075] In step 550 of method 500, the network orchestrator uses the tracking data received from the participating network nodes to generate a tracking report for the tracked application (e.g., Figure 5 The tracking report (188) includes the application's flow path (e.g., unidirectional or bidirectional flow path). The tracking report can be transmitted to the operator's device user interface and displayed on one or more user interface pages. For example, it can be displayed on a user interface page (e.g., ...). Figure 5A summary of the tracking report is displayed on the user interface page 300. As another example, the specific details of the summarized tracking report can be displayed on the user interface page (e.g., ...). Figure 5 On the user interface page 400. Method 500 then moves from step 550 to step 555, where method 500 ends.

[0076] Although this disclosure describes and illustrates events occurring in a particular order Figure 6 This disclosure covers specific steps of the method, but covers those occurring in any suitable order. ​ Any appropriate steps of the method. Furthermore, although this disclosure describes and illustrates methods for determining including... ​ This disclosure describes example methods for network path tracing of specific steps, but covers any suitable methods for determining network path tracing for an application, including any appropriate steps, and where appropriate, the method may include... ​ The method may include all, some, or no steps. Furthermore, although this disclosure describes and illustrates the execution of... ​ The method may refer to specific components, devices, or systems for specific steps, but this disclosure covers the execution of... ​ Any appropriate combination of any appropriate component, device, or system of any appropriate step of the method.

[0077] ​ An example computer system 600 is illustrated. In a particular embodiment, one or more computer systems 600 perform one or more steps of one or more methods described or illustrated herein. In a particular embodiment, one or more computer systems 600 provide the functionality described or illustrated herein. In a particular embodiment, software running on one or more computer systems 600 performs one or more steps of one or more methods described or illustrated herein, or provides the functionality described or illustrated herein. Specific embodiments include one or more portions of one or more computer systems 600. Throughout this document, references to computer systems may include computing devices and vice versa, where appropriate. Furthermore, references to computer systems may include one or more computer systems, where appropriate.

[0078] The present disclosure encompasses any suitable number of computer systems 600. The present disclosure encompasses a computer system 600 in any suitable physical form. As examples and not by way of limitation, computer system 600 can be an embedded computer system, a system on a chip (SOC), a single-board computer system (SBC) (such as, for example, a computer-on-module (COM) or a system-on-module (SOM)), a desktop computer system, a laptop or notebook computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobile telephone, a personal digital assistant (PDA), a server, a tablet computer system, an augmented / virtual reality device, or a combination of two or more of these. Where appropriate, computer system 600 can include one or more computer systems 600 in a single physical casing or distributed across multiple physical casings. Where appropriate, one or more computer systems 600 can perform one or more steps of one or more methods described or illustrated herein without material

[0079] In particular embodiments, computer system 600 includes a processor 602, memory 604, storage 606, an input / output (I / O) interface 608, a communication interface 610, and a bus 612. Although the present disclosure describes and illustrates a particular computer system having particular components arranged in a particular fashion, the present disclosure encompasses any suitable computer system having any suitable components arranged in any suitable fashion.

[0080] In particular embodiments, processor 602 includes hardware for executing software, such as instructions of a computer program. As an example and not by way of limitation, to execute instructions, processor 602 can retrieve (or fetch) the instructions from an internal register, an internal cache, memory 604, or storage 606; decode and execute them; and then write one or more results to the internal register, internal cache, memory 604, or storage 606. In particular embodiments, processor 602 can include one or more internal caches for data, instructions, or addresses. The present disclosure contemplates processor 602 including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor 602 can include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches can be copies of instructions from memory 604 or storage 606, and the instruction caches can speed up retrieval of those instructions by processor 602. Data in the data caches can be copies of data from memory 604 or storage 606 for instructions executing at processor 602 to operate on; the results of previous instructions executed at processor 602 for access by subsequent instructions executing at processor 602 or for writing to memory 604 or storage 606; or other suitable data. Data caches can speed up read or write operations by processor 602. The TLBs can speed up virtual address translation for processor 602. In particular embodiments, processor 602 can include one or more internal registers for data, instructions, or addresses. The present disclosure contemplates processor 602 including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor 602 can include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors 602. Although the present disclosure describes and illustrates a particular processor, the present disclosure contemplates any suitable processor.

[0081] In particular embodiments, memory 604 includes main memory for storing instructions executable by processor 602 or data upon which processor 602 operates. As an example and not by way of limitation, computer system 600 can load instructions from storage 606 or another source (such as another computer system 600) into memory 604. Processor 602 can then load the instructions from memory 604 into internal registers or internal cache. To execute the instructions, processor 602 can retrieve the instructions from the internal registers or internal cache and decode them. During or after execution of the instructions, processor 602 can write one or more results (which can be intermediate or final results) to the internal registers or internal cache. Processor 602 can then write one or more of these results to memory 604. In particular embodiments, processor 602 executes only instructions in one or more internal registers or internal cache or in memory 604 (as opposed to storage 606 or elsewhere), and only operates on data in one or more internal registers or internal cache or in memory 604 (as opposed to storage 606 or elsewhere). One or more memory buses, which can each include an address bus and a data bus, can couple processor 602 to memory 604. Bus 612 can include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor 602 and memory 604 and facilitate access to memory 604 by processor 602, in response to requests from processor 602. In particular embodiments, memory 604 includes random access memory (RAM). Where appropriate, this RAM can be volatile memory or non-volatile memory, or a combination of both. Where appropriate, this RAM can be dynamic RAM (DRAM) or static RAM (SRAM). Where appropriate, this RAM can be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Where appropriate, memory 604 can include one or more memories 604. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

[0082] In particular embodiments, storage 606 includes mass storage for data or instructions. As an example and not by way of limitation, storage 606 can include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc (e.g., a compact disc or DVD, etc.), a solid-state drive (SSD), a tape drive, a USB drive, or a combination of two or more of these. Storage 606 can be removable or non-removable (or fixed), and can include one or more storage devices. Storage 606 can be internal or external, and can be connected to computer system 600 via an adapter. In particular embodiments, storage 606 is non-volatile solid-state memory. In particular embodiments, storage 606 includes read-only memory (ROM). Where appropriate, this ROM can be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage 606 taking any suitable physical form. Storage 606 can include one or more storage control units facilitating communication between processor 602 and storage 606, where appropriate. Where appropriate, storage 606 can include one or more storage control units facilitating communication between processor 602 and storage 606 over an external I / O interface 608. Where appropriate, storage 606 can include one or more storage control units facilitating communication between processor 602 and storage 606 over an adapter. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

[0083] In particular embodiments, I / O interface 608 includes hardware, software, or both, providing one or more interfaces for the exchange of information between computer system 600 and one or more I / O devices. Where appropriate, computer system 600 can include one or more of these I / O devices, which can be connected to computer system 600 through I / O interface 608. One or more of these I / O devices can enable communication between a person and computer system 600. As an example, and not by way of limitation, these I / O devices can include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, any suitable I / O device, or a combination of two or more of these. I / O devices can include one or more sensors. This disclosure contemplates any suitable I / O devices and any suitable I / O interface 608 for them. Where appropriate, I / O interface 608 can include one or more device or software drivers enabling processor 602 to drive one or more of these I / O devices. I / O interface 608 can include one or more I / O interfaces 608, where appropriate. Although this disclosure describes and illustrates a particular I / O interface, this disclosure contemplates any suitable I / O interface.

[0084] In particular embodiments, communication interface 610 includes hardware, software, or both providing one or more interfaces for the exchange of information between computer system 600 and one or more other computer systems 600 or one or more networks. As an example, and not by way of limitation, communication interface 610 can include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI network. This disclosure contemplates any suitable network and any suitable communication interface 610 for it. As an example, and not by way of limitation, computer system 600 can communicate with an ad hoc network, a personal area network (PAN), a LAN, a WAN, a MAN, or one or more portions of the Internet or a combination of two or more of these. One or more portions of one or more of these networks can be wired or wireless. As an example, computer system 600 can communicate with a wireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular telephone network (such as, for example, a Global System for Mobile Communications (GSM) network, a 3G network, a 4G network, a 5G network, or a Long Term Evolution (LTE) network), or other suitable wireless network or a combination of two or more of these. Computer system 600 can include any suitable communication interface 610 for any of these networks, where appropriate. Communication interface 610 can include one or more communication interfaces 610, where appropriate. Although this disclosure describes and illustrates a particular communication interface, this disclosure contemplates any suitable communication interface.

[0085] In particular embodiments, bus 612 includes hardware, software, or both coupling components of computer system 600 to each other. As an example, and not by way of limitation, bus 612 can include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HYPERTRANSPORT (HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCIe) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association local (VLB) bus, or another suitable bus or interconnect, or a combination of two or more of these. Where appropriate, bus 612 can include one or more buses 612. Although this disclosure describes and illustrates a particular bus, this disclosure contemplates any suitable bus or interconnect.

[0086] To summarize, in one embodiment, a method includes receiving, by a network orchestrator from a user device, a trace parameter. The method also includes determining, by the network orchestrator, to initiate a network path trace for an application, generating, by the network orchestrator, a filter policy for the network path trace using the trace parameter, and assigning, by the network orchestrator, a trace identification to the network path trace. The method also includes initiating, by the network orchestrator, the network path trace within a network by communicating the filter policy and the trace identification to a first node of the network, and receiving, by the network orchestrator, network path trace data from a plurality of nodes of the network. The method also includes generating, by the network orchestrator, a trace report for the application using the network path trace data.

[0087] Herein, a computer-readable non-transitory storage medium or media can include one or more semiconductor-based or other integrated circuits (ICs) (such, as for example, field-programmable gate arrays (FPGAs) or application-specific ICs (ASICs)), hard disk drives (HDDs), hybrid hard drives (HHDs), optical discs, optical disc drives (ODDs), magneto-optical discs, magneto-optical drives, floppy diskettes, floppy disk drives (FDD s), magnetic tapes, solid-state drives (SSDs), RAM-drives, SECURE DIGITAL cards or drives, any other suitable computer-readable non-transitory storage media, or any suitable combination of two or more of these, where appropriate. A computer-readable non-transitory storage medium can be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate.

[0088] Herein, “or” is inclusive and not exclusive, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A or B” means “A, B, or both,” unless expressly indicated otherwise or indicated otherwise by context. Moreover, “and” is both joint and several, unless expressly indicated otherwise or indicated otherwise by context. Therefore, herein, “A and B” means “A and B, jointly or severally,” unless expressly indicated otherwise or indicated otherwise by context.

[0089] The scope of the disclosure includes all changes, substitutions, variations, alterations, and modifications to the example embodiments described or illustrated herein that a person having ordinary skill in the art would comprehend. The scope of the disclosure is not limited to the example embodiments described or illustrated herein. Moreover, although this disclosure describes and illustrates various embodiments including particular components, elements, features, functions, operations or steps, any one or more of these embodiments each might include any combination or permutation of any of the components, elements, features, functions, operations, or steps described or illustrated anywhere else herein. Further, although this disclosure describes and illustrates an apparatus, or system, or components thereof, as being adapted to, being configured to, being enabled to, being operable to, or being capable of, performing a particular function, such an apparatus, system, or component can be so adapted, configured, enabled, operable, or capable of, whether or not it is activated, on, or unlocked, as long as it is so adapted, configured, enabled, operable, or capable. Further, although this disclosure describes and illustrates particular embodiments as providing particular advantages, particular embodiments can not provide these advantages, provide some or all of these advantages, or provide other advantages not expressly described or illustrated herein.

Claims

1. A network orchestrator, comprising: one or more processors; and one or more computer-readable non-transitory storage media coupled to the one or more processors and comprising instructions that, when executed by the one or more processors, cause the network orchestrator to perform operations comprising: receiving tracking parameters from a user device, wherein the tracking parameters are characteristics associated with an application and are used to track a flow path of the application through a network; determining to initiate a network path trace for the application; generating a filtering policy for the network path trace using the tracking parameters, wherein the filtering policy is used to filter packets belonging to the application within the network; assigning a trace identification to the network path trace; binding the trace identification to the filtering policy; initiating the network path trace within the network by communicating the filtering policy and the trace identification to a first node of the network, wherein upon receiving the filtering policy, the first node filters uplink packets received from the user device, and wherein the first node traces an internal code path of each uplink packet and saves internal trace results on the first node using the trace identification, a flow identification of a flow of an uplink packet, and an order of arrival of an uplink packet as a three-level index; receiving network path trace data from a plurality of nodes of the network, wherein the plurality of nodes of the network includes the first node and the network path trace data includes a flow identification assigned by the first node to globally represent a flow; and generating a trace report for the application using the network path trace data. the trace report comprises a bidirectional flow path within the network.

2. The network orchestrator of claim 1, wherein, the tracking parameters comprise at least two selected from a group consisting of:

3. The network orchestrator of claim 1 or 2, wherein, a site identification; a virtual private network (VPN) identification; an internet protocol (IP) address of the user device; and an identification of the application.

4. The network orchestrator of claim 1 or 2, wherein: the trace identification is communicated within metadata of a packet from the first node of the network to a second node of the network; and the metadata further comprises at least one selected from a group consisting of: an indication of a flow direction of the packet; a debugging level of the network path trace data; and the flow identification assigned by the first node. the trace report further comprises at least one selected from a group consisting of:

5. The network orchestrator of claim 1 or 2, wherein, a network path of each flow of the network path trace; network locations where each flow experiences packet drops; metrics associated with each flow; a total number of packets associated with each flow; a total number of bytes associated with each flow; a list of the packets associated with each flow; and internal trace results associated with each of the packets.

6. The network orchestrator of claim 1 or 2, the operations further comprising: receiving an end trace command; and in response to receiving the end trace command, communicating a stop trace command for the network path trace to the plurality of nodes of the network. the network path trace data comprises: ​ ​ 7. The network orchestrator of claim 1 or 2, wherein, ​ flow statistics for each of a plurality of nodes of the network; and internal tracking results for each packet associated with each of the plurality of nodes.

8. A method for determining network path tracking, comprising: receiving, by a network orchestrator, tracking parameters from a user device, wherein the tracking parameters are characteristics associated with an application and are used to track a flow path of the application through a network; determining, by the network orchestrator, to initiate network path tracking for the application; generating, by the network orchestrator, a filtering policy for the network path tracking using the tracking parameters, wherein the filtering policy is used to filter packets belonging to the application within the network; assigning, by the network orchestrator, a tracking identification to the network path tracking; binding, by the network orchestrator, the tracking identification to the filtering policy; initiating, by the network orchestrator, the network path tracking within the network by communicating the filtering policy and the tracking identification to a first node of the network, wherein upon receiving the filtering policy, the first node filters uplink packets received from the user device, and wherein the first node tracks an internal code path of each uplink packet and saves internal tracking results on the first node using the tracking identification, a flow identification of a flow of uplink packets, and an order of arrival of uplink packets as a three-level index; receiving, by the network orchestrator, network path tracking data from a plurality of nodes of the network, wherein the plurality of nodes of the network includes the first node and the network path tracking data includes flow identifications assigned by the first node to globally represent flows; and generating, by the network orchestrator, a tracking report for the application using the network path tracking data.

9. The method of claim 8, wherein, the tracking report includes bidirectional flow paths within the network.

10. The method of claim 8 or 9, wherein, the tracking parameters include at least two selected from a group consisting of: a site identification; a virtual private network (VPN) identification; an internet protocol (IP) address of the user device; and an identification of the application.

11. The method of claim 8 or 9, wherein: the tracking identification is communicated within metadata of a packet from a first node of the network to a second node of the network; and the metadata further includes at least one selected from a group consisting of: an indication of a flow direction of the packet; a debugging level of the network path tracking data; and a flow identification assigned by the first node.

12. The method of claim 8 or 9, wherein, the tracking report further includes at least one selected from a group consisting of: a network path of each flow of the network path tracking; network locations where each flow experiences packet drops; metrics associated with each flow; a total number of packets associated with each flow; a total number of bytes associated with each flow; a list of the packets associated with each flow; and internal tracking results associated with each of the packets.

13. The method of claim 8 or 9, further comprising: receiving, by the network orchestrator, an end tracking command; and ​ ​ In response to receiving the end trace command, transmitting, by the network orchestrator, a stop trace command for the network path trace to a plurality of nodes of the network.

14. The method of claim 8 or 9, wherein, The network path trace data includes: flow statistics data for each node of the plurality of nodes of the network; and internal trace results for each packet associated with each node of the plurality of nodes.

15. One or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations comprising: receiving trace parameters from a user device, wherein the trace parameters are characteristics associated with an application and are used to trace a flow path of the application through a network; determining to initiate a network path trace for the application; generating a filtering policy for the network path trace using the trace parameters, wherein the filtering policy is used to filter packets belonging to the application within the network; assigning a trace identification to the network path trace; binding the trace identification to the filtering policy; initiating the network path trace within the network by transmitting the filtering policy and the trace identification to a first node of the network, wherein upon receiving the filtering policy, the first node filters uplink packets received from the user device, and wherein the first node traces an internal code path of each uplink packet and saves internal trace results on the first node using the trace identification, a flow identification of a flow of the uplink packet, and an arrival order of the uplink packet as a three-level index; receiving network path trace data from a plurality of nodes of the network, wherein the plurality of nodes of the network includes the first node and the network path trace data includes a flow identification assigned by the first node to globally represent a flow; and generating a trace report for the application using the network path trace data.

16. The one or more computer-readable non-transitory storage media of claim 15, wherein, The trace report includes a bidirectional flow path within the network.

17. The one or more computer-readable non-transitory storage media of claim 15 or 16, wherein, The trace parameters include at least two selected from a group consisting of: a site identification; a virtual private network (VPN) identification; an Internet Protocol (IP) address of the user device; and an identification of the application.

18. The one or more computer-readable non-transitory storage media of claim 15 or 16, wherein: the trace identification is transmitted within metadata of a packet from a first node of the network to a second node of the network; and the metadata further includes at least one selected from a group consisting of: an indication of a flow direction of the packet; a debugging level of the network path trace data; and a flow identification assigned by the first node.

19. The one or more computer-readable non-transitory storage media of claim 15 or 16, wherein, The trace report further includes at least one selected from a group consisting of: a network path of each flow of the network path trace; network locations where each flow experiences packet drops; metrics associated with each flow; a total number of packets associated with each flow; a total number of bytes associated with each flow; a list of the packets associated with each flow; and internal trace results associated with each of the packets.

19. A system comprising: a network orchestrator configured to: receive trace parameters from a user device, wherein the trace parameters are characteristics associated with an application and are used to trace a flow path of the application through a network; determine to initiate a network path trace for the application; generate a filtering policy for the network path trace using the trace parameters, wherein the filtering policy is used to filter packets belonging to the application within the network; assign a trace identification to the network path trace; bind the trace identification to the filtering policy; initiate the network path trace within the network by transmitting the filtering policy and the trace identification to a first node of the network, wherein upon receiving the filtering policy, the first node filters uplink packets received from the user device, and wherein the first node traces an internal code path of each uplink packet and saves internal trace results on the first node using the trace identification, a flow identification of a flow of the uplink packet, and an arrival order of the uplink packet as a three-level index; receive network path trace data from a plurality of nodes of the network, wherein the plurality of nodes of the network includes the first node and the network path trace data includes a flow identification assigned by the first node to globally represent a flow; and generate a trace report for the application using the network path trace data. The trace report includes a bidirectional flow path within the network. The trace parameters include at least two selected from a group consisting of: a site identification; a virtual private network (VPN) identification; an Internet Protocol (IP) address of the user device; and an identification of the application.

18. The system of claim 19, wherein: the trace identification is transmitted within metadata of a packet from a first node of the network to a second node of the network; and the metadata further includes at least one selected from a group consisting of: an indication of a flow direction of the packet; a debugging level of the network path trace data; and a flow identification assigned by the first node. The trace report further includes at least one selected from a group consisting of: a network path of each flow of the network path trace; network locations where each flow experiences packet drops; metrics associated with each flow; a total number of packets associated with each flow; a total number of bytes associated with each flow; a list of the packets associated with each flow; and internal trace results associated with each of the packets.

20. The one or more computer-readable non-transitory storage media of claim 15 or 16, the operations further comprising: receiving an end trace command; and in response to receiving the end trace command, transmitting a stop trace command for the network path trace to a plurality of nodes of the network.

21. A network orchestrator, comprising: means for receiving trace parameters from a user device, wherein the trace parameters are characteristics associated with an application and are used to trace a flow path of the application through a network; means for determining to initiate a network path trace for the application; means for generating a filtering policy for the network path trace using the trace parameters, wherein the filtering policy is used to filter packets belonging to the application within the network; means for assigning a trace identification to the network path trace; means for binding the trace identification to the filtering policy; means for initiating the network path trace within the network by transmitting the filtering policy and the trace identification to a first node of the network, wherein upon receiving the filtering policy, the first node filters uplink packets received from the user device, and wherein the first node traces an internal code path of each uplink packet and saves internal trace results on the first node using the trace identification, a flow identification of a flow of an uplink packet, and an arrival order of an uplink packet as a three-level index; means for receiving network path trace data from a plurality of nodes of the network, wherein the plurality of nodes of the network includes the first node, and the network path trace data includes a flow identification assigned by the first node to globally represent a flow; and means for generating a trace report for the application using the network path trace data.

22. The network orchestrator of claim 21, further comprising means for implementing the method of any one of claims 9 to 14.

23. A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method of any one of claims 8 to 14.

Images