The problem
When a network breaks, the honest description is usually this
The connection dropped at 10:43 and we do not know why.
The evidence is scattered across switch logs, firewall logs, DHCP and DNS, each with its own clock and its own format — and most of it has already rolled over by the time anyone looks.
So the engineer guesses, swaps a cable, restarts a service, and the fault comes back in two days.
The intermittent fault is worse
It drops for ninety seconds every couple of days, at no particular time.
There is no practical way to be watching when it happens. Packet capture fills the disk in an hour.
So it goes unsolved for months.
Put every state change on one timeline, at nanosecond resolution, and the story assembles itself:
10:41:58 a second DHCP server appeared on 192.168.20.99 10:42:17 nine hosts took a different default gateway 10:42:19 34% packet loss outbound 10:42:23 41 TCP connections to Server X dropped 10:47:12 ended - port Gi0/14 was shut manually
Who it is for
Anyone who has been asked what happened and had nothing to point at
Whoever gets asked afterwards
The outage ended before you were paged, and someone still expects an answer on Monday. The only thing that can give you one is a recorder that was already running when it happened.
Small teams without a SIEM
The tooling for this layer is either ancient and contextless, or an enterprise platform with a budget to match. This is one binary on one host, and it costs nothing.
Networks the container era skipped
Modern eBPF observability is aimed at Kubernetes. VLANs, ARP, DHCP, routing and switch ports were left with SNMP and NetFlow. This is built for that layer.
How it differs
None of these are bad tools. They answer other questions.
Each of these is better than NetRewind at what it was built for. The gap is not capability, it is the question being asked.
| Tool | What it gives | What it does not |
|---|---|---|
| NetFlow / ntopng | Traffic statistics | No causal context, no L2/L3 state |
| Zeek / Arkime | Rich logs from a SPAN port | Heavy storage; blind to state and config changes |
| Cilium / Pixie / Retina | Excellent eBPF observability | Built for containers and Kubernetes; know nothing about VLANs, ARP or switches |
| SIEM | Log aggregation | Large infrastructure, and the correlation is still your job |
| SNMP / Nagios | "The interface is down" | One instant, no history, no cause |
The gap NetRewind aims at: light, agentless, aware of the ordinary enterprise LAN, and producing a causal narrative rather than a wall of alerts.
Status
Layers 1 to 4 recorded, correlated, and proven end to end
Interface state, neighbour tables, routes and addresses come from netlink. Connection outcomes come from two eBPF programs on stable kernel tracepoints. Filtering changes come from polling the nftables ruleset. DHCP, DNS and ICMP metadata come from a filtered packet socket, and reachability from ICMP probes measured against a baseline. Nineteen correlation rules read the result.
The lab runs fourteen scenarios: thirteen injected faults, plus a stretch of ordinary successful traffic — because a recorder that has only ever seen breakage has proven nothing about its baseline. The run then gates itself twice. First, that every injected fault is findable in the record. Second, and separately, that correlation reached the right conclusion rather than merely having the evidence available to reach one. A GNS3 topology of Cisco routers and switches covers what namespaces cannot: real VLANs, real OSPF, and a gateway address moving between two physical routers.
sudo make labok gateway-hijack concludedok contested-address concludedok default-route-moved concludedok default-route-lost concludedok service-unreachable concludedok change-broke-a-path concludedPASS: every injected fault was reconstructed, and correlation named the cause
That second gate is the one that matters. Having the evidence in the store and drawing the right conclusion from it are different achievements, and only the first is easy.
Roadmap
- M0
- Envelope, store, interface state, CLI
- done
- M1
- Neighbours, routes, addresses; temporal identity; narrative queries; fault-injection lab
- done
- M2
- eBPF connection observation, rollups, system.drop
- done
- M2b
- nftables rule changes; resets and timeouts from a second tracepoint
- done
- M3
- Isnad correlation engine with backward cause matching, nineteen-rule library
- done
- M4
- GNS3 lab: OSPF core, real VLANs, a trunk, the recorder on an access port
- done
- M5
- Web interface, Prometheus and OpenTelemetry export, releases for amd64 and arm64, a bootable appliance
- done
- M5e
- Self-update from signed releases
- done
What is left is conntrack, so a recorder at the gateway sees the connections it forwards and not only its own, and LLDP and SNMP for switch-side topology. Both are named in the changelog rather than implied to exist.
Known limitations
The things it cannot do, stated rather than papered over
A recorder that silently omits what it missed is not evidence of anything: the record would show a quiet network, and a quiet network is what an operator concludes when nothing is wrong. That principle is enforced in the code, and it applies to this page too.
- It sees what reaches it
- Where you put the recorder decides what the record is worth. At the gateway it sees everything crossing the boundary; on a mirror port it cannot see the gateway’s own routing and filtering decisions; as one host on a segment it does not see conversations it is not part of. The runbook sets out what each position costs.
- Connection outcomes are host-local, and switches are invisible
- The tracepoint sees this host’s sockets, so a recorder at the gateway sees its own connections rather than the ones it forwards — that needs conntrack, which is not built. LLDP and SNMP are not collected either, so what a switch knows about its own ports stays outside the record.
- MAC randomisation breaks long-term device tracking
- Phones randomise their hardware address per network, so the identity table cannot follow a mobile device across weeks. DHCP client-id and behavioural fingerprinting narrow the gap; they do not close it.
- The filtering collector polls every five seconds
- A rule added and reverted inside one interval leaves no trace. Parsing nft monitor instead would break whenever nft changes how it prints — and a recorder that stops recording without saying so is the failure this exists to prevent. The poll is the lesser evil.
- It has not run on a production network
- Everything shown here happened in Linux network namespaces or on a GNS3 topology of Cisco routers and switches. The Windows collectors were also exercised on a real physical machine — a real adapter flapped, a real incident diagnosed — but neither has run on a live production network. Real networks bring vendor quirks, scale, and failure modes a lab does not produce. Treat this as a proven approach rather than an operational track record.
One shipped rule exists purely to say this out loud during an incident: recorder-was-blind fires on system.gap or system.drop at 100% confidence, and its advice is that nothing can be concluded about that period from this recorder.
Licence and privacy
Free software, and it stays that way
AGPL-3.0. Run it on as many machines as you like, for as long as you like, commercially or not, with nothing to buy and nobody to ask.
The source is the product
Every line is published. The obligation the AGPL adds is narrow: if you modify NetRewind and offer that modified version to others over a network, publish your changes too. Running it on your own network, modified or not, obliges you to nothing.
No account, no telemetry
It does not report usage anywhere. The only outbound request it makes is a daily check of the GitHub release feed to see whether a newer version exists — one HTTPS request, and a single line of config turns it off.
It will not update itself behind you
Installing an update is off by default. This recorder produces evidence, and a machine that rewrites its own binary unasked is a change of trust rather than a convenience. Turn it on if you want it.