SD-WAN Address Planner

Describe your site types, segments, hubs and growth. The planner sizes every block, packs them into your parent range on natural boundaries and gives you a formula and a full list of site subnets, so the plan can go straight into a template, a script or an IPAM. Tell it which ranges you already use and it will warn you about clashes and steer clear of them.

1. Start from a preset or build your own

2. Parent range

Network in CIDR form

Ranges you already use (optional) One per line, with an optional label after the range. The planner warns when a block overlaps one of them, and the quiet range suggestion keeps clear of them. Nothing you type leaves your browser.

3. Design

Regions Each region gets its own summary route Hubs / data centres Total across all regions LAN block per hub (prefix) For example 22 gives a /22 per hub Devices per site Default. 2 for an HA pair Devices per hub Each gets a loopback Transports per site Default. Tunnels per hub, per spoke Cloud networks VPCs, VNets or transit hubs Cloud network prefix For example 20 gives a /20 each Site growth (%) Default. Extra site slots reserved Host growth (%) Extra hosts reserved per segment Reserved per subnet Network, broadcast, gateway, HA Tunnel model ADVPN uses a shared overlay subnet per hub Tunnel addressing Pool for overlay interface IPs

4. Site types

Each site type has its own segments. Name them anything you like, give each a host count, and optionally force a prefix length or set a VLAN ID. Devices, transports and site growth can be overridden per type; leave them blank to use the defaults above.

5. Plan

Allocation

Block	Role	Size	Addresses	Detail

Site templates

The same layout repeats for every site of that type. Use the formula to generate subnets in a Jinja template or script.

What is left in the parent

Export

The site list has one row per site per segment, with generated site names such as BRANCH-001, the region, VLAN and subnet. It covers the sites you have today, not the growth slots.

How it works

Each segment is sized to the smallest block that holds its hosts, the growth you asked for and the reserved addresses per subnet. A /30 is the smallest subnet it will produce. If you force a prefix that is too small for the hosts, the planner uses the size that fits and tells you. The segments of one site are packed into a single block, and that site block is rounded up to a power of two.

Site blocks of the same type are grouped into a pool sized for the planned site count, including growth. With more than one region, each region's pools are grouped again, so a region advertises as one route and the whole design as one more. Hub LANs, cloud networks, overlay addresses and loopbacks sit beside them. Everything is packed largest first, which keeps each block on its natural boundary and leaves the free space at the end as large aligned blocks.

Tunnel counts assume every spoke builds a tunnel to each hub in its own region on every transport. That is the hub-and-spoke case. Partial meshes and dual-device sites will change the real numbers, so treat the count as a starting point and check it against your platform's documented limits.

The Fortinet ADVPN model changes two things. First, overlay addressing. In Fortinet's ADVPN examples the hub and all of its spokes share one overlay subnet, with a /32 on each tunnel interface, so the planner reserves one subnet per hub per transport, sized for every spoke on it plus the hub, instead of a pair of addresses per tunnel. Second, shortcut tunnels. A spoke builds them on demand from an existing tunnel and they reuse that tunnel's address, so they add no addressing. They do count against the IPsec tunnel limits on your spokes, which is what the shortcut estimate is for. The number you enter is your own guess at peak concurrent shortcuts per spoke, because the planner cannot know your traffic pattern. Unnumbered tunnels stay unnumbered under either model.

Ranges you already use are checked against each planned block, role by role, and against what is left free in the parent. The planner does not pack around them. If one overlaps, it tells you which blocks are affected, and the quiet range suggestion looks for a parent that clears all of them, trying 10.0.0.0/8 first and then 172.16.0.0/12 and 192.168.0.0/16.

This is IPv4 only. The built-in clash check compares your allocated space with a short list of ranges that often collide with home routers, Docker, Kubernetes, cloud defaults and VPN products. It cannot see your own network beyond what you list, so check the result against your IPAM before you commit.

Where an IPAM fits

This page designs the address space. It does not remember what you assign afterwards, and it cannot see what is already in use. Once a plan is agreed, an IPAM is the right place to record it and to keep it honest. These are the options I would look at, roughly from lightest to heaviest:

A spreadsheet or a Git repo. The site list CSV and the JSON export are plain files, so for a small deployment they may be all you need. Keep them in version control and review changes like code.
phpIPAM: a lightweight, open source, web-based IPAM that is easy to host yourself. A good step up from a spreadsheet.
NetBox: open source IPAM and DCIM with a REST API, widely used as a network source of truth. A natural fit if you automate your builds from data.
Nautobot: a network source of truth and automation platform that began as a fork of NetBox, with a stronger focus on plugins and job automation.
Infoblox and BlueCat: commercial DDI platforms that manage DNS, DHCP and IPAM together. They suit large estates where DHCP and DNS need to follow the address plan automatically.
AWS VPC IP Address Manager: worth a look if most of your address space lives in AWS and you want allocation rules enforced there.

The site list CSV has one row per site per segment, so loading it into a prefix import takes a little reshaping, which I have not tested against any particular IPAM. Whichever one you choose, treat the IPAM as the record and this planner as the design tool that feeds it.

Python version

The same planner is available as a command line tool and a Python library: sdwan-address-planner on GitHub. It is MIT licensed, needs nothing beyond the Python standard library, and gives the same answers as this page. Use it when a plan belongs in Git next to your templates, or when a CI job should fail because a design no longer fits or a new range collides.

pip install git+https://github.com/MichealGarner/sdwan-address-planner.git