Systems and methods for non-intrusive network performance monitoring

A first network device may receive packets as part of a traffic flow of an internet protocol session, select a packet based on a rule, and add, to a packet replica of the selected packet, routing information capable of being used to generate performance indicators associated with the IP session. The first network device may modify a portion of the packet replica to include values that will cause the packet replica to fail to reach a destination device associated with the IP session, and provide the packet replica to other network devices to cause a second network device to perform a validation procedure to determine that the packet replica is unable to be validated based on the values, to generate the performance indicators using the packet replica or a group of packet replicas that have been modified, and to provide the performance indicators to a particular device.

BACKGROUND

Packet switching is a method of grouping data which is transmitted over a digital network into packets which are made of a header and a payload. Data in the header may be used by network devices to direct packets to destinations where the payload may be used as part of a service.

SUMMARY

According to some possible implementations, a first network device may include one or more memories and one or more processors, to: select a packet that is part of the traffic flow based on a rule. The one or more processors may generate a packet replica of the packet that has been selected. The one or more processors may add, to the packet replica, routing information that is capable of being used to generate network performance indicators associated with the IP session. The one or more processors may modify a portion of the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session. The one or more processors may provide the packet replica to one or more other network devices to cause a second network device, of the one or more other network devices, to perform a validation procedure to determine that the packet replica is unable to be validated based on the one or more values included in the packet replica, generate or cause another device to generate the network performance indicators using the packet replica or a group of packet replicas that have been modified, and provide or cause the other device to provide the network performance indicators to a particular device.

According to some possible implementations, a method may include receiving, by a first network device, packets as part of a traffic flow of an internet protocol (IP) session. The method may include selecting, by the first network device, a packet that is part of the traffic flow. The method may include generating, by the first network device, a packet replica of the packet that has been selected. The method may include adding, by the first network device and to the packet replica, routing information that is capable of being used to generate network performance indicators associated with the IP session. The method may include modifying, by the first network device, the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session. The method may include providing, by the first network device and as part of the traffic flow of the IP session, the packet replica to one or more other network devices to cause a second network device, of the one or more other network devices, to remove the packet replica from the traffic flow of the IP session based on the packet replica including the one or more values that have been modified, and to perform one or more actions that cause the network performance indicators to be generated and provided to another device.

According to some possible implementations, a non-transitory computer-readable medium may store instructions that include one or more instructions that, when executed by one or more processors of a network device, cause the one or more processors to receive, from another network device, a packet replica as part of a traffic flow of an internet protocol (IP) session. The packet replica may include routing information capable of being used to generate network performance indicators associated with the IP session. The packet replica may have been modified to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session. The one or more instructions may cause the one or more processors to perform a validation procedure by processing the packet replica. The packet replica may fail the validation procedure based on the one or more values included in the packet replica. The one or more instructions may cause the one or more processors to identify the routing information included in the packet replica based on the packet replica failing the validation procedure. The one or more instructions may cause the one or more processors to generate the network performance indicators using the packet replica or a group of packet replicas that have been modified and received over time. The one or more instructions may cause the one or more processors to provide the network performance indicators to a particular device.

DETAILED DESCRIPTION

A packet switched network may include network devices (e.g., switches, routers, and/or the like) that may send and/or receive packets as part of traffic flow of a session (e.g., an internet protocol (IP) session) for a service. In some cases, network congestion may cause the network devices to drop packets or to delay packet transmission of the packets. Additionally, paths through the packet switched network may change because of hardware failures and/or software failures associated with the network devices.

When a service is offered over the packet switched network, key performance metrics (referred to herein as network performance indicators) may be agreed upon between a network service provider and a customer. For example, a service-level agreement (SLA) between the network service provider and the customer may include stipulations that certain network performance indicators are to be monitored and/or satisfied (e.g., network devices may need to adhere to threshold levels of performance to be in compliance with terms of the SLA).

In some cases, to test the network performance indicators, the network service provider may configure the network devices to generate and transmit synthetic probe packets throughout the packet switched network and may process the synthetic probe packets to determine the network performance indicators.

However, the synthetic probe packets may be an ineffective solution for testing network performance indicators because the synthetic probe packets may display different forwarding behavior than packets of actual traffic flow of the IP session. For example, the synthetic probe packets may have different IP addresses than the packets of the actual traffic flow of the IP session (e.g., a different source IP address, a different destination IP address, etc.), may be a different packet size (e.g., in bytes) than the packets of the actual traffic flow of the IP session, may take different paths through the packet switched network than the packets of the actual traffic flow of the IP session, and/or the like. Other solutions may rely on changes to a forwarding plane of one or more network devices used to route the actual traffic flow of the IP session (e.g., by adding additional headers to the packets that are part of the actual traffic flow of the IP session). These solutions may be disruptive and difficult to implement in existing packet switched networks.

