Size the network before you quote it.
Feed in RVTools data or manual host counts, define the per-host port profile, pick your TOR and FC switch platforms โ and get port counts, oversubscription ratios, dual-fabric SAN math, a switch BOM, and a customer-ready report. 100% in your browser, nothing uploaded.
How it works
1๏ธโฃ Load demand
Drop an RVTools export (.xlsx) and it reads host counts per cluster from the vHost tab โ or type host counts in manually, or try the demo environment. Optionally log your existing switch inventory so the plan shows net-new vs reuse.
2๏ธโฃ Configure fabrics
Set the target host count and the per-host port profile โ mgmt, data/vMotion, storage IP, FC HBAs. Then tune each fabric: TOR preset, uplinks, oversubscription target, dual-homing and spares for Ethernet; FC preset, ISL reserve, array target ports and dual fabric for the SAN. Live switch-count previews as you tune.
3๏ธโฃ Get the network plan
Switch BOM with net-new vs existing reuse, oversubscription ratios, per-fabric worked math, SE talking points, and a downloadable HTML briefing report.
What it reads from RVTools
| Tab | What it unlocks |
|---|---|
vHost | Host count per cluster โ the only required tab. Network sizing starts from hosts, not VMs |
vInfo | VM counts per cluster โ context only, shown next to host counts so the demand table reads like the estate |
Same tolerant parser as the other sizers โ modern and legacy column names both work, missing tabs degrade gracefully. No export handy? Manual entry takes host counts per group, which is all the math needs.
Sizing math, explained
Ethernet and FC are sized as two independent fabrics off the same host count:
downlink ports = hosts ร ฮฃ ports/host per class mgmt + data/vMotion + storage IP
TOR switches = ceil(downlink ports รท usable downlinks/switch) rounded to pairs for A/B dual-homing, +1 for N+1 spare
oversubscription = ฮฃ(downlink ports ร speed) รท (switches ร uplinks ร uplink speed)
FC switches/fabric = ceil(device ports รท 2 รท (switch ports โ ISL reserve)) device ports = host HBAs + array targets, split across Fabric A/B, total ร 2
Worked example โ 12 hosts, profile 2ร1G mgmt + 2ร25G data + 2ร25G storage IP, Cisco Nexus 93180YC-FX3 (48ร25G downlinks, 6ร100G uplinks), dual-homed:
| Step | Numbers | Result |
|---|---|---|
| Downlink ports | 12 ร (2 + 2 + 2) | 72 ports |
| Usable downlinks/switch | 48 (uplinks are separate QSFPs) | 48 |
| TOR switches | ceil(72 รท 48) = 2 โ dual-homed pair | 2 switches |
| Port utilization | 72 รท (2 ร 48) | 75% |
| Downlink bandwidth | 48ร25G + 24ร1G โ 1,224 Gbps | 1.22 Tbps |
| Uplink bandwidth | 2 switches ร 6 ร 100G | 1.20 Tbps |
| Oversubscription | 1,224 รท 1,200 | ~1.02 : 1 |
FC side of the same example โ 2 HBAs/host at 32G, 2 arrays ร 4 targets, Brocade G720 (64 ports, 8 reserved for ISLs): 32 device ports โ 16 per fabric โ ceil(16 รท 56) = 1 switch per fabric โ 2 FC switches (Fabric A + B).
Honest limitations
- This is port-count sizing, not traffic modeling. It doesn't model per-workload bandwidth, burst behavior, or latency โ oversubscription here is a capacity ratio, not a performance guarantee.
- Optics, cables, and licenses aren't priced or counted โ the BOM is switch chassis counts. Your VAR quoting tooling turns that into a parts list.
- The spine / aggregation layer isn't modeled โ uplink ports are counted and ratio'd, but spine switch counts are out of scope.
- Host profiles are uniform โ every host gets the same port profile. Mixed estates (GPU nodes, edge hosts) should be sized as separate runs.
- FC ISL reservation is a port count, not a bandwidth design โ actual east-west ISL needs depend on traffic patterns this tool can't see.
- Switch presets are simplified to port counts and speeds โ features, buffer depth, licensing, and power draw aren't compared. Use Custom when the preset doesn't match the SKU you're quoting.
- No pricing โ the output is switch counts and ratios, which your VAR tooling turns into quotes.
Frequently asked questions
Is my data uploaded anywhere?
No. Files are read with the browser's FileReader API and parsed in memory by a vendored copy of SheetJS running in this page; manual entries never leave the form. There is no server and no network request carrying your data โ check devtools' network tab, or disconnect after the page loads.
Is anything stored in my browser?
Only what you choose to save. Named Projects and autosave live in your browser's localStorage โ on your machine only, never uploaded. Hit "Clear session data" to wipe them, or close the tab and the in-memory session is gone.
Do I need an RVTools export, or can I type numbers in?
Either. The export gives you host counts per cluster automatically from the vHost tab. Manual entry just needs host counts per group โ the math never looks at VMs, they're context only.
What is oversubscription, and what should I target?
The ratio of total downlink bandwidth (everything plugged into the TOR) to total uplink bandwidth (TOR to spine). 3:1 is the classic datacenter rule of thumb the tool defaults to; 1:1 is non-blocking. Storage-heavy or vMotion-heavy estates deserve a lower target โ east-west traffic is what oversubscription punishes.
Why does the tool push dual-homing and dual FC fabrics?
Because a single TOR switch or a single FC fabric is a maintenance and failure blast radius that takes down every host in the rack. A/B dual-homing (vPC/MLAG) and Fabric A/B are standard presales posture โ the tool sizes for them by default and flags it loudly when you turn them off.
How should I size the ISL reservation?
The default reserves 8 ports per FC switch for inter-switch links. That covers a port-channeled ISL trunk between the A-side switches (and B-side) in a two-switch fabric. Bigger fabrics or long-distance ISLs need more โ raise it and watch the usable-port count move.
My hosts run 25G but the TOR is 100G โ what happens?
On the 64ร100G preset, enable QSFP breakout: each 100G port becomes 4ร25G (or 4ร10G). The tool models that. Without breakout, a 25G host burns a whole 100G port โ the findings will call it out as waste.
Should management ports live on the TOR switches?
They can โ SFP28 ports usually accept 1G โ but many shops hang mgmt (and IPMI/iDRAC) off a cheap dedicated 1G switch instead of burning 25G TOR ports. If your profile has 1G mgmt on a 25G TOR, the findings suggest the dedicated-mgmt-switch alternative.
How does existing-inventory reuse work?
Log the switches the customer already owns (preset + count per fabric) on step 1. The plan subtracts reusable ports from demand and reports net-new switches. It assumes existing ports are reusable at the needed speeds โ sanity-check that against the actual installed optics.
Can I share the results with my team or the customer?
Yes โ the Plan tab generates a standalone HTML briefing you can download and email. Fully self-contained, no external dependencies, and it contains only the analysis, which you control. Scrub customer names from group labels first if the report leaves your org.
Does it do pricing?
No โ it produces switch counts, port utilization, and oversubscription ratios. Your VAR quoting tooling turns that BOM into dollars.