Comandos en la caja

Dos conjuntos de comandos separados llegan a un Customer Edge, y ninguno contiene al otro.

• En la caja, la CLI del Sitio tiene 6 comandos de nivel superior y 82 subcomandos execcli.
• A través de la red, la API de depuración tiene su propio catálogo de 34.

La mayor parte de la superficie en la caja no tiene equivalente en la API: todo el plano de control Vega, los wrappers de Envoy, la captura de paquetes, el conjunto de parámetros de kubelet, los archivos edit-* y el par de acceso root auxiliar solo son accesibles desde la caja.

Para acceder a ellos se necesita SSH o la consola serie, y algo que no está documentado en ningún lugar:

execcli es un comando oculto

execcli no aparece en el menú interactivo de la CLI del Sitio. Toma el nombre de un comando como argumento, y al escribir execcli seguido de Tab se listan los 82 con la descripción de una línea del propio dispositivo para cada uno. Ese menú de completado es el catálogo autoritativo para una compilación, y es lo que registra sitecli/exec-catalog.json.

Cómo se midió esto y cómo se superponen los conjuntos

El conjunto que aparece a continuación no fue transcrito de un documento del proveedor. Se leyó de nodos en producción con scripts/sitecli_ssh_harvest.py y se confirmó en sitecli/exec-catalog.json con su procedencia. Tres ejecuciones, en tres estados de registro:

Medido en	Nivel superior	execcli
site_state: PROVISIONING	6	82
site_state: PROVISIONED	6	82
site_state: ONLINE	6	82

Las tres devolvieron conjuntos idénticos — los mismos nombres, no solo los mismos totales, y la última fue un despliegue diferente con nombres de sitio y recursos distintos. Por lo tanto, la superficie de comandos no cambia con el estado de registro, y un comando que está ausente realmente está ausente en lugar de no estar disponible aún.

En comparación con los 34 de la API de depuración, esto da dos cifras que conviene tener claras:

• 51 subcomandos execcli no tienen equivalente en la API.
• 55 es la misma cifra contada sobre toda la superficie en la caja, porque también incluye los cuatro comandos configure*, que se encuentran en el nivel superior en lugar de bajo execcli.

Ambas son correctas; un lector que recalcule una y encuentre la otra no ha cometido un error. Todas las cifras aquí se derivan de sitecli/catalog.json y sitecli/exec-catalog.json.

Cinco comandos que no existen

factory-reset, upgrade, reboot, show y clear no están en esta compilación. Son el tipo de cosas que una CLI del Sitio plausiblemente tiene, estuvieron en la clasificación de este repositorio durante un tiempo bajo esa suposición, y ninguna enumeración los encontró. El nivel superior tiene exactamente seis entradas: configure, configure-generic-hardware, configure-network, configure-http-proxy, diagnosis y health.

Tres comandos de la API no son subcomandos execcli

Buscarlos bajo execcli no encuentra nada, lo que se interpreta como “el comando falta”:

• health y diagnosis son comandos de nivel superior de la CLI del Sitio. Escríbalos directamente en el prompt >>>, sin prefijo execcli.
• dig es accesible a través de la API de depuración y no aparece en ninguno de los menús en la caja, por lo que está ausente del listado de passthrough a continuación. Es exclusivo de la API.

Qué está documentado y qué solo se lista

Un Customer Edge ejecuta Linux y varios daemons de terceros. Documentar sus comandos duplicaría sus propias referencias e implicaría que F5 es propietario de ellos, por lo que la regla es: documentar el software de F5, y para todo lo demás documentar solo lo que es específico de un CE.

Tres niveles, porque “nuestro” y “de ellos” no es una división limpia. La división está registrada en sitecli/command-classification.json.

Nivel	Tratamiento
Software de F5	Documentación completa — propósito, sintaxis, argumentos, salida capturada, qué buscar. Argo, Vega, vpm, vifdump, configure*, el conjunto edit-*, parámetros de kubelet, acceso root.
Interpretación específica del CE	Una herramienta de terceros cuya salida tiene un significado particular en un CE. Se documenta la lectura específica del CE y la semántica propia de la herramienta se deja en el upstream.
Passthrough	Linux simple o de terceros sin nada específico del CE que mencionar. Se lista como disponible, con un puntero al upstream. Sin prosa.

Esa distinción decide si existe una página en absoluto, y es lo que evita que esta documentación se deteriore hasta convertirse en una copia peor de las páginas del manual.

Software de F5

Plano de control VegaSeis comandos vegactl: objetos de configuración, tablas de introspección, búferes de traza y qué nodo tiene el rol primario.

EnvoyCuatro wrappers alrededor de la interfaz de administración de Envoy — listeners, clusters y dos volcados de configuración.

Captura de paquetesLos cinco comandos vifdump. Documentados, nunca ejecutados aquí: escriben archivos de captura en el nodo.

Parámetros de kubeletLeer, agregar y eliminar parámetros personalizados de kubelet. Dirigido por Soporte.

Servicio vpmEl agente que registra el nodo y ejecuta los contenedores de la plataforma.

Archivos de configuraciónLos cuatro comandos edit-* que abren archivos propiedad de F5 en el nodo.

Acceso root auxiliarCreación y eliminación de la cuenta root xuser. Dirigido por Soporte, y deja el nodo modificado.

Configuración del nodoLos cuatro comandos configure* en el nivel superior de la CLI del Sitio.

Passthrough

Disponibles en la caja y no documentados aquí — estos son el sistema operativo y los daemons de terceros, no el software de F5, y sus propias referencias son mejores que cualquier cosa que esta página pudiera replicar.

Comandos	Upstream
ping, netstat, lsof, ip, ip-link-show, nmcli, tracepath	iproute2, NetworkManager
top, check-mem, sysctl, load-sysctl-conf, journalctl, files, rpm-ostree, chronyc-sources	coreutils, procps, systemd, rpm-ostree, chrony
edit-etc-hosts, edit-sysctl-conf	Los archivos son del sistema operativo
systemctl-status-crio, systemctl-status-docker, systemctl-status-kubelet, systemctl-status-iscsid, systemctl-status-multipathd	systemd
systemctl-restart-crio, systemctl-restart-docker, systemctl-restart-kubelet, systemctl-restart-iscsid, systemctl-restart-multipathd	systemd — cada uno de estos interrumpe las cargas de trabajo en el nodo

Dos de estos merecen conocerse aunque no tengan página propia. files realiza operaciones con archivos y solo escribirá en /tmp. Y cada systemctl-restart-* es disruptivo por definición — reiniciar crio o kubelet interrumpe las cargas de trabajo en ese nodo.

Siete comandos existen en compilaciones más recientes y no en esta

collect-database-stats, iptables-lv, los tres comandos marker-exists-*, systemctl-restart-NetworkManager y systemctl-start-crio-prune están ausentes aquí y presentes en la compilación 20260703-e2c462a, dando 89 comandos execcli allí frente a 82 aquí. Comandos en compilaciones más recientes los documenta. Están registrados bajo not_on_this_build.newer_build en la clasificación para que nada aquí se confunda con algo que se puede ejecutar en crt-20250613-3382.

collect-debug-info es un caso aparte: no aparece en ningún menú ni catálogo. El texto de bienvenida de la CLI del Sitio dice que la CLI “permite… recopilar información de depuración para soporte”, por lo que el nombre probablemente fue derivado de esa prosa en lugar de observado. Está marcado como no verificado y deliberadamente no se sondea — ejecutar especulativamente un comando desconocido en un nodo en producción es como se inició una captura de paquetes vifdump en un CE que todavía se estaba registrando.