Azure Virtual Network Test

An Azure virtual network (VNet) is a representation of your own network in the Azure cloud. It is a logical isolation of the Azure cloud dedicated to your subscription. You can fully control the IP address blocks, DNS settings, security policies, and route tables within this network. You can also further segment your VNet into subnets and launch Azure IaaS virtual machines (VMs) and/or Cloud services (PaaS role instances). Additonally, you can connect the virtual network to your on-premises network using one of the connectivity options available in Azure. In essence, you can expand your network to Azure, with complete control on IP address blocks with the benefit of enterprise scale Azure provides. Following are the benefits of virtual networks in an environment:

• Isolation. VNets are completely isolated from one another. That allows you to create disjoint networks for development, testing, and production that use the same CIDR address blocks.
• Access to the public Internet. All IaaS VMs and PaaS role instances in a VNet can access the public Internet by default. You can control access by using Network Security Groups (NSGs).
• Access to VMs within the VNet. PaaS role instances and IaaS VMs can be launched in the same virtual network and they can connect to each other using private IP addresses even if they are in different subnets without the need to configure a gateway or use public IP addresses.
• Name resolution. Azure provides internal name resolution for IaaS VMs and PaaS role instances deployed in your VNet. You can also deploy your own DNS servers and configure the VNet to use them.
• Security. Traffic entering and exiting the virtual machines and PaaS role instances in a VNet can be controlled using Network Security groups.
• Connectivity. VNets can be connected to each other, and even to your on-premises datacenter, by using a site-to-site VPN connection, or ExpressRoute connection. To learn more about VPN gateways, visit About VPN gateways.

If the virtual networks experience a sudden slowdown or are rendered inaccessible, the virtual machines and cloud services associated with the virtual networks will not be accessible thus causing setback to the user experience. To avoid such setbacks, it is essential for the administrators to figure out the count and the status of the virtual networks in the target environment. The Azure Virtual Network test helps administrators in this regard!.

This test helps administrators to figure out the number of virtual networks available in the target Microsoft Azure cloud . The detailed diagnosis of the test will list the status of each virtual network in the cloud. This way, administrators can figure out the virtual networks that are currently down/inaccessible.

Target of the Test: Microsoft Azure

Agent deploying the test: A remote agent

Output of the test: One set ofresults for the target Microsoft Azure being monitored

TEST PERIOD - How often should the test be executed Host– The host for which the test is being configured SUBSCRIPTION ID- Specify the GUID which uniquely identifies your subscription to the target Microsoft Azure that is to be monitored. CERTIFICATE PATH - In order to collect metrics from the target Microsoft Azure, the eG agent communicates via Microsoft Azure Service Management API Requests. By default, a management certificate is required to authenticate Microsoft Azure Service Management API Requests. The Management certificate should be associated with the subscription ID. The management certificate can be created on your own or you can request Microsoft Azure portal to create a certificate on behalf of you. Prior to creating a management certificate, you have to create a keystore. The steps for creating a management certificate and the keystore is discussed elaborately in Section 1.1. The created keystore will reside in the <JAVA_INSTALL_DIR>\jre7\bin folder. Specify the exact path to the keystore file in this text box. If you have requested Microsoft Azure portal to create the management certificate, then, specify the exact path on which you have stored the keystore file. For example, if the keystore file created is WindowsAzureKeyStore.jks and if you have stored it in D:\Azure folder, then specify the CERTIFICATE PATH as D:\Azure\WindowsAzureKeyStore.jks. CERTIFICATE PASSWORD - Specify the password that is provided while creating the keystore in this text box. confirm password - Confirm the password by retyping it here. dd frequency - Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency. detailed diagnosis - To make diagnosis more efficient and accurate, the eG system embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option against DETAILED DIAGNOSIS. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability. Both the bad and normal frequencies configured for the detailed diagnosis measures should not be 0.

Measures reported by the test:

Measurement	Description	Measurement Unit	Interpretation
Virtual network:	Indicates the number of virtual networks that were configured for the subscription.	Number	The detailed diagnosis of this measure if enabled, lists the Name, Status, Location, Subnet name, Subnet address space, Address prefix and ID.