CCNP ENCOR OSPF Configuration and Verification: Multi-Area Normal Areas, Summarization, Filtering, and Adjacency Troubleshooting

Joe Edward Franzen -

1. Why this OSPF topic matters for ENCOR

For CCNP ENCOR, OSPF isn’t just one of those memorize-the-definition-and-move-on topics. You’re expected to configure it, verify it, read the outputs, and figure out why a route showed up—or didn’t. In the real world, most OSPF problems I run into tend to fall into four pretty predictable buckets: the interface isn’t actually in OSPF, the neighbor relationship never comes up cleanly, the LSDB isn’t what I expected, or the route just never shows up in the routing table. And honestly, that same breakdown is usually the quickest way to work through exam questions too.

So anyway, this article stays tightly focused on OSPFv2 in the kind of Cisco IOS XE enterprise designs I’ve worked with over and over: single-area and multi-area normal areas, passive interfaces, broadcast and point-to-point behavior, ABR summarization, and just enough inter-area filtering awareness to keep you out of trouble. OSPFv3, NSSA, and redistribution are only there for recognition here, not as the main event.

Here’s the base topology I’m using so the examples stay consistent: R1 and R2 share an Ethernet segment in Area 0. R2 is the ABR, and it reaches R3 over a routed link in Area 10. R3 also has a user LAN that needs to be advertised into OSPF, but it absolutely shouldn’t be trying to form neighbors there. Where useful, R4 can be added on the Area 0 Ethernet to demonstrate DR/BDR and DROTHER behavior.

2. Before we touch the CLI, let’s anchor the core OSPF concepts and what it takes to form adjacency.

OSPF is a link-state IGP, which means routers aren’t just swapping destination routes back and forth—they’re sharing topology information so everybody can build the same picture of the network. Routers exchange that topology data, build a link-state database, or LSDB, for each area, and then run SPF to figure out the best paths. And this part’s really important: the LSDB isn’t the routing table, and the routing table still isn’t the forwarding table. That distinction matters. A route can absolutely be present in the LSDB and still not make it into the RIB if a lower-administrative-distance route already exists, the next hop can’t be resolved, or some other path wins the selection process. By default, OSPF uses an administrative distance of 110, so that’s the number I keep in the back of my mind whenever I’m checking route selection.

On Cisco IOS XE, the OSPF process ID is locally significant. That means neighbors don’t have to match process IDs at all. The router ID, though, does have to be unique inside the OSPF domain. Usually, the router ID selection order goes like this: a manually configured router-id first, then the highest loopback IP, and if neither of those exists, the highest active physical interface IP. If you change the router ID after OSPF is already running, the new RID usually does not take effect until you reset the process, commonly with clear ip ospf process.

OSPF cost is the metric used by SPF. By default on Cisco, cost is derived from reference bandwidth divided by interface bandwidth. The old default reference bandwidth is 100 Mbps, so Gigabit and even 10-Gigabit links can both wind up with a cost of 1 unless you tune it. In modern networks, that can hide real path differences.

R1(config)# router ospf 10

That sets the reference bandwidth to 10,000 Mbps, which is a lot more sensible in a modern enterprise network. The big rule is consistency—if you change the reference bandwidth, do it everywhere in the OSPF domain.

The packet types behind adjacency matter a lot when you’re troubleshooting: Hello finds neighbors, DBD exchanges LSDB summaries, LSR asks for missing LSAs, LSU sends the LSAs, and LSAck confirms receipt. If the problem shows up before 2-Way, I’m usually thinking hello-level mismatch first. If it falls apart in ExStart or Exchange, I start suspecting DBD negotiation problems like an MTU mismatch or duplicate router ID symptoms.

The LSA types that matter most for this scope are Type 1 Router LSAs, Type 2 Network LSAs, and Type 3 Summary LSAs. Type 1 and Type 2 stay inside the area where they belong. Type 3 LSAs are generated by ABRs to advertise reachability between areas. For route-code recognition, remember: O = intra-area, O IA = inter-area. Also recognize O E1/E2 and O N1/N2 even if externals are out of scope here.

On common Cisco defaults, broadcast and point-to-point networks typically use hello/dead timers of 10/40. Other network types can differ. For adjacency, think precisely: area ID, authentication, hello/dead timers, stub flag, and network type expectations must align. On broadcast and NBMA networks, the hello packet also carries the network mask, and that has to match too. On point-to-point links, mask mismatch isn’t treated the same way at hello time, although your IP design still needs to make operational sense.

3. Baseline lab: single-area to multi-area OSPF

Use this consistent addressing:

R1 E0/0 = 10.0.12.1/24 (Area 0)
R2 E0/0 = 10.0.12.2/24 (Area 0)
R2 E0/1 = 10.0.23.1/30 (Area 10)
R3 E0/0 = 10.0.23.2/30 (Area 10)
R3 E0/1 = 10.3.3.1/24 user LAN in Area 10, and I’d keep that interface passive.
R2 Loopback0 = 2.2.2.2/32

