Isolating service faults using loopbacks

A device may receive an indication to perform a loopback test to identify a source of a communication error among a set of devices. The device may configure a value in a data structure to permit identification of a set of packets during the loopback test. The value may be associated with a parameter related to the set of packets. The device may perform the loopback test using the set of packets. A header of the set of packets may be configured with a same value for a same parameter as the value configured in the data structure. The device may identify the source of the communication error based on a result of performing the loopback test. The device may perform an action related to addressing the communication error based on identifying the source of the communication error.

BACKGROUND

Loopback, or loop-back, may refer to the routing of electronic signals, digital data streams, or flows of items back to a source without intentional processing or modification. Loopback may permit testing of a transmission performance of one or more electronic devices, and/or a transportation infrastructure (e.g., communications network).

SUMMARY

According to some possible implementations, a device may include one or more processors to receive an indication to perform a loopback test to identify a source of a communication error associated with a set of links among a set of devices. The one or more processors may configure a value in a type-length-value (TLV) element to permit or cause an action to be performed with respect to a set of packets based on the value. The value may be associated with a parameter associated with the set of packets. The value may be used to identify the set of packets during the loopback test. The one or more processors may perform the loopback test using the set of packets. A header of the set of packets may be configured with a same value for a same parameter as the value configured in the TLV element. The one or more processors may identify the source of the communication error based on a result of performing the loopback test. The one or more processors may perform another action related to fixing the communication error based on identifying the source of the communication error.

According to some possible implementations, a non-transitory computer-readable medium may store one or more instructions that, when executed by one or more processors, cause the one or more processors to receive an indication to perform a loopback test using a set of packets. The loopback test may be used to identify a source of a communication error associated with a set of links among a set of devices. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to configure a value in a type-length-value (TLV) element to permit or cause an action to be performed with respect to the set of packets. The value may be used to determine whether the set of packets is to be looped back during the loopback test. The value may be associated with a parameter related to the set of packets.

The one or more instructions, when executed by the one or more processors, may cause the one or more processors to perform the loopback test using the set of packets. A header of the set of packets may be configured with a same value for a same parameter as the value configured in the TLV element. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to identify the source of the communication error based on a result of performing the loopback test. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to perform another action related to addressing the communication error based on identifying the source of the communication error.

According to some possible implementations, a method may include receiving, by a device, an indication to perform a loopback test to identify a source of a communication error among a set of devices. The method may include configuring, by the device, a value in a data structure to permit identification of a set of packets during the loopback test. The value may be associated with a parameter related to the set of packets. The method may include performing, by the device, the loopback test using the set of packets. A header of the set of packets may be configured with a same value for a same parameter as the value configured in the data structure. The method may include identifying, by the device, the source of the communication error based on a result of performing the loopback test. The method may include performing, by the device, an action related to addressing the communication error based on identifying the source of the communication error.

DETAILED DESCRIPTION

A network of network devices may be experiencing communication errors on a set of links among the network devices. For example, the network devices may be experiencing congestion on the set of links, dropped packets, a bit rate that fails to satisfy a threshold, jitter, and/or the like. A network administrator associated with the network may want to perform a set of loopback tests on the set of links to identify a source of the communication errors. Although performing the set of loopback tests may permit the network administrator to identify a source of the communication errors, the set of loopback tests may disrupt all communications on the set of links, including communications that are not experiencing communication errors (e.g., some layer two communications, of the Open Systems Interconnection (OSI) model, may be experiencing communication errors while other layer two communications on the same link are not experiencing communication errors). This may negatively impact a performance of a network.

Some implementations, described herein, provide a network device to configure a type-length-value (TLV) element in a manner that permits another network device, on which a loopback test is being performed, to determine whether to loop back a packet to the network device, to provide the packet to a destination, or to perform another action related to the packet after receiving the packet from the network device. In this way, the network device may permit another network device to dynamically and selectively loop back a packet for a loopback test without looping back all packets received from the network device. This reduces or eliminates disruptions to communications during performance of a loopback test, thereby improving communications among a set of network devices during a loopback test. In addition, this permits the network device to test particular layer two communications, or communications of other layers, without disrupting all layer two, or other layer, communications, thereby improving a test of layer two, or other layer, communications.

FIGS. 1A-1Care diagrams of an overview of an example implementation100described herein. For illustration, implementation100includes a client device, and three network devices, shown as network devices ND1, ND2, and ND3. AlthoughFIGS. 1A-1Cshow a single client device and three network devices, in practice, there may be thousands, millions, billions, etc. of client devices and/or network devices.

