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.
42 checks across routing, access-control policy, and forwarding behavior — each classified by what it puts at risk: availability, security, correctness, or hygiene. Their results are then brought 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. Nothing is removed, merged, re-rated or hidden in the process — a run with 230 findings still reports 230, every one individually visible, and each grouping carries the specific reason each finding belongs to it. 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 the security-side findings that come out of the same analysis: an access-list that denies encrypted management access while permitting the cleartext one, a remote-access line not tied to centralized authentication, a BGP export policy advertising prefixes the device doesn't originate. 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. The population rules are deliberately conservative: below five comparable devices it says nothing at all, below eight it reports an observation rather than a candidate pattern, and the majority behavior must be at least 80% consistent before a difference is worth reporting. 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.
No. Verify works from device configurations alone, so you can run it whether or not you have a source of truth. If you already use Intentflow Reconcile, you can point a verification at an existing import instead of uploading the same configs twice.
No. There are no agents, no collectors, and no connection to your devices. You upload the running-configs your backup tooling already collects, and the entire analysis runs on that text. Nothing is deployed or changed on the network.
Cisco IOS and IOS-XE, Cisco NX-OS, Juniper Junos, and Arista EOS. Upload a .zip, a .tar.gz, or a single file of running-configs.
A linter reads one device at a time. Verify works on a model of the whole network, and three layers run on top of the checks. Correlation composes several independent analyses into a single finding with a cause — a BGP session that matches on both sides is also traced through the forwarding model, so “established, but silently blocked along the path” arrives as one finding rather than two facts you have to connect — then relates findings to each other by location and by evidenced circumstance, without hiding any of them. Cohorts group devices by structure rather than hostname and report the one behaving unlike its peers, as a difference and never as a violation. Behavior and resilience ask what no single device can answer: the complete reachability matrix, what breaks when each device fails, and what changed since your last run. How the correlation layer works →
42 checks over one network model: 11 on routing, 18 on policy, 13 on forwarding, each classified by what it puts at risk — availability, security, correctness, or hygiene. They cover BGP and OSPF adjacencies that can't form or only look established, IPsec tunnels that fail to negotiate, access-list behavior proven exhaustively rather than sampled, cleartext management access and remote-access lines outside central authentication, BGP export policies advertising prefixes the device doesn't originate, duplicate IPs, VRF, MTU and native-VLAN mismatches, disagreeing HSRP/VRRP gateways, VXLAN and EVPN mapping errors, unreachable pairs checked in both directions, forwarding loops, disagreeing equal-cost paths, asymmetric return paths, and single points of failure both routing and physical. The documentation lists every one, check by check.
Yes — that is the Resilience view, and it runs on every verification. It answers in destinations that stop being reachable rather than in topology, works from routing alone with no physical topology data required, and names which devices were simulated so a result is never read as a whole-network guarantee.
A one-time verification is $99 with no account required. A standalone subscription is $249/month or $2,490/year and covers one network and 10 runs a month. If you are already on Hosted NetBox, Verify is a $149/month add-on; on standalone Reconcile it is $200/month. Prices exclude tax.
A report where every finding is explained in plain English — what happened, why, what it affects, and what to do about it — with passes shown alongside failures and the underlying technical detail one click away. You can read it on the dashboard or download it as PDF, text, or JSON. A sample report is published on this page.
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.