MPLS over Satellite: How Enterprise WANs Extend Private Connectivity to Remote Sites

Enterprises with operations in remote locations face a fundamental connectivity challenge: the corporate WAN needs to reach every site, but terrestrial MPLS circuits and fiber simply do not extend to mining camps, offshore platforms, rural branch offices, or temporary field operations. The network still needs to work — with the same traffic isolation, QoS guarantees, and provider-managed routing that the rest of the WAN delivers.

Satellite solves the last-mile problem. When a satellite link replaces the terrestrial tail circuit, MPLS can ride over it the same way it rides over any Layer 2 transport. The remote site joins the enterprise WAN as a standard CE-connected spoke, with label-switched paths providing the same forwarding behavior as any other site on the network.

This article is a practical engineering guide to MPLS over satellite. It covers how the architecture works, where it makes sense, what the latency and QoS trade-offs look like, and when MPLS over satellite is the right choice versus simpler alternatives like internet VPN. For a broader view of enterprise satellite connectivity options, see Enterprise Satellite Internet Guide. For backhaul architecture fundamentals, see Satellite Backhaul Explained.

What Does MPLS over Satellite Mean?

MPLS over satellite means extending a provider-managed or enterprise MPLS network over a satellite link to reach a remote site that has no terrestrial connectivity. In practical terms, a router at the remote site acts as a Customer Edge (CE) device. Instead of connecting to the provider's PE router over a fiber or leased line, the CE connects over a satellite link. The satellite replaces the physical last mile — everything above Layer 2 operates the same way it would on a terrestrial circuit.

At the hub or teleport side, the satellite link terminates at a Provider Edge (PE) router that connects to the MPLS backbone. The PE and CE establish a routing adjacency (typically BGP or OSPF), exchange routes, and the PE assigns labels for forwarding traffic through the provider core. From the MPLS network's perspective, the satellite-connected site is just another spoke — the label-switched path does not care whether the underlying transport is fiber, microwave, or satellite.

This is fundamentally different from ordinary internet access over satellite. With internet access, the remote site gets a public IP and best-effort connectivity to the internet. With MPLS over satellite, the remote site gets private, isolated connectivity to the enterprise WAN. Traffic is separated by labels, routing is managed by the provider, paths are deterministic, and QoS policies can be enforced end-to-end.

The key engineering insight is that satellite is the transport layer. MPLS is a Layer 2.5/3 technology that runs over whatever Layer 2 medium is available. The satellite modem presents an Ethernet or serial interface to the CE router — the router does not know or care that the packets are traversing a satellite hop. This transparency is what makes MPLS over satellite work without protocol modifications.

Typical Use Cases

Remote Branch Offices

Banks, government agencies, and retail chains operating in emerging markets frequently have branches in locations where terrestrial MPLS circuits are unavailable or prohibitively expensive. A satellite MPLS connection gives these branches the same WAN connectivity as urban offices — private IP addressing, centralized routing, and consistent security policies — without waiting for fiber buildout that may never arrive.

Mining and Industrial Sites

Mining operations, pipeline monitoring stations, and industrial facilities in remote areas need both OT (operational technology) and IT connectivity back to corporate headquarters. MPLS over satellite provides the traffic isolation needed to separate SCADA and telemetry traffic from enterprise IT traffic on a single satellite link, with VRF-based segmentation ensuring that control system traffic is never mixed with general internet browsing. For detailed treatment of industrial control over satellite, see SCADA over Satellite.

Oil and Gas Operations

Upstream exploration and production sites — drilling rigs, well pads, production platforms — require private connectivity to operations centers for real-time production data, safety systems, and corporate communications. These sites are often in locations (offshore, deep desert, Arctic) where the only viable transport is satellite. MPLS provides the managed routing and traffic engineering that these mission-critical operations demand.

Temporary Field Operations

Construction projects, humanitarian response, and military forward operating bases need WAN connectivity that deploys in days, not months. A flyaway satellite terminal with an MPLS-capable CE router can extend the enterprise WAN to a temporary site anywhere with sky visibility. When the operation concludes, the terminal is redeployed — no infrastructure remains.

Backup WAN Path

Enterprises with terrestrial MPLS at their primary sites use satellite MPLS as a backup path. When the terrestrial circuit fails, BGP route preference shifts traffic to the satellite link. The site remains on the corporate WAN with the same addressing and routing — only the latency and bandwidth characteristics change. This is a common pattern for sites where a single terrestrial circuit represents a single point of failure.

How MPLS over Satellite Is Architected

The architecture follows the standard MPLS VPN model, with the satellite link inserted as the last-mile transport for remote sites.

