Problemas de instalación
Compruebe lo siguiente:
- La ISO debería haberse copiado a una unidad USB con particiones MBR y modo DD.
- La BIOS del servidor debe tener su modo de arranque predeterminado de fábrica (por ejemplo, DUAL).
- Si hay un controlador RAID, se debe configurar una unidad lógica y marcarla como de arranque.
- Compruebe si el servidor utilizado en la instalación cumple con los requisitos de hardware de BQN.
- Compruebe que la instalación se ha realizado en el disco duro y no se ha sobrescrito la unidad USB.
Sin acceso a la dirección IP de gestión
El BQN utiliza una interfaz de red dedicada para la gestión. La interfaz de gestión admite los servicios SSH y WEB (HTTPs). En caso de problemas para acceder a la IP de gestión configurada, compruebe lo siguiente:
- Asegúrese de que el puerto de la interfaz de red de administración esté conectado a la red adecuada.
- Verifique que el estado del enlace de la interfaz de red de administración esté activo. Si la interfaz de administración está conectada a un switch de red, verifique que el puerto en el switch esté activo y que sus atributos coincidan con las propiedades que muestra el comando show interface.
- Si accede a la dirección IP de gestión desde una red diferente, asegúrese de que el enrutamiento estático esté configurado para la red de acceso, como se explica en la sección Interfaz de red de la Guía del usuario.
- Si hay firewall en la red de gestión, permita el acceso al puerto TCP 22 para el servicio SSH y al puerto TCP 443 para el servicio WEB.
- Verifique utilizando la consola del sistema que la dirección IP de gestión y el prefijo de red son correctos. Conecte un monitor y un teclado al servidor e inicie sesión como root:
- Si sospecha que la configuración de IP de OAM es incorrecta o desconocida, conecte un monitor y un teclado al servidor e inicie sesión como root para cambiarla utilizando el asistente bta en modo interactivo. Por ejemplo, para cambiar la interfaz de administración a en0o1 con la dirección IP 10.10.10.12/24 (presione enter para aceptar la respuesta sugerida):
Si la interfaz no está disponible en el momento del cambio (por ejemplo, participó en un wire), un mensaje solicitará un reinicio. Después del reinicio, el BQN debería tener la nueva IP e interfaz de red de administración.
- La interfaz de administración de BQN puede estar protegida por su propio firewall. El problema podría ser que su dirección IP de origen no esté incluida en la lista blanca de ese firewall. Esto podría suceder incluso para direcciones de la misma subred de la IP de administración de BQN si la subred no forma parte de las reglas del firewall. Puede desactivar el firewall temporalmente hasta que se restablezca la conexión al puerto de administración. Conecte un monitor y un teclado al servidor e inicie sesión como root:
Una vez que la IP de gestión sea accesible, puede definir la nueva lista blanca de rangos de IP de origen permitidos.
- If the command <span class="character-highlight">wizard bta interactive</span> fails, connect with a console and a keyboard and try changing the configuration directly. In the following example, the management interface is in en0o2 and we will move it to interface en0o1 and from IP address 192.168.0.121 to IP address 10.0.0.121, with default gateway 10.0.0.1:
Web no accesible
- Compruebe que se puede acceder a la dirección IP de gestión mediante SSH,
- Compruebe que está utilizando HTTPS en el acceso (HTTP no es compatible). Ejemplo de URL: https://192.168.0.121
- Compruebe que está utilizando el usuario bqnadm (no se puede utilizar root en el acceso GUI).
- Cuando se instala desde cero, asegúrese de que el comando "wizard bta" se ejecutó (de lo contrario, el servicio web GUI no estará activo un usuario bqnadm no creado).
- Verifique que el puerto SSH del servidor BQN no ha sido modificado. Para acceder al BQN utilizando un puerto diferente al 22, puede definir reglas de reenvío de puertos en el router en la ruta de acceso, pero el puerto SSH del BQN no puede ser cambiado. Iniciando sesión en el servidor como root, puede verificar que el puerto SSH es el 22 de la siguiente manera:
Si es necesario, comente la línea que especifica un puerto diferente al 22.
- Compruebe que su navegador es compatible (Edge, Firefox, Chrome). MS Explorer, por ejemplo, no es compatible.
Interfaz de red inactiva
Si el icono Network Interfaces en el Dashboard no está en verde.
Vaya a Configuration->Interfaces->Data Wires
En rojo (Crítico)
- Si no hay ningún wire configurado, cree uno.
- Si hay wires configurados pero sus interfaces no están en estado UP, lo más probable es que esto indique que las interfaces no son compatibles con Intel. Vaya a Configuración->Interfaces->Wires de datos y haga clic en la interfaz inactiva para ver el modelo (ID del proveedor PCI) y confirme que no es Intel. Elimine el wire y cree uno nuevo con ambas interfaces en modo pcap. Esto debería colocar las interfaces en estado UP, pero con una capacidad de rendimiento mucho menor (menos de 1 Gbps).
- Si hay wires configurados, con interfaces en estado UP pero con el ENLACE inactivo, hay un problema en la conexión con el otro equipo. Conecte ambos puertos de interfaz entre sí en un bucle utilizando un cable/fibra adecuado. Si ambas interfaces están activas, entonces el problema está en el otro equipo.
Si el enlace sigue inactivo y se utilizan puertos ópticos, verifique que los transceptores:
- sean compatibles con Intel
- son compatibles (consulte la lista de tarjetas de red compatibles).
- del tipo que requiera la instalación (por ejemplo, SFP+-LR en una instalación con fibra monomodo y SFP+-LR en el otro extremo).
En amarillo (Aviso)
- Si las wires aparecen como inactivas deberían tener tráfico, sigue los pasos de la sección anterior (Crítico).
- Si los wires aparecen como «inactivos» no se están utilizando y deseas eliminar la señal de aviso, puedes borrar los wires que no se utilicen. Ten en cuenta que los cambios en la wire interrumpirán el tráfico durante un tiempo (entre 10 segundos y dos minutos, dependiendo de la configuración del servidor).
Tráfico invertido
Si el icono de «Tráfico invertido» del panel de control aparece en naranja (Advertencia), significa que el volumen de tráfico en la dirección de subida es mayor que en la de bajada. Esto puede ser normal en implementaciones pequeñas (menos de cien abonados, como una red BQN en un laboratorio), pero en una red real lo más probable es que indique que algunos de los wires conectado incorrectamente, de modo que el puerto de acceso está conectado al lado de Internet y viceversa.
Para comprobar que así es, ve a «Estado» > «Interfaces» > «Rendimiento» y comprueba que las interfaces de acceso transmiten más tráfico del que reciben y que ocurre lo contrario en las interfaces de Internet. Si no es así, es señal de que el wire invertido.
Para solucionar el problema, vaya a Configuration->Interfaces->Data Wires y, en el hilo invertido, pulse el icono paraIntercambiar interfaces.
En «Estado» > «Interfaces» > «Ancho de banda» , ahora debería mostrarse más tráfico enviado que recibido en las interfaces de acceso:
Tráfico bajo
El icono de «Tráfico bajo » del panel de control es de color amarillo y se encuentra en estado «AVISO».
Pasa el ratón por encima del icono para comprobar que aparece el aviso «Tráfico bajo ». Esto indica que hay muy poco tráfico pasando por el servidor BQN. Es normal si el sistema aún está a la espera de que se le envíe tráfico. Sin embargo, en un sistema en producción, puede ser un indicio de que algún fallo en otra parte de la red está impidiendo que el tráfico llegue al servidor BQN.
Tráfico asimétrico
El tráfico asimétrico se produce cuando el servidor BQN solo detecta una de las direcciones del tráfico (enlace ascendente o descendente) y no la otra.
El tráfico asimétrico puede afectar a todo el tráfico que pasa por el BQN o solo a una parte del mismo.
La optimización de TCP requiere un tráfico simétrico, por lo que la asimetría provoca una degradación de la experiencia del abonado y es necesario desactivar el TCPO en el tráfico afectado mientras se soluciona el problema.
Todo el tráfico es asimétrico
El icono de «Tráfico bajo» del panel de control es de color naranja y se encuentra en estado de ADVERTENCIA.
Pasa el ratón por encima del icono. Debería aparecer una advertencia en «Tráfico de subida » o«Tráfico de bajada ». Esto indica que no hay tráfico pasando por el BQN en esa dirección y, por lo tanto, el tráfico es asimétrico.
Para desactivar TCPO en el tráfico afectado, ve a Configuración -> Ajustes de optimización y desactiva la opción «Optimización TCP general» hasta que se solucione el problema de enrutamiento del tráfico que provoca la asimetría.
Parte del tráfico es asimétrico
El icono de «Tráfico bajo» del panel de control está en verde, en estado NORMAL, y, sin embargo, se están recibiendo quejas de los clientes por una disminución de la calidad del servicio.
Para comprobar si parte del tráfico es asimétrico, ve a Estado->Suscriptores->Métricas de QoE y aplica un filtro en la tabla de suscriptores para ver únicamente a aquellos que tengan 0 bytes en la dirección de subida (MBYTES-DOWN) o en la de bajada (MBYTES-UP).
Descarta las direcciones IP de multidifusión o de difusión. En el caso de esas direcciones IP, es perfectamente normal que el tráfico se produzca solo en una dirección. Por ejemplo, la dirección de difusión IPv4 255.255.255.255 o la dirección de multidifusión de enlace local IPv6 ff02::,
Si observas direcciones IP normales con 0 bytes en una dirección y un tráfico considerable en la otra, significa que esa dirección IP presenta tráfico asimétrico. Dado que el problema suele deberse a un enrutamiento incorrecto del tráfico, otras direcciones IP de la misma subred también se verían afectadas.
Para desactivar TCPO en el tráfico afectado mientras se corrige el enrutamiento, ve a Configuración -> Flujos de abonados y crea una política de flujo con la optimización TCP desactivada; a continuación, crea un perfil de acceso que contenga las direcciones IP o rangos de direcciones IP de los abonados afectados y vincúlalos a una regla. Consulta los detalles en este ejemplo.
Administrador de licencias
Si el icono Administrador de licencias en el panel de control está en amarillo y el texto dice “license-mgr-connection:notice”, esto se debe a que el servidor BQN no puede acceder al administrador de licencias. El administrador de licencias es responsable de validar las licencias SW de BQN y también ayuda a Bequant a brindar un soporte más proactivo al informar problemas del servidor.
Asegúrese de que el servidor BQN pueda iniciar conexiones salientes a la IP del Administrador de licencias (comuníquese con el soporte de Bequant para obtener más detalles).
Para comprobar que es posible establecer una conexión saliente, inicia sesión como root y realiza un telnet a la dirección IP y el puerto indicados:
La conexión por Telnet debería funcionar si se puede acceder al gestor de licencias.
Licencia no OK
Si el icono de la licencia en el panel de control aparece en rojo y el texto indica «license-available:critical»o«license-expiration: critical», significa que no hay ninguna licencia válida. Esto podría deberse a varias razones:
- No hay ninguna licencia definida en el nodo
- La licencia no es válida
- La licencia ya no es válida (su fecha de finalización ha expirado).
Póngase en contacto con su distribuidor para obtener una licencia válida.
Puede comprobar el estado de la licencia en Administration->License.
Cuando no hay una licencia válida, el BQN reenviará todo el tráfico de forma transparente: el servicio no se verá afectado, pero ninguno de los procesamientos avanzados del BQN se aplicará al tráfico.
Límite de licencia excedido
Si el icono de la licencia en el panel de control aparece en naranja y el texto indica «license-usage: warning», se está superando la capacidad máxima de la licencia (el tráfico total que pasa por el servidor BQN supera el límite de la licencia).
Póngase en contacto con su distribuidor para obtener una actualización de la licencia.
Puede comprobar la capacidad de la licencia en Administration->License.
En Statistics->Throughput->Overview, una línea roja mostrará el límite de la licencia junto con los niveles recientes de producción.
Exceder el límite de la licencia debe ser temporal, mientras la licencia se actualiza a la capacidad correcta.
Cuando se excede el límite de la licencia, el QoE no descartará ningún paquete; simplemente los puenteará.
El efecto sobre el tráfico es diferente a nivel de flujo y a nivel de sesión de suscriptor.
Efectos a nivel de flujo:
- Mientras se excede el límite de la licencia, los nuevos flujos no tendrán licencia.
- Los flujos existentes antes de que se exceda la licencia no se ven afectados: si se estaban optimizando, siguen haciéndolo, y lo mismo ocurre si no tienen licencia.
- Una vez que el tráfico optimizado cae por debajo del límite, los nuevos flujos se optimizan de nuevo.
- Los flujos existentes antes de que la licencia caiga por debajo del límite no se ven afectados: si no tenían licencia, permanecen así, y lo mismo ocurre si se estaban optimizando.
- Un flujo sin licencia tiene:
- Sin TCPO
- Sin shaping
- No genera métricas (retransmisiones, latencias, DPI, etc.).
Efectos a nivel de sesión de suscriptor:
- Mientras se excede el límite de la licencia, las nuevas sesiones de suscriptor no tendrán licencia.
- Las sesiones de los suscriptores existentes antes de que se superara el límite de licencias permanecen inicialmente en su estado actual: si estaban optimizadas, siguen estándolo, y lo mismo ocurre si no lo estaban.
- Si la licencia permanece por encima del límite, las sesiones de suscriptor que se están optimizando pueden pasar a no tener licencia si acumulan un gran número de flujos no optimizados.
- Una vez que el tráfico optimizado cae por debajo del límite, las nuevas sesiones de suscriptor se optimizan de nuevo.
- Las sesiones de suscriptor que finalizan antes de que la licencia caiga por debajo del límite permanecen inicialmente en su estado actual: si no tenían licencia, permanecen así, y lo mismo ocurre si se estaban optimizando.
- Si la licencia permanece por debajo del límite, las sesiones de suscriptor sin licencia pueden pasar a optimizarse si acumulan un número reducido de flujos optimizados.
- Una sesión de suscriptor sin licencia presenta las siguientes características:
- sin ACM,
- sin limitación de velocidad
- sigue generando cifras totales de volumen de tráfico.
- Se suspende la presentación de informes sobre el volumen de cuotas.
- No se producirá ningún bloqueo al agotarse la cuota.
- Las demás métricas, como las retransmisiones, las latencias, etc., se reducirán a los valores de los flujos que se estén optimizando.
- Una sesión de suscriptor que se está optimizando se verá afectada por el hecho de que algunos de sus flujos pueden no tener una licencia y, por lo tanto, el suscriptor puede tener un conjunto reducido de mediciones en comparación con el funcionamiento normal. Esto afecta al ACM y también a las métricas generadas para ese suscriptor.
El efecto de exceder el límite de la licencia es que cada vez más tráfico dejará de tener la funcionalidad QoE y, a la inversa, la cantidad de tráfico que obtiene la funcionalidad QoE disminuye. Una vez que la cantidad de tráfico que obtiene la funcionalidad QoE está por debajo del límite de la licencia, los nuevos flujos y las sesiones de suscriptor recuperarán la funcionalidad QoE. Esto continúa hasta que se excede el límite de la licencia, después de lo cual el efecto se repite nuevamente. Con este comportamiento oscilante, la QoE sigue proporcionando funcionalidad al tráfico hasta el límite de la licencia. El BQN comprueba continuamente el nivel de rendimiento frente a los límites de la licencia (cada minuto o menos), por lo que la adaptación es bastante rápida.
Carga elevada de CPU
Si el icono de CPU en el panel de control no está en verde, algunas CPU están funcionando a niveles anormalmente altos. Esto normalmente se debe a un tráfico desequilibrado (concentrado en unas pocas IP de suscriptor) o a un exceso de tráfico que está siendo procesado por el servidor BQN.
El nivel de rendimiento se puede consultar en «Estadísticas» > «Rendimiento» > «Resumen», y los niveles de CPU, en «Estadísticas» > «Sistema» > «CPU».
Existen dos tipos de alarmas, dependiendo de los niveles de carga de la CPU:
- Naranja si algunos núcleos de la CPU tienen una carga elevada (por encima del 80 % de uso).
- Rojo si algunos núcleos de la CPU están a una carga muy alta (por encima del 90% de uso).
En primer lugar, una breve introducción al uso básico de BQN.
Averiguar las afinidades de los núcleos de la CPU: E/S y trabajadores
En el BQN, los procesos críticos se ejecutan con máxima prioridad en los núcleos de CPU que se les han asignado. A esto se le denomina «afinidades de núcleo». A dos procesos se les asignan núcleos de CPU:
- Procesos de E/S: se encargan de las operaciones de lectura y escritura de los paquetes de tráfico que entran y salen de los puertos de la interfaz de red.
- Workers: son los procesos del plano de datos encargados de todo el procesamiento de paquetes (optimización de TCP, ACM, diversos shaping , inspección DPI, etc.).
El resto de los procesos BQN se ejecutan en cualquier núcleo disponible, pero en el caso de que se haya designado uno concreto, el programador puede interrumpir el proceso de baja prioridad para ejecutar uno de alta prioridad. Si el servidor cuenta con suficientes núcleos de CPU, algunos se dejan sin asignar para que puedan dedicarse a procesos de baja prioridad.
Para ver la afinidad de los núcleos de la CPU en tu servidor, ejecuta este comando:
En este ejemplo, el servidor tiene 10 núcleos. Siete núcleos se asignan a procesos de alta prioridad: seis para ejecutar procesos de trabajo y uno para ejecutar procesos de E/S. Quedan tres núcleos sin asignar, listos para ejecutar procesos de baja prioridad. La asignación concreta de los núcleos dependerá del número de núcleos de la CPU, del número de wires de la velocidad de dichos wires. El BQN intentará realizar la asignación más óptima en función de esas variables. En el ejemplo, hay un wire una capacidad de rendimiento wire 10 Gbps.
El campo «affinity» indica los núcleos asignados. En el ejemplo, la E/S se encuentra en el núcleo número 3 —siendo 0 el primer núcleo (0x8 = 1000)— y gestiona el tráfico de ambas interfaces del wire. Los trabajadores se encuentran en los núcleos del 4 al 9 (0x3F0 = 1111110000). Los núcleos del 0 al 2 no están asignados (núcleos de uso general).
Las instancias de los procesos de trabajo se numeran a partir del uno. En el ejemplo, la instancia de trabajo n.º 1 se encuentra en el núcleo 4 y la instancia de trabajo n.º 6, en el núcleo 9.
Puedes ver la instancia de trabajo que gestiona un suscriptor concreto consultando la sección «Detalles adicionales» del panel de control del suscriptor.
Averigua qué núcleos están sobrecargados
Ve a Estadísticas->Sistema->CPU e identifica los núcleos de la CPU que estén ocupados en un 80 % o más. Revisa las últimas 24 horas, ya que es posible que la carga elevada se haya producido en algún momento anterior.
Determina si los núcleos de la CPU afectados son de E/S o de trabajo.
A veces, los picos de carga de la CPU son breves y no se aprecian en las estadísticas del sistema, ya que estas muestran un promedio calculado en intervalos de 5 minutos. Ve a Administración->Registros->Sistema.
Aumenta el número de líneas (por ejemplo, 1000 líneas) y configura la expresión regular positiva para filtrar «cpu». De este modo, deberían aparecer las alarmas de CPU generadas y, lo que es más importante, una entrada de registro que indique qué núcleo de CPU concreto se ve afectado. En el siguiente ejemplo, el código 6 pasa al estado de alarma alta debido a un uso del 94 %:
En nuestro ejemplo, Core 6 es un trabajador.
Alta carga en los núcleos de la CPU del trabajador
La causa habitual es un desequilibrio en el tráfico. BQN utiliza las direcciones IP de los suscriptores para distribuir el tráfico entre los trabajadores disponibles. Si unas pocas direcciones IP concentran demasiado tráfico, los trabajadores que las gestionan pueden verse desbordados.
Ve a Estadísticas > Suscriptores > Principales por tiempo para ver cómo se distribuye el tráfico entre los suscriptores con mayor uso. Comprueba si los que aparecen en los primeros puestos concentran mucho más tráfico que el resto.
Para confirmarlo, haz clic con el botón derecho del ratón en las direcciones IP con mayor uso para acceder al panel de control del suscriptor correspondiente y comprueba el número de instancia en «Detalles adicionales». Por ejemplo, en el ejemplo que estamos siguiendo, si el núcleo de trabajo es el número 6, la instancia esperada es la 3. La instancia debe coincidir con la que figura en los registros del sistema.
Si no se detecta ningún desequilibrio en el tráfico, es posible que el problema se deba a unos niveles de tráfico elevados en general. En ese caso, el núcleo de trabajo con mayor carga irá cambiando de vez en cuando. Ve a Estadísticas -> Rendimiento -> Resumen y comprueba si los picos de tráfico coinciden con los picos de los núcleos de trabajo.
Puede ser necesaria una actualización de hardware. Póngase en contacto con el servicio de soporte de Bequant.
Mientras tanto, el BQN cuenta con mecanismos internos para mitigar la elevada carga de los núcleos de trabajo, con el fin de evitar pérdidas de tráfico mediante la reducción del volumen de tráfico optimizado.
Otras medidas de mitigación que puedes adoptar mientras esperas la actualización del hardware:
- Activa el bypass para aquellas direcciones IP que estén provocando la sobrecarga. El tráfico de esas direcciones IP no se optimizará ni se limitará, pero la carga de los núcleos afectados debería reducirse, ya que los trabajadores no procesarán el tráfico procedente de esas direcciones IP.
- Si utilizas NAT entre el BQN y los usuarios finales, aumenta el número de direcciones IP que utiliza el NAT, de modo que el BQN pueda distribuir el tráfico entre más direcciones.
Si el servidor BQN se utiliza únicamente para TCPO y/o límites de velocidad por flujo, se puede mejorar la distribución de la carga de la CPU activando el control por flujo. El control por flujo distribuye la carga de tráfico entre los núcleos de la CPU por cada flujo individual, en lugar de la distribución de tráfico predeterminada por suscriptor. Esto mejora el equilibrio de la carga de la CPU, pero, dado que el control por suscriptor se realiza por núcleo, no permite el control a nivel de suscriptor, como ACM, tasas de política o límites de flujo por suscriptor.
Alta carga de E/S en los núcleos de la CPU
Una carga elevada de los núcleos de E/S es un problema crítico, ya que algunos paquetes no se retransmitirán y, por lo tanto, se descartarán debido a una capacidad de procesamiento insuficiente de los núcleos.
Este problema suele deberse a unos niveles elevados de tráfico. Ve a Estadísticas → Rendimiento → Resumen paracomprobar que los picos de tráfico se corresponden con los picos en los núcleos de E/S afectados.
Otra posibilidad es que la interfaz de red del servidor BQN no admita la distribución de la carga del tráfico entre varios procesos de E/S. Esto ocurre con el tráfico PPPoE en algunos modelos de tarjetas de red. Véase Interfaces de red compatibles y Solución de problemas del XL710.
Otra posible causa es que el wire modo pcap, lo que limita su capacidad a unos 1 Gbps de ancho de banda¹. Si se trata de un error de configuración y la tarjeta de red es compatible con Intel, ve a Configuración -> Interfaces -> Wires de datos y cambia el wire modo normal (DPDK).
Puede ser necesaria una actualización de hardware. Póngase en contacto con el servicio de soporte de Bequant.
Mientras tanto, una posible medida es modificar las afinidades de los núcleos de la CPU, reasignando los núcleos de trabajo o los núcleos sin asignar a los procesos de E/S. El servicio de asistencia de Bequant te ayudará con ello.
Carga elevada de memoria
Si el icono de «Memoria» del panel de control no aparece en verde, significa que algunos procesos se están quedando sin memoria.
Existen dos tipos de alarma, en función de los niveles de carga de la memoria:
- Naranja si algunos procesos alcanzan un uso elevado (por encima del 90% de uso).
- Rojo si algunos procesos alcanzan un uso muy alto (por encima del 95% de uso).
Averigua el uso de la memoria
Ve a Estadísticas->Sistema->Memoria e identifica qué memoria supera el umbral de uso. Revisa las últimas 24 horas, ya que es posible que el pico de uso se haya producido en el pasado.
La memoria del sistema se divide en tres secciones:
- Pool de DPDK: es la memoria del sistema reservada para la biblioteca DPDK, en la que se almacenan los paquetes de tráfico. En los servidores NUMA, cada NUMA contará con su propio pool de DPDK para almacenar el tráfico relacionado con las tarjetas de red instaladas en ese NUMA.
- Pool de memoria (mpool): es la memoria del sistema que utilizan los procesos de trabajo para almacenar información sobre flujos, suscriptores y metadatos de tráfico.
- Resto de la memoria del sistema (el 20 % del total): la utiliza el resto del sistema; por ejemplo, el gestor de la API al interactuar con sistemas de facturación externos, para tareas de gestión, etc.
Una causa habitual del elevado consumo de memoria es un rendimiento de tráfico excesivo. Comprueba si los picos de «Estadísticas → Rendimiento → Resumen» se corresponden con los picos de «Estadísticas → Sistema → Memoria».
A veces, los picos de uso de memoria son breves y no se aprecian en las estadísticas del sistema, ya que estas muestran un promedio calculado en intervalos de 5 minutos. Ve a Administración > Registros > Sistema.
Aumenta el número de líneas (por ejemplo, 1000 líneas) y configura la expresión regular positiva para filtrar por «memoria». Esto debería mostrar las alarmas de memoria generadas.
Una entrada de registro que indica que el grupo DPDK está registrando un uso elevado tiene el siguiente aspecto (en este ejemplo, el grupo DPDK tiene un uso del 92 %):
El grupo de DPDK es compartido por todos los trabajadores y, por lo tanto, el hecho de que la alarma se haya generado cuando la instancia 2 del trabajador estaba realizando una solicitud no significa que sea la instancia 3 la responsable del elevado uso.
Una entrada del registro que indica que el mpool está experimentando un uso elevado tiene el siguiente aspecto (en este ejemplo, el mpool tiene un uso del 96 %):
El «mpool» se divide a partes iguales entre todos los trabajadores, cada uno con su propio subpool, por lo que la instancia de trabajador en la que se genera la alarma es la responsable del elevado uso (la instancia de trabajador 3 en nuestro ejemplo).
Puede ser necesaria una actualización de hardware. Póngase en contacto con el servicio de soporte de Bequant.
Mientras tanto, el BQN cuenta con mecanismos internos para mitigar el elevado consumo de memoria, con el fin de evitar pérdidas de tráfico mediante la reducción del volumen de tráfico optimizado.
Alto uso del grupo de recursos de DPDK
Esto puede deberse a una configuración incorrecta de NUMA: en los servidores NUMA, se espera que las tarjetas de red estén repartidas entre los dos NUMA. Si todas las tarjetas de red se encuentran en el mismo NUMA, el grupo DPDK del otro NUMA no se utilizará, mientras que el grupo DPDK del NUMA que alberga todas las tarjetas de red registrará un uso elevado.
Para resolver el problema, es necesario reasignar las tarjetas de red, de modo que se distribuyan entre las dos zonas NUMA del servidor. El servicio de asistencia de Bequant te ayudará con ello y, mientras tanto, también te asesorará sobre cómo ajustar el uso del grupo DPDK. Además, se puede desviar parte del tráfico a través de la opción «Configuración» → «Ajustes de optimización».
Alto uso de mpool
Si solo hay unas pocas instancias de trabajo implicadas en el problema, es posible que este se deba a un desequilibrio en el tráfico. BQN utiliza las direcciones IP de los suscriptores para distribuir el tráfico entre las instancias de trabajo disponibles. Si unas pocas direcciones IP concentran demasiado tráfico, las instancias de trabajo que las gestionan pueden quedarse sin memoria.
Ve a Estadísticas > Suscriptores > Top por tiempo para ver cómo se distribuye el tráfico entre los suscriptores con mayor uso. Comprueba si los que encabezan la lista concentran mucho más tráfico que el resto.
Para confirmarlo, haz clic con el botón derecho del ratón en las direcciones IP con mayor uso para acceder al panel de control del abonado y comprueba el número de instancia en «Detalles adicionales». Por ejemplo, en el ejemplo que estamos siguiendo, será la instancia 3. La instancia debe coincidir con la que figura en los registros del sistema.
Un uso elevado de mpool también puede deberse a un nivel elevado de suscriptores simultáneos y/o flujos de tráfico.
Este problema requerirá una actualización de hardware. Mientras tanto, las direcciones IP con tráfico concentrado pueden desviarse accediendo a «Configuración» > «Ajustes de optimización».
Alto consumo de memoria del sistema
Esto puede deberse a un elevado volumen de tráfico, a flujos simultáneos de abonados y/o de tráfico, y al intercambio de datos de sincronización con sistemas de facturación externos.
La memoria se transferirá al disco, lo que ralentizará considerablemente el servidor, por lo que se recomienda ir a «Configuración» → «Ajustes de optimización» y activar el desvío de todo el tráfico mientras se actualiza la memoria.
Sin sincronización RADIUS
El RADIUS está configurado en «Configurar» → «RADIUS/REST/Facturación», pero no aparece ninguna información sobre RADIUS en «Estado» → «Abonnados» → «Atributos de los abonnados»: al filtrar por «Asignado por RADIUS» no aparece ningún abonnado.
Comprobar la recepción del tráfico RADIUS
Captura el tráfico RADIUS en «Estado» > «Interfaces» > «Estado de enlace», seleccionando la interfaz de gestión (la que tiene marcada la columna «MGT») y utilizando «puerto 1812 o puerto 1813» como filtro:
Establece el tiempo de espera de captura en un periodo superior al intervalo de cierre contable.
También es posible capturar el tráfico RADIUS mediante la CLI. Conéctate a través de SSH:
Si no se registra tráfico, los mensajes RADIUS no están llegando al servidor BQN. . Consulte la siguiente sección.
No se han recibido mensajes RADIUS
Si se ha configurado el cortafuegos BQN (Configuración -> Interfaces -> Cortafuegos de gestión), deben añadirse todas las direcciones IP de los clientes RADIUS (en este ejemplo, 10.10.10.10 y 10.10.10.11).
Si aún así no se reciben mensajes RADIUS, hay que comprobar el resto de los saltos de tráfico. En nuestro ejemplo, los clientes RADIUS se encuentran en la subred 10.10.10.0/24 y el BQN, en la subred 192.168.0.0/24. Comprueba que exista una ruta válida entre las dos subredes y que ningún cortafuegos intermedio bloquee el puerto UDP 1813 (contabilidad RADIUS) y, si se encuentra en modo proxy RADIUS, el puerto UDP 1812 (autenticación RADIUS).
Consulta el registro del sistema
Si se reciben mensajes RADIUS, pero sin sincronización RADIUS, revisa los registros del sistema.
Ve a Administración->Registros->Sistema y utiliza la expresión regular «RADIUS».
Si no se encuentra ninguna entrada en el registro del sistema, puedes aumentar su nivel. Accede al servidor BQN a través de SSH:
Espera un rato y vuelve a mirar en «Administración» → «Registros» → «Sistema» utilizando la expresión regular «RADIUS».
Por ejemplo, esta entrada del registro indica que la dirección IP 10.10.10.10 es desconocida:
Ve a Configuración->RADIUS/REST/Facturación->RADIUS y añade la dirección como cliente RADIUS válido.
Esta otra entrada del registro indica que el secreto utilizado por el cliente no coincide con el del BQN:
Ve a Configuración->RADIUS/REST/Facturación->RADIUS y comprueba que la clave secreta del cliente RADIUS sea correcta.
Activar los registros de la API
Si se reciben mensajes RADIUS, pero sin sincronización RADIUS, una alternativa a los registros del sistema son los registros de la API.
Accede al shell del servidor BQN mediante SSH:
Y consulta los registros de la API con el comando:
Un ejemplo de un mensaje «Accounting Start» recibido correctamente y la respuesta correspondiente del BQN al cliente RADIUS:
El mensaje RADIUS asocia la política de tarifas RA-30M/40M-60M/80M-50M/70M-2/3 a la dirección IP del abonado 10.0.0.1.
A continuación se muestra un ejemplo de un mensaje «Accounting Start» recibido que se ha procesado y al que se ha respondido «OK», pero que presenta un error en el nombre del tipo de interés de la política:
No se ha podido extraer el nombre de la política de velocidad del mensaje RADIUS: policyName (n/a). Si esto ocurre, ve a la sección «Comprobar los parámetros AVP».
Comprueba los parámetros AVP de RADIUS
Si se reciben y aceptan mensajes RADIUS y, sin embargo, el BQN no muestra ningún atributo procedente de RADIUS, comprueba en las capturas del tráfico RADIUS recibido que los mensajes contengan los AVP esperados.
Además, ve a Configuración->RADIUS/REST/Facturación->RADIUS y comprueba, en la sección «Selección de AVP», que el AVP con la política de tarifas aparezca en la lista (y, por lo tanto, sea compatible con BQN) y que no se esté ignorando. Por ejemplo, si se utiliza el AVP «Mikrotik-Rate-Limit»:
Sin sincronización REST
REST se configura en «Configurar» → «RADIUS/REST/Facturación» → «REST», pero no se encuentra ninguna información sobre REST en«Estado» → «Suscriptores» → «Atributos del suscriptor»: al filtrar por «Asignado por REST» no aparece ningún suscriptor.
Comprobar la recepción del tráfico REST
Captura el tráfico REST en «Estado» > «Interfaces» > «Estado del enlace», seleccionando la interfaz de gestión (la que tiene marcada la columna «MGT») y utilizando «tcp y puerto 3443» como filtro:
Envía algunas consultas REST a la dirección IP de OAM de BQN.
También es posible capturar el tráfico REST mediante la CLI. Conéctate a través de SSH:
Si no se detecta tráfico, los mensajes REST no están llegando al servidor BQN. Consulta la siguiente sección.
No se han recibido mensajes REST
Si se ha configurado el cortafuegos BQN (Configuración -> Interfaces -> Cortafuegos de gestión), deben añadirse todas las direcciones IP de los clientes REST (en este ejemplo, 10.10.10.10 y 10.10.10.11).
Si aún así no se reciben los mensajes REST, hay que comprobar el resto de los saltos de tráfico. En nuestro ejemplo, los clientes REST se encuentran en la subred 10.10.10.0/24 y BQN en la subred 192.168.0.0/24. Comprueba que exista una ruta válida entre ambas subredes y que ningún cortafuegos intermedio bloquee el puerto TCP 3443.
Consulta el registro del sistema
Si se reciben mensajes REST, pero sin sincronización REST, revisa los registros del sistema.
Ve a Administración->Registros->Sistema y utiliza la expresión regular «REST|HTTP».
Si no se encuentra ninguna entrada en el registro del sistema, puedes aumentar su nivel. Accede al servidor BQN a través de SSH:
Espera un rato y vuelve a mirar en «Administración» → «Registros» → «Sistema» con la expresión regular «REST|HTTP».
Por ejemplo, esta entrada del registro indica que la dirección IP 10.10.10.10i es desconocida:
Ve a Configuración->RADIUS/REST/Facturación->REST y asegúrate de que la dirección sea la de un cliente REST válido.
Esta otra entrada del registro indica que el nombre de usuario o la contraseña son incorrectos:
Ve a Configuración->RADIUS/REST/Facturación->REST y comprueba que el nombre de usuario y la contraseña sean los mismos que utiliza el cliente REST.
Activar los registros de la API
Si se reciben mensajes REST, pero sin sincronización RADIUS, una alternativa a los registros del sistema son los registros de la API.
Accede al shell del servidor BQN mediante SSH:
Y consulta los registros de la API con el comando:
Un ejemplo de una consulta REST recibida correctamente y la respuesta BQN:
A continuación se muestra un ejemplo de una consulta REST recibida con un URI desconocido (la consulta no se ha formulado correctamente):
Habilitar los registros de la API
Si hemos detectado que hay un problema en una de las solicitudes, podemos averiguar cuál es la que lo está causando activando los rastros de la API. De este modo, se generará un archivo de rastreo por cada solicitud o respuesta.
Accede al shell del servidor BQN mediante SSH:
Además, BQN generará registros de las últimas 5 solicitudes y respuestas REST. Estos registros se encuentran en el directorio /opt/bqn/var/trace. Inicia sesión mediante SSH:
La primera solicitud/respuesta es correcta:
La segunda solicitud/respuesta presenta un error:
The POST request has a wrong body. Review the REST clientPOST request and compare it with the REST API reference manual. In this example,the POST body had a typo (double quotes after value missing): {"subscriberId": "myid}
Problema con la emisión del certificado REST
Si una solicitud a una API REST devuelve un error relacionado con la verificación del certificado, por ejemplo:
La razón es que el certificado BQN está autofirmado y el cliente debe desactivar la validación del certificado. Por ejemplo, usando curl:
Y usando python:
Versión de TLS de REST
BQN utiliza TLS 1.2. Algunas versiones nuevas de python rechazan TLS 1.2 de forma predeterminada. Para que lo acepte, utilice el siguiente código:
Puede encontrar un ejemplo completo de esto aquí.
No hay sincronización de facturación
Si el sistema de facturación está configurado y el icono de Facturación en el panel de control está en rojo, está fallando el acceso al sistema de facturación.
Haga clic en el icono de facturación para ir a la página de estado de la facturación:
En este ejemplo, hubo una sincronización exitosa a las 12:13:52 recuperando 1000 suscriptores, pero hubo un intento fallido después. Puede forzar un intento de sincronización presionando el botón Sincronizar ahora.
Si el fallo persiste, siga estos pasos:
- Comprueba las credenciales de acceso al sistema de facturación: clave API, nombre de usuario/contraseña, etc. Estas credenciales deben estar registradas en el sistema de facturación.
- En algunos sistemas de facturación (por ejemplo, Splynx), es necesario conceder acceso a determinadas llamadas a la API REST.
- En algunos sistemas de facturación (por ejemplo, Azotel), también es necesario autorizar la dirección IP de origen desde la que se accede al sistema de facturación. Se trata de la dirección IP pública que llega al sistema de facturación desde la dirección de gestión de BQN (la misma si el servidor de BQN utiliza una dirección IP pública).
- Comprueba que se pueda determinar la dirección IP del servidor de facturación. Si no es así, el BQN mostrará 0.0.0.0 en el campo «Servidor» del «Estado de facturación». Esto puede deberse a que se desconoce el nombre del servidor o a que el BQN no tiene configurado ningún servidor DNS. Para configurar un servidor DNS, accede a la página de la interfaz de gestión.
- Compruebe que se pueda acceder a la dirección IP de facturación desde el servidor BQN:
Consulta el registro del sistema
Ve a Administración->Registros->Sistema y utiliza la expresión regular «billing».
Si se produce algún problema al conectarse al servidor de facturación, aparecerá un mensaje similar al siguiente:
Si no se encuentra ninguna entrada en el registro del sistema, puedes aumentar su nivel. Acceso al servidor BQN a través de SSH:
Espera un rato y vuelve a mirar en Administración->Registros->Sistema con la expresión regular «billing»:
En este primer ejemplo, una solicitud ha devuelto un error: el código HTTP es 200, pero contiene el código de error de nivel REST RATE_LIMITED.
Y si buscas %ERR-EINVAL:
La BQN se queja de que no puede obtener las «cuentas» del sistema de facturación.
Estos dos registros muestran la causa principal: el problema se debe a que la clave de API ha superado su límite de solicitudes. La solución sería aumentar dicho límite.
Otro ejemplo de error en una solicitud:
En este caso, el sistema de facturación devuelve un código HTTP 401 con el código interno UNAUTHORIZED. Por lo tanto, la causa principal en este otro ejemplo radica en las credenciales de acceso: o bien la clave API o las credenciales complementarias son incorrectas, o bien el BQN está accediendo al sistema de facturación desde una dirección IP no autorizada.
Activar los registros de la API
Si se puede acceder al servidor de facturación y, aun así, la sincronización falla y no se encuentra ninguna entrada en el syslog, profundiza en el análisis activando los registros de la API. Accede al shell del servidor BQN mediante SSH:
Y consulta los registros de la API con el comando:
Un ejemplo de una solicitud correcta (en este caso, una solicitud POST para obtener la matriz «products»):
Y un ejemplo de una solicitud fallida (relacionada con un intento de consultar las «cuentas» de facturación):
Habilitar los registros de la API
Si hemos detectado que hay un problema en una de las solicitudes, podemos averiguar cuál es la que lo está causando activando los rastros de la API. Esto generará un archivo de rastreo por cada solicitud o respuesta.
Accede al shell del servidor BQN mediante SSH:
Además, el BQN generará registros de las últimas 5 solicitudes y 5 respuestas entre el BQN y el sistema de facturación. Estos registros se encuentran en el directorio /opt/bqn/var/trace. Inicia sesión mediante SSH.
Busca una solicitud relacionada con «cuentas»:
Y una vez identificada la solicitud (0001 en este ejemplo), comprueba la respuesta con el mismo ID:
En este caso, el problema se debe a que la clave de la API ha superado su límite de solicitudes. La solución sería aumentar dicho límite.
Interactúa directamente con el servidor de facturación mediante curl
Si aún se desconoce la causa del problema, puedes enviar una solicitud directamente al sistema de facturación utilizando el comando «curl» de Linux. Puedes hacerlo desde un servidor distinto al servidor BQN, a menos que solo se pueda acceder al sistema de facturación desde el BQN. Esta tarea requiere conocimientos especializados sobre el sistema de facturación y las convenciones de las solicitudes de API. Por ejemplo, para enviar una consulta a un sistema de facturación de Azotel:
Servidores NTP no sincronizados
Si el icono de NTP está en amarillo, el NTP no está configurado. Haga clic en el icono para ir a la página de configuración.
Si los servidores NTP están configurados pero el BQN no puede sincronizarse con ninguno de ellos, el icono de NTP en el panel estará en naranja:
Un cambio abrupto en la hora del sistema debido a la falta de sincronización NTP puede provocar breves pérdidas de servicio mientras el sistema se ajusta. Para evitar que esto suceda, tenga siempre al menos un servidor NTP en sincronización.
Puede consultar la lista de servidores NTP configurados en Administración->Fecha del sistema->Servidores NTP.
Debería sincronizarse al menos un servidor NTP. En el ejemplo anterior, se ha elegido el servidor NTP 145.238.203.14 para la sincronización del reloj (indicado por el * junto a la dirección IP del servidor) y se ha contactado hace 36 segundos (columna WHEN).
Si no hay ningún servidor NTP disponible, el BQN mostrará el mensaje de advertencia NTP not synchronized, como en la ventana siguiente:
To solve the issue, if you have a local NTP server, add it to the list clicking the <i class="fa-solid fa-ellipsis-vertical"></i> menu icon and selecting Add Server…
Si no tiene servidores NTP locales, asegúrese de que el puerto UDP 123 esté abierto desde la IP de gestión del BQN a Internet, incluso en el firewall del BQN, si está activado.
Problemas de disco
Para verificar el estado del disco del sistema, haga clic en el icono de DISCO del panel:
El icono del disco se mostrará en naranja (estado de advertencia) cuando quede menos del 15% del almacenamiento del disco.
La tarjeta de red Intel XL710 no alcanza los 40 Gbps de tráfico PPPoE
Una tarjeta de red Intel XL710 que maneja tráfico PPPoE puede estar limitada a un rendimiento de 10 Gbps a pesar de haber negociado un enlace de 40 Gbps. Una posible razón es que la tarjeta no está realizando el balanceo de carga del tráfico PPPoE y los paquetes se entregan a un solo proceso, lo que limita el rendimiento máximo.
La funcionalidad de distribución de paquetes en la tarjeta Intel se implementa mediante Intel Dynamic Device Personalization (DDP). Se deben cumplir tres condiciones:
- El paquete BQN bqnkernel debe ser R3.0.19 o posterior. Requiere un reinicio del sistema después de la instalación del paquete.
- La versión del firmware de la tarjeta debe ser compatible con DDP con balanceo de carga PPPoE (consulte la sección a continuación).
- El paquete BQN bqn debe ser R4.27 o posterior.
Actualización del firmware de la tarjeta de red
El siguiente procedimiento de actualización de firmware solo funciona con tarjetas de red Intel. Las tarjetas de red de proveedores distintos de Intel que utilizan un chipset Intel no se pueden actualizar mediante este procedimiento.
La distribución PPPoE requiere la versión de firmware 7.0 y la versión DDP 1.1.6.1 (en teoría, la versión de firmware 6.01 también funcionaría, pero esto no se ha verificado en nuestro laboratorio).
El siguiente procedimiento implica la interrupción del tráfico y el reinicio del servidor, por lo que el servidor BQN debe retirarse de la ruta de tráfico.
En primer lugar, para verificar la versión del firmware de la tarjeta, los puertos de interfaz XL710 deben ser accesibles por el sistema operativo, es decir, no estar bajo el control de DPDK. Por lo tanto, si alguno de los puertos de interfaz forma parte de un wire, debe colocarse en modo pcap. En la GUI de BQN, vaya a Configuración->Interfaces-> Wires de datos y elimine los wires puertos de esa tarjeta de red y vuelva a crearlos con los puertos en modo pcap.
Una vez hecho esto, las interfaces deberían estar visibles y se puede obtener la versión del firmware utilizando el comando ethtool:
En este ejemplo, la versión del firmware es 5.0 y la tarjeta necesita una actualización. El resto de la sección describe cómo hacerlo.
Para realizar una actualización del firmware, el servidor necesita arrancar para que el kernel del sistema operativo permita dichos cambios. Haga una copia de seguridad del archivo de configuración de grub antes de editarlo:
En la primera entrada del menú, añada iomem=relaxed en la línea linuxboot . La línea tendrá un aspecto similar a este:
Guarde el archivo y reinicie el servidor.
Descargue la herramienta de actualización de Intel para la familia X700 a su PC, descomprímala y transfiera el paquete de Linux al servidor BQN. Ejemplo:
Vaya al servidor BQN para descomprimir el tarball y ejecute la herramienta de actualización:
La herramienta le guiará a través del proceso de actualización del firmware para todas las tarjetas de red X710 detectadas en el sistema.
Después de completar la actualización del firmware, restablezca los wires modo normal (sin pcap). En la interfaz gráfica de usuario de BQN, vaya a Configuración->Interfaces->Cables de datos y elimine los wires los puertos de esa tarjeta de red y vuelva a crearlos con los puertos en modo normal (sin marcar la casilla pcap).
Elimine el parámetro iomem=relaxed del archivo de configuración de grub y reinicie el sistema:
Comprobando que la distribución de carga PPPoE está habilitada
Una vez que el firmware de la red, bqnkernel y los paquetes bqn estén en la versión correcta, la distribución de carga del tráfico PPPoE debería estar habilitada en cada puerto de red XL710 de forma predeterminada. Por ejemplo:
El comando show indica que hay un perfil DDP (para PPPoE) y que la distribución de carga está habilitada.
Deshabilitando la distribución de carga PPPoE
Si hay algún problema con la tarjeta de red y el perfil DDP, el DDP se puede desactivar utilizando el comando no ddp pppoe en todos los puertos de la tarjeta de red, seguido del comando system interface ddp reset en cualquiera de esas interfaces. Por ejemplo:
La interfaz del sistema de comandos ddp reset descarga el perfil DDP sin necesidad de reiniciar el sistema. Tenga en cuenta que basta con aplicarlo a uno de los puertos para restablecer toda la tarjeta de red.
Si el problema persiste, mantenga el comando no ddp pppoe en todos los puertos de la tarjeta de red y realice un reinicio del sistema.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.