Get started with network automation

From the first read-only look at your devices to changes that check and undo themselves, one chapter at a time. Designing the network as code is a separate path: [Get started with network design repositories](/docs/en/get-started-network-design). ## 1. What Zaryn does for a network ```diagram type: cards --- 🗂 | Config backups and drift | Every config kept as versions; anything off the approved one is flagged, line by line | accent 🗺 | A live map | Drawn from what the devices say about their neighbors, with single points of failure marked | 🧮 | An address plan | Every subnet and address, and the conflicts: one IP on two interfaces, two MACs, mismatched masks | 🔎 | Why A can't reach B | Followed hop by hop through routes, ACLs and firewalls, with the rule that drops it | good 🔮 | A digital twin | What a change would break, before it touches a device | good 🔁 | Safe rollouts | Changes made by the collector, checked live, taken back if the network doesn't hold | warn ``` A **site** is a place with network devices: an office, a data center, a POP. Zaryn shows each site live and keeps its history. ## 2. How it works ```diagram type: graph title: A collector at the site, Zaryn in the cloud alt: The collector logs in to the devices over SSH with read-only commands and sends what they print to Zaryn over outgoing HTTPS; you see the site on Zaryn legend: ghost=SSH, read-only commands; path=Outgoing HTTPS height: 44 --- box Your site | 2 2 62 40 | good node r1 | core router | 12 10 | router | | `show`, `display`, `print`, `/export`: commands built into zev node sw | switches | 12 22 | switch | node fw | firewall | 12 34 | firewall | node col | zev collector | 46 22 | collector | accent | Any Linux box at the site. Keeps the passwords; only makes outgoing connections node z | Zaryn | 82 10 | cloud | | Map, backups, drift, paths, twin, history node you | you | 82 34 | user | good | link r1 col | | ghost link sw col | | ghost link fw col | | ghost link col z | HTTPS out | path link z you | | path2 ``` The **collector** is zev running on a machine at the site. It logs in to your devices over SSH and runs only **read-only commands** that are built into zev, so nothing Zaryn sends can make it change a device. Passwords stay on the collector, and it only connects **outward**: no port to open. ## 3. What it reads, and what's free ```diagram type: cards --- 🟦 | Cisco IOS and IOS-XE | Routers and switches, ACLs, OSPF and BGP | 🟥 | Huawei VRP | Routers and switches | 🟧 | MikroTik RouterOS | Including firewall rules and its own neighbor discovery | 🐧 | FRRouting, VyOS | Linux routers | 🆓 | Free: up to 10 devices | Every check, the twin and rollouts of up to 10 devices | good ✦ | Premium: up to 1,000 | Waves, canaries, maintenance windows, failure drills | accent ``` ## 4. Make a site and start the collector ```diagram type: flow title: Ten minutes to a running collector --- Make a site | zaryn.xyz/sites → New site, e.g. `hq` | | 🏢 ~ Collector and settings Join | `zev site join zsite_…` on the collector machine | accent | 🔑 ~ sudo zev site install Running | A service: checks in every 30 s, reads every 15 min | good | ▶ ``` ```bash zev site join zsite_… --server https://api.zaryn.xyz sudo zev site install ``` [Install zev](/docs/en/installation) on the collector first. The service keeps its files in `/var/lib/zev/site`. ## 5. Logins, tried before they're used ```bash zev site cred add core-admin --user netops # asks for the password zev site cred add old-ios --user admin --enable # Cisco: also the enable secret zev site test 10.0.0.1 --cred core-admin ``` ```text ✓ CORE-SW1 Cisco IOS / IOS-XE 15.2(2)E7 WS-C2960X-48FPD-L (1840 ms) interfaces 52 (31 up) neighbors 4 config 612 lines, 7 secrets replaced before upload ``` Each login is a named **credential** on the collector. `zev site test` reads a device right away and shows what Zaryn would see, sending nothing. Secrets in configs are replaced before anything leaves the collector. ## 6. Add your devices ```diagram type: flow title: Two ways to fill the site or: or --- By address | On the Devices tab: address, vendor (or let zev tell), credential | accent | ➕ ? Find them | Add ranges like `10.0.0.0/24`; neighbors the devices report show up too ~ within a minute Read | Config, interfaces, routes, neighbors, addresses | good | ✓ ``` Everything found waits under **Found on the network**, to add with one click or ignore. ## 7. Backups and drift ```diagram type: diff title: A device that drifted from its approved config file: core-sw1 · running vs approved --- @@ interface GigabitEthernet0/1 interface GigabitEthernet0/1 description to-servers - switchport trunk allowed vlan 10,20 + switchport trunk allowed vlan 10,20,99 > Someone added VLAN 99 to a trunk. Intended? Approve this config. Not? This is exactly what to put back. + spanning-tree portfast trunk ``` The first config the collector reads becomes the **approved** one. Every later change is a new version; a running config that differs from the approved one is **drifted**, with the difference line by line. Lines that change by themselves (timestamps, NTP clock periods) are ignored, so an unchanged config never looks changed. The last 500 versions of each device are kept. ## 8. The map ```diagram type: graph title: Drawn from what the devices say alt: A live map of a core router, two distribution switches and access switches, with a single point of failure marked legend: down=If it fails start: The map height: 46 --- node core | core | 50 8 | router | accent node d1 | dist1 | 28 24 | switch node d2 | dist2 | 72 24 | switch | warn | A single point of failure: acc3 hangs on it alone node a1 | acc1 | 12 40 | switch node a2 | acc2 | 40 40 | switch node a3 | acc3 | 72 40 | switch link core d1 link core d2 link d1 a1 link d1 a2 link d2 a2 link d2 a3 step dist2 fails | acc2 still has dist1. acc3 is cut off: Zaryn marks dist2 as a single point of failure before it happens. node d2 | bad link core d2 | down link d2 a2 | down link d2 a3 | down node a3 | bad ``` The map comes from the devices themselves: CDP, LLDP, MikroTik's neighbor discovery, OSPF and BGP peers, and shared subnets. Devices and links whose loss would cut others off are marked. ## 9. The address plan ```diagram type: cards title: What the Addresses tab catches --- ⚠ | One address, two interfaces | The same IP configured twice: one of them will lose | bad 👥 | One address, two MACs | Two machines answering for one IP | bad 📏 | Mismatched masks | One subnet with a /24 here and a /25 there | warn 📊 | How full | Every subnet, its addresses, and how much is left | good ``` ## 10. What changed, when ```diagram type: cards --- 📝 | Config changes | Every change to a running config, with its diff | accent 🔌 | Interfaces | Up, down, flapping | 🤝 | Neighbors | Appearing and disappearing | 📵 | Reachability | A device the collector can't reach anymore | warn ``` The site's **Changes** list is the network's timeline: the first place to look after "it worked yesterday". ## 11. Why can't A reach B? ```diagram type: flow title: Path Explain, hop by hop --- Ask | From, to, protocol and port, e.g. laptop → server, TCP 80 | | ❓ ~ followed through every device Walk | Each hop's route and each ACL or firewall rule it meets | accent | 🚶 ~ the answer Why | "sw1 drops it: SERVERS-OUT rule 40 deny ip any any" | bad | ✕ ``` ```text Blocked by a filter sw1 drops it (outbound on GigabitEthernet0/2): SERVERS-OUT, rule 40 deny ip any any log ``` On the **Paths** tab, the answer is one of: reachable both ways, blocked by a filter, no route, a routing loop, an interface down, the reply not coming back, leaving the site, or "can't tell" with what's missing. It quotes the rule or route that decides, and equal-cost paths are followed one by one. [In depth](/docs/en/network-paths). ## 12. Watch what matters ```diagram type: flow title: A probe, and what happens when it fails --- Probe | Ping, a TCP port, an HTTP(S) URL or a DNS name, every 30 s to an hour | | 📡 ~ two failures in a row Failing | Shown on Health and in Changes | warn | ⚠ ~ automatically Explained | Zaryn runs Path Explain from the collector to the target | good | 🔎 ``` "Refused" (the host answered, nothing listens) is told apart from "no answer" (dropped on the way), and each probe keeps a week of results. ## 13. Try a change on the twin ```diagram type: flow title: See what it would do, before it does it --- Edit | The device's current config, in the editor; several devices if the change spans them | accent | ✎ ~ See what it would do Predict | Every pair of subnets, your probes and watched paths, on the network as it is and would be | | 🔮 ~ the answer Differences | What stops working first, in red, with the rule or route that makes the difference | warn | ⚖ ``` Open a site, then **Try a change**. Nothing is sent to the devices: the twin works from what they said last. From a script or CI: `zev site diff acme/hq r1=r1.cfg`. [The digital twin](/docs/en/network-twin). ## 14. Roll it out, with an undo ```diagram type: sequence title: A rollout that checks itself lanes: You | Zaryn | Collector | Devices alt: You approve; the collector applies the change, waits for the network to settle, checks it against the twin's prediction, and either keeps it or takes it back --- You -> Zaryn : approve (four eyes if the site asks) Zaryn -> Collector : the commands, and their undo Collector -> Devices : apply note Collector : let the network settle, then check: reachable? neighbors kept? routes as the twin predicted? probes passing? Collector -> Devices : holds: keep it | good Collector -> Devices : doesn't: take it back | bad Collector --> Zaryn : what happened, step by step ``` The collector can only change devices after someone on its own machine runs `sudo zev site changes on`. Nothing Zaryn says can turn that on. On MikroTik, FRRouting and VyOS, the device itself also reverts if the collector disappears mid-change. [Rollouts](/docs/en/network-rollouts). ## 15. One change, every device ```diagram type: cards --- 📚 | Runbooks | NTP, syslog, DNS, a rotated SNMP community, a user who left: written once per vendor, run on every device that needs it | accent 🐤 | Canary (Premium) | The first device alone; the rest follow only if it holds | 🌊 | Waves (Premium) | N devices at a time, each wave checked before the next | 🕐 | Maintenance windows (Premium) | Nothing starts before it; what's left stops when it ends | good ``` Free rollouts take up to 10 devices in one wave, with every check and the automatic rollback. ## 16. Device access without passwords ```diagram type: flow title: A terminal, approved, recorded, ended --- Ask | `zev site ssh acme/hq core-sw --minutes 30 --reason …` | | ✋ ~ a site admin approves Connected | The collector logs in with the password it keeps; you never see it | accent | 🔑 ~ every key recorded Ended | Time's up, or revoked; replay it on the Access tab | good | ⏹ ``` No more shared admin passwords in spreadsheets: an engineer or contractor gets a terminal for a limited time, approved by an admin, recorded keystroke by keystroke. [Device access](/docs/en/network-access). You've gone from a read-only look to safe, checked changes. Next: [Network sites](/docs/en/network-sites), [Path Explain](/docs/en/network-paths), [the digital twin](/docs/en/network-twin) and [rollouts](/docs/en/network-rollouts) in depth, and [design repositories](/docs/en/get-started-network-design) for the network as code.