Some implementations described herein provide a first network device to generate packet replicas of packets that are part of a traffic flow of an IP session, and to intelligently modify the packet replicas such that a second network device will be able to use the packet replicas to generate network performance indicators associated with the IP session. For example, the first network device may receive packets as part of the traffic flow of the IP session, and may a select packet for further processing. The packet selected by may be part of a group of packets that are selected for further processing. In this case, the first network device may generate a packet replica of the packet, and may add, to the packet replica, routing information (e.g., segment routing operations, administration, and maintenance (OAM) information) that may be used to generate the network performance indicators.

Additionally, the first network device may modify the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session (e.g., by modifying a value in a header of the packet replica, such that the second network device is unable to validate the packet replica as a result of the modification). Furthermore, the first network device may provide the packet replica to one or more other network devices (e.g., downstream network devices) as part of the traffic flow of the IP session.

Furthermore, the packet replica may be provided to the second network device, which may perform a validation procedure on the packet replica and determine that the packet replica is unable to be validated. The packet replica may fail the validation procedure based on the modifications made to the packet replica by the first network device. This may cause the second network device to remove the packet replica from the traffic flow of the IP session. Additionally, the second network device may generate the network performance indicators using the packet replica (or a group of packet replicas that have been received over time) and may provide the network performance indicators to a network performance management platform that may be tasked with providing proof of compliance to various terms of an SLA.

In this way, the first network device and/or the second network device efficiently and effectively orchestrate accurate monitoring and reporting of network performance associated with the IP session. For example, by creating packet replicas that include the same IP address information as packets that are part of the traffic flow of the IP session, the first network device improves accuracy of the network performance indicators by enabling the packet replicas to exhibit the same forwarding behavior as the packets that are part of the traffic flow of the IP session. Additionally, using packet replicas to determine network performance indicators conserves resources (e.g., processing resources, network resources, and/or the like) relative to a solution that requires modifying a forwarding plane of one or more network devices. For example, using the packet replicas to determine the network performance indicators may conserve resources that might be expended modifying a forwarding plane configuration, resources spent processing new headers that are added to every packet that would be part of traffic flow of an IP session, and/or the like.

FIGS. 1A-1Care diagrams of an example implementation100described herein. For example, example implementation100may include a first session end-point for an internet protocol (IP) session (shown as Session End-Point A), a second session end-point for the IP session (shown as Session End-Point B), a group of network devices that are part of a network that is to be used to route traffic flow of the IP session and generate and/or report network performance indicators associated with the IP session, and one or more devices that may receive the network performance indicators (shown as a Network Performance Management Platform and a User Device). The group of network devices may include a first edge device (e.g., shown as Edge Device (ED)1), core network devices (e.g., shown as Core Network Device (CND)1through CND N), and a second edge device (e.g., shown as ED2). While not shown, in other cases, customer equipment may serve as intermediary devices between session end-points and edge devices of the network, and may assist in routing the traffic flow of the IP session.

As shown inFIG. 1A, and by reference number105, packets that are part of the traffic flow of the IP session may be routed between the first session end-point and the second session end-point via the network. The packets that are part of the IP session may be IP version 4 (IPv4) packets, IP version 6 (IPv6) packets, and/or the like.

The network may be a packet switched network, and the group of network devices that are part of the network may route the traffic flow using a tunneling technique, such as a generic routing encapsulation (GRE) technique, a multiprotocol label switching (MPLS) technique (e.g., an MPLS technique using user datagram protocol (UDP), an MPLS technique using GRE, and/or the like), a virtual extensible local area network (VXLAN) technique (e.g., using the generic protocol extension (GPE)), a generic network virtualization encapsulation (GENEVE) technique, and/or the like. Additionally, while the group of network devices described herein may be said to be routing layer 3 (L3) traffic, it is to be understood that this is provided by way of example. In practice, the group of network devices may be used to route layer 2 (L2) traffic or other types of traffic.

As shown by reference number110, the first edge device may select a packet that is part of the traffic flow for further processing. For example, the first edge device may select the packet to be used to generate a packet replica, which may be then used by one or more other devices to determine the network performance indicators associated with the IP session, as described further herein. Additionally, whileFIG. 1Ashows selection of a single packet, the first edge device may periodically select packets over time, such that a sampling of packets is collected and able to be used to generate a set of packet replicas.

