El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento incluye preguntas frecuentes y situaciones de solución de problemas que los usuarios pueden encontrar mientras trabajan con el agente en la nube CX.
R. Sí, para algunos escenarios de implementación específicos se espera la redirección a cloudfront.net. Se debe permitir el acceso sin conexión con la redirección habilitada en el puerto 443 para estos FQDN.
A. Sí
A. OVA y VHD
A. Para OVA
Para VHD
R. Sí, se detecta la asignación de dirección IP durante la configuración IP. Sin embargo, no se admite el cambio de dirección IP que se espera para el agente en la nube de CX en el futuro. Se recomienda que los clientes reserven la IP para el agente en la nube CX en su entorno DHCP.
R. No, sólo se admite IPV4.
R. Sí, se validan la sintaxis de la dirección IP y la asignación de dirección IP duplicada.
R.La implementación de OVA depende de la velocidad de la red que copia los datos. La configuración IP tarda aproximadamente de 8 a 10 minutos, incluidas las creaciones de contenedores y Kubernetes.
R. La máquina host en la que se implementa OVA debe cumplir los requisitos proporcionados como parte de la configuración del portal CX. El agente en la nube CX se prueba con VMware/Virtual Box en un hardware con procesadores Intel Xeon E5 con una relación vCPU/CPU de 2:1. Si se utiliza una CPU de procesador menos potente o una proporción mayor, el rendimiento puede disminuir.
R. No, el código de emparejamiento solo se puede generar cuando el agente en la nube CX no está registrado.
R.El ancho de banda no supone una limitación cuando el agente en la nube CX y Cisco DNA Center se encuentran en la misma red LAN/WAN en el entorno del cliente. El ancho de banda de red mínimo requerido es de 2,7 Mbit/s para las colecciones de inventario de 5000 dispositivos +13000 Puntos de acceso para una conexión de agente a Cisco DNA Center. Si se recopilan registros del sistema para obtener información de nivel 2, el ancho de banda mínimo necesario es de 3,5 Mbits/seg. para cubrir 5000 dispositivos +13000 puntos de acceso para inventario, 5000 dispositivos registros del sistema y 2000 dispositivos para análisis; todos se ejecutan en paralelo desde CX Cloud Agent.
R. Se puede acceder a los registros del sistema para la VM del agente desde el inicio de sesión de la VM local mediante las dos rutas siguientes:
/var/log/syslog.1 (al que se accede a través de los inicios de sesión de cxcadmin y cxcroot)
/var/log/syslog (al que se accede mediante root)
R. Aquí se muestra el conjunto de versiones lanzadas de CX Cloud Agent que se enumeran:
donde A es una liberación a largo plazo distribuida en 3-5 años.
R. Para localizar y actualizar al agente en la nube CX más reciente:
A. cxcadmin.
R. Las contraseñas se establecen durante la configuración de la red.
R. El agente en la nube de CX no proporciona ninguna opción específica para restablecer la contraseña, pero puede utilizar los comandos de Linux para restablecer la contraseña de cxcadmin.
A. Las políticas de contraseña son:
A. Para confirmar la disponibilidad de SSH:
Iptables -A OUTPUT -p tcp -m tcp —dport 22 -j ACCEPT
Para desactivar los puertos SSH activados anteriormente en el agente en la nube CX:
iptables -L OUTPUT —line-number | grep dpt | grep ssh | awk '{print $1}'
iptables -L OUTPUT <Line number>
A. Para confirmar el alcance SNMP:
iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT
iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT
snmpwalk -v2c -c cisco IPADDRESS
Para desactivar los puertos SNMP activados anteriormente en el agente en la nube CX:
iptables -L OUTPUT —line-number | grep dpt | grep ssh | awk '{print $1}'
iptables -L OUTPUT <Line number2 Number>
iptables -L OUTPUT <Line number1 Number>
A. Para establecer la contraseña de Grub:
R. La contraseña caduca en 90 días.
R. Sí, la cuenta se inhabilita después de cinco (5) intentos fallidos consecutivos. El periodo de bloqueo es de 30 minutos.
A. Para generar una frase de contraseña:
R. Sí, pero para utilizar el nombre de host, el usuario debe proporcionar la dirección IP del servidor de nombres de dominio (DNS) durante la configuración de la red.
R. Se admiten los siguientes cifrados:
A. Para iniciar sesión:
R. Sí, se registran como parte del archivo "var/logs/audit/audit.log".
R. El tiempo de espera de la sesión SSH se produce si el agente en la nube CX permanece inactivo durante cinco (5) minutos.
R. Están disponibles los siguientes puertos:
AMÉRICA |
EMEA |
Asia Pacífico, Japón y China |
cloudsso.cisco.com |
cloudsso.cisco.com |
cloudsso.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
api-cx.cisco.com |
agent.us.csco.cloud |
agent.emea.cisco.cloud |
agent.apjc.cisco.cloud |
ng.acs.agent.us.csco.cloud |
ng.acs.agent.emea.cisco.cloud |
ng.acs.agent.apjc.cisco.cloud |
Nota: además de los dominios enumerados, cuando los clientes de EMEA o APJC reinstalen el agente en la nube CX, se debe permitir el dominio agent.us.csco.cloud en el firewall del cliente.
El dominio agent.us.csco.cloud ya no es necesario después de una reinstalación correcta.
Nota: Asegúrese de que se permita el tráfico de retorno en el puerto 443.
Inbound port: para la gestión local de CX Cloud Agent, se debe poder acceder a 514 (Syslog) y 22 (ssh). Los clientes deben permitir que el puerto 443 de su firewall reciba datos de CX Cloud.
Conexión del agente en la nube CX con Cisco DNA Center y otros recursos
P. ¿Cuál es el propósito y la relación de Cisco DNA Center con CX Cloud Agent?
R. Cisco DNA Center es el agente en la nube que gestiona los dispositivos de red de las instalaciones del cliente. CX Cloud Agent recopila la información de inventario del dispositivo desde el Cisco DNA Center configurado y carga la información de inventario disponible en Asset View de CX Cloud.
P. ¿Dónde pueden los usuarios proporcionar los detalles de Cisco DNA Center sobre el agente en la nube CX?
R. Durante el Día 0 - Configuración de CX Cloud Agent, los usuarios pueden agregar los detalles de Cisco DNA Center desde el portal de CX Cloud. Durante las operaciones del día N, los usuarios pueden añadir Cisco DNA Centers adicionales desde
Admin Settings > Data Source.
P. ¿Cuántos Cisco DNA Centers se pueden agregar?
R. Se pueden agregar diez (10) clústeres de Cisco DNA Center o 20 clústeres no pertenecientes a Cisco DNA Center.
P. ¿Cómo elimino un Cisco DNA Center conectado de CX Cloud Agent?
R. Para quitar un Cisco DNA Center conectado de CX Cloud Agent, póngase en contacto con el Technical Assistance Center (TAC) para abrir un caso de soporte desde el portal de CX Cloud.
P. ¿Qué función puede tener el usuario de Cisco DNA Center?
R. El rol de usuario puede ser admin u Observer.
P. ¿Cómo se reflejan las modificaciones en CX Cloud Agent debido a los cambios en las credenciales del DNA Center conectado?
A. Ejecute el comando cxcli agent modifyController desde la consola de CX Cloud Agent:
Póngase en contacto con el soporte técnico para cualquier problema durante la actualización de credenciales de Cisco DNA Center.
P. ¿Cómo se almacenan los detalles de Cisco DNA Center y de los recursos de archivos simiente en CX Cloud Agent?
R. Todos los datos, incluidas las credenciales de los controladores conectados a CX Cloud Agent (por ejemplo, Cisco DNA Center) y los activos conectados directamente (por ejemplo, mediante un archivo simiente o un intervalo de IP), se cifran mediante AES-256 y se almacenan en la base de datos de CX Cloud Agent, que está protegida con una ID de usuario y una contraseña seguras.
P. ¿Existe alguna limitación a la hora de introducir rangos de IP al añadir otros activos?
R. Sí, el agente en la nube de CX no puede gestionar las operaciones de detección para rangos de IP de subred más grandes. Cisco recomienda utilizar rangos de subred minimizados limitados a 10 000 direcciones IP.
P. ¿Se puede utilizar una subred pública para la implementación de CX Cloud Agent v2.4 para la subred personalizada de servicios y el clúster?
R. Cisco no recomienda el uso de una subred de IP pública por los siguientes motivos:
- Riesgos de seguridad: las direcciones IP públicas exponen el clúster y los servicios a Internet, lo que aumenta el riesgo de acceso no autorizado, ataques y posibles violaciones de datos.
- Conflictos de direcciones IP: el uso de subredes IP públicas puede provocar conflictos de IP, especialmente si se asignan las mismas direcciones IP en otro lugar de Internet, lo que provoca problemas de conectividad y comportamientos inesperados.
- Complejidad en la configuración de red: la gestión de políticas de red, reglas de firewall y routing se vuelve más compleja cuando se trata de direcciones IP públicas. Esto puede dar lugar a errores de configuración y aumentar los gastos de mantenimiento.
Una subred IP pública se puede utilizar si está asignada únicamente a una organización del cliente y configurada a través de la red del cliente.
P. ¿Con qué frecuencia se puede iniciar la operación de redescubrimiento?
R. La operación de redescubrimiento sólo se debe realizar si hay un cambio en la red del cliente (por ejemplo, después de agregar o eliminar dispositivos dentro de la red).
P. ¿Cuál es el flujo de trabajo para agregar "Otros activos como origen de datos" al cargar un archivo simiente?
R. El flujo de trabajo es el siguiente:
- Cargue el archivo simiente en CX Cloud.
- El archivo simiente se almacena temporalmente en la cubeta de Cisco Cloud AWS S3 (con la encriptación SSE habilitada).
- El archivo simiente se envía al agente de nube CX y el archivo simiente se elimina de la cubeta S3
- El agente en la nube de CX procesa las entradas del archivo simiente y cifra las credenciales mediante una clave AES 256 (esta clave es única para cada agente en la nube de CX). Estas credenciales cifradas se almacenan en la base de datos de agentes en la nube de CX.
- El archivo simiente se elimina del agente de nube CX una vez que se procesan las entradas del archivo simiente.
P. ¿Qué tipo de cifrado se utiliza al acceder a la API de Cisco DNA Center desde CX Cloud Agent?
A. HTTPS sobre TLS 1.2 se utiliza para la comunicación entre Cisco DNA Center y CX Cloud Agent.
P. ¿Qué operaciones realiza CX Cloud Agent en el Cisco DNA Center Cloud Agent integrado?
R. El agente en la nube de CX recopila datos del centro de DNA de Cisco sobre los dispositivos de red y utiliza la interfaz de ejecución de comandos del centro DNA de Cisco para comunicarse con los dispositivos finales y ejecutar los comandos CLI (comando show). No se ejecutan comandos de cambio de configuración.
P. ¿Qué datos predeterminados se recopilan de Cisco DNA Center y se cargan en el back-end?
A.
- Entidad de red
- Módulos
- show version
- Config
- Información de imagen del dispositivo
- Etiquetas
P. ¿Qué datos adicionales se recopilan de Cisco DNA Center y se cargan en el back-end de Cisco?
R. Consulte este documento para obtener más información.
P. ¿Cómo se cargan los datos de inventario en el backend?
R. El agente de nube CX carga los datos de inventario a través del protocolo TLS 1.2 en el servidor backend de Cisco.
P. ¿Cuál es la frecuencia de carga del inventario?
R. La recopilación se activa según la programación definida por el usuario y se carga en el servidor de Cisco.
P. ¿Puede el usuario volver a programar el inventario?
R. Sí, hay una opción disponible en Centro de administración > Orígenes de datos para modificar la información de programación.
P. ¿Cuándo se produce el tiempo de espera de conexión entre Cisco DNA Center y Cloud Agent?
A. Los tiempos de espera se categorizan de la siguiente manera:
- Para la conexión inicial, el tiempo de espera máximo es de 300 segundos. Si no se establece la conexión entre Cisco DNA Center y Cloud Agent en un máximo de cinco (5) minutos, la conexión finaliza.
- Para actualizaciones recurrentes, típicas o periódicas: el tiempo de espera de respuesta es de 1800 segundos. Si no se recibe la respuesta o no se puede leer en 30 minutos, la conexión finaliza.
Análisis de diagnóstico de CX Cloud Agent utilizado
P. ¿Qué comandos de escaneo se ejecutan en el dispositivo?
R. Los comandos que deben ejecutarse en el dispositivo para el análisis se determinan dinámicamente durante el proceso de análisis. El conjunto de comandos puede cambiar con el tiempo, incluso para el mismo dispositivo (y que no esté bajo el control del Análisis de diagnóstico).
P. ¿Dónde se almacenan y se perfilan los resultados del análisis?
R. Los resultados escaneados se almacenan y perfilan en el backend de Cisco.
P. ¿Los duplicados (por nombre de host o IP) en el Centro de ADN de Cisco, se agregan al Análisis de diagnóstico cuando el origen del Centro de ADN de Cisco está conectado?
R. No, los duplicados se filtran de manera que solo se extraen los dispositivos únicos.
P. ¿Qué sucede cuando falla uno de los escaneos de comando?
R. El escaneo del dispositivo se detiene por completo y se marca como fallido.
P. ¿Qué sucede cuando los escaneos múltiples se superponen?
R. La ejecución simultánea de varias exploraciones de diagnóstico puede ralentizar el proceso de exploración y provocar posibles errores de exploración. Cisco recomienda programar análisis de diagnóstico o iniciar análisis bajo demanda con un intervalo de al menos 6-7 horas entre las programaciones de recopilación de inventario para que no se superpongan.
Registros del sistema de agentes en la nube CX
P. ¿Qué información de estado se envía al portal de la nube de CX?
R. Registros de aplicaciones, estado de Pod, detalles de Cisco DNA Center, registros de auditoría, detalles del sistema y detalles de hardware.
P. ¿Qué detalles del sistema y del hardware se recopilan?
A. Ejemplo de resultado:
detalles_del_sistema":{
"os_details":{
"containerRuntimeVersion":"docker://19.3.12",
"kernelVersion":"5.4.0-47-generic",
"kubeProxyVersion":"v1.15.12",
"kubeletVersion":"v1.15.12",
"machineID":"81edd7df1c1145e7bcc1ab4fe778615f",
"operatingSystem":"linux",
"osImage":"Ubuntu 20.04.1 LTS",
"systemUUID":"42002151-4131-2ad8-4443-8682911bdadb"
},
"hardware_details":{
"total_cpu":"8",
"cpu_utilization":"12.5%",
"total_memory":"16007MB",
"free_memory":"994 MB",
"hdd_size":"214G",
"free_hdd_size":"202G"
}
}
}
P. ¿Cómo se envían los datos de salud al backend?
R. Con CX Cloud Agent, el servicio de mantenimiento transfiere los datos al servidor de Cisco.
P. ¿Cuál es la política de retención de registros de datos de estado del agente en la nube de CX en el backend?
R. La política de retención de datos de estado del agente en la nube de CX en el backend es de 120 días.
P. ¿Qué tipos de cargas están disponibles?
A.
- Carga del inventario
- Carga de Syslog
- Carga de estado del agente, incluida la carga de estado
- Estado de los servicios: cada cinco (5) minutos
- Podlog - Cada una (1) hora
- Registro de auditoría: cada una (1) hora
Resolución de problemas
Problema: no se puede acceder a la dirección IP configurada.
Solución: ejecute ssh utilizando la IP configurada. Si se agota el tiempo de espera de la conexión, la razón posible es una configuración incorrecta de IP. En este caso, reinstale configurando una dirección IP válida. Esto se puede hacer a través del portal con la opción de reinstalación proporcionada en la
Admin Centerpágina.
Problema: ¿cómo puedo comprobar que los servicios están en funcionamiento tras el registro?
Solución: siga estos pasos para confirmar que los grupos de dispositivos están en funcionamiento:
- ssh a la IP configurada como cxcadmin
- Proporcione la contraseña
- Ejecute el comando kubectl get pods
Los grupos de dispositivos pueden estar en cualquier estado (En ejecución, Inicializando o Creando contenedor). Después de 20 minutos, las vainas deben estar en el estado En ejecución.
Si el estado es no se está ejecutando o Pod Inicializando, verifique la descripción del pod con el comando kubectl describe pod <podname> .
El resultado tendrá información sobre el estado del grupo de dispositivos.
Problema: ¿Cómo verificar si el interceptor SSL está inhabilitado en el proxy del cliente?
Solución: ejecute el comando curl que se muestra aquí para verificar la sección del certificado del servidor. La respuesta tiene los detalles del certificado del servidor web concsoweb.
curl -v —header 'Autorización: básica xxxxxx' https://concsoweb-prd.cisco.com/
* Certificado de servidor:
* subject: C=US; ST=California; L=San José; O=Cisco Systems, Inc.; CN=concsoweb-prd.cisco.com
* fecha de inicio: 16 de febrero 11:55:11 2021 GMT
* fecha de caducidad: 16 de febrero 12:05:00 2022 GMT
* subjectAltName: el host "concsoweb-prd.cisco.com" coincidió con "concsoweb-prd.cisco.com" de cert
* emisor: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID SSL, CA G3
* Certificado SSL verificado de acuerdo.
> GET / HTTP/1.1
Problema: los comandos kubectl fallaron y muestra el error como "La conexión al servidor X.X.X.X:6443 fue rechazada - ¿especificó el host o puerto correcto?"
Solución:
- Compruebe la disponibilidad de los recursos. [ejemplo: CPU, Memoria].
- Espere a que comience el servicio Kubernetes.
Problema: ¿Cómo obtener los detalles de la falla de recolección para un comando/dispositivo?
Solución:
- Ejecute
kubectl get pods y obtenga el nombre del grupo de dispositivos de recopilación.
- Ejecute
kubectl logs <collectionPodName> para obtener los detalles específicos del comando/dispositivo.
Problema: el comando kubectl no funciona con el error "[authentication.go:64] No se puede autenticar la solicitud debido a un error: [x509: el certificado ha caducado o aún no es válido, x509: el certificado ha caducado o aún no es válido]"
Solución:Ejecute los comandos que se muestran aquí como usuario cxcroot
rm /var/lib/rancher/k3s/server/tls/dynamic-cert.json
systemctl restart k3s
kubectl —insecure-skip-tls-verify=true delete secret -n kube-system k3s-serve
systemctl restart k3s
Respuestas de fallos de recopilación
La causa de la falla de recolección puede ser cualquier restricción o problema que se observe con el controlador o los dispositivos agregados presentes en el controlador.
La tabla que se muestra aquí tiene el fragmento de error para los casos prácticos vistos en el microservicio de recopilación durante el proceso de recopilación.
caso de uso |
Fragmento de registro en microservicio de recopilación |
Si el dispositivo solicitado no se encuentra en Cisco DNA Center |
{ |
Si el dispositivo solicitado no es accesible desde Cisco DNA Center |
{ |
Si el dispositivo solicitado no es accesible desde Cisco DNA Center |
{ |
Si el comando solicitado no está disponible en el dispositivo |
{ |
Si el dispositivo solicitado no tiene SSHv2 y Cisco DNA Center intenta conectar el dispositivo con SSHv2 |
{ |
Si el comando está deshabilitado en el microservicio de recopilación |
{ |
Si el Command Runner Task falló y la URL de la tarea no es devuelta por Cisco DNA Center |
{ |
Si la tarea Command Runner no se pudo crear en el centro de DNA de Cisco |
{ |
Si el microservicio de recopilación no recibe una respuesta para una solicitud de Command Runner de Cisco DNA Center |
{ |
Si Cisco DNA Center no está completando la tarea dentro del tiempo de espera configurado (5 minutos por comando en el microservicio de recopilación) |
{ |
Si la tarea Command Runner Task falló y el ID de archivo está vacío para la tarea enviada por Cisco DNA Center |
{ |
Si la tarea Command Runner Task falló y Cisco DNA Center no devuelve la etiqueta de ID de archivo |
{ |
Si el dispositivo no es apto para la ejecución del ejecutor de comandos |
{ |
Si el ejecutor de comandos está deshabilitado para el usuario |
{ |
Respuestas de error de análisis de diagnóstico
Los fallos de análisis y las causas pueden provenir de cualquiera de los componentes enumerados.
Cuando los usuarios inician un análisis desde el portal, ocasionalmente se muestra como "error: error interno del servidor".
La causa del problema es uno de los componentes enumerados
- Punto de control
- Gateway de datos de red
- Conector
- Análisis de diagnóstico
- CX Cloud Agent Microservice [administrador de dispositivos, recopilación]
- Cisco DNA Center
- APIX
- Mashería
- Ping Access
- BANCO DE HIERRO
- IRONBANK GW
- Big Data Broker (BDB)
Para ver los registros:
- Inicie sesión en la consola de CX Cloud Agent.
- Ejecutar
kubectl get pods .
- Obtenga el nombre de la recopilación, el conector y la facilidad de mantenimiento del grupo de dispositivos.
- Para comprobar los registros de microservicios de recopilación, conector y mantenimiento.
- Ejecutar
kubectl logs <collectionpodname>
- Ejecutar
kubectl logs <connector>
- Ejecutar
kubectl logs <servicability>
La tabla siguiente muestra el fragmento de error que se ve en los registros de microservicio de recopilación y microservicio de mantenimiento que se produce debido a problemas o restricciones con los componentes.
Caso de uso |
Fragmento de registro en microservicio de recopilación |
El dispositivo puede ser accesible y compatible, pero los comandos que se ejecutan en ese dispositivo se enumeran en bloques en el microservicio de recopilación |
{ |
Si el dispositivo para un análisis no está disponible. Se produce en un escenario, cuando hay un problema de sincronización entre los componentes, como el portal, la exploración de diagnóstico, el componente CX y el centro de DNA de Cisco |
No se ha encontrado ningún dispositivo con id 02eb08be-b13f-4d25-9d63-eaf4e882f71a |
Si el dispositivo que se intenta escanear está ocupado, (en un escenario) en el que el mismo dispositivo ha sido parte de otro trabajo y no se manejan solicitudes paralelas desde Cisco DNA Center para el dispositivo |
Todos los dispositivos solicitados ya están siendo consultados por el ejecutor de comandos en otra sesión. Pruebe con otros dispositivos |
Si el dispositivo no es compatible con el análisis |
Los dispositivos solicitados no están en el inventario. Pruebe con otros dispositivos disponibles en el inventario. |
Si el dispositivo que se ha intentado escanear no está accesible |
"Error al ejecutar el comando: show udi\nError al conectar con el dispositivo [Host: x.x.x.x:22] Sin ruta al host: sin ruta al host |
Si no se puede acceder a Cisco DNA Center desde el microservicio Cloud Agent o Collection del Cloud Agent no está recibiendo respuesta para una solicitud de Command Runner de Cisco DNA Center |
{ |
caso de uso |
Fragmento de registro en el microservicio del agente de punto de control |
Si la solicitud de análisis tiene detalles de programación que faltan |
Error al ejecutar la solicitud |
Si la solicitud de análisis tiene detalles del dispositivo que faltan |
No se pudo crear la directiva de digitalización. No hay dispositivos válidos en la solicitud |
Si la conexión entre el CPA y la conectividad está inactiva |
Error al ejecutar la solicitud |
Si el dispositivo para análisis solicitado no está disponible en Análisis de diagnóstico |
No se pudo enviar la solicitud de análisis. Motivo = {\"mensaje\":\"No se encontró el dispositivo con nombre de host=x.x.x.x'\"} |
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
25-Jul-2024 |
Se han agregado nuevas preguntas y respuestas para la versión 2.4 |
1.0 |
31-Oct-2022 |
Versión inicial |