The console answers, but the Manager web page keeps sending you to Diagnostic Center. Is it ready for certificate work? This procedure separates first boot from application readiness on Cisco Catalyst SD-WAN 20.18.2.1, paired with C8000v on IOS XE 17.18.02, built in my home lab.
This is part of the Cisco SD-WAN series. Previous: Plan a Cisco SD-WAN 20.18 lab: addresses, system IPs, sites, and organization. Next: Validator and Controller initial configuration on SD-WAN 20.18.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
Start with the right resources
SD-WAN Manager stores configuration and statistics as well as serving a graphical user interface (GUI). Think of it as a management application with a database, rather than a router with a web page attached.
Cisco's 20.18 resource guide lists a small Manager as 16 virtual CPUs, 32 GB RAM, and 500 GB storage. Follow the release-specific sizing and deployment instructions for your environment before first boot.
My two-edge lab became usable with eight CPUs and 32 GB. Earlier attempts with one to four CPUs returned intermittent 503 responses during setup. Eight CPUs is below Cisco's published specification. It worked here, but I would not use that result to size a supported installation.
This post starts at the Manager console. The deployment and storage-selection instructions below come from Cisco's bring-up guide. I did not reinstall or restart the working Manager to capture a second first boot.
Choose the standalone persona
Cisco's documentation shows this first-boot menu:
1) COMPUTE_AND_DATA
2) DATA
3) COMPUTE
Select persona for vManage (1, 2 or 3):For one standalone Manager, choose 1, Compute + Data. A persona is the set of services a node runs, like choosing all departments for a one-office company. The Compute-only and Data-only roles belong to a cluster.
Cisco says the persona cannot be changed afterward. Decide before you confirm.
The appliance also asks which storage device to use for its data. Formatting that device deletes its contents. On a fresh installation, identify the intended data device from your deployment plan before you approve formatting. Do not follow a device name copied from a different installation.
Older examples show 100 GB data disks. Use the current 20.18 resource specification for sizing, not that old example as a universal requirement.
Configure the Manager identity and transport
The lab's bootstrap script applied this configuration:
config
system host-name manager
system system-ip 1.1.1.1
system site-id 1000
system organization-name pinglabz-lab
system vbond 172.16.30.30
vpn 0 interface eth1 ip address 172.16.10.10/24
vpn 0 ip route 0.0.0.0/0 172.16.10.1
commit and-quitThis is a delta against the appliance's existing configuration. It is not a complete replacement for every default stanza. Check show running-config vpn 0 afterward. The transport interface must be enabled and have its tunnel-interface configuration.
The Manager uses 1.1.1.1 as its system identity and 172.16.10.10 as its transport address. The Validator setting points at the Validator's transport address, 172.16.30.30.
Use a separate management connection for browser and console access. In this lab, the access inventory reaches the Manager at 172.30.30.10. Cisco's documented out-of-band design uses VPN 512. Restrict management access to your administration network.
Complete the first login
Open the Manager's HTTPS address from that administration network. Use the initial credentials for your deployment, then change the password when prompted. Keep the replacement in your password manager. Nothing in this series requires putting it into a post or a shell history.
Our first-login automation changed the password before the settings requests. The saved screenshots include the login and the later dashboard, not an uninterrupted recording of the entire first-boot sequence.
Cisco documents a guided first-time configuration flow from 20.18.1. Follow the enterprise-certificate path for this series. Do not enter Smart Account credentials or start a PnP Connect sync for this local build.
Wait for application readiness
An open HTTPS port does not prove that the settings service is ready. During our build, the Manager redirected to /diagnostic/web/ before the application was healthy.
Our script checked GET /dataservice/client/server and required HTTP 200 three times, five seconds apart, before writes. The GUI became usable roughly 28 minutes after the completed deployment started. That is one observed startup time, not a timer to automate blindly.
If the page still redirects or returns 503, stop before certificate installation. Check the appliance health and resource allocation. Repeatedly submitting the same install request made the failure harder to recover from in our earlier attempt.
Set the fabric's shared values
After readiness, we set the organization to pinglabz-lab, the Validator to 172.16.30.30:12346, and the controller certificate authorization to enterprise signing. The CA setup follows in Enterprise Root CA.
One API detail from the successful build matters: the Manager's certificate signing request (CSR) used its system IP.
POST /dataservice/certificate/generate/csr
{"deviceIP":"1.1.1.1"}Using 172.16.10.10 in that request returned "Not able to find any device" in the build notes. The transport address and the API's device identity are different fields.
Verify from another device
After the remaining control components and certificates were configured, the Validator showed a Manager peer at 172.16.10.10, up on ports 12346 through 13046. That fresh read-only capture confirms the installed Manager participates in the fabric.
The saved dashboard also shows one Manager, one Validator, one Controller, and two reachable edges. Those are end-of-build checks. At this point in a new build, an empty edge list is expected. Get the Validator and Controller configured before trying to onboard a branch.