# 👻Debunking Palo Alto’s SD-WAN Gateway Myths | Why Hub-and-Spoke is Superior🚲 Palo Alto Networks recently published an article titled "[What is an SD-WAN Gateway?](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway)", which contains a **significant amount of misinformation** aimed at promoting their **mesh-based SD-WAN solution** while attempting to discredit the **hub-and-spoke architecture**—the very model that [**Fusion’s SD-WAN**](https://fusionsdwan.co.za/) (and other truly scalable SD-WANs) rely on. The article misrepresents **latency**, **scalability**, **network failure points**, and **cloud efficiency**, presenting a **flawed** case for a **mesh-based SD-WAN** that simply does not hold up to scrutiny. This article breaks down the **false claims** made by Palo Alto and demonstrates why **hub-and-spoke SD-WAN is the only viable solution for large-scale networks**. --- ## **1\. Latency | A Complete Misunderstanding of Network Performance** Palo Alto’s article fundamentally **misrepresents the causes of latency** and the **capabilities of different SD-WAN architectures**. * **Claim:** *"Hub-and-spoke architectures introduce unnecessary detours, increasing latency."* * **Reality:** *Latency is caused by congested paths, not by network topolo*[*gy.*](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway) A **hub-and-spoke SD-WAN** actually **minimises** latency by dynamically **selecting the best path** based on **real-time performance metrics**. Legacy networking has no way of determining the lowest-latency path, but **Fusion’s SD-WAN actively measures and routes traffic accordingly**. Palo Alto's diagram falsely implies that hub-and-spoke networks force all traffic through a central hub, creating unnecessary delays. **This is simply not true**. A **well-designed** hub-and-spoke network **optimises traffic paths** dynamically, **selecting the lowest-latency route available**. Take South Africa, for example—a country Palo Alto’s marketing would likely consider "poorly connected." Yet, from **Johannesburg, latency to major cloud services is under 2ms**, and across the entire country, the worst-case latency is **under 20ms**. The diagram Palo Alto uses is **pure misinformation**, designed to scare businesses into **choosing an inferior solution**. ### **Detours Happen on Every Network** Palo Alto blames hub-and-spoke for "detours" in network traffic. But in reality: * **Detours are a fact of life in networking**—whether using **mesh, hub-and-spoke,** [**or even a direct connection**](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway). * **Internet routing changes constantly** due to congestion, outages, and provider decisions. Mesh-based SD-WAN does **not** magically eliminate detours; it just makes routing **less predictable** and harder to manage at scale. --- ## **2\. Single Point of Failure | A False Argument** Palo Alto claims that a hub-based SD-WAN architecture is a **single point of failure**. This argument completely ignores **modern networking realities**. * **Claim:** *"A hub in a hub-and-spoke model is a single point of failure."* * **Reality:** *Cloud-based SD-WAN hubs are deployed in redundant configurations with multi-path connectivity.* [A prope](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway)rly designed hub-and-spoke **is not a single point of failure** because: 1. [**C**](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway)**loud hubs are deployed at peering exchanges with massive redundancy.** 2. **Fusion’s SD-WAN (and others like it) use N+N redundancy at the hub level**, ensuring failover to another hub automatically. 3. **A well-architected SD-WAN does not depend on a single hub—it uses regional hubs for resilience.** If Palo Alto’s logic were correct, then **the entire cloud model would be a single point of failure**, which it clearly **is not**. Their own **firewalls are cloud-managed**, yet they do not claim those to be unreliable. **The hypocrisy is obvious.** ### **The True Single Points of Failure | Palo Alto’s X-Connect Model** What Palo Alto conveniently **ignores** is that their **mesh-based SD-WAN relies on direct interconne**[**ctions between sites**. These](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway) are known as **x-connects**, and they **in**[**troduce far greater risks** th](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway)an a well-designed hub-and-spoke network. * Each **x-connect is a potential failure point**. * **Managing 200+ x-connects** is a **nightmare** compared to a **handful of redundant cloud hubs**. * The more direct links you introduce, the **more unstable the network becomes**. By contrast, **Fusion’s SD-WAN is cloud-native**, leveraging **redundant, high-performance interconnects** that benefit from **carrier-grade redundancy**. --- ## **3\. Scalability | The Biggest Lie in Palo Alto’s Article** Palo Alto tries to paint hub-and-spoke as **less scalable than mesh networking**, which is perhaps the **most ridiculous claim in the entire article**. * **Claim:** *"Hub-and-spoke architectures do not scale well beyond a certain number of locations."* * **Reality:** *Mesh networks become unmanageable beyond 200 sites, wh*[*ile hub-and-spoke scales to*](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway) *millions.* ### **Why Hub-and-Spoke Scales & Mesh Does Not** 1. **Mesh requires each site to manage a direct connection to every other site**. This results in an **exponential increase in overhead**. 2. **With 10 locations, a full-mesh network has 45 connections**. 3. **With 100 locations, a full-mesh network has 4,950 connections**—a **management and resource nightmare**[.](https://www.paloaltonetworks.com/cyberpedia/what-is-an-sd-wan-gateway) 4. **With 1,000 locations, it becomes impossible to manage**. **Hub-and-spoke eliminates this problem** by: * **Centralising the heavy lifting** at cloud-based hubs. * **Allowing regional hubs to handle traffic intelligently**. * **Reducing the number of required connections, making the network easier to scale and maintain**. This is why **large-scale networks—including global enterprises, cloud providers, and service providers—rely on hub-and-spoke architectures**. If mesh scaled better, companies like **Google, AWS, and Microsoft** would have adopted it. They haven’t—because it doesn’t work. Palo Alto’s **mesh-based SD-WAN is resource-intensive, cumbersome, and completely unscalable beyond small deployments**. **That’s the real reason they are pushing this narrative—they cannot compete in truly large-scale environments.** --- ## **The Verdict | Palo Alto’s Mesh SD-WAN is a Marketing Gimmick** Palo Alto's attempt to discredit **hub-and-spoke SD-WAN** is nothing more than **a marketing stunt designed to sell an inferior solution**. Their claims about **latency, single points of failure, and scalability** are **misleading at best and outright false at worst**. ### **What They Don’t Want You to Know** * **Hub-and-spoke SD-WANs like Fusion’s provide the best latency paths because they operate at cloud interconnect points**. * **Cloud hubs are NOT single points of failure—Palo Alto's x-connect mesh introduces MORE failure risks.** * **Mesh networks become unmanageable beyond 200 sites—hub-and-spoke scales to millions.** Palo Alto is attempting to push **a fundamentally flawed networking model** that **does not scale, does not optimise performance, and does not provide the reliability businesses need**. If you’re looking for **a truly scalable, reliable, and high-performance SD-WAN solution**, **Fusion’s hub-and-spoke architecture is the right choice**—not Palo Alto’s **misguided attempt at rebranding networking fundamentals**. %[https://youtu.be/bxl_r3dK3EQ?si=jpbkg5YBbTy5JegY]