Patent Description:
Modern computing networks may include multiple devices, services, and other network nodes that are interconnected by various interfaces. A network may be managed by a centralized network controller, which may track a topology of the network. That is, the network controller may track the devices within the network, as well as the connections between those devices. In order to keep the topology up-to-date as various network nodes are added or removed from the network, the network controller may rely on advertisements from the network nodes. These advertisements may include link layer discovery protocol (LLDP) messages, for example. In some cases, the topology may be manually updated by an administrator.

However, in some cases, the network controller may be unaware of nodes that have joined the network. For example, a node may be connected to the network that does not transmit the advertisements throughout the network. Accordingly, the network controller may be unable to perceive the node. In some instance, the node could be a Bump-in-the-Wire (BitW) device.

Unknown network nodes may cause a variety of problems. In some cases, an unknown network node may be benign. For example, an administrator may add a transparent firewall node to the network, without updating the topology. Further, the transparent firewall node may not advertise its presence in the network. Thus, a network controller associated with the network may be unaware of the new firewall node. In some cases, an unknown network node can disrupt the functionality of the network. For example, the firewall node may unexpectedly delay and/or drop data packets transmitted throughout the network, which could interrupt network communications.

Further, a nefarious actor may connect a malicious node to a network that remains deliberately hidden. For instance, a snooping node configured to capture and analyze private network traffic may be added to the network. In some cases, the snooping node may report the private network traffic to an external, unauthorized party, thereby creating a security vulnerability within the network. In some cases, malicious network nodes can attack vulnerabilities within the network, or even exfiltrate data outside the network. Therefore, hidden nodes pose a huge security risk to networks. Accordingly, there is a need to identify unknown network nodes within a network.

<CIT> describes a method for providing connection information between a first communication device and a second communication device is described. At least one purposely corrupted packet that includes a purposely corrupted packet attribute is generated by the first communication device. The at least one purposely corrupted packet is transmitted by the first communication device to the second communication device via a port coupled to a communications network. A count of packets that are transmitted, the count of packets including the at least one purposely corrupted packet and selected additional packets, is generated by the first communication device. An indication of the count of the at least one purposely corrupted packet and the selected additional packets that are transmitted from the first communication to the second communication device via the port is provided to the second communication device.

This disclosure describes various systems, devices, and methods for diagnosing nodes within a network. In an example method, a first network node receives an indication of a diagnostic transmission originating from a second network node. The first network node receives a forwarded transmission corresponding to the diagnostic transmission. Based on at least one of the indications of the forwarded transmission, a presence and/or a malfunction of an intermediary node between the first network node and the second network node can be diagnosed.

In some instances, the method includes transmitting, to a network controller, a report indicating the presence and/or the malfunction of the intermediary node between the first network node and the second network node.

According to some examples, a header of the diagnostic transmission includes a first address and a payload of the diagnostic transmission comprises the first address and a header of the forwarded transmission includes a second address and the payload of the forwarded transmission comprises the first address. The presence and/or the malfunction of the intermediary node can be diagnosed by determining that the first address in the payload of the forwarded transmission is different than the second address in the header of the forwarded transmission.

In some examples, the diagnostic transmission includes corrupted data and uncorrupted data and the forwarded transmission includes the uncorrupted data and omits the corrupted data. For instance, diagnosing the presence and/or the malfunction of the intermediary node includes determining that the forwarded transmission omits the corrupted data. In some cases, the corrupted data is first corrupted data associated with a first layer, the diagnostic transmission further includes second corrupted data associated with a second layer, the second layer is different from the first layer, and the forwarded transmission further includes the second corrupted data. In some examples, the method further includes determining that the intermediary node is active in the first layer based on the absence of the first corrupted data in the forwarded transmission; and determining that the intermediary node is invisible in the second layer based on the presence of the second corrupted data in the forwarded transmission.

In some cases, the diagnostic transmission includes a first packet and a second packet. The first packet may include inert malicious data and the second packet may include non-malicious data. The forwarded transmission can include the second packet and omit the first packet. In some examples, diagnosing the presence and/or malfunction of the intermediary node includes determining that the forwarded transmission omits the first packet.

According to some examples, the diagnostic transmission includes a first type of data and a second type of data. The forwarded transmission can include the first type of data and the second type of data. In some cases, diagnosing the presence and/or malfunction of the intermediary node includes determining that a first time at which the first type of data in the forwarded transmission is received is different than a second time at which the second type of data in the forwarded transmission is received.

In some examples, the diagnostic transmission includes at least one first packet and an in-situ Operations, Administration, and Management (iOAM) tag indicating first contents of the at least one first packet. The forwarded transmission may include at least one second packet and the iOAM tag. In some instances, identifying the presence of the intermediary node is based, at least partly, on the iOAM tag in the forwarded transmission indicating the first contents that are different than second contents of the at least one second packet.

This disclosure describes various techniques for diagnosing network nodes within a network. According to some examples, one or more unknown network nodes may be connected between two diagnostic network nodes. The two diagnostic network nodes can perform one or more diagnostic tests by exchanging transmissions that traverse the unknown network node(s). Based on the results of the tests, one or both of the diagnostic network nodes may identify the presence of the unknown network node(s). Further, some of the tests can be used to identify one or more layers over which the unknown network node(s) are visible, such that the type of the unknown network node(s) can be identified. In various cases, one or both of the diagnostic network nodes can notify other network nodes within the network (e.g., switches, routers, load balancers, network controllers, or the like) of the presence and/or type of the unknown network node(s). Accordingly, various nodes within the network can refrain from routing data traffic through the unknown network node(s) and utilize a different path through the network. In various examples, the tests can be performed on one or more known network nodes, in order to determine whether the known network node(s) are malfunctioning. If the known network node(s) are malfunctioning, the diagnostic network nodes can indicate the malfunctioning known network node(s) to the other network nodes or to a centralized controller system.

Various implementations described herein are directed to practical improvements to network environments. Example techniques described within this disclosure enable the identification of unknown network nodes within a network, whether benign or malicious. Further, some techniques can be used to identify whether known network nodes are malfunctioning. These techniques for diagnosing the presence and/or functionality of network nodes can be used to prevent disruptions and security risks within the network.

Further, various examples described herein cannot be practically performed within the human mind. According to some examples, intermediary network nodes are diagnosed by monitoring data within diagnostic and/or forwarded transmissions through a network environment. The human mind is not equipped to perform these techniques. This disclosure provides non-abstract techniques that are fundamentally integrated into network environments.

Various implementations of the present disclosure will be described in detail with reference to the drawings, wherein like reference numerals present like parts and assemblies throughout the several views. Additionally, any samples set forth in this specification are not intended to be limiting and merely demonstrate some of the many possible implementations.

<FIG> illustrates an example environment <NUM> for diagnosing intermediary nodes within a network. As illustrated, the environment <NUM> includes an internal network <NUM> that includes multiple network nodes. As used herein, the terms "node," "network node," and their equivalents, can refer to any entity within a network that can transmit packets to and/or receive packets from at least one other node. A node may be a device, a software instance, a Virtual Machine (VM), a container, a virtual process, or the like. In some examples, a node may include a grouping of devices or virtual resources, such as security groups, subnetworks, and so forth. In some examples, a node can be a client, a server, or a combination thereof. In particular, the internal network <NUM> may include a first network node <NUM> and a second network node <NUM>. In some implementations, the network nodes within the internal network <NUM> may be interconnected by interfaces in accordance with a Clos topology, a spine-and-leaf topology, or the like.

Further, the internal network <NUM> may include a controller <NUM>. As used herein, the terms "network controller," "controller," and their equivalents, can refer to an entity that provides centralized automation, management, policy programming, application deployment, and/or health monitoring for the fabric of the internal network <NUM>. In some cases, the controller <NUM> may be embodied in an Application Policy Infrastructure Controller (APIC™). The controller <NUM> may be embodied in one or more network nodes within the internal network <NUM>. The controller <NUM> may, in some cases, analyze data traffic through the internal network <NUM>, receive reports that enable the controller <NUM> to identify the functions performed by various network nodes within the internal network <NUM>, monitor capacity utilized within the network <NUM>, and the like. In some cases, the controller <NUM> is configured to direct various functions of the first network node <NUM> and/or the second network node <NUM>, as well as any other network nodes within the internal network <NUM>. Thus, the controller <NUM> may optimize the utilization of network resources (e.g., communication resources, processing resources, memory resources, and the like) within the internal network <NUM> by controlling the network nodes.

In some cases, the internal network <NUM> may include a load balancer <NUM>. As used herein, the term "load balancer," and its equivalents, can refer to an entity configured to distribute workloads across a limited amount of resources, in order to ensure that the workloads are distributed across the resources. In some examples, a load balancer may distribute data traffic over different paths through the internal network <NUM> to prevent one or more communication resources from being overloaded. In some instances, a load balancer may distribute the performance of tasks over different network nodes within the internal network <NUM>, to prevent one or more of the network nodes from being overloaded. In some cases, a load balancer can be embodied by a network node (e.g., a device, a VM or application executed by at least one device, a network fabric controller, or the like). For example, a load balancer may evenly distribute network traffic across multiple switches within an example network. The load balancer <NUM> of <FIG> may be embodied in one or more network nodes within the external network <NUM>.