In some implementations, the first edge device may select the packet based on a rule. The rule may include a first rule indicating to periodically select packets after a threshold time period (e.g., by selecting a first packet received after the threshold time period passes), a second rule indicating to randomly select packets (e.g., by randomly selecting a time until a next incoming packet is to be selected, by randomly selecting a number that indicates a number of incoming packets that are to be received before a packet is selected, and/or the like), a third rule indicating to select packets that include a particular IP address and/or identifier (e.g., a port identifier, a protocol identifier, and/or the like), a fourth rule indicating to select packets based on a routing or forwarding path of the packets, and/or the like.

To provide a few examples, assume that over time (e.g., several seconds, minutes, hours, etc.), a thousand packets are sent to the first edge device as part of the traffic flow of the IP session. In this example, if the first edge device is configured with the first rule, the first edge device may select a packet after a threshold time period passes (e.g., a millisecond, a second, etc.). As another example, assume the first edge device is configured with the second rule indicating to randomly select packets. In this example, the first edge device may use a random number generator to generate a random number (e.g., five) which may dictate the next packet that is selected (e.g., the first edge device may wait five seconds and select the next packet received, the first edge device may select a fifth incoming packet, and/or the like). In this way, the first edge device conserves processing resources and/or network resources relative to selecting and generating packet replicas of every packet that is part of the traffic flow of the IP session.

As shown by reference number115, the first edge device may generate a packet replica of the packet. For example, the first edge device may generate a packet replica of the packet that has identical values and/or properties as the packet. To provide a few examples, an IP address used for the packet may be the same IP address used for the packet replica, the packet and the replica packet may be the same size or length, the payload of the packet and the packet replica may include the same data, and/or the like.

In this way, as the traffic flow of the IP session is being routed through the network, the first edge device is able to select packets that are part of the traffic flow, and to generate packet replicas of the selected packets for further processing, as described further herein.

As shown inFIG. 1B, and by reference number120, the first edge device may add routing information to the packet replica. For example, the first edge device may add routing information (e.g., routing operations, administration, and maintenance (OAM) information) to a payload of the packet replica (e.g., by overriding the payload which is a copy of the payload of the original packet). Additionally, or alternatively, the first edge device may add a new header (e.g., a transport header) to the packet replica and may include the routing information in the new header.

The routing information may include any information that may be available to the first edge device and that may be used by other network devices for determining network performance indicators (e.g., latency, jitter, packet loss, and/or the like). For example, the routing information may include session information for the IP session, packet replica information for packet replicas sent through the network as part of the IP session, and/or the like.

