Hands-On Networking with Azure

This chapter introduces Azure Virtual Networks, differences between the Azure Service Management and Azure Resource Manager models, and some key points that will help you to design your solution. We will also cover Azure Virtual Network subnet types and in which scenarios these subnets would be used. Finally, you will learn how to automate all the manual tasks that have been implemented throughout the chapter.

To go through the book smoothly, you need to have the following:

One of the major facts in our life is networking. In the beginning, human beings used to make networks communicate with each other to fulfill their needs. That's why when the computer revolution took place, networks were a very important piece of the puzzle to let computers communicate with each other.

Through the whole of the IT revolution, networks used to be an indispensable part of every IT environment to have a properly functioning environment. It is no surprise that networking is a vital part of cloud from many aspects, starting from the remote connection to your Azure VMs, to spanning your environment across on-premises and Azure. You will notice that networks are used with almost all Azure services, this includes, but is not limited to Azure VMs, Azure SQL Databases, Azure Web Apps, and so on.

At the time of writing, Microsoft Azure is generally available in 36 regions, with plans announced for six additional regions, as shown in the following table:

This global presence means you can build your networks in the nearest region, and access them from anywhere in the world, considering that Microsoft keeps building new data centers in new regions, so latency between your on-premises environment and Azure is decreased.

Due to an overlap of terms and some misperceptions about the ways that Azure services are delivered, terminology is a sticking point even for people who have been working with the technology for some time. The following table provides accurate, but short definitions for the terms related to Azure services. These definitions will be expanded upon in detail throughout the book, so don't worry if you are confused at first:

Previously, Azure used to provide its services via two portals, but recently, Microsoft discontinued the ASM (Classic) portal. However, if you have any services that were running in the classic portal you do not have to worry about them because they have been migrated to Azure ARM portal. Considering that these services would follow the old ASM model. Also, you will note that in the new Azure portal there are two flavors for them. For example, there will be Virtual Machines, and Virtual Machines (Classic).

Historically, Azure services were provided via one portal before 2014, the classic portal, which can be accessed via the following link https://manage.windowsazure.com/. As of now, this portal will redirect to the ARM portal.

The model that was used for that portal is called the ASM model, within which each resource existed independently. You could not manage your resources together, you had to build up and track each resource. For example, you will have to manage the networks from the NETWORKS blade, and the same goes for the storage, virtual machines, and so on. So, when your environment gets bigger, there will be chaos in the management scheme. You will have to know which Azure Virtual Machines are using which virtual networks to do its communications, and that might lead to some critical situations, such as reaching the limits of the allowed number of public IPs, and whenever you need to add a new public IP to be used for a VM in your environment, you would not be able to do so because of the poor management of resources. This would not be your only concern while working with the ASM model. If you want to delete a solution with multiple resources, you will have to do it with each resource manually, and so on.

This is how the classic portal looked:

 Figure 1.1: Azure Classic portal

Azure portal (ARM model)

In 2014, Microsoft launched a new portal that follows a new model, called the ARM model, which can be accessed via the following link https://portal.azure.com/.

When you open the Azure portal, it will look as follows:

Figure 1.2: Azure portal

This model depends on the concept of resource groups, which means you can group all your resources within a container, resulting in resources being deployed in parallel. As a result, you will not face the same problems as you did with the ASM model.

The following diagram describes the deployed resources through the ARM model:

Figure 1.3: Resource manager management model at a high level

Here are the benefits you will gain using that portal:

• Ability to manage your resources as a group instead of managing them separately.
• Using Role-Based Access Control (RBAC) to control access to resources, so that you can assign permissions to a user on a resource or some resources, but not to other resources (as it was in the classic portal).
• Using tags to organize and classify your resources, which can help you with billing. For example, you might want to monitor the billing of some resources that make up a solution, for example, a web server. By assigning a tag to the resources that make up that solution, you would be able to monitor its billing, and so on.
• Support the usability of JSON to deploy resources instead of using the portal:
  • Deploy resources in parallel instead of deploying them sequentially, and waiting until every resource deployment finishes to deploy another one.
  • Specify dependencies during the resources deployment. For example, a VM will not be created until a storage account and a virtual network get deployed, because the VM VHD would need a place to be stored in and an IP address from a virtual network.
  • Reuse of the JSON template to deploy solutions with the same specifications.