The internal network <NUM> may include one or more internal communication networks <NUM> by which data can be transmitted between nodes within the internal network <NUM>. As used herein, the term "communication network," and its equivalents, can refer to a network including one or more nodes and/or one or more interfaces over which data can be communicated. As used herein, the term "interface," and its equivalents, can refer to a connection between two nodes in a network, such as the nodes within the internal network <NUM>. In some cases, an interface may directly connect the two nodes and/or may omit any intermediary nodes. An interface may be connected to a first port of a first network node (e.g., a physical of device and/or a virtual port of a software instance) and to a second port of a second network node. In some cases, an interface between two nodes can be a wired interface, such that a packet can be transmitted as a signal conducted through a solid medium (e.g., an Ethernet cable, a fiber-optic cable, etc.) connecting the two nodes. In some examples, an interface between nodes can be a wireless interface, such that a packet can be transmitted as a signal through a fluid medium (e.g., air, water, etc.) connecting the two nodes. A wireless interface may be defined according to a type of wave used to carry the signal (e.g., a sound wave, an electromagnetic wave, etc.) and a frequency of the wave (e.g., an ultrasonic frequency, a radio frequency, an infrared frequency, etc.). An interface may be further defined according to a particular communication protocol, which may indicate how data transmitted over the interface is modulated. Some examples of communication protocols applicable to this application include Transmission Control Protocol (TCP)/Internet Protocol (IP), Wi-Fi, Bluetooth, or the like. In various examples, the communication network(s) <NUM> may include at least one wired (e.g., optical fiber) network over which nodes within the internal network <NUM> can transfer data.

According to various implementations, the internal network <NUM> may be further connected to one or more external networks <NUM>. The external network(s) <NUM> may be connected to the communication network(s) <NUM> of the internal network <NUM>. Some examples of the external network(s) <NUM> include public networks, wide area networks (WANs), or combinations thereof. For example, the external network(s) <NUM> may include the Internet, radio access networks (RANs), wireless core networks (e.g., evolved packet core (EPC) networks, 5th generation core (5GC) networks, etc.), or the like.

One or more user devices <NUM> may connect to the internal network <NUM> via the external network(s) <NUM>. For example, the user device(s) <NUM> may transmit data to, or receive data from, at least one node within the internal network <NUM> via the external network(s) <NUM>. As used herein, the terms "user device," "wireless communication device," "communication device," "mobile device," "client device," and "terminal" can be used interchangeably herein to describe any user equipment (UE) that is capable of transmitting/receiving data (e.g., wirelessly) using any suitable communications/data technology, protocol, or standard, such as Global System for Mobile (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), New Radio (NR), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over Internet Protocol (IP) (VoIP), Voice over LTE (VoLTE), Institute of Electrical and Electronics Engineers' (IEEE) <NUM>. 1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), and/or any future IP-based network technology or evolution of an existing IP-based network technology. In general, a UE can be implemented as any suitable type of computing device configured to communicate over a wired or wireless network, including, without limitation, a mobile phone (e.g., a smart phone), a tablet computer, a laptop computer, a Portable Digital Assistant (PDA), a wearable computer (e.g., electronic/smart glasses, a smart watch, fitness trackers, etc.), an Internet-of-Things (IoT) device, an in-vehicle (e.g., in-car) computer, and/or any similar mobile device, as well as situated computing devices including, without limitation, a television (smart television), a Set-Top-Box (STB), a desktop computer, and the like.

In some cases, the internal network <NUM> may include a firewall and/or some other security policy configured to filter and/or quarantine potentially malicious traffic from the external network(s) <NUM> and the user device(s) <NUM>. The firewall and/or security policy may be embodied within one or more nodes of the internal network <NUM>. In various examples, an example firewall may intercept data traffic transmitted to or through the internal network <NUM> (e.g., data traffic transmitted between the communication network(s) <NUM> and the external network(s) <NUM>), inspect the data traffic based on one or more filter conditions, and selectively block at least a portion of the data traffic that satisfies the filter condition(s). Accordingly, the internal network <NUM> may be protected from malicious data traffic originating outside of the internal network <NUM>.

The controller <NUM> and/or the load balancer <NUM> may maintain (e.g., store) a topology of the internal network <NUM>. The topology (also referred to as a "network topology") may indicate the arrangement of network nodes in the internal network <NUM> and interfaces interconnecting the network nodes. In some cases, the topology can further indicate functions and/or capacities of the network nodes. In some cases, the controller <NUM> may identify the topology of the internal network <NUM> by receive one or more advertisements (e.g., messages) from the network nodes within the internal network <NUM>. The controller <NUM> may utilize the topology to control the internal network <NUM>. In some cases, the load balancer <NUM> may utilize the topology to balance loads between the various network nodes within the internal network <NUM>.

The topology, however, may be outdated if additional network nodes are added to the internal network <NUM>. In some cases, the topology can be manually updated by a network administrator. According to some implementations, the topology can be updated based on advertisements (e.g., LLDP messages) transmitted throughout the internal network <NUM>. However, in some circumstances, the topology is not updated. For example, a network node can be added to the internal network <NUM> by a user that does not manually update the topology. In some cases, the network node may be benign, but nevertheless unknown to the controller <NUM>, other devices, and/or other users. In some cases, the network node may be malicious, and the user may refrain from updating the topology for nefarious purposes. In both types of cases, the network node may cause problems to the functionality of the internal network <NUM>.

In various implementations of the present disclosure, the first network node <NUM> and the second network node <NUM> may diagnose the presence of an intermediary node <NUM> within the internal network <NUM>. In some cases, the intermediary node <NUM> may be a Bump in the Wire (BitW) node and/or device, such as a security appliance, a transparent firewall node, or the like. The intermediary node <NUM> may be transparent to visibility of the internal network <NUM>. In some examples, the controller <NUM> may maintain the network topology based on communicating with all network nodes it controls and querying their LLDP databases in order to discover network nodes. LLDP is a standardized link-layer protocol defined by IEEE as Station and Media Access Control Connectivity Discovery, which is specified in IEEE <NUM>. An example network node participating in LLDP may generate and transmit LLDP messages that advertise the node's identity (e.g., an address of the node), capabilities, and neighbor nodes. The example network node may receive LLDP messages from its neighbor nodes, which the network node can use to identify its neighbor nodes. The example network node may further store indications of its neighbor nodes in an LLDP database and report information about its neighbor nodes to the controller <NUM>, which may update the topology based on the LLDP messages. However, in various examples, the intermediary node <NUM> could be an in-line Intrusion Prevention System (IPS)-type device that refrains from generating LLDP messages that would otherwise identify its presence to its neighbors within the internal network <NUM>. Thus, the intermediary node <NUM> may be invisible to the internal network <NUM> and may be undetectable to LLDP-based techniques for defining and updating the network topology of the internal network <NUM>. In various implementations, the controller <NUM> may maintain the network topology based on messages associated with other discovery protocols that are transmitted throughout the internal network <NUM>, such as messages in accordance with the CISCO™ Discovery Protocol (CDP), Link Layer Topology Discovery (LLTD) protocol, the NORTEL™ Discovery Protocol (NDP), or the like. However, in these implementations, the intermediary node <NUM> may be similarly undetectable using other discovery protocols. Similarly, the intermediary node <NUM> may be undetectable using traceroute, because the intermediary node <NUM> may refrain from decrementing the time-to-live (TTL) data fields of traceroute packets.

The first network node <NUM> may include a first diagnostic system <NUM>. The second network node <NUM> may include a second diagnostic system <NUM>. The first diagnostic system <NUM> and/or the second diagnostic system <NUM> may include or be embodied within a software container, a smart network interface card (smartNIC), a virtualized function, an operating system (OS), an application, or the like, which may be part of the first network node <NUM> and/or the second network node <NUM>.

In various implementations, the first network node <NUM> and/or the first diagnostic system <NUM> may participate in a handshake procedure with the second network node <NUM> and/or the second diagnostic system <NUM>. For example, the first network node <NUM> may transmit an offer message over a particular layer (e.g., Layer <NUM>) which advertises the capability of the first diagnostic system <NUM>. Upon receiving the offer message, the second network node <NUM> may send a confirmation message over the particular layer to the first network node <NUM> and/or the first diagnostic system <NUM> that indicates a capability of the second diagnostic system <NUM>. Accordingly, the first network node <NUM> and/or the first diagnostic system <NUM> may be synchronized with the second network node <NUM> and/or the second diagnostic system <NUM> and may subsequently test for the presence of the intermediary node <NUM>.

