Lab: Use Azure Network Watcher for monitoring and troubleshooting network connectivity

All tasks in this lab are performed from the Azure portal (including a PowerShell Cloud Shell session)

Note: When not using Cloud Shell, the lab virtual machine must have the Azure PowerShell 1.2.0 module (or newer) installedhttps://docs.microsoft.com/en-us/powershell/azure/install-az-ps

Lab files:

  • Labfiles\Module_06\Network_Watcher\az-101-03b_01_azuredeploy.json

  • Labfiles\Module_06\Network_Watcher\az-101-03b_02_azuredeploy.json

  • Labfiles\Module_06\Network_Watcher\az-101-03b_01_azuredeploy.parameters.json

  • Labfiles\Module_06\Network_Watcher\az-101-03b_02_azuredeploy.parameters.json

Scenario

Adatum Corporation wants to monitor Azure virtual network connectivity by using Azure Network Watcher.

Objectives

After completing this lab, you will be able to:

  • Deploy Azure VMs, Azure storage accounts, and Azure SQL Database instances by using Azure Resource Manager templates

  • Use Azure Network Watcher to monitor network connectivity

Exercise 1: Prepare infrastructure for Azure Network Watcher-based monitoring

The main tasks for this exercise are as follows:

  1. Deploy Azure VMs, an Azure Storage account, and an Azure SQL Database instance by using an Azure Resource Manager template

  2. Enable Azure Network Watcher service

  3. Establish peering between Azure virtual networks

  4. Establish service endpoints to an Azure Storage account and Azure SQL Database instance

Task 1: Deploy Azure VMs, an Azure Storage account, and an Azure SQL Database instance by using Azure Resource Manager templates

  1. From the lab virtual machine, start Microsoft Edge, browse to the Azure portal at http://portal.azure.com and sign in by using a Microsoft account that has the Owner role in the target Azure subscription.

  2. In the Azure portal, navigate to the New blade.

  3. From the New blade, search Azure Marketplace for Template deployment.

  4. In the list of results, click Template deployment (deploy using custom templates), and then click Create.

  5. On the Custom deployment blade, click the Build your own template in the editor link. If you do not see this link, click Edit template instead.

  6. From the Edit template blade, load the template file Labfiles\Module_06\Network_Watcher\az-101-03b_01_azuredeploy.json.

    Note: Review the content of the template and note that it defines deployment of an Azure VM, an Azure SQL Database, and an Azure Storage account.

  7. Save the template and return to the Custom deployment blade.

  8. From the Custom deployment blade, navigate to the Edit parameters blade.

  9. From the Edit parameters blade, load the parameters file Labfiles\Module_06\Network_Watcher\az-101-03b_01_azuredeploy.parameters.json.

  10. Save the parameters and return to the Custom deployment blade.

  11. From the Custom deployment blade, initiate a template deployment with the following settings:

    • Subscription: the name of the subscription you intend to use in this lab

    • Resource group: the name of a new resource group az1010301b-RG

    • Location: the name of the Azure region which is closest to the lab location and where you can provision Azure VMs and Azure SQL Database

    • Vm Size: Standard_DS2_v2

    • Vm Name: az1010301b-vm1

    • Admin Username: Student

    • Admin Password: Pa55w.rd1234

    • Virtual Network Name: az1010301b-vnet1

    • Sql Login Name: Student

    • Sql Login Password: Pa55w.rd1234

    • Database Name: az1010301b-db1

    • Sku Name: Basic

    • Sku Tier: Basic

    Note: To identify VM sizes available in your subscription in a given region, run the following from Cloud Shell and review the values in the Restriction column (where <location> represents the target Azure region):

    Get-AzComputeResourceSku | where {$_.Locations -icontains "<location>"} | Where-Object {($_.ResourceType -ilike "virtualMachines")}
    

    Note: To identify whether you can provision Azure SQL Database in a given region, run the following from Cloud Shell and ensure that the resulting Status is set to Available (where <location> represents the target Azure region):

    Get-AzSqlCapability -LocationName <regionname>
    

    Note: Do not wait for the deployment to complete but proceed to the next step.

  12. In the Azure portal, navigate to the New blade.

  13. From the New blade, search Azure Marketplace for Template deployment.

  14. In the results, click Template deployment (deploy using custom templates), and then click Create.

  15. On the Custom deployment blade, click the Build your own template in the editor link. If you do not see this link, click Edit template instead.

  16. From the Edit template blade, load the template file Labfiles\Module_06\Network_Watcher\az-101-03b_02_azuredeploy.json.

    Note: Review the content of the template and note that it defines deployment of an Azure VM.

  17. Save the template and return to the Custom deployment blade.

  18. From the Custom deployment blade, navigate to the Edit parameters blade.

  19. From the Edit parameters blade, load the parameters file Labfiles\Module_06\Network_Watcher\az-101-03b_02_azuredeploy.parameters.json.

  20. Save the parameters and return to the Custom deployment blade.

  21. From the Custom deployment blade, initiate a template deployment with the following settings:

    • Subscription: the name of the subscription you are using in this lab

    • Resource group: the name of a new resource group az1010302b-RG

    • Location: the name of an Azure region where you can provision Azure VMs, but which is different from the one you selected during previous deployment,

    • Vm Size: Standard_DS2_v2

    • Vm Name: az1010302b-vm2

    • Admin Username: Student

    • Admin Password: Pa55w.rd1234

    • Virtual Network Name: az1010302b-vnet2

    Note: Make sure to choose a different Azure region for this deployment

