gabrielmoreira ANTA validation — the assertion layer
Every other NetClaw source reads state. This one asserts on it and returns a verdict you can act on.
Server: anta-mcp (NetClaw-authored over ANTA 1.9.0, Apache-2.0, own virtualenv) · 4 tools ·
1,272 tokens · 208 tests in the catalogue
Which plane answers — read this before reaching for another server
Three servers touch Arista. They answer different questions, and picking the wrong one gives a confidently wrong answer.
| Plane | Server | Answers |
|---|---|---|
| Validation | this skill | does the state match what it should be — pass/fail |
| Management | arista-cvp-mcp |
what does CloudVision say — inventory, tags, compliance as CVP sees it |
| Device CLI | pyats-*, multivendor-cli |
what is the raw state — show-command output |
Use this skill to assert, not to fetch. If the question is "what is the interface MTU", that is the CLI plane. If the question is "is the MTU what it should be", that is this one.
The verdicts — five, and they never merge
| Verdict | Means | Never counts as |
|---|---|---|
pass |
tested, expectation held | — |
fail |
tested, expectation did not hold | — |
not_applicable |
the feature is not configured — nothing was tested | fail |
skipped |
ANTA declined to run it | pass |
error |
device unreachable or the run broke | fail |
not_applicable is the one that matters
ANTA natively reports a test for an unconfigured feature as a failure. Measured on a lab switch:
VerifyBGPPeerCount → failure
"'show bgp summary vrf all' failed on veos1: BGP inactive"
That device has no BGP at all. Reporting it as a failure claims a BGP fault where there is no
BGP. The server reclassifies it to not_applicable and keeps the original message.
When you report results: say "BGP: not applicable — this device does not run BGP", never "BGP test failed".
There is no health percentage, and you should not compute one
passed / total is meaningless when not_applicable and skipped sit in the denominator. Forty
tests of which thirty are not applicable is not "25% healthy" — it is ten real answers and thirty
non-answers. The server refuses to emit a percentage. Report the five counts.
Workflow
1. Find the tests (contacts no device):
anta_list_tests: category="routing.bgp" # or keyword="ntp", or both
2. Learn what a test needs (contacts no device):
anta_describe_test: test="VerifyEOSVersion" # returns its input schema
Do this whenever a test takes inputs. A test run without required inputs is reported as skipped
with the requirements listed — it does not guess a default and silently test the wrong thing.
3. Run them:
anta_run_tests:
host: "172.20.20.4"
tests: ["VerifyEOSVersion", "VerifyUptime", "VerifyNTP"]
inputs: {"VerifyEOSVersion": {"versions": ["4.36.1F"]}, "VerifyUptime": {"minimum": 3600}}
Or by category: category: "hardware".
Reading a result honestly
- An unreachable device returns
errorwith zero results. It is not a broken device — nothing was tested. Say "could not reach the device", never "the device failed its tests". - An empty selection returns
no_tests_selected. No test matched. That is not a healthy device. - A
failnames observed and expected. Quote both — "NTP expected synchronised, actual unsynchronised" is actionable; "NTP test failed" is not.
Credentials and scope
ANTA_USERNAME / ANTA_PASSWORD come from the environment and are never tool arguments and
never appear in output. ANTA_VERIFY_TLS defaults to false because lab switches ship self-signed
certificates — and the setting is always disclosed in the response as tls_verified, so a
downgrade is visible rather than silent.
Boundaries
- EOS only. ANTA is Arista's framework. This is not multivendor validation, and it must not be described as such.
- Read-only. ANTA tests; it does not configure. There is no remediation path here — if a test fails, fixing it goes through the normal change process with its CR gating.
- On demand. This is not continuous monitoring. For "what was it doing over time", use
zabbix-metrics-history.