Reaching a Customer Edge

Four access routes are available. The appropriate choice depends on the current state of the node, your network location, and the diagnostic depth required:

Route	Needs node ONLINE	Needs network reachability	Limits	Covers
Debug API	yes	yes	Requires ~25–30 minutes of convergence on a new site	43-command catalog
Site Console	no	via Azure Bastion, no jump host needed	Requires Azure Bastion Standard SKU with native client support (disabled by default)	F5 built-in node troubleshooting UI
SSH	no	from inside the VNet, to internal address only	Public key must be present at initial boot	Complete on-box Site CLI
Serial console	no	no	One concurrent session per VM; 2,048-character paste limit	Complete on-box Site CLI

Serial console serves as the break-glass mechanism and is the only path that functions when a node lacks working network connectivity.

The Site Console is typically the most convenient starting point. It requires no SSH key distribution, jump host, public IP, or VM modifications, relying instead on Azure Role-Based Access Control (RBAC). It provides F5’s built-in troubleshooting UI rather than a raw command shell. The primary prerequisite is Azure Bastion, which is opt-in via enable_bastion (default false) to avoid ongoing infrastructure costs.

SSH provides access when the debug API is insufficient, exposing the full range of on-box commands beyond the 43 exposed by the API. It has two operational constraints: the public key is injected via cloud-init and must be present at initial boot (adding keys to running nodes requires VM replacement), and sshd listens exclusively on the node’s internal address (requiring connectivity from within the VNet).

Why the split is not a preference

The debug API is served by the F5 Distributed Cloud control plane, which relays to the node over the tunnel vpm establishes during registration. No registration means no tunnel, which means the API has nothing to relay to.

It fails in an unhelpful way rather than an obvious one, so a node that never came up looks like an API problem.

Serial console goes the other way entirely — through the Azure platform to the node’s emulated serial port. It does not care whether the node has registered, has network reachability, or has a working data plane. That independence is the whole point, and it is why boot diagnostics has to stay enabled on the CE VMs.

What to reach for

If you are writing automation, or collecting evidence you want to re-run later, use the debug API. If registration is the thing that is broken, serial console is not a fallback — it is the only option.

Credentials

Each route uses different credentials, and none of them belongs on a command line.

• Debug API — an F5 Distributed Cloud API token, as XCSH_API_TOKEN, with the tenant URL as XCSH_API_URL. The xcsh context file at ~/.config/xcsh/contexts/<tenant>.json holds both, which is what scripts/capture-sitecli.sh reads when the environment does not supply them. This deployment’s tenant is f5-sales-demo; a token minted for another tenant returns a bare 401 that reads as an expired credential.
• Site Console — two credentials, at different layers. Your interactive Azure login opens the Bastion tunnel, and the appliance’s own admin account signs in to the console behind it over HTTP Basic. The Azure side is stated by Microsoft to need Reader on the VM, its NIC and the Bastion host; that requirement is not verified here, because every test ran as the subscription owner.
• SSH — the private half of the keypair whose public half the deployment wrote into /var/home/admin/.ssh/authorized_keys at first boot, plus a host inside the VNet to reach the internal address through. Connect as admin, not azureuser.
• Serial console — your interactive Azure login. There is no service principal for this: the F5 corporate Entra tenant does not permit provisioning one, which is also why no part of this runs in CI.

Never pass a token as an argument

A token on a command line lands in shell history and in the process list, where every other user on the machine can read it. capture-sitecli.sh refuses --token outright for that reason and supplies the header to curl on stdin instead.