Mgmt firewall, cable plan and Ansible export, a click-together topology builder, and pods for leaf-spine-superspine fabrics.

[muhittink]

Dont merge, just to show some ideas

What changes for an existing plan

Opening a plan you already have, without touching anything:

• The BOM orders more.
  • Two mgmt firewalls in a redundant management network, one otherwise. Each is a vendor-neutral 1U server with 6x 1G RJ45, running pfSense or Debian with FRR. The Teltonika RUTXR1 used so far is end of life, last order 2027-02-03 per Teltonika's EOL list.
  • RJ45 cables change. Each mgmt server now has one cable, to its own mgmt spine, instead of one to every mgmt spine. Each mgmt firewall adds three, as in the deployment guide's routed out-of-band network.
• 25G breakouts are counted per leaf. A breakout serves one switch port, but a group's ports spread over the leaf pair. Groups whose node count is not a multiple of 4 were ordered short: 9 nodes need 6 breakouts, not 5. The leaf capacity check had the same error. Groups of 8 nodes, as in the templates, are unaffected.
• Plan format 2. Files exported now are refused by older planners instead of losing data silently. A stored plan the app cannot read is kept under metal-stack-planner/plan-unreadable before it is replaced.
• Leaf-spine-superspine plans get pods. A plan without pods gets an implicit Pod 1 holding every rack, plus the central rack's own spines. That doubles the spines in the BOM, and validation warns that a single pod gains nothing over leaf-spine. See below.
• Clicking the topology selects instead of jumping to the Plan tab. "Open in plan editor" in the inspector still jumps. Clicks on the diagram used to not arrive at all in Chromium, see the pointer fix below.

Management network

• Mgmt server i, mgmt firewall i and mgmt spine i form a chain. The firewall links to the server, to the server's BMC and to the mgmt spine's eth0.
• Each spine hands its single eth0 to one mgmt spine, in turn.
• Mgmt links are colored by the port they land on: red for a switch's eth0, green between front-panel ports.

Topology builder

• A palette adds partitions, racks, rack groups, server groups, spines, exits, routers and external networks at the current selection.
• An inspector reuses the Plan tab's section editors. They now size their grids by the section (container queries), so they also fit the narrow inspector.
• Server groups can be dragged onto another rack. The move uses moveChassis from Sven-Ric's drag-and-drop-rack branch: only the model function, its tests and the store action, in a commit under his name.
• ZoomPane captured the pointer on every press, so no click on a diagram element ever arrived. It now captures only once a press moves past 4 px.

Cable plan and Ansible export

derive/deploy/cabling.ts names both ends of every cable in a partition:

• Hostnames follow a production inventory layout: <partition>-r01leaf01, -spine01, -mgmtspine01, -mgmtserver01, -mgmtfw01.
• SONiC port names come from sonic-buildimage port_config.ini for the AS7726-32X and AS4630-54TE. A model without a port map is reported, never guessed.

Its tests compare the cable counts per type with deriveBom() for the default plan, every template, and plans with every cabled feature.

Export Ansible downloads <plan>-inventory.yaml:

• Layout: a group per partition with role child groups and the generic role groups production playbooks target.
• Variable names are the ones metal-roles v0.35.0 reads: sonic-config, metal-core, mgmt-server, dhcp, pixiecore, ztp.
• Addresses: loopbacks, mgmt interfaces and PXE subnets come from the IP plan. The IP plan gains mgmt loopbacks and four /30 mgmt links per side.
• DHCP: dhcp_subnets on the mgmt servers cover every network the switches relay, each server with its own share of the range. The ONIE and SONiC ZTP options are included.
• ASNs: production-like, see the header of inventory.ts.
• Cable plan: planner_ports documents the cables per device.
• Missing inputs stay undefined, never a placeholder, so the roles' asserts stop a run. The file header lists them: control plane endpoints, release, DNS/NTP, BMC credentials, upstream peers, keys, switch MACs.

npm run dev   # Plan tab: "Export Ansible"; Topology tab: palette, inspector, drag & drop
ansible-inventory -i <plan>-inventory.yaml --list

Leaf-spine-superspine: pods and planes

Before, every leaf linked to every spine and every spine to every superspine, so the superspine tier carried no traffic. Now it follows the 5-stage Clos of RFC 7938:

• A pod's racks uplink only to the pod's own spines (Figure 3, section 3.2.3).
• Spine j of every pod connects to plane j of the superspines (section 3.2.4).
• The central rack's spines are the border pod for exits, storage leaves and a control-plane rack, adapted from section 5.2.4.
• ASNs follow section 5.2.1: one for the superspines, one per pod's spines.

derive/pods.ts is the single source for this, and spinePorts() in bom.ts the single rule for spine links. They drive:

• the BOM and the port budgets, incl. superspines,
• the busiest spine's oversubscription ratio,
• the rack layout and the IP plan,
• the cable plan and the Ansible export.

Pods are edited in the central rack section, and each rack picks its pod. The diagram draws each pod as a box with its spines above its racks.

Knob	Where	Meaning
Partition.pods	central rack section	the compute pods; none means an implicit Pod 1
Rack.podId	rack section	the pod a rack belongs to; unknown or absent means the first pod
spineCount	"Spines per pod"	spines of every pod, the central rack included
superspineCount	"Superspines"	must be a multiple of spineCount: one plane per spine

Verification

• npm run test (368), lint, format check and build pass.
• New assertions were shown to fail once against the old code or a deliberate mutation. For example, a full spine-superspine mesh in the cable plan fails the cable-vs-BOM comparison with 44 against 32 trunks.
• The generated inventories were read by ansible-inventory with 0 warnings (it exits 0 even on YAML errors, so warnings were counted). Variable names were matched against metal-roles at v0.35.0-2-g75c0fbe. sonic-config's frr.conf.j2 and sonic-config.yaml.j2 and dhcp's dhcpd.conf.j2 were rendered with the generated host variables.
• These were clicked through in headless Chromium with real mouse events: the builder, drag & drop, the pod editor, and the stored-plan migration and backup.
• A second session reviewed the pod work and re-ran its own mutation probes at 8802e79.

Known limits

• Leaf-spine-superspine is a planning design after RFC 7938, not a metal-stack reference architecture. It has not run on hardware or in containerlab, EVPN over two spine tiers included. Validation says so on every such partition, and the Ansible export marks it "UNTESTED in a lab". Validate it in a lab before ordering.
• Nothing in the export was run against a live fabric. Rendering templates and parsing the inventory proves structure, not behaviour. The ASN scheme and port conventions are this planner's choices, modelled on one production inventory.
• Pod spine hostnames are positional (p01spine01). Removing or reordering a pod renames them in the export.
• Older planner builds on the same origin still replace a format-2 stored plan with an empty one. The backup exists only from this build on.
• Not generated or cabled:
  • an L2 management network,
  • a control-plane rack of its own,
  • the AS4625-54T (no upstream port map),
  • internet routers in the inventory,
  • an end-of-row switch for mgmt leaf eth0,
  • the mgmt firewall's uplink.
• Builder gaps: no "Pod" item in the palette, new racks land in the first pod, no keyboard alternative for drag & drop. Clicking was tested in Chromium only.
• pfSense caveat: pfsensible has no module for FRR/BGP or numbered DHCP options, so a pfSense mgmt firewall is not covered by Ansible.

🤖 Generated with Claude Code