Start from the link and the protocol family

OSPF is a link-state routing protocol. Participating routers exchange information about the network topology and independently calculate routes using the resulting link-state database. OSPFv2 is commonly associated with IPv4 routing, while OSPFv3 supports IPv6 and can support other address families in some implementations. They have related concepts but are not interchangeable processes. A lab using OSPFv2 on IPv4 does not by itself demonstrate that IPv6 routes are being exchanged.

Before investigating OSPF, ensure the physical or logical connection works and the directly connected addresses are appropriate. An administratively down interface or a mismatched transit VLAN prevents a neighbor relationship regardless of router ID. On a point-to-point IPv4 link, verify the interface addresses and masks place the routers in a shared subnet. On IPv6, verify link-local connectivity and interface operational status. A working ping does not prove OSPF will form, but a failed local-link test narrows the problem to connectivity or filtering before the routing protocol.

Area design matters even in a single-area lab. Both neighbors must agree on the OSPF area used for their shared link, commonly area 0 in introductory topologies. A router can have OSPF enabled for another interface or area and still not send the expected hellos on the current link. Do not diagnose a neighbor solely by checking that router ospf 10 appears in the running configuration; confirm that OSPF is actually enabled on the precise interface and address family.

Follow the neighbor-state progression instead of treating every non-FULL state as failure

OSPF neighbors discover one another with Hello packets. They negotiate adjacency and exchange database information as appropriate for the network type. The displayed states can include Down, Init, 2-Way, ExStart, Exchange, Loading and Full. On a broadcast Ethernet segment, two routers that are not designated router or backup designated router may remain in a 2-Way relationship with each other by design; not every 2-Way state represents an outage. Ask whether full adjacency is expected between those particular neighbors under the segment’s DR/BDR election.

Many preventable failures involve mismatched parameters such as area, subnet, network type or Hello/Dead timing where the implementation requires alignment. Duplicate router IDs can create confusing adjacency behavior because OSPF identifies routers with 32-bit router IDs independently of interface addresses. A maximum transmission unit mismatch can stall some adjacencies during database exchange. An access list or control-plane protection rule blocking OSPF traffic may prevent expected Hellos even when ICMP works.

For troubleshooting, record the local router ID, interface, area, network type, Hello/Dead intervals and neighbor state from both ends. show ip ospf neighbor and show ip ospf interface are common IOS observations for OSPFv2. For OSPFv3, use the platform’s OSPFv3 neighbor and interface display commands; spelling and command hierarchy vary by IOS XE release. Compare the observed values rather than blindly restarting the process, which destroys useful evidence about where adjacency stopped.

Explain DR and BDR selection on broadcast networks

On a shared broadcast segment such as Ethernet, OSPF elects a designated router (DR) and backup designated router (BDR) to reduce adjacency complexity. The election considers interface priority and router ID, with platform- and event-specific behavior about when a new election occurs. The DR and BDR are roles for the multiaccess network, not global titles held by a router everywhere. A router can be the DR on one VLAN and not on another.

On point-to-point networks, no DR/BDR election is needed because the link has only two logical participants for the routing relationship. If a lab changes a physical interface from broadcast to point-to-point network type, expect a different neighbor and adjacency model. Never force the network type as a generic fix without confirming the topology and peer configuration. A correct design explains the medium and why an election is useful—or unnecessary.

An OSPF issue limited to one Ethernet segment may come from a mismatched broadcast versus point-to-point network type, an unexpected priority setting, or a router-ID conflict. Use the interface output to see the elected DR and BDR as well as local priority. The network’s routing policy may be unaffected if all relevant adjacencies and routes are correct; changing election results solely to make a diagram appear prettier can cause disruptive convergence.

Separate route origination, learning, selection and forwarding

A Full neighbor is necessary for a particular exchange but not a guarantee that every expected route is installed. The router must advertise the appropriate network or interface information, the receiver must process it, and the resulting route must be selected into its routing table. Competing connected or static routes to the same prefix can affect installation. A route may be learned in the OSPF database without appearing as the selected forwarding route. Trace the problem from the originating interface through neighbor state, database entry, local route selection and next-hop reachability.