Note: Do not wait for the deployment to complete but proceed to the next step.

Task 2: Enable Azure Network Watcher service

  1. In the Azure portal, use the search text box on the All services blade to navigate to the Network Watcher blade.

  2. On the Network Watcher blade, verify that Network Watcher is enabled in both Azure regions into which you deployed resources in the previous task and, if not, enable it.

Task 3: Establish peering between Azure virtual networks

Note: Before you start this task, ensure that the template deployment you started in the first task of this exercise has completed.

  1. In the Azure portal, navigate to the az1010301b-vnet1 virtual network blade.

  2. From the az1010301b-vnet1 virtual network blade, display the az1010301b-vnet1 - Peerings blade.

  3. From the az1010301b-vnet1 - Peerings blade, create a VNet peering with the following settings:

    • Name: az1010301b-vnet1-to-az1010302b-vnet2

    • Virtual network deployment model: Resource manager

    • Subscription: the name of the Azure subscription you are using in this lab

    • Virtual network: az1010302b-vnet2

    • Name of peering from az1010302b-vnet2 to az1010301b-vnet1: az1010302b-vnet2-to-az1010301b-vnet1

    • Allow virtual network access from az1010301b-vnet1 to az1010302b-vnet2: Enabled

    • Allow virtual network access from az1010302b-vnet2 to az1010301b-vnet1: Enabled

    • Allow forwarded traffic from az1010302b-vnet2 to az1010301b-vnet1: Disabled

    • Allow forwarded traffic from az1010301b-vnet1 to az1010302b-vnet2: Disabled

    • Allow gateway transit: Disabled

Note: The Azure portal allows you to configure both directions of the peering simultaneously. When using other management tools, each direction must be configured independently.

Task 4: Establish service endpoints to an Azure Storage account and Azure SQL Database instance

  1. In the Azure portal, navigate to the az1010301b-vnet1 virtual network blade.

  2. From the az1010301b-vnet1 virtual network blade, display the Service endpoints blade.

  3. From the az1010301b-vnet1 - Service endpoints blade, add a service endpoint with the following settings:

    • Service: Microsoft.Storage

    • Subnets: subnet0

  4. Repeat the step to create a second service endpoint:

    • Service: Microsoft.Sql

    • Subnets: subnet0

  5. In the Azure portal, navigate to the az1010301b-RG resource group blade.

  6. From the az1010301b-RG resource group blade, navigate to the blade of the storage account included in the resource group.

  7. From the storage account blade, navigate to its Firewalls and virtual networks blade.

  8. From the Firewalls and virtual networks blade of the storage account, configure the following settings:

    • Allow access from: Selected networks

    • Virtual networks:

      • VIRTUAL NETWORK: az1010301b-vnet1

        • SUBNET: subnet0
    • Firewall:

      • ADDRESS RANGE: none
    • Exceptions:

      • Allow trusted Microsoft services to access this storage account: Enabled

      • Allow read access to storage logging from any network: Disabled

      • Allow read access to storage metrics from any network: Disabled

  9. In the Azure portal, navigate to the az1010301b-RG resource group blade.

  10. From the az1010301b-RG resource group blade, navigate to the az1010301b Azure SQL Server blade.

  11. From the Azure SQL Server blade, navigate to its server’s Firewalls and virtual networks blade.

  12. From the Firewalls and virtual networks blade of the Azure SQL Database server, configure the following settings:

    • Deny public network access: No

    • Connection policy: Default

    • Allow Azure services and resources access to this server: No

    • No firewall rules configured

    • Virtual networks:

      • Name: az1010301b-vnet1

      • Subscription: the name of the subscription you are using in this lab

      • Virtual network: az1010301b-vnet1

      • Subnet name: subnet0/ 10.203.0.0/24

Result: After you completed this exercise, you have deployed Azure VMs, an Azure Storage account, and an Azure SQL Database instance by using Azure Resource Manager templates, enabled Azure Network Watcher service, established global peering between Azure virtual networks, and established service endpoints to an Azure Storage account and Azure SQL Database instance.