The session information may include a session identifier of the IP session, a start time for the session, a total time the session has been active, a customer identifier associated with the IP session, and/or the like. The packet replica information may include a packet sequence identifier for a packet replica (e.g., which may be used to determine a sequence in which packet replicas are sent or received), a packet time stamp (e.g., indicating a time a packet replica is sent or received by a network device, one or more interface identifiers (e.g., indicating an interface a packet replica is sent from or received at), a path identifier that identifies a path used to route or forward the packet replica within the network (e.g., by identifying particular network devices or components of network devices that the packet replica traveled through), and/or the like.

As shown by reference number125, the first edge device may modify the packet replica. For example, the first edge device may modify a header of the packet replica to include one or more values that will cause the packet replica to fail to reach the second session end-point (e.g., Session End-Point B). In this case, the second edge device (e.g., Edge Device2) may be configured to attempt to validate all packets that are part of the traffic flow of the IP session, and may be able unable to validate the packet replica based on the one or more values that are modified in the header, as described further herein.

In some implementations, the first edge device may modify a checksum value in the header of the packet replica. For example, if the packet replica is an IPv4 packet, the first edge device may set an IPv4 header checksum value to an incorrect value that may cause a checksum validation error when the packet replica is processed by the second edge device.

Additionally, or alternatively, the first edge device may modify a packet length value in the header of the packet replica. For example, the first edge device may set a packet length value to an incorrect value that does not match an actual length of the packet replica. This may cause a packet length validation error when the packet replica is processed by the second edge device.

Additionally, or alternatively, the first edge device may modify a time to live (TTL) value in the header of the packet replica. For example, the first edge device may set a TTL value to a particular value (e.g., 0, 1, etc.) that may trigger a validation error when the packet replica is processed by second edge device.

As shown by reference number130, the first edge device may provide the packet replica to a first core network device as part of the traffic flow of the IP session. For example, the first edge device may use a forwarding plane for determining how to route the traffic flow of the IP session (e.g., which may indicate that a next hop is the first core network device). This may cause the packet replica to be routed through the network, to the second edge device, using a path that is also used by the packets that are part of the traffic flow of the IP session.

As shown by reference number135, the second edge device may remove the packet replica from the traffic flow of the IP session. For example, the second edge device may remove the packet replica from the traffic flow of the IP session based on determining that the packet replica does not conform to one or more requirements of a validation procedure. In this case, the second edge device may perform a validation procedure on the packet replica, and the packet replica may fail the validation procedure based on the modifications that were made to the header of the packet replica.

As an example, assume the first edge device modified a checksum value in the header of the packet replica. In this example, the second edge device may perform a checksum validation procedure by comparing the checksum value to a configured checksum value. If the checksum value and the configured checksum value do not match, the second edge device may generate a validation error, increment an error counter, and/or the like, which may cause the second edge device to remove the packet replica from the traffic flow of the IP session.

As another example, assume the first edge device modified a packet length value in the header of the packet replica. In this example, the second edge device may perform a packet length validation procedure that involves processing the packet replica to generate a value identifying an actual packet length, and comparing the value identifying the actual packet length to the packet length value included in the header. If the value identifying the actual packet length does not match the packet length value in the header, the second edge device may generate a validation error, increment an error counter, and/or the like, which may cause the second edge device to remove the packet replica from the traffic flow of the IP session.

As another example, assume the first edge device modified a TTL value in the header of the packet replica. In this example, the second edge device may perform a TTL validation procedure that involves processing the packet replica to determine that the TTL value satisfies an error threshold (e.g., a value of 0, a value of 0 or 1, etc.). If the TTL value satisfies the error threshold, the first edge device may generate a validation error, increment an error counter, perform a protocol-specific action (e.g., send a message, such as an internet control message protocol (ICMP) TTL expiry message, to a source device), and/or the like. This may cause the second edge device to remove the packet replica from the traffic flow of the IP session.

As shown by reference number140, the second edge device may identify the routing information included in the packet replica. For example, the second edge device may identify the routing information after removing the packet replica from the traffic flow, after the packet replica fails the validation procedure, and/or the like. In this case, the second edge device may be configured to identify values that are not typically included in the packets that are part of the traffic flow of the IP session. As such, the second edge device may identify the routing information by processing the new header of the packet replica or the payload of the packet replica. This may allow the second edge device to use the routing information to generate or cause another device to generate the network performance indicators, as described further herein.

By adding the routing information to the packet replica, the first network device ensures that the packet replica includes information that will be needed to monitor network performance. Furthermore, by modifying one or more values of the packet replica, the first edge device ensures that the second network device will detect and remove the packet replica from the traffic flow of the IP session, thereby preventing the packet replica from interfering with the IP session by reaching the second session end-point.

As shown inFIG. 1C, the second edge device, or the network performance management platform, may be configured to determine the network performance indicators. For example, and as shown by reference number145-1, the second edge device may determine the network performance indicators (e.g., latency, jitter, packet loss, packet delay, and/or the like) by processing the routing information of the packet replica or a group of packet replicas that are identified over a particular time period.

In some implementations, the second edge device may determine latency for the packet replica or the group of packet replicas. For example, the second edge device may determine latency for the packet replica from a first network device to a second network device (e.g., from the first edge device to the first core network device, from the first edge device to the second edge device, and/or the like). In this case, the second edge device may determine the latency by calculating a time needed for the packet replica to be provided from the first network device to the second network device. In some cases, the second edge device may send the packet replica (or the group of packet replicas) back to the second network device, such that latency may be measured by considering a round trip time (RTT) of the packet replica (or the group of packet replicas).

Additionally, or alternatively, the second edge device may determine jitter for the packet replica or the group of packet replicas. For example, the second edge device may determine jitter for the group of packet replicas as the group of packet replicas travel from a first network device to a second network device. In this case, the second edge device may determine jitter by calculating a variance in the latency of the group of packet replicas.

Additionally, or alternatively, the second edge device may determine packet loss or packet delay for the packet replica or the group of packet replicas. For example, if the routing information for each packet replica indicates a packet sequence number, the second edge device may determine packet loss by identifying whether packet replicas are missing (e.g., based on the group of packet replicas including some, but not all, of the packet sequence numbers). A similar technique may be implemented to determine packet delay.

As shown by reference number150-1, the second edge device may provide the network performance indicators to the network performance management platform. For example, the second edge device may use a communication interface (e.g., an application programming interface (API) or another type of interface) to provide the network performance indicators to the network performance management platform. As shown by reference number155-1, the network performance management platform may store the network performance indicators.

As shown by reference number160-1, the second edge device may provide the network performance to the user device. For example, the second edge device may use a communication interface (e.g., an application programming interface (API) or another type of interface) to provide the network performance indicators to the user device. The user device may be a device of an organization providing network services, a device of an organization using the network services, and/or the like.

As shown by reference number165-1, a user interface of the user device my display the network performance indicators. This may allow users to identify network performance indicators, to verify whether the traffic flow of the IP session is in conformance with a service-level agreement (SLA) (which may specify certain threshold performance metrics that are to be satisfied), and/or the like.

In some implementations, assume the network performance management platform is configured to determine the network performance indicators. In this case, and as shown by reference number145-2, the second edge device may provide, to the network performance management platform, the routing information for the packet replica or for a group of packet replicas. As an example, the second edge device may be configured to provide the routing information for packet replicas as soon as the routing information is identified. As another example, the second edge device may be configured to periodically provide routing information for a group of packet replicas that have been identified over time.

As shown by reference number150-2, the network performance management platform may determine the network performance indicators. For example, the network performance management platform may determine latency, jitter, packet loss, packet delay, and/or the like, in a manner described above.

As shown by reference number155-2, the network performance management platform may provide the network performance to the user device. For example, the network performance management platform may use the communication interface to provide the network performance indicators to the user device. As shown by reference number165-2, the user interface of the user device may display the network performance indicators.

In some implementations, the second edge device and/or the network performance management platform may perform one or more actions associated with assisting in reporting and/or improving network performance. For example, the second edge device and/or the network performance management platform may be configured to automatically generate and provide, to a device associated with the network service provider and/or a device associated with the customer, a notification indicating that one or more terms of a service-level agreement (SLA) are not presently satisfied. In some cases, the notification may be generated and provided based on a network performance indicator satisfying a threshold level of performance (e.g., a level associated with poor performance, a level that allows the network service provider to fix a performance problem prior to breaching the SLA, and/or the like).

Additionally, or alternatively, the second edge device and/or the network performance management platform may be configured to generate instructions to repair an error (e.g., a hardware error, a software error, etc.) that is affecting network performance and/or to automatically repair the error. For example, the second edge device may use the routing information to identify an error that is likely to be a cause of poor network performance. In this case, the second edge device may be configured with rules that associate particular errors with particular actions, and may reference the rules to determine a particular action to perform or to recommend that another device perform.

In this way, the first network device and/or the second network device efficiently and effectively orchestrate accurate monitoring and reporting of network performance. For example, by creating packet replicas that include the same IP address information as packets that are part of the traffic flow of the IP session, the first network device improves accuracy of the network performance indicators by enabling the packet replicas to exhibit the same forwarding behavior as the packets that are part of the traffic flow of the IP session.

As indicated above,FIGS. 1A-1Care provided merely as an example. Other examples are possible and may differ from what was described with regard toFIGS. 1A-1C. For example, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown inFIGS. 1A-1C. Furthermore, two or more devices shown inFIGS. 1A-1Cmay be implemented within a single device, or a single device shown inFIGS. 1A-1Cmay be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of example implementations100may perform one or more functions described as being performed by another set of devices of example implementations100.

FIG. 2is a diagram of an example environment200in which systems and/or methods, described herein, may be implemented. As shown inFIG. 2, environment200may include one or more peer devices210, a group of network devices220(shown as Network Device220-1through Network Device220-N), a network performance management platform230, and/or a network250. Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Peer device210includes one or more devices capable of receiving and/or providing network traffic. For example, peer device210may include a traffic transfer device, such as a router, a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a server executing a virtual machine, etc.), a security device, an intrusion detection device, a load balancer, or a similar type of device. Additionally, or alternatively, peer device210may include an endpoint device that is a source or a destination for network traffic. For example, peer device210may include a computer or a similar type of device. Peer device210may receive network traffic from and/or may provide network traffic to other peer devices210via network250(e.g., by routing packets using network device(s)220as an intermediary). In some implementations, peer device210may provide traffic flow of an internet protocol (IP) session to network device220(e.g., an edge device in a network, a core network device, and/or the like).