According to some implementations, testing can be triggered by the controller <NUM>. For example, the controller <NUM> may transmit, to the first network node <NUM> and/or the first diagnostic system <NUM>, as well as to the second network node <NUM> and/or the second diagnostic system <NUM>, an activation message. The activation message may be transmitted over the communication network(s) <NUM>. Upon receiving the activation message, the first network node <NUM>, the first diagnostic system <NUM>, the second network node <NUM>, and/or the second diagnostic system <NUM> may initiate testing to identify the presence of the intermediary node <NUM>. In various examples, the controller <NUM> may transmit the activation message periodically (e.g., every <NUM> hours, every day, or at some other frequency).

In some implementations, the first network node <NUM> and the second network node <NUM> may be presumed adjacent within the internal network <NUM>. As used herein, the term "adjacent," and its equivalents, can refer to nodes that are connected to each other, wherein communications between the nodes does not need to be routed between other nodes. For instance, two adjacent nodes may exchange data over a single network interface. In some cases, nodes can be adjacent in a particular network layer, such that communications between the layer-adjacent nodes do not need to be routed between other nodes within the particular network layer. Nodes within a network are "presumed adjacent" when an existing network topology (e.g., stored or otherwise maintained by controller of the network) indicates the nodes are adjacent. Nodes that are presumed adjacent may nevertheless be nonadjacent due to the presence of one or more unknown, intermediary nodes. In the example illustrated in <FIG>, the first network node <NUM> and the second network node <NUM> may be presumed adjacent by the existing topology maintained by the controller <NUM>. However, the first network node <NUM> and the second network node <NUM> may actually be nonadjacent within the internal network <NUM>, due to the presence of the intermediary node <NUM>.

To identify the presence of the intermediary node <NUM>, the first network node <NUM> and/or the first diagnostic system <NUM> may transmit a diagnostic transmission to the second network node <NUM> and/or the second diagnostic system <NUM>. As used herein, the terms "transmission," "message," and their equivalents, can refer to data transmitted between network nodes. In some cases, a transmission may include one or more protocol data units (PDUs) (e.g., data packets) transmitted between the network nodes. A transmission can be referred to a "unicast" transmission when it is transmitted by a single network node and received by a single network node. A transmission can be referred to as a "multicast" transmission when it is transmitted by a single network node and received by multiple network nodes. In various cases, the diagnostic transmission may be transmitted by the first network node <NUM> and/or the first diagnostic system <NUM> over an interface that is presumed to directly connect the first network node <NUM> to the second network node <NUM>. In some examples, an indication of the diagnostic transmission may be further transmitted by the first network node <NUM> and/or the first diagnostic system <NUM> to the second network node <NUM> and/or the second diagnostic system <NUM> over the communication network(s) <NUM>.

If the intermediary node <NUM> was absent from the internal network <NUM>, then the diagnostic transmission would be received by the second network node <NUM> and/or the second diagnostic system <NUM> in an expected manner. For example, the as-received diagnostic transmission may include the same data as the as-transmitted diagnostic transmission. However, due to the presence of the intermediary node <NUM>, the diagnostic transmission may be as-received in an unexpected manner. That is, the second network node <NUM> and/or the second diagnostic system <NUM> may receive a forwarded transmission from the intermediary node <NUM>, which may indicate the presence of the intermediary node <NUM>. In some cases, the second network node <NUM> and/or the second diagnostic system <NUM> may return an indication of the forwarded transmission to the first network node <NUM> and/or the first diagnostic system <NUM>.

In some examples, the diagnostic transmission may include an address of the first network node <NUM> and/or the first diagnostic system <NUM>. For instance, the diagnostic transmission may include at least one data packet that indicates the address of the source of the data packet. As used herein, the term "address," and its equivalents, can refer to an identifier of a node within a network that can be used to define the node as a destination of a transmission. One example of a type of address is a Media Access Control (MAC) address, which is defined according to the IEEE <NUM> standard. A MAC address can include <NUM> bits that uniquely define a node within a network. Another example of a type of address is an IP address, which is defined according to the IP communications protocol developed by the Internet Engineering Task Force (IETF). In IP version <NUM> (IPv4), an IP address can include <NUM> bits that uniquely define a node within a network. In IP version <NUM> (IPv6), an IP address can include <NUM> bits that uniquely define a node within a network. In some cases, the intermediary node <NUM> may automatically update the address in order to reflect the address of the intermediary node <NUM>. Accordingly, the forwarded transmission may include a different address than the diagnostic transmission. Based on this discrepancy, the intermediary node <NUM> can be identified.

In some instances, the diagnostic transmission may include a mixture of uncorrupted data and corrupted data. As used herein, the term "uncorrupted data," and its equivalents, can refer to data that lacks errors and/or includes less than a threshold amount (e.g., a threshold number of bits) of errors. As used herein, the term "corrupted data," and its equivalents, can refer to data that includes one or more errors. Errors can include, for instance, a PDU transmitted over a non-common port, an acknowledgement message over a connection that has not been established, a corrupt packet header, or the like. Various network nodes may automatically filter out corrupted data that they receive. For instance, the intermediary node <NUM> may include the uncorrupted data in the forwarded transmission, and refrain from including to corrupted data in the forwarded transmission. Thus, the intermediary node <NUM> may be identified based on the absence of the corrupted data in the forwarded transmission.

In some examples, the diagnostic transmission may include a mixture of non-malicious data and malicious data. As used herein, the term "malicious data" can refer to data that is ordinarily associated with malware. The malicious data in the diagnostic transmission may be benign, such that the malicious data may refrain from exposing the internal network <NUM> to security risks. For instance, the malicious data may include a European Institute for Computer Antivirus Research (EICAR) test file. However, the malicious data may include one or more patterns of data that are known to be associated with malware, and therefore are likely to be filtered or quarantined by conventional firewalls and/or security platforms. In some cases, the intermediary node <NUM> may apply a security policy that filters out malicious data. Thus, the intermediary node <NUM> may include the non-malicious data in the forwarded transmission and may refrain from including the malicious data in the forwarded transmission. Due to the absence of the malicious data in the forwarded transmission, the intermediary node <NUM> may be identified.

According to some instances, the diagnostic transmission may include a mixture of different types of data. As used herein, the terms "type," "data type," "type of data," and their equivalents, can refer to data that is encapsulated, formatted, and/or encoded in a particular manner. Some examples of different types of data include raw Internet Protocol (IP) data, Transmission Control Protocol (TCP) data, User Datagram Protocol (UDP) data, Internet Control Message Protocol (ICMP) data, HyperText Transfer Protocol (HTTP) data, Secure Socket Layer (SSL) or Transport Layer Security (TLS) data, or the like. In some instances, the intermediary node <NUM> may process the different types of data at different rates. For example, the intermediary node <NUM> may perform deep packet inspection of a type of data included in the diagnostic transmission, which may slow down the processing of the type of data. Thus, the different types of data may be received by the second network node <NUM> and/or the second diagnostic system <NUM> in the forwarded transmission at different times. The discrepancy in the times at which the different types of data are received may be used to identify the presence of the intermediary node <NUM>.

In various examples, the first network node <NUM> may perform a cable length test on an interface that is toward the second network node <NUM>, thereby identifying a length of a first cable connecting the first network node <NUM> to the intermediary node <NUM>. Similarly, the second network node <NUM> may perform a cable length test on an interface that is toward the first network node <NUM>, thereby identifying a length of a second cable connecting the second network node <NUM> to the intermediary node <NUM>. In some cases, the diagnostic transmission may include a data field that indicates a length of the first cable. The intermediary node <NUM> may forward the data field in the forwarded transmission. The second network node <NUM> may compare the length of the first cable indicated in the data field with the length of the second cable. The first cable and the second cable may have different lengths. The different cable lengths can be used to identify the presence of the intermediary node <NUM>.

According to some implementations, the diagnostic transmission can include some existing data traffic transmitted from the first network node <NUM> to the second network node <NUM>. The diagnostic transmission may further include one or more tags indicating the data in the diagnostic transmission. For instance, the tag(s) can include in-situ OAM (iOAM) classifiers that indicate each one of the packets in the diagnostic transmission. iOAM classifiers are defined according to the Internet Engineering Task Force (IETF) and can provide real-time telemetry data that can be embedded within live data traffic. Examples of iOAM classifiers that could be included in the tag(s) include node identification (IDs) of nodes (e.g., the first network node <NUM>, the second network node <NUM>, and/or the intermediary node <NUM>) from which the diagnostic transmission is sent and/or over which the diagnostic transmission traverses, ingress and/or egress interfaces (e.g., interfaces between the first network node <NUM>, the second network node <NUM>, and/or the intermediary node <NUM>), timestamps (e.g., at which the diagnostic transmission is generated and/or transmitted by the first network node <NUM>, the second network node <NUM>, and/or the intermediary node <NUM>), transit-delay, transit jitter, sequence numbers, application-defined metadata, a hash value of a packet as-transmitted, or the like. In some cases, the tag(s) may indicate the presence of the intermediary node <NUM> directly. For example, the second network node <NUM> may identify the presence of the intermediary node <NUM> in response to identifying that a node ID of the intermediary node <NUM> is present in the tag(s). In some cases, the tag(s) may indicate contents (e.g., a hash of the contents, a node sending the packet, or the like) of the packet as-transmitted from the first network node <NUM> that may be different than the contents of the packet as-received, which may indicate the presence of the intermediary node <NUM>. For instance, if the tag(s) indicate that the first network node <NUM> is the sender of the packet, but the contents (e.g., the header and/or payload) of the packet indicate something different, then the presence of the intermediary node <NUM> can be identified. Alternatively, the presence of the intermediary node <NUM> can be identified indirectly, based on the tag(s). For instance, the intermediary node <NUM> may drop at least some of the packets, such that the forwarded transmission omits at least some of the packets and tag(s) included in the diagnostic transmission. The tag(s) in the forwarded transmission may be used to identify that at least some of the packets were dropped. Accordingly, the presence of the intermediary node <NUM> can be identified due to the dropped packets.

