The Protocol With No Database
Three different kinds of nothing: no database to join, a database nobody implements, and a table with the answers but not the inputs
Michel Wijnberg
The last two posts were about joining a link-state protocol carefully: getting in without becoming a path, getting out without leaving a ghost. Both assume there is something to join.
This one is about the cases where there is not, and they are not all the same case. I have three, and they fail in three genuinely different ways.
One: there is no database
EIGRP is an advanced distance-vector protocol. Neighbours exchange reachability and distance information; they do not maintain a shared link-state database. There is no synchronised copy that every router holds, so there is nothing to synchronise with. The join move from the previous two posts does not exist here, because the thing you would join was never built.
What does exist is each router’s own view: its neighbours, and its topology table of
destinations with the distances it has computed. That is read over SNMP, from
CISCO-EIGRP-MIB, one router at a time, and the adjacency graph is reassembled from
what each router says about its own neighbours.
Reassembled, not read. Nobody in the network holds the picture. It only exists once you have asked everyone and put the answers together, which is a different epistemic position from reading an LSDB, and worth being honest about even when the resulting graph looks identical.
The neighbour who will not say who they are
Then a specific problem, and it is a nice one.
An EIGRP neighbour entry gives you the neighbour’s address. For IPv6 that address is link-local, and a link-local address identifies an interface on a link. It does not identify a device. Two routers on opposite sides of the network can carry the same link-local address without any conflict, because the scope is the link.
So the neighbour table tells you something is over there and declines to tell you what.
The resolution comes from a different layer entirely: the LLDP and CDP adjacencies already discovered for that device, indexed by interface. Match the EIGRP neighbour’s interface against the L2 neighbour on the same interface and you learn which device is on the far end.
Which means an EIGRP edge in Osprey is, underneath, two independent observations agreed: the routing protocol saying an adjacency exists, and the link layer saying who is at the other end. When the L2 data is missing, the neighbour stays unresolved. It is not guessed from addressing, not inferred from naming, not matched on a subnet. An edge that cannot be attributed to a device does not become an edge.
Two: the table has the answers but not the inputs
The EIGRP topology table is where the second kind of nothing lives, and it is the one that produced a refusal in the product.
The table has twelve accessible columns. Between them they carry DUAL’s distances: the feasible distance, the current computed distance, the distance a successor reported, plus successor counts and next-hop state. That is enough to show you what each router currently believes, and the first post in this blog shows exactly that: each router’s own number, decreasing along a chain.
It is not enough to compute anything new.
To recompute a metric after a hypothetical change you need the components the reported
distances were derived from, and the interface state behind them. Those are on the
router: ask e-ams1-cr1 for show ip eigrp topology 10.64.0.0/15 and it prints minimum
bandwidth, total delay, reliability, load, MTU and hop count for that prefix, which is
how I know they exist rather than inferring it.
They are not in the MIB table being read. The twelve columns carry what DUAL decided. The router keeps what DUAL decided it from, and does not publish it here.
So Osprey refuses. Ask it to simulate a failure in an EIGRP domain and it declines to project a new chain, and says why: it cannot predict DUAL re-convergence, because the tables it reads carry the distances and not the metric components a recomputation needs.
Two things about that refusal matter more than the refusal itself.
It is scoped to what we read, not to the protocol. The message is written to say that this is a data-collection ceiling, not a property of EIGRP, because a future enricher that reads the components from somewhere else would lift it. A product that says “EIGRP cannot be simulated” is quietly telling you never to ask again, which is a different and much worse statement than “I do not currently collect the inputs”.
It is precise about when it fires. If the simulated change is a pure removal, and the removed thing is provably not on the observed chain, the real chain is still shown, with a note saying the failure does not touch it. Taking capacity away somewhere else cannot improve a distance-vector path that was not using it. But a cost change or a new link can attract a path from anywhere, so those always count as touching. The engine refuses where it has to, not categorically, and the difference is the whole value of the refusal.
Three: the database exists in the standard and nowhere else
The third kind of nothing is the most frustrating, because it is nobody’s bug.
IS-IS has a standard MIB: RFC 4444, at .1.3.6.1.2.1.138. Osprey’s SNMP discovery probes
that tree first, and only falls back to the Cisco tree at
.1.3.6.1.4.1.9.10.118. The two OID sets share a base-relative column layout and differ
only where the MIBs genuinely differ, which is one circuit-column shift; the adjacency
columns are identical. The design is deliberately vendor-neutral.
The standard path has never been proven against real hardware.
Not because it is untested in the unit sense: it has tests. Because every device we can
reach implements only the Cisco tree. Probe a lab router for the standard .138 tree and
it returns No Such Object. The vendor-neutral code path is exercised by fixtures and by
nothing else, and I would rather write that sentence than let it be discovered.
Then Arista made it worse, in an instructive way. Probing vEOS-lab 4.29.2F on the
services pod: the standard .138 tree returns No Such Object, and so does the Cisco
.9.10.118 tree. Neither. The device speaks IS-IS perfectly well and there is no SNMP
tree to ask about it at all.
The same agent serves OSPF-MIB happily, and LLDP-MIB, and registers the OSPF tree dynamically once OSPF is configured. So the honest answer for those nodes is not “IS-IS discovery failed” and it is certainly not an empty topology. It is this device cannot be asked this question, and the pod’s leaves are consequently discovered over OSPF instead.
I am not going to turn that into a claim about the market, because two vendors is not a survey. What I can say is bounded and still useful: across every device we have been able to test, the standard MIB was not implemented, and the Cisco enterprise MIB was the only tree that exposed the data at all. A standard nothing we can reach implements is not a standard we can build a promise on.
The menu is the honest version of this post. Four reports are unreachable here because they read a database that does not exist, and each greyed-out entry carries its own reason on hover rather than opening onto an empty table. EIGRP gets its own entry instead, because what it can answer is a different question.
Three kinds of nothing
Put them side by side, because a product that treats them identically is lying about at least two:
| What is missing | The temptation | What it does instead |
|---|---|---|
| no database to join | invent a topology source | reconstruct from every router’s own view, and label it |
| the inputs, not the answers | assume default bandwidth and delay | refuse to simulate, and name the ceiling as ours |
| the MIB itself | return an empty topology | say this device cannot be asked, and use the tree it serves |
Read the middle column. Every one of those produces a screen that looks exactly like the screen you get when the data was really there. That is the whole problem with filling gaps: the output has no way to tell you which parts of it were observed.
The point
The first two posts in this series were about being a careful guest in someone else’s protocol. This one is about the rooms you are not let into at all.
Being a good guest there means something different: not finding a way in, but saying precisely which door was locked. An unresolved EIGRP edge, a simulation that declines, a device that cannot be asked. Three refusals, each naming its own cause, none of them dressed up as an answer.
Next, and last in this series: the one source that comes to you rather than waiting to be asked, and the two ways that changes what you can believe. Push, Don’t Poll.