MPLS vs. SD-WAN

MPLS (Multiprotocol Label Switching) is a high-performance networking technique that directs data from one node to the next based on short path labels rather than long network addresses.

Think of traditional IP routing like a traveler who has to stop at every intersection to look at a map and decide which way to go. MPLS is like a traveler with a pre-printed ticket; at every stop, the conductor just looks at the ticket and points them to the next train immediately.

How MPLS Works

In a standard network, every router performs an independent “lookup” of the destination IP address to decide where to send a packet. This is time-consuming. MPLS streamlines this process:

1. Labeling: When a packet enters the MPLS network, the first router (the Label Edge Router) attaches a label to it.
2. Forwarding: Internal routers (called Label Switch Routers) only look at that label.⁵ They don’t care about the IP address or what’s inside the packet.
3. Pathing: The packet follows a pre-defined “Label Switched Path” (LSP) across the network.
4. Removal: When the packet leaves the MPLS network, the last router strips the label and sends the original IP packet to its final destination.

Why is it Useful?

While newer technologies like SD-WAN are popular, MPLS remains a “gold standard” for enterprise connectivity for several reasons:

1. Quality of Service (QoS)

MPLS is famous for its ability to prioritize traffic. You can “tag” specific types of data—like a Zoom call or a VoIP phone system—to ensure they always take the fastest, least congested path.¹⁰ This prevents your voice calls from “lagging” even if someone else on the network is downloading a massive file.

2. Predictable Performance

Because the paths are pre-defined, the latency (delay) is extremely consistent. This is vital for “mission-critical” applications like financial trading or real-time remote machinery where even a millisecond of jitter can cause problems.

3. Reliability & SLAs

MPLS is usually a private service provided by a single carrier. This allows the provider to offer a Service Level Agreement (SLA) that guarantees 99.9% uptime and specific speeds. Standard internet (like your home Wi-Fi) is “best effort,” meaning if the neighborhood gets congested, your speed just drops.

4. Privacy and Security

Since MPLS traffic travels over a private provider backbone rather than the public internet, it is inherently more secure against external hacking or “snooping.” It acts like a private tunnel between your office buildings.

MPLS vs. SD-WAN: The 2026 Context

Today, many companies use a Hybrid WAN approach. They keep MPLS for their most sensitive, real-time data (like voice and video) but use cheaper SD-WAN (broadband internet) for everyday tasks like email and web browsing.

One of the biggest advantages of SD-WAN is that it gives you the choice of who controls it.

Unlike MPLS, which is almost always “ISP-controlled” (you pay a carrier like AT&T or Verizon to manage the entire circuit), SD-WAN can be managed in three different ways:

1. DIY (Do It Yourself)

In this model, you own the control.

• The Setup: You buy SD-WAN hardware (like Huawei) and plug it into any internet connection you want (Starlink, local cable, or fiber).
• Who Controls It? Your internal IT team. You log into a central dashboard to set your own rules—for example, “Send all Zoom traffic over the fastest link.”
• The Benefit: Total freedom. You can fire your ISP tomorrow, switch to a new one, and your SD-WAN setup stays exactly the same.

2. Managed SD-WAN (ISP/Provider Controlled)

This is much more like the traditional MPLS experience.

• The Setup: You pay an ISP or a Managed Service Provider (MSP) to handle everything. They provide the hardware, the internet links, and the configuration.
• Who Controls It? The Provider. If you want to change a rule or add a new office branch, you usually have to submit a “support ticket” for them to do it.
• The Benefit: “Hands-off.” It’s great for companies with small IT teams who don’t want to worry about the technical details.

3. Co-Managed (The Middle Ground)

This is a popular “hybrid” model in 2026.

• The Setup: The ISP provides the heavy-duty infrastructure and monitoring.
• Who Controls It? Both. The ISP keeps the “pipes” running, but they give you a login to the dashboard so you can change your own security policies or app priorities in real-time.

Comparison at a Glance

Why this matters:

The reason people love SD-WAN is Carrier Independence. In an MPLS world, the ISP “owns” the path. In an SD-WAN world, the software “owns” the path, and it doesn’t care whose internet it’s using. If one ISP goes down, the SD-WAN software just shifts your data to a backup ISP (like a 5G SIM card) in milliseconds without the ISP even knowing.

Building a DIY SD-WAN is essentially an exercise in “Overlay Networking.” Since there is no single “SD-WAN protocol,” you have to combine several standard protocols to handle three distinct jobs: Tunneling (the road), Routing (the map), and Security (the gatekeeper).

