Modern enterprises must grow to remain competitive, but this expansion makes WAN management more challenging. Spinning up a new branch or edge computing site with traditional WAN infrastructure can be time-consuming and expensive, with network solutions needing to be purchased and installed and new MPLS links taking weeks or even months to activate. Each branch has infrastructure that admins need to manage remotely, which means accessing many different jump boxes and remembering many different configuration schemas. Essentially, it’s like each branch has its own unique toolkit. That means every additional branch increases the management complexity, making it more likely that mistakes or inefficiencies will occur.

The cloud-delivered branch is a relatively new concept that provides branch networking, security, and management solutions as a cloud-based service. The idea is to simplify remote management by reducing the number of individual solutions deployed at each branch and allowing admins to monitor and control all of their branches from a single place. This is like giving teams one single toolkit that can service every branch.

This post describes the three cloud-based services involved in a cloud-delivered branch, and gives an example of how to implement a cloud-delivered branch using the Nodegrid platform from ZPE Systems.

To see examples of a cloud-delivered branch in action, request a free demo of the Nodegrid platform.

Request a Demo

How a cloud-delivered branch simplifies remote management

There are three key components of a cloud-delivered branch: cloud-based infrastructure management, cloud-based network management, and cloud-based cybersecurity. Let’s discuss the technologies used in each component.

Cloud-managed branch gateways

A branch gateway is a networking device that lives in the branch and provides access to the enterprise WAN as well as cloud resources and the internet. A gateway that’s optimized for branch networking will usually combine multiple network functionalities in one to save rack space and reduce complexity. For the purposes of the cloud-delivered branch, one of these features should be device management, i.e. serial console/console server technology. This functionality means that any infrastructure component connected to the gateway, whether it’s via RJ-45 or Wi-Fi, can be remotely managed by simply logging into the gateway’s software, reducing the need for a jump box or dedicated management hardware. Of course, what makes it a cloud-managed branch gateway is that admins manage it (and all connected infrastructure) from a cloud platform instead of directly connecting to the gateway over the WAN. This means that admins have management access from anywhere in the world, without needing to be on the enterprise network.

Software-defined wide area networking (SD-WAN)

SD-WAN, or software-defined wide area networking, simplifies WAN management by decoupling control functions from the underlying hardware and making them available as software. Essentially, SD-WAN splits a WAN architecture into two layers: the physical hardware that connects branches to the enterprise network (e.g., cloud-managed branch gateways), and the networking logic that orchestrates WAN traffic (e.g., routing rules and load balancing). In a cloud-delivered branch, SD-WAN’s software lives in the cloud, giving network teams a centralized place from which to monitor and control the entire WAN architecture, no matter how many branches are involved.

Secure Access Service Edge (SASE)

SASE (pronounced “sassy”) is a solution that combines multiple enterprise security technologies into a single stack that’s delivered as a cloud-based service. SASE uses SD-WAN technology to directly connect branch users and devices to enterprise resources in the cloud, first passing that traffic through the SASE stack to ensure that security policies and controls are applied. That means this traffic doesn’t need to go through a traditional firewall, which reduces bottlenecks at the central data center without requiring a security appliance at each branch. Eliminating firewalls at most branches decreases management complexity for network admins, and reducing the load on a centralized data center firewall improves performance for the entire enterprise.

How to implement a cloud-delivered branch with Nodegrid

A cloud-delivered branch uses cloud-based infrastructure management, network management, and security to simplify remote branch management. The best practices for building infrastructure to support a cloud-delivered branch include:

Best practices:	Benefits:
Using vendor-neutral hardware and software solutions	Reduces the number of infrastructure devices that need to be deployed Enables unified, centralized infrastructure management Supports third-party apps and automation
Implementing out-of-band (OOB) management at each site	Provides an alternative path to critical remote infrastructure during WAN/LAN outages Reduces the frequency and cost of truck-rolls Ensures that resource-intensive automation workflows don’t cause production latency
Incorporating branch LAN management into the cloud-management umbrella	Extends software-defined networking control into the branch LAN Unifies branch WAN and LAN management behind a single pane of glass Increases efficiency and ensures holistic coverage

Let’s walk through an example of how these best practices are implemented using the Nodegrid platform from ZPE Systems.

Vendor-neutral branch gateways and cloud management

