La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento include le domande frequenti e gli scenari di risoluzione dei problemi che gli utenti possono incontrare quando utilizzano l'agente cloud CX.
R. Sì, per alcuni scenari di distribuzione specifici è previsto il reindirizzamento a cloudfront.net. L'accesso in uscita deve essere consentito con il reindirizzamento abilitato sulla porta 443 per questi FQDN.
A. Sì
A. OVA e VHD
A. Per gli ovuli
Per VHD
R. Sì, viene rilevata l'assegnazione dell'indirizzo IP durante la configurazione IP. Tuttavia, la modifica dell'indirizzo IP prevista per l'agente cloud CX in futuro non è supportata. Si consiglia di riservare l'IP per l'agente cloud CX nell'ambiente DHCP.
R. No, è supportato solo il protocollo IPV4.
R. Sì, vengono convalidati la sintassi degli indirizzi IP e l'assegnazione di indirizzi IP duplicati.
A.La distribuzione degli OAV dipende dalla velocità della rete che copia i dati. La configurazione IP richiede all'incirca 8-10 minuti, inclusi Kubernetes e la creazione di container.
R. Il computer host su cui è distribuito OVA deve soddisfare i requisiti forniti nell'ambito della configurazione del portale CX. L'agente cloud CX viene testato con VMware/Virtual box in esecuzione su un hardware con processori Intel Xeon E5 con rapporto vCPU/CPU impostato su 2:1. Se si utilizza una CPU del processore meno potente o un rapporto maggiore, le prestazioni possono peggiorare.
R. No, il codice di associazione può essere generato solo quando l'agente cloud CX non è registrato.
A.La larghezza di banda non è un vincolo quando l'agente cloud CX e Cisco DNA Center si trovano nella stessa rete LAN/WAN nell'ambiente del cliente. La larghezza di banda di rete minima richiesta è 2,7 Mbit/sec per le raccolte di inventario di 5000 dispositivi + 13000 access point per la connessione di un agente a Cisco DNA Center. Se i syslog vengono raccolti per le informazioni di livello 2, la larghezza di banda minima richiesta è 3,5 Mbit/sec per le coperture di 5000 dispositivi +13000 Access Point per inventario, 5000 dispositivi syslog e 2000 dispositivi per scansioni, il tutto eseguito in parallelo da CX Cloud Agent.
R. È possibile accedere ai syslog per la macchina virtuale dell'agente dall'accesso alla macchina virtuale locale utilizzando i due percorsi seguenti:
/var/log/syslog.1 (accesso tramite cxcadmin e cxcroot login)
/var/log/syslog (accesso tramite root)
R. Di seguito sono elencate le versioni rilasciate di CX Cloud Agent:
dove A è una release a lungo termine distribuita su 3-5 anni.
R. Per individuare e aggiornare l'agente cloud CX più recente:
A. cxcadmin
R. Le password vengono impostate durante la configurazione della rete.
R. L'agente cloud CX non fornisce alcuna opzione specifica per reimpostare la password, ma è possibile utilizzare i comandi Linux per reimpostare la password per cxcadmin.
R. I criteri per la password sono:
A. Per confermare la raggiungibilità SSH:
Iptables -A OUTPUT -p tcp -m tcp —dport 22 -j ACCEPT
Per disabilitare le porte SSH abilitate in precedenza nell'agente cloud CX:
iptables -L OUTPUT —numero-riga | dpt grep | grep ssh | sveglio '{print $1}'
iptables -L OUTPUT <numero riga>
R. Per confermare la raggiungibilità di 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 indirizzo IP cisco
Per disabilitare le porte SNMP abilitate in precedenza nell'agente cloud CX:
iptables -L OUTPUT —numero-riga | dpt grep | grep ssh | sveglio '{print $1}'
iptables -L OUTPUT <numero riga2 Numero>
iptables -L OUTPUT <Numero riga1>
A. Per impostare la password di Grub:
R. La password scade tra 90 giorni.
R. Sì, l'account viene disabilitato dopo cinque (5) tentativi consecutivi non riusciti. L'account viene bloccato per 30 minuti.
A. Per generare una passphrase:
R. Sì, ma per utilizzare il nome host, l'utente deve fornire l'indirizzo IP DNS (Domain Name Server) durante la configurazione della rete.
R. Sono supportati i seguenti cifrari:
A. Per accedere:
R. Sì, sono registrati come parte del file "var/logs/audit/audit.log".
R. Il timeout della sessione SSH si verifica se l'agente cloud CX rimane inattivo per cinque (5) minuti.
R. Sono disponibili le seguenti porte:
AMERICAS |
EMEA |
APJC |
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 |
agente.emea.cisco.cloud |
agente.apjc.cisco.cloud |
ng.acs.agent.us.csco.cloud |
ng.acs.agent.emea.cisco.cloud |
ng.acs.agent.apjc.cisco.cloud |
Nota: oltre ai domini elencati, quando i clienti EMEA o APJC reinstallano l'agente cloud CX, il dominio agent.us.csco.cloud deve essere consentito nel firewall del cliente.
Il dominio agent.us.csco.cloud non è più necessario dopo la corretta reinstallazione.
Nota: verificare che il traffico di ritorno sia consentito sulla porta 443.
Inbound port: per la gestione locale dell'agente cloud CX, devono essere accessibili 514 (Syslog) e 22 (ssh). I clienti devono consentire alla porta 443 nel proprio firewall di ricevere i dati da CX Cloud.
Connessione di CX Cloud Agent con Cisco DNA Center e altre risorse
D. Qual è lo scopo e la relazione di Cisco DNA Center con CX Cloud Agent?
R. Cisco DNA Center è l'agente cloud che gestisce i dispositivi di rete della sede del cliente. CX Cloud Agent raccoglie le informazioni di inventario dei dispositivi dal Cisco DNA Center configurato e carica le informazioni di inventario disponibili nella Asset View di CX Cloud.
D. Dove possono gli utenti fornire i dettagli Cisco DNA Center sull'agente cloud CX?
R. Durante il Giorno 0 - Installazione di CX Cloud Agent, gli utenti possono aggiungere i dettagli di Cisco DNA Center dal portale CX Cloud. Durante le operazioni del Giorno N, gli utenti possono aggiungere altri Cisco DNA Center da
Admin Settings > Data Source.
D. Quanti Cisco DNA Center è possibile aggiungere?
R. È possibile aggiungere dieci (10) cluster Cisco DNA Center o 20 non cluster Cisco DNA Center.
D. Come rimuovere un Cisco DNA Center connesso da CX Cloud Agent?
R. Per rimuovere un Cisco DNA Center connesso dall'agente cloud CX, contattare il Technical Assistance Center (TAC) per aprire una richiesta di assistenza dal portale cloud CX.
D. Quale ruolo può svolgere l'utente Cisco DNA Center?
R. Il ruolo utente può essere admin o observer.
D. In che modo le modifiche apportate all'agente cloud CX a causa delle modifiche delle credenziali di un DNA Center connesso?
R. Eseguire il comando cxcli agent modifyController dalla console dell'agente cloud CX:
Contattare il supporto tecnico per qualsiasi problema durante l'aggiornamento delle credenziali di Cisco DNA Center.
D. Come vengono archiviati i dettagli degli asset di Cisco DNA Center e dei file di inizializzazione in CX Cloud Agent?
R. Tutti i dati, incluse le credenziali dei controller connessi all'agente cloud CX (ad esempio, Cisco DNA Center) e gli asset connessi direttamente (ad esempio, tramite file di inizializzazione, intervallo IP), vengono crittografati utilizzando AES-256 e archiviati nel database dell'agente cloud CX che è protetto con un ID utente e una password protetti.
D. Esistono limitazioni per l'immissione di intervalli IP quando si aggiungono altre risorse?
R. Sì, l'agente cloud CX non è in grado di gestire le operazioni di rilevamento per intervalli IP di subnet più grandi. Cisco consiglia di utilizzare intervalli di subnet ridotti a 10.000 indirizzi IP.
D. È possibile utilizzare una subnet pubblica per l'implementazione dell'agente cloud CX v2.4 per il cluster e la subnet personalizzata del servizio?
R. Cisco sconsiglia di utilizzare una subnet IP pubblica per i seguenti motivi:
- Rischi per la sicurezza: gli indirizzi IP pubblici espongono cluster e servizi a Internet, aumentando il rischio di accessi non autorizzati, attacchi e potenziali violazioni dei dati.
- Conflitti di indirizzi IP: l'utilizzo di subnet IP pubbliche può causare conflitti IP, soprattutto se gli stessi indirizzi IP vengono assegnati in altre posizioni su Internet, con conseguenti problemi di connettività e comportamenti imprevisti.
- Complessità nella configurazione di rete: la gestione dei criteri di rete, delle regole firewall e del routing diventa più complessa quando si utilizzano indirizzi IP pubblici. Ciò può causare errori di configurazione e un aumento del sovraccarico di manutenzione.
È possibile utilizzare una subnet IP pubblica se è assegnata esclusivamente a un'organizzazione del cliente e impostata sulla rete del cliente.
D. Con quale frequenza è possibile avviare l'operazione di riscoperta?
R. L'operazione di nuova individuazione deve essere eseguita solo se si verifica una modifica nella rete del cliente (ad esempio, dopo l'aggiunta o l'eliminazione di dispositivi nella rete).
D. Qual è il flusso di lavoro per l'aggiunta di "Altre risorse come origine dati" quando si carica un file di origine?
R. Il flusso di lavoro è il seguente:
- Caricare il file di inizializzazione in CX Cloud.
- Il file di inizializzazione viene temporaneamente archiviato nel bucket S3 di Cisco Cloud AWS (con la crittografia SSE abilitata).
- Il file di inizializzazione viene inviato all'agente cloud CX e il file di inizializzazione viene eliminato dal bucket S3
- L'agente cloud CX elabora le voci dei file di inizializzazione e crittografa le credenziali utilizzando una chiave AES 256 (questa chiave è univoca per ciascun agente cloud CX). Queste credenziali crittografate vengono archiviate nel database dell'agente cloud CX.
- Il file di origine viene eliminato dall'agente cloud CX una volta elaborate le voci del file di origine.
D. Che tipo di crittografia viene utilizzata durante l'accesso all'API Cisco DNA Center da CX Cloud Agent?
R. HTTPS over TLS 1.2 viene utilizzato per la comunicazione tra Cisco DNA Center e l'agente CX Cloud.
D. Quali operazioni vengono eseguite dall'agente cloud CX sull'agente cloud Cisco DNA Center integrato?
R. L'agente cloud CX raccoglie dati dai Cisco DNA Center sui dispositivi di rete e utilizza l'interfaccia di esecuzione dei comandi di Cisco DNA Center per comunicare con i dispositivi terminali ed eseguire i comandi CLI (comando show). Non viene eseguito alcun comando di modifica della configurazione.
D. Quali dati predefiniti vengono raccolti da Cisco DNA Center e caricati nel back-end?
R.
- Entità di rete
- Moduli
- Show version
- Config
- Informazioni sull'immagine del dispositivo
- Tag
D. Quali dati aggiuntivi vengono raccolti da Cisco DNA Center e caricati nel back-end Cisco?
R. Per ulteriori informazioni, consultare il documento.
D. Come vengono caricati i dati di inventario nel back-end?
R. CX Cloud Agent carica i dati di inventario tramite il protocollo TLS 1.2 sul server back-end Cisco.
D. Qual è la frequenza di caricamento delle scorte?
R. La raccolta viene attivata in base alla pianificazione definita dall'utente e caricata nel back-end Cisco.
D. L'utente può riprogrammare l'inventario?
R. Sì, è disponibile un'opzione da Amministrazione > Origini dati per modificare le informazioni di pianificazione.
D. Quando si verifica il timeout della connessione tra Cisco DNA Center e Cloud Agent?
A. I timeout sono classificati come segue:
- Per la connessione iniziale, il timeout è un massimo di 300 secondi. Se non viene stabilita una connessione tra Cisco DNA Center e Cloud Agent entro un massimo di cinque (5) minuti, la connessione viene terminata.
- Per aggiornamenti ricorrenti, tipici o: il timeout di risposta è 1800 secondi. Se la risposta non viene ricevuta o non può essere letta entro 30 minuti, la connessione viene terminata.
Analisi diagnostica di CX Cloud Agent
D. Quali comandi di scansione vengono eseguiti sul dispositivo?
R. I comandi che devono essere eseguiti sul dispositivo per la scansione vengono determinati in modo dinamico durante il processo di scansione. L'insieme di comandi può cambiare nel tempo, anche per lo stesso dispositivo (e non in controllo di Diagnostic Scan).
D. Dove vengono archiviati e analizzati i risultati dell'analisi?
R. I risultati della scansione vengono archiviati e analizzati nel back-end Cisco.
D. I duplicati (per nome host o IP) in Cisco DNA Center vengono aggiunti alla scansione diagnostica quando è collegata l'origine Cisco DNA Center?
R. No, i duplicati vengono filtrati in modo da estrarre solo i dispositivi univoci.
D. Cosa succede quando una delle analisi dei comandi ha esito negativo?
R. La scansione del dispositivo si interrompe completamente e viene contrassegnata come non riuscita.
D. Cosa succede quando più scansioni si sovrappongono?
R. L'esecuzione simultanea di più scansioni diagnostiche può rallentare il processo di scansione e potenzialmente causare errori di scansione. Cisco consiglia di pianificare analisi diagnostiche o di avviare analisi su richiesta ad almeno 6-7 ore di distanza dalle pianificazioni di raccolta delle scorte in modo che non si sovrappongano.
Log di sistema di CX Cloud Agent
D. Quali informazioni sullo stato vengono inviate al portale CX Cloud?
R. Registri delle applicazioni, stato dei dispositivi, dettagli di Cisco DNA Center, registri di verifica, dettagli di sistema e dettagli hardware.
D. Quali dettagli relativi al sistema e all'hardware vengono raccolti?
A. Output di esempio:
system_details":{
"os_details":{
"containerRuntimeVersion":"docker://19.3.12",
"kernelVersion":"5.4.0-47-generic",
"kubeProxyVersion":"v1.15.12",
"kubeletVersion":"v1.15.12",
"machineID":"81edd7df1c1145e7bcc1ab4fe78615f",
"operatingSystem":"linux",
"osImage":"Ubuntu 20.04.1 LTS",
"systemUUID":"42002151-4131-2ad8-4443-8682911bdadb"
},
"dettagli_hardware":{
"total_cpu":"8",
"cpu_usage":"12,5%",
"total_memory":"1607 MB",
"free_memory":"9994 MB",
"hdd_size":"214G",
"free_hdd_size":"202G"
}
}
}
D. Come vengono inviati i dati di integrità al back-end?
R. Con l'agente cloud CX, il servizio di integrità (facilità di manutenzione) invia i dati al back-end Cisco.
D. Quali sono le regole di conservazione dei log di dati sullo stato dell'agente cloud CX nel back-end?
R. Il criterio di conservazione del log di dati sull'integrità dell'agente cloud CX nel back-end è di 120 giorni.
D. Quali tipi di caricamento sono disponibili?
R.
- Caricamento scorte
- Caricamento syslog
- Caricamento dell'integrità dell'agente, incluso il caricamento dell'integrità
- Integrità dei servizi: ogni cinque (5) minuti
- Podlog - Ogni (1) ora
- Registro di controllo - Ogni (1) ora
Risoluzione dei problemi
Problema: impossibile accedere all'indirizzo IP configurato.
Soluzione: eseguire ssh utilizzando l'IP configurato. In caso di timeout della connessione, è possibile che l'indirizzo IP non sia stato configurato correttamente. In questo caso, eseguire nuovamente l'installazione configurando un indirizzo IP valido. A tale scopo, è possibile utilizzare il portale con l'opzione di reinstallazione fornita nella
Admin Centerpagina.
Problema: come posso verificare che i servizi siano attivi e in esecuzione dopo la registrazione?
Soluzione: per verificare che i pod siano attivi e in esecuzione, procedere come segue:
- Eseguire il comando SSH sull'IP configurato come cxcadmin
- Immettere la password
- Eseguire il comando kubectl get pods
I pod possono essere in qualsiasi stato (in esecuzione, inizializzazione o creazione di contenitori). Dopo 20 minuti, i baccelli devono essere in stato In esecuzione.
Se lo stato non è in esecuzione o Pod Initializing, controllare la descrizione del pod con il comando kubectl description pod <podname>.
L'output conterrà informazioni sullo stato del pod.
Problema: come verificare se l'intercettore SSL è disabilitato sul proxy del cliente?
Soluzione: eseguire il comando curl illustrato per verificare la sezione relativa al certificato del server. La risposta contiene i dettagli del certificato del server Web concavo.
curl -v —header 'Authorization: Basic xxxxxx' https://concsoweb-prd.cisco.com/
* Certificato server:
* soggetto: C=US; ST=California; L=San Jose; O=Cisco Systems, Inc.; CN=concsoweb-prd.cisco.com
* data di inizio: 16 febbraio 11:55:11 2021 GMT
* data di scadenza: 16 febbraio 12:05:00 2022 GMT
* subjectAltName: l'host "concsoweb-prd.cisco.com" corrisponde al certificato "concsoweb-prd.cisco.com"
* autorità emittente: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID SSL CA G3
* Il certificato SSL è valido.
> GET/HTTP/1.1
Problema: i comandi kubectl non sono riusciti e mostrano l'errore come "La connessione al server X.X.X.X:6443 è stata rifiutata - sono stati specificati l'host o la porta corretti"
Soluzione:
- Verificare la disponibilità delle risorse, [esempio: CPU, Memoria].
- Attendere l'avvio del servizio Kubernetes.
Problema: come ottenere i dettagli dell'errore di raccolta per un comando o un dispositivo?
Soluzione:
- Eseguire
kubectl get pods e ottenere il nome del contenitore di raccolta.
- Eseguire
kubectl logs <collectionPodName> per ottenere i dettagli specifici del comando o del dispositivo.
Problema: il comando kubectl non funziona con l'errore "[authentication.go:64] Impossibile autenticare la richiesta a causa di un errore: [x509: certificato scaduto o non ancora valido, x509: certificato scaduto o non ancora valido]"
Soluzione:eseguire i comandi visualizzati come utente 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-serving
systemctl restart k3s
Risoluzione degli errori di raccolta
L'errore di raccolta può essere causato da qualsiasi vincolo o problema riscontrato nel controller aggiunto o nei dispositivi presenti nel controller.
Nella tabella riportata di seguito è riportato il frammento di codice di errore relativo ai casi di utilizzo rilevati nel microservizio Collection durante il processo di raccolta.
Scenario d'uso |
Frammento di codice nel log del microservizio Collection |
Il dispositivo desiderato non viene rilevato in Cisco DNA Center |
{ |
Il dispositivo desiderato non è raggiungibile da Cisco DNA Center |
{ |
Il dispositivo desiderato non è raggiungibile da Cisco DNA Center |
{ |
Se il comando richiesto non è disponibile nel dispositivo |
{ |
Se il dispositivo richiesto non dispone di SSHv2 e Cisco DNA Center tenta di connetterlo con SSHv2 |
{ |
Il comando è disabilitato nel microservizio Collection |
{ |
Esecuzione dell'attività Command Runner non riuscita, Cisco DNA Center non restituisce l'URL dell'attività |
{ |
Creazione dell'attività Command Runner non riuscita in Cisco DNA Center |
{ |
Se il microservizio Collection non riceve una risposta per una richiesta di Command Runner da Cisco DNA Center |
{ |
Cisco DNA Center non completa l'attività entro il timeout configurato (5 minuti per comando nel microservizio Collection) |
{ |
Se l'operazione Command Runner non è riuscita e l'ID file è vuoto per l'operazione inviata da Cisco DNA Center |
{ |
Se l'operazione Command Runner non è riuscita e il tag ID file non viene restituito da Cisco DNA Center |
{ |
Command Runner non può essere eseguito sul dispositivo |
{ |
Command Runner non può essere eseguito dall'utente |
{ |
Risoluzione degli errori di analisi diagnostica
Gli errori di scansione e le cause possono essere da uno qualsiasi dei componenti elencati.
Quando gli utenti avviano un'analisi dal portale, a volte viene restituito il messaggio "operazione non riuscita: errore interno del server".
La causa del problema è uno dei componenti elencati
- Punto di controllo
- Gateway dei dati della rete
- Connettore
- Analisi diagnostica
- Microservizio di CX Cloud Agent (devicemanager, collection)
- Cisco DNA Center
- APIX
- Mashery
- Accesso ping
- IRONBANK
- IRONBANK GW
- Big Data Broker (BDB)
Per visualizzare i registri:
- Accedere alla console di CX Cloud Agent.
- Immettere il comando.
kubectl get pods
- Ottenere il nome del pod della raccolta, il connettore e la facilità di manutenzione.
- Per verificare la raccolta, il connettore e i registri dei microservizi di facilità di manutenzione.
- Immettere il comando
kubectl logs <collectionpodname>
- Immettere il comando
kubectl logs <connector>
- Immettere il comando
kubectl logs <servicability>
Nella tabella seguente viene visualizzato il frammento di codice di errore presente nei registri del microservizio Raccolta e del microservizio facilità di manutenzione che si verifica a causa dei problemi/vincoli dei componenti.
Scenario d'uso |
Frammento di codice nel log del microservizio Collection |
Il dispositivo può essere raggiungibile e supportato, ma i comandi da eseguire su tale dispositivo sono elencati a blocchi nel microservizio Collection |
{ |
Se il dispositivo per l'analisi non è disponibile. Si verifica in uno scenario in cui esiste un problema di sincronizzazione tra componenti quali portale, analisi diagnostica, componente CX e Cisco DNA Center |
Nessun dispositivo trovato con ID 02eb08be-b13f-4d25-9d63-eaf4e882f71a |
Il dispositivo che si sta tentando di analizzare è occupato, in uno scenario in cui lo stesso dispositivo fa parte di un altro processo e Cisco DNA Center non gestisce richieste parallele per il dispositivo |
Tutti i dispositivi richiesti sono già stati interrogati dal runner di comandi in un'altra sessione. Provare con altri dispositivi |
Il dispositivo non supporta la funzionalità di analisi |
I dispositivi richiesti non sono in inventario. Provare con altri dispositivi disponibili in inventario |
Se il dispositivo che si è tentato di analizzare non è raggiungibile |
"Errore durante l'esecuzione del comando: show udi\nErrore durante la connessione al dispositivo [Host: x.x.x.x:22] Nessuna route all'host: nessuna route all'host |
Cisco DNA Center non è raggiungibile dal Cloud Agent oppure il microservizio Collection del Cloud Agent non riceve risposta in seguito a una richiesta Command Runner di Cisco DNA Center |
{ |
Scenario d'uso |
Frammento di codice nel log del microservizio Control Point Agent |
Nella richiesta di analisi mancano i dettagli della pianificazione |
Impossibile eseguire la richiesta |
Nella richiesta di analisi mancano i dettagli del dispositivo |
Impossibile creare il criterio di analisi. Nessun dispositivo valido nella richiesta |
Connettività al CPA assente |
Impossibile eseguire la richiesta |
Il dispositivo da analizzare non supporta le analisi diagnostiche |
Impossibile inviare la richiesta di analisi. Motivo = {\"messaggio\":\"Impossibile trovare il dispositivo con nome host=x.x.x.x'\"} |
Revisione | Data di pubblicazione | Commenti |
---|---|---|
2.0 |
25-Jul-2024 |
Per la versione 2.4 sono state aggiunte nuove domande e risposte |
1.0 |
31-Oct-2022 |
Versione iniziale |