Fork me 🍴

Willian Antunes

Learning hub-spoke with Packet Tracer and deploying it through Terraform on Azure

7 minute read

azure, packet-tracer, hub-spoke, terraform, networking

Table of contents
  1. The hypothetical scenario
  2. Configuring each router in the Packet Tracer
  3. The same scenario on Azure using Terraform
    1. Details about the translation
    2. Testing connectivity using Ping
    3. Testing connectivity using Network Watcher
  4. Conclusion

We'll understand how to build a hub-spoke network topology through practice. We won't cover many aspects of networking design though, such as proper subnetting, broadcast domain, dynamic routing, and others.

The hypothetical scenario

Let's say we have the following scenario:

  • Your company will have three sites.
  • Each site may have more than 60.000 hosts.

Download the laboratory file and open it on the Packet Tracer. You'll see the following:

Network topology containing three sites. One site is identified as yellow with address space 10.10.0.0/16, another as blue and purple with address space 10.11.0.0/16, and the last as red with address space 10.12.0.0/16.

Each router has a name:

  • Site A: It represents a spoke.
  • Site B: It represents a spoke.
  • Hub: The hub virtual network is the central point of connectivity. If we had more spokes, the topology would look like a star. Let's imagine it being our main site.

We'll complete the configuration through static routing.

Configuring each router in the Packet Tracer

This is the configuration for the hub router:

Router> enable
Router# config t
Router(config)# no ip domain-lookup
Router(config)# hostname hub
hub(config)# int f0/0
hub(config-if)# ip address 10.10.0.1 255.255.0.0
hub(config-if)# no shut
hub(config-if)# int s0/2
hub(config-if)# ip address 172.0.0.1 255.255.255.252
hub(config-if)# clock rate 64000
hub(config-if)# no shut
hub(config-if)# int s0/3
hub(config-if)# ip address 172.0.0.5 255.255.255.252
hub(config-if)# clock rate 64000
hub(config-if)# no shut
hub(config-if)# exit
hub(config)# ip route 10.11.0.0 255.255.0.0 172.0.0.2
hub(config)# ip route 10.12.0.0 255.255.0.0 172.0.0.6
hub(config)# exit
hub# write

The line where we set the serial interface with the clock rate is only required to make the configuration work. Usually, the clock rate is defined by the modem to which the serial interface connects. This is the configuration for the site-a router:

Router> enable
Router# config t
Router(config)# no ip domain-lookup
Router(config)# hostname site-a
site-a(config)# int f0/1
site-a(config-if)# ip address 10.11.0.1 255.255.248.0
site-a(config-if)# no shut
site-a(config-if)# int f1/0
site-a(config-if)# ip address 10.11.8.1 255.255.248.0
site-a(config-if)# no shut
site-a(config-if)# int s0/2
site-a(config-if)# ip address 172.0.0.2 255.255.255.252
site-a(config-if)# no shut
site-a(config-if)# exit
site-a(config)# ip route 10.10.0.0 255.255.0.0 172.0.0.1
site-a(config)# ip route 10.12.0.0 255.255.0.0 172.0.0.1
site-a(config)# exit
site-a# write

This is the configuration for the site-b router:

Router> enable
Router# config t
Router(config)# no ip domain-lookup
Router(config)# hostname site-b
site-b(config)# int f0/1
site-b(config-if)# ip address 10.12.0.1 255.255.0.0
site-b(config-if)# no shut
site-b(config-if)# int s0/2
site-b(config-if)# ip address 172.0.0.6 255.255.255.252
site-b(config-if)# no shut
site-b(config-if)# exit
site-b(config)# ip route 10.11.0.0 255.255.248.0 172.0.0.5
site-b(config)# ip route 10.11.8.0 255.255.248.0 172.0.0.5
site-b(config)# ip route 10.10.0.0 255.255.0.0 172.0.0.5
site-b(config)# exit
site-b# write

We could summarize the routes 10.11.0.0/21 and 10.11.8.0/21 to 10.11.0.0/16. You can try it if you want. When we finish the configuration, we can ping each host using a protocol data unit (PDU). It's interesting to notice that the first ICMP package does not work because the ARP protocol needs to find the MAC address 👀. Another interesting exploration to do is to execute show ip route and show ip interface brief on each router.

The same scenario on Azure using Terraform

Download the project and follow the prerequisites in the README file. Now run the container:

docker compose run --rm docker-client-tf-did bash

Execute terraform init followed by terraform apply and await its conclusion.

Notice: We are not using Azure Virtual Network Manager, though it's highly recommended. Know how to create hub-spoke topology through it.

Details about the translation

You'll see the following regions in the main.tf file:

The main.tf file shows 7 regions: VNET, Routing Table, Peering Connections, Public IPs, Azure Firewall, NAT Gateway, and Virtual Machines.

In terms of VNet addresses, we have the following:

  • Spoke site A: 10.11.0.0/16.
  • Spoke site B: 10.12.0.0/16.
  • Hub: 10.10.0.0/16.

Spoke site A is the only one that has two subnets. The other two only have one. If we look at how each network communicates with each other in the Packet Tracer, the router is responsible for it, given how the routing is configured. On the other hand, Azure does not work this way; it does not work by configuring the routing table solely. Using the hub network for transit (read more about service chaining), we have three solutions:

  1. Use a Virtual Network Appliance (VNA) and configure it to route traffic to and from spoke A and V.
  2. Create a Virtual Network Gateway of type VPN for gateway transit.
  3. Use Azure Firewall to route traffic between VNets. It also secures and inspects network traffic.

The translation uses the option 3. Azure Firewall requires a particular subnet, so we have an additional one for the hub network. Look at the article Spoke-to-spoke Networking for further details regarding other possible solutions.

In terms of outbound connectivity, we are going to use NAT Gateway. It can provide internet access from the hub virtual network for all spoke virtual networks peered.

The image illustrates how we translated the previous network topology to the Azure cloud provider. It has additional resources such as NAT Gateway, Firewall, and Virtual Machines.

Testing connectivity using Ping

Pick up a virtual machine from spoke site A and connect to it using the serial console:

When you select a virtual machine, you can choose "go to serial console" to connect to it.

Use the user spoke-site-a-host-1 and the password returned from the terraform output vm_password command. Ping the IP 10.12.0.4 and check it out! 😉

Testing connectivity using Network Watcher

You can use this approach to test connectivity in many ways. For example, what is the next hop from a virtual machine in spoke site A that targets the IP of a virtual machine in spoke site B?

It shows the "Network Watcher | Next hop" window on Azure Portal.

With Network Watcher, we don't need to access the machine to test connectivity.

Conclusion

Suppose you have to learn how to design and implement networking topologies, though you only know the very basics. In that case, it's highly recommended to do it first on the Packet Tracer to comprehend theories, then go to a cloud service such as Azure. Learning by practice is fantastic because you consolidate everything through mistakes we usually face in production environments.

See everything we did here on GitHub.

Posted listening to Pride And Joy, Stevie Ray Vaughan & Double Trouble 🎶.


Have you found any mistakes 👀? Feel free to submit a PR editing this blog entry 😄.