Batfish and the promise of checking a network before change

In brief

• Batfish is an Apache 2.0-licensed open-source network analysis project that converts supported device, cloud and routing configurations into a common model and answers questions about whole-network behaviour before production state is changed.
• Symbolic analysis can examine large classes of packet headers, routes and failures, but every result is conditional: it is only as sound as the completeness of the snapshot, parser coverage, supported semantics and the property the operator chose to test.
• The project grew from research published at NSDI in 2015 into an actively maintained engine with pybatfish, differential analysis, cloud modelling and widening platform support, including SONiC, A10 and EVPN/VXLAN.
• Batfish is not the same as Intentionet or commercial assurance products: the open project can move some errors from production into review, but data collection, intent definition, staged rollout, live telemetry and the final decision about trusting the model remain the operator’s responsibility.

A harmless edit can have a network-wide blast radius

A network change almost always begins as text. An engineer edits a route map, ACL, BGP peer, redistribution rule or cloud route table and carefully examines a few lines of diff. Locally, the edit may be syntactically valid and even appear obvious, but production does not execute it separately from the rest of the network: routers, firewalls, virtual networks and overlays combine it with other policies, advertisements, topology, tunnels, defaults and failure states.

The gap between local configuration and global behaviour is the central problem Batfish addresses. An operator gives the engine a snapshot containing configurations and, where needed, additional context such as topology hints, runtime routes, host data or cloud state. Batfish parses supported syntax, converts it into a vendor-independent representation, computes control-plane and forwarding outcomes, and answers questions about paths, filters, reachability, routing policy and selected failure scenarios.

Through the Python client pybatfish, these questions can be incorporated into the same repository and review process used to prepare the configuration itself. A route leak, a lost backup path or an unexpected security-policy change can then appear during a pull request rather than after a maintenance window. The purpose is not to replace the engineer with mathematics, but to give the review process network context that is difficult for a person to reconstruct fully from files.

Batfish’s strongest results are sometimes called proofs. That term is useful only when accompanied by a boundary: a symbolic reachability query can examine the modelled packet-header space and show that no modelled packet from a specified class reaches a prohibited destination, or return a counterexample if one does. This coverage can be far broader than any manually selected set of probe tests, but it says nothing about a device, route, physical condition or vendor feature omitted from the snapshot.

Batfish also does not observe queue depth, optical power, packet corruption, undocumented ASIC behaviour or an application fault above the network layer. A passing result is therefore proof of a property in a particular model, not a certificate of immunity for production. The project’s strength is precisely that its conditions can be named and retained: which snapshot was analysed, which engine version was used, which warnings appeared, which question was asked and which answer was returned.

That promise is already significant. Traditional network assurance has often relied on reading configuration, laboratory tests, post-change probes and the experience of the engineer who will later receive the page if something fails. Batfish moves part of the checking earlier and thereby becomes infrastructure for the change process rather than part of the packet path.

Configuration became distributed code before networks treated it as code

The problem from which Batfish emerged is not a lack of syntax checkers. It is that network policy is distributed across many devices and control systems, each implementing only part of the overall result. The availability of one flow may simultaneously depend on route origination, import, transformation, selection, export, acceptance by another device, installation in a forwarding table, an ACL, NAT and a tunnel.

Reviewing one device at a time is therefore structurally incomplete. A local checker can report whether a network operating system accepts a command, while a linter may identify obsolete syntax or a suspicious pattern. Neither is necessarily designed to calculate the end-to-end consequence once routing policy, forwarding state and filters interact across the whole network.

Batfish treats the network as one semantic entity, although the source material for that entity remains a collection of configurations and external state. This model is especially important in a multi-vendor environment, where the same ideas are expressed through different commands, defaults and entities. One vendor uses route maps, another uses policy statements, while a cloud provider may encode analogous behaviour in an API entity with no direct equivalent in a configuration file.

Batfish parsers and its vendor-independent representation attempt to bring supported semantics onto a common level at which the same network-wide questions can be asked. This reduces dependence on a particular configuration language but creates a new trust boundary. The common representation is only as accurate as the translation of every feature affecting the property under examination.

Unsupported statements, partially modelled behaviour and vendor-specific defaults must not disappear as noise. Conversion warnings and coverage boundaries are therefore part of the result rather than technical debris surrounding it. A parser that accepts a file successfully but fails to represent a forwarding-changing command may create more dangerous confidence than one that fails explicitly.

The same problem arises in the cloud. A repository may contain templates and intended state, while routes, interfaces, attachments and security entities are created dynamically through provider APIs. Batfish can include AWS and Azure constructs in a snapshot, but responsibility for collecting current state remains with the operator, and support for a format does not itself make the snapshot complete.