In various examples, the diagnostic transmission can include one or more metrics indicating data traffic that was previously transmitted by the first network node <NUM> and addressed to the second network node <NUM>. For instance, the diagnostic transmission may indicate a number of packets transmitted by the first network node <NUM> in a particular time interval. The forwarded transmission, similarly, may indicate the number of packets. Upon receiving the forwarded transmission, the second network node <NUM> may compare the number of data packets sent by the first network node <NUM> to the number of data packets received by the second network node <NUM>. If there is a discrepancy between the number of sent and received packets, the presence of the intermediary node <NUM> can be identified.

In some cases, the first network node <NUM> and/or the first diagnostic system <NUM> may send multiple diagnostic transmissions to the second network node <NUM> and/or the second diagnostic system <NUM>, in order to identify the presence of the intermediary node <NUM>. For example, the diagnostic transmissions may be transmitted over different layers. As used herein, the terms "layer," "abstraction layer," and their equivalents, can refer to one or more network nodes that exchange data via a standardized communication protocol. The Open System Interconnection (OSI) model (defined by the International Standardization Organization (ISO)) is an example of a conceptual model that characterizes multiple layers with respective communication protocols. For example, Layer <NUM> in the OSI model is defined as the "physical" layer, and governs the transmission of bit streams over a physical medium; Layer <NUM> in the OSI model is defined as the "data link" layer, and governs the transmission of data between nodes that are connected by a physical layer; Layer <NUM> in the OSI model is defined as the "network" layer, and governs routing, addressing, and traffic control across a multi-node network; Layer <NUM> in the OSI model is defined as the "transport" layer, which governs the transmission of data segments throughout a network; Layer <NUM> in the OSI model is defined as the "session" layer, which governs continuous sessions between nodes; Layer <NUM> is defined as the "presentation" layer, which governs data translated between networking services and applications; and Layer <NUM> is defined as the "application" layer, which governs data communicated by application programming interfaces (APIs), and the like. Different layers may be associated with different types of PDUs over which data can be transmitted. For example, the PDU associated with Layer <NUM> may be a frame, the PDU associated with Layer <NUM> may be a packet, the PDU associated with Layer <NUM> may be a segment and/or datagram, and so on.

In some cases, the intermediary node <NUM> may be invisible in one layer but may be detectable in another layer. For example, the intermediary node <NUM> may automatically forward PDUs sent in one layer but may actively manipulate and/or delay PDUs sent in another layer. Accordingly, when the intermediary node <NUM> is invisible in one layer, the presence of the intermediary node <NUM> may be identified by testing in other layers. In some implementations, in a first test, the first network node <NUM> and/or the first diagnostic system <NUM> may transmit a first diagnostic transmission over a first layer (e.g., a frame including corrupted and uncorrupted data over Layer <NUM>). If the presence of the intermediary node <NUM> is indiscernible based on the first test, a second test may be performed. In the second test, the first network node <NUM> and/or the first diagnostic system <NUM> may transmit a second diagnostic transmission over a second layer (e.g., a packet including corrupted and uncorrupted data over Layer <NUM>). According to some cases, the second test may be used to identify the presence of the intermediary node <NUM>. In various examples, multiple tests can be performed via diagnostic transmissions over different layers, until the presence of the intermediary node <NUM> is identified. In cases where the intermediary node <NUM> is absent, the multiple tests may be performed without confirming the presence of an intermediary node. Further, one or more layers over which the intermediary node <NUM> is active may be identified using these techniques, such that a type of the intermediary node <NUM> can be identified.

In some implementations, different types of tests can be performed in a particular order, in order to identify the presence of the intermediary node <NUM> in a maximally efficient manner. For example, an address-based test may be performed with the use of fewer communication resources than a corrupted data-based test, because the diagnostic and/or forwarded transmissions associated with the address-based test may include less data than the corrupted data-based test. Accordingly, the address-based test may be performed as an initial screening technique, and the corrupted data-based test may be performed subsequently to the address-based test if the address-based test is inconclusive (e.g., if the intermediary node <NUM> is undetected by performance of the address-based test). In various examples, a tag-based test can be performed before other tests, because the tag-based test can be performed without injecting additional data traffic into the internal network <NUM>, thereby conserving resources of the internal network <NUM>. In some cases, some or all of the types of tests described herein can be performed consecutively in order to effectively identify the presence of the intermediary node <NUM>, regardless of whether the intermediary node <NUM> is undetectable using one or more of the types of tests.

According to various implementations, the first network node <NUM>, the first diagnostic system <NUM>, the second network node <NUM>, and/or the second diagnostic system <NUM> may identify the presence of the intermediary node <NUM> based on the diagnostic transmission and the forwarded transmission. Upon identifying the presence of the intermediary node <NUM>, the first network node <NUM>, the first diagnostic system <NUM>, the second network node <NUM>, and/or the second diagnostic system <NUM> may update the topology based on the intermediary node <NUM>. For example, the topology may be updated by transmitting a report indicating the intermediary node <NUM> to the controller <NUM>.

In some implementations, further transmissions between the first network node <NUM> and the second network node <NUM> may be avoided, in order to avoid the intermediary node <NUM>. For example, upon identifying the presence of the intermediary node <NUM>, the first network node <NUM> may route additional data transmissions destined for the second network node <NUM> through the communication network(s) <NUM>, rather than through the intermediary node <NUM>, or vice versa. In some cases, the controller <NUM> may route data traffic through the communication network(s) <NUM>, rather than through the intermediary node <NUM>, based on the updated topology. For instance, the controller <NUM> could modify the underlying network fabric to avoid sending any data traffic towards the intermediary node <NUM>.

In some cases, the presence of the intermediary node <NUM> may be reported to a network administrator. For instance, the network administrator may be a user associated with the user device(s) <NUM>. The first network node <NUM>, the second network node <NUM>, and/or the controller <NUM> may transmit, to the user device(s) <NUM> an alert indicating the presence of the intermediary node <NUM>. The user device(s) <NUM> may, in turn, output the alert to the network administrator. As a result, the network administrator may remove and/or otherwise disable the intermediary node <NUM> within the internal network <NUM>, thereby preventing disruptions to the functions of the internal network <NUM>.

In some cases, the intermediary node <NUM> may be known. For example, the intermediary node <NUM> may be indicated within the existing network topology. Nevertheless, the first network node <NUM> and/or the first diagnostic system <NUM> may transmit the diagnostic transmission, and the second network node <NUM> and/or the second diagnostic system <NUM> may receive the forwarded transmission, in order to diagnose whether the intermediary node <NUM> is malfunctioning. For instance, the diagnostic transmission and the forwarded transmission can be compared, in order to identify whether the intermediary node <NUM> is malfunctioning by dropping packets. In some cases, the first network node <NUM> and/or the first diagnostic system <NUM>, the second network node <NUM> and/or the second diagnostic system <NUM>, or a combination thereof, may indicate how the intermediary node <NUM> is malfunctioning in a report destined for the controller <NUM>, the load balancer <NUM>, or the user device(s) <NUM>.

<FIG> and <FIG> illustrate examples of signals transmitted between various elements within the environment <NUM> illustrated in <FIG>. <FIG> illustrates example signaling <NUM> for a transmitting node diagnosing an intermediary node within a network. As illustrated, the signaling <NUM> may be performed between the first network node <NUM>, the second network node <NUM>, the controller <NUM>, and the intermediary node <NUM>, which are described above with reference to <FIG>. In some examples, the functionality performed by the first network node <NUM> could be performed by the first diagnostic system <NUM> described above, the functionality performed by the second network node <NUM> could be performed by the second diagnostic system <NUM> described above, or a combination thereof.

The first network node <NUM> may transmit a diagnostic transmission <NUM> toward the second network node <NUM>, which may be received by the intermediary node <NUM>. The diagnostic transmission <NUM>, for instance, is transmitted through the intermediary node <NUM>. The diagnostic transmission <NUM> may be addressed to the second network node <NUM>. For example, the diagnostic transmission <NUM> may include one or more data packets that are addressed to the second network node <NUM>. In various cases, the diagnostic transmission <NUM> may selectively include data that is likely to be manipulated by the intermediary node <NUM>. In some cases, the diagnostic transmission <NUM> may include data that can be used to derive whether the intermediary node <NUM> is manipulating data forwarded by the intermediary node <NUM>. For instance, the diagnostic transmission <NUM> may include a MAC address of the first network node <NUM>, a mixture of corrupted data and valid data, a mixture of malicious data and valid data, multiple types of data, an indication of a length of a cable over which the first network node <NUM> transmits the diagnostic transmission <NUM>, iOAM tags, data traffic metrics, or the like.

