Skip to main content

Connectivity Validation Overview

Invariant empowers network and security teams to proactively validate network connectivity and enforce security policies using a powerful rule-based system within a digital twin environment. This ensures that critical services remain accessible and security postures are maintained, whether monitoring a live network or testing changes before deployment.

At its core, Invariant's connectivity validation relies on user-defined rules that specify expected network behavior:

  • Critical Flow Rules (critical-flow): Assert that specific traffic must always be successfully delivered. Violations occur if any part of this defined flow is blocked or fails to route.
  • Deny Rules (deny): Assert that specific traffic must never be successfully delivered. Violations occur if any path allows this traffic.
  • Deny-Others Rules (deny-others): Assert that within a defined scope (e.g., all TCP traffic to a sensitive zone), only explicitly permitted flows are allowed, and all other traffic within that scope is denied.

These rules are evaluated against a model of your network built from its configuration files.

Evaluation Models: How Rules are Checked​

Invariant offers flexible ways to evaluate your network against these rules:

On Upload (Installed Rules)​

This is the primary method for ongoing validation.

  1. You define your connectivity and security rules in YAML files within the invariant/policies/ directory of your network snapshot.
  2. When you upload your snapshot using the invariant run command, Invariant analyzes the network model and evaluates all installed rules against it.
  3. The results of this evaluation, including any violations or confirmations of policy adherence, are stored. This creates a historical record of your network's compliance status.
  4. You can access these results using the invariant show <report_name> command. For example, invariant show policy_violations would list any access policy rules that failed.
# Example: Run analysis on the current directory's snapshot
invariant run

# Example: Show violations for access policy rules
invariant show policy_violations --json

Iterative Testing & Pre-Flight ("Try-Rule" Concept)​

While Invariant doesn't have a single command named "try-rule" for ad-hoc checks without permanent record, the same principle of testing rules or configuration changes is achieved through an iterative workflow:

  1. Local Changes: Modify your local snapshot files. This could involve:
    • Editing device configurations to simulate a change.
    • Adding or modifying rules in your invariant/policies/ directory.
    • Simulating "what-if" scenarios, such as the impact of a link failure (e.g., by commenting out an interface in a config file or, for more advanced simulations, using capabilities like Batfish's fork_snapshot if building custom PySDK scripts).
  2. Re-evaluate: Run invariant run on this modified local snapshot. Invariant will create a new analysis record for this version.
  3. Analyze Results: Inspect the reports as you would for a regular upload.

This iterative process is fundamental for:

  • Rule Development: Testing new rules to ensure they behave as expected.
  • Pre-Flight Change Validation: Evaluating the impact of proposed network configuration changes before they are deployed to the live network. This could be integrated into CI/CD pipelines, as demonstrated in the Preflight Automation Demo.

Enforcement Strategies: Applying Validation in Practice​

Invariant supports two main strategies for enforcing connectivity policies:

Live Network Monitoring​

  • Process: Regularly (e.g., hourly, daily) sync your live production network configurations into a dedicated Invariant Network (e.g., a network named "live_production_scans").
  • Benefit: Invariant continuously validates your live network state against your defined policies. This provides ongoing assurance and rapid detection of unintended changes or emerging compliance issues.
  • Outcome: If violations are detected, alerts are triggered (see Alerting). The historical record of snapshots helps in tracking when a violation started and was remediated, aiding in Time To Remediation (TTR) analysis.

Pre-Flight Change Validation​

  • Process: Integrate Invariant into your change management workflow. Before any network configuration change is deployed, the proposed configurations are uploaded to Invariant (often to a separate Invariant Network or a temporary snapshot in the main network).
  • Benefit: This allows you to catch potential connectivity issues, security policy violations, or unintended side-effects of a change before it impacts the production environment.
  • Example: A network team works on a change in a Git feature branch. A CI/CD pipeline (like Jenkins) automatically runs invariant run on this branch. If Invariant detects violations, the build fails, preventing a problematic change from being merged or deployed.

Alerting on Violations​

Invariant automatically generates alerts when rule violations are detected during a snapshot evaluation.

  • Configuration: Alerts are configured via Notification Groups in the Invariant UI (Settings > Notification Groups). You can specify email addresses to be notified for violations within specific Invariant Networks.
  • Timeliness: This ensures that relevant teams are promptly informed of issues, enabling quicker response and remediation.

Troubleshooting Connectivity Issues with Invariant​

Invariant provides powerful tools for troubleshooting connectivity problems, whether they are discovered through alerts from live monitoring or during pre-flight validation.

Initial Triage​

  • Alerts: Alerts provide the first indication of an issue, typically pointing to the specific Invariant Network and snapshot where violations occurred.
  • Invariant UI: The Invariant web UI (often linked from an alert, conceptually) provides a quick overview of the failing snapshot, the rules that were violated, and often direct links to example traceroutes for those violations.

Detailed Analysis with CLI Reports​

For in-depth investigation, the Invariant CLI is invaluable:

  • Violation Details: Reports like critical_flows_details (for critical flow rule failures) and policy_details (for access policy violations) provide concrete examples of violating traffic flows. 
    invariant show critical_flows_details --json
    invariant show policy_details --json
  • Virtual Traceroutes: These reports include detailed virtual traceroutes. Unlike traditional traceroutes, Invariant's traces show:
    • The hop-by-hop path of the example packet.
    • Routing decisions made at each hop.
    • Evaluation against ACLs and firewall rules encountered along the path.
    • The final disposition of the packet (e.g., ACCEPTED, DENIED_IN, NO_ROUTE).

Historical Investigation​

If an issue is detected in the live network, you can use Invariant's snapshot history to determine when it began:

  • List Snapshots: Use invariant snapshots to view a list of past evaluations with timestamps. 
    invariant snapshots --network live_production_scans --tsv
  • Inspect Historical Reports: Use the snapshot UUID with invariant show --snapshot <uuid> ... to retrieve reports (e.g., policy_violations) from a specific point in time. This helps pinpoint when a violation was first introduced.

Root Cause Analysis​

Invariant aids in root cause analysis, especially when the reason for a failure isn't immediately obvious:

  • Comparing Snapshots: If a change introduced an issue, you can compare various reports (e.g., routes, bgp_session_status, interfaces, ipsec_edges) between the problematic snapshot and a known-good (e.g., "golden") snapshot. Diffing the JSON or TSV outputs of these reports can highlight specific configuration or state changes that led to the problem. 
    # Example: Diffing route tables
    invariant show routes --snapshot <bad_snapshot_uuid> --json > bad_routes.json
    invariant show routes --snapshot <good_snapshot_uuid> --json > good_routes.json
    diff good_routes.json bad_routes.json
  • Testing Hypotheses Safely: If you suspect a particular configuration change or failure caused an incident, you can:
    1. Modify a local copy of your network snapshot to reflect your hypothesis (e.g., revert a specific config line, comment out an interface to simulate a link down, change an ACL).
    2. Run invariant run on this experimental snapshot.
    3. Observe if the original issue is resolved or reproduced. This allows you to confirm or deny potential causes in a safe, offline digital twin environment without impacting the live network.

By leveraging these capabilities, Invariant provides a comprehensive framework for validating network connectivity, enforcing security policies, and efficiently troubleshooting issues.