A real branch site — what it actually takes to connect 30 users to the rest of the company

The 30-second version

A branch is just a small office that needs to talk to your data center, your cloud, and the internet — without you having to drive there to fix things. Cisco Meraki MX is what I reach for when the answer needs to be "plug it in and it works." For 30 people in a satellite office, the alternative (Cisco ASA + manual IPSec config) is overkill and a nightmare to support.

What follows is the deployment I actually use. Names and IPs swapped for safety, but the topology is real.

Topology

                       ┌──────────────────┐
                       │   dashboard.     │  ← config lives here, not on box
                       │   meraki.com     │
                       └────────┬─────────┘
                                │ (cloud mgmt)
                                │
   [ ISP A: cable     ]─────┐   │
                            ├───[ MX84 @ branch-01 ]───┐
   [ ISP B: LTE backup ]────┘                          │
                                                       │
                              AutoVPN (dynamic mesh)   │
                                                       │
                            ┌──────────────────────────┴─┐
                            │                            │
                  [ MX @ dc-east ]              [ MX @ dc-west ]
                  (concentrator)                (concentrator)
  

What the user actually wants

The user doesn't care about any of the above. The user wants:

• Wi-Fi works
• Email works
• SAP / Salesforce / their app works
• VoIP doesn't sound like robots

Your job is to make all four of those true, simultaneously, without ever visiting the site after install.

Step 1 — Claim the appliance

Every Meraki device has a serial number on the box. Before it ships to the branch, you claim it in the dashboard:

• Dashboard → Organization → Inventory
• Click Claim → paste the serial
• Assign to your network (e.g. branch-01)

Now when someone in the branch plugs it in, it phones home over its WAN interface, downloads its config, and you're done. This is the part that feels like magic the first time you see it.

Step 2 — VLANs and DHCP

I always carve a small branch into at least three VLANs:

Voice on its own VLAN matters more than people realize. The moment users start streaming Netflix from the conference room, your voice quality tanks unless QoS marks the voice VLAN priority. Meraki handles this automatically once you tag the voice VLAN as such — it'll mark traffic with DSCP EF without you having to think about it.

Step 3 — AutoVPN (the actual point)

AutoVPN is why Meraki MX exists at branch sites. It builds an IPSec mesh automatically between every Meraki appliance in your organization. There is no crypto isakmp policy 10, no pre-shared key spreadsheet, no "did Bob update the IP after we changed ISPs?" Just:

• At each datacenter MX: Security & SD-WAN → Site-to-site VPN → Hub
• At each branch MX: Security & SD-WAN → Site-to-site VPN → Spoke → choose hubs
• Specify which subnets participate

Done. Tunnels come up in under a minute. They re-establish automatically if one ISP fails. You don't write any crypto config. Ever.

Step 4 — Dual ISP failover

Always order two circuits if budget allows. Cable + LTE is cheap and works almost everywhere. In Meraki:

• Security & SD-WAN → SD-WAN & traffic shaping
• Define each uplink, set a probe destination (I use 8.8.8.8 and the dashboard itself)
• For voice traffic specifically: Performance class = voice → prefers low-latency, low-loss path automatically

The MX measures every uplink in real time. When the primary degrades — not just fails, degrades — voice traffic moves to the backup while everything else stays on the primary. Users on a phone call don't notice anything.

Step 5 — Things that always go wrong

The vendor's "free Wi-Fi" requirement

Branches in malls, coworking, airports — they always require an SSID called something like Acme-Guest with a captive portal. Meraki has splash pages built in. Do not write your own. Do not deploy a separate captive portal box. The native one works.

The user who plugs their phone into the wrong port

Use Meraki's built-in Switchport profiles. Tag user-VLAN on access ports, voice-VLAN with voice tagging. If a phone moves, it still works. If a laptop ends up in a "phone only" port, it sits in the voice VLAN where it can't see anything sensitive. You're welcome.

The branch admin who unplugs things "to fix them"

Enable client tracking. When tickets come in, you can see exactly which cable was unplugged at what time. This has settled more arguments than any other Meraki feature.

What I'd add for a bigger branch

If the branch grows past ~75 users:

• Move from MX84 to MX95 or MX105 (more throughput)
• Add Meraki MS switches downstream — single dashboard for switching too
• If they have on-prem servers (rare these days), drop a Meraki MR access point on its own SSID for IoT separation
• Consider a third uplink — many sites now have fiber + cable + LTE for true diversity

What I'd never use Meraki for

Be honest with yourself: Meraki is for operationally simple network problems. If the branch needs deep packet inspection on encrypted traffic, complex BGP peering with multiple ASNs, or anything requiring full programmatic config control — drop a Palo Alto firewall behind the MX (or replace the MX entirely). I love Meraki for what it's built for. I don't pretend it's a Palo Alto.

Notes from one engineer's actual deployments. If you spot something I got wrong (or could be doing better), I'd love to hear it — drop me a line.