First, a clean single-area foundation using classic network statements:

R1(config)# router ospf 10

That loopback gives R1 something real to learn:

R1# show ip route ospf

Now let’s extend this to multi-area OSPF, with R2 acting as the ABR and R3 living in Area 10. Here interface-based OSPF is used on R3 because you need to recognize both styles:

R2(config)# router ospf 10

Healthy neighbor verification:

R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 00:00:37 10.0.12.1 Ethernet0/0 3.3.3.3 0 FULL/ - 00:00:33 10.0.23.2 Ethernet0/1

Healthy route recognition on R1 after multi-area comes up:

R1# show ip route ospf

The exam point is simple: O is intra-area, O IA is inter-area through the ABR.

4. Neighbor states, packet flow, and the failure patterns you actually need to recognize

The adjacency states go in this order: Down, Init, 2-Way, ExStart, Exchange, Loading, Full. What really matters is knowing what each state means operationally:

Down: no valid hellos seen.
Init: hello received, but your RID is not listed in the neighbor hello yet; often one-way communication.
2-Way: bidirectional hello exchange works. On broadcast networks, DROTHER-to-DROTHER can stay here normally.
ExStart: master/slave DBD negotiation begins.
Exchange: DBD packets are being exchanged.
Loading: routers request and receive missing LSAs using LSR/LSU.
Full: LSDB sync is complete for that adjacency.

State-based troubleshooting is high value for ENCOR:

Init usually suggests one-way hellos, multicast blocked, ACL issue, passive interface, or wrong network type assumptions. ExStart/Exchange often points to MTU mismatch or duplicate RID symptoms. DBD packets include MTU information, which is why MTU problems show up later than hello problems. Full but route missing means stop troubleshooting adjacency and inspect LSDB, summarization, filtering, and RIB selection.

Useful commands:

show ip ospf neighbor show ip ospf interface show ip ospf show ip ospf database show ip route ospf

If you use debug, keep it controlled. Command availability and output can vary by IOS XE release. Typical examples are:

debug ip ospf hello debug ip ospf adj undebug all

In production, prefer show commands first, use terminal monitoring carefully, and avoid broad debugging during busy change windows.

5. Now, about network types, DR/BDR behavior, and Ethernet running as point-to-point

Ethernet defaults to OSPF network type broadcast. On broadcast multiaccess networks, routers absolutely do become neighbors, but DROTHER routers only form full adjacencies with the DR and BDR, and they stay in 2-Way with the other DROTHERs. That reduces flooding complexity. DR election is based on interface priority, then router ID. A priority of 0 means that router will never win DR or BDR.

Two operational facts are easy exam traps: DR election is non-preemptive, and changing priority later does not automatically replace the current DR. To force a new election, you typically bounce the interface or reset the OSPF relationship.

Healthy broadcast verification on R1 might look like this:

Ethernet0/0 is up, line protocol is up

On a true point-to-point link, there’s no DR or BDR at all. If you’re using Ethernet but want point-to-point OSPF behavior, you’ve got to set that explicitly:

R2(config)# interface Ethernet0/1

Then verification should show Network Type POINT_TO_POINT and state POINT_TO_POINT. For exam awareness, you should still recognize NBMA and point-to-multipoint, even though they’re not the main focus here.

6. Now let’s talk about passive interfaces, authentication, and the basic security hygiene that goes with them.

A passive interface stops OSPF hellos and prevents neighbor formation on that interface, but the connected network is still advertised only if that interface is actually included in OSPF by network statement or interface configuration. That’s exactly why passive interfaces are so useful for user VLANs, loopbacks, and LANs where you want the subnet advertised but you definitely don’t want to form OSPF neighbors there.

R3(config)# router ospf 10

That default-passive pattern is excellent operationally, but it is also a classic trap: forget no passive-interface on a transit link and no adjacency forms.

Authentication is another basic control. If authentication mismatches, adjacency fails. On IOS XE, you should recognize simple password and MD5/message-digest style configuration:

R2(config)# interface Ethernet0/1

Verify with show ip ospf interface. From a security standpoint, authentication plus passive interfaces makes rogue adjacency on user-facing segments a lot less likely.

7. Multi-area design, summarization, and filtering reality

Area 0 is the backbone. In standard OSPF, every non-backbone area needs logical connectivity to Area 0. If the backbone isn’t physically contiguous, virtual links can be used for standards-based connectivity, but in clean enterprise designs they’re usually something I try to avoid.

ABRs maintain separate LSDBs per area and generate Type 3 LSAs between areas. Summarization for normal inter-area routes is done on the ABR with area range. Address math must be correct. For example, these four Area 10 prefixes summarize cleanly into 10.10.0.0/22:

