Intentflow Verify Documentation

How it works

Three steps - no agents, no access to your live network, nothing installed.

Upload your configs

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. Already using Intentflow Reconcile? Reuse an existing import instead - see Using an existing Reconcile import. Include a show lldp neighbors detail (or CDP) capture for each device whose physical links you want assessed - the physical-topology checks below cover exactly the devices you supply one for, and the report states which devices those were. No separate step required. If you're a hosted NetBox customer, your own Cable records are used automatically, no upload needed at all.

We model your network as a whole

Every uploaded config is analyzed together as one connected network - the same way traffic actually moves through it - not one device at a time in isolation. Nothing is deployed, changed, or even reachable from the outside; the analysis runs entirely on the configuration you upload. The modeling and simulation itself runs on Batfish, the open-source network configuration analysis engine - a real, independently-verifiable model of your network's behavior, not a black box. What Intentflow adds on top is the correlation layer, the plain-English findings, and the workflow around it - see The correlation layer below.

Get a verification report

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 four views: Overview (the state of the run - coverage, verdict, and the network model discovered from your configuration), Findings (everything the checks produced, searchable and filterable), Network Behavior (the reachability matrix, which devices Intentflow considers structurally comparable, any device behaving unlike its peers, and what changed since your previous run) and Resilience (what stops being reachable when a single device fails) — both marked Beta in the app, meaning they run on every verification but their shape is still changing. Findings tell you what deserves attention; the other views let you investigate why, and a finding links across to the analysis it came from rather than repeating it. The same content, plus the observed scope of each finding, downloads as PDF, text, or JSON (view a sample report).

Supported platforms

The same parser Reconcile uses - filename or content is enough to identify a config, no manifest required.

A batch can mix platforms freely - each file is identified on its own. Unlike Reconcile, Verify needs the complete running-config for a device, not targeted command output - a full config is what makes routing, policy, and forwarding behavior actually analyzable. See Using an existing Reconcile import for how this affects reused imports specifically.
Platform	What Verify reads
Cisco IOS / IOS-XE	`show running-config`
Cisco NX-OS	`show running-config`
Arista EOS	`show running-config`
Juniper Junos	`show configuration`

The correlation layer

Verify's real job isn't answering a checklist of independent yes/no questions in isolation. It works at two levels: several underlying analyses are composed into a single finding, and findings that concern the same place in the network, or share an evidenced circumstance, are related to each other.

Why does this matter?

A network model can answer a lot of narrow questions in isolation: is this BGP session's configuration internally consistent? Does this access-list line ever match anything? Does a route exist toward this address? Any one of those answers, taken alone, can be technically correct and still misleading - "the configuration looks fine" is not the same question as "does this actually work." Verify's correlation layer exists to close that gap: it cross-references multiple independent signals about the same session, link, or path before deciding whether something is actually broken, and reports one finding with the real cause - not a pile of loosely related observations for you to connect yourself.

A worked example

Two routers have a BGP session. Their configuration matches on both sides - same AS numbers, same IP addresses - and by every configuration-level signal, the session reports as established. That's usually where a simpler tool would stop. Verify goes one step further: it traces a connection between the two peers' addresses through the forwarding model to see whether it gets through. If an access list somewhere along that path silently blocks it, Verify reports exactly that - a session that looks healthy by every configuration signal, but doesn't actually work, with the specific reason why - instead of either missing it entirely or reporting two disconnected facts ("session established" and, separately, "traffic blocked here") and leaving you to notice they're the same problem.

Correlation between findings, and what it will not do

Above the findings, Verify relates them to each other. Findings landing on the same device or device pair are grouped as one place to investigate; separately, findings that share an evidenced circumstance - configurations that did not fully parse, forwarding failures aimed at segments independently found to be isolated - are gathered under that circumstance, with the evidence for it stated. Nothing is removed, merged, re-rated or hidden. If a run has 230 findings, it still reports 230 findings and every one stays individually visible: correlation reorganises them for investigation, it does not summarise them away. Each grouping carries the specific reason each finding belongs to it, so "why were these put together?" has an answer you can check rather than a claim you have to trust. What this layer deliberately does not do is assert that one finding caused another - that requires re-running the analysis with a specific element removed, which is a different kind of proof.

Comparable devices, and why Verify never names them

