CLI relies on text matching. SNMP can't write configuration. Those are the two structural failures that model-driven management fixes. AsterNOS unifies three protocols — NETCONF, RESTCONF, gNMI — behind a single YANG model, routing configuration push, state query, and telemetry subscription through one validation engine.
Architecture: One Dispatch Brain, Three Access Channels
AsterNOS's protocol stack has four layers, top to bottom:
Access layer: each protocol carries its own transport. NETCONF runs over SSH, RESTCONF over an HTTP Server, gNMI over gRPC (HTTP/2). Klish CLI commands also enter here, but get real-time translated into YANG expressions by the Command Converter.
Presentation layer: every request converges on one component — YANG Model Validation / Request Dispatch. This is the single entry point. Request type, field boundaries, and dependency rules (YANG's type, pattern, must/when constraints) get 100% pre-validated here before anything is dispatched downward. A validation failure gets rejected before it ever touches the business layer.
Control layer: the CRUD controller turns validated requests into actual operations. In the same layer, the Notification Agent runs in reverse — watching for state and event changes below, then pushing them up to gNMI's Subscribe channel or NETCONF's notification stream.
Model and data layer: Object Mapping bidirectionally maps the business model to SONiC's underlying key-value structure, then writes through a Redis Connector into Redis's Cfg DB. All three protocols, four entry points, converge on the same Cfg DB. That means regardless of which protocol changed the config, the database state before it reaches the ASIC is single and consistent.
At the model level, AsterNOS runs two tracks: proprietary YANG models for deep customization, OpenConfig public models for multi-vendor interoperability. Both get equal parsing, validation, and dispatch support in the architecture — the choice of model doesn't change protocol behavior.
Core Capabilities, Protocol by Protocol
NETCONF (RFC 6241): Transactional Safety
Three datastores: <running/> (active config, writable, effective immediately), <startup/> (loaded on next boot, writable only via <copy-config> or <save-config>), <operational/> (read-only, real hardware counters and state).
Four base operations: <get-config> (queries all three datastores), <get> (running's config + state), <edit-config> (merge/replace/create/delete), <copy-config>, <close-session>.
Capabilities, all implemented:
Writable-running:
<edit-config>writes<running/>directly. No candidate-then-commit two-phase flow.Rollback-on-Error: built in, no client
<error-option>needed. One failed node reverts the entire request — all-or-nothing.Validate: automatic. Clients can't call a separate
<validate>RPC or attach<test-option>— already validated before push.Distinct Startup: running and startup stay separate; syncing requires an explicit
<copy-config>or<save-config>.URL capability:
<copy-config>/<edit-config>accept a<uri>covering file, http, https, scp, sftp, ftp. URI-as-source into a database target isn't supported yet.IETF-NETCONF-Monitoring (RFC 6022, partial):
<get>lists capability set, datastore views, loaded YANG schemas;<get-schema>downloads a model file directly.
Native extension RPCs handle operations: <save-config> (quick save), <image-upgrade> (remote image upgrade, optionally preserving config), <clear-counters-interface> / <show-interface-summary> (stat clearing, diagnostics).
RESTCONF (RFC 8040): Stateless Integration
Two URL families: data under /rest/v1/running/ (e.g. /rest/v1/running/interfaces/Ethernet1), operational actions under /rest/v1/rpc/ (e.g. /rest/v1/rpc/show-version, via POST).
Five HTTP verbs, five operations: GET (read, no state change), POST (create a resource, or trigger an RPC — dual purpose), PUT (full replace, body must carry every required field), PATCH (partial update, only changed fields), DELETE (returns 404 on a resource that doesn't exist).
Capabilities:
Stateless: writes
<running/>directly with immediate effect, like NETCONF, but no SSH session or session lock. Every request is independent — fits concurrent scripting and CI/CD.Pure JSON: request and response bodies are JSON only. Python/Ansible parse directly, no XML conversion layer.
Path compression + depth: redundant list nodes dropped from URLs and payloads;
depthparameter caps how many levels get pulled, up to 10, so one call doesn't drag back the full tree.API Token: long-lived tokens with configurable expiry. Scripts attach
Authorization: Bearer {session_token}— no re-auth per call.Resource isolation: config/state reads and writes are scoped to
/rest/v1/running/; system-level control actions are scoped to/rest/v1/rpc/— the two never overlap in path space.
gNMI: High-Frequency Telemetry
Transport is gRPC/HTTP2, Protobuf binary underneath. Authentication is username/password in gRPC Metadata, wrapped in TLS.
Four standard methods:
Capabilities: discover supported YANG model set and gNMI version.
Get: query config/state data for one or more paths.
Set: Create/Update/Replace/Delete on a target path — each operation resolves to exactly one target, no ambiguous batches.
Subscribe: the core capability. Device pushes updates real-time or on a fixed interval — SNMP polling replaced by active push, nanosecond precision, feeding Prometheus and Grafana directly.
Encoding: config and query use JSON or JSON_IETF (RFC 7951); high-frequency Subscribe streams use GPB binary for volume.
Which One to Use
Scenario | Protocol | Why |
|---|---|---|
Bulk policy push across devices, requiring network-wide consistency | NETCONF | Stateful SSH session + built-in Rollback-on-Error — a partial failure auto-reverts the entire change |
CI/CD pipelines, Ansible/Python scripts, cloud management platform integration | RESTCONF | Stateless, pure JSON, no session lock to maintain — lower barrier for external systems |
High-frequency state collection feeding Prometheus/Grafana | gNMI | Streaming Subscribe replaces polling, at nanosecond precision |
These three aren't mutually exclusive. In AsterNOS they share the same YANG validation engine and the same Cfg DB, so consistency is guaranteed by the architecture regardless of entry point — the choice is about what you need: transactional safety, integration speed, or collection frequency. In practice they run side by side in one automation stack: NETCONF for config changes, gNMI for real-time monitoring, RESTCONF for external platform integration.