10.10.0.010.10.0.0/24, 10.10.1.0/24, 10.10.2.0/24, and 10.10.3.0/24

R2(config)# router ospf 10

Inside Area 10, those component prefixes still exist in the local LSDB. Across the area boundary, Area 0 routers should see a Type 3 summary instead of individual specifics:

R1# show ip route ospf

The main caveat is partial failure. If at least one component route remains active, the summary can still be advertised, and traffic for a failed specific subnet may still be attracted toward the ABR. That is the real black-hole risk.

Filtering needs careful wording. In simple ENCOR study, know that OSPF filtering is more limited and more context-sensitive than many candidates expect. area filter-list prefix is an ABR feature for inter-area Type 3 filtering, and direction matters. It does not filter intra-area Type 1/2 LSAs. Platform and release behavior can vary, so it’s worth checking your own lab instead of overgeneralizing. And don’t forget that prefix-lists have an implicit deny at the end.

Direction awareness:

out filters Type 3 LSAs this ABR advertises into the specified area.
in filters inter-area Type 3 information considered from that area for advertisement decisions on the ABR.

Verification must be router-specific and area-specific: check whether the receiving router lacks the expected Type 3 LSA, and check the ABR summary database and policy configuration. Do not use the vague phrase “missing from the LSDB” without saying on which router and for which area.

8. Verification and troubleshooting workflow

Use a fixed sequence:

1. Interface and IP: verify up/up, addressing, and basic reachability.
2. OSPF participation: show ip protocols and show ip ospf interface to confirm the interface is actually in OSPF and in the correct area.
3. Neighbor state: show ip ospf neighbor to identify where adjacency stopped.
4. LSDB: show ip ospf database and, for ABR work, show ip ospf database summary.
5. RIB: show ip route ospf to see what installed.
6. Deeper checks: show ip ospf, show ip ospf border-routers, and if needed show ip cef for forwarding validation.

Three common patterns:

No neighbor: check passive interface, area mismatch, authentication, hello/dead mismatch, multicast filtering to 224.0.0.5/224.0.0.6, and whether the interface is even enabled for OSPF.

Stuck in ExStart/Exchange: check MTU first. A lab workaround exists with ip ospf mtu-ignore, but that is not the preferred production fix; align the underlying MTU.

Full adjacency but route missing: separate LSDB from RIB logic. If the relevant LSA isn’t present on the receiving router, start thinking about the area boundary, summarization, or filtering. If the LSA is there but the route still won’t install, think lower-AD competing routes, path selection, or an unresolved next hop.

Example of LSDB present but OSPF route not installed because of a competing static route:

R1(config)# ip route 10.3.3.0 255.255.255.0 10.0.12.254

That reinforces one of the most important ENCOR lessons: a healthy adjacency does not guarantee an OSPF route will appear in the RIB.

9. ENCOR review sheet and exam traps

Here are the facts I’d really make sure you know cold:

  • The OSPF process ID on Cisco is locally significant, so it doesn’t need to match between neighbors.
  • The router ID has to be unique, and if you change it, you’ll usually need to clear the OSPF process before it takes effect.
  • Broadcast Ethernet defaults to DR/BDR behavior, while point-to-point has no DR or BDR.
  • Ethernet defaults to OSPF broadcast; use ip ospf network point-to-point if you want p2p behavior on Ethernet.
  • DR election is non-preemptive.
  • Broadcast/P2P defaults are commonly hello 10, dead 40.
  • Type 1 and Type 2 LSAs stay area-local, and Type 3 LSAs are generated by ABRs for inter-area reachability.
  • O = intra-area, O IA = inter-area.
  • Passive interfaces stop hellos and neighbor formation, but still advertise the network only if OSPF includes that interface.
  • area range summarizes at the ABR; it does not remove component prefixes from the originating area LSDB.
  • Filtering in OSPF is limited and very context-sensitive, so always verify it on the exact router and area you’re working with.
  • ExStart/Exchange trouble: think MTU first.
  • Missing route: think adjacency, then LSDB, then RIB/policy.

Core commands:

router ospf <pid>
network <ip> <wildcard> area <area-id>
ip ospf <pid> area <area-id>
passive-interface default
no passive-interface <int>
area <area-id> range <prefix> <mask>
show ip ospf neighbor
show ip ospf interface
show ip ospf database
show ip route ospf
show ip protocols

Memorization anchors: 224.0.0.5 = AllSPFRouters, 224.0.0.6 = AllDRouters, Area 0 = backbone, and the neighbor state order is Down, Init, 2-Way, ExStart, Exchange, Loading, Full.

If you can look at an OSPF problem and decide whether it is interface-level, adjacency-level, LSDB-level, or RIB/policy-level, you are thinking the right way for both ENCOR and production operations.