Remote site: A CE router (Cisco, Juniper, or similar) connects to a satellite modem or integrated terminal via Ethernet. The CE router runs the enterprise routing protocol (BGP or OSPF) and presents the local LAN to the WAN. Multiple VRFs can be configured on the CE to segment traffic — for example, separating voice, data, and management into distinct virtual networks over the same physical satellite link.

Satellite segment: The link itself typically uses a hub-and-spoke (star) topology, which is the most common architecture for enterprise MPLS over satellite. The remote terminal transmits to a hub station at the teleport. For architecture options including mesh and hybrid topologies, see Satellite Network Topology.

Hub/teleport side: A PE router at the hub connects to the MPLS provider backbone or the enterprise core network. The PE terminates the routing adjacency with the remote CE, assigns MPLS labels, and forwards traffic through the provider's label-switched network to other sites. The teleport provides the RF infrastructure — antenna, BUC, LNB — and the satellite modem that presents the link as an Ethernet interface to the PE router.

Routing: BGP is the standard protocol between CE and PE in MPLS VPN deployments. The PE redistributes the remote site's routes into MP-BGP (Multi-Protocol BGP) for distribution across the MPLS backbone. OSPF can also be used as the CE-PE protocol, with the PE performing mutual redistribution between OSPF and MP-BGP. The choice depends on the enterprise's existing routing design.

Segmentation: VRF (Virtual Routing and Forwarding) instances provide Layer 3 isolation. A single satellite link can carry multiple VPNs — voice, SCADA, corporate data, guest internet — each with its own routing table and forwarding policy. This is one of the key advantages of MPLS over simpler VPN approaches: the segmentation is enforced at the network layer, not just at the encryption layer.

Why Latency Matters

Satellite latency is the single most important factor in MPLS over satellite design. For GEO satellites — which carry the majority of enterprise MPLS traffic today — the one-way propagation delay is approximately 250 ms (36,000 km to geostationary orbit and back). With processing, modulation, and routing delays added, the practical round-trip time is approximately 600 ms.

MPLS does not reduce this latency. MPLS is a forwarding mechanism — it determines how packets are switched through the provider network using labels. It does not change the speed of light or the distance to the satellite. A packet traversing an MPLS label-switched path over GEO satellite experiences the same 600 ms round-trip as a packet traversing a plain IP route over the same satellite link.

Applications that work well: Email, file synchronization, ERP transactions, database queries, SCADA polling, and bulk data transfer are all latency-tolerant. These applications complete their work in seconds or minutes regardless of whether individual round-trips take 50 ms or 600 ms. They are the sweet spot for MPLS over GEO satellite.

Applications that struggle: Real-time voice is manageable with proper QoS (strict priority queuing, jitter buffers) but noticeable — speakers experience a half-second delay that requires conversational adaptation. Video conferencing works but with degraded interactivity. Interactive remote desktop sessions feel sluggish. Any application with tight timeout assumptions may need tuning.

TCP performance: Standard TCP congestion control algorithms struggle with the high bandwidth-delay product (BDP) of satellite links. A 10 Mbps link with 600 ms RTT has a BDP of 750 KB — the TCP window must reach this size before the link is fully utilized. WAN optimization appliances with TCP acceleration (spoofing local ACKs, using performance-enhancing proxies) are essential for achieving full throughput on MPLS over satellite links.

For detailed latency numbers across GEO, MEO, and LEO orbits, see Satellite Latency Comparison.

QoS and Traffic Engineering

QoS matters more on satellite than on terrestrial links for three reasons: bandwidth is expensive (satellite capacity costs 10–100x more per Mbps than terrestrial), capacity is shared (most satellite services use contended bandwidth), and high latency amplifies the impact of congestion (a congested terrestrial link adds milliseconds of queuing delay; a congested satellite link adds milliseconds on top of an already-600 ms baseline).

Typical QoS classes for MPLS over satellite include:

MPLS traffic engineering provides a natural mapping between label-switched paths and satellite QoS queues. Each traffic class can be assigned to an LSP with specific bandwidth reservations, and the satellite modem's QoS scheduler can map these LSPs to corresponding queuing priorities. This end-to-end QoS chain — from the CE router through the MPLS network to the satellite modem — is one of the primary advantages of MPLS over internet VPN for satellite deployments.

CIR (Committed Information Rate) and MIR (Maximum Information Rate) are critical parameters in satellite MPLS contracts. The CIR defines the guaranteed minimum bandwidth — the amount of capacity the provider commits to delivering at all times. MIR defines the burst ceiling when network capacity permits. For MPLS traffic engineering to work effectively, the CIR must be sufficient for all strict-priority and guaranteed-minimum traffic classes combined. For SLA details and how to evaluate CIR/MIR commitments, see Satellite SLA Explained.

