Network view

Connection issues can occur across different devices, users, binaries and destinations. Network view accelerates troubleshooting and helps you identify the appropriate team or vendor to fix network-related issues by providing an interactive visualization of connection.events data.

Accessing Network view

Network view is available in various modules and features to simplify troubleshooting network-related issues.

Application module

This enables application owners to troubleshoot network connectivity issues for their desktop or network application.

To access Network view in Applications

Open up either a desktop or a network app in the Applications module.
For applications that are both web and desktop, click on the Desktop tab
View the Network tab

Refer to the Applications documentation page for more information.

Device view

Device view continues to allowing troubleshooting a particular device To access Network view in Device view, open the Network tab. Refer to the Device View documentation page for more information.

Investigations module

Investigations allows you to investigate issues by writing and updating a query and visualizing it in Network view. To see Network view in Investigations:

From the Visual editor on the Investigation page, select Connection Events in the Display dropdown.
From the NQL editor on the Investigation page, run a query with connection.events table.

Refer to the Investigations documentation page for more information.

Search in the main menu:

Search enables you to quickly troubleshoot a particular binary, user, destination domain or port by getting to investigations prefiltered.

To troubleshoot a destination domain or port:
- Type in a specific destination domain or port whether configured or not in Nexthink, click on Connections to the destination in the pop-up search window and open the Network tab on the loaded page.
To troubleshoot a binary, user or device:
- select Retrieve all > (Connection) Events from the binary action menu in the pop-up search window and open the Network tab on the loaded page. See the image below.

The system will filter the Network view visualization based on the entry point you use. For instance, display Network view with pre-filtered connection events for a particular binary.

Refer to the Search documentation page for more information.

Data privacy in Network view

To prevent users from seeing sensitive data in Network view or in an investigation, set the Data privacy restriction of the user profile to any of the options below.

anonymous users, devices, destinations and domains
anonymous users and devices
anonymous users

Data privacy restrictions apply to the connection.events data used by Network view.

Refer to the Profiles documentation for more information.

Seeing Network view in Investigations

To see the Network view in Investigations, the query must use the Connection events table.

In the Visual editor, choose Connection Events in the Display dropdown.

In the NQL editor, ensure the query starts with connection.events.

To troubleshoot specific network-related issues using queries, refer to the Application Connectivity troubleshooting documentation.

Using Network view

Network view breaks down the selected metrics for connection.events into multiple properties and shows how properties relate. Nodes and lines represent these relationships.

Network view displays four columns by default, allowing you to click on nodes or lines to drill down lower levels of breakdowns.

To switch from the displayed metrics and begin troubleshooting issues:

Click the Display dropdown above the Network view visualization.
Select one of the available metrics for the particular connection data set.

Transport protocols in Network view

Sort the connection.events data displayed in Network view according to the transport protocol.

Find the following options above the Network view visualization:

Click TCP only for Transmission Control Protocol (TCP) connections established by a device.
Click UDP only for User Datagram Packages (UDP).
Click Any for both TCP and UDP.

Line thickness for visual comparison

The thickness of a line, which connects two nodes, is proportional to the metric value between those respective nodes when compared to the same metric values between different nodes in the same two columns.

The screenshot below shows the metric value between the columns Application → name and Destination type, which in this case represents connections values.

The thin line between the Outlook application node and the internet destination, considering the metric value for this case, represents fewer connections when compared to the MECM application node.

When viewing issue-related metrics, thick lines help you identify the most problematic areas.

Line coloring for issue detection

To identify issues quickly, lines are shown in red for the following issue-related metrics:

Failed connections : number_of_failed_connections
Failed connections - no host : failed_connections___no_host__
Failed connections - no service : failed_connections___no_service__
Failed connections - no service : failed_connections___rejected__

These issue-related metrics require setting the transport protocol to TCP only as they exclusively apply to TCP connections.

Node sorting

The system sorts nodes in descending order within each column. This makes it likelier that thicker lines appear towards the top, but this is not always true.

Network view shows the top eight nodes in each column. If a column has more than eight nodes, the values are aggregated into the Others node at the bottom of the column:

Click on More to open another eight nodes in a column.
Click Less to hide additional nodes.

To facilitate data interpretation, each node is associated with all paths going through it.

Hovering over a node or line

Hover over a node or a line to highlight the connection metric value that goes through that node or line.

The example below highlights all failed_connections___no_host__ between users from Solution Consulting and the Firefox application.

Drilling down to specific fields

Network view displays four columns by default. Each column is associated with a hierarchy of fields to reduce the number of nodes shown on the screen.

The table below lists the hierarchy of fields for each column, which goes from general to specific.

Column 1 Device	Column 2 User	Column 3 Binary	Column 4 Destination
Public IP → Country	AD Department	Application → Name	Destination → Type
Public IP → State	Username	Binary → Product name	Destination → Owner
Public IP → City		Binary → Name	Destination → Country
Device → Name		Binary → Version	Destination → Data center region
			Destination → Domain

To drill down on a Network view field, you have the following options:

Click on a node in the Network view visualization.
Click on a line between two nodes.

After clicking on a node or line, you can navigate back up the hierarchy using the expandable dropdowns in each column heading in Network view.

