Hello Friends,

!!! Merry Christmas and WISH YOU HAPPY NEW YEAR to all of you and your family!!! 🙂

Today let’s continue with our last article on ” VNet Peering ” and will see how to configure Hub – Spoke topology. In this article we will go through step by step to configure Hub – Spoke VNet peering. So Let’s Start 🙂

Tool Installation Articles :

1. Configure Azure Command Line Interface ( Azure CLI) On Windows
2. Configure PowerShell For Microsoft Azure Az Module On Windows

Previous Azure Series :

1. Learn Basics Of Azure Networking In 100 Hours
2. Learn Basics Of Microsoft Azure Storage services
3. Learn Basic Of Azure Active Directory And Azure Identity And Access Management
4. Azure DevOps – Learn at one place
5. Learn Basics Of Lift-And-Shift Migration To Azure

If you have missed our previous articles on networking, please check them in following links.

Part 10 – Issue when Configure DNS Records In Azure DNS

Part 11 – ExpressRoute

Part 12 – Azure VPN Network Gateway

Part 13 – Configure Azure Point-to-Site VPN

Part 14 – Configure Azure VNet-to-VNet Connection

Part 15 – Configure Azure Site-to-Site VPN Connection

Part 16 – Azure Virtual Network (VNet) peering

Next Article : Part 18 – Azure Traffic Manager 1

Hub – Spoke Topology Use Case :

In this use case we will implement a Hub-Spoke virtual network topology which will enabled the HUB VNet to communicate with its SPOKE VNet networks via VNet Peering. Also it required the SPOKE networks to be able to communicate with each other but peering between them is not allowed.

prerequisite :

To configure the above Hub-Spoke topology, we need some resources in advance. Followings are the required resources.

• HUB VNet — MSTechs_HUB_VNet
• SPOKE VNet 1 — KJ_VNet
• SPOKE VNet 2 — AccountPack_VNet
• VM 1 – AccountPack_VM
• VM 2 — KJ_VM
• VM 3 —HUB VM
• Virtual Network Gateway with HUB — MSTechs_HUB_VNet_Gateway

As we can see, we have created 3 Virtual Networks (VNet) for our use case. We have created the above resource in before hand. One important point to note is all VNet must created with non-overlapping IP addresses .

VNet peering is Non-Transitive – which means, in our use-case in the above figure, even SPOKE 1 (KJ_VNet) is peered with the HUB network and the HUB ( MSTechs_HUB_VNet ) is peered with SPOKE 2 ( AccountPack_VNet ), this does not enable automatic communication between SPOKE 1 ( KJ_VNet ) and SPOKE 2 ( AccountPack_VNet ) unless they are exclusively peered which in our requirement we were not allowed to do. There are several ways to implement Spoke to Spoke communication .

So, let’s explore, how we can enable communication between the Spokes networks without peering by configuring a Virtual Network Gateway to the HUB (MSTechs_VNet)network.

Configuration :

1. Login to Azure portal and create 3 Virtual Networks ( 1 VNet for HUB and 2 for SPOKE )with non-overlapping IP addresses if not created yet.
2. We are ready with our 3 Virtual Networks . Now configure Virtual Network Gateway with HUB VNet ( MSTechs_VNet)
3. The next step is to start peering them from HUB to each SPOKE and from each SPOKE to HUB. So let’s start Peering 🙂 .
4. Navigate to the Hub VNet ( MSTechs_HUB_VNet ) and go to Peering page. Add a new peering with Spoke 1 VNet ( KJ_VNet) as shown in the following image. Allow gateway transit option from HUB.

5. Repeat the above step to create a peering with SPOKE 2 (AccountPack_Vnet) as well as shown in the following figure.

6. Initially To establish a successful connection, we required to create a peering to the HUB Virtual Network from each of the SPOKE Networks. But now azure automatically creating those peering along with the first peering. As we can see in the following figure Azure creates two more peering from each SPOKE to HUB.

7. Verify that, the peering status of all peerings are connected and Gateway transit is enable from Hub to Spoke peering but disable from spoke to Hub peering as shown in the following figure.

8. We will now create the 2 Route Tables and define user routes needed for the SPOKE to SPOKE communication as shown in the following figures.

9. Repeat the above step to create another route table as AccountPack_RouteTable , as shown in the following figure.

10. So far so good. Now time comes to define user routes for both route tables as in the following figures.

11. The next is to associate these Route tables with our Virtual Networks .So let’s navigate to the KJ_VNet and select the  Subnet_1 subnet . In the Route table field select, KJ_RouteTable and click Save as shown in the following figures.

12. Repeat the above step to associate AccountPack_RouteTable as shown in the following figure.

Testing Peering connectivity :

So far so good. I can see this article became a big one so from now, I will try to avoid screen shots . we are ready with our all configurations. Now it is time to test our connectivity between both Spokes network via Hub network.

We have provisioned a virtual machine in each of the Spoke network (KJ-VM and AccountPack-VM) as shown in the above figure. To start our testing, Let’s follow the below steps.

1. In the Remote Desktop of KJ-VM, open PowerShell and enter ping AccountPack-VM . Then we will receive Time out message . The ping fails, because ping uses the Internet Control Message Protocol (ICMP). By default, ICMP isn’t allowed through the Windows firewall.
2. To allow ICMP inbound through window firewall, run the below command from both VMs. New-NetFirewallRule –DisplayName “Allow ICMPv4-In” –Protocol ICMPv4 .
3. From command prompt of KJ-VM, ping AccountPack-VM. We will receive message like, Reply from 10.2.0.4: bytes=32 time<1ms TTL=128
4. Same way we can test the KJ-VM connectivity from AccountPack-VM.

Hope this article helps you 🙂 . My next article of this series is Part 18 – Azure Traffic Manager 1 .

Keep reading, share your thoughts, experiences. Feel free to contact us to discuss more.

If you have any suggestion / feedback / doubt, you are most welcome. Stay tuned on Knowledge-Junction, will come up with more such articles

Thanks for reading  🙂