How to configure OSPF totally stubby area on Catalyst Center / DNAC

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

A totally stubby area is OSPF's way of cutting noise. The ABR injects only a default route into the area. No external LSAs (type 5), no inter-area routes (type 3 either, with the no-summary keyword). For a branch with one uplink and a weak CPU, this is the cheapest LSDB you can run. I designed this for a 42-branch retail rollout out of ESS Bengaluru last year, the branch boxes were base ISR-4221 with 4 GB RAM and the full OSPF table from the core would have eaten the control plane. On Catalyst Center (DNAC), here is the working configuration.

Pre-requisites

• Catalyst Center (DNAC) with OSPF process already up. Run show ip ospf and confirm the process ID and the existing area set.
• One ABR (the device that sits between area 0 and the stubby area). On a branch box, the branch router is normally not the ABR: the WAN aggregation router is.
• All routers inside the stubby area must agree it is stubby. Mismatched stub flags trigger %OSPF-4-ERRRCV with mismatch reason 'stub area option mismatch' and the adjacency stays in EXSTART.
• Console + management VLAN reachability. If you misconfigure the area type, you may lose your remote shell when the default route disappears.
• SmartNet (₹85,000-2 lakh annually) or a Redington partner ticket, handy if you want a TAC review of the LSDB after change.

Step-by-step on Catalyst Center (DNAC)

1. Pick the area number. Pick any non-zero area. I use area 51 for branches because it's memorable and not in use anywhere else in the core.
2. Configure the ABR. Under router ospf 1: area 51 stub no-summary. The no-summary keyword is what makes it totally stubby. without it you still get type 3 LSAs.
3. Configure each internal router in the area. Under router ospf 1: area 51 stub. Internal routers do NOT need no-summary; only the ABR controls type 3 injection.
4. Place interfaces in the area. Either via the legacy network 10.51.0.0 0.0.255.255 area 51 statement, or per-interface with ip ospf 1 area 51 under the interface config.
5. Verify the LSDB shrank. show ip ospf database | inc Type-5 should return nothing on internal routers. show ip ospf database | inc Summary should show only the default route (0.0.0.0).
6. Confirm the default route landed. show ip route 0.0.0.0. You should see O*IA 0.0.0.0/0 [110/11] via .... The *IA is the marker.
7. Save and snapshot. write memory. Pull a fresh show running-config | section router ospf into your CMDB so the next on-call can read the area structure without a console session.

A deployment I shipped

The 42-branch ESS Bengaluru retail rollout used Catalyst Center (DNAC) (or its branch equivalent on smaller sites) as the WAN edge. Before we cut over to totally stubby, each branch held the full BGP-redistributed OSPF LSDB, about 3,400 prefixes: and CPU was sitting at 38% on idle. After enabling area 51 stub no-summary on the two regional ABRs and area 51 stub on every branch, the branch LSDB collapsed to about 60 entries (the local subnets plus a single default). CPU dropped to 4%. Memory footprint shrank by 380 MB per box. The change ran across two weekends, branch-by-branch, with a Redington partner engineer on-site for the first six. Total project cost was under ₹1,80,000 in labour. No SmartNet escalation needed.

How I verify the change actually works

1. show ip ospf | inc stub, area marked as stub no-summary on ABR.
2. show ip route ospf. only intra-area routes plus a default.
3. show ip ospf database | inc Type-5, empty on internal routers.
4. show processes cpu | inc OSPF: CPU should be lower than the pre-stubby baseline.

Gotchas I've eaten in production

• %OSPF-4-ERRRCV: option mismatch. One router thinks the area is normal, the other thinks stub. Make every router in the area run area 51 stub (with no-summary on the ABR only).
• Default route missing. The ABR did not generate the default. Re-verify area 51 stub no-summary on the ABR. The no-summary flag is what triggers automatic default injection.
• External routes still appear. One of your routers is running an ASBR for the area, you can't redistribute into a stub area. Move the redistribution to the backbone area.
• %SPANTREE-2-RECV_PVID_ERR on the L2 underlay. Not OSPF, but it breaks the underlying VLAN. adjacency never forms. Fix the trunk first.

Cost impact

Numbers are 2026 indicative ranges and depend on the SKU plus your reseller. Redington and Ingram Micro typically beat list by 8-14% for partner-managed renewals. GeM-tender pricing varies again, most government rate contracts include first-year SmartNet bundled into the hardware price.

Tooling I keep on the bench

• Putty 0.78 for the console session. Logging is on by default for every box I touch.
• SecureCRT 9.4 when the customer has tab-heavy sessions or needs tabbed scripting against a fleet.
• Wireshark 4.2 for any time the platform behaviour does not match the documentation. A 10-second capture answers what 30 minutes of show commands cannot.
• Cisco DNA Center / Catalyst Center for fleets above 30 devices. The compliance dashboard catches drift that an engineer never sees.
• Cisco Modeling Labs (CML 2.7) for pre-prod testing. ₹0 for personal use up to 20 nodes; commercial licence runs about ₹1.2 lakh annually.
• Ansible 2.16 for templated rollouts. The cisco.ios and cisco.nxos collections both handle the platforms in this guide.

How this interacts with other Cisco surfaces

Hardly any change on Catalyst Center (DNAC) lives alone. The features in this guide ripple into adjacent boxes: sometimes within seconds, sometimes the next morning. Here is what I trace before I close a ticket.

Catalyst Center (DNAC) compliance