Batfish’s core is therefore more accurately described as semantic analysis than configuration checking. The engine asks what the supplied network will do under supported semantics, then allows the same question to be repeated before and after a change so the results can be compared. The engineering benefit is that global behaviour becomes a testable property rather than a mental simulation of thousands of configuration lines.

A research question became a reusable engine

Batfish grew out of academic and engineering work that led to the 2015 NSDI paperA General Approach to Network Configuration Analysis. The foundational paper had seven authors: Ari Fogel, Stanley Fung, Luis Pedrosa, Meg Walraed-Sullivan, Ramesh Govindan, Ratul Mahajan and Todd Millstein. That list matters because the project’s history was collective from the outset and should not become a narrative about a single founder.

The 2013–2014 research prototype combined configuration parsing, control-plane computation and data-plane queries within a common network-analysis architecture. Publication and open code in 2015 created a public technical foundation. Parsers, question libraries and community use expanded from 2015 to 2018, gradually taking the engine beyond the networks and features demonstrated in the first paper.

The next transition concerned automation. From 2019 to 2021, pybatfish notebooks, Python workflows and base-versus-delta analysis made Batfish easier to use from CI/CD and internal network-automation systems. The main change was not the notebook interface itself, but the ability to turn a network property into an executable test run whenever candidate state changed.

The internal analysis architecture changed as well. Early Batfish relied on a Datalog-centred design; later, much of the analysis moved to specialised representations, including binary decision diagrams, or BDDs. A 2023 experience paper described the redesign and reported large speed improvements on the workloads studied, including analysis of networks with thousands of devices in minutes.

Those figures demonstrate substantial engineering progress but do not establish a universal response time. Runtime depends on topology, the number of transformations, the particular question and the structure of model state. Batfish is therefore better assessed not through a single benchmark, but by whether a particular organisation can complete the checks it needs within its change window.

The project continued to follow changing infrastructure. Cloud modelling, SONiC, A10 and EVPN/VXLAN developed during 2024–2026. Tagged release v2025.07.07, dated 7 July 2025, added initial A10 support, including BGP, ACLs, virtual servers, NAT and VRRP-A, as well as initial SONiC coverage throughconfig_db.jsonandfrr.conf, and expanded support for Layer 3 EVPN/VXLAN tunnels and Type 5 routes.

The terms initial and expanded matter more here than the list of logos. Platform support appears layer by layer, and neither A10, SONiC nor EVPN/VXLAN can automatically be treated as fully modelled across all versions and scenarios. Every new feature extends the engine’s usefulness while also enlarging the maintenance surface on which semantic errors can occur.

At the research cut-off of 10 August 2026, the main repository and documentation remained active after the July 2025 tag. The most recent tagged release in the supplied material remained v2025.07.07, while development continued on the main branch. The pybatfish documentation identified version 0.36.0; this is a client documentation release rather than the Batfish engine version, again demonstrating the need to version assurance components separately.

The project’s history therefore cannot be reduced to a simple progression from prototype to product. It includes wider vendor coverage, the movement of questions into automation, replacement of the internal analysis architecture and gradual expansion into cloud and data-centre overlays. Each improvement creates its own operational debt: more parsers require more reviewers, CI integration demands version discipline, and symbolic scale requires a clear explanation of where the model ends.

The engine computes a network, not a collection of files

Batfish begins with an analysis snapshot rather than a live packet stream. Device configurations usually form the foundation, but a snapshot for a particular environment may additionally contain topology information, host data, cloud state, runtime BGP routes, LLDP/CDP data and other inputs. An immutable analysis unit matters because it allows the decision state to be reproduced and later reveals exactly which data set produced a particular answer.

Parsing is the first hard boundary. Network operating systems from different vendors use their own grammars, defaults and methods of expressing analogous functions. Batfish parsers create syntax structures for supported formats, after which the conversion layer translates understood statements into a common internal model while retaining warnings where translation is incomplete.

The vendor-independent model is then used for control-plane computation. The engine reasons about supported protocol sessions, route origination, propagation, import and export policy, redistribution, route selection, virtual routing instances and associated state. The result is not an emulation of proprietary router code; it is an independent model of the outcome implied by the supplied configuration and Batfish’s implemented protocol semantics.

That independence creates both value and limitation. Without running the actual network operating system, Batfish can analyse different vendors in one framework and search for network-wide consequences. Production may nevertheless differ because of undocumented behaviour, a vendor defect, a timing dependency or a feature not yet represented by the model. Model fidelity must therefore be supported by tests and observable coverage rather than the phrase vendor-independent.

The engine synthesises forwarding behaviour from the control plane. Forwarding tables, ACLs, NAT, topology and supported tunnel states are combined into a model of packet movement. At this level, an operator can ask whether one set of locations reaches another, which path a flow takes, where a packet is filtered and how a routing-policy change alters forwarding state.