Network device220includes one or more devices capable of receiving, processing, storing, routing, and/or providing traffic (e.g., a packet, a packet replica, other information or metadata, and/or the like) in a manner described herein. For example, network device220may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router, a provider core router, etc.), a virtual router, and/or the like. Additionally, or alternatively, network device220may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, a data center server, etc.), a load balancer, and/or a similar device. In some implementations, network device220may be a physical device implemented within a housing, such as a chassis.

In some implementations, network device220may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center. In some implementations, a group of network devices220may include a first network device220, one or more core network devices220, a second network device220, and/or the like. In some implementations, network device220may route the traffic flow using a tunneling technique, such as a generic routing encapsulation (GRE) technique, a multiprotocol label switching (MPLS) technique (e.g., an MPLS technique using user datagram protocol (UDP), an MPLS technique using GRE, and/or the like), a virtual extensible local area network (VXLAN) technique (e.g., using the generic protocol extension (GPE)), a generic network virtualization encapsulation (GENEVE) technique, and/or the like.

Network performance management platform230includes one or more devices capable of receiving, storing, processing, generating, and/or providing information associated with network performance indicators. For example, network performance management platform230may include a server device (e.g., a host server, a web server, an application server, etc.), a data center device, or a similar device.

In some implementations, as shown, network performance management platform230may be hosted in cloud computing environment240. Notably, while implementations described herein describe network performance management platform230as being hosted in cloud computing environment240, in some implementations, network performance management platform230may not be cloud-based (i.e., may be implemented outside of a cloud computing environment) or may be partially cloud-based.