If the customer runs Catalyst Center, any out-of-band CLI edit will show as compliance drift inside 15 minutes. I either pre-stage the change as a template in the Network Design workflow, or I accept the drift flag and immediately re-sync the device state. Leaving the drift unresolved means the next compliance scan re-applies the previous template and silently wipes your change.

SD-WAN policy fabric

On a fabric router under vManage / Cisco SD-WAN control, CLI edits to features the controller manages get reverted on the next template push. The right move is to apply the change via a feature template, attach a CLI add-on for what the GUI does not cover, and push from vManage. If you are testing in isolation, detach the device from vManage first.

Identity Services Engine (ISE) RADIUS sessions

When the platform you are touching also acts as a NAS for 802.1X, every config save reloads the RADIUS subsystem briefly. Active wired sessions held by ISE can reauthenticate. Schedule the change outside the 9 a.m. login spike or use aaa accounting update periodic 5 to keep stale sessions visible to ISE while the box settles.

Firepower / FTD inspection

If a Firepower NGIPS or FTD sits between the inside and outside zones, any new NAT flow needs an access-control rule allowing it. The control-plane change on the router does not automatically open the firewall. I keep a paired change request open on FMC so the rule lands in the same window.

Duo MFA for admin login

If admin logins are protected by Cisco Duo, plan for the push prompt during your change window. A Duo push that times out at the wrong moment can leave you locked out of the second box mid-change. I keep a parallel console session open before I touch any auth-related config.

Long-term monitoring I leave running

A clean change is one that still looks clean a month later. On Catalyst Center (DNAC), I leave the following hooks in place after every deployment touched by this guide.

• SNMPv3 polling on the interfaces involved, CPU, memory, input / output bps, errors. PRTG or LibreNMS both work; the customer's existing NMS is usually fine.
• Syslog forwarding to a central collector. I prefer Graylog 5.2 with a dashboard that filters on %LINEPROTO-5-UPDOWN, %SYS-5-CONFIG_I, %SPANTREE-2-RECV_PVID_ERR, %OSPF-4-ERRRCV, and any platform-specific NAT / MPLS facility codes.
• NetFlow / IPFIX at low sample rate (1 in 1,000) to the customer's flow collector. Useful for proving that the NAT pool is being used the way the design intended.
• Monthly compliance scan via Catalyst Center or a manual show running-config diff against the change baseline. Drift catches silent edits.
• Quarterly review of SmartNet entitlement. If the SmartNet contract is about to expire (₹85,000 - 2 lakh annual, set a calendar 60 days out), renewal lead time on a GeM-tender customer can be 90 days.

None of these are heavy lifts. Combined, they catch the regressions that an ad-hoc show command will not. Customers who run them rarely call us about repeat incidents on the same change.

More frequently asked questions

Can I roll back without a reload?

Yes for every topic in this guide. The no-form of each command unwinds the change in real time. Run show running-config before and after so you can diff with VSCode or notepad++ if anything looks off.

Does this break IPv6?

No. None of these features touch the IPv6 forwarding path. If you run dual-stack on Catalyst Center (DNAC), IPv6 keeps its own LSDB, its own NAT (or NPTv6) state, and its own LDP context. they share nothing with IPv4 here.

What about IOS XE Stack-Wise V1/V2 mismatch?

Mixing Stack-Wise V1 and V2 members in the same stack is unsupported and reliably breaks NAT pool ownership. Replace the older member before configuring any of these features on a stacked Catalyst.

Is this safe to run during business hours?

Read-only verification is always safe. Config changes, even the no-op-looking ones: can disturb production. I schedule a 30-minute window with the customer, capture pre-change state, run the change, verify, and stop. A Comsys Mumbai-style runbook keeps this consistent across teams.

Will SmartNet TAC help if I get stuck?

Yes. With an active SmartNet (₹85,000 - 2 lakh annually depending on SKU and tier) TAC will accept a P3 ticket and review the running-config plus the relevant show outputs. Without SmartNet you can still post on the Cisco Community forum but expect community response speed, not SLA speed.

How do I avoid this becoming legacy debt?

Document the change in CMDB. Tag it with the project name. Add the verification commands to the runbook. Add a Catalyst Center compliance policy if you run one. The engineer who picks this up in 2028 will thank you.

What I do after the change is in

Three habits keep me sane after any production config change. First, I leave the console session logged in for 15 minutes and watch the syslog buffer. Second, I run show logging | last 100 from a fresh session 24 hours later. Third, I ask the customer's NOC to confirm zero alerts during the window. The combination catches almost every regression before it becomes a Monday morning ticket.

On a Catalyst Center (DNAC)-class platform, the syslog patterns that I watch for are %LINEPROTO-5-UPDOWN on the affected interfaces, %SYS-5-CONFIG_I for unexpected re-edits, and %SPANTREE-2-RECV_PVID_ERR on the L2 underlay. If none of those show up in the next 48 hours, the change has settled.

If you came here because of a live outage, the fastest rollback is almost always the no-form of the commands above. Restore. Stabilise. Then reschedule the change for a quiet window. Production is not the time to be brave.

Related fixes

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

• How to configure OSPF totally stubby area on Catalyst 8300/8500
• How to configure OSPF totally stubby area on Catalyst 9200
• How to configure OSPF totally stubby area on Catalyst 9300
• How to configure OSPF totally stubby area on Catalyst 9400
• How to configure OSPF totally stubby area on Catalyst 9500
• How to configure OSPF totally stubby area on Catalyst 9800 WLC