The same architecture supports differential analysis. A base snapshot and candidate snapshot are tested with the same question, after which the operator compares behaviour rather than text alone. If a small BGP edit changes remote route selection, a semantic diff can expose the effect even when the textual diff occupies one line.

Batfish is written primarily in Java, while pybatfish provides a Python-facing client for notebooks and automation. This separation has operational significance: internal tools may depend on pybatfish schemas and answer formats while the analysis engine operates separately. Client, engine and internal test versions should therefore be treated as linked dependencies in one assurance system.

Symbolic reachability tests a property rather than a handful of probes

A ping asks a narrow question of a live system: did one selected packet reach one destination at one moment? Synthetic transactions and traceroutes broaden observation, but any finite set of probes covers only a small part of the possible headers, ingress points, paths and failure states. A successful ping does not prove that every prohibited source is isolated, while a failed ping does not automatically explain whether the route, filter, host, application or measurement path is responsible.

Batfish starts with a property. An operator might specify, for example, that guest networks must never reach the management subnet. The engine symbolically represents the relevant packet-header space, while BDDs can compactly describe large sets of addresses, ports, protocols and transformations without enumerating every individual packet.

The result may be negative or constructive. Batfish can show that no header represented by the model satisfies the prohibited path, or return a counterexample containing a source, destination, protocol and trace. Operationally, a counterexample is often more useful than a general failure because the engineer receives a reproducible case and a specific policy-decision point to investigate.

Symbolic analysis also changes when checking occurs. Candidate configuration need not yet exist on a production device, so a violation can be identified before deployment and used to block a pull request or change ticket. This is what makes Batfish especially attractive for network automation: a network-wide property becomes part of pre-deployment software testing.

Symbolic search is not infinitely cheap. Some topologies, transformations and questions create expensive state spaces, so runtime depends on both the network and the query. The BDD redesign improved scale on published workloads, but a large estate must still plan the compute and latency of its assurance platform if that platform controls release gates.

Most importantly, symbolic completeness within the model does not imply physical completeness. Batfish does not measure queueing, optical degradation, congestion on a real interface, a flapping transceiver, packet corruption or application response time. It generally computes stable or selected routing states rather than reproducing every timer race during convergence, so live telemetry remains a separate source of evidence.

Model and observation therefore complement each other. Batfish shows what the supplied state should mean under supported semantics, while probes, device telemetry and application measurements show what actually occurred after deployment. A difference between them is a useful diagnostic signal, not a reason to declare either source universally correct in advance.

Differential analysis asks what changed, not merely whether the syntax is valid

A major review too often begins with the question, ‘Is the new configuration valid?’ A more useful question is what behaviour will change and whether every change is intentional. Differential analysis compares base and candidate snapshots and shows differences in routes, reachability, paths, filters and other properties, making the blast radius of an edit reviewable before rollout.

Routing policy illustrates the value particularly well. Adding a community, changing local preference, redistribution or a filter may affect decisions several hops away from the edit. A cloud route-table change can open or isolate another network, while removing one path may silently destroy the only route that survives a failure.

In a CI workflow, the repository contains proposed configuration, and automation builds a candidate snapshot and runs tests against approved state. Some invariants can be strict: management networks must not be reachable by users; reserved address space must not be accepted through external BGP; a critical prefix must retain two failure-independent paths; a default route must not leak into a protected domain. For other changes, it is more appropriate to produce a structured report and leave the decision to a person.

The quality of this process is determined not by the number of tests but by the quality of the properties. A green suite may omit the property that later fails in production, while tests that merely repeat existing behaviour can preserve an old mistake. Service owners, security teams and network engineers must connect invariants to service objectives, incident history and architecture rather than treating them as an eternal set of assertions.

Test maintenance becomes part of the cost. When network design changes, an invariant may need a different scope, a new exception or another failure-domain model. The most dangerous response to a failing test is to disable it until the suite is green without investigating the cause. A mature process treats a changed answer as a review event and records what changed: the network, the model or the question.

Answer stability matters as well. pybatfish questions and typed answer elements become an API for internal tools, while an engine or client upgrade can alter the or interpretation of what previously counted as a passing result. Production deployments should therefore pin versions, retain definitions and test upgrades on representative snapshots before a new version begins blocking production changes.

Differential analysis does not eliminate a common-mode model error. If the same missing input or parser defect exists in both base and candidate snapshots, the diff may report that nothing dangerous changed even though both models are wrong. Semantic comparison adds a valuable analytical dimension but does not replace validation of source-snapshot fidelity.

A support matrix is a risk map, not a row of vendor logos

Batfish documents a broad set of network operating systems, firewalls and public-cloud constructs. Such breadth is necessary because a modern service path may cross physical routers, virtual appliances, cloud route tables, security policy and an EVPN/VXLAN fabric. A network-wide property is only as dependable as the least accurately modelled relevant component on that path.