As shown inFIG. 1A, and by reference number105, network device ND1may receive an indication, from the client device (e.g., based on input from a user of the client device), to perform a loopback test to identify a source of a communication error on a set of links among a set of network devices (e.g., network devices ND1through ND3). Network device ND1may receive the indication based on detecting a communication error on a link among network devices ND1, ND2, and ND3. A communication error may include congestion, packet loss, jitter, a bit rate that fails to satisfy a threshold, and/or the like. AlthoughFIG. 1Ashows network device ND1receiving the indication, any one of network devices ND1, ND2, and/or ND3may receive the indication to perform the loopback test.

As shown by reference number110, network device ND1may configure a value of a parameter in a type-length-value (TLV) element that identifies a set of packets to permit and/or cause an action to be performed with respect to the set of packets based on the value. Network device ND1may configure the TLV with information identifying a parameter, such as a media access control (MAC) address, an Internet protocol (IP) address, information identifying a specific protocol being used (e.g., IP, transmission control protocol (TCP), border gateway protocol (BGP), and/or the like), a port identifier used to provide and/or receive communications, an EtherType, and/or the like.

In some implementations, the value of the parameter in the TLV element may indicate that the packet is to be looped back in association with a loopback test. Conversely, the value of the parameter in the TLV element may indicate that the packet is not to be looped back as part of a loopback test. In this way, network devices ND1through ND3may use a value of a TLV to determine which packets are to be looped back in association with a loopback test.

Network device ND1may provide a set of instructions to network device ND2indicating whether the value of the parameter in the TLV element indicates that the packet is to be looped back. In addition, network device ND2may provide a similar set of instructions to network device ND3. Additionally, or alternatively, network device ND1may provide information indicating the value of the parameter in the TLV element that network device ND1is configuring, thereby permitting network device ND2to configure a TLV element stored by network devices ND2with the same value that network device ND1configured. In addition, network device ND2may provide similar information to network device ND3.

Network device ND1may store (e.g., in a table, a list, a data structure, etc.), the TLV element. For example, and as shown by reference number115, network device ND1may store information identifying a parameter for which a value is being configured in the TLV element. In addition, network device ND1may store information identifying the value of the parameter in the TLV element. As shown by reference number120, network device ND1may configure the TLV element with information identifying a MAC address as the parameter to be used to determine whether to loop back a packet and that the value for the parameter is “A:B:C.”

As shown inFIG. 1B, and by reference number125, network device ND1may perform the loopback test using the set of packets with a same value for a same parameter as was configured for the TLV element. For example, network device ND1may perform the loopback test using a set of packets that includes information in a header of the set of packets identifying “A:B:C” as a MAC address associated with the set of packets.

As shown by reference number130, network device ND1may provide the set of packets to network device ND2in association with a loopback test. In some implementations, network device ND1may provide thousands, millions, billions, etc., of packets when providing the set of packets. Additionally, or alternatively, network device ND1may provide packets not associated with the loopback test (e.g., packets that are associated with other communications). For example, network device ND1may provide packets that do not have the same value for the same parameter that network device ND1configured for the TLV element (e.g., packets that include information in a header of the packets identifying a different MAC address than “A:B:C”).

As shown by reference number135, network device ND2may loop back the set of packets. For example, network device ND2may loop back the set of packets that have the same value for the same parameter as was configured for the TLV element (e.g., the set of packets configured with information in a header of the set of packets identifying “A:B:C” as the MAC address associated with the set of packets). In this way, network device ND2may loop back a portion of the packets received from network device ND1.

As shown by reference number140, network device ND1may receive the set of packets that was looped back by network device ND2(e.g., when, or based on, monitoring a link to receive a portion of the set of packets). As shown by reference number145, network device ND1may record information related to the set of packets provided to network device ND2with the same value for the same parameter as was configured for the TLV element (e.g., using a counter). For example, network device ND1may record that for MAC address “A:B:C,” a quantity of packets sent by network device ND1to network device ND2was 100, and a quantity of packets received by network device ND1after network device ND2looped back the set of packets was 100. In this way, network device ND1may record information related to the set of packets provided to, and looped back by, network device ND2, thereby permitting network device ND1to determine whether a source of a communication error is on a link between network devices ND1and ND2.

