Skip to content

Commit

Permalink
Merge pull request #468 from atoakley/andrew/ra-update
Browse files Browse the repository at this point in the history
Update Reference Architecture deployment instructions
  • Loading branch information
GitHubber17 authored Aug 20, 2019
2 parents 559edd2 + 4cb1b04 commit 4493eee
Show file tree
Hide file tree
Showing 4 changed files with 124 additions and 283 deletions.
215 changes: 84 additions & 131 deletions docs/reference-architectures/hybrid-networking/hub-spoke.md
Original file line number Diff line number Diff line change
@@ -1,16 +1,16 @@
---
title: Implement a hub-spoke network topology in Azure
title: Hub-spoke network topology in Azure
titleSuffix: Azure Reference Architectures
description: Implement a hub-spoke network topology in Azure.
author: telmosampaio
ms.date: 06/05/2019
description: This reference architecture deploys a hub-spoke network topology in Azure.
author: MikeWasson
ms.date: 08/19/2019
ms.topic: reference-architecture
ms.service: architecture-center
ms.subservice: reference-architecture
ms.custom: seodec18, networking
---

# Implement a hub-spoke network topology in Azure
# Hub-spoke network topology in Azure

This reference architecture shows how to implement a hub-spoke topology in Azure. The *hub* is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. The *spokes* are VNets that peer with the hub, and can be used to isolate workloads. Traffic flows between the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection. [**Deploy this solution**](#deploy-the-solution).

Expand Down Expand Up @@ -101,7 +101,9 @@ Also consider what services are shared in the hub, to ensure the hub scales for

## Deploy the solution

A deployment for this architecture is available on [GitHub][ref-arch-repo]. It uses VMs in each VNet to test connectivity. There are no actual services hosted in the **shared-services** subnet in the **hub VNet**.
A deployment for this architecture is available on [GitHub][ref-arch-repo]. It uses VMs in each VNet to test connectivity. Two instances of each jumpbox are deployed — one Linux VM and one Windows VM. In a real deployment, you would deploy a single type.

No shared services are deployed in the hub. For a version that includes shared services, see [Hub-spoke network topology with shared services in Azure](./shared-services.md).

The deployment creates the following resource groups in your subscription:

Expand All @@ -111,210 +113,161 @@ The deployment creates the following resource groups in your subscription:
- spoke1-vnet-rg
- spoke2-vnet-rg

The template parameter files refer to these names, so if you change them, update the parameter files to match.

### Prerequisites

[!INCLUDE [ref-arch-prerequisites.md](../../../includes/ref-arch-prerequisites.md)]

### Deploy the simulated on-premises datacenter
### Deploy the reference architecture

To deploy the simulated on-premises datacenter as an Azure VNet, follow these steps:
Follow these steps to deploy the architecture:

1. Navigate to the `hybrid-networking/hub-spoke` folder of the reference architectures repository.

2. Open the `onprem.json` file. Replace the values for `adminUsername` and `adminPassword`.

```json
"adminUsername": "<user name>",
"adminPassword": "<password>",
```

3. (Optional) For a Linux deployment, set `osType` to `Linux`.

4. Run the following command:

```bash
azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p onprem.json --deploy
```

5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine, and a VPN gateway. It can take about 40 minutes to create the VPN gateway.

### Deploy the hub VNet
1. Open the `hub-spoke.json` file.

To deploy the hub VNet, perform the following steps.

1. Open the `hub-vnet.json` file. Replace the values for `adminUsername` and `adminPassword`.
1. Replace the values for all instances of `[replace-with-username]` and `[replace-with-password]`.

```json
"adminUsername": "<user name>",
"adminPassword": "<password>",
"adminUsername": "[replace-with-username]",
"adminPassword": "[replace-with-password]",
```

2. (Optional) For a Linux deployment, set `osType` to `Linux`.

3. Find both instances of `sharedKey` and enter a shared key for the VPN connection. The values must match.
1. Find both instances of `[replace-with-shared-key]` and enter a shared key for the VPN connection. The values must match.

```json
"sharedKey": "",
"sharedKey": "[replace-with-shared-key]",
```

4. Run the following command:
1. Save the file.

1. Run the following command:

```bash
azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-vnet.json --deploy
azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p hub-spoke.json --deploy
```

5. Wait for the deployment to finish. This deployment creates a virtual network, a virtual machine, a VPN gateway, and a connection to the gateway. It can take about 40 minutes to create the VPN gateway.
1. Wait for the deployment to finish. This deployment creates four virtual networks, eight VMs, two VPN gateways, the connection between the two VPN gateways, and configures virtual network peering. It can take about 40 minutes to create the VPN gateways.

### Test connectivity to the hub VNet &mdash; Windows deployment
### Test connectivity &mdash; Windows

To test connectivity from the simulated on-premises environment to the hub VNet using Windows VMs, follow these steps:
To test connectivity from the simulated on-premises environment to the hub and spokes using Windows, follow these steps:

1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group.

2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `onprem.json` parameter file.
2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `hub-spoke.json` parameter file.

3. Open a PowerShell console in the VM, and use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VM in the hub VNet.
3. Open a PowerShell console in the VM, and use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VM in the hub.

```powershell
Test-NetConnection 10.0.0.68 -CommonTCPPort RDP
Test-NetConnection 10.0.0.36 -CommonTCPPort RDP
```

The output should look similar to the following:
The output should look similar to the following:

```powershell
ComputerName : 10.0.0.68
RemoteAddress : 10.0.0.68
RemotePort : 3389
InterfaceAlias : Ethernet 2
SourceAddress : 192.168.1.000
TcpTestSucceeded : True
```
```powershell
ComputerName : 10.0.0.36
RemoteAddress : 10.0.0.36
RemotePort : 3389
InterfaceAlias : Ethernet 2
SourceAddress : 192.168.1.000
TcpTestSucceeded : True
```

3. Use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VMs in the spokes.

```powershell
Test-NetConnection 10.1.0.36 -CommonTCPPort RDP
Test-NetConnection 10.2.0.36 -CommonTCPPort RDP
```

> [!NOTE]
> By default, Windows Server VMs do not allow ICMP responses in Azure. If you want to use `ping` to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM.
> By default, Windows Server VMs do not allow ICMP responses in Azure. If you want to use `ping` to test connectivity, enable ICMP traffic in the Windows Advanced Firewall for each VM.
### Test connectivity to the hub VNet &mdash; Linux deployment
### Test connectivity &mdash; Linux

To test connectivity from the simulated on-premises environment to the hub VNet using Linux VMs, follow these steps:
To test connectivity from the simulated on-premises environment to the hub and spokes using Linux, follow these steps:

1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group.
1. Use the Azure portal to find the VM named `jbl-vm1` in the `onprem-jb-rg` resource group.

2. Click `Connect` and copy the `ssh` command shown in the portal.

3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `onprem.json` parameter file.
3. Run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `hub-spoke.json` parameter file.

4. Use the `nc` command to test connectivity to the jumpbox VM in the hub VNet:
4. Use the `nc` command to test connectivity to the jumpbox VM in the hub:

```shell
nc -vzw 1 10.0.0.68 22
nc -vzw 1 10.0.0.37 22
```

### Deploy the spoke VNets

To deploy the spoke VNets, perform the following steps.

1. Open the `spoke1.json` file. Replace the values for `adminUsername` and `adminPassword`.
The output should look similar to the following:

```json
"adminUsername": "<user name>",
"adminPassword": "<password>",
```

2. (Optional) For a Linux deployment, set `osType` to `Linux`.
```shell
Connection to 10.0.0.37 22 port [tcp/ssh] succeeded!
```

3. Run the following command:
4. Use the `nc` command to test connectivity to the jumpbox VMs in each spoke:

```bash
azbb -s <subscription_id> -g spoke1-vnet-rg -l <location> -p spoke1.json --deploy
nc -vzw 1 10.1.0.37 22
nc -vzw 1 10.2.0.37 22
```

4. Repeat steps 1-2 for the `spoke2.json` file.
### Add connectivity between spokes

This step is optional. If you want to allow spokes to connect to each other, use [Azure Firewall](/azure/firewall/) to force traffic from spokes to the router when trying to connect to another spoke. Perform the following steps to deploy Azure Firewall, firewall rules to allow RDP and SSH, and user-defined routes (UDRs) to allow the two spoke VNets to connect:

5. Run the following command:
1. Navigate to the `hybrid-networking/hub-spoke` folder of the reference architectures repository.

```bash
azbb -s <subscription_id> -g spoke2-vnet-rg -l <location> -p spoke2.json --deploy
```
2. Run the following command:

6. Run the following command:
```bash
azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-firewall.json --deploy
```

```bash
azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-vnet-peering.json --deploy
```
> [!NOTE]
> The private IP address of the Azure Firewall is set to 10.0.0.132. This will be the IP address for this deployment due to the way Azure allocates private IP addresses. Any modifications to this deployment may change this default address. In that situation, edit the `hub-firewall.json` route tables and replace all instances of `nextHop` in the routes to point to the correct private IP address of Azure Firewall.

### Test connectivity to the spoke VNets &mdash; Windows deployment
### Test connectivity between spokes &mdash; Windows

To test connectivity from the simulated on-premises environment to the spoke VNets using Windows VMs, perform the following steps:
If you connected the spokes, perform these steps to verify connectivity using Windows:

1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group.

2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `onprem.json` parameter file.
2. Click `Connect` to open a remote desktop session to the VM. Use the password that you specified in the `hub-spoke.json` parameter file.

3. From inside this remote desktop session, open another remote desktop session to 10.1.0.36. That's the private IP address of the jumpbox in spoke 1.
3. Open a PowerShell console in the VM, and use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VMs in the spoke VNets.
4. From the second remote desktop session, open a PowerShell console. Use the `Test-NetConnection` cmdlet to verify that you can connect to the jumpbox VM in spoke 2.
```powershell
Test-NetConnection 10.1.0.68 -CommonTCPPort RDP
Test-NetConnection 10.2.0.68 -CommonTCPPort RDP
Test-NetConnection 10.2.0.36 -CommonTCPPort RDP
```
### Test connectivity to the spoke VNets &mdash; Linux deployment
### Test connectivity between spokes &mdash; Linux
To test connectivity from the simulated on-premises environment to the spoke VNets using Linux VMs, perform the following steps:
If you connected the spokes, perform these steps to verify connectivity using Linux:
1. Use the Azure portal to find the VM named `jb-vm1` in the `onprem-jb-rg` resource group.
1. Use the Azure portal to find the VM named `jbl-vm1` in the `onprem-jb-rg` resource group.
2. Click `Connect` and copy the `ssh` command shown in the portal.
3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `onprem.json` parameter file.

4. Use the `nc` command to test connectivity to the jumpbox VMs in each spoke:
3. From a Linux prompt, run `ssh` to connect to the simulated on-premises environment. Use the password that you specified in the `hub-spoke.json` parameter file.
```bash
nc -vzw 1 10.1.0.68 22
nc -vzw 1 10.2.0.68 22
```
4. Use the Azure portal to find the VM named `s1jbl-vm1` in the `spoke1-vnet-rg` resource group.
### Add connectivity between spokes
5. Click `Connect` and copy the `ssh` command shown in the portal.
This step is optional. If you want to allow spokes to connect to each other, use [Azure Firewall](/azure/firewall/) to force traffic from spokes to the router when trying to connect to another spoke. To deploy Azure Firewall, along with user-defined routes (UDRs) to allow the two spoke VNets to connect, perform the following steps:
6. In the ssh session created in step 3, run `ssh` to connect to the spoke-1 jumpbox. Use the password that you specified in the `hub-spoke.json` parameter file.
1. Add a subnet for Azure Firewall to the hub virtual network.

```bash
az network vnet subnet create -g hub-vnet-rg --vnet-name hub-vnet -n AzureFirewallSubnet --address-prefixes 10.0.0.128/26
```
2. Deploy Azure Firewall:

```bash
az group deployment create -g hub-vnet-rg --template-file hub-firewall.json
```
3. Run the following command to get the privateIPAddress of the firewall created in step 2:
7. Use the `nc` command to test connectivity to the jumpbox VM in spoke 2:
```bash
az resource show -g hub-vnet-rg -n hub-firewall --resource-type Microsoft.Network/azureFirewalls --query properties.ipConfigurations[0].properties.privateIPAddress
nc -vzw 1 10.2.0.37 22
```
4. Edit the hub-firewall-routes.json file and replace all occurrences of `<azure_firewall_private_ip>` with the IP Address from the previous command. Save hub-firewall-routes.json and then run the following command.

```bash
azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-firewall-routes.json --deploy
```
5. Run the following command to disable BGP route propagation for the route tables associated with the spoke subnets:

```bash
az network route-table update -g hub-vnet-rg -n spoke1-rt --disable-bgp-route-propagation true
az network route-table update -g hub-vnet-rg -n spoke2-rt --disable-bgp-route-propagation true
```

To verify connectivity, perform the following steps:

1. Log into the VM named `jb-vm1` in the `onprem-jb-rg` resource group.

1. From this login session, log into the jumpbox VM for spoke-1. The private IP address is 10.1.0.68.
1. Use the `Test-NetConnection` cmdlet (Windows) or `nc` command (Linux) to test connectivity to 10.2.0.68, which is the jumpbox VM for spoke-2.
## Next steps
For a version of this architecture that deploys shared identity and security services, see [Hub-spoke network topology with shared services in Azure](./shared-services.md).
<!-- links -->
Expand Down
Loading

0 comments on commit 4493eee

Please sign in to comment.