HowToFixMe
Cisco Real World Problems

ISR 4000 OSPF NSSA Type 7 LSA not converted to Type 5: Fix

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

⚡ At a glance
BrandISR 4000
FamilyCisco Real World Problems
CategoryCisco
Guide typeProblem Fix
Skill levelIntermediate

I run a Cisco shop in Bengaluru and spend most weeks elbow-deep in ISR 4000 chassis either on Putty 0.78 over a console cable or on SecureCRT 9.4 in tabbed mode against a stack of devices in a Mumbai DC. Ospf nssa type-7 lsa not converted to type-5 at the abr is one of those issues that does not show up in CCNA labs but absolutely shows up in production at 11 pm on a Friday. I have shipped this fix on customer sites between Chennai, Hyderabad, Bengaluru, and Pune over the last three years on hardware bought through Redington, Ingram Micro, and Cisco GeM tenders. The fix below is what I trust under a maintenance window.

The short version: An ASBR inside an NSSA originates Type-7 LSAs and they reach the ABR, but the ABR does not translate them to Type-5 for the backbone, so the external prefixes never leave the area. Root cause: Only the ABR with the highest router-id in the NSSA performs the Type-7-to-Type-5 translation, and only if the P-bit is set in the Type-7 LSA. If the ASBR is using area X nssa no-redistribution, or if the NSSA option is set to nssa default-information-originate without explicit translation, the conversion never fires.. The fix involves a small number of CLI changes plus a verification pass. Total time on a clean run: 10 to 30 minutes including the soft-reset wait. If you are reading this at 7 pm because the change has to land before midnight, skip to the step-by-step section and come back for the context later.

This article gives you the working network-engineer view: what the CLI looks like on a ISR 4000, what to verify after the change, which gotchas have bitten me on real customer sites, and what the rollback looks like if it goes sideways. SmartNet 8x5xNBD on a top-of-rack ISR 4000 pair costs roughly 65,000 to 1,80,000 INR per year per pair depending on the SKU; the procedures below are all covered under that contract. If you are running the chassis without SmartNet, your TAC escalation will be paid per-incident at roughly 15,000 to 30,000 INR per case.

What you need before you start

Bench the change before you touch production. The list below is what lives on my engineering desk for any Cisco IOS XE config change:

Why this matters on a ISR 4000

Only the ABR with the highest router-id in the NSSA performs the Type-7-to-Type-5 translation, and only if the P-bit is set in the Type-7 LSA. If the ASBR is using area X nssa no-redistribution, or if the NSSA option is set to nssa default-information-originate without explicit translation, the conversion never fires.

The way this typically presents in production is that An ASBR inside an NSSA originates Type-7 LSAs and they reach the ABR, but the ABR does not translate them to Type-5 for the backbone, so the external prefixes never leave the area. The fingerprint is consistent enough that once you have seen it twice, you can rule it in or out inside five minutes of opening a console session. The reason it confuses junior engineers is that the symptom looks like a generic network problem - flapping adjacency, lost prefix, high CPU - and the actual root cause is buried in a specific config line or capability negotiation that does not show up in the headline status output.

The log signature you should expect during the failure is:

no error log per se - symptom is that show ip ospf database external in area 0 is empty even though Type-7 LSAs exist inside the NSSA

For an Indian customer running on Redington-supplied hardware with a SmartNet 8x5xNBD contract, this kind of failure typically gets to TAC within an hour of detection if the NOC is on-the-ball. TAC will ask for the show tech, the crashinfo (where applicable), and the timestamps of the relevant log entries. Have all three ready before opening the case and the resolution time drops from hours to minutes.

Step-by-step on a ISR 4000

The procedure below is what I follow during a maintenance window. Each step should complete cleanly before moving to the next; if any step does not match the expected output, stop and re-check rather than continuing forward.

  1. Confirm Type-7 LSAs exist inside the NSSA. show ip ospf database nssa-external on a router inside the area - entries should be present with P-bit set.
  2. Identify which ABR should be the translator. By default it is the ABR with the highest router-id in the NSSA. show ip ospf border-routers lists candidates.
  3. On the chosen ABR, pin translation: router ospf 1 then area 10 nssa translate type7 always. The always keyword forces translation regardless of the election outcome.
  4. Confirm Type-5 LSAs appear in area 0. show ip ospf database external on a backbone router should now list the translated prefixes with the ABR as the advertising router.
  5. Check forwarding actually works. show ip route on a backbone router should show the prefixes as O E2 with next-hop pointing to the ABR.
  6. Verify P-bit handling on the originating ASBR: the ASBR must set the P-bit, which is the default unless someone has used area 10 nssa no-summary no-redistribution, which can suppress translation.
  7. Save: write memory on every router touched.

Total wall-clock time for a clean run is typically 10 to 30 minutes including the soft-reset waits. If the change blows past that, you have either picked the wrong fix or the underlying cause is something deeper than what this article addresses.

Verification you actually trust

