Zaryn features·5 min read

Digital twin: test a change before you make it

See what a config change would do to your network before anyone types it. Which traffic stops, starts or takes another way and why, every routing table entry that changes, and the single points of failure it creates. On the site page, from the command line, and on every pull request.

You give it the configs as they would be. It answers with:

Which traffic stops working, starts working, or takes another way. Every pair of subnets, every loopback, the flows the changed ACL rules name, your watched paths and probes. Each one is checked hop by hop on the network as it is and as it would be.
Why. The device and the exact rule or route that makes the difference, with the whole walk for both versions side by side.
The change in words. "interface Gi0/1 shut down", "OSPF cost on eth1: default → 100", "EDGE: rule added: deny tcp any host 10.2.0.10 eq 22", "BGP no longer announces 10.2.0.0/24".
Every routing table entry that changes, on every device, not only the one you edited.
Failure drills (Premium). Every device and every link is failed in turn, before and after the change. You get the new single points of failure it creates and the ones it removes.

Nothing is ever sent to the devices. The twin works from what the devices of a site said last.

Try a change on the site page

Open a site, then Try a change. Choose a device: its current config opens in an editor. Edit it, or load a file, and add more devices if the change spans them. Then See what it would do.

Flows that stop working come first, in red. Open one to see Now and With the change hop by hop. Below the results you can explain any path on the twin: ask about any source and destination, on the network as it would be.

From the command line or CI: zev site diff

Terminal

zev site diff acme/hq r1=r1.cfg core-sw=core-sw.cfg

Text

✗ 212 of 214 flows tested behave the same; 1 stop working; 1 take another way. 3 routing table entries change.What changes  r1  EDGE: rule added: deny tcp any host 10.2.0.10 eq 22  r1  OSPF cost on GigabitEthernet0/1: default → 100Stop working  ✗ 10.1.0.100 → 10.2.0.10 tcp/22  (r1 EDGE: added deny tcp any host 10.2.0.10 eq 22)      before: 10.1.0.100 reaches 10.2.0.10 (tcp/22), and the reply comes back      after:  r1 drops it out GigabitEthernet0/2: EDGE rule "deny tcp any host 10.2.0.10 eq 22"Take another way  ~ 10.1.0.100 → 10.3.0.100 icmp  (10.1.0.0/24 → 10.3.0.0/24)      r1 → r3  ⇒  r1 → r2 → r3

It exits with 1 when something stops working (or, with --drills, when a new single point of failure appears), so a CI job can stop a change. --json prints the whole answer. It uses your zev login, or ZEV_SERVER and ZEV_TOKEN in CI.

Pull requests on a config repository

Keep the site's configs in a repository on Zaryn, one file per device, named after it: configs/r1.cfg, configs/core-sw.rsc (the extension is optional: .cfg, .conf, .rsc, .txt, .boot and others). Then, in the site's Collector and settings, link it under Config repository. Only an admin of the repository can link it.

From then on, every pull request that changes a device's file gets the twin:

