WO2015119611A2

WO2015119611A2 - Trace packet and path analysis in a software defined network

Info

Publication number: WO2015119611A2
Application number: PCT/US2014/015084
Authority: WO
Inventors: Santosh Kumar Singh; Anh Tuan Vuong; Ravindra KENCHAPPA
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2014-02-06
Filing date: 2014-02-06
Publication date: 2015-08-13
Also published as: WO2015119611A3

Abstract

A trace packet can be used for path analysis in a software defined network (SDN). The trace packet can be generated with a source address matching a source address of an existing flow, a destination address matching a destination address of the existing flow, and a unique identifier (UID). The trace packet can be injected into a network via a specified port of a network device along a programmed path of the existing flow. An observation post (a defined network device along the programmed path of the exiting flow) can be instructed to send any packet that includes the UID to a network controller for path analysis.

Description

TRACE PACKET AND PATH ANALYSIS IN A SOFTWARE DEFINED

NETWORK

Background

[0001] In a software defined network (SDN), applications can control the way that packets traverse a network. An SDN is a network where the data plane (the underlying systems that forward traffic) is separated from the control plane (the system that makes decisions about how traffic traverses the network). These applications can control packet flows by programming flow tables on network devices such as switches, routers, bridges, etc. Examples of such applications can include load balancers, network address translation (NAT), security applications, and routing applications such as open shortest path first (OSPF), etc.

Brief Description of the Drawings

[0002] Figure 1 is a diagram illustrating an example of a network according to the present disclosure.

[0003] Figure 2 is a diagram illustrating an example of a network according to the present disclosure.

[0004] Figure 3A is a diagram illustrating an example of a system according to the present disclosure.

[0005] Figure 3B is a diagram illustrating an example of a network controller according to the present disclosure.

[0006] Figure 4 is a flow chart illustrating an example of a method according to the present disclosure. Detailed Description

[0007] Debugging a software defined network (SDN) can be difficult because tools such as ping and traceroute do not work in the SDN. Traceroute is a diagnostic tool for displaying the route and measuring delays of packets across an Internet Protocol (IP) network. A series of Internet Control Message Protocol (ICMP) echo request packets can be addressed to a destination host. The time-to-live (TTL) is used in determining the intermediate routers being traversed towards the destination, where routers decrement the packets' TTL values by one when routing and discarding packets whose TTL value has reached zero, returning an ICMP error message indicating that the ICMP time has been exceeded. The history of the route can be recorded as the round-trip times of the packets received from each successive host in the route. In contrast, ping is used to test the reachability of a host on an IP network and computes the round-trip times for messages from an originating host to a destination point. Ping sends an ICMP echo request packet to a target and waits for an ICMP response, measuring elapsed time in the process.

[0008] These tools may not work in an SDN because the network controller would have to add a rule to the switches regarding how to handle ping or traceroute packets. By default, the ping or traceroute packet would be sent to the controller if a flow for the ping or traceroute packet had not been

programmed into the network. That is, the ping or traceroute would fail if there is no rule telling the switches what to do with the ping or traceroute packet.

[0009] Applications may program flow tables based on traffic pattern type, source, destination, quality of service (QoS), and other associated fields.

However, there are limitations to the flow tables such as the number of flows allowed per flow table. Therefore applications may write macro flows (e.g., using wildcard match features) rather than micro flows. Macro flows can include less specific flow information that can cover multiple micro (specific) flows.

However, if macro flow rules are not programmed correctly, troubleshooting can be difficult because errors can manifest themselves across multiple micro flows. Even where flows are programmed correctly, a network device may not honor the programmed flow actions. Such instances can be difficult to diagnose because the flow appears to be programmed correctly. The present disclosure overcomes these obstacles with trace packet generation and path analysis in an SDN based on generated trace packets and flow match validation for networks managed by a standalone network controller or a team of network controllers.

[0010] In the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how a number of examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be used and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.