Exercise 2: Use Azure Network Watcher to monitor network connectivity

The main tasks for this exercise are as follows:

  1. Test network connectivity to an Azure VM via virtual network peering by using Network Watcher

  2. Test network connectivity to an Azure Storage account by using Network Watcher

  3. Test network connectivity to an Azure SQL Database by using Network Watcher

Task 1: Test network connectivity to an Azure VM via virtual network peering by using Network Watcher

  1. In the Azure portal, navigate to the Network Watcher blade.

  2. From the Network Watcher blade, navigate to the Connection troubleshoot.

  3. On the Network Watcher - Connection troubleshoot blade, initiate a check with the following settings:

    • Source:

      • Subscription: the name of the Azure subscription you are using in this lab

      • Resource group: az1010301b-RG

      • Source type: Virtual machine

      • Virtual machine: az1010301b-vm1

    • Destination: Specify manually

      • URI, FQDN or IPv4: 10.203.16.4

      Note: 10.203.16.4 is the private IP address of the second Azure VM az1010302b-vm1 which you deployed to another Azure region

    • Probe Settings:

      • Protocol: TCP

      • Destination port: 3389

    • Advanced settings:

      • Source port: blank
  4. Wait until results of the connectivity check are returned and verify that the status is Reachable. Review the network path and note that the connection was direct, with no intermediate hops in between the VMs.

    Note: If this is the first time you are using Network Watcher, the check can take up to 5 minutes.

Task 2: Test network connectivity to an Azure Storage account by using Network Watcher

  1. From the Azure Portal, start a PowerShell session in the Cloud Shell.

    Note: If this is the first time you are launching the Cloud Shell in the current Azure subscription, you will be asked to create an Azure file share to persist Cloud Shell files. If so, accept the defaults, which will result in creation of a storage account in an automatically generated resource group.

  2. In the Cloud Shell pane, run the following command to identify the IP address of the blob service endpoint of the Azure Storage account you provisioned in the previous exercise:

    [System.Net.Dns]::GetHostAddresses($(Get-AzStorageAccount -ResourceGroupName 'az1010301b-RG')[0].StorageAccountName + '.blob.core.windows.net').IPAddressToString
    
  3. Note the resulting string and, from the Network Watcher - Connection troubleshoot blade, initiate a check with the following settings:

    • Source:

      • Subscription: the name of the Azure subscription you are using in this lab

      • Resource group: az1010301b-RG

      • Source type: Virtual machine

      • Virtual machine: az1010301b-vm1

    • Destination: Specify manually

      • URI, FQDN or IPv4: the IP address of the blob service endpoint of the storage account you identified in the previous step of this task
    • Probe Settings:

      • Protocol: TCP

      • Destination port: 443

    • Advanced settings:

      • Source port: blank
  4. Wait until results of the connectivity check are returned and verify that the status is Reachable. Review the network path and note that the connection was direct, with no intermediate hops in between the VMs, with minimal latency.

    Note: The connection takes place over the service endpoint you created in the previous exercise. To verify this, you will use the Next hop tool of Network Watcher.

  5. From the Network Watcher - Connection troubleshoot blade, navigate to the Network Watcher - Next hop blade and test next hop with the following settings:

    • Subscription: the name of the Azure subscription you are using in this lab

    • Resource group: az1010301b-RG

    • Virtual machine: az1010301b-vm1

    • Network interface: az1010301b-nic1

    • Source IP address: 10.203.0.4

    • Destination IP address: the IP address of the blob service endpoint of the storage account you identified earlier in this task

  6. Verify that the result identifies the next hop type as VirtualNetworkServiceEndpoint

  7. From the Network Watcher - Connection troubleshoot blade, initiate a check with the following settings:

    • Source:

      • Subscription: the name of the Azure subscription you are using in this lab

      • Resource group: az1010302b-RG

      • Source type: Virtual machine

      • Virtual machine: az1010302b-vm2

    • Destination: Specify manually

      • URI, FQDN or IPv4: the IP address of the blob service endpoint of the storage account you identified earlier in this task
    • Probe Settings:

      • Protocol: TCP

      • Destination port: 443

    • Advanced settings:

      • Source port: blank
  8. Wait until results of the connectivity check are returned and verify that the status is Reachable.

    Note: The connection is successful, however it is established over Internet. To verify this, you will use again the Next hop tool of Network Watcher.

  9. From the Network Watcher - Connection troubleshoot blade, navigate to the Network Watcher - Next hop blade and test next hop with the following settings:

    • Subscription: the name of the Azure subscription you are using in this lab

    • Resource group: az1010302b-RG

    • Virtual machine: az1010302b-vm2

    • Network interface: az1010302b-nic1

    • Source IP address: 10.203.16.4

    • Destination IP address: the IP address of the blob service endpoint of the storage account you identified earlier in this task

  10. Verify that the result identifies the next hop type as Internet

