Azure – Networking – Part 17 – VNet Peering 2 – Hub-spoke VNet topology


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 🙂

If you have missed our previous articles on azure networking, please check it 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.

Figure 1 Azure Networking – VNet Peering – Hub-Spoke use case

prerequisite :

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

  • HUB VNetMSTechs_HUB_VNet
  • SPOKE VNet 1KJ_VNet
  • SPOKE VNet 1AccountPack_VNet
  • VM 1AccountPack_VM
  • VM 2KJ_VM
  • VM 3HUB VM
  • Virtual Network Gateway with HUBMSTechs_HUB_VNet_Gateway
Figure 2 Azure Networking – VNet Peering – Hub and Spoke Vnets
Figure 3 Azure Networking – VNet Peering – VMs in different VNet

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.
Figure 4 – Azure Networking – VNet Peering between MSTechs_VNet with KJ_VNet

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

Figure 5 – Azure Networking – VNet Peering between MSTechs_VNet with AccountPack_VNet

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.

Figure 6 – Azure Networking – VNet Peering – Created peering from 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.

Figure 7 – Azure Networking – VNet Peering – Peering status is Connected

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.

Figure 8 – Azure Networking – VNet Peering – Create Route Table
Figure 9 – Azure Networking – VNet Peering – Create Route Table for KJ Network

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

Figure 10- Azure Networking – VNet Peering – Create Route Table for Account Pack Network
Figure 11 – Azure Networking – VNet Peering – Created Route Table

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

Figure 12 – Azure Networking – VNet Peering – KJ Route table Route configuration
Figure 13 – Azure Networking – VNet Peering – Account Pack route table Route configuration

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.

Figure 14 – Azure Networking – KJ_VNet Subnets
Figure 15 – Azure Networking – KJ route table associated

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

Figure 16 – Azure Networking – Account Pack route table associated

Testing Peering connectivity :

Figure 17 – Azure Networking – Test VM

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  🙂

One thought on “Azure – Networking – Part 17 – VNet Peering 2 – Hub-spoke VNet topology

  1. It was wonderful article, i’d like to know one thing. IN figure 12 you have maentioned next hop address of Virtual Network Gateway (10.0.1.4) while what i understood Virtual Network Gateway subnet CIDR range is 10.0.0.0. The same applies to figure 13

    Kindly advise.

This site uses Akismet to reduce spam. Learn how your comment data is processed.