[0011] The figures herein follow a numbering convention in which the first digit corresponds to the drawing figure number and the remaining digits identify an element or component in the drawing. For example, reference numeral 102 may refer to element "02" in Figure 1 and an analogous element may be identified by reference numeral 202 in Figure 2. Elements shown in the various figures herein can be added, exchanged, and/or eliminated so as to provide a number of additional examples of the present disclosure. In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the present disclosure, and should not be taken in a limiting sense.

[0012] Figure 1 is a diagram illustrating an example of a network 100 according to the present disclosure. In some examples, the network 100 can be an SDN. The network 100 can include network controller 102 (e.g., an SDN controller) that can include a processing resource in communication with a memory resource. The memory resource can include a set of instructions, executable by the processing resource to perform a number of functions described herein. In some examples, the network controller 102 can be a discrete device, such as a chassis based switch. In some examples, the network controller 102 can be a logical device implemented by more than one physical device. For example, the network controller 102 can be a plurality of physical computing devices.

[0013] An SDN is a form of network virtualization in which the control plane (system that makes decisions that affect network traffic) is separated from the data plane (system that moves the network traffic) and implemented as software. Network administrators can therefore have programmable, and in some cases centralized, control of network traffic without requiring physical access to the network's hardware devices. The network controller 102 can implement the control plane. Implementing a control plane can include providing processing and memory resources to execute instructions comprising the software that implements the control plane.

[0014] The network 100 includes a number of computing devices 104-1 , 104-2, 104-3, 104-4 (referred to generally herein as computing devices 104, without limiting examples to a particular number of computing devices). A computing device 104 can be a host such as a server, laptop, desktop, access point, etc. Each computing device 104 has a respective network address. For example, computing device 104-1 is illustrated with address 10.0.0.5, computing device 104-2 is illustrated with address 10.0.0.6, computing device 104-3 is illustrated with address 10.0.0.7, and computing device 104-4 is illustrated with address 10.0.0.8. The computing devices are interconnected by a number of network devices 106-1 , 106-2, 106-3, 106-4 (referred to generally herein as network devices 106, without limiting examples to a particular number of network devices). Examples of network devices 106 include switches, routers, bridges, hubs, and the like.

[0015] Each network device 106 in the network is connected to the network controller via the control plane 1 12. The control plane 1 12 allows the network controller 102 to program and monitor flows on each of the network devices 106. The topology of the network 100 includes a number of physical links 1 10 between the computing devices 104 and network devices 106. The data plane operates over the physical links 1 10 so that packets can transfer between computing devices 104 via the network devices 106. [0016] An example of a programmed path 108 between computing device 104-2 and computing device 104-1 is illustrated via network device 106-2 and network device 106-1 . This programmed path 108 can be an existing flow programmed on both network device 106-2 and network device 106-1 . The programmed path 108 can also be an expected path between the computing device 104-2 and the computing device 104-1 based on the network topology (e.g., the physical links 1 10) because the programmed path 108 appears to be the most direct path between the computing device 104-2 and the computing device 104-1 . In some instances it may be desirable to analyze the

programmed path 108. For example, the computing device 104-2 could be a personal computer and the computing device 104-1 could be a hypertext transfer protocol (HTTP) server that is not responding.