To say a device behaves unlike its peers, Verify first has to decide which devices are peers. It groups them by structure, not by name: which VRFs a device has, whether it runs BGP or OSPF, and how many loopback, transit and LAN interfaces it carries. Hostname conventions vary from network to network, so a group built on a naming guess would be exactly the grouping you cannot check. Verify describes each group by that signature and never gives it a business name. It will tell you these eleven devices share a shape; it will not call them "the branch sites," because that is a claim about their role that no configuration states. The signature is shown so you can reject the grouping - which you could not do against a label that had already interpreted it for you. A device with no structural peer gets its own group of one rather than being hidden: that is precisely the device no comparison can ever be made about, and saying so is more useful than its silent absence.

A deviation is a difference, not a fault

Where a group is large enough to compare, Verify reports a device that behaves unlike the rest of it. 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 behaviour must be at least 80% consistent before any difference is worth reporting - two-of-three is noise, and treating it as signal would manufacture exactly the false positives the rest of the catalog is built to avoid. A relationship Verify could not determine is excluded from both sides of the comparison, because "we could not tell" is not evidence of consistency or of difference. And the result is always reported as a difference. Verify will not call it a violation, because nothing in your configuration says which behaviour was intended - one deliberately hardened branch looks identical to one misconfigured branch, and only you can tell those apart.

Conditions are evidence-backed, never causal

Some findings share a circumstance rather than a location - forwarding failures aimed at segments independently found to be isolated, or results limited by configurations that did not fully parse. Verify gathers those under the circumstance and states the evidence for it, so the grouping is checkable. A condition never fires on symptoms alone: without the independent evidence, there is no condition, however suggestive the pattern looks. The wording is deliberate too - a condition says findings are consistent with a circumstance, never that the circumstance caused them. Proving cause means re-running the analysis with that element removed, which is a different kind of proof and one Verify does not claim to have made.

Confidence reflects how direct that correlation is

Some findings are the direct, deterministic result of comparing two configured values - an AS number that plainly doesn't match. Others require reasoning across multiple signals where a legitimate, intentional design could look the same as a mistake - two ends of a link deliberately placed in different VRFs for a real routing-boundary reason, for instance. Verify labels every finding's confidence accordingly (see Confidence, severity & verdict) so you can tell "this is definitely wrong" apart from "this is worth a second look" at a glance, rather than treating every finding as equally certain.

What gets checked

Four categories, composed from your network's own configuration and modeled behavior - never a guess about intent that isn't in the configs themselves.

Snapshot

How much of what you uploaded could actually be analyzed, before any behavioral check runs on top of it.

Parse coverage. How many of your devices were fully understood, partially understood, or couldn't be analyzed at all - and why, per device. Every later category's results are only as complete as this coverage.
Physical topology coverage. Which devices have real physical-link data behind them (from an LLDP/CDP upload or NetBox Cable records) and which don't - naming exactly what to upload to unlock the physical-topology checks below for the devices still missing it.

Routing

BGP and OSPF, checked for whether sessions can actually form and stay up - not just whether their configuration looks consistent.

BGP session cannot form. Both sides configured a session toward each other, but something disagrees - most commonly the AS number each side expects for the other. The specific mismatch is named, not just "check your config."
A BGP session is up but carrying no routes. The session formed correctly and looks healthy in every status check, but not one prefix has been learned over it - either the far side is advertising nothing, or an inbound filter is discarding everything that arrives. Reported for awareness rather than as a confirmed fault, since a session that genuinely carries nothing is a legitimate design in a few cases and configuration alone can't tell the two apart.
BGP peer configured on only one side. One device has a neighbor statement pointing at a real, uploaded device - but that device never configured a session back. Distinct from a mismatch: nothing needs correcting on both sides, only one.
BGP peer configuration is incomplete. A neighbor is configured, but something required (a local AS, a peer IP, an update-source) is missing entirely.
BGP peer configuration is ambiguous. A neighbor statement matches more than one uploaded device - not clear which one the session would actually form with.
BGP peer not found in this upload. A device references a peer address that isn't part of what you uploaded - reported at the lowest severity, since this is the normal shape of a real external or upstream peer, not necessarily a mistake.
BGP session appears established, but the path is blocked. The flagship correlation finding - see The correlation layer above.
BGP session is configured correctly but didn't come up. Both sides agree on each other's AS numbers and addresses, so the configuration itself isn't the problem. Where the underlying path is provably blocked, the report names the specific direction and reason; where the path is confirmed fine, it says so plainly and points at authentication or timers instead of guessing.
OSPF adjacency didn't form. Two interfaces on a shared link have OSPF configured, but never became neighbors - the specific mismatch (area, or another adjacency parameter) is named.
OSPF configured on a shut interface. Real OSPF configuration sits on an interface that's administratively down - flagged for awareness (this is often deliberate, e.g. planned maintenance) rather than treated as a certain mistake, since it would otherwise silently disappear from the routing domain with no other signal anywhere in the report.
IPsec tunnel isn't established. Two sides have a site-to-site VPN tunnel configured, but the encryption/authentication parameters - or the pre-shared key itself - don't actually match. Named specifically (a key mismatch vs. a broader parameter mismatch), not just "the tunnel is down."