A Nodegrid branch gateway such as the Bold Services Router is installed at each branch to provide WAN and internet access. These all-in-one networking solutions provide routing, switching, and console server management functionality, reducing the number of infrastructure devices that need to be deployed. All Nodegrid devices are completely vendor-neutral, which means you can use them to host your SD-WAN, SASE, or edge computing applications, saving you from buying and installing additional hardware. In addition, vendor-neutral Nodegrid gateways unify branch infrastructure management through the ZPE Cloud software. Any infrastructure connected to a Nodegrid device at any branch is available to manage through ZPE’s centralized, cloud-based platform, simplifying remote management and providing greater opportunities for optimization and automation. Plus, ZPE Cloud software is also vendor-neutral, meaning you can integrate third-party apps and tools to create a fully customizable infrastructure and network orchestration platform.

Gen 3 out-of-band management

One of the most challenging aspects of remote branch management is recovering from network outages without any technical staff on-site to reboot devices or refresh IP addresses. Out-of-band (OOB) management solves this problem by providing an alternative path to critical remote infrastructure that doesn’t rely on the production WAN or LAN. Teams use OOB management to troubleshoot and fix problems and recover from outages, reducing the need for costly truck-rolls. Nodegrid branch gateways provide Gen 3 OOB management capabilities, the most advanced form of OOB technology. Nodegrid gateways are considered Gen 3 because they support third-party infrastructure and network automation via the OOB network. That means teams can use their preferred scripting languages and tools to execute resource-intensive automation workflows on a management network that’s completely separate from the production network. For example, admins can run AIOps root-cause analysis tools to fix problems, or orchestrate automation device provisioning, without taking up valuable MPLS bandwidth or creating additional latency on the production LAN. Additionally, companies typically need a jump box at every branch to host all their troubleshooting, remediation, and automation tools. The benefit of vendor-neutral Nodegrid devices is that they become a one-stop shop for OOB as well as all the services and tools you’d normally install on a jump box. This eliminates the need for separate out-of-band management and jump box appliances.

Branch LAN management with SD-Branch

SD-WAN provides software abstraction and cloud management for WAN architectures, but it typically stops at the edge of the branch, meaning admins use a different solution to manage the internal branch LANs. Nodegrid gateways extend software-defined networking control into the branch LAN using technology called SD-Branch. That means teams can use the same ZPE Cloud platform to control every aspect of branch networking, creating a streamlined management environment that increases efficiency and ensures holistic coverage. Using a Nodegrid device for your cloud-delivered branch reduces the number of network solutions deployed at each site, standardizes branch network management, and increases your automation and orchestration capabilities. Deploying fewer boxes decreases the cost to spin up a new branch, while standardization and automation helps to reduce operating expenses and increase operational efficiency.

Ready to learn more about implementing a cloud-delivered branch?

To learn more about implementing a cloud-delivered branch with Nodegrid, contact ZPE Systems today.

Contact Us

Software-defined wide area networking, or SD-WAN, uses software abstraction to create a virtual overlay network that sits on top of the underlying WAN infrastructure. This gives organizations greater control over distributed network architectures and enables a high degree of automation. SD-WAN can be deployed in a hub-and-spoke model or a variety of mesh topologies depending on the organization’s requirements and capabilities.

In this guide are the most common SD-WAN deployment models with diagrams, pros and cons, and best practices to help organizations choose the right topology.

Hub-and-spoke SD-WAN deployment models

In the hub-and-spoke model, large data centers serve as centralized hubs that all SD-WAN traffic must flow through. The spokes are the campuses, branch offices, and edge sites that connect to each hub in order to access the enterprise WAN.

The hub-and-spoke SD-WAN deployment model can be executed in a couple of different ways:

Spoke-to-hub only

In this SD-WAN deployment model, the spokes for a particular hub are unable to communicate with each other, they can only interact with the central hub. The networking logic for this deployment model is relatively simple compared to the others. It’s also useful when spoke sites need to be isolated from each other for security, privacy, or regulatory reasons.

Spoke-to-spoke via hub

In this deployment, spoke sites can communicate with each other, but all of their traffic must pass through the central hub first. Again, this makes SD-WAN networking logic a little simpler than allowing direct communication between sites. It also allows spoke traffic to pass through a centralized firewall first so that traffic can be inspected and security policies can be applied without needing to deploy firewall appliances at each spoke site.

Hub-and-spoke pros and cons