[0017] According to a number of examples of the present disclosure, a network administrator can use the network controller 102 to generate a trace packet including a source address matching a source address of the existing flow 108 (e.g., the address 10.0.0.6 of the computing device 104-2), a destination address matching the destination address of the existing flow 108 (e.g., the address 10.0.0.5 of the computing device 104-1 ), and a unique identifier (UID) for the trace packet. The network controller 102 can encipher the trace packet to generate the UID so that the network controller 102 can identify it uniquely for efficient and proper analysis (e.g., as opposed to reflecting other traffic associated with the existing flow 108 to the network controller 102). Enciphering the trace packet can include converting the trace packet to a coded form (e.g., by operation of an algorithm such as a hashing algorithm, where operating the algorithm using the trace packet as an input generates the UID). The UID can be registered on the network controller 102. Registering the UID on the network controller 102 and/or embedding the UID in the trace packet that may reach the observation post 107 can facilitate unique identification of the trace packet by the observation post 107 and/or the network controller 102. The observation post 107 is described in more detail below. Registering the UID can allow the network controller 102 to encipher a received packet to generate a UID, compare it to the registered UID, and in response to the UIDs matching, identify that the received packet matches the trace packet. In some examples, the UID can be added to the trace packet (e.g., during generation of the trace packet and enciphering thereof). Trace packets can be generated for protocols that carry a data payload in some form such as protocols in the network layer or above in the Open Systems Interconnection (OSI) model. Examples of such protocols can include the transmission control protocol (TCP), user datagram protocol (UDP), dynamic host configuration protocol (DHCP), and ICMP, among others.

[0018] The network controller 102 can be used to assign an observation post 107 (e.g., network device 106-1 ). The observation post 107 can be assigned to any of the network devices 106 on the programmed path 108. The network controller 102 can instruct the observation post 107 to send any packet that includes the matching criteria specified by the trace packet to the network controller 102 for path analysis. Once the observation post 107 has been assigned, a trace packet can be generated with the UID to test the programmed path 108. If the observation post 107 receives a packet with the specified matching criteria, it can send a copy of the packet to the network controller 102. The network controller 102 can decode the packet to get a fingerprint of the packet (e.g., the path history of the packet, including addresses and/or ports of network devices 106 through which it has traversed) and/or the UID. In response to the received fingerprint matching the matching criteria of the trace packet (e.g., matching the programmed path 108), the network controller 102 can update its record (e.g., memory structure) that it received the trace packet from the observation post 107. The network controller 102 can set a success status for the observation post 107 in response to the trace packet being received from the observation post 107. The network administrator can use the network controller 102 to query whether the trace packet was received from the observation post 107. If the status is set to success, it means that the programmed path is correct with respect to the network device 106 assigned as the observation post 107. If the status is not set to success, it means that either the trace packet is being dropped or that it is not yet received by the observation post. [0019] The network administrator can use the network controller 102 to reassign the observation post 107 to a different network device (e.g., network device 106-2) along the programmed path 108 of the trace packet (e.g., in response to the success status being set for the previous observation post). Moving the observation post 107 can facilitate a determination of the point of failure along the programmed path 108.

[0020] Figure 2 is a diagram illustrating an example of a network 200 according to the present disclosure. The network 200 can be analogous to the network 100 illustrated in Figure 1 . The network 200 can be an SDN and include an SDN controller 202. The network 200 is illustrated including a number of computing devices 204-1 , 204-2 (referred to generally herein as computing devices 204) and a number of network devices 206-1 , 206-2, 206-3 (referred to generally herein as network devices 206). A first computing device 204-1 is connected to a second computing device 204-2 via a number of physical links 210 through a first network device 206-1 , a second network device 206-2, and a third network device 206-3. In the example illustrated in Figure 2, the physical links 210 (e.g., expected path) are the same as the programmed path 208 (e.g., existing flow). Figure 2 also includes a number of path injector and path analysis actions 214 as described herein (e.g.,

implemented in the control plane of the network 200).