Policy

Access lists, cross-device consistency, and configuration hygiene.

An access-list line can never take effect. Fully shadowed by an earlier line in the same list. Flagged as critical when the shadowed line would have done something different (traffic is being handled the opposite way from what its author intended), or as a low-severity note when it's simply redundant.
An access-list in use permits every packet. Not sampled - searched across every packet the list could ever see, with no denied packet found anywhere in that space. An access-list attached to an interface that denies nothing looks like enforcement in the configuration while having no effect on traffic. Reported as an observation, since a deliberate allow-all is a real thing.
An access-list in use denies every packet. The same exhaustive search in the other direction: no permitted packet exists. Critical, because unlike a routing problem this stops every protocol and every source at once - whatever sits behind that interface is unreachable rather than degraded.
An access-list denies encrypted management access but permits the cleartext one. The list blocks SSH and admits Telnet, which carries the same credentials in the clear - the opposite of what either rule was presumably for. Both halves are found by exhaustive search and reported with the exact lines, so which one is wrong is a decision you can check rather than take on trust. Not reported as "permits Telnet", which is true of almost any permissive list and says nothing about your configuration.
A configuration reference points at something that doesn't exist. A route-map, ACL, or prefix-list is referenced by name but never actually defined anywhere in what you uploaded.
A route-map used as a BGP filter can never permit anything. Searched across every route it could ever be given - not one sample - the filter never lets anything through, so no routes will be exchanged in that direction even though a filter is configured as if some should. Reported with moderate confidence, since a deliberately closed peering direction looks identical.
A BGP export policy advertises more than the device originates. Searched exhaustively for any route outside the device's own connected networks that its outbound route-map would permit - and reported with the concrete prefix it found. Only for peers in another AS, since re-advertising routes you did not originate is the normal job of an internal route reflector. Raised from informational to a warning when the device peers with two or more outside networks and filters toward none of them, which is what turns a network into unintended transit between them. Stated as an observation: an unfiltered export is a perfectly ordinary design where the upstream filters on its own side, and configuration alone cannot tell that apart from a leak.
Unused configuration objects. Defined but never referenced anywhere - zero effect on behavior, reported as one combined note rather than one finding per object, since a real network can easily carry dozens of these without any of them being a problem.
Duplicate IP address. The same address is configured as active on more than one device - traffic to it will be answered unpredictably.
VRF mismatch across a link. Two interfaces that are genuinely the same physical or logical link are assigned to different VRFs - flagged for review rather than as a certain mistake, since intentional VRF stitching at a boundary is a real design pattern.
MTU mismatch across a link. Two ends of the same link are configured with different maximum transmission units - a common, easy-to-miss cause of connections that work for small requests but stall on larger transfers.
First-hop-redundancy members disagree on the virtual IP. Two devices in the same HSRP or VRRP group are configured with different virtual addresses - they aren't actually providing one shared, coherent gateway, whatever each side's configuration intended.
VXLAN segment maps to different VLANs. The same VXLAN network ID bridges to a different local VLAN on different switches in the fabric - traffic crossing the overlay can land in the wrong broadcast domain depending on which switch it enters through.
EVPN routed segment disagrees between switches. The same VRF is routed over the EVPN-VXLAN fabric with a different network ID or route target on different switches - inter-subnet routing for that tenant can silently fail on the mismatched device even though every device's own configuration looks fine on its own.
Remote access line isn't tied to centralized authentication. A management line accepts logins without going through a real authentication policy with a fallback method - a hygiene note, not an assertion that the line has no password at all.
IP/subnet mismatch on a physical link. Two interfaces confirmed to be the same real cable - via an LLDP/CDP upload or your NetBox Cable records - are configured with addresses in different subnets. Unlike the VRF/MTU checks above, this needs real physical-topology data to catch at all: without it, the two ends never register as a link in the first place, so a mismatch on it is invisible.
Native VLAN mismatch on a trunk. The same physically-confirmed link, both ends configured as a trunk, disagreeing on which VLAN carries untagged traffic - a classic cause of traffic silently leaking across VLANs.
Physically connected, but nothing running. A real cable, per your topology data, with no IP or VLAN configuration on either end at all - reported at low severity, since this is often deliberate spare or decommissioned capacity, not a mistake.