The pull request shows a network twin check: behaves the same, behaves differently, or breaks things. People who can see the site get the whole answer.
The "before" is the target branch's files (the device's last collected config where there's no file), and the "after" is the pull request's.
Merging waits while traffic would stop working, or while a new single point of failure appears (with Premium's drills).
A repository admin can merge anyway. Zaryn keeps who did it, when, and what the twin said, and the site's Changes shows it.

The twin is worked out again whenever either branch moves.

Failure drills (Premium)

Redundancy is easy to lose without noticing: a link shut "for a while", a route that only exists on one side. The drills fail every device and every link in turn, with the change and without it, and test the flows that work.

New single points of failure: something whose failure would now stop flows that survived it before the change. These hold a pull request back like broken flows do.
No longer single points of failure: the change added redundancy.
Links that were already single points of failure are listed too, so you know where you stand.

How it works

The twin simulates routing from every device's config, twice: with the configs as they are, and as proposed. Only the difference is applied to what the devices said last: their routing tables, interfaces and filters. So:

Routes the simulation can't see, such as a default route learned from your ISP or routes from devices outside the site, stay as they are.
Anything the simulation simplifies is simplified the same way both times, and cancels out.

What it simulates from the configs:

Interfaces: addresses, shutdown and no shutdown.
Static routes, including Null0 and blackhole routes, distances, and next hops resolved through other routes.
OSPF: which interfaces take part (network statements, interface areas, MikroTik templates), costs, passive interfaces, equal-cost paths, redistribution of connected and static routes, and announcing a default route.
BGP between the site's devices: eBGP and iBGP sessions configured on both sides, network statements, redistribution, next-hop-self, and the best path by AS path length, then eBGP before iBGP.
ACLs and firewall rules from the new config: Cisco ACLs and where they're applied, Huawei traffic filters, MikroTik's firewall.

Each vendor's own administrative distances are used. Path Explain then walks each flow through both versions, exactly as it does for Path Explain.

What it doesn't simulate yet

Better to know than to trust it blindly:

OSPF areas are treated as one (no summarization between areas, no stub areas), and OSPF external routes are type 2.
BGP policy: route maps, prefix lists, communities, local preference, MED. Sessions to devices outside the site keep what they learned.
VRFs, policy-based routing, NAT, IPv6, IS-IS, EIGRP and RIP.
Firewall changes on Linux-based devices (FRR, VyOS, Linux): iptables and nftables aren't in the config Zaryn reads, so only their routing changes are simulated.

The answer lists what it rests on, including devices without a config and the flows it had no time to test.

Limits

Up to 400 flows per run. Flows named by changed rules, watched paths and probes go first.
Drills: up to 60 failures over up to 150 flows.
The behavior diff is free on every plan; failure drills come with Premium.

A maintenance window goes wrong when a change does something nobody expected: an ACL line that also blocks backups, an OSPF cost that sends everything over the slow link, a "harmless" shutdown that leaves one router holding the whole office. The **digital twin** shows you that before the change reaches a device. You give it the configs as they would be. It answers with: - **Which traffic stops working, starts working, or takes another way.** Every pair of subnets, every loopback, the flows the changed ACL rules name, your [watched paths and probes](/docs/en/network-paths). Each one is checked hop by hop on the network as it is and as it would be. - **Why.** The device and the exact rule or route that makes the difference, with the whole walk for both versions side by side. - **The change in words.** "interface Gi0/1 shut down", "OSPF cost on eth1: default → 100", "EDGE: rule added: deny tcp any host 10.2.0.10 eq 22", "BGP no longer announces 10.2.0.0/24". - **Every routing table entry that changes,** on every device, not only the one you edited. - **Failure drills (Premium).** Every device and every link is failed in turn, before and after the change. You get the new single points of failure it creates and the ones it removes. Nothing is ever sent to the devices. The twin works from what the devices of a [site](/docs/en/network-sites) said last. ## Try a change on the site page Open a site, then **Try a change**. Choose a device: its current config opens in an editor. Edit it, or load a file, and add more devices if the change spans them. Then **See what it would do**. Flows that stop working come first, in red. Open one to see **Now** and **With the change** hop by hop. Below the results you can **explain any path on the twin**: ask about any source and destination, on the network as it would be. ## From the command line or CI: zev site diff ```bash zev site diff acme/hq r1=r1.cfg core-sw=core-sw.cfg ``` ```text ✗ 212 of 214 flows tested behave the same; 1 stop working; 1 take another way. 3 routing table entries change. What changes r1 EDGE: rule added: deny tcp any host 10.2.0.10 eq 22 r1 OSPF cost on GigabitEthernet0/1: default → 100 Stop working ✗ 10.1.0.100 → 10.2.0.10 tcp/22 (r1 EDGE: added deny tcp any host 10.2.0.10 eq 22) before: 10.1.0.100 reaches 10.2.0.10 (tcp/22), and the reply comes back after: r1 drops it out GigabitEthernet0/2: EDGE rule "deny tcp any host 10.2.0.10 eq 22" Take another way ~ 10.1.0.100 → 10.3.0.100 icmp (10.1.0.0/24 → 10.3.0.0/24) r1 → r3 ⇒ r1 → r2 → r3 ``` It exits with 1 when something stops working (or, with `--drills`, when a new single point of failure appears), so a CI job can stop a change. `--json` prints the whole answer. It uses your `zev login`, or `ZEV_SERVER` and `ZEV_TOKEN` in CI. ## Pull requests on a config repository Keep the site's configs in a repository on Zaryn, one file per device, named after it: `configs/r1.cfg`, `configs/core-sw.rsc` (the extension is optional: `.cfg`, `.conf`, `.rsc`, `.txt`, `.boot` and others). Then, in the site's **Collector and settings**, link it under **Config repository**. Only an admin of the repository can link it. From then on, every pull request that changes a device's file gets the twin: - The pull request shows a **network twin** check: behaves the same, behaves differently, or breaks things. People who can see the site get the whole answer. - The "before" is the target branch's files (the device's last collected config where there's no file), and the "after" is the pull request's. - **Merging waits** while traffic would stop working, or while a new single point of failure appears (with Premium's drills). - A **repository admin can merge anyway**. Zaryn keeps who did it, when, and what the twin said, and the site's Changes shows it. The twin is worked out again whenever either branch moves. ## Failure drills (Premium) Redundancy is easy to lose without noticing: a link shut "for a while", a route that only exists on one side. The drills fail every device and every link in turn, with the change and without it, and test the flows that work. - **New single points of failure:** something whose failure would now stop flows that survived it before the change. These hold a pull request back like broken flows do. - **No longer single points of failure:** the change added redundancy. - **Links that were already single points of failure** are listed too, so you know where you stand. ## How it works The twin simulates routing from every device's config, twice: with the configs as they are, and as proposed. Only the **difference** is applied to what the devices said last: their routing tables, interfaces and filters. So: - Routes the simulation can't see, such as a default route learned from your ISP or routes from devices outside the site, stay as they are. - Anything the simulation simplifies is simplified the same way both times, and cancels out. What it simulates from the configs: - **Interfaces:** addresses, shutdown and no shutdown. - **Static routes,** including Null0 and blackhole routes, distances, and next hops resolved through other routes. - **OSPF:** which interfaces take part (network statements, interface areas, MikroTik templates), costs, passive interfaces, equal-cost paths, redistribution of connected and static routes, and announcing a default route. - **BGP** between the site's devices: eBGP and iBGP sessions configured on both sides, network statements, redistribution, next-hop-self, and the best path by AS path length, then eBGP before iBGP. - **ACLs and firewall rules** from the new config: Cisco ACLs and where they're applied, Huawei traffic filters, MikroTik's firewall. Each vendor's own administrative distances are used. Path Explain then walks each flow through both versions, exactly as it does for [Path Explain](/docs/en/network-paths). ## What it doesn't simulate yet Better to know than to trust it blindly: - OSPF areas are treated as one (no summarization between areas, no stub areas), and OSPF external routes are type 2. - BGP policy: route maps, prefix lists, communities, local preference, MED. Sessions to devices outside the site keep what they learned. - VRFs, policy-based routing, NAT, IPv6, IS-IS, EIGRP and RIP. - Firewall changes on Linux-based devices (FRR, VyOS, Linux): iptables and nftables aren't in the config Zaryn reads, so only their routing changes are simulated. The answer lists what it rests on, including devices without a config and the flows it had no time to test. ## Limits - Up to 400 flows per run. Flows named by changed rules, watched paths and probes go first. - Drills: up to 60 failures over up to 150 flows. - The behavior diff is free on every plan; failure drills come with Premium.

← previous · [

Path Explain and probes

] · next →

Encrypted repositories