[0021] Figure 2 includes a flow table for each network device (e.g., flow table 215 for network device 206-2). The flow tables can include flow rules for existing flows (e.g., existing flow 225 defined in flow table 215). By way of example, the network controller 202 can assign an observation post to the second network device 206-2 to test the programmed path 208 between the first computing device 204-1 and the second computing device 204-2. In some examples, a network administrator can assign the observation post via the network controller 202. The network controller 202 can generate a trace packet 213 and register the trace packet 213 (as used herein, registering the trace packet can include registering the trace packet itself, registering a fingerprint of the trace packet, and/or registering a UID of the trace packet) to an existing flow 225 based on a source address 216-2, a destination address 218-2, and a protocol of the trace packet 213. In some examples, a network administrator can define the trace packet via the network controller 202. As illustrated, an existing flow 225 defined on the second network device 206-2 includes a source address 216-1 and a destination address 218-1 that match the source address 216-2 and the destination address 218-2 of the trace packet 213. In some examples, the incoming port 220-2 of a particular network device of the trace packet 213 can match an incoming port 220-1 of the existing flow 225.

Accordingly, a flow rule 226 can be added to the existing flow 225 on the second network device 206-2, where the flow rule 226 includes the source address 216-2, the destination address 218-2, an incoming port 220-2, a priority 222-2, and an outgoing port / action 224-2 for the trace packet 213.

[0022] The flow rule 226 can be added for the trace packet 213 with a higher priority 222-2 (e.g., 1001 ) than a priority 222-1 (e.g., 1000) of the existing flow 225 corresponding to the trace packet 213 on the second network device 206-2. The higher priority for the flow rule 226 for the trace packet 213 can cause the second network device 206-2 to take the defined action 224-2 for the flow rule 226 before and/or instead of taking the defined action for the existing flow 225. In the example illustrated in Figure 2, this means that the

corresponding packet (trace packet 213) would be sent out of the "controller port" (e.g., be sent to the network controller 202).

[0023] Although not specifically illustrated in the flow rule 226 in Figure 2, the flow rule 226 can specify a more specific flow based on flow table capability in order to send only one class of traffic consisting of the trace packet to the network controller 202 (e.g., to reduce the volume of traffic being sent to the controller 202).

[0024] Although not specifically illustrated in the flow rule 226 in Figure 2, the flow rule 226 can also specify a protocol for the trace packet 213. Thus, the trace packet 213 can be application specific. Specifying a protocol can prevent the second network device 206-2 from sending any packet (e.g., other traffic that is associated with a flow that is not experiencing an error because the flow for that protocol is working properly) that matched the source address 216-2 and destination address 218-2 of the trace packet 213 to the network controller 202. [0025] The network controller 202 can inject the trace packet 213 into the network 200 on behalf of a source of the existing path (e.g., computing device 204-1 ) via a specified port of a network device (e.g., port 2 of network device 206-1 ) along a programmed path 208 of the existing flow. As illustrated, the network controller 202 can inject the trace packet 213 via a port of a network device 206-1 that is upstream, with respect to the programmed path 208, of the network device 206-2 that is assigned an observation post and downstream of the computing device 204-1 that is the source of the flow.

[0026] If the programmed path 208 is programmed correctly on the first network device 206-1 where the trace packet 213 is injected, then the first network device 206-1 should correctly forward the trace packet 213 to the second network device 206-2 (e.g., out of port 3 of the first network device 206- 1 and into port 4 of the second network device 2026-2). Because the second network device 206-2 has been assigned the observation post with the accompanying flow rule 226, the second network device 206-2 will send the trace packet 213 to the network controller 202. In some examples, the network controller 202 can set a success status for the second network device 206-2 (observation post) merely because the trace packet 213 was received

