mirror of
https://github.com/LibreQoE/LibreQoS.git
synced 2026-11-02 20:30:15 -06:00
changes
This commit is contained in:
Robert Chacon committed
1 parent
8c4642c2ca
commit
c7de842f66
27 files changed
+1414
-310
No files matched your search
@@ -13,6 +13,7 @@ Bienvenido a la documentación de LibreQoS
|
||||
v2.0/ubuntu-server-es
|
||||
v2.0/bridge-es
|
||||
v2.0/quickstart-es
|
||||
v2.0/git-install-es
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
@@ -21,6 +22,9 @@ Bienvenido a la documentación de LibreQoS
|
||||
v2.0/configuration-es
|
||||
v2.0/integrations-es
|
||||
v2.0/components-es
|
||||
v2.0/node-manager-ui-es
|
||||
v2.0/stormguard-es
|
||||
v2.0/scale-topology-es
|
||||
v2.0/update-es
|
||||
v2.0/troubleshooting-es
|
||||
|
||||
@@ -30,10 +34,12 @@ Bienvenido a la documentación de LibreQoS
|
||||
|
||||
v2.0/insight-es
|
||||
v2.0/api-es
|
||||
v2.0/lts-es
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: Misceláneo
|
||||
|
||||
v2.0/cake-es
|
||||
v2.0/performance-tuning-es
|
||||
v2.0/extras-es
|
||||
+122
-42
@@ -1,33 +1,65 @@
|
||||
# API del Nodo de LibreQoS
|
||||
|
||||
## Requisitos
|
||||
La API de nodo LibreQoS requiere una suscripción activa a LibreQoS Insight.
|
||||
|
||||
La API del nodo LibreQoS requiere una suscripción activa a LibreQoS Insight.
|
||||
|
||||
## Instalación
|
||||
|
||||
### Descarga
|
||||
### Si instaló vía `.deb` (recomendado)
|
||||
|
||||
```
|
||||
cd ~
|
||||
sudo apt-get update
|
||||
sudo apt-get upgrade
|
||||
wget https://libreqos.io/wp-content/uploads/2025/09/lqos_api.zip
|
||||
sudo apt-get install unzip
|
||||
sudo mkdir /opt/lqos_api/
|
||||
sudo chown -R $USER /opt/lqos_api/
|
||||
cd /opt/lqos_api/
|
||||
unzip lqos_api.zip
|
||||
```
|
||||
`lqos_api` se instala con LibreQoS en:
|
||||
|
||||
`/opt/libreqos/src/bin/lqos_api`
|
||||
|
||||
### Ejecución de prueba
|
||||
```
|
||||
cd /opt/lqos_api/
|
||||
./lqos_api
|
||||
|
||||
```bash
|
||||
/opt/libreqos/src/bin/lqos_api
|
||||
```
|
||||
|
||||
### Servicio systemd
|
||||
|
||||
Si la ejecución de prueba funciona correctamente, use `sudo nano /etc/systemd/system/lqos_api.service` y pegue el siguiente contenido:
|
||||
El paquete incluye un archivo de servicio de ejemplo:
|
||||
|
||||
```bash
|
||||
sudo cp /opt/libreqos/src/bin/lqos_api.service.example /etc/systemd/system/lqos_api.service
|
||||
```
|
||||
|
||||
Luego ejecute:
|
||||
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable lqos_api
|
||||
sudo systemctl start lqos_api
|
||||
```
|
||||
|
||||
### Actualizar solo el binario de la API
|
||||
|
||||
Use el script de ayuda:
|
||||
|
||||
```bash
|
||||
cd /opt/libreqos/src
|
||||
./update_api.sh
|
||||
```
|
||||
|
||||
Esto descarga el `lqos_api` más reciente e instala en `/opt/libreqos/src/bin/lqos_api`.
|
||||
|
||||
Puede omitir el reinicio del servicio:
|
||||
|
||||
```bash
|
||||
./update_api.sh --no-restart
|
||||
```
|
||||
|
||||
O instalar en otra ruta:
|
||||
|
||||
```bash
|
||||
./update_api.sh --bin-dir /alguna/ruta/bin --no-restart
|
||||
```
|
||||
|
||||
### Archivo de servicio manual (si es necesario)
|
||||
|
||||
Si crea el servicio manualmente, use:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
@@ -35,15 +67,17 @@ After=network.service lqosd.service
|
||||
Requires=lqosd.service
|
||||
|
||||
[Service]
|
||||
WorkingDirectory=/opt/lqos_api/
|
||||
ExecStart=/opt/lqos_api/lqos_api
|
||||
WorkingDirectory=/opt/libreqos/src/bin
|
||||
ExecStart=/opt/libreqos/src/bin/lqos_api
|
||||
Restart=always
|
||||
|
||||
[Install]
|
||||
WantedBy=default.target
|
||||
```
|
||||
|
||||
Luego ejecute:
|
||||
```
|
||||
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable lqos_api
|
||||
sudo systemctl start lqos_api
|
||||
@@ -51,42 +85,66 @@ sudo systemctl start lqos_api
|
||||
|
||||
## Uso
|
||||
|
||||
Vea `localhost:9122/api-docs` para la interfaz de Swagger UI.
|
||||
Vea `localhost:9122/api-docs` para la interfaz Swagger.
|
||||
|
||||
`/api-docs` es la fuente de verdad para su versión instalada. La disponibilidad de endpoints puede cambiar entre versiones.
|
||||
|
||||
## Guía de despliegue y hardening
|
||||
|
||||
Postura recomendada para producción:
|
||||
|
||||
1. Mantenga la API accesible solo desde redes de gestión confiables.
|
||||
2. No exponga la API directamente a Internet público.
|
||||
3. Si requiere acceso remoto, publíquela detrás de un reverse proxy con TLS y autenticación.
|
||||
4. Restrinja acceso entrante con allowlists de firewall (host/red).
|
||||
5. Monitoree logs de API/servicio para detectar accesos anómalos.
|
||||
|
||||
Si la API no se necesita en un nodo, deshabilite el servicio:
|
||||
|
||||
```bash
|
||||
sudo systemctl disable --now lqos_api
|
||||
```
|
||||
|
||||
Si está habilitada, verifique el estado tras actualizaciones:
|
||||
|
||||
```bash
|
||||
sudo systemctl status lqos_api
|
||||
```
|
||||
|
||||
## Endpoints de la API
|
||||
|
||||
### Salud y sistema
|
||||
- `/health` - Comprobación de salud del servicio
|
||||
- `/reload_libreqos` - Recargar la configuración de LibreQoS
|
||||
- `/validate_shaped_devices` - Validar el CSV de dispositivos modelados
|
||||
- `/lqos_stats` - Obtener estadísticas internas de lqosd
|
||||
- `/stormguard_stats` - Obtener estadísticas de Stormguard
|
||||
- `/bakery_stats` - Obtener el recuento de circuitos activos de Bakery
|
||||
- `/health` - Verificación de salud del servicio
|
||||
- `/reload_libreqos` - Recarga configuración de LibreQoS
|
||||
- `/validate_shaped_devices` - Valida CSV de Shaped Devices
|
||||
- `/lqos_stats` - Estadísticas internas de lqosd
|
||||
- `/stormguard_stats` - Estadísticas de StormGuard
|
||||
- `/bakery_stats` - Conteo de circuitos activos de Bakery
|
||||
|
||||
### Métricas de tráfico
|
||||
- `/current_throughput` - Estadísticas actuales de rendimiento de la red
|
||||
- `/top_n_downloaders/{start}/{end}` - Descargadores principales por tráfico
|
||||
- `/worst_rtt/{start}/{end}` - Hosts con peor tiempo de ida y vuelta (RTT)
|
||||
- `/current_throughput` - Throughput actual de red
|
||||
- `/top_n_downloaders/{start}/{end}` - Top descargadores por tráfico
|
||||
- `/worst_rtt/{start}/{end}` - Hosts con peor RTT
|
||||
- `/worst_retransmits/{start}/{end}` - Hosts con más retransmisiones TCP
|
||||
- `/best_rtt/{start}/{end}` - Hosts con mejor tiempo de ida y vuelta (RTT)
|
||||
- `/host_counter` - Todos los contadores de tráfico por host
|
||||
- `/best_rtt/{start}/{end}` - Hosts con mejor RTT
|
||||
- `/host_counter` - Contadores de tráfico por host
|
||||
|
||||
### Topología de red
|
||||
- `/network_map/{parent}` - Mapa de red desde el nodo padre
|
||||
- `/full_network_map` - Topología de red completa
|
||||
- `/top_map_queues/{n}` - Las N colas principales por tráfico
|
||||
- `/node_names` - Obtener nombres de nodos a partir de IDs
|
||||
- `/funnel/{target}` - Analizar el embudo de tráfico hacia el circuito
|
||||
- `/network_map/{parent}` - Mapa de red desde nodo padre
|
||||
- `/full_network_map` - Topología completa
|
||||
- `/top_map_queues/{n}` - Top N colas por tráfico
|
||||
- `/node_names` - Nombres de nodos por ID
|
||||
- `/funnel/{target}` - Análisis de embudo hacia circuito
|
||||
|
||||
### Gestión de circuitos
|
||||
- `/all_circuits` - Listar todos los circuitos
|
||||
- `/raw_queue_data/{circuit_id}` - Datos en bruto de colas para el circuito
|
||||
- `/all_circuits` - Lista de todos los circuitos
|
||||
- `/raw_queue_data/{circuit_id}` - Datos de cola en bruto por circuito
|
||||
|
||||
### Análisis de flujos
|
||||
- `/dump_active_flows` - Volcar todos los flujos activos (lento)
|
||||
- `/dump_active_flows` - Volcado de flujos activos (lento)
|
||||
- `/count_active_flows` - Conteo de flujos activos
|
||||
- `/top_flows/{flow_type}/{n}` - Flujos principales por tipo de métrica
|
||||
- `/flows_by_ip/{ip}` - Flujos para una IP específica
|
||||
- `/top_flows/{flow_type}/{n}` - Top flujos por tipo de métrica
|
||||
- `/flows_by_ip/{ip}` - Flujos por IP específica
|
||||
- `/flow_duration` - Estadísticas de duración de flujos
|
||||
|
||||
### Geo y protocolos
|
||||
@@ -94,3 +152,25 @@ Vea `localhost:9122/api-docs` para la interfaz de Swagger UI.
|
||||
- `/current_endpoint_latlon` - Coordenadas geográficas de endpoints
|
||||
- `/ether_protocol_summary` - Resumen de protocolos Ethernet
|
||||
- `/ip_protocol_summary` - Resumen de protocolos IP
|
||||
|
||||
## Cobertura de API en versiones recientes
|
||||
|
||||
Compilaciones recientes ampliaron cobertura en algunas áreas. Dependiendo de su versión, la API también puede incluir:
|
||||
|
||||
- Resúmenes de alertas y warnings
|
||||
- Resúmenes de conteo de dispositivos y circuitos
|
||||
- Consulta de detalle para circuito individual
|
||||
- Helpers de búsqueda para flujos de UI
|
||||
- Endpoints de detalle de scheduler y estadísticas de colas
|
||||
|
||||
Use `localhost:9122/api-docs` para confirmar rutas y esquemas exactos en su nodo.
|
||||
|
||||
## Capturar inventario de endpoints por release
|
||||
|
||||
Para notas de release o runbooks internos, capture un snapshot de rutas API desde el nodo:
|
||||
|
||||
```bash
|
||||
curl -s http://localhost:9122/api-docs | jq -r '.paths | keys[]' | sort
|
||||
```
|
||||
|
||||
Guarde esta salida junto con artefactos del release para comparar diferencias entre versiones.
|
||||
@@ -1,72 +1,80 @@
|
||||
# Componentes de Software de LibreQoS
|
||||
# Componentes de software de LibreQoS
|
||||
|
||||
## Servicios systemd
|
||||
|
||||
## Servicios de Systemd
|
||||
### lqosd
|
||||
|
||||
- Administra el código XDP actual.
|
||||
- Desarrollado en Rust.
|
||||
- Ejecuta la interfaz gráfica (GUI) disponible en http://a.b.c.d:9123
|
||||
- Administra la lógica de shaping/XDP.
|
||||
- Implementado en Rust.
|
||||
- Ejecuta la UI local disponible en `http://a.b.c.d:9123`.
|
||||
- Hospeda páginas de Node Manager como:
|
||||
- Mapa de flujos
|
||||
- Árbol de red
|
||||
- Explorador ASN
|
||||
- Árbol/Pesos de CPU
|
||||
- Editores de configuración para integraciones (UISP, Splynx, Netzur, VISP, etc.)
|
||||
|
||||
### lqos_scheduler
|
||||
|
||||
- lqos_scheduler realiza actualizaciones continuas de los reguladores de tráfico (shapers) de LibreQoS, incluyendo la obtención de datos desde cualquier integración CRM habilitada (UISP, Splynx, Netzur).
|
||||
- Acciones realizadas:
|
||||
- Al iniciar: realiza una configuración completa de las colas.
|
||||
- Cada X minutos: actualiza las colas, obteniendo nueva configuración desde la integración CRM si está habilitada.
|
||||
- El intervalo por defecto es de 30 minutos, por lo que la actualización ocurre cada 30 minutos.
|
||||
- El intervalo de minutos puede ajustarse mediante el parámetro `queue_refresh_interval_mins` ubicado en `/etc/lqos.conf`.
|
||||
- Realiza refrescos continuos de shaping, incluyendo lectura de integraciones CRM habilitadas.
|
||||
- Acciones:
|
||||
- Al iniciar: ejecución de setup completo de colas.
|
||||
- Cada X minutos: actualización de colas y datos de integración.
|
||||
- El intervalo por defecto es 30 minutos (`queue_refresh_interval_mins` en `/etc/lqos.conf`).
|
||||
|
||||
### Verificar el estado de los servicios
|
||||
### Verificación de estado
|
||||
|
||||
```
|
||||
```bash
|
||||
sudo systemctl status lqosd lqos_scheduler
|
||||
```
|
||||
Si el estado de alguno de los dos servicios aparece como 'failed', debe examinarse la causa utilizando journalctl, el cual muestra el historial completo del servicio. Por ejemplo, si lqosd ha fallado, ejecute:
|
||||
```
|
||||
sudo journalctl -u lqosd -b
|
||||
```
|
||||
Presione la tecla End en su teclado para ir al final del registro y ver las actualizaciones más recientes.
|
||||
|
||||
Lqosd indicará las razones específicas por las cuales falló, como una interfaz que no está activa, falta de soporte para múltiples filas en la interfaz, entre otros problemas.
|
||||
Si algún servicio aparece como `failed`, revise logs:
|
||||
|
||||
```bash
|
||||
sudo journalctl -u lqosd -b
|
||||
sudo journalctl -u lqos_scheduler -b
|
||||
```
|
||||
|
||||
### Depuración de lqos_scheduler
|
||||
|
||||
En segundo plano, lqos_scheduler ejecuta el script de Python scheduler.py, el cual a su vez ejecuta el script de Python LibreQoS.py
|
||||
`lqos_scheduler` ejecuta `scheduler.py`, que a su vez invoca `LibreQoS.py`.
|
||||
|
||||
- scheduler.py: realiza actualizaciones continuas de los reguladores de tráfico (shapers) de LibreQoS, incluyendo la obtención de datos desde cualquier integración CRM habilitada (UISP, Splynx, Netzur).
|
||||
- LibreQoS.py: se encarga de crear y actualizar las filas y el regulamiento de tráfico de los dispositivos.
|
||||
Flujo de depuración recomendado:
|
||||
|
||||
Ejecuciones puntuales de estos componentes individuales pueden ser de gran ayuda para depurar y asegurar que todo esté correctamente configurado.
|
||||
|
||||
Primero, detenga el servicio lqos_scheduler:
|
||||
|
||||
```shell
|
||||
```bash
|
||||
sudo systemctl stop lqos_scheduler
|
||||
```
|
||||
|
||||
Para realizar una ejecución única de LibreQoS.py, utilice:
|
||||
|
||||
```shell
|
||||
sudo ./LibreQoS.py
|
||||
```
|
||||
|
||||
- Para ejecutar en modo depuración con respuestas mas detalladas, use:
|
||||
|
||||
```shell
|
||||
cd /opt/libreqos/src
|
||||
sudo ./LibreQoS.py --debug
|
||||
```
|
||||
|
||||
Para confirmar que lqos_scheduler (scheduler.py) funciona correctamente, ejecute:
|
||||
|
||||
```shell
|
||||
sudo python3 scheduler.py
|
||||
```
|
||||
|
||||
Una vez que se hayan corregido los errores, reinicie el servicio lqos_scheduler con:
|
||||
|
||||
```shell
|
||||
sudo systemctl start lqos_scheduler
|
||||
```
|
||||
|
||||
### Solución de problemas de los servicios
|
||||
Consulta la sección de [Solución de Problemas](troubleshooting-es.md).
|
||||
## Modo privacidad en Node Manager
|
||||
|
||||
Node Manager incluye redacción del lado cliente para demos/capturas:
|
||||
|
||||
- Se activa con el ícono de máscara en la barra superior.
|
||||
- La preferencia se guarda en `localStorage`.
|
||||
- Oculta datos visibles en la UI; no modifica archivos fuente.
|
||||
|
||||
## Canal de problemas urgentes
|
||||
|
||||
Node Manager incluye un canal de problemas urgentes para eventos de alta prioridad (por ejemplo, límite de circuitos mapeados).
|
||||
|
||||
- Los eventos aparecen en el indicador de navegación superior.
|
||||
- Pueden revisarse y reconocerse desde el modal de problemas urgentes.
|
||||
- Úselo como señal rápida; confirme detalle con `journalctl -u lqosd`.
|
||||
|
||||
## Indicador de estado del scheduler
|
||||
|
||||
Node Manager incluye visibilidad del estado del scheduler.
|
||||
|
||||
- Úselo como señal rápida de salud para jobs periódicos.
|
||||
- Si el scheduler no está saludable, valide primero estado de `lqosd` y `lqos_scheduler`.
|
||||
- Revise detalle con:
|
||||
- `journalctl -u lqos_scheduler --since "30 minutes ago"`
|
||||
- `journalctl -u lqosd --since "30 minutes ago"`
|
||||
|
||||
## Solución de problemas de componentes
|
||||
|
||||
Consulte [Solución de Problemas](troubleshooting-es.md).
|
||||
@@ -3,6 +3,37 @@
|
||||
## Acerca de Insight
|
||||
Conoce más sobre Insight en nuestro sitio web, [aquí](https://libreqos.io/insight/).
|
||||
|
||||
## Comportamiento de licenciamiento de Insight (lado nodo)
|
||||
|
||||
### Material de claves local y grants offline
|
||||
|
||||
LibreQoS guarda material de claves de Insight en:
|
||||
|
||||
`<lqos_directory>/.keys/`
|
||||
|
||||
Las compilaciones actuales pueden cachear grants firmados localmente para que el nodo siga operando durante pérdidas temporales de conectividad con servicios de control de Insight. La validez y expiración del grant se aplica localmente.
|
||||
|
||||
Notas operativas:
|
||||
|
||||
- Mantenga `.keys/` persistente entre reinicios.
|
||||
- Trate `.keys/` como material sensible.
|
||||
- Si hay estado inválido de grant/clave, `lqosd` mostrará errores de licencia/grant en logs.
|
||||
|
||||
### Límites de circuitos mapeados y estado de licencia
|
||||
|
||||
Compilaciones recientes aplican límites de circuitos mapeados según estado de licencia.
|
||||
|
||||
Si su nodo está sin licencia/válido, LibreQoS puede aplicar un límite predeterminado de circuitos mapeados. Cuando se excede, los logs incluyen mensajes como:
|
||||
|
||||
- `Mapped circuit limit reached`
|
||||
- `Bakery mapped circuit cap enforced`
|
||||
|
||||
Cuando ocurra:
|
||||
|
||||
1. Revise estado de licencia Insight en la UI.
|
||||
2. Revise `journalctl -u lqosd` para conteos requested/allowed/dropped.
|
||||
3. Verifique si la cantidad de circuitos mapeados excede su licencia.
|
||||
|
||||
## Interfaz de Insight
|
||||
|
||||
### Barra de tareas
|
||||
|
||||
@@ -6,6 +6,7 @@
|
||||
+ [Acceso API de Splynx](#acceso-api-de-splynx)
|
||||
+ [Sobrescrituras de Splynx](#sobrescrituras-de-splynx)
|
||||
* [Integración con Netzur](#integración-con-netzur)
|
||||
* [Integración con VISP](#integración-con-visp)
|
||||
* [Integración con UISP](#integración-con-uisp)
|
||||
+ [Estrategias de Topología](#estrategias-de-topología-1)
|
||||
+ [Estrategias de Manejo de Suspensiones](#estrategias-de-manejo-de-suspensiones)
|
||||
@@ -153,6 +154,46 @@ python3 integrationNetzur.py
|
||||
|
||||
La integración actualiza `ShapedDevices.csv` y, salvo que `always_overwrite_network_json` esté deshabilitado, también `network.json`. Ajuste la opción Integración → Común si necesita preservar un `network.json` existente entre ejecuciones de Netzur.
|
||||
|
||||
## Integración con VISP
|
||||
|
||||
Primero, configure los parámetros relevantes de VISP en `/etc/lqos.conf`:
|
||||
|
||||
```ini
|
||||
[visp_integration]
|
||||
enable_visp = true
|
||||
client_id = "su-client-id"
|
||||
client_secret = "su-client-secret"
|
||||
username = "usuario-app"
|
||||
password = "password-app"
|
||||
# Opcional: si se deja vacío, se usa el primer ISP ID del token
|
||||
# isp_id = 0
|
||||
timeout_secs = 20
|
||||
# Opcional: dominio para enriquecimiento de sesiones online
|
||||
# online_users_domain = ""
|
||||
```
|
||||
|
||||
Notas:
|
||||
|
||||
- La importación VISP usa GraphQL y actualmente trabaja en estrategia `flat`.
|
||||
- La integración reescribe `ShapedDevices.csv` en cada ejecución.
|
||||
- `network.json` solo se sobrescribe cuando `always_overwrite_network_json = true` (en `[integration_common]`).
|
||||
- Los tokens de VISP se cachean en `<lqos_directory>/.visp_token_cache_*.json`.
|
||||
|
||||
Importación manual:
|
||||
|
||||
```bash
|
||||
python3 integrationVISP.py
|
||||
```
|
||||
|
||||
Para ejecución automática con scheduler:
|
||||
|
||||
- `[visp_integration] enable_visp = true`
|
||||
- reinicie scheduler:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart lqos_scheduler
|
||||
```
|
||||
|
||||
## Integración con UISP
|
||||
|
||||
Primero, configure los parámetros relevantes de UISP en `/etc/lqos.conf`.
|
||||
@@ -246,8 +287,32 @@ commit_bandwidth_multiplier = 0.98 # Establecer mínimo al 98% del máximo (CIR
|
||||
ipv6_with_mikrotik = false # Habilitar si usa DHCPv6 con MikroTik
|
||||
always_overwrite_network_json = false # Establecer true para reconstruir topología en cada ejecución
|
||||
exception_cpes = [] # Excepciones de CPE en formato ["cpe:parent"]
|
||||
squash_sites = [] # Opcional: sitios a compactar (flujo legacy de full)
|
||||
enable_squashing = false # Opcional: habilita lógica adicional de compactación
|
||||
do_not_squash_sites = [] # Opcional: sitios excluidos de compactación
|
||||
ignore_calculated_capacity = false # Opcional: prioriza capacidad configurada sobre la calculada
|
||||
insecure_ssl = false # Opcional: ignora validación TLS del API UISP
|
||||
```
|
||||
|
||||
### Opciones avanzadas/operativas de UISP
|
||||
|
||||
Las compilaciones actuales también incluyen estas opciones en los editores de configuración de Node Manager:
|
||||
|
||||
- `exclude_sites`: lista de sitios a excluir de la importación.
|
||||
- `exception_cpes`: sobrescrituras `cpe:parent` para asignación ambigua.
|
||||
- `squash_sites`: lista opcional de sitios a compactar en flujos `full`.
|
||||
- `enable_squashing`: habilita compactación adicional donde aplique.
|
||||
- `do_not_squash_sites`: exclusiones explícitas de compactación.
|
||||
- `use_ptmp_as_parent`: prioriza AP PtMP como padre en rutas relevantes.
|
||||
- `ignore_calculated_capacity`: usa capacidades configuradas en lugar de calculadas.
|
||||
- `insecure_ssl`: deshabilita validación de certificados TLS para UISP.
|
||||
|
||||
Uso recomendado:
|
||||
|
||||
1. Mantenga `insecure_ssl = false` salvo necesidad interna clara (PKI/self-signed).
|
||||
2. Use primero `exclude_sites` y `do_not_squash_sites` para cambios más seguros.
|
||||
3. Aplique `squash_sites`/`enable_squashing` de forma incremental y valide colocación de colas tras cada cambio.
|
||||
|
||||
Para probar la integración con UISP, ejecute:
|
||||
|
||||
```shell
|
||||
|
||||
+12
-32
@@ -1,38 +1,18 @@
|
||||
# LibreQoS Long-Term Stats (LTS)
|
||||
# Nomenclatura LTS heredada (deprecado)
|
||||
|
||||
## Acerca de LTS
|
||||
Obtén más información sobre LTS en nuestro sitio web, [aquí](https://libreqos.io/lts/).
|
||||
|
||||
## Registro
|
||||
Encuentre su ID de Nodo LibreQoS iniciando sesión en su equipo donde se encuentre LibreQoS por SSH y ejecutando:
|
||||
```{warning}
|
||||
LTS está deprecado y fue reemplazado por LibreQoS Insight.
|
||||
Para despliegues actuales y nuevas suscripciones, use la documentación de Insight:
|
||||
[Insight](insight-es.md)
|
||||
```
|
||||
sed -n 's/node_id = //p' /etc/lqos.conf | sed -e 's/^"//' -e 's/"$//'`
|
||||
```
|
||||
El resultado será un número largo: el identificador único de su caja LibreQoS.
|
||||
|
||||
Ahora visite:
|
||||
```
|
||||
https://stats.libreqos.io/trial1/YOUR_NODE_ID
|
||||
```
|
||||
Donde YOUR_NODE_ID es el ID de Nodo que encontró en el paso anterior.
|
||||
## Nota de migración
|
||||
|
||||
Si es la primera vez que usa LTS, seleccione "Sign Up - Regular Long-Term Stats".
|
||||
Si tiene referencias heredadas a LTS en runbooks/documentación interna:
|
||||
|
||||
Complete el registro para la prueba gratuita de 30 días ingresando su información de pago.
|
||||
- Reemplácelas por referencias a Insight.
|
||||
- Use [insight-es.md](insight-es.md) para comportamiento y flujos actuales.
|
||||
- Use [api-es.md](api-es.md) para detalles de API de nodo (`/api-docs` en su nodo es la fuente de verdad).
|
||||
- En algunas rutas UI/código todavía aparecen nombres históricos como `lts_trial` o `config_lts`; en versiones actuales se refieren a flujos de Insight.
|
||||
|
||||
El proceso de registro le proporcionará una Clave de Licencia LTS.
|
||||
|
||||
Regrese a la caja de LibreQoS y edite el archivo `/etc/lqos.conf` para modificar la sección [long_term_stats] de la siguiente manera:
|
||||
```
|
||||
[long_term_stats]
|
||||
gather_stats = true
|
||||
collation_period_seconds = 60
|
||||
license_key = "YOUR_LICENSE_KEY"
|
||||
uisp_reporting_interval_seconds = 300
|
||||
```
|
||||
Donde YOUR_LICENSE_KEY es su clave única de licencia LTS obtenida en el paso anterior. Asegúrese de incluir las comillas.
|
||||
|
||||
Ahora guarde el archivo y ejecute: `sudo systemctl restart lqosd lqos_scheduler`. Esto reiniciará el proceso lqosd, permitiéndole comenzar a enviar datos a LTS.
|
||||
|
||||
## Acceso a LTS
|
||||
Para acceder a LTS, visite [https://stats.libreqos.io/](https://stats.libreqos.io/) - e ingrese su clave LTS, usuario (correo electrónico) y contraseña.
|
||||
Las instrucciones heredadas de onboarding de LTS se removieron para evitar confusión en despliegues nuevos.
|
||||
@@ -0,0 +1,76 @@
|
||||
# Interfaz Node Manager de LibreQoS
|
||||
|
||||
Esta página documenta las vistas clave del Node Manager y su comportamiento operativo en la interfaz local (`http://ip_del_shaper:9123`).
|
||||
|
||||
## Vistas principales
|
||||
|
||||
### Dashboard
|
||||
- Resumen por widgets de throughput, retransmisiones, RTT, flujos y actividad de colas.
|
||||
- El contenido puede variar según versión y funciones habilitadas.
|
||||
|
||||
### Vista de árbol de red
|
||||
- Vista jerárquica de nodos/circuitos desde la perspectiva del shaper.
|
||||
- Útil para identificar cuellos de botella y patrones de utilización padre/hijo.
|
||||
|
||||
### Mapa de flujos
|
||||
- Visualización geográfica de flujos según geolocalización de endpoints.
|
||||
- Requiere volumen de datos reciente suficiente.
|
||||
|
||||
### Explorador ASN
|
||||
- Exploración por ASN (volumen, RTT/retransmisiones y detalle de flujos asociados).
|
||||
- Resultados vacíos suelen indicar poco dato reciente, no necesariamente falla.
|
||||
|
||||
### Árbol/ponderación de CPU
|
||||
- Muestra distribución de colas/circuitos por núcleo de CPU.
|
||||
- Ayuda a validar comportamiento de binpacking y balance de carga.
|
||||
|
||||
### Editor de Shaped Devices
|
||||
- Editor CRUD para `ShapedDevices.csv`.
|
||||
- Incluye paginación y filtros en versiones actuales.
|
||||
|
||||
### Problemas urgentes
|
||||
- Node Manager puede mostrar problemas operativos urgentes emitidos por servicios backend.
|
||||
- Ejemplos: advertencias de límites de mapeo/licencia y errores de alta prioridad.
|
||||
- Operadores pueden reconocer/limpiar eventos desde la UI.
|
||||
- Códigos comunes: `MAPPED_CIRCUIT_LIMIT` y `TC_U16_OVERFLOW` (ver [Solución de Problemas](troubleshooting-es.md#códigos-de-problemas-urgentes-y-primeras-acciones)).
|
||||
|
||||
### Estado del scheduler
|
||||
- Node Manager muestra salud/disponibilidad del scheduler.
|
||||
- Úselo para validar refrescos periódicos después de cambios de configuración/integración.
|
||||
- Si hay errores, correlacione con:
|
||||
- `journalctl -u lqos_scheduler --since "30 minutes ago"`
|
||||
- `journalctl -u lqosd --since "30 minutes ago"`
|
||||
|
||||
## Modo privacidad / redacción
|
||||
|
||||
- Se activa con el ícono de máscara en la barra superior.
|
||||
- Es redacción del lado cliente y se guarda en `localStorage` del navegador.
|
||||
- Ayuda a ocultar PII en capturas/demos.
|
||||
- No modifica `ShapedDevices.csv`, `network.json` ni datos backend.
|
||||
|
||||
## Comportamiento de vistas vacías
|
||||
|
||||
Las siguientes vistas pueden verse vacías cuando hay poco dato:
|
||||
- Mapa de flujos
|
||||
- Sankey del árbol de red
|
||||
- Explorador ASN
|
||||
|
||||
Si ocurre:
|
||||
1. Confirme que `lqosd` está saludable.
|
||||
2. Espere a que se acumule tráfico/dato reciente.
|
||||
3. Recargue la página.
|
||||
4. Revise logs:
|
||||
|
||||
```bash
|
||||
journalctl -u lqosd --since "10 minutes ago"
|
||||
```
|
||||
|
||||
## Nota de nomenclatura heredada
|
||||
|
||||
Algunos identificadores internos todavía usan nombres históricos `lts_*`. Operativamente, en versiones actuales se refieren a flujos de Insight.
|
||||
|
||||
## Páginas relacionadas
|
||||
|
||||
- [Componentes](components-es.md)
|
||||
- [Configuración](configuration-es.md)
|
||||
- [Solución de Problemas](troubleshooting-es.md)
|
||||
@@ -1,28 +1,71 @@
|
||||
# Ajuste de Rendimiento
|
||||
# Ajuste de rendimiento
|
||||
|
||||
## Ubuntu inicia lentamente (~2 minutos)
|
||||
## Base de CPU e IRQ
|
||||
|
||||
### Listar todos los servicios que dependen de la red
|
||||
Configure el governor de CPU en modo rendimiento para bare metal/hipervisor:
|
||||
|
||||
```shell
|
||||
```bash
|
||||
sudo cpupower frequency-set --governor performance
|
||||
```
|
||||
|
||||
Confirme que el conteo de colas NIC y la distribución por CPU sean razonables:
|
||||
|
||||
```bash
|
||||
ethtool -l <interfaz>
|
||||
grep -E 'CPU\\(|IRQ' /proc/interrupts | head -n 50
|
||||
```
|
||||
|
||||
Si un solo núcleo/cola está saturado y los demás están ociosos, rebalancee afinidad IRQ/colas y revise la configuración de colas en `/etc/lqos.conf`.
|
||||
|
||||
## Presión por topología/colas
|
||||
|
||||
Cuando modele jerarquías grandes:
|
||||
|
||||
- Prefiera estrategias de menor profundidad (`ap_only`/`ap_site`) salvo que necesite jerarquía completa.
|
||||
- Use `promote_to_root` en topologías multi-sitio para evitar cuellos de botella de un solo núcleo.
|
||||
- Valide CPU Tree/CPU Weights en Node Manager después de cambios topológicos importantes.
|
||||
|
||||
Consulte también [Escalado y diseño de topología](scale-topology-es.md).
|
||||
|
||||
## Frecuencia del scheduler y carga
|
||||
|
||||
La cadencia de `lqos_scheduler` afecta carga del plano de control y velocidad de cambios.
|
||||
|
||||
- Comience con `queue_refresh_interval_mins` conservador.
|
||||
- Reduzca intervalo solo si su integración/API y host soportan ese churn.
|
||||
- Tras cambiar intervalo, monitoree:
|
||||
- `journalctl -u lqos_scheduler --since "30 minutes ago"`
|
||||
- estado del scheduler en Node Manager
|
||||
|
||||
## Despliegue de StormGuard
|
||||
|
||||
Si usa StormGuard:
|
||||
|
||||
1. Inicie con `dry_run = true`.
|
||||
2. Observe al menos un periodo de alto tráfico.
|
||||
3. Pase a modo activo solo tras revisar estado/depuración.
|
||||
|
||||
Vea [StormGuard](stormguard-es.md).
|
||||
|
||||
## Arranque lento / dependencias de red
|
||||
|
||||
Si Ubuntu arranca lento por dependencias de `network-online`, inspeccione:
|
||||
|
||||
```bash
|
||||
systemctl show -p WantedBy network-online.target
|
||||
```
|
||||
|
||||
### En Ubuntu 22.04 este comando puede ayudar
|
||||
En algunos entornos Ubuntu, deshabilitar servicios no usados de cloud/iSCSI puede ayudar:
|
||||
|
||||
```shell
|
||||
systemctl disable cloud-config iscsid cloud-final
|
||||
```bash
|
||||
sudo systemctl disable cloud-config iscsid cloud-final
|
||||
```
|
||||
|
||||
### Establecer el governor correcto para la CPU (baremetal/hipervisor)
|
||||
Valide esta acción contra su entorno antes de aplicarla.
|
||||
|
||||
```shell
|
||||
cpupower frequency-set --governor performance
|
||||
```
|
||||
## Convergencia de ruteo (OSPF)
|
||||
|
||||
### OSPF
|
||||
Para despliegues enrutados, ajuste timers OSPF entre core y edge para reducir ventanas de indisponibilidad en reinicios:
|
||||
|
||||
Se recomienda ajustar los temporizadores OSPF de ambos vecinos (core y edge router) para minimizar el tiempo de inactividad cuando el servidor LibreQoS se reinicie.
|
||||
|
||||
* hello interval
|
||||
* dead interval
|
||||
- hello interval
|
||||
- dead interval
|
||||
@@ -0,0 +1,73 @@
|
||||
# Escalado y diseño de topología
|
||||
|
||||
Esta guía se centra en diseñar `network.json` y elegir estrategias de integración para mantener rendimiento estable a escala.
|
||||
|
||||
## Principios de diseño
|
||||
|
||||
- Mantenga la jerarquía tan simple como sea posible.
|
||||
- Evite concentrar demasiado tráfico bajo un único padre de nivel superior.
|
||||
- Use nombres y relaciones padre/hijo estables para reducir churn de colas.
|
||||
- Valide cambios de topología en ventana de mantenimiento.
|
||||
|
||||
## Selección de estrategia por escala
|
||||
|
||||
Use la estrategia más simple que cumpla el objetivo operativo:
|
||||
|
||||
| Estrategia | Ajuste típico de escala | Tradeoff |
|
||||
|---|---|---|
|
||||
| `flat` | Máximo rendimiento, mínima jerarquía | Menor visibilidad/agregación |
|
||||
| `ap_only` | Redes grandes centradas en APs | Buen rendimiento, visibilidad media |
|
||||
| `ap_site` | Redes medianas/grandes con sitio+AP | Mejor agregación, costo moderado |
|
||||
| `full` | Necesidad de ruta/backhaul completo | Mayor control y mayor costo CPU/memoria |
|
||||
|
||||
Si necesita `full` y detecta saturación de un solo núcleo, use `promote_to_root`.
|
||||
|
||||
## Distribución padre/hijo
|
||||
|
||||
Objetivos:
|
||||
|
||||
- Balancear padres de nivel superior en tráfico y cantidad de circuitos.
|
||||
- Evitar ramas excesivamente profundas sin valor real para shaping.
|
||||
- Mantener nombres de hermanos únicos y estables.
|
||||
|
||||
Señales de alerta:
|
||||
|
||||
- Un núcleo saturado de forma persistente y el resto ocioso.
|
||||
- Reconstrucciones grandes de colas por cambios menores.
|
||||
- CPU Tree de Node Manager con distribución muy sesgada.
|
||||
|
||||
## Nodos virtuales y agrupación lógica
|
||||
|
||||
Los nodos virtuales ayudan para organización y agregación visual.
|
||||
|
||||
- Úselos para mejorar operabilidad y reportes.
|
||||
- No los use para ocultar una topología física confusa.
|
||||
- Valide colisiones de nombres tras promoción virtual.
|
||||
|
||||
## Guardrails de colas/clasificadores
|
||||
|
||||
A gran escala, la presión sobre identificadores de clase puede ser real.
|
||||
|
||||
- Monitoree eventos urgentes como `TC_U16_OVERFLOW`.
|
||||
- Si aparece, reduzca complejidad topológica y/o aumente paralelismo de colas.
|
||||
- Reevalúe profundidad de estrategia (`full` -> `ap_site`/`ap_only`) cuando haya riesgo.
|
||||
|
||||
Consulte [Solución de Problemas](troubleshooting-es.md#códigos-de-problemas-urgentes-y-primeras-acciones).
|
||||
|
||||
## Checklist de despliegue para cambios de topología
|
||||
|
||||
1. Respaldar `network.json` y `ShapedDevices.csv`.
|
||||
2. Aplicar un conjunto de cambios por vez.
|
||||
3. Revisar logs de `lqos_scheduler` y `lqosd` tras cada cambio.
|
||||
4. Validar en Node Manager:
|
||||
- CPU Tree / CPU Weights
|
||||
- comportamiento de mapa de flujos/ASN/árbol
|
||||
- estado del scheduler y problemas urgentes
|
||||
5. Mantener plan de rollback con configuración y archivos previos.
|
||||
|
||||
## Páginas relacionadas
|
||||
|
||||
- [Integraciones](integrations-es.md)
|
||||
- [Ajuste de rendimiento](performance-tuning-es.md)
|
||||
- [Configuración](configuration-es.md)
|
||||
- [Solución de Problemas](troubleshooting-es.md)
|
||||
@@ -0,0 +1,74 @@
|
||||
# StormGuard
|
||||
|
||||
StormGuard es el subsistema de ajuste adaptativo de colas de LibreQoS para eventos de congestión y calidad.
|
||||
|
||||
## Qué hace StormGuard
|
||||
|
||||
- Monitorea señales en tiempo real (throughput, métricas RTT/pérdida y contexto de saturación).
|
||||
- Aplica ajustes acotados a límites de nodos configurados para proteger calidad bajo estrés.
|
||||
- Expone estado y depuración en Node Manager.
|
||||
|
||||
## Configuración
|
||||
|
||||
StormGuard se configura en `/etc/lqos.conf` bajo `[stormguard]`.
|
||||
|
||||
Claves comunes:
|
||||
|
||||
- `enabled`: habilita o deshabilita StormGuard.
|
||||
- `dry_run`: calcula decisiones sin aplicar cambios de colas en vivo.
|
||||
- `targets`: lista de nodos de nivel superior a gestionar.
|
||||
- `minimum_download_percentage`: piso mínimo de descarga.
|
||||
- `minimum_upload_percentage`: piso mínimo de subida.
|
||||
- `log_file`: ruta opcional para telemetría CSV de decisiones/cambios.
|
||||
|
||||
Ejemplo:
|
||||
|
||||
```toml
|
||||
[stormguard]
|
||||
enabled = true
|
||||
dry_run = true
|
||||
log_file = "/var/log/stormguard.csv"
|
||||
targets = ["SITE_A", "SITE_B"]
|
||||
minimum_download_percentage = 0.5
|
||||
minimum_upload_percentage = 0.5
|
||||
```
|
||||
|
||||
Si está probando, comience con `dry_run = true`.
|
||||
|
||||
## UI y depuración
|
||||
|
||||
- Node Manager incluye vistas de estado y depuración de StormGuard.
|
||||
- La página de depuración muestra:
|
||||
- límites efectivos actuales
|
||||
- métricas de evaluación
|
||||
- contexto de reglas/decisiones
|
||||
|
||||
## Patrón de despliegue seguro
|
||||
|
||||
1. Habilitar con `dry_run = true`.
|
||||
2. Observar durante varios periodos pico.
|
||||
3. Validar que no haya oscilaciones indeseadas.
|
||||
4. Cambiar a `dry_run = false`.
|
||||
5. Monitorear después de cada cambio grande de topología/integración.
|
||||
|
||||
## Solución de problemas
|
||||
|
||||
Si el comportamiento parece incorrecto:
|
||||
|
||||
```bash
|
||||
sudo systemctl status lqosd lqos_scheduler
|
||||
journalctl -u lqosd --since "30 minutes ago"
|
||||
```
|
||||
|
||||
También verifique:
|
||||
|
||||
- que los nombres en `targets` aún coincidan con `network.json`
|
||||
- que cambios de integración no hayan renombrado nodos clave
|
||||
- que los pisos mínimos sean razonables para su perfil de tráfico
|
||||
- que `log_file` (si se usa) sea escribible por el servicio
|
||||
|
||||
## Páginas relacionadas
|
||||
|
||||
- [Configuración](configuration-es.md)
|
||||
- [Componentes](components-es.md)
|
||||
- [Solución de Problemas](troubleshooting-es.md)
|
||||
@@ -1,79 +1,94 @@
|
||||
# Solución de Problemas
|
||||
# Solución de problemas
|
||||
|
||||
## Problemas Comunes
|
||||
## Problemas comunes
|
||||
|
||||
### La contraseña de usuario no funciona
|
||||
|
||||
Eliminar el archivo lqusers:
|
||||
```
|
||||
Elimine el archivo de usuarios:
|
||||
|
||||
```bash
|
||||
sudo rm /opt/libreqos/src/lqusers.toml
|
||||
sudo systemctl restart lqosd lqos_scheduler
|
||||
```
|
||||
Entonces visita: BOX_IP:9123/index.html
|
||||
Esto le permitirá configurar el usuario nuevamente desde cero utilizando la interfaz web.
|
||||
|
||||
Luego abra: `IP_CAJA:9123/index.html`.
|
||||
|
||||
### No hay WebUI en x.x.x.x:9123
|
||||
|
||||
La interfaz web (WebUI) está controlada por el servicio lqosd. Generalmente, cuando la WebUI no se inicia, se debe a que lqosd está en un estado fallido. Verifica si el servicio lqosd está corriendo con el siguiente comando:
|
||||
```
|
||||
sudo systemctl status lqosd
|
||||
```
|
||||
La WebUI depende de `lqosd`. Cuando no carga, normalmente `lqosd` está fallando.
|
||||
|
||||
Si el estado es 'failed', examina la causa usando journalctl, que muestra el estado completo del servicio:
|
||||
```
|
||||
```bash
|
||||
sudo systemctl status lqosd
|
||||
journalctl -u lqosd --since "10 minutes ago"
|
||||
```
|
||||
Presiona la tecla End en el teclado para ir al final del registro y ver las últimas actualizaciones.
|
||||
|
||||
Lqosd proporcionará razones específicas del fallo, como por ejemplo que una interfaz no está activa, o que le falta soporte para múltiples filas (multi-queue), u otros problemas.
|
||||
`lqosd` suele mostrar causa específica (interfaz caída, falta de multi-queue, etc.).
|
||||
|
||||
### LibreQoS está en ejecución, pero no se está aplicando el shaping al tráfico
|
||||
### LibreQoS está en ejecución, pero no hace shaping
|
||||
|
||||
En el archivo /etc/lqos.conf, asegúrese de que los parámetros `to_internet` y `to_network` estén configurados correctamente.
|
||||
Si no lo están, simplemente intercambie las interfaces y reinicie lqosd y el scheduler.
|
||||
Verifique en `/etc/lqos.conf` que `to_internet` y `to_network` estén correctos.
|
||||
|
||||
```
|
||||
```bash
|
||||
sudo systemctl restart lqosd lqos_scheduler
|
||||
```
|
||||
|
||||
Asegurese de que los servicios estén funcionando correctamente
|
||||
|
||||
```
|
||||
sudo systemctl status lqosd lqos_scheduler
|
||||
```
|
||||
|
||||
El servicio lqos_scheduler depende de que el servicio lqosd esté en buen estado y en ejecución.
|
||||
### On-a-stick: shaping incorrecto o una dirección débil
|
||||
|
||||
### El servicio lqosd no se está ejecutando o falló al iniciar
|
||||
On-a-stick depende de split correcto por dirección. Si la detección TX o `override_available_queues` está mal, el mapeo puede degradarse.
|
||||
|
||||
Verifica el estado del servicio lqosd:
|
||||
```
|
||||
```bash
|
||||
sudo systemctl status lqosd
|
||||
journalctl -u lqosd --since "10 minutes ago"
|
||||
sudo systemctl restart lqosd lqos_scheduler
|
||||
```
|
||||
|
||||
Si el estado es 'failed', examine la causa con journalctl, que muestra el estado completo del servicio:
|
||||
```
|
||||
### El servicio lqosd no se ejecuta o falla al iniciar
|
||||
|
||||
```bash
|
||||
sudo systemctl status lqosd
|
||||
journalctl -u lqosd --since "10 minutes ago"
|
||||
```
|
||||
Presiona la tecla End en el teclado para ir al final del registro y ver las últimas actualizaciones.
|
||||
|
||||
Lqosd le mostrará razones específicas del fallo, como por ejemplo que una interfaz no está activa, que le falta soporte multi-queue, u otros problemas.
|
||||
|
||||
### Depuración avanzada de lqosd
|
||||
|
||||
Desde la línea de comandos, ejecuta:
|
||||
```
|
||||
```bash
|
||||
sudo RUST_LOG=info /opt/libreqos/src/bin/lqosd
|
||||
```
|
||||
Esto ejecutará lqosd en modo debug y te proporcionará detalles sobre por qué falló al iniciar.
|
||||
|
||||
### El servicio lqos_scheduler muestra errores
|
||||
|
||||
```bash
|
||||
sudo journalctl -u lqos_scheduler --since "1 day ago" --no-pager > lqos_sched_log.txt
|
||||
```
|
||||
|
||||
### El estado del scheduler en Node Manager aparece no saludable
|
||||
|
||||
Versiones recientes muestran estado/readiness del scheduler en Node Manager.
|
||||
|
||||
Si aparece caído/desactualizado:
|
||||
|
||||
1. Verifique ambos servicios.
|
||||
2. Revise logs recientes del scheduler.
|
||||
3. Revise logs de `lqosd` para eventos de scheduler ready/error.
|
||||
4. Si hubo cambios recientes, reinicie servicios.
|
||||
|
||||
```bash
|
||||
sudo systemctl status lqosd lqos_scheduler
|
||||
journalctl -u lqos_scheduler --since "30 minutes ago"
|
||||
journalctl -u lqosd --since "30 minutes ago"
|
||||
sudo systemctl restart lqosd lqos_scheduler
|
||||
```
|
||||
|
||||
Si oscila entre ready/error, valide credenciales y timeouts de integración en `/etc/lqos.conf`.
|
||||
|
||||
### RTNETLINK answers: Invalid argument
|
||||
|
||||
Este error suele aparecer cuando el qdisc tipo MQ no puede ser añadido correctamente a la interfaz de red (NIC).
|
||||
Esto sugiere que la tarjeta de red no tiene suficientes filas RX/TX. Asegurese de estar utilizando las [NICs recomendadas](requirements-es.md).
|
||||
Suele indicar que no se pudo agregar correctamente qdisc MQ en la NIC (colas RX/TX insuficientes). Verifique [NICs recomendadas](requirements-es.md).
|
||||
|
||||
### Error de Python ModuleNotFoundError en Ubuntu 24.04
|
||||
```
|
||||
### Python ModuleNotFoundError en Ubuntu 24.04
|
||||
|
||||
```bash
|
||||
pip uninstall binpacking --break-system-packages --yes
|
||||
sudo pip uninstall binpacking --break-system-packages --yes
|
||||
sudo pip install binpacking --break-system-packages
|
||||
@@ -84,40 +99,89 @@ pip uninstall deepdiff --break-system-packages --yes
|
||||
sudo pip uninstall deepdiff --break-system-packages --yes
|
||||
sudo pip install deepdiff --break-system-packages
|
||||
```
|
||||
### Todas las IPs de clientes aparecen como "Unknown IPs" en lugar de "Shaped Devices" en la interfaz gráfica
|
||||
```
|
||||
|
||||
### Todas las IPs de clientes aparecen como Unknown IPs
|
||||
|
||||
```bash
|
||||
cd /opt/libreqos/src
|
||||
sudo systemctl stop lqos_scheduler
|
||||
sudo python3 LibreQoS.py
|
||||
```
|
||||
El texto que se genera en la terminal al ejecutar LibreQoS.py proporciona más detalles sobre errores más específicos relacionados con problemas en los archivos ShapedDevices.csv y network.json.
|
||||
Una vez que haya identificado el error y corregido ShapedDevices.csv y/o network.json, ejecute:
|
||||
|
||||
```sudo systemctl start lqos_scheduler```
|
||||
|
||||
### Colisión al promover nodos virtuales (network.json)
|
||||
|
||||
Si LibreQoS.py falla con un error como `Virtual node promotion collision: 'AP_A' already exists at this level.`, tienes un nodo con `"virtual": true` cuyos hijos se promueven a un nivel padre donde ya existe un nodo con el mismo nombre.
|
||||
|
||||
Renombra uno de los nodos en conflicto (los nombres deben ser únicos entre hermanos después de la promoción), o reestructura la jerarquía para que los hijos promovidos no colisionen.
|
||||
|
||||
### Error de segmentación (segfault) en systemd
|
||||
|
||||
Si experimenta un segfault en systemd, este es un problema conocido en systemd [1](https://github.com/systemd/systemd/issues/36031) [2](https://github.com/systemd/systemd/issues/33643).
|
||||
Como solución temporal, puede compilar systemd desde cero:
|
||||
|
||||
### Instalar dependencias de compilación
|
||||
Corrija errores en `ShapedDevices.csv` y/o `network.json`, luego:
|
||||
|
||||
```bash
|
||||
sudo systemctl start lqos_scheduler
|
||||
```
|
||||
|
||||
### Flow Map / Tree Overview / ASN Explorer aparecen en blanco
|
||||
|
||||
Algunas vistas requieren suficiente dato reciente para renderizar.
|
||||
|
||||
1. Confirme que `lqosd` está saludable.
|
||||
2. Espere acumulación de tráfico.
|
||||
3. Recargue la página tras 1-2 minutos.
|
||||
4. Revise logs:
|
||||
|
||||
```bash
|
||||
journalctl -u lqosd --since "10 minutes ago"
|
||||
```
|
||||
|
||||
Si sigue en blanco con tráfico normal, recolecte logs y abra issue.
|
||||
|
||||
### Colisión de promoción de nodo virtual (`network.json`)
|
||||
|
||||
Si `LibreQoS.py` falla con `Virtual node promotion collision: 'AP_A' already exists at this level.`, hay un nodo con `"virtual": true` cuyos hijos colisionan por nombre al promoverse.
|
||||
|
||||
Renombre nodos en conflicto o reestructure jerarquía para evitar colisiones.
|
||||
|
||||
### Se alcanzó el límite de circuitos mapeados
|
||||
|
||||
Si ve mensajes como:
|
||||
|
||||
- `Mapped circuit limit reached`
|
||||
- `Bakery mapped circuit cap enforced`
|
||||
|
||||
LibreQoS está aplicando un límite de circuitos mapeados.
|
||||
|
||||
Checks recomendados:
|
||||
|
||||
1. Confirmar estado de licencia Insight en UI.
|
||||
2. Revisar logs de `lqosd` para requested/allowed/dropped.
|
||||
3. Reducir circuitos mapeados (corto plazo) o ajustar licencia/límites (largo plazo).
|
||||
|
||||
### Códigos de problemas urgentes y primeras acciones
|
||||
|
||||
Node Manager muestra códigos legibles por máquina para triage rápido.
|
||||
|
||||
| Código | Significado | Primeros checks | Ruta de corrección típica |
|
||||
|---|---|---|---|
|
||||
| `MAPPED_CIRCUIT_LIMIT` | Bakery está forzando límite de circuitos mapeados. | Estado de licencia Insight y `journalctl -u lqosd` con requested/allowed/dropped. | Reducir circuitos mapeados o actualizar licencia/límites. |
|
||||
| `TC_U16_OVERFLOW` | IDs minor de clases/colas excedieron rango u16 de tc en una cola CPU. | `journalctl -u lqos_scheduler -u lqosd`, profundidad topológica y distribución por colas. | Aumentar paralelismo de colas y/o simplificar/rebalancear jerarquía. |
|
||||
|
||||
Patrón operativo:
|
||||
|
||||
1. Abra el detalle del problema urgente en Node Manager (código/mensaje/contexto).
|
||||
2. Recolecte logs correlacionados de `lqosd` y `lqos_scheduler`.
|
||||
3. Aplique mitigación inmediata.
|
||||
4. Reconozca/limpie el evento en UI cuando esté estable.
|
||||
|
||||
### Segfault de systemd
|
||||
|
||||
Si experimenta un segfault en systemd, es un problema conocido [1](https://github.com/systemd/systemd/issues/36031) [2](https://github.com/systemd/systemd/issues/33643).
|
||||
|
||||
#### Instalar dependencias de compilación
|
||||
|
||||
```bash
|
||||
sudo apt update
|
||||
sudo apt install build-essential git meson libcap-dev libmount-dev libseccomp-dev \
|
||||
libblkid-dev libacl1-dev libattr1-dev libcryptsetup-dev libaudit-dev \
|
||||
libpam0g-dev libselinux1-dev libzstd-dev libcurl4-openssl-dev
|
||||
```
|
||||
|
||||
#### Clonar el repositorio de systemd desde github
|
||||
#### Clonar systemd desde GitHub
|
||||
|
||||
```
|
||||
```bash
|
||||
git clone https://github.com/systemd/systemd.git
|
||||
cd systemd
|
||||
git checkout v257.5
|
||||
@@ -125,9 +189,9 @@ meson setup build
|
||||
meson compile -C build
|
||||
sudo meson install -C build
|
||||
```
|
||||
Después, reinicia el sistema y confirma la versión de systemd con `systemctl --version`
|
||||
|
||||
```
|
||||
libreqos@libreqos:~$ systemctl --version
|
||||
systemd 257 (257.5)
|
||||
Luego reinicie y valide con:
|
||||
|
||||
```bash
|
||||
systemctl --version
|
||||
```
|
||||
Reference in new issue
Block a user