Azure Networking with Hub & Spoke Architecture

07 April 2020 Admin Cloud, Azure, Networking

This post covers the basic about the Hub and Spoke network architecture and then, shows a practical sample of implementation by using a Transitive Peer-to-Peer topology. Basic knowledge on Azure Networking is needed to understand and follow it completely. 

Hub and Spoke Architecture

This architecture pattern usually contains a central Hub virtual network connected to an on-premises network, via either a VPN gateway or an ExpressRoute circuit. Additional Spoke virtual networks are connected to the Hub virtual network via peering connections but not directly to each other. All in all, the Hub network provides inter-connectivity among the Spokes network.

Peer to Peer Transitive Routing Definition

Peer-to-peer transitive routing describes network traffic between two virtual networks (Spokes) that is routed through an intermediate virtual network (Hub). For example, let's say we have three virtual networks such as  SpokeA, Hub and SpokeB. SpokeA is peered to Hub, Hub is peered to SpokeB, but SpokeA and SpokeB are not connected. For network traffic to get from SpokeA to SpokeB and vice versa, it would have to travel through Hub network. This action is transitive routing and it will be what I am describing in this post. The other part, namely, the connection to on-premises networks via VPN gateway or ExpressRoute will be likely covered in a second part.

Peer to Peer Transitive Routing Sample

Let's start with the basic sample already mentioned in the previous section:

SpokeA VNet <-> Peering <-> Hub VNet <-> Peering <-> SpokeB VNet

Peering relationships are established between the Hub virtual network and both the SpokeA and SpokeB virtual networks. There is no direct peering relationship between SpokeA and SpokeB. However, we want SpokeA and SpokeB virtual networks be able to communicate to each other.

So, here are the three different virtual networks along with main settings and resources included on them as I have configured in my sample:

  • Hub Virtual Network
    • Address Space: 10.4.0.0/16
    • Subnets: default (10.4.0.0/24)
    • Network Virtual Appliance: Windows 2016 Server Virtual Machine called jm-NVA with ICMP enabled in firewall for testing purposes and IP Forwarding enabled at operating system level.
    • Here is the whole diagram for more clarification:

Hub Network

  • Spoke A Virtual Network
    • Address Space: 10.0.0.0/16
    • Subnets: default (10.0.0.0/24)
    • Windows 2016 Server Virtual Machine called SpokeA-vm with ICMP enabled in firewall for testing purposes.
    • Here is the whole diagram for more clarification:

Spoke A Virtual Network

  • Spoke B Virtual Network
    • Address Space: 10.1.0.0/16
    • Subnets: default (10.1.0.0/24)
    • Windows 2016 Server Virtual Machine called SpokeB-vm with ICMP enabled in firewall for testing purposes.
    • Here is the whole diagram for more clarification:

 Spoke B Virtual Network

Peering Settings

Each peering relationship is made up of two peering connections, one for traffic from the Hub to the Spoke (A or B), and the other one for traffic from the Spoke (A or B) to the Hub. 

  • This is the configuration for peering relationship for Hub <-> Spoke A: 
    • Allow forwarded traffic from Hub to Spoke A. It means traffic not generated in Hub Network (set from Spoke B in this sample) to be allowed to flow to Spoke A Network.
    • Allow virtual network access from Hub to Spoke A. To allow communication between the two virtual networks, from Hub to Spoke A.
    • Allow virtual network access from Spoke A to Hub. To allow communication between the two virtual networks, from Spoke A to Hub.

  • This is the configuration for peering relationship for Hub <-> Spoke B: 
    • Allow forwarded traffic from Hub to Spoke B. It means traffic not generated in Hub Network (set from Spoke B in this sample) to be allowed to flow to Spoke B Network.
    • Allow virtual network access from Hub to Spoke B. To allow communication between the two virtual networks, from Hub to Spoke B.
    • Allow virtual network access from Spoke B to Hub. To allow communication between the two virtual networks, from Spoke B to Hub.

Network Virtual Appliance Settings

  • Turn on IP Forwarding (Enabled state) within the Network Interface Card (NIC) associated to the Network Virtual Appliance (NVA).

Turn on IP Forwarding on NIC for NVA

  • Turn on IP Forwarding within Network Virtual Appliance (NVA) at operating system level. 
    • Open a Remote Desktop Connection to NVA.
    • Run the following command from PowerShell:

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name IpEnableRouter -Value 1

  • Enable ICMP in Firewall for test connectivity using ping. We will use this protocol only to test as it is just recommended for development environments. Run the following command from PowerShell: 

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

  • Restart your NVA Virtual Machine for changes to take effect. In any case, you should see something like this:

Route Tables Settings

  • Configure Routing for Spoke A:
    • Create a Routing Table
    • Create a routing rule that routes all the traffic covered by the IP address space of Spoke B to the Network Virtual Appliance IP address. See picture below.
      • Address prefix: Spoke B address prefix (10.1.0.0/16)
      • Next hop Address: NVA Private IP (10.4.0.4)
    • Assign the Routing Table to Spoke A virtual network using the Subnets -> Associate menu.

  • Configure Routing for Spoke B:
    • Create a Routing Table
    • Create a routing rule that routes all the traffic covered by the IP address space of Spoke A to the Network Virtual Appliance IP address. See picture below.
      • Address prefix: Spoke A address prefix (10.0.0.0/16)
      • Next hop Address: NVA Private IP (10.4.0.4)
    • Assign the Routing Table to Spoke B virtual network using the Subnets -> Associate menu.

Test Connectivity

  • Test connectivity from SpokeA to SpokeB
    • Open a RDP connection to SpokeA-vm
    • Open a CMD console and ping SpokeB-vm (10.1.0.4). As you can see below, the test connection was successfully!

Ping SpokeA to SpokeB

  • Test connectivity from SpokeB to SpokeA
    • Open a RDP connection to SpokeB-vm
    • Open a CMD console and ping SpokeA-vm (10.0.0.4). As you can see below, the test connection was also successfully!

SpokeB ping to SpokeA

In addition to this, you can use Powershell to test not only connectivity but complete routing across networks. As you can see in the picture below, tracert cmdlet gives us the complete route for a request. This case, it was run in SpokeA-vm to trace route to SpokeB-vm. Note the first hop to 10.4.0.4 (jm-NVA) and then, next hop to 10.1.0.4 (SpokeB-vm):

References

Peer to peer transitive routing Part 1 | Peer to peer transitive routing Part 2

Route Network Traffic

Other Related Articles

Hub & Spoke Topology with Peerings and Virtual Network Gateway as NVA

 

Tags :

Add comment