How to Automatically Run Reachability Checks on Every Network Change

You’d never make a change to your network without running it through ample checks first. But are you really checking everything?

Even complex Python scripts that you continuously update, that rebuild your entire topology from scratch, have a blind spot: They only see the network as it exists the instant that script runs.

If someone adjusts a schema or adds a device minutes later, another team member’s change might have unintended consequences no one knows about—until you’re all stuck firefighting a midnight outage or dealing with a failed audit.

With Infrahub’s new Graph Traversal capability, you can cover all your bases with Reachability Checks that automatically assess changes across your entire network in real time while a Proposed Change is still in review.

What’s a reachability check?

For the purposes of this article, we’re defining reachability checks as a set of rules that assert one part of your network can reach another through approved points only, never through forbidden ones.

Today, most teams enforce a rule like that in a Python script. The script pulls the devices, interfaces, and BGP sessions, rebuilds the topology in memory, walks every source-to-destination path, and applies the rule. It’s essentially rebuilding your network graph in code by hand.

There are a few issues with this approach:

First, some rules don’t make it into code at all. They live in Slack threads, old Confluence diagrams, or the longest-tenured team member’s head.

Second, network paths are always changing and your scripts have to change too. Even if you do manage to codify every rule, keeping them enforced on every change as engineers add devices, reroute traffic, and touch the topology daily is really, really hard. And it gets harder the bigger your team gets.

On a small team, the person making a change has mapped out the whole network they’re about to touch. In a large org, an engineer rerouting traffic or swapping an ASN on one team may have no idea they’re about to break a path another team is responsible for. They don’t have the full map, let alone all the rules, in their head.

What makes Infrahub Reachability Checks different

Infrahub stores your network as a graph: all the devices, sessions, zones, and tenants are queryable objects. Any change to the modeled intent appears in the graph immediately, including a change still under review in a branch.

Infrahub’s Graph Traversal traces every path between a source and destination and any dependencies between them. Other tools can trace paths but they surface those paths as a backend API for engineers to script against. Infrahub puts a rule-authoring UI on top of a live graph. That means any operator (not just a programmer) can define what “reachable” means and have it enforced automatically.

And because Infrahub Reachability Checks run against the Proposed Change in its branch, and shows the graph as it would look after merge, engineers can see a violation their change would introduce before it reaches production, not after.

Reachability rule permissions give you control

Infrahub lets you control who can define your reachability rules.

• Automation specialists can write scripted checks.
• Operators are granted a rule-authoring permission through Infrahub’s object-level RBAC. They define and refine Reachability Checks: which paths must hold, which transits are forbidden, and how deep to look.
• Network engineers can propose changes to the graph but they can’t create, edit, or delete Reachability Checks.

With these permissions, network operators can guarantee their rules are being followed, and engineers can be confident their proposed changes won’t cause issues down the line.

How to write an automatic Reachability Check in Infrahub

1. A network operator authors a Reachability Check.

Let’s say they want to assert that ATL1-edge1 can reach JFK1-edge1 via AS 64496 but never AS 8220.

In Infrahub, they head to Reachability Checks > Add a Reachability Rule, then input:

• The source (ATL1-edge1)
• The destination (JFK1-edge1)
• Max depth (say, 3)
• Max paths (say, 50)

Then they add their two constraints:

1. Must transit: AS 64496
2. Must never transit: AS 8220

As soon as the rule is published, Infrahub automatically reviews every Proposed Change against it. No need for an engineer to memorize the rule or even know it exists.

If any part of the reachability rule or its constraints are changed, those updates takes effect immediately.

2. An engineer opens a Proposed Change.

Reachability Checks run, tracing every path from source to destination and testing each of those paths against every rule and constraint in the Reachability Check.

3. The change passes or fails.

In the Checks tab of their Proposed Change, engineers see green for passed tests or red for failed tests. In the case of a failed proposed change:

• The violation is flagged on the Proposed Change so it can’t slip through unnoticed. Whether this hard blocks a merge or surfaces as a required failing check depends on your merge policy.
• The engineer can open the reachability rule in the UI to see exactly which constraint their change violated. Rules are visible to everyone although only operators can edit them.

Using Reachability Checks to solve common network engineering problems

As you can imagine, Reachability Checks that assess every Proposed Change against every rule and your live graph are useful for solving a lot of common network engineering problems.

Here are just a few of the problems that can be solved:

• Impact assessment: Before a change merges, you can see source-to-destination paths it might break.
• Dependency analysis: Map everything a node touches so when something goes down, you know exactly what’s affected.
• Security compliance: Prove every flow crosses the required inspection zone and never an unapproved bypass. If you define as rules your PCI scope, zero-trust boundaries, or whatever your compliance framework demands, those get checked on every change.
• Capacity management: Check a change against the capacity and utilization you’ve modeled on each link so a proposed path won’t be routed over one that’s already modeled at its limit.
• Path redundancy: Enforce that critical pairs always maintain two disjoint paths. If losing one link would leave you with no failover, you find out before the maintenance window.
• Hop-count bounds: Assert that a destination must be reachable within a specific hop budget along approved low-latency transit.

Have more to add? Let us know in the OpsMill community on Discord.

Getting started with Reachability Checks

• Watch a full deep dive on reachability checks on YouTube.
• Read the blog post on Graph Traversal to go deeper on how it works.
• Explore our reachability schema repository.