therefrom. In some examples, the network controller 202 can first examine a fingerprint of the trace packet received from the second network device 206-2 and compare it to expected matching criteria for the trace packet 213 based on the programmed path 208. In this example, the fingerprint and/or matching criteria could include information such as one or more of the following: the source address of the computing device 204-1 (00:1 E:0B:AE:D3:BE), the outgoing port (1 ) of the computing device 204-1 , the incoming port (2) of the first network device 206-1 , the outgoing port (3) of the first network device 206-1 , the incoming port (4) of the second network device 206-2, and/or the destination address (00:0c:29:03:7f:48) of the second computing device 204-2. If the fingerprint of the trace packet received from the second network device 206-2 matches the expected matching criteria for the trace packet 213, then the network controller 202 can set the success status for the second network device 206-2. [0027] After the network controller 202 sets the success status for the second network device 206-2, a network administrator can query a status for the second network device 206-2 (e.g., via the network controller 202). If the status is set to success, then the network administrator may wish to continue testing the programmed path 208. The network controller 202 can inject the trace packet 213 back into the network 200 via a defined network device (e.g., via the second network device 206-2) and instruct a different observation post (e.g., a different network device 206-3 downstream of the previous observation post with respect to the existing flow) to send any packet that includes the UID to the network controller 202. This testing process can continue until the test packet 213 is not returned to the network controller 202, which would indicate that the observation post that is assigned when the test packet 213 is not returned to the network controller 202 can be a point of failure.

[0028] If the programmed path 208 is not programmed correctly on the first network device 206-1 , then the trace packet 213 will not reach the second network device 206-2 and therefore the second network device 206-2 will not be able to send the trace packet to the network controller 202. When the network controller does not receive the trace packet 213 from the second network device 206-2 and/or when a network administrator queries and does not find a success status for the second network device 206-2, it will be apparent that the first network device 206-1 is the point of failure.