ARM key points

For a better understanding of the ARM model, you might need to consider the following key points:

• Resources with the same lifecycle should be gathered in the same resource group
• Resources in different regions can be in the same resource group
• Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group and then add it to the new resource group
• Resource groups support RBAC, wherein a user can have access to some specific resources, and have no access to the others
• Some resources can be shared across resource groups such as storage accounts
• ARM virtual machines can only be placed in ARM storage accounts
• You cannot create a virtual machine using the ARM model and assign it to a virtual network built using the ASM model
• You cannot use a prebuilt image that was created by ASM APIs to build a VM using the ARM model, but as a workaround you can copy the VHD files from the storage account in the classic portal to a storage account created in the ARM model
• You can migrate assets from the ASM model to the ARM model
• Every resource must be assigned to a resource group, so whenever you want to move a resource between resource groups you must remove it from its current resource group, and then add it to the new resource group

Note

You can change the background of the portal by double-clicking on any unused area of the dashboard. You can navigate between four colors (blue, dark blue, white, and black). For further information about the difference between the ARM and ASM models, check out the following article: https://blogs.technet.microsoft.com/meamcs/2016/12/22/difference-between-azure-service-manager-and-azure-resource-manager/.

As you have a network in your on-premises (private data center) to facilitate the communication between your machines/devices and even to secure and isolate machines/devices from each other, you will need to do the same tasks in the cloud. That is why Microsoft offers Azure VNet.

Azure VNet is one of the most commonly used Microsoft Azure Networking services. Azure VNet is sort of like a LAN within which you can have address spaces that can be divided into multiple subnets. Considering that, only private IPs ranges can be used for the address spaces and their subnets.

Creating Azure VNet

Creating an Azure VNet is a pretty straightforward process. To do this task, follow these steps:

1. Open the ARM portal and log in using the account associated with your Azure subscription.

2. Once logged in, navigate to More services, and search for virtual network, as shown in the following screenshot:

Figure 1.4: Searching for virtual networks blade

3. You will be navigated to a new blade, wherein you can display the virtual networks you have created, and you can also create new virtual networks, as shown in the following screenshot:

Figure 1.5: Virtual networks blade

4. Click on Add, and a new blade will be opened for which you have to fill the following fields:
   • Name: The name of the virtual network.
   • Address space: The virtual network's address range in CIDR notion.
   • Subscription: If you have multiple subscriptions associated to the account you have logged in with, you have to specify which subscription will be charged for this service.
   • Resource group: Specify whether you want to create a new resource group for the resource you are creating, or use an existing one.
   • Location: The region on which this virtual network will operate.
   • Subnet-name: The name of the first subnet in the virtual network you are creating.
   • Subnet | Address range: The subnet's address range in CIDR notion. It must be contained by the address space of the virtual network.
   • Service endpoints (Preview): It can be used in securing your traffic between some Azure services in Microsoft's backbone network. More information about it will be covered in Chapter 2, Delving into Azure Virtual Networks:

Figure 1.6: Creating a virtual network

5. Click on Create, and within a moment the virtual network will be created.

Adding address spaces to the virtual network

You can add other address spaces to the virtual network, and later those address spaces can be divided into subnets. To add another address space, follow these steps:

1. Navigate to the Virtual networks blade, and you will find that the virtual network you have created is already there, as shown in the following screenshot:

Figure 1.7: Displaying the created virtual networks

2. Click on the virtual network, and a new blade will pop up, as shown in the following screenshot:

Figure 1.8: PP-Virtual Network overview

3. Then, you will navigate to Address space, wherein you will find all the address spaces of this virtual network, as shown in the following screenshot:

Figure 1.9: Address spaces of the virtual network

4. To add a new address space, you only need to hover over Add additional address range, and add the address space you would need, then click on Save, as shown in the following screenshot:

