3.5Configuring OSPFv2 and OSPFv3

OSPF faults fall into two broad classes: the adjacency does not form, or the adjacency is up but the expected route does not appear. The first shows up as a neighbor missing from show ip ospf neighbor or stuck in EXSTART/EXCHANGE, and the cause is almost always a parameter mismatch between the two ends. The second involves design intent—summarization, filtering, area type, or the scope of network statements. This section builds a procedure that first classifies which side the problem is on, then routes you to the right verification command by the shortest path.

3.5.1Conditions for forming an adjacency

• The values that must match for an adjacency are: the same area ID, the same hello and dead intervals, the same authentication type and key, the same stub flag (area type), the same subnet (matching mask) on broadcast networks, and compatible network types. In addition, the two routers must not share a router ID. Miss any one and the neighbor never appears in show ip ospf neighbor.
• An MTU mismatch produces a distinctive symptom: hellos are exchanged so the adjacency starts, but the DBD exchange stalls and it sits in EXSTART/EXCHANGE. If show ip ospf neighbor never reaches FULL and oscillates between those two states, first compare MTU on both ends with show interface. The workaround ip ospf mtu-ignore exists, but it only hides the root cause (an inconsistent MTU design) and should not be the permanent fix.
• Understand passive-interface precisely: it stops sending hellos on that interface so no adjacency forms, yet the interface's network continues to be advertised as long as it is covered by a network statement. It therefore correctly serves the requirement "eliminate pointless hellos and adjacency risk on a host-only LAN while still advertising that segment." The belief that "passive also stops advertising the route" is wrong.

3.5.2Network types and DR/BDR

• On a broadcast network (the Ethernet default), a DR (designated router) and BDR are elected to prevent an explosion of adjacencies, and the other routers (DROTHERs) reach FULL only with the DR and BDR. Election goes by OSPF priority (default 1; 0 means ineligible), then router ID, higher winning, and because whoever came up first stays (no preemption), adding a higher-priority router later does not automatically change the DR.
• On a point-to-point (P2P) network there is only one peer, so no DR/BDR is elected. When an Ethernet L3 link is used by just two routers, ip ospf network point-to-point removes the DR election wait for faster convergence and simplifies the adjacency design—but note that the network type must match on both ends or no adjacency forms.

3.5.3Area design, summarization, and filtering

• When creating multiple normal areas, every area must attach to the backbone (area 0); if one is physically detached, a virtual link connects it logically (not recommended as a permanent design). An ABR keeps a separate LSDB for each attached area and injects inter-area routes between them as type-3 LSAs.
• Summarization has fixed locations: inter-area summarization happens on the ABR with area <id> range <prefix>, and external summarization on the ASBR with summary-address <prefix>. Summarizing shrinks the LSDB and table and, operationally more importantly, stops flapping of individual links inside the range from propagating outward (suppressing SPF recomputation).
• As a principle, filter without breaking the LSDB. Inter-area filtering on an ABR uses area <id> filter-list prefix <name> in|out to stop the type-3 LSA from being injected at all. By contrast, distribute-list ... in only suppresses installation into the local routing table and stops neither the LSDB nor downstream advertisement—it easily creates the asymmetric state "my neighbor has the route but I do not," so do not confuse their purposes.
• OSPFv3 is the IPv6-capable version: adjacencies form using link-local addresses, and configuration is primarily per interface (ospfv3 1 ipv6 area 0). Its address-family support lets one process handle IPv4 as well. The router ID is still a 32-bit dotted-decimal value, so in an environment with no IPv4 address at all, the process will not start unless you configure router-id manually.

Suppose you add a new branch router R3 to area 1, but the OSPF adjacency with the ABR R2 never reaches FULL. show ip ospf neighbor does list the neighbor, and its state oscillates between EXSTART and EXCHANGE. This is the diagnostic fork. If the neighbor did not appear at all, it would be rejected at the hello stage, implicating a different area ID, different hello/dead intervals, an authentication mismatch, a different subnet mask, or a different network type. But here the adjacency started, which conversely proves all hello-matched values already agree. EXSTART/EXCHANGE is the stage where DBD (database description) packets are exchanged to begin LSDB synchronization, and the classic cause of stalling there is an MTU mismatch. Comparing show interface on both ends, R2's interface is 1500 bytes while R3's is 9000 from leftover jumbo-frame configuration. The large DBD packets cannot be received by the peer, so retransmissions loop and it never progresses. Adding ip ospf mtu-ignore would indeed reach FULL, but that is a partial solution that hides the symptom: with the MTU still genuinely mismatched, OSPF works while upper-layer applications that use large packets suffer a blackhole-like fault. The correct fix is to align MTU on both ends to the designed value. Once FULL is reached, a new operational issue arises: "headquarters sees 10.1.32.0/24 through 10.1.35.0/24 behind R3 individually, and every time a branch link flaps, headquarters recomputes SPF." The remedy is to summarize on the ABR, R2, with area 1 range 10.1.32.0 255.255.252.0. It matters not to confuse the summarization point with the ASBR's summary-address, which summarizes redistributed external routes (type 5/7). After summarizing, the summary route persists even as individual links inside the range bounce, so flapping does not propagate out of the area and SPF recomputation is suppressed. Finally, R3's LAN interface faces only end hosts, so you set passive-interface—but that merely stops hellos to eliminate needless adjacency formation and security exposure, and as long as the interface is covered by a network statement that LAN is still advertised. There is no need to re-add network statements out of the misconception that "making it passive also stops advertising."

3.5.4Section summary

• Adjacency failure means a hello-stage mismatch (area ID, timers, authentication, mask, network type), while stalling in EXSTART/EXCHANGE classically means an MTU mismatch
• Broadcast elects a DR/BDR (priority, then router ID, with no preemption) while P2P elects none; the network type must match on both ends
• Summarize with area range on the ABR and summary-address on the ASBR to damp flap propagation; passive-interface stops only hellos and keeps advertising the route