Arista ACE-S Automation (Foundations) cheat sheet

EOS is a Linux-based network OS; the CLI runs as a set of user-space processes above an unmodified Linux kernel, so standard Linux tools and containers can coexist with routing processes.

EOS supports two configuration models: the traditional per-feature CLI commands and the session-based 'configure session' workflow, which stages changes, shows a diff, and commits atomically.

The running configuration can be viewed as text ('show running-config') or as structured JSON ('show running-config | json'), the latter being the basis for programmatic parsing.

eAPI (management API) exposes CLI commands over HTTP/HTTPS with JSON or text encoding; requests carry a 'cmds' array, 'format', and 'version' fields, and replies include 'result' plus per-command 'errors'.

CloudVision is a multi-tier platform: a management plane (CVP) for change control, provisioning, and telemetry aggregation, and a data plane of EOS devices streaming to it.

CloudVision change control models every config push as a Change Control with a task list, approval workflow, and rollback snapshot, so changes are auditable rather than direct CLI edits.

EOS devices connect to CloudVision via TerminAttr, the on-box agent that carries streaming telemetry, configlet state, and event data over gRPC.

Arista's model-driven approach uses OpenConfig and Arista-native YANG models; 'management api models' and 'show management api models' expose which paths are available for gNMI/gNOI.

Device identity in CloudVision is keyed on hostname plus system MAC/serial; duplicate hostnames or IP reuse cause device flapping and must be resolved before onboarding.

pyeapi is the Python client library for eAPI; connect with 'pyeapi.connect_to("node")' or a config file, then call node.enable(), node.config(), or node.api('interfaces').

The eAPI JSON-RPC request body uses 'jsonrpc': '2.0', 'method': 'runCmds', 'params' containing 'version', 'cmds', and 'format'; errors are returned per command index, not as HTTP failures.

Netmiko/NAPALM/Scrapli are transport libraries: Netmiko handles interactive CLI sessions, NAPALM provides a vendor-neutral getters/config API, Scrapli offers fast sync/async CLI and NETCONF drivers.

Ansible uses inventory plus modules; Arista-specific modules include eos_command, eos_config, eos_facts, and eos_vlan, and 'ansible_connection: httpapi' with eapi or 'network_cli' selects the transport.

Jinja2 templating renders device configs from variables; use '{% %}' for logic, '{{ }}' for substitution, and filters like 'default()' to avoid undefined-variable failures.

Idempotency means re-running a playbook or script produces no change when state already matches; eos_config achieves this by diffing candidate against running config.

gNMI operations are Get, Set (replace/update/delete), Subscribe (once, poll, stream), and Capabilities; paths use slash-separated YANG node names and Set requires encoding (JSON_IETF or PROTO).

RESTCONF maps YANG to HTTP verbs: GET reads, PUT/PATCH create/merge, DELETE removes, and the media type 'application/yang-data+json' is standard for payloads.

CI/CD for network config typically chains: template render, lint/syntax check, dry-run diff, staged deploy via CloudVision change control, then post-change verification.

Configlets are reusable config snippets bound to containers or devices; they are hierarchical, so a child container inherits parent configlets unless overridden.

Containers form a tree (Tenant > Device > Interface levels); moving a device between containers re-evaluates which configlets apply and triggers reconciliation.

Change Controls execute a sequence of tasks (configlet push, image upgrade, reboot) with optional approval gates and automatic rollback snapshots.

Image management uses EOS image bundles and upgrade workflows; the upgrade task handles copy, boot-variable change, and reboot, with pre/post checks in the change control.

Provisioning (ZTP) uses DHCP options to hand a device a bootstrap file; the device loads the script, registers with CloudVision, and receives its intended config.

Compliance/reconciliation compares intended config (from configlets) against actual device config and flags drift as a compliance error.

Tags and tag-based queries select device subsets for configlet or change-control targeting, independent of container hierarchy.

CloudVision Studios provide a form-driven, model-based config generation layer on top of configlets for common designs (e.g., EVPN, MLAG).

The CloudVision resource API (cvprac / REST endpoints) exposes endpoints like /cvprac for configlet, container, task, and change-control CRUD operations.

TerminAttr streams three main data classes: OpenConfig state paths, EOS-native counters, and event/syslog data, all exported over gRPC to CloudVision.

gNMI Subscribe modes: ONCE returns one snapshot, POLL samples on demand, STREAM sends continuous updates with 'on_change' or a sample interval.

Streaming telemetry scales better than SNMP polling because the device pushes only changed or sampled data instead of the collector walking OIDs.

sFlow samples packet headers plus interface counters; it is stateless export, useful for traffic-mix and top-talker analysis rather than per-flow accounting.

EOS supports 'show interfaces counters' and 'show interfaces counters errors' for local verification; CloudVision aggregates these into interface health dashboards.

CloudVision's telemetry stack normalizes device data into a time-series store, enabling historical charts, alert rules, and anomaly detection.

Alert rules in CloudVision are defined on metric thresholds or event patterns and route notifications via integrations (email, Slack, webhooks).

Flow and telemetry correlation: combine sFlow/IPFIX flow records with interface counters and syslog events to localize congestion or drops to a specific link and time.

NetDB/device inventory and topology discovery feed the observability layer; stale topology or missing device state produces gaps in dashboards and alerts.