Figure 1.10: Adding new address space

5. Once you save the changes, the address space will be a part of the virtual network.

Adding subnets to the virtual network

There are two types of subnets in Azure VNet:

• Subnet: The normal form of subnets, which is the result of dividing the virtual network
• Gateway subnet: The subnet that acts as a gateway for communication with other networks

By default, you must specify at least one subnet while creating the virtual network, as discussed earlier. However, later you might need to have other subnets, and to do so, you have to follow these steps:

1. Navigate to the virtual network that you have created earlier and then go to SETTINGS | Subnets, as shown in the following screenshot:

Figure 1.11: Virtual Network Subnets

2. Click on Subnets, and a new blade will be opened, where you need to specify the following:
   • Name: The name of the subnet.
   • Address range (CIDR block): The subnet's address range in CIDR notation (considering that it must be contained by the address space of the virtual network).
   • Network security group: This works like a firewall to filter what traffic that be allowed to flow in/out of the network. More information about this topic will be covered in Chapter 2, Delving into Azure Virtual Networks.
   • Route table: You can expand the communication between multiple VNets by setting a route table. More information about this topic will be covered in Chapter 4, Network Connectivity Scenarios in Azure.
   • Service endpoints (Preview): As mentioned earlier, this can be used to let some Azure services communicate in Microsoft's backbone network. More information about it will be covered in Chapter 2, Delving into Azure Virtual Networks.

Figure 1.12: Adding subnets

3. Once you click on OK, the subnet will be added within a moment.

Note

When specifying the subnet's address range, you must have noted that there are five reserved IPs. The first and the last IPs are reserved for protocol conformance known as network and broadcast in addition to three more IPs used for Azure services.

Creating the gateway subnet is no different than the normal subnet creation, except you cannot set the name of the gateway subnet, as shown in the following screenshot:

Figure 1.13: Adding gateway subnet

Note

Every virtual network can only have one gateway subnet.

It is no surprise that we commonly face repetitive and time-consuming tasks. For example, you might want to create multiple storage accounts. You would have to follow the previous guide multiple times to get your job done. This is why Microsoft supports its Azure services with multiple ways of automating most of the tasks that can be implemented in Azure. Throughout this book, two of the automation methods that Azure supports will be used.

Azure PowerShell

PowerShell is commonly used with most Microsoft products, and Azure is not less important than any of these products.

Mainly, you can use Azure PowerShell cmdlets to manage Azure Networking tasks, however, you should be aware that Microsoft Azure has two types of cmdlets, one for the ASM model, and another for the ARM model, which we will be using throughout this book.

The main difference between cmdlets of the ASM model and the ARM model is, there will be an RM added to the cmdlet of the current portal.

For example, if you want to create an ASM virtual network, you would use the following cmdlet:

New-AzureVirtualNetwork

But for the ARM model, you would use the following:

New-AzureRMVirtualNetwork

Note

Most of the time this would be the case. But a few Cmdlets are totally different and some others don't even exist in the ASM model and do exist in the ARM model.

By default, you can use Azure PowerShell cmdlets in Windows PowerShell, but you will have to install its module first.

Installing the Azure PowerShell module

There are two ways of installing the Azure PowerShell module on Windows:

• Download and install the module from the following link: https://www.microsoft.com/web/downloads/platform.aspx
• Install the module from PowerShell Gallery

Installing the Azure PowerShell module from PowerShell Gallery

The following are the required steps to get Azure PowerShell installed:

1. Open PowerShell in an elevated mode.
2. To install the Azure PowerShell module for the current portal run the following cmdlet Install-Module AzureRM. If your PowerShell requires a NuGet provider you will be asked to agree to install it, and you will have to agree for the installation policy modification, as the repository is not available on your environment, as shown in the following screenshot:

Figure 1.14 Installing the AzureRM PowerShell module

Creating a virtual network in Azure portal using PowerShell

To be able to run your PowerShell cmdlets against Azure successfully, you need to log in first to Azure using the following cmdlet:

