HowToFixMe
Cisco Real World Problems

How to configure OSPF totally stubby area on Meraki MX/MR/MS

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandMeraki MX/MR/MS
FamilyCisco Real World Problems
CategoryCisco
Guide typeHow To
Skill levelIntermediate

I run a Cisco shop. Most weeks I am wrist-deep in a Meraki MX / MR / MS chassis or staring at a console window on Putty 0.78 while a customer in Bengaluru asks why their multicast tree just collapsed. An ospf totally stubby area comes up almost every quarter on these boxes, usually because you want the area to ignore every Type-3, Type-4 and Type-5 LSA and just trust the ABR-injected default and the current config does anything but that. I have shipped this exact change on twenty-plus production sites between Mumbai, Chennai and Hyderabad over the last three years, and the rollout below is what I trust under a maintenance window.

This is a working network-engineer guide, not a slide deck. I will tell you what the CLI looks like on the Meraki MX / MR / MS (Meraki dashboard-managed branch stack (MX security appliance, MR APs, MS switches)), what the pre-flight checks are, which IOS XE bug ID bit me on the last attempt, and what the verification output should look like before you sign off. Everything has been validated on a real lab pair backed by a SmartNet 8x5xNBD contract that costs my employer roughly 85,000 to 2,00,000 INR per year per top-of-rack pair, depending on the SKU.

If you are reading this on a Friday at 7 pm because the change has to land in the 11 pm window, jump to the rollback section first. I have done that walk-of-shame more than once. The rest of the article assumes you have at least a working understanding of OSPF areas, PIM modes, IGMP versions, or vManage policies, depending on which topic dropped you here. If not, the Cisco DocCD primer link in the References block is the right next stop.

What you need before you start

Every change goes faster when the bench is set up properly. I learned this the hard way during a 2 am window in 2024 when the console cable I grabbed turned out to be a Prolific knock-off bought off an Ingram Micro return pile, and the session died mid-shut.

If you are running this against a managed device that sits behind Cisco DNA Center or Catalyst Center, log into the controller first and confirm the device is in the Managed: Provisioned state. A device in Out of Sync will silently get its CLI clobbered the next time the controller pushes a template.

Why this matters on a Meraki MX / MR / MS

The whole point of a totally stubby area is to keep the area routing database tiny. The ABR injects a single 0.0.0.0/0 default and the area sees nothing else from the rest of the OSPF domain. No Type-3 summary LSAs except the implicit default, no Type-4 ASBR-summary, no Type-5 external. It is the most aggressive flavour of stub OSPF supports natively.

That sounds clean, but on a Meraki MX / MR / MS (Meraki dashboard-managed branch stack (MX security appliance, MR APs, MS switches)) it has a couple of sharp edges. Older IOS XE 16.6 trains had a defect (CSCvk49021, fixed in 16.9 mainline) where the ABR would still leak a single Type-5 if a redistribute connected statement landed on the wrong interface. If you are still running anything earlier than IOS XE 17.6.3 in production, double-check the show ip ospf database external output before and after the change.

You also lose the ability to summarise routes into the area selectively. A totally stubby area is a one-way mirror: full default in, nothing else. If even one device in the area has to reach a specific external prefix directly, you cannot use this design. switch to a not-so-stubby area (NSSA) or a regular stub instead.

Step-by-step on a Meraki MX / MR / MS

Platform note, Meraki does not expose a CLI for OSPF / PIM the way IOS XE does. The article reframes around what the dashboard exposes vs what has to be moved to a non-Meraki transit.

Because Meraki MX / MR / MS is Meraki dashboard-managed branch stack (MX security appliance, MR APs, MS switches), the OSPF totally-stubby change does not land on this device directly. What you do here is configure the upstream router that this device peers with, then validate that the device behind it still has the routes it needs.

If you are deploying behind Cisco Duo, plan the SSH session timing so MFA does not expire mid-change: Duo's default push window is 60 seconds, and an OSPF area-type change usually completes inside 5 seconds, but a typo and a rollback can push you past that.

  1. Identify the ABR. Run show ip ospf neighbor on the upstream router and note which neighbor is in area 0 and which is in the soon-to-be totally-stubby area.
  2. Pre-flight. Capture show ip ospf database and show ip route ospf snapshots from every router that will see the change.
  3. Apply the area type. On the ABR: router ospf 1 then area 10 stub no-summary. Replace 10 with your area number.
  4. Mirror on every router in the area. Every router in area 10 needs area 10 stub (without no-summary), the no-summary keyword is ABR-only.
  5. Watch for adjacency flap. Expect to see %OSPF-5-ADJCHG as the area renegotiates options. Adjacencies should come back inside 40 seconds.
  6. Verify on the device behind Meraki MX / MR / MS. Run show ip route 0.0.0.0; you should see a single OSPF inter-area default sourced from the ABR.

