Skip to main content

Network Snapshots Overview

A Network Snapshot in Invariant is a digital twin of your network, enabling offline analysis and validation. It's constructed by Invariant using your device configuration files and other supplemental data, with Batfish as the core network modeling engine.

This approach allows Invariant to analyze your network's behavior—routing, security policies, and connectivity—without requiring live access to your devices, ensuring a secure and isolated environment for pre-change validation and ongoing monitoring.

How Snapshots Work​

Invariant takes your provided configuration files, processes them (including pre-processing steps like credential stripping for security), and feeds them into Batfish. Batfish then builds a comprehensive, vendor-neutral model of your network. This model understands device configurations, routing protocols, firewall rules, and more, effectively creating a simulated version of your live network.

Credential Stripping: Invariant and Batfish analyze configurations offline. Sensitive information like passwords, SNMP community strings, or other credentials are not required in the configurations for analysis and should be removed or replaced with placeholders before creating a snapshot for optimal security.

Supported Vendors​

Invariant supports all network device vendors that Batfish supports. This includes a wide range of physical and virtual devices. You typically provide the output of show running-config (or its equivalent) for each device.

Key supported vendors include:

  • Arista
  • Cisco (IOS, IOS-XE, IOS-XR, NX-OS, ASA)
  • Juniper (JunOS - EX, MX, SRX, PTX, T-Series)
  • Palo Alto Networks
  • Fortinet
  • F5 BIG-IP
  • AWS (VPC configurations)
  • SONiC
  • Cumulus Linux
  • Check Point

For a complete list and specific instructions for each vendor, refer to the Batfish documentation on supported vendors and Invariant's Supported Platforms page.

Core Concepts​

Network as Code in Native Configuration​

Invariant embraces the "Network as Code" paradigm by working directly with the native configuration syntax of your network devices. You don't need to translate your configs into an intermediate format.

! Example: A snippet from a Cisco IOS configuration file
hostname MyRouter
!
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 no shutdown
!
router ospf 1
 network 192.168.1.0 0.0.0.255 area 0

This allows you to use your existing configuration management workflows and version control systems.

Simulated Protocol Negotiation​

The digital twin built by Invariant and Batfish simulates how your network devices would negotiate and establish various network protocols. This includes:

  • BGP: Session establishment, route advertisement, and policy application.
  • OSPF: Adjacency formation and Link-State Advertisement (LSA) exchange.
  • IPSec: Tunnel establishment and security associations.
  • FIB Calculation: Determination of Forwarding Information Bases (RIBs to FIBs) on each device.

This simulation provides a deep understanding of the network's control plane and data plane behavior.

Inserting Missing Pieces​

Real-world networks interact with external entities (like the Internet or private backbones) and have operational states that aren't always fully captured in static configurations. Invariant allows you to provide supplemental data to model these aspects accurately:

  • ISP Connections: Model your Internet Service Provider connections using an isp_config.json file in the batfish/ directory. This helps simulate default routes and external connectivity.
    batfish/isp_config.json (Conceptual Example)
    {
        "borderInterfaces": [
            {
                "borderInterface": { "hostname": "border-router1", "interface": "GigabitEthernet0/0" }
            }
        ],
        "ispNodeInfo": [
            { "asn": 65000, "name": "MyISP", "role": "TRANSIT" }
        ]
    }
  • eBGP Messages: Specify external BGP announcements using external_bgp_announcements.json (Batfish format) to model routes learned from external peers.
  • Layer 1/2 Details: If L3 inference isn't sufficient (e.g., due to IP address reuse or link-local addressing), provide a layer1_topology.json file (Batfish format) with explicit cabling information.
  • Operational States: Use runtime_data.json (Batfish format) to specify operational states like interface up/down status or current bandwidth, which can override what's inferred from static configs.

Model Quality and Fine-Tuning​

The accuracy of Invariant's analysis depends on the quality of the network model. It's crucial to verify this model, especially during initial onboarding.

  • Invariant Reports: Use reports like file_parse_status, ignored_lines, undefined_references, and unconnected_nodes to identify potential issues in how configurations were parsed or interpreted.
  • Explicit Vendor Specification: If Batfish struggles to auto-detect a device's vendor, you can add a RANCID-style header to the configuration file (e.g., !RANCID-CONTENT-TYPE: cisco-ios).

Careful review and fine-tuning ensure the digital twin accurately reflects your network's intended state and behavior.

Directory Structure​

To create a network snapshot for Invariant, organize your files into a specific directory structure. Invariant processes this directory to build the network model.

my_network_snapshot/
├── aws_configs/          # (Optional) AWS resource configurations (JSON)
├── batfish/              # (Optional) Batfish-specific supplemental data
│   └── isp_config.json   # Example: ISP modeling
├── configs/              # Core device configuration files (e.g., Cisco, Juniper)
├── def/                  # (Optional) Network and service definitions (Aerleon/Capirca YAML or .def/.svc)
│   ├── networks.yaml
│   └── services.yaml
├── hosts/                # (Optional) Host configurations and iptables
├── invariant/
│   ├── locations/        # (Optional) Named location definitions (YAML)
│   │   └── locations.yaml
│   └── policies/         # (Required for validation) Invariant rule files (YAML)
│       └── my_policy.yaml
└── probe_targets.yaml    # (Optional) Custom probe targets for connectivity tests

Refer to the Snapshot Reference for detailed information on each directory and file format.

Lifecycle​

The lifecycle of a network snapshot in Invariant involves several key stages:

  1. Upload: The user packages their network configurations and supplemental data into the defined directory structure. This snapshot is then uploaded to Invariant, typically using the CLI. 
    invariant run --target my_network_snapshot/ --network production_dc
  2. Evaluation (Eval): Once uploaded, Invariant processes the snapshot:
    • It uses Batfish to parse the configurations and build a detailed, vendor-neutral model of the network (the digital twin).
    • It then evaluates this model against any Invariant rules (access policies, critical flows) defined in the invariant/policies/ directory.
  3. Data Access: After evaluation, Invariant makes a rich set of data and reports available. This data provides insights into the network model (e.g., routing tables, BGP sessions) and the results of the rule validations. 
    # View routing table for a specific node
    invariant show routes --snapshot <snapshot_uuid> --json | jq '.[] | select(.Node == "my_router")'

    # Check for policy violations
    invariant show policy_violations --snapshot <snapshot_uuid>
  4. Iterative Analysis (Try Rule): The generated model and reports allow for iterative analysis. Users can:
    • Query various aspects of the network model.
    • Refine existing Invariant rules or add new ones and re-evaluate them against the same uploaded snapshot without needing to re-upload all configuration files (if only rules change). This is typically done by modifying rule files and re-running invariant run.
    • Use Invariant's "Try Rule" feature in the UI (or by crafting specific queries) to test hypotheses about network behavior.

This lifecycle enables both pre-change validation (by uploading a proposed set of configurations) and ongoing monitoring of the production network.