WAN....it's not the internet!! (sometimes) // FREE CCNA // EP 8

WAN connectivity is the practical problem of how geographically separated offices—corporate headquarters, branch locations, and even “coffee shop” sites—reach shared systems in the data center without relying on a simple “just run a cable” approach. The core takeaway is that enterprises typically avoid sending all branch traffic over the public internet by using carrier-managed WAN services that keep traffic private, predictable, and—when needed—prioritized for applications like VoIP.

Inside the enterprise, LANs handle local traffic within the corporate office or data center, while WANs handle the long-distance links between those separate sites. This matters because many centralized services live in the data center or headquarters: phone systems (including Cisco Unified Communications Manager), email, databases, websites, payroll, and point-of-sale systems at remote locations. Branch phones need dial tone and voicemail; branch stores need to reach corporate systems for transactions. That centralized design creates a dependency on reliable WAN transport.

Historically, companies connected sites using leased lines—dedicated circuits such as T1 (about 1.54 Mbps) and T3 (about 43 Mbps), with European equivalents like E1/E3. Leased lines were private because they carried only the customer’s traffic, but scaling to many branches became expensive and operationally messy. Older WAN technologies like Frame Relay and ATM also served as alternatives, but they’re largely legacy now.

A major modern workhorse is MPLS (Multi-Protocol Label Switching). With MPLS, an enterprise orders an MPLS circuit from a carrier at each site, and the carrier routes traffic across its network using labels. The result is a “private” WAN experience even though the underlying infrastructure is shared: the carrier creates virtual circuits so one customer’s traffic stays logically separated from others. MPLS is often described as an “MPLS VPN,” but it doesn’t necessarily rely on encryption; separation comes from label switching and virtual circuits. At the network level, the customer edge (CE) router connects to the provider edge (PE) router, and routing happens with packets (layer 3), not Ethernet frames.

MPLS remains common, but it’s increasingly challenged by SD-WAN, which uses standard internet connections and software controls to improve performance and reliability. The shift is driven by changing traffic patterns: more applications now run in public cloud platforms like AWS and Azure, reducing the need for every branch to backhaul to a data center.

Metro Ethernet (Metro E) is another WAN option, typically used between major sites within the same metro area. It can provide very high throughput (often 1 Gbps or 10 Gbps) using fiber and is frequently delivered as layer 2 connectivity. Metro E comes in variants such as E-Line (point-to-point), E-Tree (hub-and-spoke), and E-LAN (multi-point), with service-level agreements that can include compensation if the provider misses uptime targets. However, Metro E is usually too costly for many branch-to-data-center links.

For smaller branches, a common lower-cost approach is site-to-site VPN over public internet. VPNs encrypt traffic so it can traverse the “big bad wild internet” safely, but performance can suffer and—crucially—traffic prioritization (QoS) may be harder than with MPLS. In practice, enterprises weigh cost against reliability, latency, and the ability to prioritize time-sensitive traffic like VoIP.

The episode closes by applying these concepts to CCNA-style scenarios: replacing expensive point-to-point WAN links often means moving to dedicated internet access at branches (and using QoS for voice), and understanding what makes VPNs “true” in real deployments (typically handled by network devices, not requiring client software). The overall message: WAN design is less about picking a single technology and more about matching transport choices to application needs, geography, and budget.