Troubleshooting Layer 3 — Routing & IP Issues

Layer 1 is up, Layer 2 is healthy, and frames are crossing switches without error — yet hosts still cannot communicate across network boundaries. At this point the fault lives at Layer 3: the IP addressing, subnet masks, and routing logic that determine whether a packet can find its destination. Layer 3 problems are uniquely deceptive because they are often asymmetric — traffic flows in one direction but not the other — and because a single missing or incorrect route entry can silently black-hole traffic with no obvious physical indication.

The three primary diagnostic tools for Layer 3 are show ip route, ping, and traceroute. Together they answer the three fundamental routing questions: does the router know how to reach the destination? (show ip route), can packets reach the destination? (ping), and where in the path does forwarding break? (traceroute). For OSPF-specific faults, show ip ospf neighbor and its companion commands add the layer of neighbour-state visibility needed to diagnose dynamic routing protocol failures.

This guide assumes Layers 1 and 2 are confirmed healthy. Verify those first using Troubleshooting Layer 1 and Troubleshooting Layer 2 before investigating routing. For static route configuration context see Static Routing Configuration. For OSPF configuration context see OSPF Single-Area Config and OSPF Neighbour States.

1. Layer 3 — Core Concepts & Diagnostic Logic

The Layer 3 Fault Hierarchy

Layer 3 problems fall into five categories. Identifying the category before touching configuration prevents wasted effort:

Fault Category	Symptom	Primary Diagnostic
Missing route	Ping fails with "U" (unreachable) or no reply — router has no route to the destination	`show ip route [dest-ip]` — no match found
Wrong next-hop or exit interface	Ping fails or traffic is forwarded to the wrong destination — route exists but points to wrong place	`show ip route [dest-ip]` — verify next-hop IP and exit interface
Routing loop	Traceroute shows the same hops repeating — two routers each point to the other for the same destination	`traceroute [dest]` — repeating hops; `show ip route` on each router
Asymmetric routing	Ping from A to B fails but B to A works — return path is missing or uses a different route	`show ip route` on both ends — compare forward and return paths
Dynamic routing protocol failure	Routes disappear intermittently or never appear — OSPF/EIGRP neighbour not forming	`show ip ospf neighbor` / `show ip eigrp neighbors` — no neighbours listed

Reading the Routing Table — Route Source Codes

Every line in show ip route begins with a one- or two-letter code identifying how the route was learned. Recognising these codes is the first step in every routing table analysis:

Code	Source	Default AD	Notes
`C`	Connected	0	Directly attached network — interface is up/up with IP address assigned
`L`	Local	0	The router's own interface IP as a /32 host route — added automatically with each connected route
`S`	Static	1	Manually configured with `ip route`. `S*` = static default route
`O`	OSPF	110	Learned via OSPF. `O IA` = inter-area, `O E1/E2` = external
`D`	EIGRP	90	Learned via EIGRP. `D EX` = external EIGRP (AD 170)
`R`	RIP	120	Learned via RIP
`B`	BGP	20 (eBGP) / 200 (iBGP)	Learned via BGP
`*`	Candidate default	—	Marks the route selected as the default gateway of last resort

ping and traceroute Output Codes

Every character in ping and traceroute output carries diagnostic meaning — reading the full output instead of just pass/fail reveals exactly which layer or hop is failing:

Character	ping Meaning	traceroute Meaning	Diagnostic Implication
`!`	Reply received — success	Reply received from hop	Path is reachable to this point
`.`	Timeout — no reply within 2 seconds	No reply from hop within timeout	Route may be missing, ACL blocking, or destination unreachable
`U`	Destination unreachable — ICMP type 3 received	Destination unreachable from a hop	A router along the path has no route and sent back an ICMP unreachable. The router that sent U has the missing route
`N`	Network unreachable	Network unreachable	No route to the destination network on the responding router
`H`	Host unreachable	Host unreachable	Network is routable but the specific host is not responding or ARP fails
`A`	Administratively prohibited — ICMP type 3 code 13	Administratively prohibited	An ACL is blocking the traffic — check access-lists on the responding router
`?`	Unknown packet type	—	Encapsulation or protocol issue
`*`	—	No reply (hop exists but doesn't respond to ICMP TTL-exceeded)	Hop is alive but has ICMP rate-limiting or an ACL blocking time-exceeded messages — not necessarily a fault

The Routing Troubleshooting Mantra — Both Directions

  For every ping or traffic flow that fails, check BOTH directions:

  Forward path:  Source router → all intermediate routers → destination
                 Each router must have a route to the DESTINATION network.

  Return path:   Destination router → all intermediate routers → source
                 Each router must have a route back to the SOURCE network.

  A ping from A to B requires:
    1. R_A knows how to reach B's network  (forward route)
    2. R_B knows how to reach A's network  (return route)
    3. Every router in between has routes for BOTH directions

  The most common asymmetric routing mistake:
    Engineer adds a static route for the forward path.
    Forgets to add the return route on the far-end router.
    Ping from A shows "." (timeout) because packets reach B
    but B's reply has no route back.
    Ping from B shows "U" (unreachable) because B has no
    forward route to A either.

2. Lab Topology & Scenario

This lab covers six Layer 3 fault scenarios across a three-router topology with a stub network on each router and an OSPF domain between R2 and R3:

  192.168.10.0/24          10.0.12.0/30           10.0.23.0/30         192.168.30.0/24
  [PC1:.10.10]──Gi0/1──NetsTuts_R1──Gi0/0──NetsTuts_R2──Gi0/1──NetsTuts_R3──Gi0/1──[PC3:.30.10]
                         Gi0/0: .1            Gi0/0: .2  Gi0/1: .5            Gi0/1: .6
                       10.0.12.1/30         10.0.12.2/30  10.0.23.5/30      10.0.23.6/30

  192.168.20.0/24
  [PC2:.20.10]──Gi0/2──NetsTuts_R2
               R2 Gi0/2: 192.168.20.1/24

  Routing design:
    R1 — Static routes only (points to R2 as next-hop for everything)
    R2 — Static route to 192.168.10.0/24 (toward R1) + OSPF for R3 networks
    R3 — OSPF only (area 0 with R2)

  Fault Scenarios:
    Scenario 1 — PC1 cannot reach PC2 (missing return static route on R2)
    Scenario 2 — PC1 cannot reach PC3 (wrong subnet mask on static route)
    Scenario 3 — Routing loop between R1 and R2 (recursive static routes pointing at each other)
    Scenario 4 — OSPF neighbour not forming between R2 and R3 (area mismatch)
    Scenario 5 — OSPF neighbour drops repeatedly (hello/dead timer mismatch)
    Scenario 6 — OSPF route present but traffic fails (subnet mask mismatch on interface)

Scenario	Affected Path	Symptom	Root Cause
1	PC1 → PC2	Ping times out from PC1 — R2 has no return route	Missing static route on R2 for 192.168.10.0/24
2	PC1 → PC3	Ping fails with "U" — static route has /24 instead of /30	Incorrect subnet mask in static route on R1
3	Any traffic via R1–R2	Traceroute shows R1 and R2 alternating — routing loop	Recursive static routes create a loop
4	R2–R3 OSPF	No OSPF neighbour — `show ip ospf neighbor` empty	R2 in area 0, R3 in area 1 — area mismatch
5	R2–R3 OSPF	Neighbour forms then drops every 40 seconds	Hello timer mismatch (R2=10s, R3=20s) causing dead timer expiry
6	PC3 → PC2	Route exists, ping fails — ARP loops or host unreachable	R3 Gi0/1 configured as /24 instead of /30 — subnet mismatch

3. Scenario 1 — Missing Return Route (Asymmetric Failure)

PC1 (192.168.10.10) cannot ping PC2 (192.168.20.10). The ping shows all dots — timeouts, not unreachables. This asymmetric pattern (timeout rather than U) is a strong indicator that packets are reaching the far end but the reply has no path back.

Step 1 — Ping and Interpret the Output

NetsTuts_R1#ping 192.168.20.10 source GigabitEthernet0/1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.20.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
.....
Success rate is 0 percent (0/5)

All dots — five consecutive timeouts. The ping is sourced from the LAN interface (192.168.10.1) to match the traffic PC1 would generate. Always use source on router pings to simulate real traffic flows — a ping sourced from the router's own IP may succeed even when end-host traffic fails, because the router has a route for its own address. Dots (rather than U) suggest the packet is reaching somewhere but the reply is lost — classic return-path failure.

Step 2 — Check the Routing Table on R1

NetsTuts_R1#show ip route
Codes: C - connected, S - static, ...

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.12.0/30 is directly connected, GigabitEthernet0/0
L        10.0.12.1/32 is directly connected, GigabitEthernet0/0
      192.168.10.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.10.0/24 is directly connected, GigabitEthernet0/1
L        192.168.10.1/32 is directly connected, GigabitEthernet0/1
S        192.168.20.0/24 [1/0] via 10.0.12.2
S        0.0.0.0/0 [1/0] via 10.0.12.2

R1's routing table looks correct — a static route for 192.168.20.0/24 via R2 (10.0.12.2) and a default route. The forward path from R1 to PC2 exists. The problem must be on the return path — R2's routing table needs to be checked for a route back to 192.168.10.0/24.

Step 3 — Check the Routing Table on R2 (Return Path)

NetsTuts_R2#show ip route
Codes: C - connected, S - static, ...

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.12.0/30 is directly connected, GigabitEthernet0/0
L        10.0.12.2/32 is directly connected, GigabitEthernet0/0
C        10.0.23.0/30 is directly connected, GigabitEthernet0/1
L        10.0.23.5/32 is directly connected, GigabitEthernet0/1
      192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.20.0/24 is directly connected, GigabitEthernet0/2
L        192.168.20.1/32 is directly connected, GigabitEthernet0/2
O        192.168.30.0/24 [110/2] via 10.0.23.6, 00:14:22, GigabitEthernet0/1

The smoking gun — R2 has no route to 192.168.10.0/24. PC2's reply packet (sourced from 192.168.20.10, destined for 192.168.10.10) arrives at R2, which has no matching route. R2 checks its routing table, finds no match for 192.168.10.0/24, and drops the packet silently (no default route to fall back to that would reach R1's LAN). This is the classic asymmetric routing failure — forward path works, return path is broken.