As shown by reference number150, network device ND2may provide the set of packets to network device ND3. In some implementations, network device ND2may provide the set of packets with the same value for the same parameter as was configured for the TLV element (e.g., a set of packets associated with MAC address “A:B:C”), so as to test a link between network devices ND2and ND3for a communication error. Additionally, or alternatively, network device ND2may provide packets, that were received from network device ND1, but that are not associated with the loopback test so that the packets can be provided to a destination (e.g., a device other than network devices ND1through ND3). In this way, other communications may be uninterrupted by the loopback test.

As shown by reference number155, network device ND3may loop back the set of packets. Network device ND3may loop back packets received from network device ND2that have the same value for the same parameter as was configured for the TLV element (e.g., packets associated with MAC address “A:B:C”). Network device ND3may provide packets not associated with the loopback test toward a destination, such as another network device (not shown), thereby reducing or eliminating disruptions to communications during a loopback test.

As shown by reference number160, network device ND2may receive the set of packets that was looped back by network device ND3. As shown by reference number165, network device ND2may record information identifying a quantity of packets provided to network device ND2with the same value for the same parameter as was configured for the TLV element (e.g., using a counter). For example, network device ND2may record information that identifies that for MAC address A:B:C, network device ND2sent 100 packets to network device ND3, and that network device ND2received 80 packets from network device ND3when network device ND3looped back the set of packets. In this way, network device ND2may record information that permits a network device to determine if a source of communication errors is on a link between network devices ND2and ND3. For example, by receiving fewer packets from network device ND3than were provided to network device ND3, a network device, such as a controller network device (not shown inFIG. 1B) and/or network device ND2, may determine that a source of an error is on a link between network device ND2and network device ND3.

AlthoughFIG. 1Bshows network devices ND1and ND2performing loopback tests, in some implementations, network devices ND1and ND2may perform the loopback tests sequentially or separately. For example, network device ND1may perform a first loopback test on a link between network devices ND1and ND2. In some implementations, if a result of the first loopback test fails to indicate an error on a link between network devices ND1and ND2, then network device ND2may perform a second loopback test on a link between network device ND2and network device ND3. This conserves processing resources of network devices by reducing or eliminating a need for network devices to perform loopback tests when another network device identifies a source of a communication error.

As shown inFIG. 1C, and by reference numbers170-1and170-2, network devices ND1and ND2may provide counter information to a controller network device. The counter information may identify a quantity of packets sent by network device ND1to network device ND2and by network device ND2to network device ND3and a quantity of packets received by network device ND1from network device ND2when the set of packets was looped back by network device ND2and a quantity of packets received by network device ND2from network device ND3when the set of packets was looped back by network device ND3. The counter information may permit the controller network device to determine a source of an error related to communications among multiple network devices, including network devices with which the controller network device is not communicating. In practice, the controller network device may receive counter information from hundreds, thousands, millions, etc. of network devices. In this way, the controller network device may receive a data set that cannot be processed manually or objectively by a human actor.

As shown by reference number175, the controller network device may perform an action based on a result of performing the loopback test. For example, the controller network device may determine a source of communication errors. Continuing with the previous example, the controller network device may identify a link between network device ND2and network device ND3as a source of one or more communication errors (e.g., based on the counter information indicating that network device ND2received fewer packets from network device ND3than were sent to network device ND3). Additionally, or alternatively, and continuing still with the previous example, the controller network device may identify network device ND3as a source of a communication error based on network device ND2receiving fewer looped back packets from network device ND3than network device ND2provided to network device ND3.

Additionally, or alternatively, and as another example, the controller network device may boot up another network device and/or power down network device ND3to fix, or address, the communication error (e.g., cause the other device to boot up and/or cause network device ND3to power down). Additionally, or alternatively, and as another example, the controller network device may disable a link between network device ND2and network device ND3and/or activate another link between network device ND2and network device ND3.

As shown by reference number180, and as another example, the controller network device may provide information for display via the client device. The information provided by the controller network device for display may identify a source of the communication error to permit a network administrator to fix, or address, the communication error.

In this way, a network device may permit another network device to dynamically and selectively loop back a packet for a loopback test without looping back all packets received from the network device. This reduces or eliminates disruptions to communications during a loopback test, thereby improving communications among a set of network devices during a loopback test. In addition, this permits the network device to test particular layer two communications, or communications of other layers, without disrupting all layer two, or other layer, communications, thereby improving a test of layer two, or other layer, communications.

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. AlthoughFIGS. 1A-1Cdescribe network device ND1as being in communication with network device ND2and network device ND2as being in communication with network device ND3, in some implementations, network device ND1may be in communication with network device ND2and/or network device ND3.

