Parent folderOpen Confluence

RWS Architecture article

ADR-018 Network validation and drift baseline with Ansible + vendor CLIs

The network operating model needs a single baseline that is simple to execute in production AAP workflows, while still producing auditable evidence and repeatable drift checks. The

  1. Typeadr
  2. Statusaccepted
  3. Domainnetwork
On this page
  1. Context and Problem Statement
  2. Decision Drivers
  3. Considered Options
  4. Decision Outcome
  5. Operational Baseline Contract (Normative)
  6. Positive Consequences
  7. Negative Consequences
  8. Pros and Cons of the Options
  9. Option 1 – Batfish + Nornir + NAPALM + Suzieq
  10. Option 2 – PyATS/Genie
  11. Option 3 – Ansible + vendor CLIs (chosen)
  12. Option 4 – Streaming telemetry + vendor NMS

Context and Problem Statement

The network operating model needs a single baseline that is simple to execute in production AAP workflows, while still producing auditable evidence and repeatable drift checks. The previous multi-tool validation baseline is effective but operationally heavy to maintain across environments.

Decision Drivers

  • Keep precheck, deploy, postcheck, and evidence capture in one orchestration lane.
  • Prefer direct vendor command coverage for operational checks.
  • Reduce cross-tool dependency overhead while preserving Git-centered traceability.
  • Make parser quality and command coverage explicit parts of the control framework.
  • Preserve optional use of advanced analysis tools without making them mandatory for every change.

Considered Options

  1. Batfish + Nornir + NAPALM + Suzieq
  2. PyATS/Genie for pre/post checks and diffing
  3. Ansible + vendor CLIs
  4. Streaming telemetry + vendor NMS for operational truth

Decision Outcome

Chosen option: Option 3 – Ansible + vendor CLIs.

Ansible + vendor CLI evidence collection is now the baseline for network validation and drift workflows in DC 3.0. Existing tools from ADR-003 (Batfish, Nornir, NAPALM, Suzieq) remain legacy optional augmentations where teams need deeper analysis, but they are not required for baseline change gates.

Operational Baseline Contract (Normative)

  • Every production workflow must execute precheck, approval, deploy, and postcheck as distinct gates.
  • deploy must use approved generated artifacts and is not allowed to bypass precheck evidence.
  • Change closure requires a complete evidence bundle: raw command output, parsed output, parser version, workflow/job metadata, actor identity, and change reference.
  • Parser failures, missing artifacts, or missing change metadata are hard failures; the change cannot be marked successful.
  • Static host inventories are out of baseline scope for in-fabric devices; inventory and intent inputs are derived from approved NetBox-backed data.
GateRequired checksMandatory failure behavior
precheckhealth baseline, route-policy baseline, parser assertionsstop workflow before deployment
approvalhuman review of generated diff and rollback planblock deploy when approval is absent
deploystage and apply replace artifact to intended device setabort on any device-level apply failure
postcheckconvergence checks, route-leak negative tests, drift comparisonmark change failed and trigger rollback workflow
evidenceartifact upload and metadata validationblock closure when artifacts are incomplete

Positive Consequences

  • AAP workflows execute checks and deployment in one consistent lane.
  • Vendor-native commands expose platform-specific control-plane and forwarding state directly.
  • Evidence artifacts are generated from the same orchestrator and job context as deployment.
  • Gate-level fail-closed behavior makes validation outcomes auditable and enforceable.
  • The baseline is easier for operations teams to adopt and scale.

Negative Consequences

  • Output normalization and comparison are inconsistent across platforms.
  • Drift detection depends on custom parsing for every device type and software train.
  • Parser and command-profile lifecycle management becomes a first-class operational responsibility.

Pros and Cons of the Options

Option 1 – Batfish + Nornir + NAPALM + Suzieq

  • Good: Strong separation of intent analysis, runtime normalization, and operational observation.
  • Good: High-quality normalized outputs for long-horizon comparisons.
  • Bad: Higher integration and maintenance overhead across multiple tools.

Option 2 – PyATS/Genie

  • Good: Powerful parsing and diffing for supported platforms.
  • Bad: Less aligned with a unified Ansible-centered execution baseline.
  • Bad: Does not inherently cover full intent-proof workflows in generated configuration artifacts.

Option 3 – Ansible + vendor CLIs (chosen)

  • Good: Simple to execute commands at scale.
  • Good: Fits AAP gate execution and evidence retention with low operational friction.
  • Bad: Output normalization and comparison are inconsistent across platforms.
  • Bad: Drift detection depends on custom parsing for every device type.

Option 4 – Streaming telemetry + vendor NMS

  • Good: Broad operational visibility over time.
  • Bad: Does not, by itself, provide pre-change evidence gates for config deployment workflows.
  • Bad: Strong vendor coupling and inconsistent data models across platforms.

Links and References