For complete QoS implementation guidance including queuing algorithms, traffic classification, and TCP acceleration, see QoS over Satellite: Traffic Shaping.

MPLS over Satellite vs Internet VPN over Satellite

The most common alternative to MPLS over satellite is running an IPsec or SSL VPN over a standard satellite internet connection. Both approaches provide private connectivity to a remote site — but they differ significantly in architecture, management, and performance guarantees.

When MPLS wins: Regulated industries requiring provable traffic isolation (banking, government, healthcare). Multi-site WANs where consistent QoS across all sites — including satellite-connected ones — is a business requirement. Deployments where voice and video quality over satellite must meet specific SLA targets. Organizations that want to offload routing and path management to a provider rather than managing VPN tunnels themselves.

When VPN wins: Cost-sensitive deployments where the managed-service premium of MPLS cannot be justified. Single-site or small-scale deployments where the overhead of MPLS is unnecessary. Situations where best-effort QoS on the satellite segment is acceptable — for example, when the remote site only runs latency-tolerant applications like email and file sync. Organizations with strong in-house networking teams that prefer to manage their own VPN infrastructure.

Real-World Trade-offs

Cost vs Control

MPLS managed services cost more than commodity internet with VPN, but they offload significant operational complexity. The provider manages CE router configuration, routing adjacencies, path engineering, and troubleshooting. For organizations with limited IT staff at remote sites — which describes most satellite-connected locations — this operational simplification can justify the cost premium. Conversely, organizations with centralized network operations centers and SD-WAN expertise may prefer the control and cost savings of managing their own VPN overlay.

Shared vs Dedicated Capacity

Most satellite MPLS services run over shared transponder capacity with a CIR/MIR model. The enterprise gets a guaranteed minimum (CIR) and can burst above it when capacity is available (MIR). Dedicated transponder capacity — where the enterprise has exclusive use of a defined bandwidth allocation — costs 3–5x more but eliminates contention entirely. The choice depends on whether the application mix can tolerate occasional congestion during peak usage periods.

SLA Considerations

An MPLS provider can offer an end-to-end SLA that covers the satellite segment, the teleport, the MPLS backbone, and potentially the far-end terrestrial tail. This single-provider accountability is valuable for enterprises that need contractual performance guarantees. With internet VPN over satellite, the SLA covers only the satellite segment — the enterprise has no performance guarantee for the internet path between the satellite ISP's PoP and the corporate network. For detailed SLA evaluation guidance, see Satellite SLA Explained.

Backup Path Integration

Satellite MPLS as a backup for terrestrial MPLS is a well-established pattern. BGP route preference (local preference, MED, or AS path prepending) controls which path is active. When the terrestrial circuit fails, BGP converges to the satellite path — typically within 30–90 seconds depending on timer configuration. The site stays on the WAN with the same IP addressing and routing; only latency and bandwidth change. Tuning BGP timers (BFD for fast detection, aggressive keepalive intervals) reduces convergence time but increases control-plane overhead on the satellite link.

Hybrid WAN and SD-WAN

Modern enterprise WANs increasingly use SD-WAN overlays that abstract the underlying transport. In this model, satellite MPLS is one transport option alongside terrestrial broadband, dedicated fiber, and cellular. The SD-WAN controller makes path decisions based on application requirements and real-time link performance. Satellite MPLS provides the guaranteed-performance transport for critical applications, while cheaper internet paths carry best-effort traffic. This hybrid approach optimizes both cost and performance across the entire WAN.

Common Misunderstandings

"MPLS automatically means low latency." MPLS is a forwarding mechanism, not a physics override. Label switching determines how packets traverse the provider network — it does not reduce propagation delay. A GEO satellite link has approximately 600 ms round-trip latency regardless of whether it carries MPLS, IP, or any other protocol. Choosing MPLS for satellite connectivity buys traffic engineering and isolation, not lower latency.

"Private WAN design replaces proper traffic engineering." Label-based isolation means traffic from different VPNs does not mix — but all VPNs share the same satellite bandwidth. Without QoS classification and bandwidth management on the satellite segment, a bulk file transfer in one VRF can saturate the link and starve voice traffic in another VRF. MPLS segmentation and satellite QoS are complementary, not substitutes.