FIG. 2is a diagram of an example environment200in which systems and/or methods, described herein, may be implemented. As shown inFIG. 2, environment200may include a client device210, one or more network devices220-1through220-N (N≥1) (hereinafter referred to collectively as “network devices220,” and individually as “network device220”), and a network230. Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Client device210includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with a communication error on a link between multiple network devices220. For example, client device210may include a desktop computer, a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device. In some implementations, client device210may receive information related to a source of a communication error on a link among multiple network devices220, as described elsewhere herein. Additionally, or alternatively, client device210may provide the information for display related to a source of an error on a link among multiple network devices220, as described elsewhere herein. AlthoughFIG. 2shows a single client device210, in practice, there may be hundreds, thousands, etc. of client devices210.

Network device220includes one or more devices (e.g., one or more traffic transfer devices) capable of receiving, generating, storing, processing, and/or providing information related to a communication error on a link among multiple network devices220. For example, network device220may include a firewall, a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar device. In some implementations, network device220may configure a TLV element with information identifying a parameter related to a packet, as described elsewhere herein. Additionally, or alternatively, network device220may perform a loopback test on a link among multiple network devices220using packets configured with the same information as was configured in the TLV element, as described elsewhere herein. In some implementations, network device220may be a physical device implemented within a housing, such as a chassis. In implementations, network device220may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center.

FIG. 3is a diagram of example components of a device300. Device300may correspond to client device210and/or network device220. In some implementations, client 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., an input/output component may be a combination of input component305and output component315).

Controller320includes a processor in the form of, for example, 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 hardware and software. 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.

Controller320may perform one or more processes described herein. Controller320may perform these processes based on executing software instructions stored by a non-transitory computer-readable medium. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

FIG. 4is a flow chart of an example process400for isolating service faults using loopbacks. In some implementations, one or more process blocks ofFIG. 4may be performed by 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 network device220, such as client device210.

As shown inFIG. 4, process400may include receiving an indication to perform a loopback test to identify a source of a communication error on a set of links among a set of network devices (block410). For example, network device220may receive an indication to perform a loopback test to identify a source of a communication error on a set of links among a set of network devices220.

In some implementations, network device220may receive an indication periodically, according to a schedule, based on requesting an indication, based on input from a user of client device210, based on detecting a communication error on a link between two or more network devices220(e.g., congestion on the set of links, dropped packets, a bit rate that fails to satisfy a threshold, jitter, etc.), and/or the like. As a specific example, network device220may detect a communication error on a link and may generate an indication based on detecting the communication error (e.g., may generate an indication that identifies the communication error). In some implementations, a set of network devices220may include hundreds, thousands, millions, etc., of network devices220. In this way, network device220may receive an indication to perform a loopback test on a set of network devices220that cannot be tested manually or objectively by a human actor.

In some implementations, a loopback test may be a test of a link where packets are sent from a first network device220to a second network device220, and the second network device220sends the packets back (e.g., loops the packets back) to the first network device220rather than providing the packets to a third network device220and/or toward another destination.

In some implementations, network device220may receive information identifying particular packets to test using the loopback test. For example, network device220may receive information identifying a particular parameter that is to be used to identify packets to be looped back and/or packets that are not to be looped back. In some implementations, a parameter may include a MAC address, an IP address, information identifying a specific protocol (e.g., IP, TCP, BGP, etc.), a port identifier, an EtherType, and/or the like. In some implementations, network device220may receive information identifying packets to be used for multiple loopback tests. In this way, network device220may be capable of performing multiple loopback tests (e.g., to be performed simultaneously, at different times, etc.), thereby increasing an efficiency of performing multiple loopback tests to identify a source of a communication error or sources of multiple communication errors (e.g., relative to receiving information related to a single loopback test).

In some implementations, 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 network230. In some implementations, traffic may refer to a set of packets.

In this way, network device220may receive an indication to perform a loopback test to identify a source of a communication error on a set of links among a set of network devices220, prior to network device220configuring a value for a TLV element that is to be used to identify a set of packets.

As further shown inFIG. 4, process400may include configuring a value of a parameter in a type-length-value (TLV) element that identifies a set of packets to permit and/or cause an action to be performed with respect to the set of packets based on the value (block420). For example, network device220may configure a value of a parameter in a TLV element that identifies a set of packets to permit and/or cause an action to be performed with respect to the set of packets based on the value.

