Problema
Determinar la fuente de la pérdida de paquetes y por qué ocurre no siempre es fácil. Los paquetes pasan por múltiples redes propiedad de diferentes ISP y organizaciones a través de Internet, y no tienes acceso a cada router en la ruta para verificar cosas como el estado del enlace y la carga de la CPU. Además, la pérdida de paquetes puede ocurrir en cualquier punto a lo largo del camino de la red.
Posibles causas
Hay numerosas razones por las que los paquetes pueden ser descartados en el camino. Algunas razones comunes son:
- Problemas de emparejamiento de ISP
- Congestión del enlace
- Mala configuración (ajustes de ancho de banda o velocidad de NIC y dúplex)
- Fallos de hardware
- Alta CPU en un dispositivo de red
- Manejo de micro-explosiones
Comprendiendo la pérdida de paquetes en Cato
Una buena manera de identificar la pérdida de paquetes en Cato es usar la pantalla de Analytics en la Cato Management Application. Los gráficos de Pérdida de paquetes y Descartados muestran la pérdida de paquetes a lo largo del tiempo y te permiten enfocarte en marcos de tiempo específicos. Estos gráficos son útiles para identificar si la pérdida de paquetes está ocurriendo y cuándo ocurrió en el pasado. Además, puedes identificar el tipo de pérdida de paquetes: pérdida del proveedor o descartado por Cato.
Nota: El tamaño de muestra de cubo de datos más pequeño en los gráficos de Analytics es de 5 segundos. Como resultado, una micro-explosión dentro de 5 ms se normalizará dentro de los promedios mostrados y no se verá como un pico en el gráfico de Analytics.
1. Pérdida del proveedor
Este es un ejemplo de pérdida de paquetes entre el Socket y el PoP. Aunque la mayoría de la pérdida de paquetes del proveedor es causada por problemas de conectividad de red en el último kilómetro fuera del control de Cato, no necesariamente excluye un problema relacionado con Cato.
Cómo Cato mide la pérdida del proveedor
La pérdida del proveedor se mide comparando un conteo de cuántos paquetes son enviados y cuántos son recibidos sobre un enlace determinado tanto en el Socket como en el PoP.
- Pérdida de paquetes downstream es la diferencia entre el número de paquetes enviados por el PoP y el número de paquetes recibidos por el Socket expresado como un porcentaje.
Fórmula:
- Pérdida de paquetes upstream es la diferencia entre el número de paquetes enviados por el Socket y el número de paquetes recibidos por el PoP expresado como un porcentaje.
Fórmula:
La forma en que Cato calcula la pérdida de paquetes del proveedor significa que, por fácil que sea, no se puede culpar de inmediato al ISP. Es posible que tengas equipo entre el Socket y el router del ISP que contribuya a la pérdida de paquetes, o puede haber problemas con la ruta de red más cerca del PoP que está fuera del control del ISP.
2. Descartado por Cato
La pérdida de paquetes descartada por Cato es causada por el Cato QoS. El motor de QoS comienza a descartar paquetes de baja prioridad cuando un enlace está congestionado y en cualquier prioridad durante explosiones de tráfico. La congestión ocurre cuando el total de tráfico de un enlace coincide con el ancho de banda configurado para el enlace. Cato también descarta paquetes si se configura una prioridad de gestión de ancho de banda con un límite de rendimiento estricto y el tráfico que coincide con la prioridad alcanza el límite. La pérdida de paquetes descartada por Cato es un comportamiento esperado y no necesariamente una señal de un problema.
Cualquier problema relacionado con la pérdida de paquetes descartada por Cato probablemente está causado por una mala configuración. Las aplicaciones críticas, como VoIP, deben tener la prioridad de gestión de ancho de banda más alta. Si ocurre congestión, el tráfico de baja prioridad es descartado por Cato, pero el tráfico de alta prioridad no se descarta. Siempre asegúrate de que se asignen las prioridades de gestión de ancho de banda apropiadas al tráfico.
Las analytics proporcionan una vista amplia de la pérdida de paquetes. Sin embargo, a menos que estés manejando la pérdida de paquetes descartada por Cato, las analytics por sí solas no pueden decirte qué está causando la pérdida de paquetes o dónde está ocurriendo.
Cómo solucionar la pérdida de paquetes
1. Determinando el alcance de la pérdida de paquetes
Cuando empiezas, es realmente importante averiguar quién o qué está experimentando la pérdida de paquetes. ¿Todos los usuarios experimentan pérdida de paquetes en un sitio, o está aislado a un solo endpoint? ¿La pérdida de paquetes ocurre sobre Internet o sobre la WAN? ¿Múltiples sitios son afectados por la pérdida de paquetes, o solo uno? ¿Todo el tráfico está afectado, o es solo una cierta aplicación? ¿La pérdida de paquetes es constante, o solo ocurre de manera intermitente?
Conocer las respuestas a las preguntas anteriores puede ayudarte a identificar Eventos de CMA relacionados y ahorrarte tiempo durante el proceso de solución de problemas. Cuantos más detalles sepas de antemano, más enfocado puede ser tu proceso de solución de problemas.
2. Revisando Analytics del sitio - Gráfico de pérdida de paquetes
¿La pérdida de paquetes se muestra en el gráfico de pérdida de paquetes del sitio Analytics? Tenemos diferentes recomendaciones basadas en gráficos de Analytics que pueden mostrar pérdida de paquetes y paquetes descartados.
Sin pérdida de paquetes
Es posible que exista pérdida de paquetes sin que se muestre ninguna pérdida de paquetes en la pantalla de Analytics. Podría haber un problema en la red local, o podría ser un problema relacionado con el PoP. Usar la herramienta de red de UI para hacer ping a una IP del lado LAN desde el Socket puede ser una buena forma de identificar la causa raíz.
Pérdida de paquetes
Si la pérdida de paquetes se muestra en el gráfico, puede ser causada por una mala configuración de BW. Por favor, revisa el ancho de banda configurado como se indica a continuación en Revisando la configuración del ancho de banda.
Para la pérdida de paquetes del proveedor, verifica si las caídas están presentes solo cuando ocurren picos de tráfico (explosiones). Si ese es el caso, identifica el tráfico que causa las explosiones usando la página de Application Analytics. Puedes limitar el tráfico de la aplicación asignándolo a un perfil de gestión de BW restrictivo.
A menudo, veremos casos donde el rendimiento es generalmente bajo, pero los picos de explosión causan pérdida de paquetes. Debemos tener en cuenta que el ISP tiene su propia política de modelado de tráfico, y en tal caso, es probable que la política del ISP y la política de modelado de tráfico de Cato tengan diferentes políticas de explosividad. Para más información sobre explosividad, consulta a continuación Revisando micro-explosiones
3. Revisando Analytics del sitio - Gráfico de paquetes descartados
Para los paquetes descartados por Cato, también debes investigar las prioridades de ancho de banda. Revisa el Analyzer de Prioridades en la pantalla Analytics del sitio para ver qué prioridad está siendo descartada. Puedes expandir la sección de prioridad para mostrar las principales aplicaciones en esa prioridad. Si la pérdida de paquetes solo afecta a una aplicación específica, puede que necesites aumentar la prioridad de esa aplicación en las Reglas de Red. Recuerda, Cato QoS está diseñado para descartar paquetes de baja prioridad cuando ocurre congestión, por lo que la pérdida de paquetes descartada por Cato no siempre es un problema.
Cato QoS también puede descartar cualquier paquete, independientemente de la prioridad, debido a explosiones en esa cola. Este comportamiento también es esperado debido a la naturaleza del manejo de explosiones. La página del Analyzer de Prioridades se puede usar para identificar si ocurren explosiones de tráfico al mismo tiempo que cuando se descartaron los paquetes. Para más información, consulta Priorización y QoS del Tráfico en Socket.
El Analyzer de Prioridades en la pantalla Analytics muestra la pérdida de paquetes en las direcciones upstream y downstream para cada prioridad de QoS.
4. (Opcional) Monitoreo de Experiencia en el Último Tramo
Los clientes con licencia de Monitoreo de Experiencia pueden revisar las pestañas de Último Tramo y Rendimiento de Aplicaciones para posibles pérdidas de paquetes y descartes de paquetes. Los datos pueden correlacionarse con los hallazgos en la página de Analytics de la red del sitio para comprender mejor de dónde se origina el problema.
5. Revisando Analytics del sitio - Pérdida de paquetes en el Último Tramo
Para evaluar si el ISP está experimentando problemas, utiliza la pestaña Último Tramo en la pantalla Analytics para verificar cualquier cambio de latencia o pérdida de paquetes que aparezcan en el enlace WAN. A diferencia de la pérdida de paquetes del proveedor, los datos del último tramo se basan en pruebas ICMP a sitios web populares. Como recomendación, se pueden agregar IPs de servicio adicionales que se puedan hacer ping a la página de monitoreo del Último Tramo. Por ejemplo, si hay problemas relacionados con VoIP, la IP del servidor SIP se puede configurar como una de las IPs.
Si se sospecha de pérdida de paquetes relacionada con el ISP, pregunta a tu ISP las siguientes preguntas:
- ¿Estás aplicando QoS en tráfico UDP/443 o UDP/1337 (DTLS)?
- ¿Aplicas alguna protección DoS en el tráfico UDP que pueda estar causando pérdida de paquetes a la IP del PoP?
- ¿Hay congestión o alta CPU en tus routers en el camino a la IP del PoP?
- ¿Permites explosiones sobre la tasa de línea suscrita?
6. Revisando la configuración del ancho de banda
La pérdida de paquetes puede ser causada por la congestión del enlace, y es importante que el ancho de banda para cada enlace WAN esté configurado correctamente en la Cato Management Application. Asegúrate de que el ancho de banda configurado coincida con lo que el ISP proporciona en la configuración del sitio. Configura el ajuste de ancho de banda de la interfaz WAN del Socket de acuerdo con los términos de la licencia del sitio de Cato.
Los entornos de Azure/AWS no tienen limitaciones de ancho de banda tradicionales. En su lugar, el ancho de banda del sitio configurado nunca debe exceder el ancho de banda compatible para el vSocket. Para Azure, a partir de la versión 21, el tamaño VM Standard_D8ls_v5 admite hasta 2Gbps. En AWS, el tamaño de instancia c5n.xlarge proporciona un ancho de banda superior a 2Gbps. Es importante asegurar que el ancho de banda configurado del sitio se mantenga dentro de los límites compatibles para un rendimiento óptimo.
Si el ancho de banda configurado es menor que lo que el ISP proporciona, el motor QoS de Cato puede comenzar a descartar paquetes cuando se excede el límite de ancho de banda configurado. Si este es el caso, hay una línea plana a lo largo del gráfico de rendimiento de Analytics del sitio igual al ancho de banda configurado del sitio junto con los paquetes descartados de Cato.
Este mismo comportamiento puede ocurrir si el ancho de banda está configurado correctamente, pero el enlace del ISP está congestionado. Aunque este comportamiento no garantiza un problema, es una buena práctica confirmar que el ancho de banda está configurado correctamente en esta situación.
Si el ancho de banda configurado es mayor que lo que el ISP proporciona, el motor QoS de Cato no se activa cuando se excede el límite de ancho de banda del ISP, y por lo tanto, el ISP puede comenzar a descartar paquetes aleatoriamente. Si este es el caso, se ve una línea plana a lo largo del gráfico de rendimiento de Analytics del sitio por debajo del nivel del ancho de banda configurado junto con la pérdida de paquetes del proveedor.
La información de rendimiento y capacidad de Socket por cada modelo de Socket está disponible en la hoja de datos de Socket, consulta este artículo: Guías de Socket X1700, X1600 & X1500.
7. Revisa el rendimiento del CPU del Socket
Desde la WebUI del Socket, selecciona la pestaña de Estado de HW. Esto mostrará el uso actual de la CPU % para cada núcleo. Una utilización de CPU consistente por encima del 90% impactará directamente el rendimiento del Socket y causará pérdida de paquetes y alta latencia. Si se observa un alto uso constante de CPU mientras ocurre pérdida de paquetes en la red, por favor Contacta con Soporte.
8. Descartar reconexiones en el sitio
Las reconexiones del sitio a Cato Cloud son una fuente de pérdida de paquetes. Revisa Inicio > Eventos para ver si la pérdida de paquetes se correlaciona con los eventos de reconexión. Filtra eventos como sub-tipo = 'reconectado'.
Los eventos de reconexión mostrarán un mensaje explicando la razón de las desconexiones. Consulta Comprender Eventos Reconectados
9. Saltándose Cato
Para pérdida de paquetes por Internet, configura un bypass de origen o destino para descartar rápidamente un problema con Cato Cloud. La forma más fácil de hacer esto es configurar un bypass de origen para la dirección IP de un solo usuario en la configuración del sitio y ver si la pérdida de paquetes continúa. Si la pérdida de paquetes continúa, el problema podría estar en la LAN, el Socket, o el ISP, pero el problema no estaría relacionado con un PoP.
10. Realizando pruebas de Ping
Inicia un ping continuo entre una dirección IP de origen y destino que esté afectada por la pérdida de paquetes. Los pings son más fáciles de rastrear y se pueden analizar en capturas de paquetes. Cuando algunas de las solicitudes de ping no llegan a su destino, probablemente estés experimentando pérdida de paquetes y se mostrará como tiempo de espera de solicitud.
La UI del Socket también te permite hacer ping por nombre de host o IP con la herramienta de ping. Puedes seleccionar la interfaz por la que deseas enviar el ping, ya sea a través de Cato o directamente a través del enlace WAN. Busca cualquier inconsistencia en los resultados del ping, como pérdida de paquetes o alta latencia. Si hay pérdida de paquetes con y sin Cato, puede indicar un problema con el ISP. Además, si uno de los enlaces es 4G/LTE, debes recordar que esos enlaces son más sensibles a la pérdida de paquetes.
La UI solo envía 10 solicitudes de ping, así que si necesitas más pings tendrás que hacer clic en el botón Ping de nuevo.
Nota: Las pruebas de ping son buenas para verificar la salud básica de la red, pero la ausencia de caídas de ping no necesariamente indica una línea limpia.
11. Ejecutando pruebas de Traceroute
Traceroute se usa para identificar los routers (saltos) entre una fuente y un destino. Mostrará pérdida de paquetes y latencia para cada uno de los saltos.
Traceroute se puede ejecutar desde la UI del Socket con la herramienta de Traceroute. Ejecuta Traceroute para encontrar cualquier pérdida de paquetes o latencia inesperadamente alta en cualquiera de los saltos sobre el enlace WAN entre el socket y el destino. La UI solo envía un paquete para cada salto y muestra la pérdida de paquetes para cada salto. Dado que solo se envía un paquete, solo verás una pérdida del 0% o del 100%.
Análisis de resultados de Traceroute
Ten en cuenta que la pérdida de paquetes mostrada en cualquier salto individual no es necesariamente una señal de problema. Un solo salto podría mostrar una pérdida de paquetes del 100% simplemente porque el ICMP no está habilitado en el router. Un salto también puede mostrar menos del 100% de pérdida de paquetes sin que haya un problema debido a la limitación de tasas de ICMP. Si ves alguna pérdida de paquetes en un salto y 0% de pérdida de paquetes en el siguiente salto, es probable que estés presenciando una limitación de tasa de ICMP.
Si hay un problema real con la pérdida de paquetes, comenzará en un salto y continuará por varios saltos, con cada salto mostrando pérdida de paquetes. También es posible que múltiples routers en un camino estén contribuyendo a la pérdida de paquetes, por lo que la cantidad de pérdida de paquetes puede variar en cada salto. Por ejemplo, hay ocho saltos en la ruta y Traceroute muestra pérdida de paquetes para los saltos 3-7.
12. Generando alta carga de tráfico para detectar pérdida de paquetes
La pantalla de Tiempo Real puede ayudar a detectar cualquier cambio de rendimiento actual para identificar pérdida de paquetes inmediata y paquetes descartados. Usa la herramienta de prueba de velocidad del Socket para simular alta carga y reproducir pérdida de paquetes debido a alta demanda durante la resolución de problemas.
Los resultados de la Speedtest del Socket a través de Cato se espera que estén cerca del ancho de banda configurado para el enlace en la Cato Management Application. Ten en cuenta que la sobrecarga del túnel DTLS (117 bytes) puede reducir ligeramente el rendimiento.
La prueba saturará el enlace y mostrará cualquier pérdida de paquetes relacionada con el ISP en la pantalla de Network Analytics. Se esperan paquetes descartados al ejecutar la prueba si el ancho de banda configurado del enlace es menor que el ancho de banda proporcionado por el ISP.
Prueba de velocidad directa
Al ejecutar la prueba de velocidad directamente a través del puerto WAN, el resultado ascendente debería estar cerca de la licencia de ancho de banda configurada en la Cato Management Application. El Socket aún usará QoS para la prueba de velocidad directa ascendente según la licencia de ancho de banda del site. Por otro lado, el resultado descendente mostrará la capacidad total del ISP local.
13. Probando el enlace con iPerf
La Socket WebUI te permite usar la herramienta iPerf para resolver problemas de rendimiento de última milla entre el Socket y el PoP conectado en el Cato Cloud. El Socket que está ejecutando el cliente iPerf realiza la prueba contra el servidor iPerf que está ejecutándose en el PoP conectado.
Ejecuta la prueba iPerf a través de Cato y directamente sobre el WAN desde la página de herramientas de la UI del socket. Selecciona UDP como protocolo (para descartar el control de flujo TCP), establece la dirección (ascendente o descendente) y la tasa de objetivo como el ancho de banda configurado. Esta herramienta puede confirmar mejor que el rendimiento sobre Cato y sobre el WAN es como se espera. Ten en cuenta que la sobrecarga del túnel DTLS (117 bytes) puede reducir ligeramente el rendimiento.
En el siguiente ejemplo, estamos estableciendo 45Mbps como la tasa de objetivo (que es el mismo ancho de banda configurado en la Cato Management Application) y la tasa recibida es más baja de lo esperado con una pérdida de paquetes del 3,7%
14. Verificando enlaces de Agregación de Enlaces (LAG)
La pérdida de paquetes y la alta latencia pueden deberse a una configuración incorrecta de Link Aggregation (LAG) entre el Socket y un switch interno. Este problema en particular no puede ser detectado en Network Analytics, sino que necesita ser resuelto dentro del LAN. Cato solo admite LAG estático y el par LAG debe admitir el mismo modo. Las discrepancias de configuración de LAG llevarán a una pérdida de paquetes.
Para más información sobre la resolución de problemas, ve a Enlace de Agregación de Enlaces (LAG) Experimentando Alta Latencia y Pérdida de Paquetes
15. Verificando la velocidad del enlace del Socket
Una posible causa de la pérdida del proveedor es que un enlace del Socket está funcionando a media dúplex. Esto significa que los paquetes solo pueden viajar en una dirección (saliente o entrante) a la vez, lo que reduce drásticamente el rendimiento y resulta en pérdida de paquetes. Todos los enlaces del Socket siempre deben estar a dúplex completo sin excepción.
Además, asegúrate de que tanto las velocidades de enlace WAN como LAN sean iguales o superiores al ancho de banda configurado para un site. La velocidad del enlace puede ser el factor limitante para el rendimiento. Por ejemplo, si el ancho de banda configurado de un site es de 200 Mbps pero el enlace LAN solo ha negociado a 100 Mbps dúplex completo, una computadora conectada al Socket no puede alcanzar más de 100 Mbps de rendimiento.
Para verificar el estado del enlace, inicia sesión en la UI del Socket y ve el estado del Enlace en la página de Monitor. El ejemplo a continuación muestra el enlace WAN1 a 100 Mbps a media dúplex.
Si notas un enlace a media dúplex o configurado a la velocidad incorrecta, verifica la configuración del puerto en el dispositivo al que el enlace del Socket está conectado. Asegúrate de que esté configurado para auto-negociación o que coincida con la configuración de velocidad del Socket. Todos los enlaces del Socket están configurados por defecto a auto-negociación, pero puedes forzar la velocidad en la página de Configuración de Red.
Si la configuración del puerto es correcta en el otro dispositivo, el cable Ethernet podría estar dañado. Reemplaza el cable por uno que sea seguro y verifica si el dúplex o velocidad cambian. Si eso no funciona, conecta una computadora portátil u otro dispositivo al puerto del Socket y verifica el estado del enlace. Haz lo mismo en el otro dispositivo. Si el enlace del Socket alcanza la velocidad esperada y dúplex completo pero el enlace del otro dispositivo no lo hace, sabrás que el problema está en el otro dispositivo.
16. Verificando IPs duplicadas
Otro problema a nivel del Socket que puede causar pérdida de paquetes es tener IPs duplicadas en la red. El Socket generalmente puede detectar conflictos de IP con sus direcciones IP de interfaz configuradas. Existe un conflicto de IP cuando dos dispositivos en la misma red tienen asignada la misma dirección IP. Si esto ocurre, verás el siguiente error en la página de Monitor de la UI del Socket.
El IP duplicado puede no detectarse cuando se configura una dirección IP estática en la interfaz WAN, ya que el Socket solo monitoriza pasivamente en busca de un conflicto de IP. Solo detectará un conflicto de IP si el Socket recibe un ARP del dispositivo con el IP en conflicto.
Una vez resuelto el problema de IP en conflicto, puede tardar hasta 24 horas en desaparecer la advertencia de la WebUI. Ver Conflicto de Dirección IP Reportado en la UI del Socket Incluso Después de Resuelto
17. Verificando micro-explosiones
Otra posible causa de pérdida de paquetes son las micro-explosiones (burstiness). Las micro-explosiones se caracterizan por un aumento repentino de paquetes o tramas de datos que ocurren dentro de un periodo de tiempo muy corto, típicamente durando solo unos pocos microsegundos a milisegundos. En situaciones donde ocurren micro-explosiones y superan el límite de tasa del enlace, el proveedor de Última Milla (ISP) puede descartar el tráfico excesivo, resultando en pérdida de paquetes.
En el gráfico a continuación, puedes ver un ejemplo de pérdida de paquetes típica causada por micro-explosiones y la mejora después de ajustar la configuración del valor de burstiness.
En el ejemplo anterior, el valor del nivel de burstiness se modificó desde el valor predeterminado de 0,2 a 0,01, lo que significa que el Socket y el PoP aplican un modelado más agresivo en el tráfico, resolviendo así el problema de pérdida de paquetes.
Ajustando configuraciones de nivel de burstiness para mitigar la pérdida de paquetes
El valor de burstiness predeterminado aplicado para las direcciones ascendentes y descendentes es 0,2. Con este valor, el Socket y el PoP serializan los paquetes al medio lo más rápido posible, permitiendo que se envíen más bytes en los primeros microsegundos del cubo de tiempo del periodo. Esta configuración optimiza el rendimiento reduciendo el retraso de serialización y la latencia general.
Como parte de este paso de resolución de problemas, necesitas reducir gradualmente el nivel de burstiness hasta que se mitigue la pérdida de paquetes. A medida que reduces el valor del nivel de burstiness, el Socket y el PoP aplican un modelado más agresivo en el tráfico, suavizando así las micro-explosiones. El valor más bajo que puedes configurar es 0,001.
La mejor práctica para ajustar el nivel de burstiness es reducir gradualmente el valor (por ejemplo, de 0,2 a 0,18). Después de reducir el valor, monitorea el impacto analizando la pérdida de paquetes en las pantallas de Tiempo Real o Network Analytics del Monitoreo del Site. Ten en cuenta que las métricas del site generalmente tardan unos minutos en actualizarse. Continúa reduciendo el valor de burstiness hasta que se mitigue la pérdida de paquetes.
Si la pérdida de paquetes no se resuelve con este procedimiento, significa que se debe a una razón diferente a las micro-explosiones. En ese caso, restaura el valor predeterminado de burstiness de 0,2 y Contacta Soporte para obtener más asistencia.
Modificando el nivel de Burstiness
El nivel de burstiness puede ajustarse para las direcciones ascendentes y descendentes. Esta configuración afecta a todos los enlaces WAN del site.
La configuración se aplica a nivel de site o a nivel de cuenta. La configuración a nivel de site tiene prioridad sobre la de nivel de cuenta.
Para configurar el nivel de Burstiness:
- Desde el menú de navegación, selecciona Recursos > Configuración Avanzada para la configuración de nivel de cuenta o Configuración del Site > Configuración Avanzada para la configuración de nivel de site.
- Selecciona valor de burstiness descendente o valor de burstiness ascendente.
- Habilita la configuración y ajusta el valor entre el rango de 0,001 - 0,2.
- Haz clic en Aplicar
- Haz clic en Guardar
Notas:
- Si el burstiness fue previamente ajustado por el Soporte de Cato, se mostrará el valor ajustado en lugar del valor predeterminado de 0,2
- Los valores de burstiness solo se pueden ajustar para los sites Socket
- El cubo de datos más pequeño en la Cato Management Application es 5 segundos, las micro-explosiones se normalizan dentro de los cubos de datos más pequeños y son generalmente difíciles de identificar.
0 comentarios
Inicie sesión para dejar un comentario.