If you were building this yourself today using open-source tools (like pfSense, VyOS, or OpenWrt), these are the specific protocols you would use:

1. Tunneling Protocols (The “Road”)

These protocols wrap your data packets in a “wrapper” so they can travel across the public internet as if they were on a private wire.

• IPsec: The industry standard for encrypted tunnels. It’s robust but can be complex to configure manually across many sites.
• WireGuard: The modern favorite for DIY setups. It is much faster and simpler than IPsec and is extremely lightweight, making it ideal for high-speed SD-WAN overlays.
• GRE (Generic Routing Encapsulation): A simple “wrapper” that allows you to send routing updates (like OSPF/BGP) over a connection. It doesn’t have security by itself, so it’s usually paired with IPsec (GRE-over-IPsec).

2. Routing Protocols (The “Map”)

The “SD” in SD-WAN comes from how the network makes decisions. You need protocols that can tell the routers which paths are healthy.

• BGP (Border Gateway Protocol): The most common choice for SD-WAN. It allows different branches to tell the “Central Hub” which local networks they have.
• BFD (Bidirectional Forwarding Detection): This is a “heartbeat” protocol. It sends tiny packets back and forth every few milliseconds. If the packets stop arriving, BFD tells the router to instantly switch to the backup link (like a 5G failover).
• OSPF: Often used inside a single large campus to keep all the local switches and routers in sync.

3. Control & Orchestration (The “Brain”)

In a DIY setup, you lack a fancy vendor dashboard, so you use automation protocols to push configurations to all your branches at once.

• NETCONF / RESTCONF: These allow you to send configuration changes to your routers using code (XML or JSON) instead of typing commands manually.
• SSH + Ansible/Terraform: Many DIY engineers use Ansible to script the rollout. You write a “Playbook” that says “Create a WireGuard tunnel on all 10 branch routers,” and Ansible executes it via SSH.

4. Quality of Service (The “Traffic Cop”)

To make sure a YouTube video doesn’t ruin a CEO’s Zoom call, you use:

• DSCP (Differentiated Services Code Point): You “tag” packets at the edge. Voice gets a “High Priority” tag, and email gets a “Best Effort” tag.
• App-ID / Deep Packet Inspection (DPI): Tools like nDPU or ntopng help your DIY router look inside the packet to see if it’s “Netflix” or “Salesforce” so it can apply the right rules.

Summary Table for DIY Builders

In a DIY SD-WAN, WireGuard provides the secure “tunnel,” but it is static—it doesn’t know if a link is down or if a new subnet has been added to a branch. BGP is the “brain” that sits inside that tunnel to handle the routing automatically.

Here is how you build a two-site “Hub and Spoke” setup using these two.

1. The Topology

• Site A (Hub): Public IP 1.1.1.1, Local Network 10.1.0.0/24, Tunnel IP 10.255.0.1
• Site B (Spoke): Public IP 2.2.2.2, Local Network 10.2.0.0/24, Tunnel IP 10.255.0.2

2. Step 1: WireGuard Configuration

The key trick for BGP is to set AllowedIPs = 0.0.0.0/0 (or at least the tunnel subnet) and not the specific branch subnets. We want the BGP protocol to handle the branch subnets instead.

Site A (Hub) – /etc/wireguard/wg0.conf

Ini, TOML

[Interface]
PrivateKey = <Hub_Private_Key>
Address = 10.255.0.1/30
ListenPort = 51820

[Peer]
PublicKey = <Spoke_Public_Key>
# We allow everything so BGP can route any subnet through here
AllowedIPs = 0.0.0.0/0 
Endpoint = 2.2.2.2:51820

Site B (Spoke) – /etc/wireguard/wg0.conf

Ini, TOML

[Interface]
PrivateKey = <Spoke_Private_Key>
Address = 10.255.0.2/30

[Peer]
PublicKey = <Hub_Public_Key>
AllowedIPs = 0.0.0.0/0
Endpoint = 1.1.1.1:51820
PersistentKeepalive = 25

3. Step 2: BGP Configuration (using FRRouting)

Once the tunnel is up and you can ping 10.255.0.1, you install a routing daemon like FRR (FRRouting). This is where the “SD-WAN” logic happens.

Site A (Hub) – frr.conf

Bash

router bgp 65001
  bgp router-id 10.255.0.1
  # Define the Spoke as a neighbor
  neighbor 10.255.0.2 remote-as 65002
  
  address-family ipv4 unicast
    # Advertise the local network to the Spoke
    network 10.1.0.0/24
  exit-address-family

Site B (Spoke) – frr.conf

Bash

