Network view
Last updated
Last updated
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.
Network view is available in various modules and features to simplify troubleshooting network-related issues.
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 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 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 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.
To prevent users from seeing sensitive data in Network view or investigations, define Data privacy:
Destinations and domains: Set to Hidden to hide destinations and domains of connectivity events from the user.
Devices: Set to Hidden to hide device names from the user.
Users: Set to Hidden to hide user names from the user.
Data privacy restrictions apply to the connection.events data used by Network view.
Refer to the Roles documentation for more information.
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.
Network view breaks down the selected metrics for connection.events into multiple properties and shows on the connection paths how properties relate. Nodes and lines represent these relationships.
The Network view connection paths display 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.
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.
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 failed_connections_ratio values.
The thin line between the Excel application node and the intranet destination, considering the metric value for this case, represents a smaller failed_connections_ratio when compared to the Microsoft Office application node.
When viewing issue-related metrics, thick lines help you identify the most problematic areas.
To identify issues quickly, lines are shown in red for the following issue-related metrics:
Failed connections ratio: failed_connections_ratio
Failed connections: number_of_failed_connections
Failed connections - no host: number_of_no_host_connections
Failed connections - no service: number_of_no_service_connections
Failed connections - no service: number_of_rejected_connections
For these issue-related metrics the system sets the transport protocol to TCP only as they exclusively apply to TCP connections.
For other metrics which are not issue-related, the lines are shown in blue.
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.
Hover over a node or a line to highlight the connection metric value that goes through that node or line.
The example below highlights the ratios of failed connections involving users from Product department and the excel.exe application.
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.
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:
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.
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:
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
Click on a line to:
Apply a filter for the selected line, which is equivalent to clicking on the two nodes it 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 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:
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 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.
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.
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.
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.
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.
The Connections timeline displays the selected metric’s development over time. For example, if you have selected Failed connections, it will show the number of failed connections across timeframe selected in the timeframe picker.
The timeline is synchronized with the connection paths. When you drill down or up on nodes, the timeline chart will update accordingly. If you are in the Investigations module and you have applied filters to your query, these filters will apply to both the connection paths and the timeline.
The Connection timeline is interactive. To focus on a specific period of interest, click and drag your mouse cursor over that timeframe in the timeline.
This action will load both Network view chart and the timeline for that period, allowing you to analyze connections data during that time.
Currently, dragging to select a period on the timeline does NOT update the timeframe picker at the top of the page. To align the displayed data with the selection in the timeframe picker, click the Reset timeframe button located above the Connections timeline.
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.
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.
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
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.
RELATED TOPICS
RELATED TRAINING
