Reaching a Customer Edge

Four routes work, and which one applies is decided by the state of the node, by where you are connecting from, and by what you need to reach — rather than by preference.

Route	Needs node ONLINE	Needs network reachability	Limits	Covers
Debug API	yes	yes	about 25–30 minutes of warm-up on a new site	43-command catalog
Site Console	no	via Azure Bastion, no jump host needed	Bastion must be Standard SKU with tunneling, and is not deployed by default	F5’s node troubleshooting UI
SSH	no	from inside the VNet, to the internal address only	key must be present from first boot	The full on-box Site CLI
Serial console	no	no	one session per VM; 2,048-character paste cap	The full on-box Site CLI

Serial console is the last resort, and the only route that survives a node with no working network path.

The Site Console is usually the one to try first. It asks least of you — no SSH key to distribute, no jump host, no public IP on the node, and no VM replacement — because access becomes an Azure RBAC decision instead of a credential-distribution problem. It gives you F5’s own troubleshooting UI rather than the command surface, so reach past it when you need to run specific commands or script anything. Its one prerequisite is Azure Bastion, which this deployment makes opt-in (enable_bastion, default false) because a Standard-SKU host bills whether or not anyone opens a tunnel.

SSH is the one to reach for when the debug API is not enough, because the appliance offers substantially more commands than the 43 that API exposes. It has two costs. The key is written by cloud-init and so must be present at first boot, which means enabling it on running nodes replaces every CE VM — a fleet rebuild rather than a configuration change. And sshd answers on the node’s internal address only, so it needs a host inside the VNet; probing the address you know the node by will always report closed.

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.