Intentflow
Intentflow
Intentflow Verify analyzes your device configurations as a whole network - routing, policy, and reachability - composing several underlying analyses into each finding rather than reporting a checklist of isolated warnings, then correlating related findings across checks so you can see where they converge. Upload configs directly, or reuse an existing Reconcile import. No NetBox instance required.
Three steps - no agents, no access to your live network, nothing installed.
A .zip, a .tar.gz, or a single file of running-configs from Cisco IOS/IOS-XE, Cisco NX-OS, Juniper Junos, or Arista EOS - however your backup tooling already collects them. Already using Intentflow Reconcile? Reuse an existing import instead of uploading again.
Your configs are analyzed together as one network, not one device at a time - the same way traffic actually moves through it. Nothing is deployed, changed, or even reachable from the outside; the analysis runs entirely on the configuration you upload.
Every finding explained in plain English - what happened, why, what it affects, and what to do about it, with passes shown alongside failures. The dashboard organises a run into Overview (what was discovered, and how much of your upload could be analyzed), Findings (everything the checks produced, searchable), Network Behavior (how connectivity actually behaves) and Resilience (what stops working if a device fails). Findings tell you what deserves attention; the other views are where you check why. Download it as PDF, text, or JSON.
Intentflow checks routing, access-control policy, and forwarding behavior — then brings the results together into clear, actionable findings. Related findings are correlated across checks, so an access filter proven to deny all traffic is reported against the reachability failures on the paths it sits on, rather than as a separate alert you have to connect yourself. Every run also reports how much of your upload could actually be analyzed — unsupported syntax, and anything that didn't come through cleanly — so a short list of findings is never mistaken for a clean network.
BGP and OSPF sessions that can't form, are configured on only one side, or look established but actually aren't - plus IPsec tunnels that fail to negotiate - traced to the real cause, not just flagged. See the correlation layer.
Access-control behavior, proven rather than sampled: what an access-list in use actually does to every packet it could ever see — searched exhaustively, so a list that denies nothing, or denies everything, is established as fact rather than inferred from a few test packets. Plus lines that can never take effect, dangling references to things that don't exist, duplicate IP addresses, VRF or MTU mismatches across a link, HSRP/VRRP gateways that disagree with each other, VXLAN segments that map to the wrong VLAN, and dead configuration nothing points at anymore.
Devices that should be able to reach each other - by your own network's routing tables - but can't, showing exactly how far the traffic actually gets. Checked in both directions, so a path that works one way but not the other doesn't pass as healthy. Plus forwarding loops, equal-cost paths that silently disagree on the outcome, and return traffic that takes a different route than it went out.
A catalog of checks can only ever ask one question about one device at a time. These ask questions no single device can answer. Network Behavior and Resilience run on every verification and are marked Beta in the product - they work, and their shape is still settling.
Which of your discovered networks can reach which, on ICMP, SSH and HTTPS - not a sample. The matrix is complete for the scope it states or it isn't produced at all, and the report says how many relationships were analyzed, how many were reachable, and lists every one that wasn't. On a 22-device network that's 1,260 relationships from 126 queries.
Devices grouped by identical structure - same VRFs, same routing protocols, same interface make-up. Grouping alone says nothing is wrong; it establishes which devices are alike enough that a difference between them would mean something. The signature each group was built from is shown, so you can disagree with the grouping rather than with a verdict.
Within a group of comparable devices, the one whose connectivity doesn't match its peers. Reported as a difference from observed peer behavior, never as a policy violation - nothing in a configuration establishes that the majority is the intended one. Only a stated intent can make a difference into a fault.
Each device is removed from the model in turn and the network re-analyzed from what's left, answering in destinations that stop being reachable rather than in topology. Needs no physical topology data - it works from routing alone. The report says which devices were simulated, so a result is never mistaken for a whole-network guarantee.
Connectivity compared against your previous run, relationship by relationship - what became unreachable, what recovered. Relationships present in only one of the two runs are counted separately: that's a change in what was analyzed, usually a different set of devices in the upload, not a change in how the network behaves.
How many of your discovered networks hold a route toward an affected destination, and how many a modeled probe confirmed can reach it - kept as two separate numbers, because what routing permits and what was demonstrated are different claims. Counts of real things, never a score.
Every issue is explained the same way: what happened, why, what it affects, and what to do next - with the underlying technical detail one click away if you want it, and a link through to the analysis it came from.
19 of 20 structurally comparable branch routers block SSH toward the management network. One doesn't. No per-device check can find this: the nineteen that block it are working correctly, and the one that doesn't is only interesting next to them. Reported as a difference from peer behavior, not as a violation - you decide which behavior was intended.
border01 and core01's BGP session reports as established by every configuration signal - but tracing that connection through the forwarding model shows it being silently blocked along the way. The session isn't as reliable as it looks.
A line meant to restrict traffic is fully shadowed by an earlier, conflicting line - traffic is being handled the opposite way from what its author intended.
Your own network's routing tables say this pair should be reachable - but it isn't. Traffic between them will fail.
Run a one-off verification, or keep verifying as your network changes.
One-time
$99
A single verification run. No account needed - pay, and we'll email you a link to upload your configs and see the report. Your report stays available to view and download for 7 days.
Subscription
$249 / month
or $2,490 / year - two months free. Standalone Verify account, no hosted NetBox required. Covers one network and 10 verification runs a month.
Hosted add-on
+$149 / month
Already on Hosted NetBox? Add Verify to your existing Business, Enterprise, or MSP-client account. On standalone Reconcile it is +$200/month, making both products $349. Same 10 runs a month either way.
Prices shown exclude tax. Applicable sales tax or VAT is calculated at checkout based on your location.