The word supported is too coarse without a feature qualification. A parser may recognise a file format while the conversion layer models only common statements. A protocol may be implemented without particular vendor extensions, or a configuration element may be read without affecting a particular question. Operators need an answer about semantic coverage rather than the mere appearance of a vendor name on a page.

The July 2025 release demonstrates this gradual process. Initial A10 support covered a specific subset, including BGP, ACLs, virtual servers, NAT and VRRP-A. Initial SONiC support usedconfig_db.jsonandfrr.conf, while EVPN/VXLAN modelling expanded around Layer 3 tunnel establishment and Type 5 routes. These additions broaden the classes of networks that can be analysed but do not make coverage a binary property.

Conversion warnings are the operational interface to this boundary. Some warnings concern statements irrelevant to the invariant being tested; others identify unsupported behaviour on the path itself. Treating every warning as fatal is impractical, but hiding all warnings is dangerous. Teams should classify warning categories by their effect on properties and separately review new warning types.

Defaults create another risk. A vendor may imply behaviour absent from the textual configuration, while a new network operating-system version may change that default. A cloud provider can generate routes or policy from external service state. Complete analysis may therefore require inventory, interface state, cloud API exports, host addresses and external advertisements, not configuration files alone.

The support matrix also shows where the project spends limited engineering resources. Supporting many vendors and features requires specialists, regression tests and continual review. Open-source contributors, commercial users, vendors and integrators may set different priorities, so wider adoption also expands the maintenance surface on which semantic defects can occur.

In the supplied material, Network to Code appears as part of the contributor and integrator ecosystem associated with platform support and automation use. Vendor network-operating-system communities provide formats and semantics that Batfish must represent, while GitHub contributors add parsers, questions and fixes. These relationships matter to sustainability but do not create automatic ownership or a formal member-governed foundation.

Failure analysis is useful only when the failure domain exists in reality

Batfish can model selected failures by changing the state of interfaces, routes, nodes or protocols and recalculating routing and reachability. Resilience engineers can therefore ask in advance whether policy and connectivity survive a failure, and find a single point of failure, a filter that blocks a backup route or two paths that unexpectedly converge on one dependency.

The scenario must correspond to a real failure domain. Removing one interface is not the same as losing a line card, rack, fibre conduit, building, cloud region or shared control service. Two links may appear independent in configuration while using the same duct, and two virtual networks may depend on a single provider control plane.

Batfish computes the topology and assumptions it receives; it does not automatically discover every common cause outside configuration. Inventory quality, circuit records, facility data and cloud architecture therefore become part of the evidence needed for meaningful resilience testing. An incorrect failure-domain label can invalidate the conclusion even when symbolic analysis is entirely correct.

Convergence creates another boundary. A stable post-failure state may be safe while a transient path during withdrawal and recomputation temporarily violates a service objective. Batfish can analyse many resulting states but does not reproduce every vendor timer, queue and race, so failure exercises and protocol telemetry remain necessary.

The best use of failure analysis is to make a resilience claim executable. If a service promises zone independence, the zones should be represented explicitly and removed in turn. If a backbone claims to have two diverse exits, the relevant dependencies and the loss of each should be modelled, while a new backup route should be tested specifically after the primary path disappears and together with security policy.

Such properties must be revisited after physical changes. A new cross-connect, cloud attachment, tunnel or shared appliance can create a common dependency without changing the high-level diagram. Failure-domain data ages just as configuration does and requires its own change discipline.

Open-source governance and commercial stewardship are connected but not interchangeable

Batfish is distributed under the Apache License 2.0 and remains a public open-source project. Its repository, issue history, documentation and release notes give users a technical history they can inspect. The foundational research was collective, and the later codebase includes a wider contributor base, but those facts alone do not imply a member-governed foundation with a simple and fully public allocation of authority.

The supplied evidence does not show an independent membership foundation controlling Batfish. Current maintainer roles are less apparent in public material than commit and release activity, so publication should carefully distinguish a specific repository contribution from a formal governance title. Commit history shows who contributed code but does not automatically identify who has final authority across every subsystem.

Several names are historically important. Ari Fogel and Ratul Mahajan co-authored the foundational paper and later became co-founders of Intentionet; Todd Millstein is associated with programming-languages and analysis contributions, Ramesh Govindan with academic networking, while Stanley Fung, Luis Pedrosa and Meg Walraed-Sullivan also authored the original work. The most accurate attribution remains collective: the early architecture was a multi-author research result, and modern Batfish is a maintained open-source codebase with a broader contribution history.

Intentionet, founded in 2018 around commercial use of Batfish, is a separate company. It builds products and services around the engine and provides a clear channel for enterprise support and adoption. Its employees may contribute substantially to the open project, but company leadership, project maintenance and customer operations are separate categories. Revenue, funding, customer claims and proprietary product capabilities cannot automatically be attributed to Batfish.