Cloud computing environment240includes an environment that hosts network performance management platform230. Cloud computing environment240may provide computation, software, data access, storage, etc. services that do not require end-user knowledge of a physical location and configuration of system(s) and/or device(s) that hosts network performance management platform230. As shown, cloud computing environment240may include a group of computing resources235(referred to collectively as “computing resources235” and individually as “computing resource235”).

Computing resource235includes one or more personal computers, workstation computers, server devices, or another type of computation and/or communication device. In some implementations, computing resource235may host network performance management platform230. The cloud resources may include compute instances executing in computing resource235, storage devices provided in computing resource235, data transfer devices provided by computing resource235, and/or the like. In some implementations, computing resource235may communicate with other computing resources235via wired connections, wireless connections, or a combination of wired and wireless connections.

As further shown inFIG. 2, computing resource235may include a group of cloud resources, such as one or more applications (“APPs”)235-1, one or more virtual machines (“VMs”)235-2, virtualized storage (“VSs”)235-3, one or more hypervisors (“HYPs”)235-4, and/or the like.

Application235-1may include one or more software applications that may be provided to or accessed by another device described herein. Application235-1may eliminate a need to install and execute the software applications on these devices. For example, application235-1may include software associated with network performance management platform230and/or any other software capable of being provided via cloud computing environment240. In some implementations, one application235-1may send/receive information to/from one or more other applications235-1, via virtual machine235-2.

FIG. 3is a diagram of example components of a device300. Device300may correspond to peer device210and/or network device220. In some implementations, peer device210and/or network device220may include one or more devices300and/or one or more components of device300. As shown inFIG. 3, device300may include one or more input components305-1through305-B (B≥1) (hereinafter referred to collectively as input components305, and individually as input component305), a switching component310, one or more output components315-1through315-C (C≥1) (hereinafter referred to collectively as output components315, and individually as output component315), and a controller320.

Input component305may be points of attachment for physical links and may be points of entry for incoming traffic, such as packets. Input component305may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component305may send and/or receive packets. In some implementations, input component305may include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and/or input queues. In some implementations, device300may include one or more input components305.

Switching component310may interconnect input components305with output components315. In some implementations, switching component310may be implemented via one or more crossbars, via busses, and/or with shared memories. The shared memories may act as temporary buffers to store packets from input components305before the packets are eventually scheduled for delivery to output components315. In some implementations, switching component310may enable input components305, output components315, and/or controller320to communicate.

Output component315may store packets and may schedule packets for transmission on output physical links. Output component315may support data link layer encapsulation or decapsulation, and/or a variety of higher-level protocols. In some implementations, output component315may send packets and/or receive packets. In some implementations, output component315may include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and/or output queues. In some implementations, device300may include one or more output components315. In some implementations, input component305and output component315may be implemented by the same set of components (e.g., and input/output component may be a combination of input component305and output component315).

Controller320includes a processor in the form of a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and/or another type of processor. The processor is implemented in hardware, firmware, or a combination of software and hardware. In some implementations, controller320may include one or more processors that can be programmed to perform a function.

In some implementations, controller320may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and/or instructions for use by controller320.

In some implementations, controller320may communicate with other devices, networks, and/or systems connected to device300to exchange information regarding network topology. Controller320may create routing tables based on the network topology information, create forwarding tables based on the routing tables, and forward the forwarding tables to input components305and/or output components315. Input components305and/or output components315may use the forwarding tables to perform route lookups for incoming and/or outgoing packets. In some cases, controller320may create a session table based on information determined while initializing a link fault detection (e.g., BFD) session, and may forward the session table to input components305and/or output components315.

FIG. 4is a flow chart of an example process400for non-intrusive monitoring of network performance of a group of network devices used to support traffic flow of an internet protocol (IP) session. In some implementations, one or more process blocks ofFIG. 4may be performed by a first network device (e.g., network device220). In some implementations, one or more process blocks ofFIG. 4may be performed by another device or a group of devices separate from or including the first network device, such as a peer device (e.g., peer device210), one or more other network devices220, such as a second network device, a network performance management platform (e.g., network performance management platform230), a computing resource (e.g., computing resource235), and/or the like.

As shown inFIG. 4, process400may include receiving packets as part of a traffic flow of an internet protocol (IP) session (block410). For example, the first network device (e.g., using input component305, switching component310, controller320, and/or the like) may receive packets as part of a traffic flow of an internet protocol (IP) session, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 4, process400may include selecting a packet that is part of the traffic flow based on a rule (block420). For example, the first network device (e.g., using input component305, switching component310, controller320, and/or the like) may select a packet that is part of the traffic flow based on a rule, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 4, process400may include generating a packet replica of the packet that has been selected (block430). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may generate a packet replica of the packet that has been selected, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 4, process400may include adding, to the packet replica, routing information that is capable of being used to generate network performance indicators associated with the IP session (block440). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may add, to the packet replica, routing information that is capable of being used to generate network performance indicators associated with the IP session, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 4, process400may include modifying a portion of the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session (block450). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may modify a portion of the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 4, process400may include providing the packet replica to one or more other network devices to cause a second network device, of the one or more other network devices, to: perform a validation procedure to determine that the packet replica is unable to be validated based on the one or more values included in the packet replica, generate or cause another device to generate the network performance indicators using the packet replica, and provide or cause the other device to provide the network performance indicators to a particular device (e.g., (block460). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may provide the packet replica to one or more other network devices to cause a second network device, of the one or more other network devices, to perform a validation procedure to determine that the packet replica is unable to be validated based on the one or more values included in the packet replica, generate or cause another device to generate the network performance indicators using the packet replica, and provide or cause the other device to provide the network performance indicators to a particular device, as described below and as described above with regard toFIGS. 1A-1C.

In some implementations, a forwarding plane of the first network device may not be modified when modifying the portion of the packet replica. In some implementations, when providing the packet replica to the one or more other network devices, the first network device may provide, to the one or more other network devices, the packet replica as part of the traffic flow of the IP session.

In some implementations, the packet replica or the group of packet replicas may have IP address information that matches the IP address information of the packets that are part of the traffic flow of the IP session. In some implementations, the rule may be a first rule indicating to randomly select particular packets after a threshold time period, a second rule indicating to select the particular packets based on the particular packets including a particular IP address or protocol identifier, or a third rule indicating to select the particular packets based on a routing or forwarding path of the particular packets.

In some implementations, the traffic flow may be supported by a label switching network, and the routing information may include segment routing operations, administration, and maintenance (OAM) information. In some implementations, when modifying the portion of the packet replica, the first network device may set an IP header checksum value to a first incorrect value, set a packet length value to a second incorrect value, or set an IP header time to live (TTL) value to a third incorrect value.

FIG. 5is a flow chart of an example process500for non-intrusive monitoring of network performance of a group of network devices used to support traffic flow of an internet protocol (IP) session. In some implementations, one or more process blocks ofFIG. 5may be performed by a first network device (e.g., network device220). In some implementations, one or more process blocks ofFIG. 5may be performed by another device or a group of devices separate from or including the first network device, such as a peer device (e.g., peer device210), a network performance management platform (e.g., network performance management platform230), a computing resource (e.g., computing resource235), and/or the like.

As shown inFIG. 5, process500may include receiving packets as part of a traffic flow of an internet protocol (IP) session (block510). For example, the first network device (e.g., using input component305, switching component310, controller320, and/or the like) may receive packets as part of a traffic flow of an internet protocol (IP) session, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 5, process500may include selecting a packet that is part of the traffic flow (block520). For example, the first network device (e.g., using input component305, switching component310, controller320, and/or the like) may select a packet that is part of the traffic flow, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 5, process500may include generating a packet replica of the packet that has been selected (block530). For example, the first network device (e.g., using switching component310, controller320, and/or the like) may generate a packet replica of the packet that has been selected, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 5, process500may include adding, to the packet replica, routing information that is capable of being used to generate network performance indicators associated with the IP session (block540). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may add, to the packet replica, routing information that is capable of being used to generate network performance indicators associated with the IP session, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 5, process500may include modifying the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session (block550). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may modify the packet replica to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 5, process500may include providing, as part of the traffic flow of the IP session, the packet replica to one or more other network devices to cause a second network device, of the one or more other network devices, to remove the packet replica from the traffic flow of the IP session based on the packet replica including the one or more values that have been modified, and to perform one or more actions that cause the network performance indicators to be generated and provided to another device (block560). For example, the first network device (e.g., using switching component310, output component315, controller320, and/or the like) may provide, as part of the traffic flow of the IP session, the packet replica to one or more other network devices to cause a second network device, of the one or more other network devices, to remove the packet replica from the traffic flow of the IP session based on the packet replica including the one or more values that have been modified, and to perform one or more actions that cause the network performance indicators to be generated and provided to another device, as described above with regard toFIGS. 1A-1C.

In some implementations, a forwarding plane of the first network device may not be modified when modifying the portion of the packet replica. In some implementations, the network performance indicators may be generated based on the packet replica or a group of packet replicas, and the packet replica or the group of packet replicas may have IP address information that matches the IP address information of the packets that are part of the traffic flow of the IP session.

In some implementations, the first network device may select the packet based on at least one of: a first rule indicating to select particular packets after a threshold time period, a second rule indicating to randomly select the particular packets, a third rule indicating to select the particular packets based on the particular packets including a particular IP address or identifier, or a fourth rule indicating to select the particular packets based on a routing or forwarding path of the particular packets. In some implementations, the routing information may include at least one of: session information for the IP session or packet replica information for the packet replica or the group of packet replicas.

In some implementations, adding the routing information may include adding the routing information to the packet replica as an additional header of the packet replica or as part of a payload of the packet replica. In some implementations, modifying the packet replica may include setting an IP header checksum value to a first incorrect value, setting a packet length value to a second incorrect value, or setting an IP header time to live (TTL) value to a third incorrect value.

FIG. 6is a flow chart of an example process600for non-intrusive monitoring of network performance of a group of network devices used to support traffic flow of an internet protocol (IP) session. In some implementations, one or more process blocks ofFIG. 6may be performed by a network device (e.g., network device220). In some implementations, one or more process blocks ofFIG. 6may be performed by another device or a group of devices separate from or including the network device, such as a peer device (e.g., peer device210), another network device (e.g., a different network device220), a network performance management platform (e.g., network performance management platform230), a computing resource (e.g., computing resource235), and/or the like.

As shown inFIG. 6, process600may include receiving, from another network device, a packet replica as part of a traffic flow of an internet protocol (IP) session, wherein the packet replica includes routing information capable of being used to generate network performance indicators associated with the IP session, and wherein the packet replica has been modified to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session (block610). For example, the network device (e.g., using input component305, switching component310, controller320, and/or the like) may receive, from another network device, a packet replica as part of a traffic flow of an IP session, as described above with regard toFIGS. 1A-1C. In some implementations, the packet replica may include routing information capable of being used to generate network performance indicators associated with the IP session, and the packet replica may have been modified to include one or more values that will cause the packet replica to fail to reach a destination device associated with the IP session.

As further shown inFIG. 6, process600may include performing a validation procedure by processing the packet replica, wherein the packet replica is to fail the validation procedure based on the one or more values included in the packet replica (block620). For example, the network device (e.g., using input component305, switching component310, controller320, and/or the like) may perform a validation procedure by processing the packet replica, as described above with regard toFIGS. 1A-1C. In some implementations, the packet replica may fail the validation procedure based on the one or more values included in the packet replica.

As further shown inFIG. 6, process600may include identifying the routing information included in the packet replica based on the packet replica failing the validation procedure (block630). For example, the network device (e.g., using input component305, switching component310, controller320, and/or the like) may identify the routing information included in the packet replica based on the packet replica failing the validation procedure, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 6, process600may include generating the network performance indicators using the packet replica or a group of packet replicas that have been modified and received over time (block640). For example, the network device (e.g., using switching component310, output component315, controller320, and/or the like) may generate the network performance indicators using the packet replica or a group of packet replicas that have been modified and received over time, as described above with regard toFIGS. 1A-1C.

As further shown inFIG. 6, process600may include providing the network performance indicators to a particular device (block650). For example, the network device (e.g., using switching component310, output component315, controller320, and/or the like) may provide the network performance indicators to a particular device, as described above with regard toFIGS. 1A-1C.

In some implementations, a forwarding plane used to route the traffic flow may not be modified when the one or more values of the packet replica are modified. In some implementations, the packet replica or the group of packet replicas may have IP address information that matches the IP address information of the packets that are part of the traffic flow of the IP session. In some implementations, the traffic flow of the IP session may be subject to a service-level agreement (SLA) that requires the network performance indicators to conform to a particular standard.

In some implementations, when performing the validation procedure, the network device may process the packet replica to determine that a header of the packet replica includes a first value that causes the packet replica to fail the validation procedure, where the first value is an IP header checksum value, a packet length value, or an IP header time to live (TTL) value. In some implementations, the network performance indicators may include at least one of: a first network performance indicator to verify an order in which packets are received, a second network performance indicator to identify packet loss, or a third network performance indicator to identify packet delay.

As used herein, the term traffic flow may include a set of packets. A packet may refer to a communication structure for communicating information, such as a protocol data unit (PDU), a network packet, a datagram, a segment, a message, a block, a cell, a frame, a subframe, a slot, a symbol, a portion of any of the above, and/or another type of formatted or unformatted unit of data capable of being transmitted via a network.