router bgp 65002
  bgp router-id 10.255.0.2
  # Define the Hub as a neighbor
  neighbor 10.255.0.1 remote-as 65001
  
  address-family ipv4 unicast
    # Advertise the local branch network to the Hub
    network 10.2.0.0/24
  exit-address-family

4. Why this is “SD-WAN”

By combining these, you get three features that standard VPNs lack:

1. Auto-Discovery: If you add a new VLAN (e.g., 10.1.50.0/24) at the Hub, you just add one line to the Hub’s BGP config. The Spoke learns about it automatically without you touching the Spoke’s config.
2. Health Monitoring (BFD): You can add BFD (Bidirectional Forwarding Detection) to the BGP neighbor. If the WireGuard tunnel stalls for even 1 second, BGP will instantly pull the routes and try a backup link (like a second tunnel over a LTE/5G connection).
3. Path Steering: You can tell BGP to prefer “Tunnel 1” (Fiber) for office data but “Tunnel 2” (Starlink) for guest traffic.

MikroTik’s RouterOS (v7) is perfect for this because it has native support for both WireGuard and BGP. In v7, BGP was completely rewritten to be faster and more “SD-WAN friendly.”

Here is how you configure a Hub and Spoke setup.

1. Site A (The Hub)

Public IP: 1.1.1.1 | LAN: 10.1.0.0/24 | Tunnel IP: 10.255.0.1/30

Step A: WireGuard Interface

First, create the “container” for the tunnel and the peer (the Spoke).

Bash

/interface wireguard add name=wg-sdwan listen-port=51820
/interface wireguard peers add interface=wg-sdwan public-key="<SPOKE_PUBLIC_KEY>" allowed-address=0.0.0.0/0 endpoint-address=2.2.2.2 endpoint-port=51820

Step B: IP Addressing

Assign the internal tunnel IP to the WireGuard interface.

Bash

/ip address add address=10.255.0.1/30 interface=wg-sdwan

Step C: BGP (The Routing)

In v7, we create a Template first, then the Connection.

Bash

# Create the BGP Instance
/routing bgp instance add name=bgp-hub as=65001 router-id=10.255.0.1

# Create a Template (Settings for the neighbors)
/routing bgp template add name=sdwan-temp as=65001

# Add the Spoke as a Neighbor
/routing bgp connection add name=to-spoke-1 remote.address=10.255.0.2/32 .as=65002 templates=sdwan-temp listen=yes local.role=ebgp

# Advertise your local LAN
/routing table add name=main fib
/routing bgp address-family ipv4 add network=10.1.0.0/24 instance=bgp-hub

2. Site B (The Spoke)

Public IP: 2.2.2.2 | LAN: 10.2.0.0/24 | Tunnel IP: 10.255.0.2/30

Step A: WireGuard Interface

Bash

/interface wireguard add name=wg-sdwan
/interface wireguard peers add interface=wg-sdwan public-key="<HUB_PUBLIC_KEY>" allowed-address=0.0.0.0/0 endpoint-address=1.1.1.1 endpoint-port=51820 persistent-keepalive=25s

Step B: IP Addressing

Bash

/ip address add address=10.255.0.2/30 interface=wg-sdwan

Step C: BGP (The Routing)

Bash

# Create the BGP Instance
/routing bgp instance add name=bgp-spoke as=65002 router-id=10.255.0.2

# Create the Template
/routing bgp template add name=sdwan-temp as=65002

# Connect to the Hub
/routing bgp connection add name=to-hub remote.address=10.255.0.1/32 .as=65001 templates=sdwan-temp local.role=ebgp

# Advertise the Spoke LAN
/routing bgp address-family ipv4 add network=10.2.0.0/24 instance=bgp-spoke

3. Adding the “SD-WAN” Secret Sauce: BFD

If you stop here, it takes BGP about 90 seconds to realize a link is dead. To make it “SD-WAN fast” (sub-second failover), add BFD.

On both routers:

Bash

/routing bfd configuration add name=sdwan-bfd interval=200ms multiplier=3
/routing bgp connection set [find name~"to-"] bfd=sdwan-bfd

This tells the router: “Check every 200ms. If you miss 3 checks, the link is dead—kill the route immediately.”

How to Verify it’s Working

Open the Terminal in your MikroTik and run:

1. /interface/wireguard/peers/print — Check if last-handshake shows a recent time.
2. /routing/bgp/session/print — Check if the state is established.
3. /ip/route/print — You should see a route to the other site with the Db (Dynamic BGP) flag.

Don't be shellfish…

Twitter

Linkedin

Google

Facebook

Email

Diggit