In some implementations, network device220may determine a value of a parameter to configure in the TLV element. In some implementations, network device220may determine a value of a parameter to configure based on the received indication (e.g., where the indication includes information identifying the value). Additionally, or alternatively, network device220may determine a value of a parameter to configure based on a communication error that network device220detects. For example, network device220may determine that particular packets are being dropped (e.g., packets that have a particular value for a particular parameter in a header of the packet). Continuing with the previous example, network device220may determine to configure the same value as is included in the headers of the dropped packets.

Additionally, or alternatively, network device220may determine a value to configure based on historical information identifying historical communication errors. For example, network device220may determine a value to configure by determining that a detected communication error is similar to a historical communication error (e.g., based on types of packets being dropped, network devices220that are experiencing disrupted communications, etc.).

In some implementations, network device220may configure information identifying a value for a parameter in a TLV element (e.g., a TLV element stored by network device220). For example, network device220may configure information identifying a determined value. Additionally, or alternatively, network device220may configure information identifying a value for a parameter in a data structure (e.g., a data structure stored by network device220). In some implementations, network device220may configure information identifying a parameter for which the value is configured. For example, network device220may determine to configure a TLV element with information identifying a value as a particular parameter, such as a MAC address, when network device220determines to configure the TLV element with a MAC address. In some implementations, network device220may configure the same TLV element with the information identifying the particular parameter as was configured with a value for the parameter.

In some implementations, network device220may initiate a counter. For example, network device220may initiate a counter to record a quantity of packets provided and/or received during the loopback test that have the same value for a parameter as was configured for the TLV element. In some implementations, the counter may be associated with the value that network device220configured in the TLV. For example, network device220may use the counter to record a quantity of packets provided and/or received that have the value configured in a header of the packet.

In some implementations, network device220may provide information identifying the value that network device220configured in the TLV to other network devices220. For example, network device220may provide information identifying the value to other network devices220on which loopback tests are to be performed and information identifying whether the value identifies a set of packets to be looped back or a set of packets to be provided toward a destination. This permits other network devices220to determine which packets are to be looped back in association with a loopback test. In some implementations, network device220may provide a set of instructions to other network devices220to configure a TLV and/or to initiate a counter in a similar manner. In this way, network devices220that are to be included in a loopback test may be capable of recording metrics that permit determination of a source of a communication error.

In some implementations, the value that network device220configured in the TLV element may indicate that a packet with the same value for the same parameter in a header of the packet is to be looped back to the particular network device220that provided the packet. For example, a first network device220may use the value to identify a packet that is to be looped back to a second network device220that provided the packet (e.g., without disrupting other packets associated with other communications). Continuing with the previous example, network device220may loop back packets that have the same value for the same parameter.

Conversely, and in some implementations, the value that network device220configured in the TLV element may indicate that a packet with the same value for the same parameter in a header of the packet is not to be looped back (e.g., is to be provided to another network device220, provided toward a destination, etc.). For example, a first network device220may use the value to identify a packet that is not to be looped back to a second network device220as part of a loopback test. Continuing with the previous example, network device220may loop back packets that do not have the same value for the same parameter. In this way, configuring a value in the TLV element permits network device220to test particular communications using a loopback test without interrupting other communications.

In this way, network device220may configure a value of a parameter in a TLV element that identifies a set of packets to permit and/or cause an action to be performed with respect to the set of packets based on the value, prior to performing a loopback test.

As further shown inFIG. 4, process400may include performing the loopback test using the set of packets with a same value for a same parameter as was configured for the TLV element (block430). For example, network device220may perform the loopback test using the set of packets with a same value for a same parameter as was configured for the TLV element.

In some implementations, network device220may provide a set of packets to another network device220. For example, network device220may provide a set of packets with the same value for the same parameter as was configured for the TLV element toward another network device220. Additionally, or alternatively, network device220may provide other packets not associated with the loopback test toward another network device220. For example, network device220may provide other packets that have different values for the same parameter as the value configured in the TLV element.

In some implementations, prior to providing a set of packets, network device220may configure a header of the set of packets. For example, network device220may configure a header such that information included in the header identifies the same value for the same parameter as was configured in the TLV element. In this way, network device220may configure a set of packets that can be used to test communications among multiple network devices220, thereby improving testing of the communications relative to not using a configured set of packets.

