Hands-On Networking with Azure

By Mohamed Waly
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Free Chapter
    Azure Virtual Networks 101
About this book

Microsoft Azure networking is one of the most valuable and important offerings in Azure. No matter what solution you are building for the cloud, you'll find a compelling use for it. This book will get you up to speed quickly on Microsoft Azure Networking by teaching you how to use different networking services.

By reading this book, you will develop a strong networking foundation for Azure virtual machines and for expanding your on-premise environment to Azure.

Hands-On Networking with Azure starts with an introduction to Microsoft Azure networking and creating Azure Virtual Networks with subnets of different types within them. The book helps you understand the architecture of Azure networks. You will then learn the best practices for designing both Windows- and Linux-based Azure VM networks. You will also learn to expand your networks into Azure and how to use Azure DNS. Moreover, you will master best practices for dealing with Azure Load Balancer and the solutions they offer in different scenarios. Finally, we will demonstrate how the Azure Application Gateway works, offering various layer-7 load balancing capabilities for applications.

By the end of this book, you will be able to architect your networking solutions for Azure.

Publication date:
March 2018
Publisher
Packt
Pages
276
ISBN
9781788998222

 

Chapter 1. Azure Virtual Networks 101

 

Introduction


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.

Learning outcomes

The following topics will be covered:

  • Introduction to Microsoft Azure Networks
  • Azure terminologies
  • Azure Service Management (ASM) versus the Azure Resource Manager (ARM) model
  • Azure Virtual Network (VNet)
  • Automating your tasks
 

Technical requirements


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

 

Introduction to Microsoft Azure Networks


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:

Region

Status

Location

East US

Generally available

Virginia

East US 2

Generally available

Virginia

Central US

Generally available

Iowa

North Central US

Generally available

Illinois

South Central US

Generally available

Texas

West Central US

Generally available

West Central US

West US

Generally available

California

West US 2

Generally available

West US 2

US Gov Virginia

Generally available

Virginia

US Gov Iowa

Generally available

Iowa

US DoD East

Generally available

Virginia

US DoD Central

Generally available

Iowa

US Gov Arizona

Generally available

Arizona

US Gov Texas

Generally available

Texas

Canada East

Generally available

Quebec City

Canada Central

Generally available

Toronto

Brazil South

Generally available

Sao Paulo State

North Europe

Generally available

Ireland

West Europe

Generally available

Netherlands

UK West

Generally available

Cardiff

UK South

Generally available

London

Germany Central

Generally available

Frankfurt

Germany Northeast

Generally available

Magdeburg

France Central

Coming soon

Paris

France South

Coming soon

Marseille

Southeast Asia

Generally available

Singapore

East Asia

Generally available

Hong Kong

Australia East

Generally available

New South Wales

Australia Southeast

Generally available

Victoria

China East

Generally available

Shanghai

China North

Generally available

Beijing

Central India

Generally available

Pune

West India

Generally available

Mumbai

South India

Generally available

Chennai

Japan East

Generally available

Tokyo, Saitama

Japan West

Generally available

Osaka

Korea Central

Generally available

Seoul

Korea South

Generally available

Busan

Australia Central 1

Coming soon

Canberra

Australia Central 2

Coming soon

Canberra

South Africa West

Coming soon

Cape Town

South Africa North

Coming soon

Johannesburg

 

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.

Note

You can find out the nearest region to you with the lowest latency via the following website http://www.azurespeed.com/. Azure services are available in 140 countries around the globe and support 17 languages, and 24 currencies.

 

Azure terminologies


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:

Term

Definition

On-premises

Means that your data center is hosted and managed at a location your company manages.

Off-premises

Means that your data center is hosted and managed in a remote place (for example, hosted and managed outside your company).

Azure Virtual Machine

The feature of providing VMs to Azure subscribers.

Blade

The window that pops up when you click on one of the Azure services in the Azure portal, such as virtual machines.

Journey

A set of blades or chain of selections. For instance, when you select VMs inside the Azure portal, click on an existing VM and then select its settings.

Resource group

Provides a logical container for Azure resources (to help manage resources that are often used together).