Commercial stewardship can strengthen an open-source project. Paid engineering helps fund parser work, integrations, documentation, support and production fixes that are difficult to sustain through volunteer effort alone. The same relationship also creates attribution and priority risks if users start treating every commercial feature as part of the upstream project or if practical operating knowledge becomes concentrated in one company.

An open licence provides a legal route to use, study and modify the code without a project licence fee. It does not create an operations team, data-collection process or support policy for the user. Enterprises still need people who understand snapshot construction, warnings, question design, upgrades and the boundaries of particular platforms. Open source reduces one form of dependency while leaving skills and integration as real switching costs.

The project’s long-term credibility will be visible through ordinary maintenance signals: public releases, issue responses, regression tests, parser corrections, documentation, contributor diversity and clear treatment of unsupported behaviour. A project can remain legally open yet become difficult to operate independently if essential knowledge moves beyond the public codebase. Conversely, commercial support is compatible with upstream portability if the core analysis can be reproduced without proprietary dependencies.

The portfolio covers parsing, routing, forwarding, policy, cloud and automation

Batfish is often described with a single label — a network configuration analysis tool — but its working surface is much broader. Configuration parsing normalises supported vendor syntax, control-plane computation derives routing outcomes, forwarding analysis turns them into paths and reachability, differential analysis compares candidate and approved snapshots, and failure questions alter selected state. Other questions examine ACLs, routing policy, cloud entities and overlays, while pybatfish connects all of this to automation.

These capabilities serve different groups. Network-automation teams depend particularly on parser fidelity and reproducibility; architects and routing engineers use control-plane and policy questions to understand route selection; security and change-review teams are more interested in reachability and filter effects. Resilience engineers model failures, developers and SREs integrate checks into delivery processes, and an enterprise may use all these roles at once without treating Batfish as a single monolithic product.

The snapshot remains the common assembly point. For change management it creates auditable evidence: an answer is tied to a particular state, engine and question. For security, the same mechanism connects a segmentation assertion to a specific network version; for automation, it can stop a change before any production device is touched.

Parsing and conversion define the first trust boundary. The control-plane engine then models supported route origination, propagation, filtering and selection; forwarding synthesis combines routing with filters, NAT and topology. BDD reachability extends the question across packet classes, differential questions distinguish semantic from textual change, ACL equivalence and search identify permit-and-deny differences and unreachable lines, while routing-policy analysis shows how route maps and BGP attributes transform routes.

Each capability has its own limit. Runtime protocol timing and vendor defects may diverge from the model; physical loss and performance remain outside forwarding analysis; both snapshots in a differential test can contain the same modelling error; and application identity may sit above the fields represented in an ACL query. Unsupported vendor extensions can alter a routing-policy result, failure modelling simplifies some correlated and transient behaviour, and EVPN/VXLAN coverage depends on platform and feature.

pybatfish makes these functions available to automation but does not change the allocation of responsibility. The Python library returns typed tables, traces and properties, yet analysis still requires an engine and a correct snapshot. Public examples lower the entry barrier, but a notebook operating on a sample topology does not prove fidelity for a particular private network until its own features and warnings have been validated.

Commercial integration adds another layer. Intentionet and other integrators may package collection, dashboards, workflow and support around the open engine. This may be a rational choice for enterprises that do not want to build every adapter themselves. Commercial products should nevertheless be described separately from Batfish so that claims about capabilities, economics and portability are not confused with the upstream project.

Batfish sits between linting, emulation and live observability

Batfish’s role is easier to understand through neighbouring approaches. A configuration linter usually examines text or local policy and quickly finds syntax errors, deprecated commands, style violations or known risky patterns. Batfish goes deeper by computing interactions inside a network-wide model, but in return requires more complete input and broader semantic coverage.

Device emulation addresses the problem differently. Cisco CML, EVE-NG and similar platforms run network operating-system images and can reproduce some real protocol behaviour and timing, which is especially useful for laboratory testing of vendor-specific software. That approach demands more resources when exploring vast spaces of packet headers, topologies and failures. Batfish operates at a more abstract level and thereby achieves a different scale with different blind spots.

Commercial assurance platforms, including Forward Networks and IP Fabric, pursue overlapping goals through packaged products. In the supplied material, Forward Networks is described as a commercial network digital-twin peer with live collection and a supported product platform, while IP Fabric is described as a network-assurance and discovery peer focused on operational snapshots and visualisation. They may reduce integration work through built-in collection, topology discovery, dashboards and support.