Clicking on a node

Click on a node to:

Apply a filter for the selected node.
Drill down one level in the column hierarchy.

In the example below, Network view applies a filter for the Zoom application.

Therefore, the third column levels down from Application → Name to Binary → Product name. The visualization and breakdowns are now as follows:

Column 1 Device	Column 2 User	Column 3 Binary	Column 4 Destination
Public IP → Country	AD Department	Application → Name	Destination → Type
Public IP → State	Username	Binary → Product name	Destination name
Public IP → City		Binary → Name	Destination location
Device → Name		Binary → Version	Destination domain name

Clicking on a line

Click on a line to:

Apply a filter for the selected line, which is equivalent to clicking on the two nodesit connects.
Drill down one level in the hierarchy of the connected columns.

Therefore, using the example from above, clicking the line between the nodes zoom.us and internet results in:

The third column levels down from Application → Name to Binary → Product name
The fourth column levels down from Destination → Type to Destination → Owner.

The visualization and breakdowns are now as follows:

Column 1 Device	Column 2 User	Column 3 Binary	Column 4 Destination
Public IP → Country	AD Department	Application → Name	Destination type
Public IP → State	Username	Binary → Product name	Destination → Owner
Public IP → City		Binary → Name	Destination location
Device → Name		Binary → Version	Destination domain name

Navigating back up the hierarchy

To navigate back up the hierarchy of the Network view fields after clicking on nodes or lines:

Click on the dropdown in the Network view column heading.
Click on any field names above the current level in the hierarchy.

When you access Network view specific to a binary or destination domain, the system applies filters to the column in Network view and sets the hierarchy to match the requested field.

The example below shows pre-filtered Alive connections data for the excel.exe binary. Click Clear filters to remove any field hierarchy filters.

CODE

| where binary.binary.name in ["excel.exe"]

Displaying ports

Toggle the Show ports button to view an additional column with the ports that have network connection activity. This enables you to troubleshoot when ports are being incorrectly blocked by the firewall or to identify ports that have unexpected traffic.

Since there can be thousands of ports connected, the system only displays 20 ports with the top metric values within the existing filter and timeframe context.

Example

Let’s say that we are looking at the Network view with the following parameters:

Application: Microsoft 365: Outlook
Timeframe: Last 7 days
Metric: Failed connections
Filter: Binary name (we have clicked the outlook.exe binary node)

When the show ports toggle is enabled, it determines and displays the top 20 ports with the most failed connections for the Microsoft 365: Outlook application and the outlook.exe binary.

Since the system only displays the top 20 ports, nodes in other columns may change depending on whether they use those top 20 ports.

The system determines the top 20 ports each time you click on a node or line. Depending on the data, the exact ports displayed may change as you drilldown.

If you start from a query that is already filtered on one or more ports, for instance, by using search, the Network view automatically displays the ports column with specified ports.

Example

If you start with the following NQL query containing filter on two ports and then navigate to the Network tab, the Ports column with the 3268 and 443 ports appears. In this case, system does not limit the number of ports displayed in the Network view.

CODE

connection.events during past 7d
| where application.name == "*Outlook*"
| where destination.port in [3268, 443]

Failed connections and failed connection ratio

When looking at the failed connections, the failed connection ratio can be very important to consider as well.

For example, when looking at the ports column in this screenshot, port 443 is at the very top with the most failed connections.

When we hover over this node, however, we see that there are a lot of attempted connections (410k) through the port. The percent of connections that have failed is low: 0.82%

If we look at the port with the next highest number of failed connections, 3268, we see a different story. 100% of the connections through this port are failing. Given the high absolute number of failed connections and the high failed connection ratio, this would be something to investigate.

Network view capacities

Network data

Network view is tied to the Application connection data (connection.events), which are the connections as observed from the operating system level.

This does not join with device-level connectivity data (connectivity.events). For example, this does not give visibility into slow connection RTT time and their Wi-Fi access points or Wi-Fi strength.
This does not join with browser level connectivity data (web.events, web.errors). For example, this does not give visibility into whether the employee is seeing certain HTTP errors or is connecting over https/http.
This does not join with application / service specific connection data (collaboration.sessions). For example, this does not give visibility into Teams call quality or Zoom call jitter.
Nexthink does not do any synthetic connections or traceroutes, so this does not provide insight into the intermediary hops via gateways.

NQL 10,000 row limit

Network view is restricted to a maximum of 10,000 unique connection paths.

A connection path is a distinct permutation of values in each of the four columns of Network view. The table below is an example of connection paths.

See Using Network view on this page for more information about Network view columns and field hierarchy.

Path	Column 1 Device	Column 2 User	Column 3 Binary	Column 4 Destination
Path	Public IP → Country	AD Department	Application → Name	Destination type
1	United States	Null	Null	internet
2	United States	Null	Null	intranet
3	United States	Null	Null	data center
4	United States	Null	Null	unknown
5	United States	Null	Chrome	internet
…	…	…	…	…
10,000	Singapore	Engineering operations	Photoshop	unknown

Query time-out

Network view queries take time to load significant amounts of connection data. To expedite the loading time, reduce the amount of connection data by:

Decreasing the timeframe.
Applying filters.