You want to practise onboarding and policies without borrowing a production network. What needs to run, and how small can you make it? My reference is Cisco Catalyst SD-WAN 20.18.2.1 with C8000v on IOS XE 17.18.02, built in my home lab.
This is part of the Cisco SD-WAN series. Before the build, read the SD-WAN components guide. Next: Plan a Cisco SD-WAN 20.18 lab: addresses, system IPs, sites, and organization.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
Choose the experiment before the platform
For routing practice, two ordinary routers can be enough. SD-WAN adds a management system, a trust system, and a separate routing control plane. You need those pieces before the first branch can exchange routes.
Think of the lab as a small company. SD-WAN Manager keeps the configuration records, the Validator checks who may enter, and the Controller distributes routing information. The WAN edges carry the traffic. The components guide explains each role.
My smallest useful topology has five SD-WAN devices:
- One Manager.
- One Validator and one Controller.
- Two C8000v edges, one at each site.
Put a host behind each edge if you want to prove that users can communicate. A second transport on each edge lets you practise path selection and failures. One transport is enough for an initial onboarding exercise.
One of each control component removes redundancy on purpose. Cisco's deployment recommendations use redundant Validators and Controllers. This is a practice topology, not an availability design.
Local software appliances
A local fabric gives you control over the whole sequence. You decide when certificates are signed, inspect the device list, and watch the edges form control connections. Those are useful experiments when you want to understand a failed join rather than follow a preconfigured exercise.
The cost is setup time and memory. You also need lawful access to the software and the right to use it. A working certificate exchange does not establish a software entitlement.
Cisco Modeling Labs (CML) is one local option if you already have access. Cisco's current SD-WAN reference-platform documentation says its supplemental distribution includes the Manager, Controller, Validator, and edges. Check the reference-platform version in your installation. Do not assume an old base distribution contains the same set.
That CML description comes from Cisco docs. I did not repeat this build in CML. These posts stay with the SD-WAN console and GUI, so the addressing and certificate checks are useful regardless of how you host the appliances.
Physical edges with local control components
If you already have suitable licensed routers, a mixed lab lets you practise cabling, console access, and transport failures on real ports. The control components still have to run somewhere.
Physical routers bring platform-specific onboarding and certificate behavior. The C8000v procedure in this series uses a generated software chassis identity and activation token. Do not apply that identity procedure to a hardware router with its own manufacturer identity.
I tested C8000v, not a physical branch router. Use Cisco's platform documentation for the hardware path.
Leave hosted labs out of this build
Hosted sandboxes and commercial courses can reduce setup work. They also choose some of the topology and access rules for you. I have not checked current reservations, prices, or provider availability, and this batch does not use a hosted service or sign up for one.
For this series, the useful comparison is whether you control the CA and the authorized device list. If an exercise gives you an already joined edge, it cannot demonstrate the exact bootstrap failure we fix later.
Budget for the Manager first
The Manager was the limiting component in my build. Early attempts with one to four virtual CPUs were unstable under setup load. The GUI returned 503 responses and sometimes redirected to Diagnostic Center.
My completed two-edge lab ran with eight virtual CPUs and 32 GB of RAM assigned to the Manager. That is an observation about a tiny lab. It is below Cisco's published 20.18 small-instance specification.
Cisco's 20.18 resource guide specifies 16 virtual CPUs, 32 GB of RAM, and 500 GB of storage for a small Manager. Use that specification when planning a supported deployment. Do not turn my eight-CPU result into a minimum requirement.
The same Cisco guide lists four CPUs and 8 GB for a small Controller, and two CPUs and 4 GB for a small Validator. Those are documented specifications, not a benchmark of every appliance in my lab. Add the edges and any test hosts to your resource budget.
Decide what counts as finished
A dashboard with five reachable devices is a useful checkpoint. It does not prove forwarding between sites.
My completed build had all of the following:
- An installed enterprise certificate on each device.
- Control connections from both edges to the Controller.
- An Overlay Management Protocol (OMP) peer on each edge.
- Two Bidirectional Forwarding Detection (BFD) sessions between the edges, one for each transport.
- A successful host-to-host ping in service VPN 10.
The saved lab capture contains five replies from the remote host. Fresh checks also show OMP up and both BFD sessions up. That gives the rest of the series a working starting point.
If your goal is only to inspect the Manager menus, you can stop sooner. If you want to break routing or test a policy, keep the two edges and test hosts. Write down the pass conditions before you start, so a green certificate row does not become your only test.