The intermediary node <NUM> may transmit a forwarded transmission <NUM> to the second network node <NUM>. In various cases, the intermediary node <NUM> may manipulate and/or modify the data within the diagnostic transmission <NUM>. The forwarded transmission <NUM> may include at least some of the data within the diagnostic transmission <NUM>. For instance, the forwarded transmission <NUM> may include valid data included in the diagnostic transmission <NUM>. In some cases, the forwarded transmission <NUM> may omit some data in the diagnostic transmission. For example, the forwarded transmission <NUM> may omit the MAC address of the first network node <NUM>, the corrupted data, the malicious data, at least some of the iOAM tags, or the like. According to some implementations, the forwarded transmission <NUM> may include data that is different than data included in the diagnostic transmission <NUM>. For instance, the forwarded transmission <NUM> may include a MAC address of the intermediary node <NUM>. In some cases, the forwarded transmission <NUM> may be split into different messages received by the second network node <NUM> at different times. For example, the forwarded transmission <NUM> may include a first message carrying a first type of data in the diagnostic transmission <NUM> and a second message carrying a second type of data in the diagnostic transmission, wherein the first and second messages are received by the second network node <NUM> at different times.

The second network node <NUM> may transmit an indication of the forwarded transmission <NUM> to the first network node <NUM>. In some cases, the indication of the forwarded transmission <NUM> may include at least some data included in the forwarded transmission <NUM>. According to some implementations, the indication of the forwarded transmission <NUM> may indicate additional details about the forwarded transmission <NUM>. For example, the indication of the forwarded transmission <NUM> may indicate that the first and second messages were received by the second network node <NUM> at different times.

The first network node <NUM> may identify the presence of the intermediary node <NUM> based on the diagnostic transmission <NUM> and/or the indication of the forwarded transmission <NUM>. The first network node <NUM> may transmit a node report <NUM> to the controller <NUM>. The node report <NUM> may indicate the presence of the intermediary node <NUM>. The controller <NUM> may use the node report <NUM> to update a network topology of a network (e.g., the internal network <NUM> described above with reference to <FIG>) including the first network node <NUM> and the second network node <NUM>.

Although not illustrated in <FIG>, in some cases, the first network node <NUM> may refrain from transmitting additional transmissions addressed to the second network node <NUM> via the intermediary node <NUM>. Further, the first network node <NUM> may forward a report indicating the intermediary node <NUM> to the second network node <NUM>. The second network node <NUM>, similarly, may refrain from transmitting additional transmissions addressed to the first network node <NUM> via the intermediary node <NUM>. These additional transmissions may instead be transmitted over an alternate path that connects the first network node <NUM> and the second network node <NUM>.

<FIG> illustrates alternate example signaling <NUM> for a receiving node diagnosing an intermediary within a network. As illustrated, the signaling <NUM> may be performed between the first network node <NUM>, the second network node <NUM>, the controller <NUM>, and the intermediary node <NUM>, which are described above with reference to <FIG>.

The first network node <NUM> may transmit a diagnostic transmission <NUM> toward the second network node <NUM>, which may be received by the intermediary node <NUM>. The diagnostic transmission <NUM> may be, for instances, transmitted through the intermediary node <NUM>. The diagnostic transmission <NUM> may be addressed to the second network node <NUM>. For example, the diagnostic transmission <NUM> may include one or more data packets that are addressed to the second network node <NUM>. In various cases, the diagnostic transmission <NUM> may selectively include data that is likely to be manipulated by the intermediary node <NUM>. In some cases, the diagnostic transmission <NUM> may include data that can be used to derive whether the intermediary node <NUM> is manipulating data forwarded by the intermediary node <NUM> in an effort to expose its existence. For instance, the diagnostic transmission <NUM> may include a MAC address of the first network node <NUM>, a mixture of corrupted data and valid data, a mixture of malicious data and valid data, multiple types of data, an indication of a length of a cable over which the first network node <NUM> transmits the diagnostic transmission <NUM>, , iOAM tags, data traffic metrics, or the like.

The intermediary node <NUM> may transmit a forwarded transmission <NUM> to the second network node <NUM>. In various cases, the intermediary node <NUM> may manipulate and/or modify the data within the diagnostic transmission <NUM>. The forwarded transmission <NUM> may include at least some of the data within the diagnostic transmission <NUM>. For instance, the forwarded transmission <NUM> may include valid data included in the diagnostic transmission <NUM>. In some cases, the forwarded transmission <NUM> may omit some data in the diagnostic transmission. For example, the forwarded transmission <NUM> may omit the MAC address of the first network node <NUM>, the corrupted data, the malicious data, the indication of the length of the cable, or the like. According to some implementations, the forwarded transmission <NUM> may include data that is different than data included in the diagnostic transmission <NUM>. For instance, the forwarded transmission <NUM> may include a MAC address of the intermediary node <NUM>. In some cases, the forwarded transmission <NUM> may be split into different messages received by the second network node <NUM> at different times. For example, the forwarded transmission <NUM> may include a first message carrying a first type of data in the diagnostic transmission <NUM> and a second message carrying a second type of data in the diagnostic transmission, wherein the first and second messages are received by the second network node <NUM> at different times.

The first network node <NUM> may transmit an indication of the diagnostic transmission <NUM> to the second network node <NUM>. In some cases, the indication of the diagnostic transmission <NUM> may include at least some data included in the diagnostic transmission <NUM>. According to some implementations, the indication of the diagnostic transmission <NUM> may indicate additional details about the diagnostic transmission <NUM>. For example, the indication of the diagnostic transmission <NUM> may indicate that the data contained in the first and second messages was transmitted by the first network node <NUM> at the same time.

The second network node <NUM> may identify the presence of the intermediary node <NUM> based on the forwarded transmission <NUM> and/or the indication of the diagnostic transmission <NUM>. The second network node <NUM> may transmit a node report <NUM> to the controller <NUM>. The node report <NUM> may indicate the presence of the intermediary node <NUM>. The controller <NUM> may use the node report <NUM> to update a network topology of a network (e.g., the internal network <NUM> described above with reference to <FIG>) including the first network node <NUM> and the second network node <NUM>.

Although not illustrated in <FIG>, in some cases, the second network node <NUM> may refrain from transmitting additional transmissions addressed to the first network node <NUM> via the intermediary node <NUM>. Further, the second network node <NUM> may forward a report indicating the intermediary node <NUM> to the first network node <NUM>. The first network node <NUM>, similarly, may refrain from transmitting additional transmissions addressed to the second network node <NUM> via the intermediary node <NUM>. These additional transmissions may instead be transmitted over an alternate path that connects the first network node <NUM> and the second network node <NUM>.

<FIG> illustrate various examples of diagnostic transmissions that can be used to diagnose an intermediary node within a network. In particular, <FIG> illustrate examples of a diagnostic transmission <NUM> received by the intermediary node <NUM> (described above with reference to <FIG>) and a forwarded transmission <NUM> transmitted by the intermediary node <NUM>.

<FIG> illustrates example signaling <NUM> using an address-based diagnostic test. As shown, the diagnostic transmission <NUM> may include a first address <NUM>. In various cases, the first address <NUM> may be an address of the sender of the diagnostic transmission <NUM> (e.g., the first network node <NUM> and/or the first diagnostic system <NUM> described above with reference to <FIG>). In various examples, the first address <NUM> may be a MAC address of the sender of the diagnostic transmission <NUM>. In some cases, the first address <NUM> is indicated in a header of the diagnostic transmission <NUM> as well as in a payload of the diagnostic transmission <NUM>.

Upon receiving the diagnostic transmission <NUM>, the intermediary node <NUM> may modify the first address <NUM> in the header of the diagnostic transmission <NUM> and forward the diagnostic transmission <NUM> with the modified header as the forwarded transmission <NUM>. The header of the forwarded transmission <NUM> may indicate a second address <NUM>, rather than the first address <NUM>. The second address <NUM> may correspond to an address of the intermediary node <NUM>. For example, the second address <NUM> may be a MAC address of the intermediary node <NUM>. However, in some cases, the intermediary node <NUM> may leave the first address <NUM> in the payload of the diagnostic transmission <NUM> unmodified. In various examples, the second address <NUM> in the header of the forwarded transmission <NUM> is compared to the first address <NUM> in the payload of the forwarded transmission <NUM>. Due to the presence of the second address <NUM> in the header of the forwarded transmission <NUM>, rather than the first address <NUM>, the intermediary node <NUM> may be diagnosed. The signaling <NUM> illustrated in <FIG> can be used to identify the intermediary node <NUM> when the intermediary node <NUM> is invisible to the corresponding network at Layer <NUM>, but is detectable at Layer <NUM>, for instance.