Batfish’s advantage in this comparison is an open and inspectable analysis engine. Its disadvantage is the surrounding engineering work: an organisation may have to build or separately purchase state collection, normalisation, identity management, workflow, user interfaces, version management and live verification. An open core is not the same as a ready-made operations product.

Formal-methods tools form another neighbouring category. They may verify narrower properties, protocols or configuration languages with very strong mathematical guarantees. Batfish matters because it combines broad multi-vendor network semantics, packet behaviour and operator-facing questions in one practical engine, not because it is the only tool to use formal methods.

Live telemetry platforms address the opposite point in time. They observe real routes, interfaces, latency, flow records, logs and service behaviour after or during deployment, and can therefore detect optical degradation, transient failure or congestion that Batfish does not model. They cannot always say what a candidate configuration that does not yet exist in production will do.

The best operating model combines pre-change modelling with live measurement. Batfish checks intended routing and forwarding before rollout, while telemetry and probes confirm selected outcomes on the real infrastructure afterwards. Choosing either model or observation as the sole source of truth weakens assurance rather than strengthening it.

This comparison also explains the difficulty with the term digital twin. Batfish models configuration, routing and forwarding in considerable depth but does not reproduce every physical, temporal and application-level behaviour. It is more accurate to call it a network model or configuration-analysis twin with explicit boundaries than a mirror of production that supposedly knows everything.

Managing the model becomes managing the network when tests block releases

When a Batfish question can stop a production change, the model acquires institutional power. A parser decision affects whether configuration is understood, a question definition may encode security or resilience policy, and an engine upgrade may alter the outcome of a previously passing test. The team that controls snapshots and assertions begins to influence network change even when routers and cloud accounts belong to other departments.

Such control requires ordinary software discipline. Questions should be versioned, reviewed and assigned owners; test fixtures should reproduce important defects; and engine upgrades should be checked against representative snapshots before promotion. Rollback is needed not only for network configuration but also for the assurance system if a new version unexpectedly changes critical answers.

The process for resolving disagreement between model and operator is especially important. If a live route, trace or packet observation contradicts Batfish, neither side should win automatically. Treating every mismatch as a device defect destroys trust in the model, while explaining every mismatch as a model limitation deprives the analysis of real authority.

A useful dispute must be reproducible. Configuration, external inputs, engine version, warnings, the question and production evidence should be retained, after which the source of the difference can be determined. A parser may have missed syntax, the conversion layer may have approximated a feature, the snapshot may have omitted runtime state, a device may behave in an undocumented way, deployment may have diverged from source control, or the invariant may simply fail to express the relevant business requirement.

A mature programme concludes such an incident with a regression test, corrected input, an updated invariant or a documented limit. In this sense, Batfish gradually moves ownership from configuration towards intent. Configuration becomes the implementation, while the requirement becomes a separately discussable and testable entity.

A service requirement might state that ‘payment servers are reachable from application networks but not user segments’, ‘customer routes never reach the public internet’, or ‘every critical site survives the loss of one failure domain’. These statements can be discussed by people who do not know every vendor command, after which network engineers convert them into executable questions.

Encoding intent distributes responsibility rather than removing it. Service owners formulate the property, network engineers connect it to topology, headers and policy, security teams specify prohibited paths, automation builds snapshots and runs tests, maintainers represent vendor semantics, and operations validates the deployed outcome. A passing process and a broken service can still coexist, but layered evidence makes the cause easier to locate.

Overrides also require governance. Some unsupported syntax may genuinely be irrelevant to a particular invariant, while a known model discrepancy may have a safe explanation. If bypass is impossible, teams will avoid the assurance system; if bypass is permitted without a record and expiry, the system loses its purpose. An exception should therefore identify the affected property, evidence, owner and closure condition.

The institutional result extends beyond one tool. Network change begins to resemble software delivery: source state is versioned, tests express expected behaviour, review occurs before deployment, staged rollout limits blast radius, and post-deployment evidence checks whether reality matches the model. Batfish does not create the entire discipline by itself, but it provides a network-wide analytical engine for it.

The source of truth determines whether the engine proves the right network

Batfish can calculate the consequences of a snapshot far more consistently than a person can mentally execute thousands of configuration lines. The snapshot must nevertheless represent the system that will actually operate. A precise answer about a stale or incomplete world may be operationally wrong despite complete internal logical consistency.

Source-control drift is an obvious example. A repository may contain intended configuration while production devices have local emergency changes. Pre-change analysis then proves the repository state rather than the actual starting point, and the next change may interact with an unrecorded production difference in a way the model never sees.

Cloud state creates another form of gap. Routes, security attachments, interfaces and service-generated entities may come from an API or control plane outside the repository. If a snapshot contains templates but not generated state, it may miss the path that actually determines reachability. The operator must decide which external data belongs in the model and how fresh it must be.