Task 3: Test network connectivity to an Azure SQL Database by using Network Watcher

  1. From the Azure Portal, start a PowerShell session in the Cloud Shell.

  2. In the Cloud Shell pane, run the following command to identify the IP address of the Azure SQL Database server you provisioned in the previous exercise:

    [System.Net.Dns]::GetHostAddresses($(Get-AzSqlServer -ResourceGroupName 'az1010301b-RG')[0].FullyQualifiedDomainName).IPAddressToString
    
  3. Note the resulting string and, from the Network Watcher - Connection troubleshoot blade, initiate a check with the following settings:

    • Source:

      • Subscription: the name of the Azure subscription you are using in this lab

      • Resource group: az1010301b-RG

      • Source type: Virtual machine

      • Virtual machine: az1010301b-vm1

    • Destination: Specify manually

      • URI, FQDN or IPv4: the IP address of the Azure SQL Database server you identified in the previous step of this task
    • Probe Settings:

      • Protocol: TCP

      • Destination port: 1433

    • Advanced settings:

      • Source port: blank
  4. Wait until results of the connectivity check are returned and verify that the status is Reachable. Review the network path and note that the connection was direct, with no intermediate hops in between the VMs, with low latency.

    Note: The connection takes place over the service endpoint you created in the previous exercise. To verify this, you will use the Next hop tool of Network Watcher.

  5. From the Network Watcher - Connection troubleshoot blade, navigate to the Network Watcher - Next hop blade and test next hop with the following settings:

    • Subscription: the name of the Azure subscription you are using in this lab

    • Resource group: az1010301b-RG

    • Virtual machine: az1010301b-vm1

    • Network interface: az1010301b-nic1

    • Source IP address: 10.203.0.4

    • Destination IP address: the IP address of the Azure SQL Database server you identified earlier in this task

  6. Verify that the result identifies the next hop type as VirtualNetworkServiceEndpoint

  7. From the Network Watcher - Connection troubleshoot blade, initiate a check with the following settings:

    • Source:

      • Subscription: the name of the Azure subscription you are using in this lab

      • Resource group: az1010302b-RG

      • Source type: Virtual machine

      • Virtual machine: az1010302b-vm2

    • Destination: Specify manually

      • URI, FQDN or IPv4: the IP address of the Azure SQL Database server you identified earlier in this task
    • Probe Settings:

      • Protocol: TCP

      • Destination port: 1433

    • Advanced settings:

      • Source port: blank
  8. Wait until results of the connectivity check are returned and verify that the status is Reachable.

    Note: The connection is successful, however it is established over Internet. To verify this, you will use again the Next hop tool of Network Watcher.

  9. From the Network Watcher - Connection troubleshoot blade, navigate to the Network Watcher - Next hop blade and test next hop with the following settings:

    • Subscription: the name of the Azure subscription you are using in this lab

    • Resource group: az1010302b-RG

    • Virtual machine: az1010302b-vm2

    • Network interface: az1010302b-nic1

    • Source IP address: 10.203.16.4

    • Destination IP address: the IP address of the Azure SQL Database server you identified earlier in this task

  10. Verify that the result identifies the next hop type as Internet

Result: After you completed this exercise, you have used Azure Network Watcher to test network connectivity to an Azure VM via virtual network peering, network connectivity to Azure Storage, and network connectivity to Azure SQL Database.

Exercise 3: Remove lab resources

Task 1: Open Cloud Shell

  1. At the top of the portal, click the Cloud Shell icon to open the Cloud Shell pane.

  2. At the Cloud Shell interface, select Bash.

  3. At the Cloud Shell command prompt, type in the following command and press Enter to list all resource groups you created in this lab:

    az group list --query "[?starts_with(name,'az1010')].name" --output tsv
    
  4. Verify that the output contains only the resource groups you created in this lab. These groups will be deleted in the next task.

Task 2: Delete resource groups

  1. At the Cloud Shell command prompt, type in the following command and press Enter to delete the resource groups you created in this lab

    az group list --query "[?starts_with(name,'az1010')].name" --output tsv | xargs -L1 bash -c 'az group delete --name $0 --no-wait --yes'
    

    Note: The command command executes asynchronously (as determined by the –nowait parameter), so it might take a few minutes before all of the resource groups are removed.

    Note: You might have to rerun the command if the resources are not deleted after the first run.

  2. Close the Cloud Shell prompt at the bottom of the portal.

Result: In this exercise, you removed the resources used in this lab.