A person typing a VLAN into one switch makes one mistake. A template applied to forty switches makes the same mistake forty times, in seconds, before anyone notices.

Validation is the counterweight. It is also the part most automation projects skip, because the first version works and the failure mode is invisible until it is not.

Five layers

Layer Catches Tool
Syntax Malformed YAML/JSON yamllint, parser
Schema Wrong type, missing field JSON Schema, YANG
Policy Valid but forbidden Custom rules
Intent Wrong device, wrong site Inventory checks
Behavior It applied but broke something Synthetic tests

Most teams do the first two and call it done. The outages come from layers three and four.

Policy as code

Rules a district should enforce mechanically:

  • VLAN IDs inside the allocated range for that site.
  • Names matching the scheme (student, staff, not VLAN104-new).
  • No any/any firewall rules.
  • No default route announced without an explicit allowlist.
  • Every network has a zone.

Those are five if statements in a script, and they prevent the errors that are most expensive to diagnose.

def validate(vlans, site):
    errors = []
    for v in vlans:
        if not 400 <= v["id"] <= 999:
            errors.append(f"VLAN {v['id']} outside site range")
        if v["id"] % 10 != site % 10:
            errors.append(f"VLAN {v['id']} does not match site {site}")
    return errors

Diff before apply

Every change should produce a diff a human can read:

- vlan 104 name student
+ vlan 104 name student-devices

If the diff is empty, the change is a no-op and should be skipped. If the diff contains lines nobody expected, stop.

Apply-then-test is not validation

Testing after the change tells you what broke. Validation before the change tells you what would have broken, while the old configuration is still one rollback away.

Five layers: each one catches a cheaper class of mistake than the one below it.

Canary and staged rollout

  1. Render configuration for all devices.
  2. Validate every device's data.
  3. Apply to one canary.
  4. Run synthetic checks against the canary.
  5. Apply in batches, checking between batches.
  6. Stop on the first failure and roll back the batch.

The canary is not ceremony. It is the only step that catches a vendor-specific behavior your schema did not model.

Worked example: a VLAN pipeline

Stage Check Failure action
Lint YAML valid Stop
Schema Required fields, types Stop
Policy Site range, naming Stop
Render Diff generated Review
Canary Client gets a lease, DNS resolves Roll back
Rollout Batch health checks Stop batch

Six stages, each cheap, and the expensive failure is caught at stage five instead of at 08:00.

What breaks in production

  • No policy layer, so a valid but wrong VLAN is applied everywhere.
  • No diff review, so an unintended change rides along with the intended one.
  • No canary, so a vendor quirk hits the whole fleet.
  • Validation that only checks syntax, which passes almost everything.
  • No rollback artifact, so "revert" means retyping.

Next

The last step is making the repository, not the device, the source of truth. Continue with GitOps for Networks.

  • Validation
  • Testing
  • Automation
  • Change Control