Virtual network

Allows VMs and services that are part of the same virtual network to access each other. However, services outside the virtual network have no way of connecting to services hosted within virtual networks unless you decide to do so.

Fault domain

A group of resources that could fail at the same time. For example, they are all running on a single rack, sharing the same power source and physical network switch.

Upgrade/update domain

A group of resources that can be updated simultaneously during

system upgrades.

Network security group (NSG)

Determines the protocols, ports, and who and what can access Azure VMs remotely.

 

ASM versus ARM model


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/.

 

Azure VNet


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.

Note

The subnets within each address space are automatically routed. The address range of a subnet that is in use cannot be edited.

Azure VNet benefits

Azure VNet has many benefits and capabilities. The following benefits are some of them:

  • Isolation: Each virtual network is isolated from other virtual networks. Therefore, you can have your dev/test environment in a virtual network separated from the production environment that exits in other virtual networks.
  • Communicating with other VNets: By default, virtual networks are isolated from each other. However, you can reach out resources in another virtual network, because virtual networks can be connected to each other.
  • Broad network access: By default, all Azure services have access to the internet, which means you can access Azure services from wherever you want, using whatever you want, as long you have an internet connection.
  • Hybrid connectivity: Azure VNet can be spanned to your data center. As a result, you will be able to connect to both your Azure resources and on-premises resources privately without the need to connect via the internet.
  • Security: You can secure your virtual networks by setting rules that determine which inbound and outbound traffic can be flowed to and outside the virtual network.

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.
  1. 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

  1. 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

  1. 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 2Delving into Azure Virtual Networks:

Figure 1.6: Creating a virtual network

  1. 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

  1. 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

  1. 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

  1. 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

  1. 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

  1. 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

  1. 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.

Azure VNet key points

While building your virtual network, you might need to consider the following points:

  • You cannot add the following address spaces to your virtual network:
    • 224.0.0.0/4 (multicast)
    • 255.255.255.255/32 (broadcast)
    • 127.0.0.0/8 (loopback)
    • 169.254.0.0/16 (link-local)
    • 168.63.129.16/32 (internal DNS)
  • You cannot connect virtual networks that have overlapped address spaces
  • As a default limit, you can create 50 virtual networks per region per subscription, but it can be increased up to 1,000 virtual networks if you contact support
  • As a default limit, you can create 1,000 subnets per virtual network, but it can be increased up to 10,000 subnets, if you contact support
  • As a default limit, you can have 4,096 private IPs per virtual network, but it can be increased up to 8,192 if you contact support
 

Automating your tasks


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:

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
  1. Once downloaded, you can start the installation:

Figure 1.15: Installing Azure CLI 2.0

  1. 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

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

Figure 1.17: Installing Azure CLI 2.0

  1. 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

  1. 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.

 

Summary


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.

 

Questions


  • Microsoft has data centers all over the globe in all continents (true/false)
  • You can assign a single Azure resource to multiple resource groups (true/false)
  • State three benefits of using the ARM model instead of the ASM model
  • State the tools that can be used to automate Azure tasks
  • What is the difference between address space and a subnet in terms of Azure networking?
  • What is the difference between a subnet and gateway subnet in terms of Azure networking?
  • Can you use 168.63.129.16/32 as an address space? Why/why not?
 

Further reading


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.

About the Author
  • Mohamed Waly

    Mohamed Waly has been interested in IT since he was a student. He has gained many certificates in the IT field. In July 2014, he was recognized as the youngest MVP in the world. He is an author, speaker, and a blogger. He has contributed to Azure communities in Egypt, such as Azure Community in Egypt and Open Source on Azure. Waly is working currently as an Infrastructure Consultant for Blue Cloud Technologies, designing and implementing solutions for customers across MEA.

    Browse publications by this author
Latest Reviews (4 reviews total)
This is a clear and concise manual , good for getting started in the subject matter.
A very efficient and affordable way to buy e-books!
Good summary about all the network services. Would like to see more details and recommendations though
Hands-On Networking with Azure
Unlock this book and the full library FREE for 7 days
Start now