Introduction to connection troubleshoot in Azure Network Watcher
The connection troubleshoot feature of Network Watcher provides the capability to check a direct TCP connection from a virtual machine to a virtual machine (VM), fully qualified domain name (FQDN), URI, or IPv4 address. Network scenarios are complex, they're implemented using network security groups, firewalls, user-defined routes, and resources provided by Azure. Complex configurations make troubleshooting connectivity issues challenging. Network Watcher helps reduce the amount of time to find and detect connectivity issues. The results returned can provide insights into whether a connectivity issue is due to a platform or a user configuration issue. Connectivity can be checked with PowerShell, Azure CLI, and REST API.
Important
Connection troubleshoot requires that the VM you troubleshoot from has the AzureNetworkWatcherExtension
VM extension installed. For installing the extension on a Windows VM visit Azure Network Watcher Agent virtual machine extension for Windows and for Linux VM visit Azure Network Watcher Agent virtual machine extension for Linux. The extension is not required on the destination endpoint.
Supported source types
The following sources are supported by Network Watcher:
- Virtual Machines
- Bastion
- Application Gateways (except v1)
Response
The following table shows the properties returned when connection troubleshoot has finished running.
Property | Description |
---|---|
ConnectionStatus | The status of the connectivity check. Possible results are Reachable and Unreachable. |
AvgLatencyInMs | Average latency during the connectivity check, in milliseconds. (Only shown if check status is reachable) |
MinLatencyInMs | Minimum latency during the connectivity check, in milliseconds. (Only shown if check status is reachable) |
MaxLatencyInMs | Maximum latency during the connectivity check, in milliseconds. (Only shown if check status is reachable) |
ProbesSent | Number of probes sent during the check. Max value is 100. |
ProbesFailed | Number of probes that failed during the check. Max value is 100. |
Hops | Hop by hop path from source to destination. |
Hops[].Type | Type of resource. Possible values are Source, VirtualAppliance, VnetLocal, and Internet. |
Hops[].Id | Unique identifier of the hop. |
Hops[].Address | IP address of the hop. |
Hops[].ResourceId | ResourceID of the hop if the hop is an Azure resource. If it's an internet resource, ResourceID is Internet. |
Hops[].NextHopIds | The unique identifier of the next hop taken. |
Hops[].Issues | A collection of issues that were encountered during the check at that hop. If there were no issues, the value is blank. |
Hops[].Issues[].Origin | At the current hop, where issue occurred. Possible values are: Inbound - Issue is on the link from the previous hop to the current hop Outbound - Issue is on the link from the current hop to the next hop Local - Issue is on the current hop. |
Hops[].Issues[].Severity | The severity of the issue detected. Possible values are Error and Warning. |
Hops[].Issues[].Type | The type of issue found. Possible values are: CPU Memory GuestFirewall DnsResolution NetworkSecurityRule UserDefinedRoute |
Hops[].Issues[].Context | Details regarding the issue found. |
Hops[].Issues[].Context[].key | Key of the key value pair returned. |
Hops[].Issues[].Context[].value | Value of the key value pair returned. |
The following is an example of an issue found on a hop.
"Issues": [
{
"Origin": "Outbound",
"Severity": "Error",
"Type": "NetworkSecurityRule",
"Context": [
{
"key": "RuleName",
"value": "UserRule_Port80"
}
]
}
]
Fault types
Connection troubleshoot returns fault types about the connection. The following table provides a list of the current fault types returned.
Type | Description |
---|---|
CPU | High CPU utilization. |
Memory | High Memory utilization. |
GuestFirewall | Traffic is blocked due to a virtual machine firewall configuration. Note that a TCP ping is a unique use case in which, if there's no allowed rule, the firewall itself responds to the client's TCP ping request even though the TCP ping doesn't reach the target IP address/FQDN. This event isn't logged. If there's a network rule that allows access to the target IP address/FQDN, the ping request reaches the target server and its response is relayed back to the client. This event is logged in the Network rules log. |
DNSResolution | DNS resolution failed for the destination address. |
NetworkSecurityRule | Traffic is blocked by an NSG Rule (Rule is returned) |
UserDefinedRoute | Traffic is dropped due to a user defined or system route. |
Next steps
Learn how to troubleshoot connections using the Azure portal, PowerShell, the Azure CLI, or REST API.
Feedback
Submit and view feedback for