What Happens If I Break This?

The first eight posts in this series were about getting the model right: discovering the network without becoming part of it, reproducing forwarding hop by hop, refusing to guess, and finding out the hard way when my own tool was drawing fiction.

All of that is preparation. A network model that is merely accurate is a very expensive photograph. The reason to spend that effort is so you can ask it the question you cannot ask the real network:

What happens if I break this?

That question decides maintenance windows. Somebody has to say whether pulling a card at 03:00 is survivable, and normally they answer it from a mental model and the memory of the last outage. What follows is not interesting because Osprey has a simulator. It is interesting because the failure no longer has to happen before you can reason about it.

---

Seven things you can change

Osprey’s simulation mode takes the live model, clones it, applies mutations, and recomputes. The complete list of things it will let you change is short, and the shortness is deliberate:

Mutation	What it does
link_failure	Take a link down
node_failure	Take a router down
cost_change	Re-metric a link, forward and reverse independently
hypothetical_link	Add a link that does not exist, with a cost and a speed
hypothetical_node	Add a router that does not exist
srlg	Fail a shared-risk group: one action, N correlated link failures
peer_failure	Drop a BGP session

Anything else is rejected with unknown mutation type. There is no area-restructuring mutation, no redistribution mutation, and no cascading-failure mutation, because I could not implement any of them without inventing data. I will come back to that.

---

One cable, and what the network does about it

Here is a real one from the lab. nrt1-cr1 ↔ sea1-cr1 is a trans-Pacific backbone link in AS 200, cost 10 under OSPFv2, one of the 275 links Osprey holds across that tenant’s two OSPF instances. I right-clicked it and chose Simulate Failure:

Read the three numbers across the top. Nothing became unreachable. 56 paths changed. No new single point of failure appeared. The whole evaluation took 57 ms, server-side.

Now read the Failed Links header, because it is doing something people miss: 2 links. I clicked one cable and Osprey failed two links, because that cable carries OSPFv2 and OSPFv3 as two independent protocol instances with two independent costs. Failing the wire fails it in both. A tool that models one edge per cable has to decide which of its two lives to end.

The interesting part is the breakdown of those 56:

• 15 increased: the path got more expensive. sea1-cr1 → nrt1-cr1 goes from cost 1 to cost 11, the direct link replaced by a three-hop path.
• 41 rerouted: the path changed hops and the cost did not move at all.

That second number is the one worth staring at. Forty-one source/destination pairs took a different route through the network and paid nothing for it, because an equal-cost alternative was already there. That is what redundancy looks like when you express it as a measurement instead of an adjective. “We have diverse paths” is a claim. “41 of 56 affected pairs reroute at identical cost” is a number, and it is the number that tells you whether the maintenance window needs to be at 03:00.

Nothing here was typed into a router. The lab did not lose a link. I asked the model.

---

The refusal at the top of the screen

Now look at the amber banner in that first screenshot, because it is an admission, and it is the reason I trust the rest of the panel:

simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view

Post three was an argument that a source-rooted corridor is the wrong model of IP forwarding, backed by a measurement: 360 of 2,839 inter-area router pairs had a corridor containing a hop no packet would ever take. I replaced that engine with one that walks every router’s own routing table, and validated it against all 4,032 pairs.

And then, in simulation, I deliberately do not use it.

The reason is in the code, and it is the sentence I am proudest of in this product:

// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.

Walking each router’s own table requires knowing what each router’s table would be after the change. In OSPF that depends on the Type-3 summary-LSAs the surviving ABRs would re-originate: LSAs that do not exist, because the failure has not happened. I can guess them. I cannot guess them correctly, and a hop-by-hop chain built on guessed summaries would carry all the authority of the validated engine and none of the validation.

So both sides of the comparison stay on the clearly-labelled projection. The before-picture is deliberately made worse so that it still matches the after-picture. A “56 paths changed” that is really “36 genuine changes plus 20 artefacts of the two sides using different engines” is not a diff. It is noise with a number on it.

---

EIGRP: the ceiling is my data, not the protocol

Fail something in the EIGRP tenant and Osprey stops rather than projecting:

the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.

EIGRP has no link-state database to recompute against. What Osprey has is each router’s own topology table read from CISCO-EIGRP-MIB, and those twelve columns carry the DUAL distances (feasible distance, computed distance, reported distance), not the components the distances were built from.

To recompute DUAL after a change you need minimum bandwidth, total delay, reliability, load, MTU and hop count. Those exist on the box; I checked, on e-ams1-cr1, with show ip eigrp topology 10.64.0.0/15. They are simply not in the MIB table Osprey reads.

That distinction is written into the code comment on purpose:

// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.

There is a real difference between “this protocol cannot be simulated” and “I do not currently collect the inputs”, and a product that blurs them is quietly telling you not to bother asking again. This one is a data-collection ceiling, and it is liftable. When I lift it, the message goes away.

There is a smaller, sharper rule underneath it. If the mutation is a pure removal (a link or node failure), and the removed thing is provably not on the observed chain, Osprey keeps showing the real chain and says why: “observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)”. Removing capacity somewhere else can never improve a distance-vector path that did not use it. But a cost change or a new link can attract a path from anywhere, so those always count as touching. The engine refuses precisely when it has to, not categorically.

---

What is not in the mutation list, and why

The seven mutations are what I could implement without fabricating inputs. The ones that are missing are missing for stated reasons:

• Area restructuring. Moving an ABR or redrawing an area boundary changes which summary-LSAs exist at all. That is not a mutation of the topology, it is a different topology.
• Redistribution changes. They depend on route-maps and prefix-lists that Osprey has no visibility into. I would be modelling a policy I cannot read.
• Cascading failures. Predicting the second failure requires queue and TCP dynamics that a topology tool has no business claiming to model. Flag the risk; do not predict the cascade.

Each of those would demo beautifully. Each would be a number with nothing behind it.

---

The point

Simulation is where a topology product either earns the modelling work or exposes it. Every shortcut taken in the data model shows up here as a confident wrong answer, because a what-if has no ground truth to be checked against. The failure has not happened, so nothing can contradict you. That is exactly why it is the feature most worth being careful in.

The honest version is less impressive per screenshot and considerably more useful at 03:00: seven things you can change, four numbers that come out, and a banner explaining which engine produced them.

---

Next: one link fails, but which parts of the network actually depended on it? The Blast Radius.