Step 4 — Fix the Missing Return Route

NetsTuts_R2(config)#ip route 192.168.10.0 255.255.255.0 10.0.12.1

! ── Verify ────────────────────────────────────────────────────────
NetsTuts_R2#show ip route 192.168.10.0
Routing entry for 192.168.10.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.12.1, via GigabitEthernet0/0
      Route metric is 0, traffic share count is 1

! ── Re-test ping from R1 ─────────────────────────────────────────
NetsTuts_R1#ping 192.168.20.10 source GigabitEthernet0/1
Sending 5, 100-byte ICMP Echos to 192.168.20.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Five exclamation marks — bidirectional reachability confirmed. The fix is a single static route on R2 pointing 192.168.10.0/24 back toward R1 via 10.0.12.1. The pattern of always checking both the forward and return routing tables is the single most important habit in Layer 3 troubleshooting — a missing return route is the most frequently occurring oversight in multi-router deployments.

4. Scenario 2 — Wrong Subnet Mask in Static Route

PC1 cannot reach PC3 (192.168.30.10). The ping returns "U" — ICMP destination unreachable — rather than timeouts. This is a different symptom from Scenario 1: a router along the path is actively sending back an unreachable message, which means a routing table lookup is failing explicitly at a known point.

Step 1 — Use traceroute to Find the Failure Point

NetsTuts_R1#traceroute 192.168.30.10 source GigabitEthernet0/1
Type escape sequence to abort.
Tracing the route to 192.168.30.10
VRF info: (vrf in name/id, vrf out name/id)
  1 10.0.12.2 1 msec 1 msec 1 msec
  2  *  *  *
  3  *  *  *

Traceroute reaches R2 (10.0.12.2) at hop 1 — the R1-to-R2 link is working. Hop 2 shows three asterisks — the packet is not advancing beyond R2. R2 is either dropping the packet or has no route to 192.168.30.0/24 from R1's perspective. Note: three asterisks on their own do not always indicate a fault — a router may suppress ICMP TTL-exceeded messages. But when combined with the ping failure, hop 2 being the last responsive hop isolates the fault to R2.

Step 2 — Check R1's Route for 192.168.30.0

NetsTuts_R1#show ip route 192.168.30.0
Routing entry for 192.168.30.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 10.0.12.2, via GigabitEthernet0/0

! ── R1 has a route — but check the static route configuration ────
NetsTuts_R1#show running-config | include ip route
ip route 192.168.20.0 255.255.255.0 10.0.12.2
ip route 192.168.30.0 255.255.255.0 10.0.12.2
ip route 10.0.23.0 255.255.255.0 10.0.12.2
ip route 0.0.0.0 0.0.0.0 10.0.12.2

! ── R2 has OSPF route for 192.168.30.0/24 — check R2's table ─────
NetsTuts_R2#show ip route 192.168.30.0
Routing entry for 192.168.30.0/24
  Known via "ospf 1", distance 110, metric 2
  * 10.0.23.6, via GigabitEthernet0/1

! ── So far so good — check R3 ────────────────────────────────────
NetsTuts_R3#show ip route
...
C   192.168.30.0/24 is directly connected, GigabitEthernet0/1
C   10.0.23.0/30 is directly connected, GigabitEthernet0/0
O   192.168.20.0/24 [110/2] via 10.0.23.5, GigabitEthernet0/0
! ── No route to 192.168.10.0/24 on R3 ──────────────────────────

R3 has no route to 192.168.10.0/24 — that is why the reply from PC3 never makes it back. But wait — the traceroute already showed the fault at hop 2 (R2), not R3. Let's look more carefully at R2's OSPF route — specifically the mask.

Step 3 — Inspect the OSPF Route Details on R2

NetsTuts_R2#show ip route 192.168.30.0 255.255.255.0 longer-prefixes
! ── No output — the /24 does not exist as R2 knows it

NetsTuts_R2#show ip route | include 192.168.30
O        192.168.30.0/24 [110/2] via 10.0.23.6

! ── Check R1's static route mask precisely ───────────────────────
NetsTuts_R1#show running-config | include 192.168.30
ip route 192.168.30.0 255.255.255.0 10.0.12.2

! ── That looks right — but check what R3 is advertising ──────────
NetsTuts_R3#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.30.1/24

