OSPF troubleshooting tickets

The static default points at 203.0.113.11, a typo for 203.0.113.1. That address is not on R1's provider subnet (Gi0/2 is 203.0.113.2/30). In this baseline there is no other route that resolves the mistyped next hop, so the configured default is not installed. Confirm with show ip route 0.0.0.0 and show ip route 203.0.113.11. Without an installed default route of its own, R1 doesn't originate one into OSPF. Fix: no ip route 0.0.0.0 0.0.0.0 203.0.113.11 and ip route 0.0.0.0 0.0.0.0 203.0.113.1. R2 and R3 get O*E2 0.0.0.0/0 back after the OSPF update and route calculation. Adding always would advertise a default despite this missing exit; it would not repair the next-hop typo.

Verify R1's installed default via 203.0.113.1, then R3's O*E2 default via 10.0.23.1. The ping to the directly connected ISP address worked without a default route, so that successful ping did not disprove this fault. A real external service also needs provider return routing.

The checklist added passive-interface default, which also made Gi0/1, the link to R2, passive. No hellos, no neighbour. Fix: under router ospf 1, no passive-interface GigabitEthernet0/1. Gi0/0 (LAN 1) should stay passive. Gi0/2 is not in OSPF anyway, so its passive setting does nothing.

The output names a specific blocked transit interface, so do not remove the whole passive policy. Compare R1's Gi0/1 OSPF settings with R2 Gi0/0, then verify R1 has one Full neighbour and R2 has two. Recheck the LAN routes and host test after the adjacency returns.

Hellos work (the neighbour exists), but the database exchange doesn't. R3's IP MTU is 1400 while R2's is 1500, so R3 rejects R2's DBDs, which announce the larger MTU. The routers can show EXSTART or EXCHANGE at different moments; do not expect one fixed state on each side.Fix: restore the lab's intended supported 1500-byte IP MTU. On R3, interface GigabitEthernet0/0, then no ip mtu, restores that baseline here because this lab has no other MTU-changing settings. Check the actual value afterwards. ip ospf mtu-ignore skips the OSPF field check; it does not make the data path support larger packets and is not the first repair for this accidental override.

EXSTART alone is not proof of an MTU mismatch; packet filtering, duplicate IDs and other negotiation problems can produce similar symptoms. Here the two measured MTUs support the diagnosis. After restoring the intended value, verify Full and the LAN 3 route. Where appropriate, test path packet sizes separately rather than treating a small successful ping as an MTU test.

Gi0/2 is missing from the interface list, so OSPF isn't running on it at all. The statement network 192.168.2.0 0.0.0.0 area 0 only matches an interface whose address is exactly 192.168.2.0, and Gi0/2 is 192.168.2.1. The passive line doesn't enable anything by itself. Fix: no network 192.168.2.0 0.0.0.0 area 0, then network 192.168.2.0 0.0.0.255 area 0 (or network 192.168.2.1 0.0.0.0 area 0).

Keep passive-interface GigabitEthernet0/2. It prevents host-side neighbours; it does not cause the missing advertisement. After repairing the selection, Gi0/2 should appear in show ip ospf interface brief with no neighbours, and R1/R3 should install the LAN 2 /24. Confirm the LAN interface is up and connected before blaming the wildcard alone.

With every router at 10 000 Mbps, each gigabit interface costs 10, so LAN 1 should be 30 (R3 Gi0/0 + R2 Gi0/0 + R1 Gi0/0) and LAN 2 should be 20. The totals are 9 lower on each route that passes R2: R2's relevant outgoing interfaces appear to cost 1 rather than 10. That fits a reference-bandwidth mismatch, but an explicit cost or a different configured interface bandwidth could do the same. Compare show ip ospf, show ip ospf interface and the interface configuration on R2. For this ticket, the confirming output is Reference bandwidth unit is 100 mbps, gigabit configured bandwidth and no explicit ip ospf cost. With 100 ÷ 1000 below 1, the calculated cost becomes the minimum of 1. Fix: auto-cost reference-bandwidth 10000 under R2's router ospf 1. In a network with more than one path, this mismatch would also change which paths are chosen.

Check all three routers use the intended reference and inspect their calculated interface costs. Afterwards, R3's LAN 1 and LAN 2 metrics should return to 30 and 20. In this line topology the next hop remains R2; changing a metric does not create a missing alternate path.

R2 labels R3 DROTHER, a router that is neither the designated router nor its backup. That role is used on broadcast and non-broadcast multi-access OSPF networks, while R3 shows R2 with no role (-). R2's Gi0/1 has gone back to the broadcast type (the "tidy-up" removed ip ospf network point-to-point), while R3 is still point-to-point. The timers match, so they reach Full, but they describe the link differently in their link-state advertisements (LSAs), the records used to calculate routes. The mismatched descriptions can prevent usable topology links even with a Full adjacency. Confirm R2 reports Network Type BROADCAST and R3 reports Network Type POINT_TO_POINT in their interface output. Fix: put ip ospf network point-to-point back on R2 Gi0/1. Compare Network Type in show ip ospf interface on both ends.

Do not treat matching Hello timers as proof of matching network types. After the interface change, allow the adjacency to rebuild, confirm both ends report point-to-point and check R1's route to 192.168.3.0/24. This repair targets the inconsistent link description rather than hiding the symptom with a static route.

R1's Gi0/1 (10.0.12.1) is now in a different area from R2's Gi0/0 in area 0. Likely cause: R1 was given ip ospf 1 area 1 on Gi0/1, or a network statement with the wrong area. Interface configuration overrides network statements, so check both. Fix: put R1's Gi0/1 back in area 0 (ip ospf 1 area 0 on the interface, or correct the network statement).

The log identifies the sender 10.0.12.1 and R2's receiving interface Gi0/0. Trace that sender to R1 Gi0/1 in the baseline table. Compare show ip ospf interface brief and the interface configuration on both routers. The OSPF process number is local and does not need to match, but the area on this shared link does. Verify the area-0 neighbour returns and LAN 1 is learned again.

A device on LAN 2 (192.168.2.50, router ID 10.10.10.10) has become an unexpected OSPF neighbour. The neighbour table alone does not prove it caused the packet loss. The second output adds that evidence: R2 is selecting an external /25 through that device for the server address. A /25 is more specific than the legitimate /24, so longest-prefix matching sends matching traffic to the unexpected neighbour regardless of the /24's metric. In this baseline Gi0/2 should have no OSPF neighbours; its Full neighbour proves Gi0/2 is no longer passive. Fix: passive-interface GigabitEthernet0/2 under router ospf 1, then find the device. Inspect and identify the device rather than assuming it is a particular VM or server. Supported OSPF authentication on authorised router links adds another control, but does not replace the passive LAN policy or prove that an authenticated router's advertisements are correct.

After the neighbour is removed, confirm the unexpected /25 disappears, the legitimate /24 via R3 is selected for 192.168.3.10 and the host test recovers. Record the advertising router ID and investigate why the configuration changed. Do not reproduce this ticket by attaching an unknown router to a live LAN.