Introduction

‍

Invariant is a system which validates your network according to user-provided rules in a highly scalable digital twin environment.

The digital twin is created directly from your network configuration files without any need for routing table dumps or any access to your network. A wide range of vendors are supported. This approach allows Invariant to catch subtle failures in a secure, ephemeral environment long before you would deploy them.

The Invariant rule language is very powerful and easy to use. Invariant critical flow rules assert that no cases exist where critical traffic could be dropped. Invariant policy rules restrict what traffic should be permitted for sensitive subnets or define traffic flows that should never be permitted in the network.

This article introduces the Invariant policy language, the processing model, and the digital twin network in more detail.

‍

Invariant policy language

Invariant’s powerful policy language allows you to make testable statements about how certain traffic should be handled by your network as a whole. These statements are called rules.

Rules can be grouped in two broad categories:

Critical flow rules, which describe traffic which should never be blocked or dropped.
Policy rules, which describe traffic which must never be successfully delivered.

If a rule fails, Invariant will automatically produce one or more virtual traceroutes demonstrating the issue.

All elements of the network are considered when testing a rule. This includes all of the following features:

BGP configuration
OSPF configuration
Static routes
VLAN / VXLAN configuration
ACLs
Enabling or disabling interfaces
Inconsistent configuration on mirrored devices
NAT
Asymmetric routing and other return path issues

Rules are expressed using simple YAML files. An example rule file appears here:

access-policy:
 - name: sensitive-vlan-policy
   comment: Policy for the sensitive vlan.
   ingress-network:
     destination-address: VLAN40
     destination-exclude: VLAN40_IF
   rules:
     - type: ingress-critical-flow
       comment: |
         [tick/2719] Allow SRE Alice remote access.
       source-address: ALICE_DESKTOP
       destination-port: SSH
       protocol: TCP UDP
     - type: ingress-deny
       comment: Deny all UDP inbound to the lab.
       source-address: RFC1918
       source-exclude: VLAN40
       protocol: UDP
     - type: ingress-deny-others
       comment: Limit ingress to only SSH from alice's desktop
       within:
         - protocol: TCP
           source-address: RFC1918
       deny-all-except:
         flows:
           - comment: Internal SSH access
             source-address: ALICE_DESKTOP
             destination-port: SSH
             protocol: TCP

‍

As shown above, rules may include owner and comment fields which could be used for justification and other compliance functions. Rules are grouped into policy sections for some target ingress or egress network. Each rule has a distinct type value with all three ingress rule types shown.

In this example, the first rule defines a critical flow for SSH traffic originating from network ALICE_DESKTOP (a /32 representing an example device) with destination address in the VLAN40 network (a /24 representing all hosts in VLAN40), excluding the IPs associated with the ingress/egress interfaces for VLAN40. The ingress/egress interfaces are excluded to limit the scope of the rule to host IPs in the VLAN40 network. Invariant will search for any possible combination of protocol, source and destination address, source and destination port within the critical flow constraints which would not be delivered successfully to VLAN40 - even if the issue might be intermittent (path-dependent).

The second rule asserts that UDP traffic originating from any internal location except VLAN40 itself should never be permitted to reach the VLAN40 network (once again excluding the IPs associated with the ingress/egress interfaces for VLAN40). Invariant will search for any possible combination of protocol, source and destination address, source and destination port within the rule constraints that could be delivered to VLAN40. Details about exactly what network interfaces would be considered as internal locations here can be found in the Rules File Syntax reference section.

The third rule asserts that the only TCP traffic allowed to reach VLAN40 from an internal location is SSH traffic originating from network ALICE_DESKTOP. All other TCP traffic from internal locations should not be able to reach the VLAN40 subnet.

See Rules File Syntax for a complete description of the policy language.

‍

One-shot policy evaluation

‍

Invariant uses a flexible one-shot evaluation strategy. Each time you invoke Invariant, a new digital twin network is created from your configuration files. Your rules are tested in the context of the network.

Invariant will generate data files at the end of each invocation. The files generated will include:

Which policy rules passed or failed.
Virtual traceroutes and other debugging context information for failed rules.
A listing of any traffic which could be dropped or rejected depending on the path taken.
Details about your network’s digital twin, including routing tables, IP allocation, VLANs, OSPF areas, BGP sessions, and more.

See section Data for a complete description of all generated data files.

‍

Instant digital twin

‍

Invariant creates a scalable digital twin network using your network configuration files. The digital twin includes routing tables calculated from BGP, OSPF, VLAN, and other configurations. It supports a range of network device vendors and also AWS network security configs. The digital twin network uses a very memory efficient representation of the network so that many devices can be considered at once.

Cabling information does not need to be explicitly provided - in most cases adjacency can be correctly inferred by matching interfaces with adjacent IPs (and you can provide additional cabling info as needed). It understands ACLs and is reasonably accurate in its representation of the network.

‍

Digital twin creation process

‍

The digital twin network is created using Batfish. This works using the following process:

Parse user-provided network configurations.
Load any user-provided override information.
Translate all vendor-specific interfaces and features into a small vendor-agnostic representation of the network.
Estimate adjacency using interfaces on the same transfer net with adjacent IPs.
Simulate BGP, OSPF convergence and compute routing tables for all devices, VRFs, VLANs, etc.

‍

Digital twin limitations

Supported features and platforms

‍

The network device platforms supported by Invariant are listed on the Supported Platforms page.

Users should be aware that while support for features that impact routing and ACLs are typically very good among the supported platforms, not every feature is necessarily supported. See Troubleshooting.

IPv4

Invariant only understands IPv4 networks.

‍