Inventory can be wrong more subtly. Two circuits may be labelled diverse while sharing one conduit, or devices may sit in different logical zones while retaining a common power dependency. Batfish can prove redundancy perfectly within those labels and still be wrong about the physical system.

A disciplined workflow therefore closes the loop between intent, delivery and observation. The organisation records the property, constructs a candidate snapshot from intended configuration and external state, runs questions, and retains the engine version, warnings and answers. After deployment it captures actual state, compares it with intent and uses live probes and telemetry for selected outcomes.

This chain distinguishes several failure classes. The intended change may have been wrong, deployment may have differed from intent, the live system may have exceeded the model because of an unsupported feature or physical condition, or the query may not have expressed the actual service requirement. Retaining evidence at each stage turns a ‘network problem’ into a diagnostic decision tree.

Warnings require the same institutional treatment because they describe the edge of knowledge. Some can demonstrably be considered irrelevant to a particular invariant, while others directly alter a path or policy. A mature programme links warning classes to the properties they can invalidate, reduces recurring noise and reviews new warning types before they become familiar.

Questions need owners. Basic reachability is not the same as correct reachability: a network may remain connected while losing path diversity, exposing a management service or selecting an undesirable exit. Service and security owners define the outcome, while network engineers translate it into locations, headers, routes and failures. Question quality therefore becomes part of the control system.

Version upgrades complete the source-of-truth problem. A new Batfish release may correct a modelling defect and change answers without any configuration change. That may be an improvement rather than a regression, but it means the model is itself a versioned dependency. The organisation must know which engine approved a change and review differences before promoting a new version.

A model earns trust when disagreement becomes shared engineering memory

No analysis engine remains correct simply because it once matched production. Vendors add commands, clouds change services, operators introduce new protocols and internal systems generate state in new ways. Batfish must be maintained as actively as the networks it describes. This is not a flaw in the proposition but the cost of explicit assumptions.

A parser defect is an especially useful test of engineering culture. If a vendor command was interpreted incorrectly, the right response is not merely to fix one customer’s snapshot. The configuration, expected semantics and observed production behaviour can become a regression case that prevents recurrence and, through an upstream contribution, turns a private incident into shared knowledge.

The same applies to a poorly formulated query. After an outage, a team may discover that a reachability assertion permitted a path the business considered prohibited because the requirement had never been recorded. The correction is then both technical and organisational: the question changes, as does the process through which service owners communicate intent to the assurance team.

A black-box assurance product may provide a simpler daily experience, and that is genuine value. Learning is harder, however, when the user cannot understand why an answer appeared. Batfish’s open code and typed results allow sophisticated teams to challenge the reasoning, reproduce a counterexample and contribute a fix. Commercial packaging can add convenience around this core without removing the need for transparent failure analysis.

Portability should be tested in practice. A buyer of commercial support should know which questions, snapshots and results can be exported, what remains upstream Batfish, and what requires a proprietary service. If the vendor relationship ends, Apache-licensed code does not disappear, but genuine independence still requires retained skills, data-collection processes, fixtures and operating knowledge.

The operating burden is substantial. Reliable collection of multi-vendor and cloud snapshots requires adapters, credentials and inventory discipline; large suites consume compute; warnings require triage; failed tests require owners; and upgrades require validation. The benefit is not free automation but the movement of engineering effort from emergency diagnosis into maintaining a model, tests and a system capable of failing visibly before production.

Batfish’s long-term credibility is therefore best measured by the quality of its correction loop. A longer vendor list is useful only when semantics are sufficient for real properties; downloads do not prove production maturity; and a customer story is useful only with a clear deployment boundary. Trust grows when users can show where the model failed, correct it and preserve the lesson.

Funding, ownership and geography limit commercial conclusions

Batfish is an open-source project without a standalone public revenue or profit statement. Its code is available under Apache 2.0 without a project licence fee, while development is supported through a combination of employer time, research activity, commercial products and services, integrator work and community contributions. The supplied evidence does not provide a single consolidated project budget.

Intentionet’s economics must be kept separate. The company’s funding, revenue, customer base, valuation and margin cannot be attributed to Batfish unless a source speaks directly about project economics. The connection matters because the company was founded by project creators and builds offerings around the engine, but it does not turn a commercial metric into an open-source metric.

Caution is also required with claims about deployment savings. Preventing an outage can indeed avoid substantial cost, while discovering an error during code review saves incident-response effort and customer impact. These observations cannot be converted into a general Batfish return on investment without named customer evidence, an avoided incident or a measured change-validation study.

Contributor labour is distributed among employers, commercial support and community work. Maintaining a broad set of vendor parsers is itself a sustainability risk because every network operating system changes and only a limited number of specialists can validate the semantics. Commercial and upstream priorities may diverge, regressions may occur, and documentation may lag newly added coverage.