[0029] Figure 3A is a diagram illustrating an example of a system 348 according to the present disclosure. The system 348 can include a data store 334, a subsystem 332, and/or a number of engines 336, 338. The subsystem can include the number of engines (e.g., trace packet generation engine 336 and/or path analysis engine 338 and can be in communication with the data store 334 via a communication link. The system 348 can include additional or fewer engines than illustrated to perform the various functions described herein. The system can represent software and/or hardware of a network controller (e.g., network controller 302 as referenced in Figure 3B, etc.).

[0030] The number of engines can include a combination of hardware and programming that is configured to perform a number of functions described herein. The programming can include program instructions (e.g., software, firmware, etc.) stored in a memory resource (e.g., computer readable medium, computer readable medium, etc.) as well as hard-wired program (e.g., logic).

[0031] For example, the trace packet generation engine 336 can include a combination of hardware and programming that is configured to allow definition of a trace packet for any of a plurality of protocols, register the trace packet to an existing flow based on a source address, a destination address, and a protocol of the trace packet, encipher the trace packet to generate a UID based on the trace packet, and/or inject the trace packet into the network via a specified port of a network device.

[0032] In some examples, the path analysis engine 338 can include a combination of hardware and programming that is configured to determine a programmed path of the trace packet based on the UID and the existing flow defined on the network device, allow assignment of an observation post to a network device along the programmed path of the trace packet, and/or instruct the observation post to send any packet that includes the UID to the path analysis engine.

[0033] The path analysis engine 338 can compare a fingerprint of a packet received from the observation post with the matching criteria (e.g., programmed path) of the trace packet and/or set a success status for the observation post in response to the fingerprint matching the matching criteria (e.g., programmed path). The path analysis engine 338 can allow reassignment of the observation post to a different network device along the programmed path of the trace packet in response to the success status being set.

[0034] In various examples, the path analysis engine 338 can identify the programmed path of the trace packet on a particular network device as being a point of failure in response to a next hop of the programmed path being undefined and in response to the destination address of the trace packet being different than an address of the particular network device.

[0035] The path analysis engine 338 can determine an expected path of the trace packet based on a source address of the trace packet, a destination address of the trace packet, and a topology of the network. The path analysis engine 338 can identify a next hop based on the expected path in response to a next hop of the programmed path being undefined and in response to a last hop of the programmed path being different than the destination address of the trace packet.

[0036] The path analysis engine 338 can use a cookie identifier to filter packets received from various network devices to classify the packets as trace packets (or not as trace packets). Each defined flow can have a respective cookie identifier associated therewith. The cookie identifier can link a particular flow to an application that defined the flow. Each application can have its own unique cookie identifier that it can add to flows that it defines. For example, a network device can have multiple flows defined thereon, where more than one of the multiple flows can share a cookie identifier if one application defined more than one flow on the network device. In some embodiments, when determining whether a trace packet has been received, the path analysis engine 338 can filter received packets using the cookie identifier to reduce the number of packets that undergo a more rigorous analysis to determine whether they are trace packets (e.g., inspecting the fingerprints and/or UIDs of the packets).

[0037] Each of the number of engines 336, 338 can include hardware and/or a combination of hardware and programming that can function as a corresponding module as described with respect to Figure 3B. For example, the trace packet generation engine 336 can include hardware and/or a combination of hardware and programming that can function as the trace packet generation module 346. In another example, the path analysis engine 338 can include hardware and/or a combination of hardware and programming that can function as the path analysis module 348.

[0038] Figure 3B is a diagram illustrating an example of a network controller 302 according to the present disclosure. The network controller 302 can utilize software, hardware, firmware, and/or logic to perform a number of functions. The network controller 302 can be a combination of hardware and program instructions configured to perform a number of functions (e.g., actions). The hardware, for example, can include a number of processing resources 340 and a number of memory resources 342, such as a computer-readable medium (CRM) or other memory resources 342. The memory resources 342 can be internal and/or external to the network controller 302 (e.g., the network controller 302 can include internal memory resources and have access to external memory resources). The program instructions (e.g., computer-readable instructions (CRI)) can include instructions stored on the CRM to implement a particular function (e.g., an action such as allocating bandwidth of an optical signal). The set of CRI can be executable by one or more of the processing resources 340. The memory resources 342 can be coupled to the network controller 302 in a wired and/or wireless manner. For example, the memory resources 342 can be an internal memory, a portable memory, a portable disk, and/or a memory associated with another resource, e.g., enabling CRI to be transferred and/or executed across a network such as the Internet.

[0039] Memory resources 342 can be non-transitory and can include volatile and/or non-volatile memory. Volatile memory can include memory that depends upon power to store information, such as various types of dynamic random access memory (DRAM) among others. Non-volatile memory can include memory that does not depend upon power to store information.

Examples of non-volatile memory can include solid state media such as flash memory, electrically erasable programmable read-only memory (EEPROM), phase change random access memory (PCRAM), magnetic memory such as a hard disk, tape drives, floppy disk, and/or tape memory, optical discs, digital versatile discs (DVD), Blu-ray discs (BD), compact discs (CD), and/or a solid state drive (SSD), etc., as well as other types of computer-readable media.

[0040] The processing resources 340 can be coupled to the memory resources 342 via a communication path 344. The communication path 344 can be local or remote to the network controller 302. Examples of a local

communication path 344 can include an electronic bus internal to a machine, where the memory resources 342 are in communication with the processing resources 340 via the electronic bus. Examples of such electronic buses can include Industry Standard Architecture (ISA), Peripheral Component

Interconnect (PCI), Advanced Technology Attachment (ATA), Small Computer System Interface (SCSI), Universal Serial Bus (USB), among other types of electronic buses and variants thereof. The communication path 344 can be such that the memory resources 342 are remote from the processing resources 340, such as in a network connection between the memory resources 342 and the processing resources 340. That is, the communication path 344 can be a network connection. Examples of such a network connection can include LAN, wide area network (WAN), PAN, and the Internet, among others.

[0041] As shown in Figure 3B, the CRI stored in the memory resources 342 can be segmented into a number of modules 336, 338 that when executed by the processing resources 340 can perform a number of functions. As used herein a module includes a set of instructions included to perform a particular task or action. The number of modules 346, 348 can be sub-modules of other modules. For example, the trace packet generation module 346 can be a sub- module of the path analysis module 348 and/or the trace packet generation module 346 and the path analysis module 348 can be contained within a single module. Furthermore, the number of modules 346, 348 can comprise individual modules separate and distinct from one another. Examples are not limited to the specific modules 346, 348 illustrated in Figure 3B.

[0042] The network controller 302 can include a trace packet generation module 346, which can generate a trace packet. The generated trace packet can include a source address matching a source address of an existing flow, a destination address matching a destination address of the existing flow, and a UID. The packet generation module 346 can inject the trace packet into a network via a specified port of a network device along a programmed path of the existing flow. The trace packet generation module can provide a scheme to create different packet types because different applications may use different packet types (e.g., different protocols) that may take different paths through the network even though they share a common source address and a common destination address. For example, a network administrator can use the network controller 302 to mimic a JavaScript Object Notation (JSON) packet schema and customize it for a specific packet protocol. The customized JSON trace packet model can then register with the network controller 302 (e.g., via an application programming interface (API) such as a representational state transfer (REST) invocation) to return the UID to the requester to interact with the system. The UID can be used in subsequent invocations of the trace packet for analyzing the path and/or determining a point of failure in the network. The trace packets can be enciphered to generate the UID to achieve uniqueness of the trace packets as they are reflected back to the network controller 302. In some examples the trace packet can be generated including the UID.

[0043] The network controller 302 can include a path analysis module 348, which can instruct an observation post, comprising a defined network device along the programmed path of the existing flow, to send any packet that includes the UID to the network controller for path analysis. In response to receiving a packet from the observation post having a fingerprint that matches the matching criteria (e.g., programmed path) of the existing flow, the path analysis module can inject the trace packet back into the network via the defined network device and instruct a different observation post, comprising a different network device downstream of the defined network device with respect to the existing flow, to send any packet that includes the UID to the network controller. The path analysis module 348 can set a success status for the observation post with respect to the trace packet in response to receiving a packet from the observation post having a fingerprint that matches the matching criteria (e.g., programmed path) of the existing flow.

[0044] Figure 4 is a flow chart illustrating an example of a method according to the present disclosure. At block 450, the method can include generating, via a network controller, an application specific trace packet having a source address and a destination address. At block 452, the method can include enciphering, via a network controller, the application specific trace packet with a UID. That is, the application specific trace packet can be generated including the UID (e.g., by enciphering the application specific trace packet to generate the UID and including the UID with the application specific trace packet) and/or the application specific trace packet can be enciphered to generate the UID.

[0045] At block 454, the method can include assigning, via the network controller, an observation post, comprising a first network device along a programmed path of the trace packet, to send a copy of a packet that includes the UID to the network controller. Assigning the observation post comprises adding a flow rule to an existing flow on the first network device instructing the first network device to send a packet of the existing flow that includes the UID to the network controller for inspection. Adding the flow rule comprises adding the flow rule with a higher priority than the existing flow.

[0046] At block 456, the method can include injecting the application specific trace packet from the network controller via a specified port of a second network device ahead of the first network device along the programmed path. Injecting the packet comprises injecting the packet on behalf of an end host via a specified port of the network device along the programmed path directly connected to the end host using a REST call.

[0047] At block 458, the method can include setting, via the network controller, a success status for the observation post in response to receiving the application specific trace packet at the network controller. Setting the success status comprises setting the success status in response to receiving the packet that includes the UID at the network controller and/or matching a fingerprint of the packet that includes the UID to the matching criteria (e.g., programmed path). The method can include querying, via the network controller, a status for the observation post to determine whether the success status has been set.

[0048] As used herein, "logic" is an alternative or additional processing resource to perform a particular action and/or function, etc., described herein, which includes hardware, e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc., as opposed to computer executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor.

[0049] As used herein, "a" or "a number of" something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets.

[0050] The above specification, examples and data provide a description of the method and applications, and use of the system and method of the present disclosure. Since many examples can be made without departing from the spirit and scope of the system and method of the present disclosure, this specification merely sets forth some of the many possible embodiment configurations and implementations.

Claims

What is claimed is:

1 . A non-transitory computer readable medium storing instructions executable by a processing resource to cause a software defined network (SDN) controller to:

generate a trace packet including:

a source address matching a source address of an existing flow; a destination address matching a destination address of the existing flow; and

a unique identifier (UID);

inject the trace packet into a network via a specified port of a network device along a programmed path of the existing flow; and

instruct an observation post, comprising a defined network device along the programmed path of the existing flow, to send any packet that includes the UID to the network controller for path analysis.

2. The medium of claim 1 , including instructions to, in response to receiving a packet from the observation post having a fingerprint that matches the programmed path of the existing flow:

inject the trace packet back into the network via the defined network device; and

instruct a different observation post, comprising a different network device downstream of the defined network device with respect to the existing flow, to send any packet that includes the UID to the network controller.

3. The medium of claim 1 , including instructions to set a success status for the observation post with respect to the trace packet in response to receiving a packet from the observation post having the UID.

4. A system for software defined network (SDN) control, comprising:

a trace packet generation engine to:

allow definition of a trace packet for any of a plurality of protocols; register the trace packet to an existing flow based on a source address, a destination address, and a protocol of the trace packet;

encipher the trace packet to generate a unique identifier (UID); and

inject the trace packet into the network via a specified port of a network device; and

a path analysis engine to:

determine a programmed path of the trace packet based on the UID and the existing flow defined on the network device;

allow assignment of an observation post to a network device along the programmed path of the trace packet; and

instruct the observation post to send any packet that includes the UID to the path analysis engine.

5. The system of claim 4, including the path analysis engine to:

compare a fingerprint of a packet received from the observation post with the programmed path of the trace packet; and

set a success status for the observation post with respect to the trace packet in response to the fingerprint matching the programmed path.

6. The system of claim 5, including the path analysis engine to allow reassignment of the observation post to a different network device along the programmed path of the trace packet in response to the success status being set.

7. The system of claim 4, including the path analysis engine to identify the programmed path of the trace packet on a particular network device as being a point of failure in response to:

a next hop of the programmed path being undefined; and

the destination address of the trace packet being different than an address of the particular network device.

8. The system of claim 4, including the path analysis engine to:

determine an expected path of the trace packet based on a source address of the trace packet, a destination address of the trace packet, and a topology of the network; and

identify a next hop based on the expected path in response to:

a next hop of the programmed path being undefined; and a last hop of the programmed path being different than the destination address of the trace packet.

9. The system of claim 4, including the path analysis engine to filter a plurality of received packets using a cookie identifier associated with the existing flow.

10. A method of path analysis in a software defined network (SDN), comprising:

generating, via a network controller, an application specific trace packet having a source address and a destination address;

enciphering, via a network controller, the application specific trace packet with a unique identifier (UID);

assigning, via the network controller, an observation post, comprising a first network device along a programmed path of the trace packet, to send a copy of a packet that includes the UID to the network controller;

injecting the application specific trace packet from the network controller via a specified port of a second network device; and

setting, via the network controller, a success status for the observation post in response to receiving the application specific trace packet at the network controller.

1 1 . The method of claim 10, wherein injecting the application specific trace packet includes injecting the application specific trace packet from the network controller via the specified port of the second network device.

12. The method of claim 10, wherein setting the success status comprises setting the success status in response to receiving the packet that includes the UID at the network controller and matching a fingerprint of the packet that includes the UID to the programmed path.

13. The method of claim 10, wherein assigning the observation post comprises adding a flow rule to an existing flow on the first network device instructing the first network device to send a packet of the existing flow that includes the UID to the network controller for inspection.

14. The method of claim 13, wherein adding the flow rule comprises adding the flow rule with a higher priority than the existing flow.

15. The method of claim 10, wherein injecting the packet comprises injecting the packet on behalf of an end host via a specified port of the network device along the programmed path directly connected to the end host using an application programming interface (API).