> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Plan a Cisco SD-WAN 20.18 lab: addresses, system IPs, sites, and organization - URL: https://www.pinglabz.com/sd-wan-lab-ip-plan/ - Published: 2026-11-05T20:34:33.000Z - Updated: 2026-11-05T20:34:33.000Z - Description: The addressing plan behind a working SD-WAN 20.18 fabric: system identities, site IDs, transport gateways, management access, and one organization string. Real values, plus the management-VPN mistake to avoid. - Author: Jaime - Tags: SD-WAN, Cisco A router has a system IP, two transport addresses, and a management address. Which one goes in the Validator setting? This plan separates them before we configure anything, using Cisco Catalyst SD-WAN 20.18.2.1 and C8000v on IOS XE 17.18.02, built in my home lab. This is part of the [Cisco SD-WAN series](https://www.pinglabz.com/cisco-sd-wan/). Previous: [Cisco SD-WAN lab options in 2026: what you need to run locally](https://www.pinglabz.com/cisco-sd-wan-lab-options/). Next: [Installing SD-WAN Manager 20.18: first boot and a stable GUI](https://www.pinglabz.com/install-sd-wan-manager/). For SD-WAN Manager (formerly vManage) and the other old names, see the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/). ## Give identity and reachability separate columns A system IP identifies an SD-WAN device, much like a routing protocol's router ID. It looks like an IPv4 address, but it is not the address you put on every WAN interface. A transport address is where packets actually go. The Validator's transport address in this lab is `172.16.30.30`. Its system IP is `1.1.1.3`. The edges use `172.16.30.30` to find it. A management address gives you a separate way in. Keep that address out of user routing. The [VPN guide](https://www.pinglabz.com/sd-wan-vpn-0-vpn-512/) explains transport VPN 0, management VPN 512, and service VPNs. ## Fill in the control-component plan | Device | System IP | Site ID | VPN 0 address | VPN 0 gateway | | ---------- | --------- | ------- | --------------- | ------------- | | Manager | 1.1.1.1 | 1000 | 172.16.10.10/24 | 172.16.10.1 | | Controller | 1.1.1.2 | 1000 | 172.16.20.20/24 | 172.16.20.1 | | Validator | 1.1.1.3 | 1000 | 172.16.30.30/24 | 172.16.30.1 | These addresses are examples for an isolated lab. In particular, the `1.1.1.x` values here are device IDs. Do not configure those public addresses on your Internet-facing interfaces. The three control components share a site ID because they belong to the same lab location. Each system IP remains unique. ## Give each branch a site A site ID groups routers at a location, like a branch number in an inventory. Two routers in one branch can share a site ID. Routers in different branches need the intended site IDs for routing and policy behavior. We have one edge at site 100 and one at site 200: | Device | System IP | Site ID | Gi2, mpls | Gi3, biz-internet | | ------ | --------- | ------- | ------------- | ----------------- | | edge1 | 10.0.0.1 | 100 | 10.10.1.11/24 | 10.20.1.11/24 | | edge2 | 10.0.0.2 | 200 | 10.10.2.12/24 | 10.20.2.12/24 | The gateways end in `.1` in each transport subnet: `10.10.1.1` and `10.20.1.1` for edge1, `10.10.2.1` and `10.20.2.1` for edge2\. Both transports can reach the control components through the routed underlay. An underlay is the ordinary IP network underneath the SD-WAN tunnels. Treat it like the roads the delivery vans need before you can plan delivery routes. A missing gateway cannot be fixed with an OMP policy. [![Lab addressing separates system IPs from VPN 0 transport addresses and gives edge1 site 100 and edge2 site 200](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-lab-ip-plan.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-lab-ip-plan.png?ref=pinglabz.com) ## Keep the management plan separate The lab's access inventory uses these management addresses: | Device | Management access address | | ---------- | ------------------------- | | Manager | 172.30.30.10 | | Controller | 172.30.30.20 | | Validator | 172.30.30.30 | | edge1 | 172.30.30.101 | | edge2 | 172.30.30.102 | These are access coordinates, not the transport addresses advertised to other edges. Do not infer a router interface's VPN from that access inventory alone. I found a management subnet in service VPN 513 in the original build. OMP advertised it to the other site. The [VPN post](https://www.pinglabz.com/sd-wan-vpn-0-vpn-512/) records that mistake. For a clean new build, put out-of-band management in VPN 512, which maps to `Mgmt-intf` on IOS XE. That intended design is Cisco's documented behavior, not a claim that I migrated the running lab's management port. ## Choose one organization string Every device in this fabric uses `pinglabz-lab`. Copy the same spelling into the Manager settings and every device's system configuration. The organization name groups the fabric's members, like a company name on an access badge. Cisco's bring-up guide says the configured name is case-sensitive and must match across the devices. Do not change the spelling halfway through signing certificates. A fresh edge1 capture shows the plan in use: ``` edge1#show sdwan running-config system system system-ip 10.0.0.1 site-id 100 admin-tech-on-failure organization-name pinglabz-lab vbond 172.16.30.30 port 12346 ! ``` The command still says `vbond`. That is the old name for the Validator, not a different device. ## Record time and allowed traffic Certificate checks depend on the clock. Pick a reachable Network Time Protocol (NTP) source and check the time before you sign or install certificates. I have not tested a new NTP configuration in this batch. Plan for HTTPS to the Manager and for the control traffic between the devices. Cisco's bring-up guide documents the ports. The Validator uses UDP 12346, while the Manager and Controller can use additional per-core ports. Edge source ports can also change through port hopping. The fresh Controller capture shows edge1 on `12406` and edge2 on `12426`. A firewall rule for only UDP 12346 would not describe all the traffic in this lab. The [control-connections post](https://www.pinglabz.com/sd-wan-control-connections/) shows those ports on the wire. Before bootstrapping the first edge, check that every system IP is unique, each transport has a gateway, and the Validator address is reachable from both transports. Keep the management and service subnets in separate columns. That plan is what we use for the Manager next.