Cisco Technology, Inc.

Appdynamics, Inc.

Check Point Software Technologies Ltd.

Ajay Chandel

Harish Nataraj

Prakash Kaligotla

Naveen Kondapalli

Jyoti Bansal

Bhaskar Sunkara

Nikhar Rakesh Saxena

Adam Leftik

According to one or more embodiments of the disclosure, techniques herein provide for auto discovery of network proxies. In particular, in one embodiment, a controller in a computer network receives, from both source devices and destination devices, corresponding Transmission Control Protocol/Internet Protocol (TCP/IP) information and associated transaction identifiers (IDs) for packets sent by the source devices and for packets received at the destination devices. The controller may then correlate particular source TCP/IP information to particular destination TCP/IP information based on associated transaction IDs being the same, and can compare the correlated source TCP/IP information and destination TCP/IP information in order to determine whether a proxy device exists (e.g., and which particular type of proxy device exists) between the source device and the destination device.

Auto discovery of network proxies

In one embodiment, a network analysis process initiates network path analysis for a transaction application operating over a logical transaction path having a first segment from a first set of transaction servers to a load balancer and a second segment then to a second set of transaction servers. The network path analysis, when for the second segment, comprises: selecting a receiving transaction server of the second set of transaction servers; identifying a TCP session associated with the transaction application already in progress to the receiving transaction server; initiating a TCP traceroute using ACK packets, whose signature matches the in-progress TCP session, from the receiving transaction server to the load balancer; and determining, in reverse, a network path of layer-3 segments and associated network metrics between the receiving transaction server and the load balancer. Specific layer-3 segments of the network path causing performance degradation of the transaction application are then identifiable.

Deep network path analysis for identifying network segments affecting application performance

In one embodiment, an agent process produces synthetic packet traffic and iteratively performs a sub-process that determines isolated network segments of the communication channel between intermediate nodes and computes a set of network metrics for the isolated network segments based at least in part on incrementing TTL expiry error data points. The sub-process also encapsulates, for inclusion within the next packet to be sent, a list of intermediate node IDs along the communication channel up to a latest received node ID and computed sets of network metrics for respective network segments. The agent process may then generate, upon termination of the sub-process, a report, the report including the list of intermediate node IDs along the communication channel up to a latest received node ID and computed sets of network metrics for respective network segments.

Isolation of network segments affecting application performance

In one embodiment, a network agent, associated with an operating system of a computing device, tracks socket connection calls made by a plurality of cotenant processes on the computing device that share a common network transport between the computing device and a remote computing device. The network agent may then extract a process identification (ID) for the socket connection calls, the process ID identifying which particular cotenant process of the plurality of cotenant processes is making each particular socket connection call. While monitoring network metrics of network traffic flows over socket connections between the computing device and the remote computing device, the network agent may attribute given network metrics from particular socket connections to a corresponding cotenant process based on the correlated process ID for the socket connection. As such, the network agent may then report the network metrics as attributed to the corresponding cotenant processes.

Network visibility for cotenant processes

A system monitors applications and network flows used during the business transaction to determine distributed business transaction anomalies caused at least in part by network performance issues. A network flow associated with a business transaction is monitored by a network agent. The network agent may capture packets, analyze the packets and other network data to determine one or more baselines, and dynamically compare subsequent network flow performance to those baselines to determine an anomaly. When an anomaly in a network flow is detected, this information may be provided to a user along with other data regarding a business transaction that is utilizing the network flow. Concurrently with the network agent monitoring, application agents may monitor one or more applications performing the business transaction. The present system reports performance data for a business transaction in terms of application performance and network performance, all in the context of a distributed business transaction.

Network aware distributed business transaction anomaly detection

A system determines the performance of a network within the context of an application using that network. Network data is collected and correlated with an application that uses the network as well as a distributed transaction implemented by the application. The collected network data is culled, and the remaining data is rolled up into one or more metrics. The metrics, selected network data, and other data are reported in the context of the application that implements part of the distributed transaction. In this manner, specific network performance and architecture data is reported along with application context information.

Application centric network experience monitoring

Data access optimization features the innovative use of a writer-present flag when acquiring read-locks and write-locks. Setting a writer-present flag indicates that a writer desires to modify a particular data. This serves as an indicator to readers and writers waiting to acquire read-locks or write-locks not to acquire a lock, but rather to continue waiting (i.e., spinning) until the write-present flag is cleared. As opposed to conventional techniques in which readers and writers are not locked out until the writer acquires the write-lock, the writer-present flag locks out other readers and writers once a writer begins waiting for a write-lock (that is, sets a writer-present flag). This feature allows a write-lock method to acquire a write-lock without having to contend with waiting readers and writers trying to obtain read-locks and write-locks, such as when using conventional spinlock implementations.

Growing community of inventors

Fremont, CA, United States of America

Ajay Chandel