Although not illustrated in <FIG>, in some implementations, the first address <NUM> can be omitted from the payload of the diagnostic transmission <NUM> and from the payload of the forwarded transmission <NUM>. For example, a destination of the forwarded transmission <NUM> may diagnose the presence of the intermediary node <NUM> by comparing the second address <NUM> in the header of the forwarded transmission <NUM> to the first address <NUM>, which may have been prestored at the destination and/or received in a message that was separate from the forwarded transmission <NUM>. In some instances, the destination of the forwarded transmission <NUM> may transmit, to the source of the diagnostic transmission <NUM>, a message indicating the second address <NUM> as-received in the header of the forwarded transmission <NUM>, and the source can diagnose the presence of the intermediary node <NUM> by comparing the second address <NUM> to its own first address <NUM>. In various implementations of the present disclosure, the presence of the intermediary node <NUM> can be diagnosed based on the second address <NUM> in the header of the forwarded transmission <NUM>.

<FIG> illustrates example signaling <NUM> using a corrupted data-based diagnostic test. As shown, the diagnostic transmission <NUM> may include corrupted data <NUM> and valid data <NUM>. As used herein, the term "valid data" may refer to data that is uncorrupted and/or non-malicious. Upon receiving the diagnostic transmission <NUM>, the intermediary node <NUM> may apply a security policy that automatically removes the corrupted data <NUM>, and the intermediary node <NUM> may forward the diagnostic transmission <NUM> as the forwarded transmission <NUM>. The forwarded transmission <NUM> may include the valid data <NUM> but may omit the corrupted data <NUM>. Due to the absence of the corrupted data <NUM> in the forwarded transmission <NUM>, the intermediary node <NUM> may be diagnosed.

According to some implementations, the corrupted data <NUM> can include selectively corrupted values at different OSI layers. For example, the corrupted data <NUM> may include at least one corrupted value in Layer <NUM>, at least one corrupted value in Layer <NUM>, and so on. The intermediary node <NUM> may be configured to block and/or drop corrupted data in some OSI layers, but not others. Accordingly, the signaling <NUM> can be used to identify the intermediary node <NUM> when the intermediary node <NUM> is invisible in at least one of the OSI layers.

In some cases, the diagnostic transmission <NUM> may include one or more packets (e.g., TCP synchronize (SYN) packets) on one or more common ports (e.g., port numbers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and so on) and one or more non-common ports (e.g., port numbers <NUM>, <NUM>, and so on). In some cases, the non-common ports may be unofficial ports that are unregistered with the Internet Assigned Numbers Authority (IANA). The packet(s) sent over the common port(s) may be the valid data <NUM>, and the packet(s) sent over the non-common port(s) may be the corrupted data <NUM>.

According to some examples, the diagnostic transmission <NUM> may include one or more acknowledgement (ACK) messages for an unestablished TCP connection within the network. These ACK messages may be included in the corrupted data <NUM>.

In some cases, the corrupted data <NUM> within the diagnostic transmission <NUM> may include a corrupt header field. In some instances, the diagnostic transmission <NUM> may include a segment (e.g., a TCP segment) with a corrupt header field. For instance, the diagnostic transmission <NUM> may include a corrupt TCP checksum. If the segment including the corrupt TCP checksum is excluded from the forwarded transmission <NUM>, then the intermediary node <NUM> may be identified as Layer <NUM>-aware (e.g., the intermediary node <NUM> may include a Layer <NUM>-aware traffic filter). In some examples, the diagnostic transmission <NUM> may include a data packet (e.g., an IP packet) with a corrupt header field. For instance, a TTL field of the header may reflect a value of "<NUM>. " If the data packet including the invalid TTL field is excluded from the forwarded transmission <NUM>, then the intermediary node <NUM> may be identified as Layer <NUM>-aware (e.g., the intermediary node <NUM> may include a Layer <NUM>-aware traffic filter). Accordingly, in these cases, a layer associated with the intermediary node <NUM> can be further identified.

According to some instances, the corrupted data <NUM> in the diagnostic transmission <NUM> may include one or more packets that include a corrupt Layer <NUM> frame (e.g., an invalid cyclic redundancy check (CRC)). If the forwarded transmission <NUM> omits the corrupt Layer <NUM> frame, then the intermediary node <NUM> may be identified as a Layer <NUM> node. Thus, in these instances, a layer associated with the intermediary node <NUM> may be further identified in addition to a presence and/or malfunction of the intermediary node <NUM>.

<FIG> illustrates example signaling <NUM> using a malicious data-based diagnostic test. As shown, the diagnostic transmission <NUM> may include malicious data <NUM> and the valid data <NUM>. In various implementations, the malicious data <NUM> may include test files such as an EICAR test file and/or a file associated with an IPS testing suite. Upon receiving the diagnostic transmission <NUM>, the intermediary node <NUM> may automatically remove the malicious data <NUM> and forward the diagnostic transmission <NUM> as the forwarded transmission <NUM>. The forwarded transmission <NUM> may include the valid data <NUM> but may omit the malicious data <NUM>. Due to the absence of the corrupted data <NUM> in the forwarded transmission <NUM>, the intermediary node <NUM> may be diagnosed.

<FIG> illustrates example signaling <NUM> using a timing-based diagnostic test. As shown, the diagnostic transmission <NUM> may include a first type of data <NUM> and a second type of data <NUM>. Upon receiving the diagnostic transmission <NUM>, the intermediary node <NUM> may process the first type of data <NUM> differently than the second type of data <NUM>. The intermediary node <NUM> may forward the diagnostic transmission <NUM> as the forwarded transmission <NUM>. However, due to the differences in processing, the intermediary node <NUM> may forward the first type of data <NUM> at a different time than the second type of data <NUM>. For example, the first type of data <NUM> may include passive TCP traffic (e.g., passive File Transfer Protocol (FTP) data connections) with a particular size (e.g., a length of <NUM> bytes), and the second type of data <NUM> may include HTTP/TCP traffic with the particular size. The intermediary node <NUM> may selectively process and/or buffer the HTTP traffic and may automatically forward the TCP traffic without processing.

In some cases, the first type of data <NUM> may be received (e.g., by the second network node <NUM> and/or the second diagnostic system <NUM> described above with reference to <FIG>) at a first time and the second type of data <NUM> may be received at a second time. That is, the apparent "time on the wire" (i.e., transmission time) of the first type of data <NUM> may be different than that of the second type of data <NUM>. Due to the differences in times at which the first type of data <NUM> and the second type of data <NUM> are forwarded, the intermediary node <NUM> may be diagnosed.

<FIG> illustrates example signaling <NUM> using a cable length-based diagnostic test. As shown, the diagnostic transmission <NUM> may include a first cable length <NUM>. In various cases, the first cable length <NUM> may indicate a length of a cable over which the diagnostic transmission <NUM> is transmitted (e.g., by the first network node <NUM> and/or the first diagnostic system <NUM> described above with reference to <FIG>). The first network node <NUM>, for instance, may perform a cable length test toward the second network node <NUM>, and may therefore identify a length of cable between the first network node <NUM> and the intermediary node <NUM>, if present. The cable length test may be performed, for instance, by a time domain reflectometer (TDR) or a round-robin (loopback) method within the first network node <NUM>. In some cases, the first cable length <NUM> may be included within a payload of a segment (e.g., a TCP segment) and/or packet (e.g., an IP packet) included in the diagnostic transmission <NUM>.

Upon receiving the diagnostic transmission <NUM>, the intermediary node <NUM> may forward the first cable length <NUM> within the forwarded transmission <NUM>. In various cases, the forwarded transmission <NUM> is received by a node (e.g., the second network node <NUM>) that is presumed to be adjacent to the first network node <NUM>. The second network node <NUM> may perform its own cable length test toward the first network node <NUM>. The second network node <NUM> may identify a second cable length that is different than the first cable length <NUM>. The second cable length may correspond to a length of cable between the second network node <NUM> and the intermediary node <NUM>. Due to the difference between the first cable length <NUM> and the second cable length, the intermediary node <NUM> may be identified. Although <FIG> illustrates that the first cable length <NUM> is forwarded by the intermediary node <NUM>, in some cases, the first cable length <NUM> can be communicated from the first network node <NUM> to the second network node <NUM> via an alternative path through the network (e.g., a path through the communication network(s) <NUM>, as described above with reference to <FIG>).

<FIG> illustrates example signaling <NUM> using a tagged-traffic-based diagnostic test. In various cases, the diagnostic transmission <NUM> may include existing data traffic that is traversing the network and the intermediary node <NUM>. As illustrated, first data traffic <NUM> may be included within the diagnostic transmission <NUM>. Further, the first data traffic <NUM> may include one or more first tags <NUM>. The first tag(s) <NUM> may indicate each of the packets within the first data traffic <NUM>. For example, the first tag(s) <NUM> may include iOAM data indicating the packets within the first data traffic <NUM>. In some cases, the first tag(s) <NUM> may indicate timestamps of each of the packets as-transmitted, a hash of various data fields at different OSI layers, or the like.

