-
Notifications
You must be signed in to change notification settings - Fork 2
property verification
Pre-Alpha. This page describes behavior that may change.
Property verification is the part of ze-chaos that turns "did the run finish without crashing" into something useful. While faults are being injected and peers are churning, a set of validators watches the state transitions and asserts protocol-level invariants that must hold regardless of the fault sequence. If any of them fails, the run fails, and the dashboard shows which property caught it.
The deeper material (each property's exact state machine, its violation conditions, and how new properties are added) lives in the source under main/internal/chaos/.
A property is a function that receives every event from the reporter and maintains its own state. On every event it decides whether the invariant still holds. If it does not, it emits a violation with a reason, the peer involved, and the event that triggered it. The orchestrator collects the violations, the dashboard shows them live, and the run exits with a non-zero exit code at the end.
The function signature is stable: a property is a report.Consumer with an extra "violations" output. This means properties plug into the same event fan-out as the terminal dashboard, the JSON log, the Prometheus exporter, and the web dashboard. Everyone sees the same events.
ze-chaos --properties all enables every property. The list today.
| Property | What it asserts |
|---|---|
convergence-deadline |
Every route that should reach a peer eventually reaches it, within the convergence deadline. |
route-consistency |
The RIB and every peer's Adj-RIB-Out agree after recovery. |
no-duplicate-routes |
No peer receives duplicate announcements for the same prefix. |
hold-timer-enforcement |
Hold timers are enforced correctly under fault conditions. |
message-ordering |
Messages are delivered in the correct order. |
ze-chaos --properties list shows the current list from the running binary. Adding a property in code makes it appear here automatically, because the list is built from the registration and not from a static file.
A few of the properties take parameters. The most common is the convergence deadline.
ze-chaos --properties convergence-deadline --convergence-deadline 5sConvergence uses the deadline as the upper bound on how long a route can take to reach every expected peer. A longer deadline catches fewer bugs but is more realistic for runs with high fault rates; a shorter deadline catches more bugs but produces false positives under heavy chaos. The default is tuned for --chaos-rate 0.1.
A failing property is the signal that the chaos run found something real. The failure appears in three places simultaneously: the dashboard property badge flips red, the stderr log prints a one-line violation, and the event log records the violation with full context.
The debugging loop is the one that makes the tool worth building:
- Record the failing run with
--event-log run.ndjson. - Replay it deterministically with
--replay run.ndjsonto confirm the failure reproduces. - Shrink it with
--shrink run.ndjsonto reduce the scenario to its minimal reproduction. - Commit the shrunk scenario as a test.
- Fix the bug. The test stays in the suite.
New properties live under main/internal/chaos/validation/. Each one implements the Property interface, registers itself in init(), and immediately appears in --properties list. The existing properties are the best reference for the shape of a new one.
The rules of thumb, from the existing code:
- A property must be cheap. It runs on the main event loop and cannot block on I/O or long computations.
- A property must be self-contained. It cannot reach into other properties' state or the orchestrator's internals.
- A property must emit a violation with enough context to reproduce the failure without needing the full event log.
- Scenarios for how to configure and run property-validated scenarios.
- Dashboard for the live view of property state during a run.
- In-tree chaos testing guide for the current authoritative reference.
-
main/internal/chaos/validation/property.goin the repo for thePropertyinterface.
Unreviewed draft. This wiki was authored in bulk and has not been reviewed. File corrections on the issue tracker.
- Overview
- YANG Model
- Editor Workflow
- Archive and Rollback
- System
- Interfaces
- VRRP
- BFD
- FIB
- OSPF
- IS-IS
- MPLS / LDP / RSVP-TE
- RSVP-TE
- SRv6
- Static Routes
- Policy Routing
- Firewall
- Traffic Control
- Class of Service
- L2TP/PPP
- PPPoE
- VPP Data Plane
- RPKI
- IPsec VPN
- TACACS+ AAA
- RADIUS AAA
- AS112 DNS
- Authorization
- Fleet
- BGP
- Starting and Stopping
- Show Commands
- Monitoring
- Flow Export
- DDoS Mitigation
- Anomaly Detection
- Health Checks
- Audit Trail
- Production Diagnostics
- Logging
- Operational Reports
- Healthcheck
- Self-Update
- Zero-Touch Provisioning
- MRT Analysis
- Upgrade and Restart
- Storage
- Policy
- Core
- Resilience
- Validation
- Capabilities
- Address Families
- Protocol
- Subsystems
- Infrastructure
- Route Server at an IXP
- Transit Edge with RPKI
- Public Looking Glass
- ExaBGP Migration Walkthrough
- FlowSpec Injection
- Chaos-Tested Peering
- AS Path Topology