FAQ
How fast are validation runs?
Execution time depends on your infrastructure size, complexity, and which engines are involved. Intent checks are the fastest -- they query NetBox data directly with no external dependencies. Config and graph checks add analysis overhead that varies with device count and topology complexity. See Scaling Best Practices for detailed guidance on expected performance at different scales.
Do I need device connectivity?
No. Intent validation reads NetBox data only. Config analysis reads rendered configs from Config Templates. Graph analysis reads NetBox data models. None require SSH or API access to devices.
What NetBox version is required?
NetBox 4.5 or later in NetBox Cloud. Branch validation requires NetBox Branching and NetBox Changes.
Can I validate devices from multiple vendors in one policy?
Yes. Intent and graph checks evaluate NetBox data, which is vendor-neutral. Config analysis operates on rendered configs, which are vendor-specific but template-driven. The config engine's NOS support is aligned with Batfish's supported platforms.
Can I run validation without NetBox Branching?
Yes. Manual and scheduled runs work without Branching. You only need Branching and Changes for the pre-change validation workflow (branch -> validate -> merge).
How do AI agents use validation?
Agents access validation through the Validation tools in the NetBox Labs Platform MCP Server, which provides tools for running validation, querying compliance analytics, and managing findings. Agents typically follow a branch workflow: create a branch, make changes, run validation, self-correct on failures, and request human review when all checks pass. See Workflows for the full agentic workflow and API Reference for the available tools.
How do I handle devices that intentionally deviate from policy?
Use the suppressed finding status to mark known exceptions. You can also use rule-level roles and platforms overrides to exclude specific device types from checks that don't apply to them.
Which compliance frameworks are supported?
Eight compliance framework policy packs are included: NIST 800-53, PCI-DSS, NIS2/DORA, NERC CIP, ISO 27001:2022, TIA-942, MANRS, and CLOS fabric design. Each pack maps specific framework controls to NetBox-validatable checks (155 total rules). See Policy Packs for details.
How complete is the framework coverage?
Each pack explicitly documents what it covers and what it doesn't. For example, the NIST 800-53 pack covers SC (boundary protection), CM (config management), CP (contingency), and AC (access control), but does not cover AU (audit logging), AT (training), PE (physical security), or SI (monitoring). NetBox Validation provides design-time compliance validation -- validating infrastructure intent before deployment. Controls that require runtime monitoring, human procedures, or physical security need other tools.
Where do checks get expected values?
Three sources, in order of precedence:
- Rule parameters -- values set on the rule (e.g.,
min_uplinks: 2) - Check defaults -- built into the check (e.g., default management prefix
10.0.0.0/8) - Config context -- dynamic per-device values from NetBox config context (e.g., NTP servers, BGP ASN)
Rule parameters override check defaults. Config context is read from the device's merged config context at runtime.
What happens with unknown check names?
Results are created with status=error and a message explaining the check was not found. Other checks in the run continue normally.
Can I create no-code checks?
Yes. Declarative checks use a query+assert pattern defined entirely in rule parameters. Set check_name to _declarative and define the query, assertion, and failure message in parameters. See Engines for details and examples.
How does the graph engine interact with device targeting?
The graph engine always builds the full site topology regardless of device targeting -- it needs complete dependency chains for infrastructure analysis. Results are then filtered to the targeted device set. This means targeted graph runs are not faster than full-site runs. For graph-heavy policies, use site-scoped runs. See Scaling Best Practices for details.
How are compliance scores calculated?
Per device, per policy, per run: score = passed / (passed + failed + errors) x 100. Skipped checks are excluded. Scores persist across runs -- a targeted run updates scores for the devices it evaluated while preserving previous scores for other devices.