"Satellite MPLS bandwidth is the same as terrestrial." Typical satellite CIR ranges from 1–10 Mbps for enterprise sites, compared to 100+ Mbps for terrestrial MPLS circuits. Applications and traffic patterns must be designed accordingly — WAN optimization, local caching, and protocol optimization are not optional on satellite links, they are essential. Traffic that works fine over a 100 Mbps terrestrial MPLS circuit may overwhelm a 5 Mbps satellite link without optimization.

"MPLS over satellite is always better than VPN." MPLS provides superior traffic engineering and provider-managed operations, but at higher cost and complexity. For a single remote site running only email and file sync, the managed-service overhead of MPLS may not be justified. The right choice depends on the number of sites, application requirements, regulatory constraints, and whether the enterprise values provider-managed operations or prefers self-managed infrastructure.

Frequently Asked Questions

Can MPLS run over satellite? Yes. MPLS is a Layer 2.5/3 forwarding technology that operates over any Layer 2 transport medium. The satellite modem presents an Ethernet or serial interface to the CE router — MPLS treats it identically to a terrestrial circuit. No protocol modifications are required.

Is MPLS over satellite suitable for enterprise applications? Yes, for latency-tolerant applications. ERP, CRM, email, file sharing, database queries, and SCADA all work well over satellite MPLS. Real-time voice is manageable with QoS but noticeable. Video conferencing works with degraded interactivity. Applications with sub-100 ms latency requirements are not suitable for GEO satellite regardless of the WAN technology used.

How is MPLS over satellite different from internet VPN? MPLS provides provider-enforced traffic isolation, end-to-end QoS guarantees, and managed routing. Internet VPN provides encryption-based privacy over best-effort internet connectivity. MPLS costs more but offloads routing management and delivers predictable performance. VPN costs less but puts the enterprise in charge of tunnel management and offers no QoS guarantees on the satellite segment.

What applications work well over satellite MPLS? Transactional and asynchronous applications perform best: ERP systems, database queries, email, file synchronization, SCADA polling, point-of-sale transactions, and bulk data transfer. These applications tolerate the 600 ms GEO round-trip without significant user impact because they do not depend on real-time interactivity.

Does MPLS reduce satellite latency? No. MPLS determines how packets are forwarded through the provider network using labels. It does not change propagation delay, which is a function of distance and the speed of light. GEO satellite latency is approximately 600 ms round-trip regardless of the overlay protocol.

How much bandwidth can MPLS over satellite provide? Typical enterprise satellite MPLS services offer CIR ranging from 512 Kbps to 20 Mbps, with MIR (burst) up to 50 Mbps or more depending on the service plan and transponder capacity. This is significantly less than terrestrial MPLS (which commonly starts at 100 Mbps), so WAN optimization and traffic engineering are essential.

Can satellite MPLS serve as a backup for terrestrial MPLS? Yes. This is one of the most common deployment patterns. BGP route preference controls active path selection. When the terrestrial circuit fails, BGP converges to the satellite path within 30–90 seconds. The site maintains the same IP addressing and WAN connectivity — only latency and bandwidth characteristics change.

Is SD-WAN compatible with MPLS over satellite? Yes. SD-WAN treats satellite MPLS as one transport option alongside terrestrial broadband, fiber, and cellular. The SD-WAN controller selects the optimal path for each application based on real-time link performance. Satellite MPLS typically carries critical traffic (voice, SCADA, transactional) while cheaper internet paths handle best-effort traffic.

Key Takeaways

• MPLS over satellite extends enterprise WAN to remote sites by using the satellite link as the last-mile transport — the CE/PE routing model works identically to terrestrial deployments.
• Satellite is the transport layer — MPLS runs over it the same way it runs over fiber or microwave, with no protocol modifications required.
• GEO latency (~600 ms RTT) applies regardless of protocol — MPLS does not reduce propagation delay, so application selection and WAN optimization are critical.
• QoS is essential, not optional — satellite bandwidth is expensive and shared, making traffic classification and priority queuing mandatory for acceptable application performance.
• MPLS vs VPN is a cost-control trade-off — MPLS provides superior traffic engineering and provider management at higher cost; VPN provides adequate privacy at lower cost with more self-management.
• Backup WAN is a proven pattern — satellite MPLS as a secondary path for terrestrial MPLS, with BGP-controlled failover, protects against single points of failure.
• Hybrid WAN with SD-WAN is the modern approach — combining satellite MPLS for critical traffic with cheaper internet transports for best-effort traffic optimizes both cost and performance.

Related Articles

• Enterprise Satellite Internet Guide
• Satellite Backhaul Explained
• QoS over Satellite: Traffic Shaping
• Satellite Latency Comparison
• SCADA over Satellite
• Satellite SLA Explained
• Satellite Network Topology