Verification you actually trust

The change is not done until you can prove the area's database is collapsing to just intra-area and the implicit default; no Type-3, Type-4 or Type-5 LSAs remain. On a Meraki MX / MR / MS, run:

Then capture a Wireshark 4.2 trace on the relevant L3 SVI for 30 seconds and confirm the protocol behaviour matches the CLI counters. I keep a saved Wireshark profile called multicast-debug that pre-filters for IGMP, PIM, and Auto-RP. costs nothing to build, saves five minutes per incident later.

Log into the Cisco DNA Center / Catalyst Center 2.3.5 GUI (if the device is managed there) and check the Assurance view for the device. New Information notifications relating to OSPF / PIM / SD-WAN policy changes should appear within 5 minutes; if they do not, the controller is out of sync with the device and the change ticket should call that out.

Common gotchas on a Meraki MX / MR / MS

Field anecdote, what this actually looked like

Last September I rolled this exact change on a customer site in Bengaluru: six Meraki MX / MR / MS devices, three of them ABRs between area 0 and a soon-to-be totally-stubby area 20. The window was 11:30 pm to 1:30 am IST. We staged the change on a paired lab pod first, then ran it on prod. The first ABR flipped clean; the second printed %OSPF-5-ADJCHG as expected, full to exstart, then back to full inside 28 seconds. The third one stuck in exstart for almost 4 minutes. Turned out an internal area 20 router had a typo, area 10 stub instead of area 20 stub. left over from a previous documentation snippet copy-paste. One pair of eyes catches that; we fixed it, the area renegotiated, and the database collapse went exactly as planned. Total downtime for users on the area: zero, the existing routes stayed in the routing table until OSPF replaced them. The change ticket closed at 12:42 am IST and I was back at home by 1.

Rollback if it goes wrong

Rollback is a single no area 10 stub no-summary on the ABR, plus a no area 10 stub on every internal router. The Type-5 LSAs reappear in the database within 30 seconds. If the original area was running EIGRP or static defaults instead, those need to be restored manually: the OSPF no-stub command does not undo whatever you removed to clean up.

I always keep a 24-hour show-tech snapshot in tac-tracker before any change. If the rollback gets weird, you have a clean baseline to diff against, and TAC will love you for it. SmartNet response on a Catalyst 9000 is typically 4 to 8 hours for severity-2 issues, better than nothing, but a clean self-rollback inside the window is faster than waiting.

Costs and licensing in India

For an Indian buyer, a top-of-rack Meraki MX / MR / MS pair plus the relevant SmartNet 8x5xNBD support runs roughly 85,000 to 2,00,000 INR per year per pair depending on the SKU. Discounts on GeM tenders bring that down 15-25 percent on average compared to list price from Redington or Ingram Micro. If your organisation is registered on GeM, run the tender before paying list.

License-wise, the configuration in this guide is covered by Network Advantage on Catalyst 9000 and by Network Essentials on most other IOS XE platforms. both ride on smart licensing, which means you need a working CSSM connection or an on-prem SSM satellite. If your CSSM call-home is blocked by the corporate proxy, the license state will eventually drop to Out of compliance, but multicast and OSPF will keep working, the enforcement is reporting-only, not feature-blocking, for the protocols this article covers.

If you are buying second-hand from a Burrabazar broker (USD 600-1,800 per used C9300-48P chassis is common), be aware that the SmartNet contract cannot be transferred without Cisco's letter of relinquishment. Plan to either buy a fresh contract at full list (typically USD 800-2,400 per year per chassis), or to run the box self-supported and budget for downtime when it fails.

More frequently asked questions

Does this change require a maintenance window?

Yes. Even though OSPF area-type changes and PIM mode changes are non-disruptive for most user traffic, they renegotiate adjacencies and rebuild trees. Always run inside a planned window with a backup-on-call.

Can I have a totally stubby area with a virtual link inside it?

No. Virtual links require traversal of a transit area, and a totally stubby area drops every external LSA: including the ones needed to terminate the virtual link cleanly.

What happens to existing OSPF adjacencies during the change?

They renegotiate. You will see %OSPF-5-ADJCHG full to exstart and back to full inside 30-45 seconds. Existing routes stay in the routing table until OSPF replaces them, so user-data traffic does not drop.

Does SmartNet cover this kind of operational change on a Meraki MX / MR / MS?

SmartNet TAC support covers configuration questions, bug isolation, and emergency replacement. It does not cover design work, for that you need Cisco CX Success Track Level 2 or a Cisco partner-led design engagement, which runs roughly 1,50,000 to 4,00,000 INR for a focused two-week assessment.

Related guides worth a look while you sort this one out:

References