OSPF uses cost to choose among possible paths according to its routing calculations. A link’s configured or derived cost matters, but it is not the first thing to adjust when a route is completely absent. If a remote subnet has a mismatched mask or is excluded from the enabled interfaces, changing costs will not manufacture the missing advertisement. In practical incidents, start with whether the prefix is originated at all and whether all expected peers are in the relevant area.

Passive interfaces are useful when advertising a connected network without forming an OSPF neighbor on a user-facing LAN. An accidentally passive transit interface can stop neighbors from forming while the process remains active. Conversely, sending Hellos toward ordinary endpoints offers little operational benefit and expands control-plane exposure. Document which interfaces are meant to exchange routing information and which are meant only to contribute reachability.

Add OSPFv3 for IPv6 without assuming configuration syntax is identical

OSPFv3 uses IPv6’s protocol environment, including link-local communication for neighbor relationships. It still uses router IDs represented as 32-bit values; the router ID is not simply the interface’s 128-bit IPv6 address. Single-area OSPFv3 troubleshooting should check IPv6 interface state, link-local adjacency, process/area placement, neighbor state and IPv6 routes. Two routers can share a global IPv6 prefix yet fail to exchange routing information if OSPFv3 is not enabled or the control plane is filtered.

One IOS XE configuration style enables OSPFv3 under an interface with an instruction such as ospfv3 10 ipv6 area 0; other releases and training platforms use different process or address-family models. Presenting one command sequence as universally supported would be misleading. Before practicing, check the version of the IOS XE image and its ? command help, and verify the result using a matching OSPFv3 show command. The objective is a working neighbor and route, not the memorization of one parser layout across every Cisco platform.

In a mixed lab, create an OSPFv2 adjacency for IPv4 and an OSPFv3 adjacency for IPv6 on the same routed links. Disable one process and observe that the other need not disappear. This proves the two address-family routing arrangements are distinct even though the underlying network is shared. Add an incorrect OSPFv3 router ID and observe how the protocol responds; then return it to a unique stable identity and confirm the neighbor and routing tables.

Build a verifiable single-area incident exercise

Use three routers in a triangle, with two point-to-point links and a separate Ethernet segment where DR/BDR election can be observed. Give each router a loopback prefix, advertise it and capture the route selection from another router. Remove one adjacency and check for convergence and alternative path selection. Then make a different deliberate mistake: change the area on one end, set a transit interface passive, alter a Hello interval or block OSPF control packets. Each defect should produce a different evidence pattern.

For every scenario, preserve a short incident note containing the diagram, interface addressing, OSPFv2 or v3 protocol family, relevant neighbor output and learned routes. Include a prediction before modifying the network; students learn faster when their mental model is testable. If a path fails, resist repeatedly clearing the routing process to see whether it recovers. First capture the state that distinguishes a link problem, neighbor negotiation issue and route-selection problem.

Only after the router can reach the test destination should the lab consider application behavior, ACLs and the reverse path. Routing reachability is one layer in an operational system. A packet can be delivered to a remote subnet while a stateful firewall still rejects the application flow. Being able to separate that policy fault from an OSPF fault is part of competent troubleshooting, even when only routing commands appear on a particular exam objective.

Keep v1.1 and the scheduled v2.0 blueprint separate

Current CCNA 200-301 v1.1 covers configuring and verifying single-area OSPFv2, including neighbors, point-to-point and broadcast networks, DR/BDR selection and router ID. The announced v2.0 objectives specify configuring single-area OSPFv2 for IPv4 and OSPFv3 for IPv6, and explicitly exclude neighbor authentication from the listed task. Candidates sitting v1.1 by February 2, 2027 should not treat v2.0 wording as though it replaced their current exam; later candidates should expect broader IPv6 routing work.

The CCNA 200-301 exam page provides the canonical exam-level connection, and the Cisco networking labs discussion helps select an environment with genuine OSPF behavior. Cisco’s v1.1 exam topics and v2.0 objectives are the actual version authority. In either version, the lasting skill is identifying where a healthy-looking routing configuration stops producing the expected adjacency or route.