Forwarding

Whether traffic your own network's routing tables say should work, actually does.

Two devices can't reach each other. Scoped to pairs your own network's routing already believes should be reachable - never an arbitrary all-to-all sweep. When the failure happens more than one hop out, the report names the actual last device the traffic reached before failing, not just the end result. Every failure here is then re-traced with all access-lists ignored, which separates the two causes that need completely different fixes: if the traffic gets through that way, an access-list is responsible and the routing is fine; if it still fails, the routing is responsible and no filter change will help.
Traffic is silently discarded (a blackhole). A route exists and matches, but the destination is a deliberate or accidental discard - distinguished from "no route was found at all," since the fix is different.
One device's failure would disconnect part of the network. Each device is switched off in a simulated copy of your network and the result re-analysed, to find the destinations that would have no remaining path. Reported with the count of destinations affected, not a resilience score - a single path is often a deliberate cost decision, so this states what would happen and leaves whether that is acceptable to you.
One device behaves differently from its structural peers. Devices are first grouped by identical structure - same VRFs, same routing protocols, same interface make-up - and the grouping is shown to you in full. Within a group, a device whose reachability differs from what the rest of the group does is named. Only reported where the group is large enough and consistent enough for "the rest of the group" to mean something, and reported as a difference from peers, never as a fault: nobody declared the majority behaviour correct.
A network segment has no route to anywhere else. A connected network whose device holds no route toward anything else in the upload. Read from the routing tables, not from a traffic test. Often deliberate - a quarantine VLAN, an out-of-band network, a lab - so this reports what the routing shows and leaves the intent to you.
A device is configured to discard traffic toward a specific prefix. A route that deliberately drops matching traffic instead of forwarding it. Often entirely intentional - route aggregation, blackholing an attack target, preventing a route leak - so this is reported as a fact to confirm rather than an assumed fault. Reported at low severity when nothing else in your network routes toward that prefix, and higher when another device does, which makes traffic actually arriving there plausible.
A device can't reach a destination that only exists in the routing table. Every other forwarding check tests somewhere a device owns - its own address, or a network directly attached to it. This tests the destinations that belong to nobody: a prefix that appears only as a route, with no interface behind it anywhere. Probed from the devices whose routing actually points at it, with the same access-list-versus-routing determination as the checks above.
Traffic gets there, but the reply can't get back. The outbound direction works, so a simple one-way test looks fine - but the response never makes it home. Anything that needs a round trip still fails, which is why this is checked in both directions rather than trusting the forward path alone.
Traffic takes a different path back than it took out. Both directions work, but they don't follow the same route in reverse. Often deliberate, so it's reported for awareness rather than as a fault - it matters most when a firewall or other stateful device sits on only one of the two paths and sees just half of each conversation.
A device can't reach a local network it should. The checks above test device-to-device paths, which prove the routers can reach each other. This tests the networks your users and applications actually sit on - every LAN found in your configuration, probed from every device whose routing already says it should get there. The two fail independently: a perfectly healthy device-to-device mesh can sit on top of a user network nobody can reach.
A service is blocked on a path that otherwise works. Basic connectivity to a network is confirmed working, but HTTPS or SSH to it is not. This is the failure a ping-based test is structurally unable to see - the path is fine, so everything looks healthy, while the application that matters is being dropped by a filter. Only reported where basic connectivity already passed, so one broken path never turns into several findings.
Forwarding loop. A packet entering the network cycles forever instead of ever reaching its destination or being dropped - always a real, always-critical problem.
Equal-cost paths don't agree. The same traffic has more than one equally-good path across your network, and those paths don't treat it the same way - one lets it through, another blocks it. Depending on which path gets picked for a given connection, the exact same request can succeed or fail with no configuration change at all.
A single device is your only physical path between two parts of the network. Built from your uploaded physical topology data - names exactly which devices would be cut off if that device failed or went down for maintenance, not just "this device matters." Reported for awareness (redundancy may be handled another way this data doesn't cover), not as a confirmed problem.

Confidence, severity & verdict

Every finding carries both a confidence level and a severity - two different questions, both answered explicitly rather than left for you to infer.

Confidence is only shown on a finding's card when it isn't "High" - the common case doesn't need a label at all.
Confidence	Meaning
High	A direct, deterministic fact - two configured values that plainly don't match, a real path trace that plainly fails.
Medium	A reasonable, but not certain, read of the evidence - the most likely explanation given what's available, not the only possible one.
Inferred	A pattern that's worth a second look, not a confirmed problem - a legitimate, intentional design could produce the same signal.

Severity	Meaning
Critical	A real, current problem - not a transient state. At least one critical finding means the overall run is FAIL.
Warning	Worth attention, but not an outright failure on its own. Any warning with zero criticals means the overall run is PASS WITH ISSUES.
Info	Worth knowing, not necessarily worth acting on - an external peer that couldn't be verified, harmless unused configuration. Never affects the overall verdict.

The report's summary block always shows passes alongside failures per category - "12 BGP sessions verified" is as much a real result as any finding, not just a to-do list of what's broken.

Run statuses

Every run moves through these states, visible live on its own page.

Analyzing configuration

Your uploaded configs are being identified and classified by platform.

Building network model

Your configs are being combined into one connected model of the network.

Running checks

Snapshot, Routing, Policy, and Forwarding run in sequence against that model - the page shows which one is currently in progress.

Completed

Finished with a clean PASS - no critical or warning findings.

Completed with issues

Finished, but the report contains at least one warning or critical finding - open it to see what.

Failed

The run itself couldn't complete - shown with the specific reason (e.g. no analyzable device configurations in what was uploaded). Rerunning after fixing the underlying issue doesn't require a fresh upload.

Using an existing Reconcile import

Already uploaded configs to Reconcile? You don't always need to upload them again.

Why "sometimes," not "always"?

Reconcile and Verify need different things from the same kind of upload. Reconcile only needs whatever command output lets it populate specific NetBox fields - a device inventory and an LLDP capture is a complete, useful Reconcile batch on its own. Verify needs a full running-config per device to model routing, policy, and forwarding behavior - a batch that's 100% complete by Reconcile's own standard can still have zero full device configs in it, if that's all it was ever fed.

What actually happens when I reuse a batch?

Verify looks at exactly which devices in that batch have a full config captured, and runs against those - honestly. If a batch has no usable device configs at all, the run fails immediately with a clear message rather than wasting time on nothing to analyze. If it's partial, the run proceeds on what's available and the report says so plainly, rather than silently pretending every device was covered.

Billing

Three ways to pay - see the pricing page for current rates.

One-time verification

A single run, no account required - pay, and a link to upload your configs and see the report is emailed to you. If that email address already has an Intentflow account, you'll be pointed to add Verify to it instead of creating a separate one - keeping everything under one login. Your report page stays available to view and download for 7 days after the run completes, then it's permanently deleted. The configuration you uploaded is also permanently deleted after 7 days, and is never sent outside our own infrastructure or to any AI model; see Security for the full lifecycle.

Standalone subscription

A recurring Verify-only account, with no hosted NetBox instance required at all.

Hosted add-on

Already on hosted NetBox? Add Verify to your existing Business or Enterprise account, or to an individual client's account if you're an MSP - billed on the same subscription, using the payment method already on file. Standalone Reconcile can add it too, at $200/month rather than $149, which puts both products at $349. Cancel any time from your dashboard; it stops renewing straight away, stays active for the rest of the period you have already paid for, and the rest of your plan is untouched. Because that period is already paid for, re-adding Verify before it ends costs nothing and changes nothing.

Is there a run limit?

Yes - every plan that includes Verify covers 10 verification runs a month, on the standalone subscription and the hosted add-on alike. The allowance resets monthly from the day Verify was activated on your account, not from your billing date, so an annual subscription gets the same 10 runs each month. A run that fails on our side - a timeout, or an upload we could not analyse - is not counted. If you need more, get in touch.

What a subscription covers is one network: your own, or a single client's. Assessing several different clients' networks needs an MSP account, or a separate subscription for each, whether or not you charge for the results (Terms, section 3).

Known limitations

Said plainly, not buried in a footnote.

Verify checks configuration and modeled behavior, not business intent. It answers "does this configuration work the way it's written," not "does this match what your organization actually intended" - the latter needs context Verify doesn't have without a source of truth like NetBox behind it. That's a deliberate, separate direction we're building toward, not a gap in what's covered today.
Coverage depends on what's uploaded. A device with no config captured at all, or only a partial one, is analyzed only as far as what's actually present - see Supported platforms and Using an existing Reconcile import.
Findings are structural and behavioral, not a security audit. Verify tells you whether your network works as configured - it isn't a vulnerability scanner and doesn't claim to be one.
Every finding is generated from your configuration alone, never from live traffic or device state. Nothing about how Verify works requires - or grants - any access to your running network.

Questions we haven't covered here?

Reach out at support@intentflow.co

Intentflow Verify documentation