Competition creates additional pressure. Vertically integrated assurance platforms sell collection, discovery, visualisation, support and workflow in one product. Some organisations will therefore choose packaged convenience even when an open engine can technically answer the same questions. Batfish’s economic advantage is not ‘free assurance’, but the ability to build on an inspectable, reusable core without a project licence fee while accepting more integration work internally.

Geographically, the software is global. Its research origins and Intentionet are associated with the United States, but repository location and contributor affiliations do not determine deployment geography. The engine can analyse networks in any country where an operator runs it, and supported vendor formats represent products with a global footprint, although no audited country-by-country census is available.

Cloud modelling adds provider and regional context without changing ownership. Batfish can analyse supported AWS and Azure constructs, but it does not own or operate cloud networks. Enterprise and provider configurations remain under customer control. The project’s global reach is therefore primarily software applicability rather than a physical network footprint.

Limitations that do not disappear after every qualification

Snapshot completeness is the first unavoidable limitation. The model sees only supplied configurations and environmental data. A missing device, external route, generated state or incorrect topology label can produce an internally confident but operationally incomplete answer. A better parser cannot solve missing input.

Parser coverage is the second limitation. Vendor features are implemented gradually, and support depth depends on syntax, release and question. A statement outside the model can change real behaviour. Conversion warnings and regression tests reduce the risk but do not turn coverage into a permanent binary property.

Intent encoding is the third. Batfish answers explicit questions and does not automatically infer every business requirement from configuration. A team can test the wrong property perfectly. The stronger the analysis, the more important agreement becomes among service, security and network owners about what the invariant actually means.

Dynamic protocol behaviour creates the fourth boundary. The engine computes stable or selected states under supported semantics, while real networks experience timers, asynchronous updates, implementation quirks and transient convergence. A safe steady state does not guarantee a safe transition, so exercises and live protocol telemetry remain necessary.

The physical network is the fifth boundary. Configuration does not reveal dirty fibre, a bad optic, queueing delay, an overheated line card, packet corruption or an ASIC defect. Production can degrade despite entirely correct routing and policy invariants, so model-based assurance does not replace physical observability.

BDD performance is the sixth. Symbolic representations compress immense packet spaces, but some topologies, transformations and queries remain computationally expensive. If Batfish becomes a mandatory release gate, the assurance platform itself needs capacity planning and defined time budgets.

Cloud-state freshness is the seventh. Provider APIs and service semantics change quickly, while snapshots depend on timely exports and current feature support. Even with an unchanged repository, the cloud model can become stale. Data collection and parser maintenance therefore remain connected tasks.

Company-project attribution is the eighth. Commercial products around Batfish may include features, support commitments and economics absent upstream. Combining these identities exaggerates adoption and distorts ownership, so naming discipline forms part of technical accuracy.

False assurance is the ninth. Formal language can create an impression of absoluteness and encourage teams to abandon staged rollout, probes or live validation. The safer rule is the opposite: a formal answer is valuable precisely because its conditions are explicit and testable.

Adoption opacity is the tenth. Public repositories, downloads and visible case studies do not reveal the number of private production deployments or the versions in use. Market-leadership claims are difficult to verify. Influence is better assessed through code, use cases and documented deployments without inventing a census.

The practical promise is a staged assurance chain, not total correctness

Batfish’s most durable contribution is a change in the default question. Traditional review asks whether configuration looks reasonable; Batfish asks what the entire network will do according to the model. Routing, security and resilience expectations become properties that can be tested before deployment rather than only after an incident.

The assurance chain has several stages, and separating them is an advantage. A parser may accept configuration, the common model may compute the control plane, a question may pass against forwarding state, and deployment may install the expected configuration, while live packets, optics and applications still behave differently because of missing input or a physical condition. Recording every stage makes a mismatch diagnosable.

A passing result should be read literally: one defined property held in one explicit model of one network state under one engine version. This is narrower than saying ‘the change is safe’, but that is what makes it defensible. It can be reproduced, challenged and improved, whereas visual review rarely leaves an equivalent audit trail.

The boundary between model and measurement reinforces the same conclusion. Batfish can predict that routing and filters permit a flow, while telemetry shows whether real packets, queues, optics and applications deliver the expected service. When they disagree, the organisation gains a useful diagnostic branch: the intended change may have been wrong, deployment may have differed, the model may be incomplete or the physical system may have failed.

Success is therefore not measured by the number of parsed files. It depends on the number of consequential properties that teams can formulate, test, review, deploy and then confirm in production. Vendor coverage matters because it supports that discipline, not because a long support matrix can itself replace fidelity.

Batfish’s promise is deliberately incomplete. The project can move a large class of network failures from production into review, make assumptions explicit and provide counterexamples before customer impact. It does not eliminate the physical network, operational judgement or live evidence, and is most useful when those boundaries remain visible.