The change is not finished until you can prove the behaviour on the ISR 4000. Run the following commands and capture the output in your change ticket:

Then take a 30-second Wireshark 4.2 capture on the relevant interface and confirm the protocol behaviour matches the CLI counters. I keep saved Wireshark profiles for BGP, OSPF, EIGRP, and PIM - each one pre-filtered to the right protocol and DSCP class. Costs nothing to build, saves about five minutes per incident later.

If the device is registered to Cisco DNA Center / Catalyst Center 2.3.5, log into the Assurance view and verify that no new alarms have fired in the five minutes since the change. The Assurance event list usually picks up routing-protocol or hardware changes within a minute or two; missing alarms can mean the controller is out of sync, which is worth flagging in the ticket regardless.

Common gotchas on a ISR 4000

Field anecdote - what this actually looked like

Bengaluru customer had a brand-new NSSA carrying redistributed BGP routes from their colocation. Inside the area, every router saw the Type-7 prefixes fine. Outside the NSSA, in area 0, the prefixes did not appear. show ip ospf database nssa-external inside the NSSA looked clean - P-bit set, sequence number incrementing. On the ABR, show ip ospf database external self-originate was empty. The ABR was not the translator - it had a lower router-id than another ABR which had been configured but was admin-down. Once we set area 10 nssa translate type7 always on the desired translator ABR, Type-5 LSAs appeared in area 0 within 30 seconds.

The takeaway from that incident, and from the dozen-or-so similar ones I have run since, is that diagnosing this scenario is more about pattern recognition than about running every possible show command. Once you have seen the failure mode once, you can identify it inside a five-minute triage and move straight to the fix.

Rollback if the change misbehaves

Every routing-protocol or hardware change on a ISR 4000 should have a documented rollback path before you start. For the scenario covered in this article, the rollback is usually a simple negation of the new lines you just added, plus a soft-reset of the affected protocol session. The pre-change snapshot lives in tac-tracker; diff against it to confirm exactly what needs to be reverted.

If the rollback itself does not restore the previous behaviour, escalate to TAC. SmartNet 8x5xNBD on a ISR 4000 pair gives you a 4-to-8 hour response SLA on severity-2 issues, which is usually enough to get a TAC engineer engaged before the next business day. For severity-1 (production-down), expect a callback inside 30 to 60 minutes from Cisco TAC India.

The pre-change snapshot from tac-tracker is your insurance policy. If you do not have one, take one now even if you are mid-incident - having it at the end of the case will make the post-incident review easier.

Costs and licensing in India

An Indian buyer looking at a top-of-rack ISR 4000 pair plus SmartNet 8x5xNBD should budget roughly 85,000 to 2,00,000 INR per year per pair depending on the SKU. Redington and Ingram Micro carry standard pricing; GeM tenders (for government-registered orgs) typically pull 15 to 25 percent off list. SmartNet renewal is usually 12 to 18 percent of the original list price annually.

License-wise, most of the features in this article are covered by Network Advantage or Network Essentials on IOS XE platforms. Smart Licensing is required - the device must reach Cisco CSSM or an on-prem SSM satellite (about USD 2,500-4,000 to deploy on-prem SSM). Without a working call-home, licences eventually drop to Out of compliance, but the protocols and features themselves keep working - enforcement is reporting-only for routing and switching.

If you are buying second-hand through a Burrabazar broker (USD 600-1,800 per used chassis is common), be aware that SmartNet contracts cannot be transferred without Cisco's letter of relinquishment. Either buy a fresh contract at full list (USD 800-2,400 per chassis per year) or run the box self-supported and budget for downtime when it fails. ESS Bengaluru, Redington, and Anuh Pharma's IT arm in Mumbai are common channels for new and refurb gear with the paperwork done properly.

Frequently asked questions

Does this change require a maintenance window?

Yes. Even when the protocol-level change is technically non-disruptive, soft-resets and adjacency renegotiation can leak user-visible behaviour. Always run inside a planned window with a backup-on-call assigned and a rollback path documented.

How long should the recovery take?

For most cases covered in this article, allow 15 to 45 minutes the first time you walk through it. Repeat incidents are usually under 10 minutes once you recognise the pattern.

Will this exact procedure work on every ISR 4000 model?

The procedure reflects current ISR 4000 behaviour on IOS XE 17.6 through 17.12. CLI syntax has been stable across these trains; if you are on an older release, verify against the platform release notes before pasting.

Does SmartNet cover this kind of operational fix on a ISR 4000?

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

Is the procedure safe to run in production?

Inside a maintenance window with a clean pre-change snapshot in tac-tracker, yes. Outside a window, no - even a clean change has a non-zero chance of triggering a follow-on adjacency or hardware behaviour you did not predict.

Does this affect my ISR 4000 warranty?

Standard CLI configuration and official IOS XE upgrades do not affect warranty. Opening sealed hardware components, using third-party transceivers without Cisco approval, or running unsupported software can void warranty - check before going further.

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

References