! ── Check R3's OSPF network statement ────────────────────────────
NetsTuts_R3#show running-config | section router ospf
router ospf 1
 network 192.168.30.0 0.0.0.255 area 0
 network 10.0.23.0 0.0.0.3 area 0
! ── OSPF wildcard for 192.168.30.0 is 0.0.0.255 (/24) ──────────

! ── Now check R1's static route to 10.0.23.0 ────────────────────
NetsTuts_R1#show running-config | include 10.0.23
ip route 10.0.23.0 255.255.255.0 10.0.12.2
!                  ^^^^^^^^^^^^^^ /24 — WRONG. Should be /30

Found it — R1 has a static route for 10.0.23.0 with subnet mask 255.255.255.0 (/24) instead of the correct 255.255.255.252 (/30). The 10.0.23.0 link between R2 and R3 is a /30 point-to-point link. With the /24 mask, R1's route covers 10.0.23.0 through 10.0.23.255 — a much broader range than the actual /30 network. This incorrect mask causes the route to match traffic that should go elsewhere and misses the actual addresses in the /30 network. Subnet mask errors in static routes are a classic silent fault — the route entry appears valid in the routing table but the mask is wrong.

Step 4 — Fix the Subnet Mask

! ── Remove the wrong route first ─────────────────────────────────
NetsTuts_R1(config)#no ip route 10.0.23.0 255.255.255.0 10.0.12.2

! ── Add the correct route with /30 mask ──────────────────────────
NetsTuts_R1(config)#ip route 10.0.23.0 255.255.255.252 10.0.12.2

! ── Also need return route on R3 for 192.168.10.0/24 ─────────────
! ── R3 uses OSPF — redistribute or add via OSPF or static ────────
NetsTuts_R3(config)#ip route 192.168.10.0 255.255.255.0 10.0.23.5

! ── Verify end-to-end ─────────────────────────────────────────────
NetsTuts_R1#ping 192.168.30.10 source GigabitEthernet0/1
!!!!!
Success rate is 100 percent (5/5)

The corrected /30 mask ensures R1's route matches exactly the 10.0.23.0/30 transit link. The additional static route on R3 provides the return path for 192.168.10.0/24 traffic. When fixing subnet mask errors, always remove the incorrect route first — adding the correct one without removing the incorrect one may result in two routes to the same network with different masks, causing unpredictable longest-prefix-match behaviour.

5. Scenario 3 — Routing Loop

All traffic destined for 192.168.30.0/24 from PC1 is experiencing a TTL-exceeded loop — packets never arrive and traceroute shows R1 and R2 alternating. The TTL decrements at each hop until it reaches zero and the packet is discarded.

Step 1 — Identify the Loop with traceroute

NetsTuts_R1#traceroute 192.168.30.10 source GigabitEthernet0/1
Tracing the route to 192.168.30.10
  1 10.0.12.2  1 msec  1 msec  1 msec
  2 10.0.12.1  1 msec  1 msec  1 msec
  3 10.0.12.2  1 msec  1 msec  1 msec
  4 10.0.12.1  1 msec  1 msec  1 msec
  5 10.0.12.2  1 msec  1 msec  1 msec
  ...
  30 10.0.12.1  1 msec  2 msec  1 msec

The alternating 10.0.12.2 (R2) and 10.0.12.1 (R1) pattern is the definitive routing loop signature — every packet bounces between R1 and R2 until its TTL expires. R1 sends the packet to R2 (its next-hop for 192.168.30.0), and R2 sends it back to R1 (its next-hop for the same destination). This continues for up to 255 hops before the final router discards the packet and may send an ICMP TTL-exceeded message back to the source.

Step 2 — Find the Loop in Routing Tables

NetsTuts_R1#show ip route 192.168.30.0
Routing entry for 192.168.30.0/24
  Known via "static", distance 1, metric 0
  * 10.0.12.2, via GigabitEthernet0/0    ← R1 sends to R2

NetsTuts_R2#show ip route 192.168.30.0
Routing entry for 192.168.30.0/24
  Known via "static", distance 1, metric 0
  * 10.0.12.1, via GigabitEthernet0/0    ← R2 sends BACK to R1 !

