No change without a dry run

A digital twin of a network is a software model built from the real configurations and topology: devices, interfaces, routing protocols, policies. Tools such as Batfish and Containerlab, and the vendors' own virtual images, let us apply a candidate configuration to the twin and see the predicted state and routes before the change window.

In practice three things come out of every twin run. A candidate configuration validated against the current production state. A simulated post-change state, compared with the current one so unintended differences show up as a diff. And predicted routes and reachability, checked against the flows the application teams care about.

The result is cutovers without surprises. On programs where the twin is part of the pipeline, the number of rollbacks used to date is zero — not because nothing was ever wrong, but because the twin found it on a Tuesday afternoon rather than at two in the morning.