What the bitemporal log makes discoverable

Most network monitoring keeps one timestamp per fact: when we last saw it. That answers “what is on the network right now” and nothing else. The moment a device unplugs, its row is overwritten or expired, and the question “what changed since last Tuesday” stops having an answer.

l2trace keeps two time axes on every observation, valid_during (when the fact was true on the wire) and recorded_during (when we believed it). That second axis is what turns change into a first-class, queryable thing instead of something you reconstruct by hand from logs. Four kinds of change fall directly out of the log.

Moves

A MAC learned on a different (switch, port) than it was on immediately before is a move. Because valid_during is append-only, the old location’s range closes and a new one opens; the transition is a row, with a before, an after, and a timestamp. “Everything that moved between Friday and Monday” is a query, not a diff you assemble from two snapshots.

A move can be benign (a laptop roamed from wireless to a dock) or a signal (a device physically relocated, or, if it bounces between two ports rapidly, a loop or a mis-cabled dual-homed host). The point is that the event exists in the record at all.

Appearances and disappearances

A MAC whose earliest-ever sighting lands inside a window is new to the fabric. A MAC with no currently-open observation whose last sighting closed inside the window is gone. Together they are half an inventory system (what showed up, what was retired) and half a security tripwire (an unfamiliar device appearing on an access port).

The distinction the second time axis buys you here is subtle but important: “we stopped seeing it” is not the same as “it left.” When the collectors are paused (a maintenance window, say), MACs age out and the log faithfully records that the observations stopped, without falsely claiming the devices were removed. A single-timestamp system shows the same drop with no way to tell the two apart.

IP rebindings, and the takeover signal

The same shape applies to the ARP/ND record. An IP that binds to a different MAC than before is a rebinding. Most rebindings are ordinary DHCP: a lease renews, the client keeps its MAC, nothing is wrong.

The interesting case is when the vendor changes. A DHCP renewal keeps the same MAC and therefore the same OUI vendor. An IP suddenly claimed by a different-vendor MAC is what an address takeover or a spoof looks like. l2trace flags exactly that case (vendor_changed) and sorts those rebindings to the top, so the set worth a security review separates itself from the routine churn.

The belief axis: what we thought vs what was true

Everything above reads the current-belief rows, so a correction shows up as the corrected reality rather than the original mistake. But the belief axis supports a question single-timestamp tools cannot even phrase: what did we believe last Tuesday versus what do we now know was true last Tuesday.

A poll that arrived late, or a reconciliation that revised an earlier record, lands as an explicit belief revision, not a silent overwrite. Where the two answers disagree is precisely where the operational picture was wrong and later got fixed, with the timestamp and reason attached. That is the difference between a system that forgets its mistakes and one you can audit.

Where to see it

See what changed — the practical recipe: the Changes surface and the /api/changes endpoint for automation.
The web UI — the Changes and Diff screens in the browser.
Diff a traceroute — the per-flow companion: reconstruct a path at two times and diff it hop by hop.