Choosing the right SD-WAN deployment model<\/a><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n[\/et_pb_text][et_pb_text admin_label=”Text” module_id=”1″ _builder_version=”4.20.2″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n
Hub-and-spoke SD-WAN deployment models<\/h2>\n
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.<\/p>\n
[\/et_pb_text][et_pb_image src=”https:\/\/zpesystems.com\/wp-content\/uploads\/2023\/03\/Hub-Spoke.png” alt=”Hub & Spoke” title_text=”Hub & Spoke” align=”center” _builder_version=”4.20.2″ _module_preset=”default” global_colors_info=”{}”][\/et_pb_image][et_pb_text admin_label=”Text” _builder_version=”4.20.2″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n
The hub-and-spoke SD-WAN deployment model can be executed in a couple of different ways:<\/p>\n
Spoke-to-hub only<\/h3>\n
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\u2019s also useful when spoke sites need to be isolated from each other for security, privacy, or regulatory reasons.<\/p>\n
Spoke-to-spoke via hub<\/h3>\n
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.<\/p>\n
Hub-and-spoke pros and cons<\/h2>\n
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\u2019s 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.<\/p>\n
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 \u2013 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.<\/p>\n
Hub-and-spoke best practices<\/h2>\n
If you\u2019re considering the hub-and-spoke approach, it\u2019s important to have a business continuity plan that accounts for hub failures. For example, you should have some sort of network failover option<\/a> (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.<\/p>\n