The hub-and-spoke approach is relatively easy to deploy and manage because all SD-WAN traffic must flow through a limited number of hub data centers. There’s no need to configure, secure, and load-balance network traffic between the numerous spoke sites that comprise an enterprise network, so organizations that are adopting SD-WAN for the first time tend to favor this approach.

However, since all spoke traffic needs to pass through a centralized hub, this creates bottlenecks that can impact network performance for all connected sites. Centralized hubs also represent single points of failure for the spokes that rely on them for enterprise network access – if a hub goes down due to a cybersecurity breach, ISP outage, or equipment failure, then spokes will lose their ability to communicate with each other or access enterprise network resources. Plus, since all traffic and data are aggregated in centralized hubs, they present attractive targets to cybercriminals, who can easily get all the valuable data they want in a single location instead of needing to move around the network.

Hub-and-spoke best practices

If you’re considering the hub-and-spoke approach, it’s important to have a business continuity plan that accounts for hub failures. For example, you should have some sort of network failover option (such as cellular LTE) in case the ISP connection goes down. You should also be able to redirect traffic from one hub to another if the first hub gets overloaded or experiences a failure. In addition, hubs should be deployed with out-of-band (OOB) management so network admins have 24/7 management access even if the SD-WAN connection goes down.

Learn more about Out-of-band (OOB) management.

Mesh SD-WAN deployment models

In the mesh deployment model, campuses, branch offices, and edge sites have some ability to communicate with each other directly, without their traffic needing to pass through a hub first. The degree to which sites can interact with each other depends on the type of mesh topology that’s deployed.

Full mesh deployment

In a full mesh deployment, there is any-to-any communication between edge and branch sites using overlay tunnels. There are often still hub data centers to handle requests for centralized enterprise resources, but most other requests are handled by services deployed at the network edge (either at the sites themselves or in the cloud).

Full mesh pros and cons

The full mesh topology enables faster communication between sites. It also allows organizations to deploy applications and services at the edge of the network where data is being generated and used, which is known as edge computing. There are also no single points of failure in the full mesh SD-WAN architecture, which reduces the risk of an outage and shortens the duration of outages that do occur. In addition, data and applications are distributed across many different locations, which can limit the damage caused by security breaches – instead of finding all your valuable data in a single server, cybercriminals have to jump around the network, increasing the chances they’ll be caught.

However, the full mesh topology is the most challenging to implement, manage, and optimize because there are so many moving parts involved. Each site needs a full stack of networking and security solutions because they aren’t relying on a centralized hub. Increasing the complexity of the SD-WAN architecture also increases the risk that mistakes will be made during configurations, deployments, and updates.

Partial mesh deployment

In this topology, some spokes can directly communicate with each other, and some services are deployed at the edge. However, there isn’t a full decentralization of applications and security, so some traffic still needs to pass through a hub.

Partial mesh pros and cons

Many organizations arrive at a partial mesh deployment on their journey from a hub-and-spoke deployment to a full mesh. A partial mesh topology reduces some of the load on centralized hubs and firewalls by moving certain services to the edge and allowing some direct site-to-site communications, which can improve performance. The organization can still rely on some centralized security functionality, reducing the number of security appliances or cloud-based services needed to protect the edge.

However, a partial mesh doesn’t completely address the limitations of a more centralized hub-and-spoke deployment. Hubs still represent potential bottlenecks and points of failure in the SD-WAN architecture. Plus, there’s still a lot of data centralization, meaning that storage and data processing servers in hubs will make attractive targets to hackers.

Hybrid mesh deployment

In a hybrid mesh, many hubs are deployed in a mesh topology, which means there is frequent communication and a high level of redundancy. However, branch and edge sites are still deployed as spokes, which means all their traffic goes through the hub mesh.

Hybrid mesh pros and cons

A hybrid mesh deployment ensures that no single hub acts as a single point of failure, enabling a high degree of redundancy and load balancing. Spoke sites can’t directly interact with each other, which reduces the complexity of the SD-WAN topology and decreases the number of security appliances to purchase and manage. Bottlenecking is also less of an issue because traffic from spokes doesn’t have to pass through a single designated hub, and can instead be distributed across multiple hubs.

However, a hybrid mesh topology is still fairly centralized, so you don’t get all the security and performance benefits of a decentralized full mesh deployment. Hubs are still valuable targets for cybercriminals, edge sites still need to send data to hubs for processing, and spokes cannot access enterprise network resources without going through the hub mesh. If that hub mesh is unavailable for any reason, spoke sites will be completely cut off.

