<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=1110556&amp;fmt=gif">
Skip to content
    September 4, 2025

    The Public Internet Is Not Your WAN

    In the move from MPLS to SD-WAN, you gained agility but lost visibility. It's time to reclaim it.

    6 min read

    Key Takeaways
    • Find out how, when replacing MPLS with public internet connectivity, you lose visibility and control.
    • Discover how SD-WAN lacks visibility into the internet underlay, and can't reveal why a path is performing poorly.
    • Establish effective management by shifting from device-centric monitoring to end-to-end path visualization.

    Within many organizations, there’s been a strategic imperative to abandon MPLS in favor of SD-WAN and direct internet access, particularly when it comes to branch office connectivity. The benefits of this move are undeniable and compelling. Organizations can establish direct cloud connectivity and realize cost savings and improved agility.

    However, when you make this move, you fundamentally alter your network's foundation, trading the predictable, engineered transport of MPLS for the best-effort nature of the public internet. This has created a critical visibility gap—a gray zone between your branch and your applications that most network teams are ill-equipped to peer into.

    This isn't just a minor operational hurdle; it's a paradigm shift. The days of a single, accountable provider with a contractually backed service level agreement (SLA) are over. Your control over the end-to-end packet path has vanished, replaced by a reality that’s governed by factors you don't manage.

    The public internet is not your WAN

    It's crucial to internalize that the internet is not a cohesive network; it's a federation of thousands of independent autonomous systems (AS) that interconnect via the Border Gateway Protocol (BGP). The path your branch office traffic takes to your data center or to a SaaS application is determined by a complex and dynamic web of peering agreements between these service providers. This path can change at any moment due to routing policy adjustments, network congestion, or even politically motivated traffic engineering, none of which are under your control.

    Unlike MPLS, where traffic paths are engineered for performance, internet paths are often engineered for the lowest cost to the provider. This frequently leads to “hot-potato” routing, instances in which an ISP hands off your traffic to the next network as quickly as possible. This can route your packets through congested peering points thousands of miles out of the way, introducing significant latency and packet loss. Even if your local broadband connection is performing perfectly, a problem in the middle mile—at an interconnection point between two major backbones—can cripple application performance, and you would have no way of knowing where it's happening.

    Deconstructing the SD-WAN abstraction

    SD-WAN is a great technology for navigating this new reality, but it's not a silver bullet for visibility. SD-WAN operates at the overlay level, creating secure tunnels (like IPsec) that run on top of physical internet connections, which constitute the underlay. Your SD-WAN appliance intelligently monitors the performance of these tunnels, measuring metrics like latency, jitter, and packet loss. If it detects that the path over your primary broadband link is degrading, it can dynamically reroute application traffic to a secondary link, such as another internet connection or LTE.

    The limitation, however, is that the SD-WAN overlay only sees the cumulative result of the underlay path; it treats the entire internet journey as a single, opaque link. It can tell you that a tunnel's performance is poor, but it cannot tell you why. The packet loss could be occurring on the local loop, within the ISP's metro-area network, at a BGP peering point, or on the SaaS provider's network doorstep. Without visibility into the underlay, you can't perform root cause analysis. You're left making blind decisions, like upgrading bandwidth at a branch when the actual bottleneck is an underperforming transit provider hundreds of hops away.

    Why traditional tooling falls short

    The tools you've relied on for decades are insufficient for this new landscape. SNMP-based monitoring, for example, is great for telling you the interface status of the router you own, but it's completely blind to the provider networks beyond it. Your router can be perfectly healthy, while the user experience is unbearable because of an issue deep within the internet.

    Simple diagnostics like ping and traceroute offer a glimpse but are ultimately inadequate. ICMP traffic is often deprioritized or blocked by network devices, providing unreliable performance metrics. While traceroute shows a list of IP hops, it doesn't provide historical performance data and can be misleading due to asymmetric paths and unresponsive routers. It gives you an instantaneous, often incomplete, picture and fails to measure critical metrics like per-hop jitter or loss.

    The imperative for end-to-end path visualization

    To effectively manage branch office connectivity today, you must shift your focus from device health to a continuous, hop-by-hop understanding of the entire data path. This requires a new class of visibility solution that goes beyond the overlay. The goal is to actively measure performance from the branch edge, across every BGP-defined AS hop in the internet underlay, all the way to the application's hosting environment.

    This is achieved with active monitoring that simulates application traffic (for example, using TCP or UDP packets) to continuously probe the network path. By analyzing the response from each hop, you can build a detailed, historical map of per-hop latency, loss, and jitter. This transforms troubleshooting. Instead of following up on a vague complaint about a slow application, you can pinpoint that a specific peering exchange between two ISPs began exhibiting 10% packet loss at a specific time, directly correlating it to user-reported issues.

    This level of empirical data ends the finger-pointing between your network team, your ISPs, and your application vendors. It provides objective evidence to escalate issues effectively and validate that provider fixes have actually resolved the underlay problem. Moving beyond MPLS was a strategic necessity, but succeeding in this new environment requires you to stop guessing about internet performance and start measuring it from end to end.

    To explore these concepts in greater detail and see how you can move from traditional to active monitoring, view our on-demand technical webcast, Take the Hassle Out of SD-WAN Management.

    Yann Guernion

    Yann has several decades of experience in the software industry, from development to operations to marketing of enterprise solutions. He helps Broadcom deliver market-leading solutions with a focus on Network Management.

    Other resources you might be interested in

    icon
    Course August 14, 2026

    AAI: Monitoring Global Shift Operations with Jobstream Runs Views

    Focuses on live operational triage, teaching operators to track real-time executions, identify "Red-Zone" failures, and drill down to resolve bottlenecks.

    icon
    Course August 14, 2026

    AAI: Triaging Incidents via the Gantt View

    See how to use the Gantt Command Center to isolate failures and restore pipelines. Trace dependency paths, evaluate delays, and inspect job properties.

    icon
    Course August 14, 2026

    AAI: Tracking Trends & Runtimes with Jobstream Run Details

    Learn how to analyze multi-week historical performance using Actual, Relative to SLA, and SLA Graph views. See how to spot and prove performance issues.

    icon
    Office Hours August 7, 2026

    Rally Office Hours: August 7, 2026

    Reveals how API queries can be used for non-static values, sharing examples from templates. Looks at risk burndown charts and iteration dropdown limits.

    icon
    Office Hours July 30, 2026

    Rally Office Hours: July 30, 2026

    View this session to find out about the new query counter widget, custom list print card updates, dynamic Rally-to-Clarity mapping, and Q3 events.

    icon
    Blog July 27, 2026

    What’s New in DX NetOps Topology: Summer 2026

    See what’s new in DX NetOps topology. Leverage capabilities for expanded multi-vendor discovery, faster triage, custom views, and seamless data exports.

    icon
    Office Hours July 23, 2026

    Rally Office Hours: July 23, 2026

    Watch the Rally Office Hours from July 23, 2026, featuring updates on custom page migration, governance work rules tips, and upcoming widget releases.

    icon
    Office Hours July 16, 2026

    Rally Office Hours: July 16, 2026

    This July 16, 2026 Rally Office Hours session highlights a new custom pages substitution variable, custom page migration updates, and community Q&A.

    icon
    Blog July 14, 2026

    Controlling Flow Telemetry Overhead in Distributed Environments

    See how the latest updates to NetOps Flow reduce telemetry overhead and optimize WAN usage. Simplify data extraction and integration with the OData 4 API.