OSPF

Using the capture alone, work out why the adjacency never reaches Full.

Four routers come up and discover each other. Watch the neighbour table climb through Init, 2-Way and Full — and note that the very first hello carries an empty neighbour list, which is exactly what makes the second one meaningful.

Each router describes only its OWN links, floods that description, and acknowledges what it receives. Open the LSDB tab on any two routers and compare them — they converge to the same four entries, and each one then does its own arithmetic.

Two paths to the branch, both exactly two router hops. OSPF takes the southern one because it costs 10 against 20. Hop count never enters into it — a fact that separates OSPF from the distance-vector protocols that came before it.

The southern path is winning. An operator raises R1's cost toward R3 from 5 to 50 — the link stays up, nothing is withdrawn — and the traffic moves north. Not one route was configured anywhere; the graph simply changed and everyone recomputed.

The southern link goes down mid-capture. R1 re-describes its links, floods the change, and every router recomputes — arriving at the northern path without a single instruction being sent. Compare how fast this is against a neighbour that dies silently.

R3 is configured with a 5-second hello where everyone else uses 2. Both routers send hellos forever, neither reports an error, and the adjacency never forms. Read the rejection note — then check how you would have found this in a real capture.

R3 has OSPF switched off. It is cabled, powered and forwarding — and completely absent from everyone's database, so the cheap southern path might as well not exist. Traffic takes the expensive route and nothing anywhere reports a fault.

R1's office interface is passive. Count the hellos on the office LAN — there are none — and then look for 10.0.1.0/24 in R4's table, where it appears anyway. The network is advertised because the interface is in OSPF; no adjacency can form because no hello is ever sent.

R3's interfaces are configured for jumbo frames and everyone else's are not. The neighbours find each other, agree on every timer, and then refuse each other's Database Descriptions because the MTU in them does not match. Read the rejection, then check which path the traffic takes instead.

The office journeys stop at the gateway. This one starts before it: two routing protocols fill one routing table, then ARP and DNS do their usual jobs, then an application opens a connection across the result. Nothing in the application's packets refers to a routing protocol — and that is what the routing protocols are for.

Two captures of one network. In the first, the routers talk only to each other and no user traffic exists at all. In the second, user traffic crosses the network — while the routing protocols carry on saying hello in the background, because they never stop. Not one of their packets carries a byte of anybody's data. OSPF and BGP create forwarding information; the routing table selects a path; IP forwards packets; TCP, TLS and HTTP carry the application. Each of those depends on the one before it having already finished.

External sites load. The internal application server does not respond at all. That split — outside works, inside does not — narrows this before you open a single packet.

The circuit to the provider is up and the interface counters climb. Nothing outside the company is reachable, and the internal network is completely unaffected.

Every device is up. Every protocol session is established. Every configuration matches the documentation. The application is unreachable anyway — this is the case that teaches what a routing table actually is.