The intermediary node <NUM> may modify the first data traffic <NUM>, thereby generating second data traffic <NUM>. The second data traffic <NUM>, for instance, may omit one or more of the packets that is dropped by the intermediary node <NUM> (e.g., due to the application of a security policy associated with the intermediary node <NUM>. The second data traffic <NUM> may include one or more second tags <NUM>, which can be a subset of the first tag(s) <NUM>. That is, the second tag(s) <NUM> may be an incomplete set of the first tag(s) <NUM>. The node receiving the second data traffic <NUM> may identify that at least some of the packets within the first data traffic <NUM> are omitted from the second data traffic <NUM>, based on the second tag(s) <NUM>. For instance, the iOAM data within the second tag(s) <NUM> may be used to identify the absence of one or more packets within the second data traffic <NUM>. By identifying that the second data traffic <NUM> of the forwarded transmission <NUM> omits at least some of the packets within the first data traffic <NUM> of the diagnostic transmission <NUM>, the intermediary node <NUM> can be diagnosed.

<FIG> illustrates example signaling <NUM> using a mass-traffic-based diagnostic test. As shown, the diagnostic transmission <NUM> may include one or more first metrics <NUM>. The first metric(s) <NUM> may indicate data traffic that was previously transmitted from a first network node (e.g., the first network node <NUM>) to a second network node (e.g., the second network node <NUM>). In some cases, the first network node is the source of the diagnostic transmission <NUM> and the diagnostic transmission <NUM> is addressed to the second network node. The first metric(s) <NUM> may include, in some examples, a number of packets (e.g., HTTP packets) transmitted from the first network node to the second network node in a particular interval. The first metric(s) <NUM> may be included in within a payload of a segment and/or packet of the diagnostic transmission <NUM>.

The intermediary node <NUM> may forward the first metric(s) <NUM> in the forwarded transmission <NUM>. An entity receiving the forwarded transmission <NUM> may compare the first metric(s) <NUM> to at least one second metric corresponding to the data traffic previously received by the second network node from the first network node. In various cases, the comparison between the first metric(s) <NUM> and the second metric(s) may indicate that one or more packets within the data traffic were dropped during the time interval. By determining that the packet(s) were not received by the second network node, the intermediary node <NUM> can be diagnosed. Although <FIG> illustrates that the first metric(s) <NUM> are forwarded by the intermediary node <NUM>, in some cases, the first metric(s) <NUM> can be transmitted over an alternative path connecting the first network node and the second network node (e.g., a path through the communication network(s) <NUM> described above with reference to <FIG>).

<FIG> illustrates an example process <NUM> for diagnosing a presence and/or a malfunction of an intermediary node within a network. In various examples, the process <NUM> may be performed by the second network node <NUM> and/or the second diagnostic system <NUM>, which are described above with reference to <FIG>.

At <NUM>, an indication of a diagnostic transmission originating from a network node may be received. The network node from which the diagnostic transmission originates may be the first network node <NUM> and/or the first diagnostic system <NUM>, as described above with reference to <FIG>. In some cases, the indication can include a transmission that is received over at least one communication network (e.g., the communication network(s) <NUM> described above with reference to <FIG>). In some instances, the indication can include a transmission that is forwarded by an intermediary node (e.g., the intermediary node <NUM> described above with reference to <FIG>).

In various cases, the diagnostic transmission may selectively include data that is likely to be manipulated by the intermediary node. In some cases, the diagnostic transmission may include data that can be used to derive whether the intermediary node is manipulating data forwarded by the intermediary node. For instance, the diagnostic transmission may include a MAC address of the node originating the diagnostic transmission, a mixture of corrupted data and valid data, a mixture of malicious data and valid data, multiple types of data, an indication of a length of a cable over which the diagnostic transmission is transmitted, iOAM tags, data traffic metrics, or the like.

At <NUM>, a forwarded transmission corresponding to the diagnostic transmission may be received. In various cases, the intermediary node may manipulate and/or modify the data within the diagnostic transmission. The forwarded transmission may include at least some of the data within the diagnostic transmission. For instance, the forwarded transmission may include valid data included in the diagnostic transmission. In some cases, the forwarded transmission may omit some data in the diagnostic transmission. For example, the forwarded transmission may omit the MAC address of the first network node, the corrupted data, the malicious data, at least some of the iOAM tags, or the like. According to some implementations, the forwarded transmission may include data that is different than data included in the diagnostic transmission. For instance, the forwarded transmission may include a MAC address of the intermediary node. In some cases, the forwarded transmission may be split into different messages received by the second network node at different times. For example, the forwarded transmission may include a first message carrying a first type of data in the diagnostic transmission and a second message carrying a second type of data in the diagnostic transmission, wherein the first and second messages are received at different times. In some cases, the forwarded transmission includes the cable length and/or the data traffic metrics of the diagnostic transmission.

At <NUM>, a presence and/or malfunction of the intermediary node may be diagnosed based on the diagnostic transmission and/or the forwarded transmission. For example, the presence and/or malfunction of the intermediary node can be identified based on the discrepancy between the MAC address indicated in the diagnostic transmission and the MAC address indicated in the forwarded transmission. In some cases, the presence and/or malfunction of the intermediary node can be identified based on the absence of the corrupted data and/or the absence of the malicious data in the forwarded transmission. In various instances, the presence and/or malfunction of the intermediary node can be identified based on a discrepancy of times at which different data types within the forwarded transmission are received. In some cases, the presence and/or malfunction of the intermediary node can be identified based on a difference between the cable length indicated in the forwarded transmission and a cable length calculated by the entity performing the process <NUM>. In various examples, the presence and/or malfunction of the intermediary node can be determined based on the iOAM tag(s) within the forwarded transmission. According to some instances, the presence and/or malfunction of the intermediary node can be identified based on data traffic metrics within the forwarded transmission.

In some cases, the presence and/or malfunction of the intermediary node may be further reported to another node within the network. For example, the presence and/or malfunction can be reported to a network controller, which may perform various functions that can address the presence and/or malfunction. In some cases, data traffic can be routed through the network in such a way that it avoids the intermediary network. In some examples, an administrator can be notified of the presence and/or malfunction of the intermediary node, and can manually address the presence and/or malfunction.

<FIG> illustrates an example process <NUM> for identifying whether an intermediary node is present within a network. In various examples, the process <NUM> may be performed by the second network node <NUM> and/or the second diagnostic system <NUM>, which are described above with reference to <FIG>.

At <NUM>, an indication of a diagnostic transmission may be received from a network node. The network node from which the diagnostic transmission originates may be the first network node <NUM> and/or the first diagnostic system <NUM>, as described above with reference to <FIG>. In some cases, the indication can include a transmission that is received over at least one communication network (e.g., the communication network(s) <NUM> described above with reference to <FIG>). In some instances, the indication can include a transmission that is forwarded by an intermediary node (e.g., the intermediary node <NUM> described above with reference to <FIG>).

In various cases, the diagnostic transmission may selectively include data that is likely to be manipulated by the intermediary node, if present. In some cases, the diagnostic transmission may include data that can be used to derive whether the intermediary node is manipulating data forwarded by the intermediary node. For instance, the diagnostic transmission may include a MAC address of the node originating the diagnostic transmission, a mixture of corrupted data and valid data, a mixture of malicious data and valid data, multiple types of data, an indication of a length of a cable over which the diagnostic transmission is transmitted, iOAM tags, data traffic metrics, or the like.

At <NUM>, a forwarded transmission corresponding to the diagnostic transmission may be received. In various cases, the intermediary node, if present, may manipulate and/or modify the data within the diagnostic transmission. The forwarded transmission may include at least some of the data within the diagnostic transmission. For instance, the forwarded transmission may include valid data included in the diagnostic transmission. In some cases, the forwarded transmission may omit some data in the diagnostic transmission. For example, the forwarded transmission may omit the MAC address of the first network node, the corrupted data, the malicious data, at least some of the iOAM tags, or the like. According to some implementations, the forwarded transmission may include data that is different than data included in the diagnostic transmission. For instance, the forwarded transmission may include a MAC address of the intermediary node. In some cases, the forwarded transmission may be split into different messages received by the second network node at different times. For example, the forwarded transmission may include a first message carrying a first type of data in the diagnostic transmission and a second message carrying a second type of data in the diagnostic transmission, wherein the first and second messages are received at different times. In some cases, the forwarded transmission includes the cable length and/or the data traffic metrics of the diagnostic transmission.

At <NUM>, the diagnostic transmission may be compared to the forwarded transmission. For example, one or more data fields within the diagnostic transmission may be compared to one or more data fields within the forwarded transmission. In some cases, packets within the diagnostic transmission can be compared to one or more packets within the forwarded transmission.

At <NUM>, the process <NUM> includes determining whether the presence of an intermediary node is confirmed. In various cases, the presence of the intermediary node may be confirmed based on a discrepancy between the diagnostic transmission and the forwarded transmission. For instance, if a MAC address in the diagnostic transmission is different than a MAC address in the forwarded transmission, the presence of the intermediary node may be confirmed. Otherwise, if the diagnostic transmission and the forwarded transmission include the same MAC address, then the presence of the intermediary node may be unconfirmed.

In some examples, the presence of the intermediary node may be confirmed based on the absence of corrupted and/or malicious data within the forwarded transmission, despite the inclusion of the corrupted and/or malicious data within the diagnostic transmission. In some cases, only a portion of the corrupted and/or malicious data is excluded from the forwarded transmission. For example, a first portion of the corrupted and/or malicious data that corresponds to a first OSI layer may be included in the forwarded transmission, whereas a second portion of the corrupted and/or malicious data that corresponds to a second OSI layer may be excluded from the forwarded transmission. Thus, the intermediary node may be further confirmed to be active on the first OSI layer. However, if the corrupted and/or malicious data is included in the forwarded transmission, then the presence of the intermediary node may be unconfirmed.

In some cases, the presence of the intermediary node may be confirmed based on a discrepancy of times at which different types of data within the forwarded transmission are received. For instance, the diagnostic transmission may include the different types of data transmitted at the same time (or within a threshold time period of each other). However, if the different types of data are received at different times (or at different times separated by greater than the threshold time period), then the presence of the intermediary node may be confirmed. If, on the other hand, the different types of data are received at the same time (e.g., or within the threshold time period of each other), then the presence of the intermediary node may be unconfirmed.

According to various examples, the presence of the intermediary node may be confirmed based on a discrepancy between tags (e.g., iOAM tags) included in the diagnostic transmission and tags included in the forwarded transmission. In some cases, the absence of one or more packets from the forwarded transmission, which were included in the diagnostic transmission, can be identified based on the tags in the diagnostic transmission, the tags in the forwarded transmission, or a combination thereof. However, if the tags indicate that all of the packets in the diagnostic transmission are included in the forwarded transmission, then the presence of the intermediary node may be unconfirmed.

If the presence of the intermediary node is confirmed at <NUM>, then the presence of the intermediary node is reported at <NUM>. For example, a report indicating the presence of the intermediary node may be generated and transmitted to a network controller (e.g., the controller <NUM> described above with reference to <FIG>), some other node within the corresponding network, or to an external device (e.g., the user device(s) <NUM> described above with reference to <FIG>). In some cases, the type of the intermediary node (e.g., the OSI layer(s) on which the intermediary node is active) can be further indicated in the report. The report may be a transmission, in various cases.

If the presence of the intermediary node is not confirmed at <NUM>, then the process <NUM> includes determining whether the final diagnostic test has been performed at <NUM>. In various cases, a protocol specifying a particular order of diagnostic tests may be followed by the entity performing the process <NUM>. The protocol may be predetermined based on various factors. For instance, diagnostic tests including the injection of a minimal amount of data within the network may be performed before diagnostic tests including the injection of a greater amount of data. In some cases, relatively simple diagnostic tests (e.g., the address-based test) may be performed before more complex diagnostic tests (e.g., the corrupted data-based and/or the malicious data-based tests). At <NUM>, it may be determined whether the final diagnostic test within the protocol has been followed.

If the final diagnostic test is determined to have not been performed at <NUM>, then the process <NUM> proceeds to <NUM>. At <NUM>, an additional diagnostic transmission is received from the network node. In some cases, the entity performing the process <NUM> may transmit a message requesting the additional diagnostic transmission. The diagnostic transmission may correspond to a next diagnostic test within the protocol. Further, after execution of <NUM>, the process <NUM> returns to <NUM>, based on the execution of the next diagnostic test.

If, however, the final diagnostic test is determined to have been performed at <NUM>, the process proceeds to <NUM>. At <NUM>, the absence of the intermediary node is reported. For instance, a message indicating the absence of the intermediary node may be generated and transmitted to another network node and/or at least one external device. In some cases, the absence of the intermediary node can be reported to the network controller.

<FIG> shows an example computer architecture for a server computer <NUM> capable of executing program components for implementing the functionality described above. The computer architecture shown in <FIG> illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The server computer <NUM> may, in some examples, correspond to a network node (e.g., the first network node <NUM> and/or the second network node <NUM>) described herein.

The computer <NUM> includes a baseboard <NUM>, or "motherboard," which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") <NUM> operate in conjunction with a chipset <NUM>. The CPUs <NUM> can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer <NUM>.

The chipset <NUM> provides an interface between the CPUs <NUM> and the remainder of the components and devices on the baseboard <NUM>. The chipset <NUM> can provide an interface to a random-access memory (RAM) <NUM>, used as the main memory in the computer <NUM>. The chipset <NUM> can further provide an interface to a computer-readable storage medium such as a read-only memory (ROM) <NUM> or non-volatile RAM (NVRAM) for storing basic routines that help to startup the computer <NUM> and to transfer information between the various components and devices. The ROM <NUM> or NVRAM can also store other software components necessary for the operation of the computer <NUM> in accordance with the configurations described herein.

The computer <NUM> can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network <NUM>. The chipset <NUM> can include functionality for providing network connectivity through a network interface controller (NIC) <NUM>, such as a gigabit Ethernet adapter. The NIC <NUM> is capable of connecting the computer <NUM> to other computing devices over the network <NUM>. It should be appreciated that multiple NICs <NUM> can be present in the computer <NUM>, connecting the computer <NUM> to other types of networks and remote computer systems. In some instances, the NICs <NUM> may include at least on ingress port and/or at least one egress port.

The computer <NUM> can be connected to a storage device <NUM> that provides non-volatile storage for the computer. The storage device <NUM> can store an operating system <NUM>, programs <NUM>, and data, which have been described in greater detail herein. The storage device <NUM> can be connected to the computer <NUM> through a storage controller <NUM> connected to the chipset <NUM>. The storage device <NUM> can consist of one or more physical storage units. The storage controller <NUM> can interface with the physical storage units through a serial attached small computer system interface (SCSI) (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer <NUM> can store data on the storage device <NUM> by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device <NUM> is characterized as primary or secondary storage, and the like.

For example, the computer <NUM> can store information to the storage device <NUM> by issuing instructions through the storage controller <NUM> to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer <NUM> can further read information from the storage device <NUM> by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device <NUM> described above, the computer <NUM> can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer <NUM>. In some examples, the operations performed by any network node described herein may be supported by one or more devices similar to computer <NUM>. Stated otherwise, some or all of the operations performed by a network node may be performed by one or more computer devices <NUM> operating in a cloud-based arrangement.

By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.

As mentioned briefly above, the storage device <NUM> can store an operating system <NUM> utilized to control the operation of the computer <NUM>. According to one embodiment, the operating system comprises the LINUX™ operating system. According to another embodiment, the operating system includes the WINDOWS™ SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further embodiments, the operating system can comprise the UNIX™ operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device <NUM> can store other system or application programs and data utilized by the computer <NUM>.

In one embodiment, the storage device <NUM> or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer <NUM>, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer <NUM> by specifying how the CPUs <NUM> transition between states, as described above. According to one embodiment, the computer <NUM> has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer <NUM>, perform the various processes described above with regard to <FIG>. The computer <NUM> can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

As illustrated in <FIG>, the storage device <NUM> stores programs <NUM>, which may include one or more processes <NUM>, as well as a diagnostic system <NUM> (e.g., the first diagnostic system <NUM> and/or the second diagnostic system <NUM> described above with reference to <FIG>). The process(es) <NUM> may include instructions that, when executed by the CPU(s) <NUM>, cause the computer <NUM> and/or the CPU(s) <NUM> to perform one or more operations.

In summary, the disclosure describes techniques for diagnosing a presence or malfunction of a network node. In an example method, a first network node receives an indication of a diagnostic transmission originating from a second network node. The second network node further receives a forwarded transmission corresponding to the diagnostic transmission. The first network node diagnoses at least one of a presence or a malfunction of an intermediary node between the first network node and the second network node based on at least one of the indications of the diagnostic transmission or the forwarded transmission.

In some instances, one or more components may be referred to herein as "configured to," "configurable to," "operable/operative to," "adapted/adaptable," "able to," "conformable/conformed to," etc. Those skilled in the art will recognize that such terms (e.g., "configured to") can generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.

Claim 1:
A method (<NUM>), comprising:
receiving (<NUM>), by a first network node, an indication of a diagnostic transmission originating from a second network node;
receiving (<NUM>), by the first network node, a forwarded transmission corresponding to the diagnostic transmission; and
diagnosing (<NUM>), by the first network node, at least one of a presence or a malfunction of an intermediary node between the first network node and the second network node based on the indication of the diagnostic transmission and the forwarded transmission, wherein a header of the diagnostic transmission comprises a first address and a payload of the diagnostic transmission comprises the first address,
wherein a header of the forwarded transmission comprises a second address and the payload of the forwarded transmission comprises the first address, and
wherein diagnosing (<NUM>) the at least one of the presence or the malfunction of the intermediary node comprises determining that the first address in the payload of the forwarded transmission is different than the second address in the header of the forwarded transmission.