Regional mesh

A regional mesh allows organizations to implement different deployment models for different regions. For instance, one region may have a spoke-to-spoke deployment, while another has a partial mesh. When traffic from one region needs to go to another, it must pass through a regional hub first.

Regional mesh pros and cons

The regional mesh model gives large or highly distributed organizations the flexibility to use deployments that meet the specific requirements of each region. For example, there may be a cluster of branch offices that process classified data for the defense industry, so the organization uses the spoke-to-hub-only deployment to isolate those sites from the rest of the enterprise network. In another region, the org may run a lot of edge computing for machine learning applications and need there to be fast and seamless communication between edge data centers. In that case, they might deploy a full mesh topology in that specific region.

However, this flexibility can also create a lot of management complexity. Admins need to learn, manage, and troubleshoot different configurations, network logic, and security rules for different regions. Plus, each region is subject to the downsides and limitations of whichever deployment model is used there. In addition, regional hubs often still act as potential bottlenecks and points of failure between each region and the enterprise network.

Mesh best practices

All of the best practices for the hub-and-spoke model also apply to mesh SD-WAN deployments. There are a couple of additional considerations for organizations considering a more decentralized deployment, including:

Cloud-delivered security – Mesh deployments typically require security solutions deployed at the edge, so that traffic doesn’t need to pass through a centralized firewall. However, purchasing appliances for each location is expensive and adds to the complexity of the architecture. Solutions like SSE (Security Service Edge) allow you to use your SD-WAN technology to send edge traffic through security services in the cloud. SSE takes many of the capabilities of traditional security appliances and combines them into a cloud-delivered stack, so organizations can get enterprise-level protection without needing to deploy additional hardware or route traffic through a central bottleneck.

Network automation – Manually configuring and controlling a complex mesh network increases the risk of human error. Luckily, SD-WAN’s software abstraction makes it easier to use automated scripts and playbooks to handle a lot of the tedious, repetitive tasks that are prone to mistakes such as device configurations and ACL (access control list) updates. Automation also means that work can get done faster and without putting additional pressure on overworked network teams.

Centralized orchestration – Mesh topologies have so many moving parts, and needing to manage each one of them separately makes it impossible to holistically control, optimize, and secure the deployment. Centralized orchestration gives network teams a common interface they can use to create, organize, deploy, monitor, and troubleshoot automated and manual SD-WAN workflows. That means the orchestrator should be vendor-neutral so it can dig its hooks into every device, application, and service in every SD-WAN site in your deployment.

Vendor neutrality – On that note, vendor neutrality is also a best practice because of how it simplifies and strengthens automation infrastructure. Many vendors lock you into using specific tools, applications, and devices, which makes automation pipelines more complicated and brittle — if one component breaks, the whole infrastructure goes down. Using vendor-neutral tools and orchestration platforms means you don’t have to inflate your toolkit or overcomplicate your automation pipeline, improving resiliency.

Choosing the right SD-WAN deployment model

Every SD-WAN topology comes with its own advantages and limitations, so organizations must assess their requirements and capabilities to determine which one to deploy. For example, if your team doesn’t have any SD-WAN experience, then jumping right into a full mesh deployment may not be practical. If you need your edge sites to have real-time data processing abilities (for example, in healthcare applications), then you may want to consider a less centralized mesh topology.

	Pros	Cons
Hub-and-spoke	Easy to deploy Reduced management complexity	Creates bottlenecks Hubs are single points of failure Centralized data is a target for hackers
Full mesh	Enables edge computing No single points of failure Decentralized data limits the blast radius of breaches	Complex implementation and management Increases risk of human error Requires edge or cloud-delivered security solutions
Partial mesh	Reduces some load on centralized hubs Easier to deploy than a full mesh Enables edge computing	Hubs can still create bottlenecks Hubs are still potential points of failure There is still some data centralization
Hybrid mesh	Enables a high degree of redundancy among hubs Not as complex as a full mesh Reduces bottlenecks	There is still some data centralization There is still some bottlenecking Hub mesh is still a point of failure
Regional mesh	Flexible and customizable Addresses specific needs of individual sites and regions	Each regional hub is a potential point of failure Variety of topologies creates a lot of management complexity Subject to the downsides and limitations of all the deployment models in use

Ready to learn more about SD-WAN deployment models?

For more guidance on how to choose and implement SD-WAN deployment models, contact the experts at ZPE Systems. Contact Us