Troubleshoot Azure with Network Watcher: Diagnostic Tools
I’m sure a lot of cloud admins had their euphoric moment when they moved / provisioned their first VMs as part of their hybrid environments. The benefits and elasticity of Microsoft Azure ensure you don’t miss out on anything from your old, traditional data center environment. In the IaaS (infrastructure as a service) versus on-premises debate, the changes don’t change that much from a management perspective. At the end of the day, we’re used to managing VMs running on our hypervisors. In Azure, it’s similar through a portal but with virtually unlimited headroom to increase the complexity and resources of the environment. The network area is not very clear compared to IaaS compared to virtual machines for a traditional network administrator. To begin with, everything is SDN (Software Defined Networking.) The cloud administrator should be familiar with how the network works in Azure and getting to know Network Watcher will help a lot when troubleshooting. In this first of two articles, we’ll show you how to get started with Network Watcher and show you a few tools you can use to make your job easier.
Getting started with Network Watcher
Network Watcher is free and does not require a provisioning process. We just need to activate the regions we want to monitor. To start using it, type Network Observer in the search box of the Azure portal. In the Overview panel, right-click the regions where you want to enable the service and click Enable network viewer. That’s it! After that, we can start exploring the different tools available on the platform.
The functionality includes three main areas: monitoring, network diagnostic tools, and logs.
This area consists of three elements: Topology, Connection Monitor, and Network Performance Monitor (NPM). Some of the blades that we can see in Network Watcher are shared with other network components on the Azure portal.
For example, the topology blade allows the cloud administrator to select a subscription, then a resource group within that subscription, and finally a specific virtual network. The result will be a graphical representation of the virtual network, including virtual machines, network interfaces, and even NSGs (Network Security Groups).
If you need to use the diagram, you can always click download topology and an .svg file will be available for download.
The second blade in the monitoring section is the connection monitor. It is a key element. We can monitor the endpoints and they can be an existing VM in Azure or a specific IP address / name. To create our first connection monitor, click on Add then specify the VM that will be the source and define the target. We can configure which port will be monitored and how often we want the probe to run. When finished, click Add.
Wait a bit, and we’ll have metrics on the connection, and we can display historical data in a grid or graph format, as shown in the image below.
- When selecting a VM as the source in the wizard, all of the target VMs listed will be part of the same virtual network. To overcome this limitation, we can always specify the IP address instead of selecting an existing VM in the wizard.
- When a VM is selected as The source, the AzureNetworkWatcherExtension will be automatically added to the given virtual machine.
- All connection monitors are displayed in the Azure Monitor / Alerts Region. Thus, a notification can be created based on the number generated by the connection monitor.
The Network Performance Monitor (NPM) uses Log Analytics and provides a solution to help the administrator understand the network. This one-of-a-kind piece requires an item on its own, and that’s why we’re going to discuss it here. (Stay tuned for this article!)
The functionality requires Log Analytics in a specific set of regions. At the time of writing this article (nine regions), it needs Log Analytics agents installed on at least one VM resource on each subnet to be able to perform proper monitoring. The solution allows monitoring of other services such as Office 365, Dynamics and even Express Route.
Exploring the Network Diagnostic Tools Area
The Checking the IP flow checks whether a provided communication will succeed or be denied depending on the current configuration. It uses five pieces of information: protocol, source IP address, destination IP address, source port, and destination port. Which answer will be Network security group rule was in effect for the proposed traffic.
The cloud administrator should select the virtual machine and network interface, then provide the destination IP address and port.
Next Hop is a simple but effective tool. The cloud administrator should select any existing virtual machine in Microsoft Azure and the target IP address. The tool will run a simulation for this traffic and provide the next hop type and IP address (if possible). Some examples of Next Hop are Internet, VirtualNetworkPeering and Virtual Network.
The Effective safety rules The tool allows the cloud administrator to select a virtual machine and its network interface. The result will be the associated NSG (if network interface or subnet level) and the incoming and outgoing rules.
The Network capture The tool resolves a very common request between the network team and the operations team when troubleshooting, which is the ability to capture traffic in a given virtual machine.
Before exploring this feature, it is recommended to create a storage account that will be used to save all captures. There is an option to keep in the monitored virtual machine. However, using storage accounts is faster to retrieve information and provides more flexibility to share files between different users without needing to connect to the affected server.
To start capturing, click Add. We need to select a subscription, a resource group and a virtual machine. We need to give the capture a name and set the following values:
- Maximum number of bytes per packet (0 means unlimited).
- Maximum number of bytes per session (1 GB in bytes).
- How long the capture will work (in our article we set a time).
To save time and space in storage, we have a few options to filter traffic by selecting source and target protocol, addresses and ports.
All captures will be listed in the Packet capture blade. We can download the .pcap link, which can be retrieved from the Details. We can delete the capture at any time by right clicking on it and selecting Stop.
The file generated as part of the capture will be stored as a blob in the storage account. This is a long path that provides all the information to identify the virtual machine, network interface, date and Azure location of the resource in question. We may use Wireshark or any other similar tool to analyze the information.
Network Watcher: Just scratch the surface
In this first article of our two-part series, we’ve covered part of the diagnostic tools section. We’ve seen how easy it is for the cloud to accomplish a series of tasks, such as:
- Administrator to generate traces.
- See a diagram of the network and virtual network adapters.
- Check if the traffic is allowed.
- Check the existing safety rules in place.
Using these tools, the cloud administrator can verify and validate communication issues between different resources within Azure and between networks.
For the second article in this two-part series where we take a look at Network Watcher Traffic Analytics, click here.
Featured Image: Shutterstock