The loop is immediately visible: R1 points to R2 (10.0.12.2) for 192.168.30.0/24, and R2 points back to R1 (10.0.12.1) for the same prefix. Neither router has a valid downstream path to 192.168.30.0/24. This happens when an engineer adds a static route on R2 pointing back toward R1 thinking it is a return route, but accidentally uses the wrong destination prefix — matching 192.168.30.0/24 (which should go to R3) instead of 192.168.10.0/24 (which should return to R1's LAN).

Step 3 — Fix the Loop

! ── R2's static route is pointing the wrong direction ────────────
! ── Remove the incorrect route on R2 ─────────────────────────────
NetsTuts_R2(config)#no ip route 192.168.30.0 255.255.255.0 10.0.12.1

! ── R3 should advertise 192.168.30.0/24 via OSPF to R2 ───────────
! ── Verify OSPF is advertising it ────────────────────────────────
NetsTuts_R2#show ip route 192.168.30.0
Routing entry for 192.168.30.0/24
  Known via "ospf 1", distance 110, metric 2
  * 10.0.23.6, via GigabitEthernet0/1   ← Now correctly via R3

NetsTuts_R1#traceroute 192.168.30.10 source GigabitEthernet0/1
  1 10.0.12.2  1 msec
  2 10.0.23.6  2 msec
  3 192.168.30.10  3 msec

Three clean hops — R1 → R2 → R3 → PC3. The OSPF route (AD 110) was being suppressed by the incorrect static route (AD 1) on R2 — lower AD always wins, so the static route to 10.0.12.1 overrode the OSPF-learned route pointing to R3. Once the incorrect static route is removed, the OSPF route re-emerges as the best path. This illustrates why static routes, with their low AD of 1, must be configured with extreme care — they unconditionally override dynamic routing protocol routes.

Administrative Distance — Why Static Beats OSPF

Scenario	Route Sources in Table	Winner	Reason
Static + OSPF same prefix	S [1/0] and O [110/2]	Static (AD 1)	Lower AD wins — OSPF route is hidden from the table
OSPF + EIGRP same prefix	O [110/x] and D [90/x]	EIGRP (AD 90)	EIGRP AD 90 < OSPF AD 110
Static default + OSPF specific	S* 0.0.0.0/0 and O 192.168.30.0/24	OSPF specific route	Longest prefix match wins before AD is compared
Floating static (AD 254) + OSPF	S [254/0] and O [110/2]	OSPF (AD 110)	Floating static only activates if OSPF route disappears

6. Scenario 4 — OSPF Neighbour Not Forming (Area Mismatch)

R3 was recently added to the network. The OSPF process is running on both R2 and R3, but no OSPF routes are appearing in R2's routing table and show ip ospf neighbor returns empty on both routers. The link between R2 and R3 (Gi0/1 / Gi0/0) is up/up.

Step 1 — Confirm OSPF Neighbour State

NetsTuts_R2#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
! ── Empty — no neighbours ────────────────────────────────────────

NetsTuts_R3#show ip ospf neighbor
! ── Empty ─────────────────────────────────────────────────────────

An empty show ip ospf neighbor on both sides of a link means OSPF Hello packets are either not being sent, not being received, or are being received and rejected. The rejection case is most common — OSPF drops Hellos that don't match on five parameters: area ID, authentication, hello/dead timers, stub area flag, and MTU (in some IOS versions). Any mismatch in these five fields prevents the neighbour relationship from advancing past the INIT state to 2WAY and beyond.

Step 2 — Check OSPF Configuration on Both Routers

NetsTuts_R2#show running-config | section router ospf
router ospf 1
 network 10.0.23.0 0.0.0.3 area 0
 network 192.168.20.0 0.0.0.255 area 0

NetsTuts_R3#show running-config | section router ospf
router ospf 1
 network 10.0.23.0 0.0.0.3 area 1
 network 192.168.30.0 0.0.0.255 area 1

The area mismatch is immediately visible — R2 places the 10.0.23.0/30 link in area 0, R3 places it in area 1. OSPF Hello packets contain the area ID of the sending interface. When R2 receives R3's Hello on Gi0/1, it sees area 1 in the Hello but its own interface is in area 0 — the area IDs do not match and R2 drops the Hello without forming a neighbour relationship. No error message is generated by default — the neighbour simply never appears.

Step 3 — Check with show ip ospf interface

NetsTuts_R2#show ip ospf interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet Address 10.0.23.5/30, Area 0, Attached via Network Statement
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  oob-resync timeout 40
  Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Neighbor Count is 0, Adjacent neighbor count is 0

NetsTuts_R3#show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.0.23.6/30, Area 1, Attached via Network Statement
  ...
  Neighbor Count is 0, Adjacent neighbor count is 0

show ip ospf interface exposes the area assigned to each OSPF-enabled interface — Area 0 on R2's Gi0/1 vs Area 1 on R3's Gi0/0. This is the definitive confirmation of the area mismatch. The command also shows hello/dead timers (10/40 here — matching on both, which rules out timer mismatch as a cause in this scenario) and the neighbour count (0 on both).

Step 4 — Fix the Area Mismatch

! ── Decision: put both ends in area 0 (backbone area) ───────────
! ── Remove incorrect area 1 statements on R3 ─────────────────────
NetsTuts_R3(config)#router ospf 1
NetsTuts_R3(config-router)#no network 10.0.23.0 0.0.0.3 area 1
NetsTuts_R3(config-router)#no network 192.168.30.0 0.0.0.255 area 1
NetsTuts_R3(config-router)#network 10.0.23.0 0.0.0.3 area 0
NetsTuts_R3(config-router)#network 192.168.30.0 0.0.0.255 area 0
NetsTuts_R3(config-router)#exit

! ── Verify neighbour forms ────────────────────────────────────────
NetsTuts_R2#show ip ospf neighbor
Neighbor ID  Pri  State    Dead Time  Address      Interface
3.3.3.3       0  FULL/  -  00:00:36  10.0.23.6    GigabitEthernet0/1

The neighbour state FULL/- confirms full OSPF adjacency has formed. The - in the DR/BDR field is correct for a point-to-point link — DR/BDR election only occurs on multi-access networks (Ethernet broadcast segments). OSPF routes for 192.168.30.0/24 will now appear in R2's routing table and propagate back to R1 via the static default route.

OSPF Neighbour Rejection — The Five Must-Match Parameters

Parameter	Must Match?	How to Check	How to Fix
Area ID	Yes — both interfaces must be in the same area	`show ip ospf interface [int]` — Area field	Correct the `network` statement area number on one router
Authentication	Yes — type (none/plain/MD5) and key must match	`show ip ospf interface [int]` — Simple password / MD5	Align `ip ospf authentication` and `ip ospf message-digest-key`
Hello / Dead timers	Yes — both timers must be identical	`show ip ospf interface [int]` — Timer intervals line	`ip ospf hello-interval` and `ip ospf dead-interval` on the interface
Stub area flag	Yes — both must agree on stub/not-stub	`show ip ospf` — Area type	Add or remove `area [id] stub` on both routers
MTU (Database Exchange)	Yes during DBD exchange — mismatch stalls at EXSTART	`show ip ospf neighbor` — stuck in EXSTART/EXCHANGE	`ip ospf mtu-ignore` on the interface (workaround) or align MTUs

7. Scenario 5 — OSPF Neighbour Flapping (Timer Mismatch)

After fixing the area mismatch from Scenario 4, R2 and R3 briefly form a neighbour relationship but it drops every 40 seconds and immediately re-forms — a symptom called OSPF flapping. The syslog shows repeated %OSPF-5-ADJCHG messages alternating between FULL and DOWN states.

Step 1 — Observe the Flapping in Syslog

NetsTuts_R2#show logging | include OSPF
Mar  7 16:10:01 GST: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Gi0/1 from LOADING to FULL
Mar  7 16:10:41 GST: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Gi0/1 from FULL to DOWN
Mar  7 16:10:42 GST: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Gi0/1 from LOADING to FULL
Mar  7 16:11:22 GST: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Gi0/1 from FULL to DOWN

The neighbour drops to DOWN exactly 40 seconds after forming — then immediately re-forms. This 40-second interval is the OSPF dead timer. When the dead timer expires without receiving a Hello from the peer, OSPF declares the neighbour dead and tears down the adjacency. The immediate re-formation indicates Hello packets are eventually arriving — just not frequently enough. This is the classic hello/dead timer mismatch signature. Use show logging to review ADJCHG events and their timestamps.

Step 2 — Compare Hello Timers on Both Interfaces

NetsTuts_R2#show ip ospf interface GigabitEthernet0/1
  ...
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

NetsTuts_R3#show ip ospf interface GigabitEthernet0/0
  ...
  Timer intervals configured, Hello 20, Dead 80, Wait 80, Retransmit 5

The mismatch is clear — R2 sends Hello packets every 10 seconds with a dead timer of 40 seconds. R3 sends Hello packets every 20 seconds with a dead timer of 80 seconds. When R3 sends a Hello every 20 seconds, R2's dead timer (40 seconds) expires before receiving the second Hello — R2 declares R3 dead and tears down the adjacency. R3 then receives R2's Hello (still arriving every 10s) and begins the process again. Hello and dead timers must be identical on both sides of an OSPF link for stable adjacency.

Step 3 — Fix the Timer Mismatch

! ── Align R3 to match R2's timers (10/40 — standard defaults) ────
NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#ip ospf hello-interval 10
NetsTuts_R3(config-if)#ip ospf dead-interval 40
NetsTuts_R3(config-if)#exit

! ── Alternatively: remove custom timers and return to defaults ────
NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#no ip ospf hello-interval
NetsTuts_R3(config-if)#no ip ospf dead-interval
NetsTuts_R3(config-if)#exit

! ── Verify stable adjacency ───────────────────────────────────────
NetsTuts_R2#show ip ospf neighbor
Neighbor ID  Pri  State    Dead Time  Address      Interface
3.3.3.3       0  FULL/  -  00:00:37  10.0.23.6    GigabitEthernet0/1

! ── Watch for stability — Dead Time should count down from 40 ─────
! ── and reset when a Hello is received, never reaching 0 ─────────

After aligning both routers to Hello 10 / Dead 40 (the IOS defaults), the Dead Time counter in show ip ospf neighbor resets every 10 seconds when a Hello arrives — it never reaches zero and the adjacency remains stable. The OSPF dead timer should always be at least three times the hello interval (4× is the IOS default relationship: dead = 4 × hello). Setting hello-interval and dead-interval independently allows these to be tuned — but both must match the peer.

OSPF Adjacency State Reference

State	Meaning	Stuck Here Indicates
DOWN	No Hellos received	No OSPF Hellos arriving — check interface, network statement, ACL blocking
INIT	Hello received but router's own RID not seen in peer's Hello	Unidirectional communication — ACL blocking in one direction, or layer 1/2 issue
2WAY	Bidirectional Hello exchange confirmed	Normal for non-DR/BDR routers on broadcast networks — not a fault on multi-access
EXSTART	Master/slave election for DBD exchange	MTU mismatch most common cause — use `ip ospf mtu-ignore`
EXCHANGE	Database Description (DBD) packets exchanged	Stuck here rarely — usually an MTU or authentication issue
LOADING	LSR/LSU exchange to synchronise databases	Transient — should resolve within seconds. If stuck, check for corrupted LSAs
FULL	Databases synchronised — full adjacency	Desired end state. On point-to-point: FULL/-. On broadcast: FULL/DR or FULL/BDR

8. Scenario 6 — Route Present but Traffic Fails (IP Addressing Error)

OSPF is stable, all routes appear correct in all routing tables, but PC3 (192.168.30.10) cannot ping PC2 (192.168.20.10). The ping from R3 itself to 192.168.20.1 works, but pings sourced from Gi0/1 (the PC3-facing interface) fail. This points to an IP addressing error on R3's interfaces.

Step 1 — Ping with Different Sources to Isolate

! ── Ping from R3's management address (router itself) ────────────
NetsTuts_R3#ping 192.168.20.1
Sending 5, 100-byte ICMP Echos to 192.168.20.1:
!!!!!
Success rate is 100 percent (5/5)

! ── Ping sourced from the PC3-facing interface ───────────────────
NetsTuts_R3#ping 192.168.20.1 source GigabitEthernet0/1
Sending 5, 100-byte ICMP Echos to 192.168.20.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.30.1
.....
Success rate is 0 percent (0/5)

The asymmetry is telling — pings from R3's own (Loopback or 10.0.23.6) address succeed, but pings sourced from Gi0/1 (192.168.30.1) fail. This means R2 has a return route for the 10.0.23.0/30 addresses but not for 192.168.30.0/24. Yet OSPF should be advertising 192.168.30.0/24 to R2. Something is wrong with how R3's Gi0/1 is configured.

Step 2 — Inspect IP Addressing on R3

NetsTuts_R3#show ip interface brief
Interface              IP-Address      OK? Method Status    Protocol
GigabitEthernet0/0     10.0.23.6       YES NVRAM  up        up
GigabitEthernet0/1     192.168.30.1    YES NVRAM  up        up

NetsTuts_R3#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.30.1/24

! ── Check what OSPF is advertising ───────────────────────────────
NetsTuts_R3#show ip ospf interface GigabitEthernet0/1
  Internet Address 192.168.30.1/24, Area 0

! ── Check what R2 received via OSPF ──────────────────────────────
NetsTuts_R2#show ip route ospf
O     192.168.30.0/24 [110/2] via 10.0.23.6, GigabitEthernet0/1

! ── Route is correct — check the PC3 subnet more carefully ────────
! ── PC3 IP: 192.168.30.10 / Mask: 255.255.255.0
! ── R3 Gi0/1 IP: 192.168.30.1 / Mask: 255.255.255.0
! ── These match — so where is the problem? ────────────────────────

! ── Extended ping from R2 to R3's LAN ────────────────────────────
NetsTuts_R2#ping 192.168.30.10 source GigabitEthernet0/2
Sending 5, 100-byte ICMP Echos to 192.168.30.10:
.....
Success rate is 0 percent (0/5)

NetsTuts_R2#ping 192.168.30.1 source GigabitEthernet0/2
Sending 5, 100-byte ICMP Echos to 192.168.30.1:
!!!!!
Success rate is 100 percent (5/5)

R2 can reach R3's interface (192.168.30.1) but not PC3 (192.168.30.10). This means R3's routing and OSPF advertising are fine — the problem is between R3 and PC3 at Layer 3. The router can reach its own interface, which rules out OSPF and routing table issues. The focus narrows to the ARP and IP configuration between R3's Gi0/1 and PC3.

Step 3 — Check PC3's IP Configuration and ARP

! ── Check ARP table on R3 ─────────────────────────────────────────
NetsTuts_R3#show arp
Protocol  Address          Age  Hardware Addr   Type   Interface
Internet  192.168.30.1       -  0c1a.3b2f.0301  ARPA   GigabitEthernet0/1
! ── No ARP entry for 192.168.30.10 — R3 cannot reach PC3 ─────────

! ── PC3 configuration (reported by user) ─────────────────────────
! PC3 IP:      192.168.30.10
! PC3 Mask:    255.255.255.0
! PC3 Gateway: 192.168.30.1  ← Correct

! ── Try to ping PC3 from R3 directly ─────────────────────────────
NetsTuts_R3#ping 192.168.30.10
.....

! ── R3 should ARP for 192.168.30.10 on Gi0/1 — it's in same /24
! ── Check if PC3 is actually in this subnet ──────────────────────
! ── Physical check reveals: PC3 NIC is configured as /30 ─────────
! PC3 actual mask: 255.255.255.252  (/30) — mismatch with R3 /24

The root cause emerges from the physical investigation — PC3's network mask was configured as /30 (255.255.255.252) instead of /24 (255.255.255.0). From PC3's perspective, only hosts in the 192.168.30.0/30 range (192.168.30.1–192.168.30.2) are in its local subnet. 192.168.30.10 is its own address, but it would try to route 192.168.30.1 (the gateway) through itself — the mask mismatch causes ARP and routing to behave incorrectly. The router (R3 with /24) and the host (PC3 with /30) have inconsistent views of what is local vs. routed.

Step 4 — Fix PC3's Subnet Mask

! ── On PC3: change subnet mask from /30 to /24 ───────────────────
! ── (Done in OS network settings — not an IOS command) ───────────

! ── After fix: verify ARP populates on R3 ────────────────────────
NetsTuts_R3#show arp
Protocol  Address          Age  Hardware Addr   Type   Interface
Internet  192.168.30.1       -  0c1a.3b2f.0301  ARPA   GigabitEthernet0/1
Internet  192.168.30.10      2  a4b2.c3d1.e5f0  ARPA   GigabitEthernet0/1

! ── End-to-end test ──────────────────────────────────────────────
NetsTuts_R3#ping 192.168.30.10 source GigabitEthernet0/1
!!!!!
Success rate is 100 percent (5/5)

With the correct /24 mask, PC3 now correctly identifies 192.168.30.1 as on its local segment, ARPs successfully, and traffic flows. The ARP table on R3 now shows PC3's MAC address — the presence of an ARP entry is a reliable confirmation that Layer 3 addressing and Layer 2 communication are both working correctly between the router interface and the end host. An empty ARP table for an expected host almost always means an IP addressing mismatch or a Layer 1/2 fault between the router port and the host.

9. Full Diagnostic Reference

show ip route — Reading a Complete Routing Table

NetsTuts_R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile,
       B - BGP, D - EIGRP, EX - EIGRP external, O - OSPF,
       IA - OSPF inter area, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type 2, E1 - OSPF external type 1,
       E2 - OSPF external type 2, i - IS-IS ...

Gateway of last resort is not set                                  ← [1]

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks        ← [2]
C        10.0.12.0/30 is directly connected, GigabitEthernet0/0   ← [3]
L        10.0.12.2/32 is directly connected, GigabitEthernet0/0
C        10.0.23.0/30 is directly connected, GigabitEthernet0/1
L        10.0.23.5/32 is directly connected, GigabitEthernet0/1
S     192.168.10.0/24 [1/0] via 10.0.12.1                        ← [4]
      192.168.20.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.20.0/24 is directly connected, GigabitEthernet0/2
L        192.168.20.1/32 is directly connected, GigabitEthernet0/2
O     192.168.30.0/24 [110/2] via 10.0.23.6, 00:22:14, Gi0/1     ← [5]

Marker	Field	Diagnostic Significance
[1]	Gateway of last resort	"not set" means no default route — traffic to unknown destinations is dropped. If expected, check for `S* 0.0.0.0/0` in config. Critical for internet-facing routers
[2]	Variably subnetted	Multiple subnets of different masks exist under this classful network — normal for modern CIDR routing. Not a fault indicator
[3]	C — Connected	Interface is up/up with an IP address. If a connected route is missing, the interface is down or has no IP configured
[4]	S [1/0] via [next-hop]	Static route — AD 1, metric 0. Verify the next-hop IP is reachable (ping it) and the destination network/mask are correct
[5]	O [110/2] via [next-hop], [age], [interface]	OSPF route — AD 110, cost 2. Age shows time since last LSA update — a recent age means OSPF is healthy. A stale age (>dead timer) suggests the neighbour may be flapping

Layer 3 Troubleshooting Decision Tree

Symptom	First Command	Key Finding	Fix
Ping fails with dots (.)	`show ip route [dest]` on source and dest routers	Missing route on return path	Add static route or redistribute into routing protocol on far-end router
Ping fails with U (unreachable)	`traceroute [dest]` to find last responding hop	Last hop has no route — `show ip route [dest]` on that router	Add missing route on the router that sent the unreachable
traceroute shows looping hops	`show ip route [dest]` on each looping router	Two routers point to each other for same prefix	Remove the incorrect static route — allow dynamic protocol route to take over
OSPF neighbour absent	`show ip ospf neighbor` + `show ip ospf interface [int]`	Area mismatch, auth mismatch, or timer mismatch	Align the mismatched parameter using the five must-match checklist
OSPF neighbour flapping	`show ip ospf interface [int]` on both routers	Hello/dead timer mismatch	`ip ospf hello-interval` and `ip ospf dead-interval` — match both ends
OSPF stuck at EXSTART	`show ip ospf neighbor` — state = EXSTART	MTU mismatch preventing DBD exchange	`ip ospf mtu-ignore` on the interface, or align MTUs on both ends
Route present, ping still fails	`show arp` + `ping [host] source [local-int]`	ARP not resolving — IP/mask mismatch on host or router	Verify host IP, mask, and gateway match the router interface subnet
Static route not in table	`show ip route [dest]` + `show run \| include ip route`	Next-hop not reachable, or higher-AD route for same prefix exists	Verify next-hop is reachable (`ping [next-hop]`), or check for conflicting connected/dynamic route
Expected OSPF route missing	`show ip ospf neighbor` + `show ip ospf database`	Neighbour not forming, or network not in OSPF process	Fix neighbour issue or add `network [prefix] [wildcard] area [id]`
Route in table but wrong next-hop	`show ip route [dest]` — check via address	Static route points to wrong next-hop	`no ip route` the incorrect entry, re-add with correct next-hop

Key Points & Exam Tips

Always verify both directions for any failed ping — the forward route may be correct while the return route is missing. Check show ip route on every router in the path, including the destination router.
Ping output characters carry precise meaning: ! = success, . = timeout (return path likely missing or ACL), U = ICMP unreachable received (a specific router has no route — check traceroute to find which one), A = ACL blocking.
Always use the source keyword on router pings to simulate end-host traffic: ping [dest] source [LAN-interface]. A ping from the router's own address may succeed even when end-host traffic fails. Use show ip interface brief to confirm interface IP addresses before pinging.
A static route with AD 1 overrides OSPF (AD 110) for the same prefix — a misconfigured static route will silently shadow a correct OSPF route. Use show ip route [dest] to see which source is active, and show running-config | include ip route to audit all configured static routes.
OSPF neighbours require five parameters to match: area ID, authentication, hello timer, dead timer, and stub flag. MTU must also match during DBD exchange or the neighbour stalls at EXSTART.
show ip ospf interface [int] is the single most useful OSPF diagnostic command — it shows area ID, hello/dead timers, authentication type, network type, and neighbour count all in one output.
OSPF neighbour flapping with a regular interval equal to the dead timer indicates a hello timer mismatch — one side's dead timer expires before the other's slower Hello arrives. Align both with ip ospf hello-interval and ip ospf dead-interval.
An empty ARP entry for a directly connected host almost always means an IP addressing or subnet mask mismatch between the router interface and the host — not a Layer 1 or Layer 2 fault.
show ip route [specific-ip] is more useful than show ip route alone — it shows the exact route entry matched by longest prefix, including the next-hop, AD, metric, and age.
On the CCNA exam: know all ping/traceroute output characters, the route source codes (C/L/S/O/D/R/B), the five OSPF must-match parameters, the AD values for all routing sources, and the difference between dots and U in ping output.

Next Steps: With Layer 3 routing confirmed operational, the next layer of investigation involves application-level reachability — verify ACLs are not blocking specific protocols with Extended ACL Configuration. For static routing configuration reference see Static Routing Configuration. For OSPF configuration and neighbour state theory see OSPF Neighbour States and OSPF Single-Area Config. For verifying routing table entries in detail see show ip route. For in-depth OSPF neighbour troubleshooting see Troubleshooting OSPF Neighbour Adjacency.

TEST WHAT YOU LEARNED

1. A ping from R1 to 192.168.30.10 returns all dots (`.....`). A ping from R1 to 192.168.30.10 sourced from Gi0/1 (192.168.10.1) also returns all dots. However, a ping directly from R3 to 192.168.10.1 returns `UUUUU`. What do these two results together indicate?

A. Both directions are completely broken — no routing exists in either direction. Add routes on all routers B. The forward path from R1 to R3 is broken — the dots indicate R1 has no route to 192.168.30.10 C. The forward path from R1 to R3 likely works (dots = timeout, not unreachable — packets may be arriving but replies are lost). The return path from R3 to R1 is definitively broken — R3 receives R1's pings but has no route back to 192.168.10.0/24, confirmed by the UUUUU from R3 showing it actively rejects traffic to that network with an ICMP unreachable D. An ACL on R3 is blocking both directions — U indicates access denied by an access-list

Correct answer is C. The two ping results must be interpreted together to understand the asymmetric failure. Dots from R1 to R3 indicate timeout — the packet may be reaching the destination but the reply has no return path (or the packet is being dropped without an unreachable message). U from R3 to R1 is definitive — R3 is sending ICMP type 3 (destination unreachable) for 192.168.10.0/24 packets, meaning it has no route to that network. Together: packets from R1 reach R3 but R3 cannot reply (no return route) — matching the dots from R1. R3's own traffic to R1 also fails with U because R3 has no route to 192.168.10.0/24. Fix: add a route to 192.168.10.0/24 on R3 pointing toward R2 (and ultimately R1). Option D is incorrect — A (not U) indicates an ACL block.

2. `show ip ospf neighbor` on R2 shows R3's neighbour state as `EXSTART` for several minutes without advancing to EXCHANGE. What is the most likely cause?

A. MTU mismatch — OSPF Database Description (DBD) packet exchange fails when the MTU on one interface is larger than the peer expects. The larger-MTU side's DBD packets exceed the peer's interface MTU and are dropped. Fix: align interface MTUs or apply ip ospf mtu-ignore on the affected interface B. Area mismatch — the routers are in different OSPF areas, preventing the EXSTART to EXCHANGE transition C. Authentication mismatch — OSPF Hellos are passing (the neighbour reached EXSTART) but DBD authentication fails D. The OSPF process ID is different on the two routers — process IDs must match for DBD exchange to succeed

Correct answer is A. The OSPF neighbour state machine is informative — the state where it gets stuck tells you what failed. EXSTART is the first stage of database exchange where routers elect a master/slave relationship and exchange initial DBD packets. An MTU mismatch causes EXSTART to stall because DBD packets from the higher-MTU router exceed the peer's maximum receivable size — the peer drops them silently. An area mismatch (Option B) would prevent the neighbour from even reaching INIT — area mismatches are detected in Hello processing, which happens before EXSTART. Authentication mismatches similarly prevent Hello exchange and would result in no neighbour entry at all or a state stuck at INIT. OSPF process IDs (Option D) do not need to match — they are locally significant only. The fix for MTU mismatch is either to align the MTUs or apply ip ospf mtu-ignore as a workaround.

3. R2's routing table shows `S 192.168.30.0/24 [1/0] via 10.0.12.1` and `O 192.168.30.0/24 [110/2] via 10.0.23.6`. Which route does R2 use to forward traffic to 192.168.30.0/24, and why?

A. The OSPF route — OSPF is more reliable than static routes because it is dynamically updated B. Both routes are used simultaneously — IOS load-balances across them using ECMP C. The OSPF route — the metric 2 is lower than the static route's metric 0 D. The static route — administrative distance 1 (static) beats AD 110 (OSPF). When two routes to the same prefix exist with different sources, IOS installs only the one with the lowest AD into the forwarding table. The OSPF route is present in the RIB but the static route shadows it. This is dangerous if the static route points to a wrong next-hop — the correct OSPF route is hidden

Correct answer is D. Administrative distance is the tiebreaker when multiple routing sources have routes to the same prefix with the same prefix length. The process is: (1) longest prefix match wins first — both routes are /24 so prefix length is equal; (2) lowest AD wins — static has AD 1, OSPF has AD 110. The static route wins unconditionally. The OSPF route is known to IOS (visible in the RIB) but not installed in the FIB for forwarding. This is why a misconfigured static route is so dangerous — it silently overrides the correct dynamically learned route. Metric comparison (Option C) only applies between routes from the same routing protocol — you never compare metrics across different protocols; AD handles that comparison. ECMP (Option B) only applies when the same source has multiple equal-cost paths to the same prefix.

4. An engineer runs `traceroute 192.168.30.10` from R1 and sees hops alternating between 10.0.12.1 and 10.0.12.2 for all 30 hops. What does this mean and what is the correct fix?

A. The traceroute is showing ECMP load balancing — R1 and R2 are both valid paths. This is normal behaviour, not a fault B. A routing loop exists — R1 forwards packets for 192.168.30.0/24 to R2, and R2 forwards them back to R1 in an infinite cycle. Each router believes the other is the correct next-hop for the same destination. Packets bounce until TTL = 0. Fix: check show ip route 192.168.30.0 on both routers, identify which static route is incorrect (pointing the wrong direction), remove it with no ip route, and confirm the correct downstream path takes over C. R1 and R2 are running HSRP — the alternating addresses represent the active and standby routers responding to probes D. The WAN link between R1 and R2 has high latency — the alternating pattern indicates packet reordering during transit

Correct answer is B. The alternating hop pattern in traceroute output is the definitive routing loop indicator. Each line in traceroute output represents one TTL increment — a packet with TTL=1 reaches the first hop (R2 at 10.0.12.2), TTL=2 reaches the second hop (R1 at 10.0.12.1), TTL=3 reaches R2 again, and so on. The packet is bouncing between the same two routers. ECMP (Option A) would show the same destination address via different paths, not the same two IPs alternating — and ECMP would not repeat the same two addresses indefinitely. HSRP (Option C) involves virtual IPs, not the physical router interface addresses. The fix requires identifying which router has the incorrect static route and removing it so the correct dynamic routing protocol route can take over forwarding.

5. `show ip ospf neighbor` shows R3 as a neighbour but the state is `2WAY/DROTHER` instead of `FULL/DR` or `FULL/BDR`. Is this a fault and what does it indicate?

A. Yes — 2WAY means the adjacency is only half-formed. Run clear ip ospf process to force a full re-election B. Yes — DROTHER means the router failed DR/BDR election and cannot exchange LSAs. Change the OSPF priority to 255 to become DR C. No — on a multi-access (Ethernet broadcast) network with more than two routers, only the DR and BDR form FULL adjacencies with all other routers. Non-DR/BDR routers (DROTHERs) form only 2WAY relationships with each other — they exchange LSAs exclusively through the DR/BDR. 2WAY/DROTHER is the correct and expected state between two DROTHERs on a broadcast segment D. Yes — 2WAY indicates the dead timer is about to expire. Reduce the hello interval to stabilise the adjacency

Correct answer is C. OSPF on multi-access (broadcast) networks uses a Designated Router (DR) and Backup Designated Router (BDR) to reduce LSA flooding. All routers form FULL adjacencies with the DR and BDR — these show as FULL/DR or FULL/BDR in the neighbour table. However, DROTHERs (routers that are neither DR nor BDR) only form 2WAY relationships with each other. They do not exchange full LSA databases directly — instead, they send updates to the DR/BDR (multicast 224.0.0.6) and receive the DR's flooded updates (multicast 224.0.0.5). So 2WAY/DROTHER is the expected, correct, and healthy state for two non-DR/BDR routers on the same Ethernet segment. The confusion arises from comparing this to point-to-point links where FULL/- is the only valid end state (no DR election on P2P links).

6. R1 has the static route `ip route 0.0.0.0 0.0.0.0 10.0.12.2` and also `ip route 192.168.30.0 255.255.255.0 10.0.12.2`. Traffic to 192.168.30.10 is being forwarded — which route is used, and why?

A. The default route — it was configured first and therefore has higher priority in the routing table B. Both routes match, so IOS uses the default route as a tiebreaker fallback whenever a specific route also exists C. Neither — two static routes to the same next-hop cancel each other out D. The specific route 192.168.30.0/24 — longest prefix match always wins before AD is compared. The default route (0.0.0.0/0) is a /0 prefix. The specific route is a /24 prefix. A /24 is a longer (more specific) match than /0 for the destination 192.168.30.10 — IOS always selects the most specific matching prefix regardless of route source or AD

Correct answer is D. Longest prefix match is the first and most important rule in IP forwarding — it applies before administrative distance and before metrics. For destination 192.168.30.10: the default route (0.0.0.0/0) matches with a prefix length of 0 — the least specific possible match. The specific route (192.168.30.0/24) matches with a prefix length of 24 — a much more specific match. IOS selects the /24 route. Only if there were no specific route would the default route be used. This is why a default route is called the "gateway of last resort" — it is only used when no more specific route exists. AD comparison only occurs between routes from different sources that have the same prefix length (e.g., two /24 routes to the same network from different protocols).

7. R3's ARP table has no entry for 192.168.30.10 (PC3), even though R3's Gi0/1 is configured as 192.168.30.1/24 and PC3 is reported to have IP 192.168.30.10. What is the most likely Layer 3 cause and how is it confirmed?

A. PC3 has an incorrect subnet mask — if PC3's mask is /30 instead of /24, PC3 believes 192.168.30.1 (the gateway) is not on its local subnet. PC3 will not ARP for the gateway directly and traffic cannot flow. Confirmed by checking PC3's NIC configuration (ipconfig /all on Windows, ip addr on Linux) and verifying the mask matches R3's /24 B. R3's OSPF is not advertising 192.168.30.0/24 — the missing ARP is caused by the route not being in R3's routing table C. PC3's default gateway is set to the wrong IP — ARP will not resolve until the gateway IP is corrected D. The ARP table has timed out — run clear arp on R3 to force ARP refresh

Correct answer is A. ARP operates at Layer 2 but is triggered by Layer 3 reachability decisions. When PC3 wants to send a packet to its default gateway (192.168.30.1), it first checks whether 192.168.30.1 is on its local subnet by ANDing its own IP and the destination IP with its subnet mask. If PC3 has a /30 mask (255.255.255.252), its local subnet is 192.168.30.8/30 — 192.168.30.1 is outside this range, so PC3 tries to route through its default gateway to reach 192.168.30.1. But 192.168.30.1 IS the gateway — PC3 needs to ARP for it directly. The /30 mask causes PC3 to treat its own gateway as a remote host, breaking ARP. An empty ARP table on the router for a connected host almost always means the host is not sending ARP requests to the router — caused by a mask mismatch, wrong IP, or physical Layer 1/2 issue. Clearing the ARP table (Option D) would not help if PC3 never ARPs for the router in the first place.

8. What is a floating static route and when would you use one in a troubleshooting or design context?

A. A static route that automatically updates its next-hop IP when the network topology changes — it "floats" to the best available path B. A static route configured with a manually higher-than-default administrative distance (e.g., 254) so that it only becomes active when the preferred dynamic routing protocol route disappears. Used as a backup path — for example, a backup ISP route that only activates if the primary OSPF or BGP route goes down C. A static route applied only to a specific VRF — it floats between VRFs depending on the source interface D. A static route with a /0 prefix length — the default route that floats to any destination not matched by a more specific route

Correct answer is B. A floating static route is configured with a higher administrative distance than the primary dynamic routing protocol so it is not installed in the routing table under normal conditions. For example: ip route 192.168.30.0 255.255.255.0 10.0.99.1 254 — the AD of 254 means this route loses to OSPF (AD 110), EIGRP (AD 90), RIP (AD 120), or any other dynamic protocol for the same prefix. The floating static only becomes active when the dynamic route disappears (neighbour down, process stopped) — at which point the floating static is installed as a backup. This pattern is used for backup connectivity (dial-on-demand backup links, secondary ISP connections) where the backup path should be completely dormant when the primary is healthy. In troubleshooting, if a floating static unexpectedly appears in the routing table, it means the primary dynamic route has failed — investigation should focus on why the dynamic routing protocol lost that route.

9. OSPF is configured on R2 and R3, but 192.168.30.0/24 does not appear in R2's routing table even though the OSPF neighbour is FULL. What are the two most likely causes?

A. The OSPF process ID is different on R2 and R3 — process IDs must match for routes to propagate B. R3's loopback interface is not configured — OSPF requires a loopback for the Router ID before it advertises routes C. The 192.168.30.0/24 network is not included in R3's OSPF network statement — R3 is not advertising it. Or a static route on R2 for the same prefix (AD 1) is installed, hiding the OSPF route (AD 110) even though OSPF learned it D. The OSPF cost on R3's Gi0/1 is too high — routes with cost above 65535 are not installed in the routing table

Correct answer is C. When an OSPF neighbour is FULL but a specific route is missing from a router's table, the investigation has two branches. First: is R3 actually advertising 192.168.30.0/24? Check with show ip ospf database on R2 — if the LSA for 192.168.30.0/24 is not in R2's OSPF database, R3 is not advertising it. The most common cause is a missing or incorrect network statement in R3's OSPF process — the wildcard mask may not include the 192.168.30.x range. Second: if the LSA is in the database but not in the routing table, a lower-AD route is hiding it — typically a static route for the same prefix. Check show ip route 192.168.30.0 to see which source is installed. OSPF process IDs (Option A) are locally significant — they do not need to match between routers and have no effect on route propagation. A loopback (Option B) is a best practice for Router ID stability but is not required for OSPF to operate or advertise routes.

10. An engineer needs to verify why traffic from 10.0.23.6 (R3's WAN interface) to 192.168.10.10 (PC1) is failing on R2, even though R2 has a static route `S 192.168.10.0/24 [1/0] via 10.0.12.1` in its table. What is the correct diagnostic sequence?

A. Run debug ip routing to trace route table changes, then debug ip packet to see every packet R2 forwards B. Run show ip ospf neighbor to check if OSPF is healthy, then show ip ospf database to confirm LSAs C. The static route must be wrong — delete it and let OSPF take over, then re-test D. (1) ping 10.0.12.1 source GigabitEthernet0/1 from R2 — verify the next-hop 10.0.12.1 is reachable from R2's WAN interface. If it fails, the static route's next-hop is unreachable and IOS will not use it. (2) show ip route 192.168.10.0 — confirm the route is installed and check the exact next-hop and exit interface. (3) ping 192.168.10.10 source GigabitEthernet0/1 — test R2 forwarding to PC1. (4) If that works but R3-originated traffic fails, check R3's routing table for 192.168.10.0/24 with show ip route 192.168.10.0 on R3

Correct answer is D. This is a methodical, layered diagnostic sequence that isolates the problem step by step without guesswork. Step 1 verifies the static route's next-hop is actually reachable — a static route to an unreachable next-hop is silently not installed in the FIB (or is installed but cannot forward). A static route with an unreachable next-hop may appear in the routing table but produce black-holed traffic. Step 2 confirms the route details are correct. Step 3 tests R2's ability to forward to the destination — isolating whether the problem is on R2 or downstream. Step 4 shifts focus to R3 if R2's forwarding is confirmed working — the problem may be that R3 has no route to 192.168.10.0/24 and cannot initiate return traffic. Option A (debug ip packet) is too verbose and resource-intensive for initial diagnosis. Option C (deleting the static route) could cause an outage before the root cause is understood.

Back to Home