In some implementations, when network device220receives a set of packets from another network device220, network device220may loop the set of packets back to the other network device220(e.g., based on the set of packets having a particular value for a parameter included in a header of the set of packets). For example, a set of packets that network device220loops back may be associated with a loopback test used to identify a source of a communication error on a set of links among network devices220. Additionally, or alternatively, network device220may provide the set of packets toward a destination (e.g., based on the set of packets not having a particular value for a parameter included in a header of the set of packets). In this way, network device220may use a set of packets in association with a loopback test without disrupting other communications that are not experiencing communication errors.

In some implementations, network device220may receive packets after another network device220has looped the packets back. For example, network device220may monitor a link via which packets were provided so as to receive the packets, or a portion thereof, when another network device220loops the packets back and may receive the packets based on monitoring the link. Additionally, or alternatively, network device220may record metrics related to the packets (e.g., a quantity of packets sent, a quantity of packets received, whether the packets have errors, a bit rate associated with a set of packets, etc.). For example, network device220may record metrics related to packets that have the same value for the same parameter as was configured in the TLV element. Additionally, or alternatively, network device220may receive counter information from another network device220(e.g., a first network device220may receive information identifying a quantity of packets that a second network device220provided to, and/or received from, a third network device220, a bit rate of a set of packets provided to, and/or received from, the third network device220, etc.). This permits network device220to analyze communications among a set of other network devices220to identify a source of a communication error.

Additionally, or alternatively, network device220may identify a source of a communication error (e.g., using counter information recorded by network device220and/or another network device220). In some implementations, and for example, a mismatch in values for a quantity of packets provided and a quantity of packets received may indicate that a corresponding link via which the packets were provided and/or that the particular network devices220associated with the link are a source of a communication error. Additionally, or alternatively, and as another example, network device220may identify a source of an error based on values for a combination of metrics.

Additionally, or alternatively, and as another example, network device220may identify a source of an error based on a pattern of values for a set of metrics being similar to a pattern associated with a known source of a communication error (e.g., as determined using machine learning). Additionally, or alternatively, and as another example, network device220may determine a source of an error based on a trend related to values for a set of metrics (e.g., a trend over time, a trend with respect to a particular network device220and/or link, etc.). Additionally, or alternatively, and as another example, network device220may identify a source of an error based on a type of error indicated by values for a set of metrics. For example, network device220may identify a source of an error based on values for the set of metrics indicating that a link is experiencing a dropped packet error, jitter, a bit rate error, and/or the like.

In some implementations, network device220may provide counter information to another device (e.g., a server device and/or client device210) to permit the other device to identify a source of a communication error. In some implementations, network device220may provide information for display via client device210. For example, network device220may provide information indicating a source of a communication error, counter information, values for a set of metrics, and/or the like to client device210for display. In some implementations, network device220may send a message (e.g., to client device210) that identifies a source of a communication error, counter information, and/or the like.

In some implementations, network device220may perform an action to fix, or address, a communication error. For example, network device220may boot up or power down, or cause a boot up or power down of, a network device220to fix, or address, the communication error. Additionally, or alternatively, and as another example, network device220may determine an alternative route via network230(e.g., an alternative set of links) for packets so that the packets avoid a source of a communication error. Additionally, or alternatively, and as another example, network device220may activate or deactivate a link among network devices220. Additionally, or alternatively, and as another example, network device220may obtain software for network device220and/or another network device220and/or may install the software or cause the software to be installed (e.g., by the other network device220).

Additionally, or alternatively, and as another example, network device220may generate a recommendation related to fixing, or addressing, the communication error. Continuing with the previous example, network device220may provide information related to the recommendation to client device210, such as to facilitate fixing, or addressing, of a communication error by a network administrator.

In this way, network device220may perform the loopback test using the set of packets with a same value for a same parameter as was configured for the TLV element.

Some implementations, described herein, permit a network device to configure a type-length-value (TLV) element in a manner that permits another network device, on which a loopback test is being performed, to determine whether to loop back a packet to the network device, to provide the packet to a destination, or to perform another action related to the packet after receiving the packet from the network device. In this way, the network device may permit another network device to dynamically and selectively loop back a packet for a loopback test without looping back all packets received from the network device. This reduces or eliminates disruptions to communications during a loopback test, thereby improving communications among a set of network devices during a loopback test. In addition, this permits the network device to test particular layer two communications, or communications of other layers, without disrupting all layer two, or other layer, communications, thereby improving a test of layer two, or other layer, communications.