Network Topology Engine

Stable

← Back to Network Automation

Concept

Graph operations on network topologies demand native performance — Python’s NetworkX caps out on large topologies. The Network Topology Engine provides a Rust-native topology engine with Python bindings, giving the Network Modeling & Configuration Library the speed of compiled code with the ergonomics of Python.

Quick Facts

What This Is

The Network Topology Engine is the Rust backend that powers the Network Modeling & Configuration Library’s graph operations. Originally embedded within the Network Modeling & Configuration Library as ank_nte, it has been extracted into its own repository as the engine matured and its scope grew beyond a simple backing store.

It provides native-speed graph algorithms, query execution, and data storage for network topology operations. It uses petgraph’s StableDiGraph for topology representation and Polars for columnar data storage.

Why It Was Split Out

As the Network Modeling & Configuration Library evolved, the Rust core grew into a substantial system with its own architectural concerns:

• Multiple storage backends (Polars, DuckDB, Lite) requiring independent testing
• Distributed compute support via nte-server and nte-backend
• Monte Carlo simulation capabilities in nte-monte-carlo
• Independent release cadence — Rust compilation and Python wheel builds benefit from isolation

Separating the Network Topology Engine enables independent versioning, faster CI, and clearer ownership boundaries.

Architecture

The Network Topology Engine is organized as a Cargo workspace with specialized crates:

Query Engine (nte-query)

The nte-query crate provides a composable query API that executes against the topology graph. Queries are built as chains of filter, select, and aggregate operations that compile down to efficient graph traversals:

• Node/edge filtering by attribute predicates (role, type, layer membership)
• Path queries — shortest path, all paths, constrained walks
• Aggregation — count, group-by, statistical summaries over topology subsets
• Lazy evaluation — queries build an execution plan, only materializing results on .collect()

Queries execute in Rust and return results to Python via PyO3, avoiding the overhead of Python-side graph traversal.

Storage Backends

The Network Topology Engine supports pluggable storage through the nte-datastore-* crates:

• Polars (nte-datastore-polars) — Primary backend. Columnar storage for efficient analytical queries over node/edge attributes.
• DuckDB (nte-datastore-duckdb) — SQL-based backend for complex analytical queries, joins, and aggregations. Useful when topology data needs to be correlated with external datasets.
• Lite (nte-datastore-lite) — Lightweight in-memory backend for small topologies and testing.
• LadybugDB (Potential) — Under evaluation as an embedded analytical database backend, offering fast columnar queries with a smaller footprint than DuckDB.

Integration with the Network Modeling & Configuration Library

The Network Modeling & Configuration Library imports the Network Topology Engine as a Python package built with Maturin/PyO3. All graph mutations and queries flow through the engine’s Rust core:

Network Modeling & Configuration Library (Python API)
    │
    ▼
NTE Python bindings (PyO3)
    │
    ▼
nte-query → nte-core → nte-datastore-*

Python users interact with the Network Modeling & Configuration Library’s Pydantic models. The Network Topology Engine handles the performance-critical work underneath.

Tech Stack

Rust, petgraph (StableDiGraph), Polars, DuckDB, PyO3/Maturin for Python bindings

← Back to Network Automation