Login-AzureRMAccount

Then, you will be prompted to enter the credentials of your Azure account. Voila! You are logged in and you can run Azure PowerShell cmdlets successfully.

To create an Azure VNet, you first need to create the subnets that will be attached to this virtual network. Therefore, let's get started by creating the subnets:

$NSubnet = New-AzureRMVirtualNetworkSubnetConfig –Name NSubnet -AddressPrefix 192.168.1.0/24
$GWSubnet = New-AzureRMVirtualNetworkSubnetConfig –Name GatewaySubnet -AddressPrefix 192.168.2.0/27

Now you are ready to create a virtual network by triggering the following cmdlet:

New-AzureRMVirtualNetwork -ResourceGroupName PacktPub -Location WestEurope -Name PSVNet -AddressPrefix 192.168.0.0/16 -Subnet $NSubnet,$GWSubnet

Congratulations! You have your virtual network up and running with two subnets associated to it, one of them is a gateway subnet.

Adding address space to a virtual network using PowerShell

To add an address space to a virtual network, you need retrieve the virtual network first and store it in a variable by running the following cmdlet:

$VNet = Get-AzureRMVirtualNetwork -ResourceGroupName PacktPub -Name PSVNet

Then, you can add the address space by running the following cmdlet:

$VNet.AddressSpace.AddressPrefixes.Add("10.1.0.0/16")

Finally, you need to save the changes you have made by running the following cmdlet:

Set-AzureRmVirtualNetwork -VirtualNetwork $VNet

Azure CLI

Azure CLI is an open source, cross platform that supports implementing all the tasks you can do in Azure portal, with commands.

Azure CLI comes in two flavors:

• Azure CLI 2.0: Which supports only the current Azure portal
• Azure CLI 1.0: Which supports both portals

Throughout this book, we will be using Azure CLI 2.0, so let's get started with its installation.

Installing Azure CLI 2.0

Perform the following steps to install Azure CLI 2.0:

1. Download Azure CLI 2.0, from the following link: https://azurecliprod.blob.core.windows.net/msi/azure-cli-2.0.22.msi

2. Once downloaded, you can start the installation:

Figure 1.15: Installing Azure CLI 2.0

3. Once you click on Install, it will start to validate your environment to check whether it is compatible with it or not, then it starts the installation:

Figure 1.16: Installing Azure CLI 2.0

4. Once the installation completes, you can click on Finish, and you are good to go:

Figure 1.17: Installing Azure CLI 2.0

5. Once done, you can open cmd, and write az to access Azure CLI commands:

Figure 1.18: Opening the Azure CLI using CMD

Creating a virtual network using Azure CLI 2.0

To create a virtual network using Azure CLI 2.0, you have to follow these steps:

1. Log in to your Azure account using the following command az login, you have to open the URL that pops up on the CLI, and then enter the following code:

Figure 1.19: Logging in to Azure via Azure CLI 2.0

2. To create a new virtual network, you need to run the following command:

az network vnet create --name CLIVNet --resource-group PacktPub --location westeurope --address-prefix 192.168.0.0/16 --subnet-name s1 --subnet-prefix 192.168.1.0/24

Adding a gateway subnet to a virtual network using Azure CLI 2.0

To add a gateway subnet to a virtual network, you need to run the following command:

az network vnet subnet create --address-prefix 192.168.7.0/27 --name GatewaySubnet --resource-group PacktPub --vnet-name CLIVNet

Adding an address space to a virtual network using Azure CLI 2.0

To add an address space to a virtual network, you can run the following command:

az network vnet update address-prefixes –add <Add JSON String>

Remember that you will need to add a JSON string that describes the address space.

So far, we have covered some preliminary subject matters regarding Azure generally, and Azure Networking specifically. Some things were not covered in detail, but detailed discussions will be raised in the coming chapters.

In the upcoming chapters, Azure networks architecture and more Azure networking services will be covered in detail. Therefore, the knowledge gained in this chapter is required for a better understanding of the coming chapters.

For more information about virtual networks, you can check out the following link: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview.