Configuring and Verifying Simple OSPF Environments for CCNP 350-401 ENCOR: Multi-Area Design, Summarization, Filtering, and Troubleshooting in Cisco IOS XE

Configuring and Verifying Simple OSPF Environments for CCNP 350-401 ENCOR: Multi-Area Design, Summarization, Filtering, and Troubleshooting in Cisco IOS XE

1. Introduction and ENCOR scope

For CCNP 350-401 ENCOR, when I say “simple OSPF,” I’m talking about the kind of OSPFv2 you actually run in production on Cisco IOS XE — multiple normal areas, Area 0 as the backbone, ABRs, summarization, filtering, passive interfaces, and the kind of verification that tells you what’s really going on. And just to be clear, that doesn’t mean CCNA-level single-area basics and nothing more. This article stays focused on normal-area enterprise design. Stub, totally stubby, NSSA, and external route policy are related topics, but not the main target here. Virtual links exist as an Area 0 continuity exception, but they are generally avoided and are out of scope beyond awareness.

2. OSPF refresher at CCNP depth

OSPF is a link-state protocol, really no way around that. Basically, routers form neighbors, synchronize the LSDB, run SPF per area, and then drop the best routes into the RIB. That sequence matters. LSDB synchronization is not the same as SPF calculation, and SPF calculation is not the same as route installation.

An internal router has all OSPF interfaces in one area. A backbone router has at least one interface in Area 0. In standard enterprise design, an ABR has at least one interface in Area 0 and at least one interface in a non-backbone area. ABRs maintain separate LSDB views per area and generate Type 3 summary LSAs between areas. That is the key to multi-area scale: intra-area topology stays local, while inter-area reachability is advertised in summarized form where possible.

Route codes matter. O means an intra-area OSPF route. O IA means an inter-area OSPF route, including summarized inter-area routes. If you read those route codes wrong, you’ll read the topology wrong too — and that’s how people chase the wrong problem for an hour.

For this topic, you really need to know Type 1 router LSAs, Type 2 network LSAs, and Type 3 summary LSAs cold. Type 2 LSAs are generated by the DR on broadcast and NBMA multiaccess networks. ABRs generate Type 3 LSAs to tell other areas what’s reachable across area boundaries. And keep in mind that on Cisco IOS and IOS XE, the OSPF process ID is only locally meaningful, so your neighbors don’t have to match it.

3. Reference topology and addressing plan

Use this four-router lab model:

R1: ABR between Area 0 and Area 2
G0/0/0 to R2 uses 10.0.0.0/30 in Area 0.
G0/0/1 to R4 uses 10.0.0.4/30 in Area 2.

R2: ABR between Area 0 and Area 1
G0/0/0 to R1 uses 10.0.0.0/30 in Area 0.
G0/0/1 to R3 uses 10.0.1.0/30 in Area 1.

R3: internal router in Area 1
R3’s got four loopbacks in Area 1: 10.1.0.1/24, 10.1.1.1/24, 10.1.2.1/24, and 10.1.3.1/24. That’s the chunk I use for the Area 1 summarization example.

R4: internal router in Area 2
R4’s running two loopbacks in Area 2: 10.2.10.1/24 and 10.2.20.1/24.

Those four Area 1 prefixes — 10.1.0.0/24 through 10.1.3.0/24 — roll up neatly into 10.1.0.0/22, and that’s exactly why I chose them. That summary belongs on R2, the ABR for Area 1.

4. Neighbor formation and packet flow

The neighbor state machine is Down, Init, Two-Way, ExStart, Exchange, Loading, Full. Hellos handle discovery and keepalives. Database Description (DBD) packets are exchanged in ExStart and Exchange to compare LSDB contents. Link-State Request (LSR) packets are the neighbor’s way of saying, “I’m missing something — send it over.” Link-State Update (LSU) packets carry the missing LSAs. Link-State Acknowledgment (LSAck) packets confirm that the LSAs were received. If you know which packet type lines up with which state, troubleshooting gets a lot faster — and a lot less painful.

When I’m checking neighbor formation, I start with the Area ID, Hello and Dead timers, authentication, and basic Layer 3 reachability on the segment. Router IDs must be unique; matching router IDs are a fault. MTU is different: it does not prevent Hello discovery, but it commonly breaks adjacency during DBD exchange, leaving neighbors stuck in ExStart or Exchange.

A fast state interpretation model:

Down: no usable Hellos, interface not in OSPF, passive interface, Layer 2 or Layer 3 issue
Init: Hellos seen one way only
Two-Way: normal for some neighbors on broadcast, suspicious on point-to-point
ExStart/Exchange: DBD negotiation issue, often MTU, duplicate RID, or network-type inconsistency
Loading: LSR and LSU synchronization incomplete
Full: LSDB synchronized for that adjacency

5. Broadcast vs point-to-point behavior

On IOS XE, Ethernet defaults to OSPF broadcast network type. That means DR and BDR election occurs, Type 2 LSAs are created, and DROTHER routers may remain in 2WAY/DROTHER with each other while being Full with the DR and BDR. That is normal.

On point-to-point links, there is no DR and BDR election and adjacency normally reaches FULL/- between the two routers. On routed Ethernet links that only connect two routers, I’ll often force point-to-point behavior:

On GigabitEthernet0/0/0, I’d configure it like this:
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

Use that carefully. Both ends should be designed consistently, because changing network type changes expected neighbor behavior and LSA representation.

DR and BDR election rules matter for ENCOR. Highest OSPF interface priority wins; highest router ID is the tiebreaker. Election is non-preemptive, so a better candidate arriving later does not automatically take over. To influence election:

On GigabitEthernet0/0/0, I’d configure it like this:
ip ospf priority 200

6. IOS XE configuration patterns and complete sample

You should know both configuration models: network statements under the OSPF process and interface-based OSPF enablement. Interface-based configuration is often easier to audit, but both are valid.

R1

router ospf 10
router-id 1.1.1.1
passive-interface default
no passive-On GigabitEthernet0/0/0, I’d configure it like this:
no passive-Now, over on GigabitEthernet0/0/1, this is the other routed side:

On GigabitEthernet0/0/0, I’d configure it like this:
I’d put 10.0.0.1/30 on it, which fits that point-to-point transit link nicely.
Then I’d place that interface into OSPF process 10 in Area 0.
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

Now, over on GigabitEthernet0/0/1, this is the other routed side:
I’d assign 10.0.0.5/30 to that link.
Then I place it in OSPF process 10, but in Area 2 this time.
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

R2

router ospf 10
I’d set the router ID manually to 2.2.2.2. Honestly, that saves you from a lot of annoying surprises later.
passive-interface default
no passive-On GigabitEthernet0/0/0, I’d configure it like this:
no passive-Now, over on GigabitEthernet0/0/1, this is the other routed side:
On the ABR, I’d summarize Area 1 as 10.1.0.0/22 with the standard Area 1 range command.

On GigabitEthernet0/0/0, I’d configure it like this:
I’d address that link as 10.0.0.2/30.
Then I’d place that interface into OSPF process 10 in Area 0.
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

Now, over on GigabitEthernet0/0/1, this is the other routed side:
I’m assigning 10.0.1.1/30 there.
Then I’d place that interface into Area 1 under OSPF process 10.
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

R3

router ospf 10
router-id 3.3.3.3
passive-interface default
no passive-On GigabitEthernet0/0/0, I’d configure it like this:

On GigabitEthernet0/0/0, I’d configure it like this:
That side gets 10.0.1.2/30.
Then I’d place that interface into Area 1 under OSPF process 10.
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

interface Loopback0
I’m assigning 10.1.0.1/24 to the first Area 1 loopback.
Then I’d place that interface into Area 1 under OSPF process 10.

interface Loopback1
The second loopback gets 10.1.1.1/24.
Then I’d place that interface into Area 1 under OSPF process 10.

interface Loopback2
The third loopback is 10.1.2.1/24.
Then I’d place that interface into Area 1 under OSPF process 10.

interface Loopback3
The fourth loopback is 10.1.3.1/24.
Then I’d place that interface into Area 1 under OSPF process 10.

R4

router ospf 10
I’d pin the router ID to 4.4.4.4 so I’m not relying on whatever address the router feels like choosing today.
passive-interface default
no passive-On GigabitEthernet0/0/0, I’d configure it like this:

On GigabitEthernet0/0/0, I’d configure it like this:
I’d address it as 10.0.0.6/30.
Then I place it in OSPF process 10, but in Area 2 this time.
I’m forcing this link to behave like a point-to-point OSPF link, which is what I want on a two-router routed segment.

interface Loopback10
iThe first Area 2 loopback gets 10.2.10.1/24.
Then I place it in OSPF process 10, but in Area 2 this time.

interface Loopback20
The second Area 2 loopback is 10.2.20.1/24.
Then I place it in OSPF process 10, but in Area 2 this time.

Manual router IDs are best practice. If you change router-id, the new RID usually does not take effect until you reset the OSPF process or reload. In production, be careful with clear ip ospf process; it is disruptive because it tears down adjacencies.

7. Passive interfaces, authentication, and cost

Passive interface is configured under the OSPF process, not with the invalid interface-level syntax sometimes shown in bad examples. Passive stops Hellos and adjacency formation on that interface, but the connected subnet is still advertised if the interface is in OSPF.

router ospf 10
passive-interface default
no passive-On GigabitEthernet0/0/0, I’d configure it like this:
passive-interface Loopback0

Passive interface reduces adjacency exposure on access-facing links, but it is not authentication. For active transit links, use authentication where appropriate. A very typical OSPFv2 MD5 configuration on IOS XE looks something like this:

On GigabitEthernet0/0/0, I’d configure it like this:
This tells OSPF to use message-digest authentication on that interface.
Then I’d set key 1 with an MD5 secret — CCNP-OSPF in this example.

Authentication mismatch typically prevents proper adjacency formation even when basic IP connectivity is fine. Verify with show ip ospf interface and, if needed, cautious use of debug ip ospf hello or debug ip ospf adj.

Also remember cost. If traffic is taking the wrong path, OSPF metric is often the reason. You can influence it directly:

On GigabitEthernet0/0/0, I’d configure it like this:
ip ospf cost 50

8. Summarization and filtering done correctly

Inter-area summarization on normal areas is configured on the ABR with area <id> range. It summarizes Type 3 LSAs leaving that area; it does not change the detailed intra-area LSAs inside the source area.

router ospf 10
On the ABR, I’d summarize Area 1 as 10.1.0.0/22 with the standard Area 1 range command.

The summary can be originated when one or more matching component routes exist. That’s useful, but it’s also why an overly broad summary can black-hole traffic for destinations that look covered by the summary but aren’t actually reachable.

Before summarization, an Area 0 router may see four O IA routes for 10.1.0.0/24 through 10.1.3.0/24. After summarization, it should see one O IA 10.1.0.0/22. In the LSDB, check show ip ospf database summary to confirm that the ABR is generating the Type 3 summary LSA.

Filtering needs precision. OSPF does not behave like a distance-vector protocol where you casually “filter routes” and assume the flooding model changes the same way. Three different ideas matter:

ABR inter-area filtering: controls Type 3 summaries between areas
Redistribution and external policy: controls external routes, largely outside this article’s scope
Distribute-list in OSPF: often affects local RIB installation, not LSDB flooding

If I wanted to filter things on the ABR, I’d be specific about it — for example, suppressing 10.1.2.0/24 from Area 1 toward the other areas while still allowing the rest of the area’s reachability through.

First I’d deny 10.1.2.0/24 in the prefix list.
Then I’d permit everything else so I don’t accidentally block more than I meant to.
router ospf 10
area 1 filter-list prefix AREA1-BLOCK out

On Cisco ABRs, out means filter Type 3 LSAs generated from that area toward other areas. in means filter Type 3 LSAs being advertised into that area. Verify direction carefully. If you instead use a distribute-list and the route disappears from show ip route ospf but the LSA remains in show ip ospf database, you changed local installation, not domain-wide advertisement.

9. Verification workflow and sample outputs

Use a deterministic workflow: interface participation, neighbor state, network type, LSDB, RIB, then policy effects.

Process and interface checks
show ip ospf
show ip ospf interface brief (common on IOS XE, but output availability can vary by platform and release)
show ip protocols

Neighbor checks
show ip ospf neighbor

Healthy point-to-point example:

Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/- 00:00:33 10.0.0.2 Gi0/0/0

Interface detail
show ip ospf On GigabitEthernet0/0/0, I’d configure it like this:

What I’m looking for in that output is the area, the network type, the hello and dead timers, cost, authentication state, whether the interface is passive, and the DR/BDR information.

LSDB checks
show ip ospf database router for Type 1
show ip ospf database network for Type 2
show ip ospf database summary for Type 3

Route-table checks
show ip route ospf

Expected inter-area summary example:

O IA 10.1.0.0/22 [110/20] via 10.0.0.2, GigabitEthernet0/0/0 is exactly what I’d expect to see after summarization kicks in.

If the neighbor is Full but the route still isn’t showing up, I compare the LSDB to the RIB first, and then I go straight to filtering or summarization. That’s usually where the answer lives. If the route is present but forwarding fails, confirm next-hop resolution and data-plane behavior with tools such as show ip cef.

10. High-yield troubleshooting cases

Case 1: Neighbor stuck in Init
Evidence: Hellos are arriving, but your RID is not listed back. Common causes: one-way communication, multicast blocked, wrong subnet on shared media, passive interface on one side. Commands: show ip ospf neighbor, show ip ospf interface, interface and Layer 2 checks.

Case 2: Neighbor stuck in ExStart or Exchange
Evidence: discovery worked, DBD exchange did not. The usual culprits are an MTU mismatch, a duplicate router ID, or a network-type mismatch. OSPF likes consistency more than people like to admit. Commands: show ip ospf neighbor, show interface, show ip ospf interface. A temporary workaround such as ip ospf mtu-ignore exists, but fixing the real MTU mismatch is better.

Case 3: Full adjacency but expected route missing
Evidence: neighbors are healthy, but route is absent from show ip route ospf. Common causes: ABR filter-list, distribute-list affecting local RIB, summary configured on wrong router, area mismatch elsewhere in the path. Commands: show ip ospf database summary, show ip route ospf, show running-config | section router ospf.

Case 4: Broadcast segment shows Two-Way
Evidence: 2WAY/DROTHER between two non-DR routers. Cause: normal on broadcast multiaccess. Verify with show ip ospf interface and confirm DR and BDR roles before declaring an outage.

Case 5: Duplicate router ID
Evidence: unstable adjacencies, odd LSDB behavior, system log or debug complaints. Fix: assign unique RIDs and reset the process during a maintenance window.

11. ENCOR rapid review and exam traps

Know these cold for exam day: neighbor states, O vs O IA, ABR role, Type 1, 2, and 3 LSAs, broadcast vs point-to-point behavior, DR and BDR election rules, passive-interface behavior, ABR summarization with area range, and the difference between LSDB visibility and RIB installation.

Common traps:

Two-Way on broadcast mistaken for failure
Passive interface mistaken for route suppression
Summary configured on an internal router instead of an ABR
MTU mismatch mistaken for Hello mismatch
Duplicate RID overlooked
Distribute-list assumed to remove LSAs from the domain
DR election assumed to be preemptive

A good memory workflow is: interface - neighbor - LSDB - RIB - policy. If you can follow that sequence under pressure, you can usually solve both exam questions and real IOS XE OSPF incidents without guessing.