Designing Your Own Enterprise Network for Remote Sites

Welcome back to our series on designing your own enterprise network! In this third installment, we will focus on designing the network for your remote sites. Just like in the main office, we need to plan subnets for workstations, voice, and Wi-Fi. Let’s dive in!

Designing Your Own Enterprise Network for Remote Sites
Designing Your Own Enterprise Network for Remote Sites

Planning Subnets for Remote Sites

For remote sites, we can follow the same basic process as in the main office. Each site will have five workstations and five phones. Additionally, we’ll assume there are around 20 wireless devices for the Wi-Fi network. If it’s a retail outlet, there may be more point-of-sale terminals or other devices, which we can include in the workstation count.

To keep things organized, we’ll select a main network for each site. Let’s use 172.170.0.0/16 for Site A and 172.180.0.0/16 for Site B. While it may seem like overkill for such small sites, using the same subnetting scheme as the main office allows for easier management and organization. Anything starting with 172.17 belongs to Site A, while anything starting with 172.18 belongs to Site B.

VLANs and Subnetting Scheme

Now, you might be wondering if we’re breaking the rules by reusing VLANs 5, 10, and 20 at the main office and the two remote sites. While it may seem against the guidelines of having one subnet per VLAN, stick with me for a moment.

The switches at the branch offices are layer 2 only, meaning the router has to be the default gateway. To achieve this, we configure a trunk link between the router and switch, resulting in a “router on a stick” topology. The router has the dot one IP address assigned to each subnet, which the workstations and phones use as their default gateway.

Further reading:  UDP: Unleashing the Power of L4 Protocol for Your Applications

DHCP Configuration

Now comes the question of DHCP configuration. We have two options: configuring the local router as a DHCP server or using a DHCP helper. In most cases, I prefer the DHCP helper option. It simplifies management by centralizing DHCP scopes and makes it easier for helpdesk staff to assist, even if they have more server than networking training.

However, it’s important to keep in mind that if the remote office loses connection to the main office, clients won’t be able to renew or request new DHCP leases. This is a downside of the DHCP helper approach. Nevertheless, it provides a streamlined solution for most scenarios.

FAQs

Q: Can I use different subnetting schemes for each remote site?

A: While it’s technically possible, it’s best to use the same subnetting scheme at each site. This helps with organization and simplifies management in the long run.

Q: What if I have more devices at a remote site than initially planned?

A: It’s always a good idea to plan for scalability. If you anticipate more devices, adjust your subnetting scheme accordingly to ensure sufficient IP address availability.

Q: Should I use a DHCP server or a DHCP helper for remote sites?

A: Both options have their pros and cons. However, using a DHCP helper is often simpler to manage, especially when dealing with multiple sites.

Conclusion

Designing an enterprise network for remote sites requires careful planning and consideration. By following a consistent subnetting scheme, configuring VLANs, and choosing the right DHCP configuration, you can create a seamless network experience for your users.

For more technology insights and guides, visit Techal. Stay tuned for the next installment in our series, where we’ll dive deeper into securing your enterprise network.

Further reading:  Variable-Length Subnet Mask (VLSM) Mastery: Efficiently Allocate IP Addresses
YouTube video
Designing Your Own Enterprise Network for Remote Sites