AVD variables
A repo of group_vars or structured_config. The design is
already machine-readable, so netlld reads it as it stands.
Point netlld at AVD variables, at the running-configs off your switches, or at a live fabric over eAPI. Get the Low-Level Design, topology diagrams, a bill of materials, a design review, a Statement of Work and a project plan — plus the Ansible and device configuration to build it back.
Footage: Dima Krivoy / Pexels
Every source becomes the same vendor-neutral fabric model, so the document, the diagrams and the configuration all come from one place.
A repo of group_vars or structured_config. The design is
already machine-readable, so netlld reads it as it stands.
Drop in show running-config from each switch. No AVD repo needed —
this is the brownfield case, and the one nothing else answers.
Point it at the switches over eAPI, or let CloudVision supply the inventory. The document describes what is actually running.
No fabric yet? Describe spines, leaf groups, tenants and addressing, and get the design document before anything is racked.
Generate a full LLD from a built-in Arista fabric — no input needed. Pick the
scenario: a straightforward leaf-spine, a three-tier multi-pod with super-spines, or a
fabric with border leaves facing a WAN. Each is a real AVD structured_config
in the repo, so this is the same pipeline your own files would take.
Adds serials, rack positions and cable records, and shows what a disagreement looks like: the sample NetBox has one cable on the wrong port and one missing.
No AVD file needed — define the fabric here. Pre-filled with a working example you can edit freely.
"Generate LLD now" builds straight from these two numbers — same one-click simplicity as the Sample tab, no services or endpoints needed. Use "Fill in the rows below" instead if you also want to add tenants or endpoints first.
switch:port, switch:port)Document a fabric you already run. Upload Arista EOS running-configs (show running-config, one file per switch), or AVD structured_config / fabric.yml files. netlld works out which one you gave it.
Reads serials, rack positions, cables and management addresses for the uploaded switches only, and lists every place NetBox and the configs disagree. The NetBox must be reachable over https from the internet; for an internal NetBox, use the command-line tool (build.py --netbox). The token is used for this one build and never stored — use a read-only token.
Uploaded files are deleted as soon as the document is built, and every value that looks like a password, key or SNMP community is removed from them before they are read. The document itself is deleted after 24 hours, or straight away with the Delete button beside it. Two things worth knowing before you upload a production config: strip passwords and SNMP communities first, and note that this is an open preview — anyone holding the link to your generated document can open it, so treat it as shareable. For sensitive networks, run the command-line tool on your own machine instead.
Design the back-end network for a GPU cluster: a rail-optimised, two-tier routed Clos where GPU r in every server cables to rail leaf r. You declare the GPUs, the switches (port count, speed, interface naming, breakout lanes), the RoCE settings on both switches and NICs, the address pools and the optics. netlld works out the switch counts, every cable, every address and ASN, checks that the NIC and switch halves of the lossless class agree, and writes the LLD, cable schedule, EOS configs and an ANTA catalog. Nothing platform-specific is assumed: a value the spec doesn't give is an error or shown as "not declared".
YAML or JSON in the shape {switch: [{port, neighbor, neighbor_port}]}. Every port is compared with the cable map, and the LLD gets an As-built section listing what is wrong, missing or unexpected.
Two-tier designs only, up to 8,192 GPU links in the browser. A bigger cluster, or one that needs a super-spine tier, is refused with the largest size that fits; the command-line tool (build_ai.py) takes the same spec. Port counts, ECN thresholds and part numbers vary by platform and release: check them against the datasheet for the SKU you're ordering. The documents are deleted after 24 hours, or straight away with the Delete button.
Map any vendor's network from the one thing every switch can tell you: who it's plugged into. Upload saved show lldp neighbors or show cdp neighbors output (brief or detail) from Cisco IOS/IOS-XE/NX-OS, Arista EOS, Juniper Junos or HPE Aruba AOS-CX. You get a diagram, a cable map and the problems a neighbour table exposes. A link counts as confirmed only when both ends report it; one-way and conflicting reports, native-VLAN and duplex mismatches, and ports with several neighbours are listed as findings.
Uploads are read in memory and never saved; only what the parsers pick out (device names, ports, platforms) reaches the report. Anyone holding the link to the report can open it until it is deleted after 24 hours, or straight away with the Delete button.
Answer the questions you'd ask on a customer discovery call — rack count, redundancy, environments, hardware preference. No ASNs, VLANs, or IP math required up front; netlld fills in the engineering detail and generates the full LLD at the end.
The customer/organization name and site — these appear on the cover of the generated document.
Every leaf always uplinks to every spine — that's automatic. These answers just size it.
Each becomes its own tenant / VRF — fully isolated at layer 3. VLANs and subnets can be filled in later once addressing is finalized.
Pick from common Arista platforms, or specify your own if you already know the model.
Underlay point-to-point links, loopbacks, and VTEP addressing. If they don't know yet, netlld assigns sensible defaults.
Optional — applied to the generated LLD's cover page and footer.
This is exactly what gets built — go back to any step to change an answer.
These are the real figures from the 12-node example above — DC2, four 7280R3A spines and eight leaves across 7050X3 and 7060DX5. Nothing here is typed in; every number is counted off the fabric model.
Plus the LLD as Word and HTML, a bill of materials, a Statement of Work, a project plan, and a runnable Ansible + AVD project.
The document is half the round trip. The same fabric model writes the configuration that builds it, two ways — and the addressing a live fabric already has is pinned, so nothing renumbers an underlay that is carrying traffic.
One Arista EOS .cfg per switch, straight from the design. No Ansible, no
AVD collection, nothing to install — the configuration the LLD describes, ready to
read. build.py --configs, or inside the zip from any build here.
Inventory, playbook, group_vars and an ASSUMPTIONS.md for
anything inferred. ansible-playbook playbook.yml and AVD builds the same
fabric its own way.
compare.py proves what AVD built matches what was documented, and
drift.py checks the design against the live network over a file, eAPI or
CloudVision.
Generated configs are what the design implies, not a replacement for what a switch runs today. Every file opens with a banner saying exactly that.
Every fabric below came out of its own AVD variables or its own running-configs. Nothing on this page was drawn by hand, and nothing in the documents was inferred from a picture.
Footage: Pexels
Six Arista fabrics, three views each — two leaf-spine pods, a three-tier multi-pod with super-spines, a border-leaf WAN edge, a plain L3LS Clos with no overlay, and a collapsed MLAG pair. Every one generated by the tool, not drawn by hand. The slides advance on their own; hover to hold one still.
The same diagrams that live in the repo under diagrams/,
generated from mermaid sources. Pick one; it draws itself.
/admin alone sits behind HTTP Basic, and generated
documents are deleted after 24 hours.AVD already generates fabric documentation, free, from Arista. If you run AVD and a Markdown reference is what you need, use it. netlld is for the two things it cannot reach: a fabric with no AVD repo, and a document someone signs off on.
| AVD self-documentation | netlld | |
|---|---|---|
| Input | AVD variables only | AVD vars, running-configs, live eAPI/CloudVision, or a form |
| Output | Markdown and CSV | Word, HTML and PDF — the format a contract names |
| Fabric with no AVD repo | Not possible | Documented from its running-configs |
| Beyond the document | — | Design review, BOM with optics, SOW, project plan |
| Back to configuration | — | AVD project and device configs, addressing pinned |
| Checks against the live network | — | Drift, over file, eAPI or CloudVision |
| Cost | Free, and maintained by Arista | Free open preview |