CX Cloud Agent - Häufig gestellte Fragen und Leitfaden zur Fehlerbehebung

Einleitung

Dieses Dokument enthält häufig gestellte Fragen und Fehlerbehebungsszenarien, mit denen Benutzer bei der Arbeit mit CX Cloud Agent konfrontiert werden können.

Bereitstellung

Frage: Ist die URL-Umleitung zu cloudfront.net ein erwartetes Verhalten bei der Verbindung mit der CX Cloud-Backend-Domäne?

A. Ja, für einige spezifische Bereitstellungsszenarien wird eine Umleitung auf cloudfront.net erwartet. Für diese FQDNs muss der ausgehende Zugriff bei aktivierter Umleitung auf Port 443 zulässig sein.

Frage: Kann der Benutzer mit der Option "Re-install" den neuen CX Cloud Agent mit einer neuen IP-Adresse bereitstellen?

A. Ja

F. Welche Dateiformate stehen für die Installation zur Verfügung?

A. OVA und VHD

Frage: In welcher Umgebung kann die installierbare Version bereitgestellt werden?

A. Für OVA

• VMWare ESXi Version 5.5 oder höher
• Oracle Virtual Box 5.2.30 oder höher

Für VHD

• Windows-Hypervisor 2012 bis 2016

Frage: Kann CX Cloud Agent eine IP-Adresse in einer DHCP-Umgebung erkennen?

A. Ja, die IP-Adresszuweisung während der IP-Konfiguration wurde erkannt. Die für den CX Cloud Agent zu erwartende Änderung der IP-Adresse wird jedoch nicht unterstützt. Kunden sollten die IP-Adresse für den CX Cloud Agent in ihrer DHCP-Umgebung reservieren.

Frage: Unterstützt CX Cloud Agent sowohl die IPv4- als auch die IPv6-Konfiguration?

A. Nein, nur IPV4 wird unterstützt.

Frage: Wird die IP-Adresse während der IP-Konfiguration validiert?

A. Ja, die IP-Adresssyntax und die Zuweisung doppelter IP-Adressen werden validiert.

Frage: Wie viel Zeit benötigen Sie für die OVA-Bereitstellung und die IP-Konfiguration?

A.Die OVA-Bereitstellung hängt von der Geschwindigkeit ab, mit der das Netzwerk die Daten kopiert. Die IP-Konfiguration dauert etwa 8-10 Minuten, einschließlich Kubernetes und Container-Erstellung.

Frage: Gibt es Einschränkungen in Bezug auf Hardwaretypen?

Antwort: Der Host-Rechner, auf dem OVA bereitgestellt wird, muss die im Rahmen der CX-Portal-Konfiguration gestellten Anforderungen erfüllen. Der CX Cloud Agent wird mit einer VMware/VirtualBox getestet, die auf einer Hardware mit Intel Xeon E5-Prozessoren mit einem vCPU-zu-CPU-Verhältnis von 2:1 ausgeführt wird. Wenn eine weniger leistungsstarke Prozessor-CPU oder ein größeres Verhältnis verwendet wird, kann sich die Leistung verschlechtern.

Frage: Kann der Kopplungscode jederzeit generiert werden?

A. Nein, der Kopplungscode kann nur generiert werden, wenn der CX Cloud Agent nicht registriert ist.

Frage: Welche Bandbreitenanforderungen bestehen zwischen Cisco DNA Centern (für bis zu 10 Cluster oder 20 Nicht-Cluster) und CX Cloud Agent?

A.Die Bandbreite stellt keine Einschränkung dar, wenn sich CX Cloud Agent und Cisco DNA Center in der Kundenumgebung im selben LAN/WAN-Netzwerk befinden. Die mindestens erforderliche Netzwerkbandbreite beträgt 2,7 Mbit/s für eine Bestandserfassung mit 5.000 Geräten sowie 13000 Access Points für eine Verbindung zwischen Agent und Cisco DNA Center. Wenn Syslogs für Level-2-Einblicke gesammelt werden, beträgt die erforderliche Mindestbandbreite 3,5 Mbit/s für die Abdeckung von 5.000 Geräten +13000 Access Points für das Inventar, 5.000 Geräte Syslogs und 2.000 Geräte für Scans - die alle parallel von CX Cloud Agent ausgeführt werden.

Frage: Wie kann auf die Agenten-Syslogs zugegriffen werden, um die virtuelle CX Cloud Agent-Maschine (VM) zu überwachen?

A. Der Zugriff auf Syslogs für Agent VM erfolgt über die lokale VM-Anmeldung über die folgenden beiden Pfade:

/var/log/syslog.1 (Zugriff über cxcadmin- und cxcroot-Anmeldedaten)

/var/log/syslog (Zugriff über Root)

Versionen und Patches

Frage: Welche Versionen werden für das Upgrade von CX Cloud Agent aufgeführt?

A. Hier sind die veröffentlichten Versionen von CX Cloud Agent aufgeführt:

• Ax0 (x steht für die aktuelle Produktionsversion mit ihren Hauptfunktionen, Beispiel: 1.3.0)
• A.x.y (wobei A.x.0 obligatorisch ist und ein inkrementelles Upgrade initiiert werden muss, x die neueste Version der Hauptfunktionen für die Produktion und y der neueste aktive Upgrade-Patch ist, Beispiel: 1.3.1)
• A.x.y-z (wobei A.x.0 obligatorisch ist und ein inkrementelles Upgrade initiiert werden muss, x die neueste Version der Hauptfunktionen für die Produktion ist und y der neueste aktive Upgrade-Patch ist, und z der Spot-Patch ist, der eine sofortige Korrektur für einen sehr kurzen Zeitraum darstellt, Beispiel: 1.3.1-1)

wobei A eine langfristige Veröffentlichung ist, die sich über 3-5 Jahre erstreckt.

Frage: Wo finden Sie die neueste Version von CX Cloud Agent und wie aktualisieren Sie den vorhandenen CX Cloud Agent?

A. So suchen Sie nach dem neuesten CX Cloud Agent und führen ein Upgrade auf diesen durch:

1. Melden Sie sich beim CX Cloud-Portal an, und navigieren Sie zum Admin Center. Das Fenster Datenquellen wird geöffnet.
2. Wählen Sie CX Cloud Agent aus, um die Detailansicht zu öffnen, und klicken Sie auf die Registerkarte Software.
3. Wählen Sie in der Dropdown-Liste Wählen Sie eine Softwareversion für Upgrade aus, und klicken Sie auf Update installieren.

Authentifizierung und Proxy-Konfiguration

Frage: Was ist der Standardbenutzer für die CX Cloud Agent-Anwendung?

A. cxcadmin

Frage: Wie wird das Kennwort für den Standardbenutzer festgelegt?

A. Kennwörter werden während der Netzwerkkonfiguration festgelegt.

Frage: Gibt es eine Option zum Zurücksetzen des Kennworts nach Day-0?

A. Der CX Cloud Agent bietet keine spezielle Option zum Zurücksetzen des Kennworts, Sie können das Kennwort für cxcadmin jedoch mithilfe der Linux-Befehle zurücksetzen.

Frage: Welche Kennwortrichtlinien gelten für die Konfiguration von CX Cloud Agent?

A. Kennwortrichtlinien sind:

• Maximales Alter (Länge) auf 90 Tage eingestellt
• Mindestalter (Länge) eingestellt auf 8 Tage
• Maximale Länge: 127 Zeichen
• Mindestens ein Zeichen in Groß- und Kleinschreibung muss enthalten sein.
• Muss mindestens ein Sonderzeichen enthalten (beispielsweise !$%^&*()_+|~-=\`{}[]:";'<>?,/)
• Die folgenden Zeichen sind nicht zulässig:
• 8-Bit-Sonderzeichen (z. B.:¬£, √Å √´, √¥, √ë,¬ø, √ü)
• Leerzeichen
• Darf nicht die letzten 10 kürzlich verwendeten Kennwörter sein
• Darf keinen regulären Ausdruck enthalten
• Darf die folgenden Wörter oder Derivate nicht enthalten: cisco, sanjose und sanfran

Frage: Wie bestätige ich, dass Secure Shell (SSH) über CX Cloud Agent auf ein Gerät erreichbar ist?

A. Um die SSH-Erreichbarkeit zu bestätigen:

1. Melden Sie sich als cxcroot-Benutzer an.
2. Führen Sie den folgenden Befehl aus, um den SSH-Port in Iptables zu aktivieren:

     Iptables -A OUTPUT -p tcp -m tcp —dport 22 -j ACCEPT

3. Führen Sie den folgenden Befehl aus, um die SSH-Erreichbarkeit zu bestätigen:

     ssh user@ip-address:port

So deaktivieren Sie die oben im CX Cloud Agent aktivierten SSH-Ports:

1. Führen Sie den folgenden Befehl aus, um die Leitungsnummer des in den IP-Tabellen aktivierten SSH-Ports abzurufen:

     iptables -L OUTPUT —line-number | Grep Dpt | Grep-SSH | Wake '{print $1}'

2. Führen Sie den folgenden Befehl aus, um die erhaltene Zeilennummer zu löschen:

     iptables -L OUTPUT <Leitungsnummer>

Frage: Wie bestätige ich die SNMP-Erreichbarkeit eines Geräts vom CX Cloud Agent?

A. So bestätigen Sie die SNMP-Erreichbarkeit:

1. Melden Sie sich als cxcroot-Benutzer an.
2. Führen Sie den folgenden Befehl aus, um die SNMP-Ports in den IP-Tabellen zu aktivieren:

      iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT

      iptables -A OUTPUT -p udp -m udp —dport 161 -j ACCEPT

3. Führen Sie den folgenden Befehl snmpwalk/snmpget aus, um die SNMP-Erreichbarkeit zu bestätigen:

      snmpwalk -v2c -c Cisco IPADDRESS

So deaktivieren Sie die oben im CX Cloud Agent aktivierten SNMP-Ports:

1. Führen Sie den folgenden Befehl aus, um die Leitungsnummern der aktivierten SNMP-Ports abzurufen (als Antwort werden zwei Leitungsnummern generiert):

iptables -L OUTPUT —line-number | Grep Dpt | Grep-SSH | Wake '{print $1}'

2. Führen Sie den folgenden Befehl aus, um die Zeilennummern (in absteigender Reihenfolge) zu löschen:

iptables -L OUTPUT <Zeilennummer2>

iptables -L OUTPUT <Leitungsnummer1 Nummer>

F. Wie stelle ich das Grub-Passwort ein?

A. So legen Sie das Grub-Kennwort fest:

1. Führen Sie .ssh als cxcroot aus, und stellen Sie das Token bereit [wenden Sie sich an das Supportteam, um das cxcroot-Token zu erhalten].
2. Führen Sie sudo su aus, um dasselbe Token bereitzustellen.
3. Führen Sie den Befehl grub-mkpasswd-pbkdf2 aus, und legen Sie das Grub-Kennwort fest. Der Hash des angegebenen Kennworts wird gedruckt. Kopieren Sie den Inhalt.
4. vi in Datei /etc/grub.d/00_header. 
5. Navigieren Sie zum Ende der Datei, und ersetzen Sie die Hash-Ausgabe gefolgt vom Inhalt password_pbkdf2 root ***** durch den erhaltenen Hash für das in Schritt 3 erhaltene Kennwort.
6. Speichern Sie die Datei mit dem Befehl :wq!.
7. Führen Sie den Befehl update-grub aus.

Frage: Welcher Ablaufzeitraum gilt für das cxcadmin-Kennwort?

A. Das Kennwort läuft in 90 Tagen ab.

Frage: Deaktiviert das System das Konto nach aufeinander folgenden erfolglosen Anmeldeversuchen?

A. Ja, das Konto wird nach fünf (5) aufeinander folgenden erfolglosen Versuchen deaktiviert. Die Sperrzeit beträgt 30 Minuten.

Frage: Wie erstelle ich eine Passphrase?

A. So erstellen Sie eine Passphrase:

1. Führen Sie .ssh aus, und melden Sie sich als cxcadmin-Benutzer an.
2. Führen Sie den Befehl remoteaccount cleanup -f aus.
3. Führen Sie den Befehl remoteaccount create aus.

Frage: Unterstützt der Proxyhost sowohl Hostname als auch IP?

A. Ja, aber um den Hostnamen zu verwenden, muss der Benutzer die DNS-IP-Adresse (Domain Name Server) während der Netzwerkkonfiguration angeben.

Secure Shell (SSH)

F. Welche Chiffren werden von der SSH-Shell unterstützt?

A. Folgende Chiffren werden unterstützt:

• chacha20-poly1305@openssh.com
• aes256-gcm@openssh.com
• aes128-gcm@openssh.com
• aes256-ctr
• aes192-ctr
• aes128-ctr

Frage: Wie melde ich mich bei der Konsole an?

A. Anmeldung:

1. Melden Sie sich als cxcadmin-Benutzer an.
2. Geben Sie das cxcadmin-Kennwort ein.

Frage: Werden SSH-Anmeldungen protokolliert?

A. Ja, sie werden als Teil der Datei "var/logs/audit/audit.log".

Frage: Welches Timeout tritt bei Leerlaufsitzungen auf?

A. Ein SSH-Sitzungs-Timeout tritt auf, wenn der CX Cloud Agent fünf (5) Minuten lang inaktiv ist.

Ports und Services

Frage: Welche Ports sind für den CX Cloud Agent offen?

A. Folgende Ports sind verfügbar:

• Ausgehender Port: Der bereitgestellte CX Cloud Agent kann mit dem Cisco Backend verbunden werden, wie in der Tabelle auf HTTPS-Port 443 angegeben, oder über einen Proxy, um Daten an Cisco zu senden, wie in der Tabelle unten angegeben. Der bereitgestellte CX Cloud Agent kann über den HTTPS-Port 443 eine Verbindung mit dem Cisco DNA Center herstellen.

NORD- UND SÜDAMERIKA	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	agent.emea.cisco.cloud	agent.apjc.cisco.cloud
ng.acs.agent.us.csco.cloud	ng.acs.agent.emea.csco.cloud	ng.acs.agent.apjc.csco.cloud

Hinweis: Wenn EMEA- oder APJC-Kunden den CX Cloud Agent neu installieren, muss zusätzlich zu den aufgeführten Domänen die Domäne agent.us.csco.cloud in der Kunden-Firewall zugelassen sein.
Die agent.us.csco.cloud-Domäne ist nach der erfolgreichen Neuinstallation nicht mehr erforderlich.

Hinweis: Stellen Sie sicher, dass Datenrückverkehr auf Port 443 zugelassen werden muss.

• Inbound port: Für die lokale Verwaltung des CX Cloud Agent müssen 514 (Syslog) und 22 (SSH) zugänglich sein. Kunden müssen zulassen, dass Port 443 in ihrer Firewall Daten von der CX Cloud empfängt.

CX Cloud Agent Connection mit Cisco DNA Center und anderen Ressourcen

F. Welchen Zweck und welche Beziehung hat Cisco DNA Center zu CX Cloud Agent?

A. Cisco DNA Center ist der Cloud Agent, der die Netzwerkgeräte am Kundenstandort verwaltet. CX Cloud Agent sammelt Inventarinformationen von Geräten aus dem konfigurierten Cisco DNA Center und lädt die Inventarinformationen hoch, die in der Ressourcenansicht von CX Cloud verfügbar sind.

Frage: Wo können Benutzer Cisco DNA Center-Details zum CX Cloud Agent angeben?

A.: Während der Einrichtung von Day 0 - CX Cloud Agent können Benutzer die Details zum Cisco DNA Center über das CX Cloud-Portal hinzufügen. Während des Day N-Betriebs können Benutzer zusätzliche Cisco DNA Center von Admin Settings > Data Source hinzufügen.

Frage: Wie viele Cisco DNA Center können hinzugefügt werden?

A. Es können zehn (10) Cisco DNA Center Cluster oder 20 Cisco DNA Center Non-Cluster hinzugefügt werden.

Frage: Wie entferne ich ein verbundenes Cisco DNA Center von CX Cloud Agent? 

A. Um ein verbundenes Cisco DNA Center aus dem CX Cloud Agent zu entfernen, wenden Sie sich an das Technical Assistance Center (TAC), um ein Support-Ticket im CX Cloud-Portal zu erstellen.

Frage: Welche Rolle kann ein Benutzer von Cisco DNA Center übernehmen?

A. Die Benutzerrolle kann entweder admin oder observer sein.

F. Wie werden Änderungen an CX Cloud Agent aufgrund von Änderungen bei den Anmeldeinformationen des verbundenen DNA-Centers angezeigt?

A. Führen Sie den Befehl cxcli agent changeController von der Konsole des CX Cloud Agent aus:

    Wenden Sie sich bei Problemen während der Aktualisierung der Cisco DNA Center-Anmeldeinformationen an den Support.

F. Wie werden die Details zu Cisco DNA Center und Seed-Dateien in CX Cloud Agent gespeichert?

A. Alle Daten, einschließlich der Anmeldedaten der mit CX Cloud Agent verbundenen Controller (z. B. Cisco DNA Center) und direkt verbundener Ressourcen (z. B. über Seed-Datei, IP-Bereich), werden mit AES-256 verschlüsselt und in der CX Cloud Agent-Datenbank gespeichert, die mit einer sicheren Benutzer-ID und einem Passwort geschützt ist.

Frage: Gibt es beim Hinzufügen anderer Ressourcen Einschränkungen bei der Eingabe von IP-Bereichen?

Antwort: Ja, der CX Cloud Agent kann Erkennungsvorgänge für größere Subnetz-IP-Bereiche nicht verarbeiten. Cisco empfiehlt die Verwendung minimierter Subnetzbereiche, die auf 10.000 IP-Adressen beschränkt sind.

Frage: Kann ein öffentliches Subnetz für die Bereitstellung von CX Cloud Agent v2.4 für den Cluster und das benutzerdefinierte Service-Subnetz verwendet werden?

A. Cisco empfiehlt aus den folgenden Gründen nicht, ein öffentliches IP-Subnetz zu verwenden:

• Sicherheitsrisiken: Öffentliche IP-Adressen setzen Cluster und Services dem Internet aus und erhöhen das Risiko von nicht autorisierten Zugriffen, Angriffen und potenziellen Datensicherheitsverletzungen.
• IP-Adresskonflikte: Die Verwendung öffentlicher IP-Subnetze kann zu IP-Konflikten führen, insbesondere wenn dieselben IP-Adressen an anderer Stelle im Internet zugewiesen werden, was zu Verbindungsproblemen und unerwartetem Verhalten führt.
• Komplexität der Netzwerkkonfiguration: Die Verwaltung von Netzwerkrichtlinien, Firewall-Regeln und Routing wird bei öffentlichen IP-Adressen immer komplexer. Dies kann zu Fehlkonfigurationen und einem erhöhten Wartungsaufwand führen.

Ein öffentliches IP-Subnetz kann verwendet werden, wenn es nur einer Kundenorganisation zugewiesen und über das Kundennetzwerk eingerichtet wird.

Frage: Wie oft kann die erneute Erkennung gestartet werden?

A. Der Vorgang zur erneuten Erkennung sollte nur dann ausgeführt werden, wenn eine Änderung im Kundennetzwerk vorliegt (z. B. nachdem Geräte im Netzwerk hinzugefügt oder gelöscht wurden).

Frage: Welcher Workflow besteht beim Hochladen einer Seed-Datei für das Hinzufügen von "anderen Ressourcen als Datenquelle"?

A. Der Workflow ist wie folgt:

1. Laden Sie die Seed-Datei in die CX Cloud hoch.
2. Die Seed-Datei wird vorübergehend im Cisco Cloud AWS S3-Bucket gespeichert (bei aktivierter SSE-Verschlüsselung).
3. Die Seed-Datei wird an den CX Cloud Agent übertragen, und die Seed-Datei wird aus dem S3-Bucket gelöscht.
4. Der CX Cloud Agent verarbeitet die Seed-Dateieinträge und verschlüsselt die Anmeldeinformationen mit einem AES 256-Schlüssel (dieser Schlüssel ist für jeden CX Cloud Agent eindeutig). Diese verschlüsselten Anmeldeinformationen werden in der CX Cloud Agent-Datenbank gespeichert.
5. Die Seed-Datei wird aus dem CX Cloud Agent gelöscht, sobald die Seed-Dateieinträge verarbeitet wurden.

Frage: Welche Art von Verschlüsselung wird beim Zugriff auf die Cisco DNA Center-API von CX Cloud Agent verwendet?

A. HTTPS über TLS 1.2 wird für die Kommunikation zwischen Cisco DNA Center und CX Cloud Agent verwendet.

Frage: Welche Vorgänge werden von CX Cloud Agent auf dem integrierten Cisco DNA Center Cloud Agent ausgeführt?

A. CX Cloud Agent sammelt Daten zu Netzwerkgeräten aus dem Cisco DNA Center und verwendet die Befehlsrunner-Schnittstelle von Cisco DNA Center, um mit Endgeräten zu kommunizieren und CLI-Befehle auszuführen (Befehl show). Es werden keine Konfigurationsänderungsbefehle ausgeführt.

Frage: Welche Standarddaten werden vom Cisco DNA Center gesammelt und an das Backend hochgeladen?

Antwort: 

• Netzwerkentität
• Module
• Show version
• Konfig.
• Gerätebildinformationen
• Tags

Frage: Welche zusätzlichen Daten werden vom Cisco DNA Center gesammelt und an das Cisco Backend übertragen?

A. Weitere Informationen finden Sie in diesem Dokument. 

Frage: Wie werden Inventardaten in das Backend hochgeladen?

A. CX Cloud Agent lädt die Bestandsdaten über das TLS 1.2-Protokoll auf den Cisco Backend-Server hoch.

Frage: Wie oft wird der Bestand hochgeladen?

A. Die Erfassung wird gemäß dem benutzerdefinierten Zeitplan ausgelöst und in das Cisco Backend hochgeladen. 

Frage: Kann der Benutzer den Bestand neu planen?

A. Ja, über Admin Center > Datenquellen ist eine Option zum Ändern der Zeitplaninformationen verfügbar.

Frage: Wann tritt die Verbindungs-Zeitüberschreitung zwischen Cisco DNA Center und Cloud Agent auf?

A. Zeitüberschreitungen werden wie folgt kategorisiert:

• Die Zeitüberschreitung für die erste Verbindung beträgt maximal 300 Sekunden. Wenn innerhalb von maximal fünf (5) Minuten keine Verbindung zwischen Cisco DNA Center und Cloud Agent hergestellt wird, wird die Verbindung beendet.
• Bei wiederkehrenden, typischen oder Aktualisierungen beträgt das Zeitlimit für Antworten 1800 Sekunden. Wenn die Antwort nicht innerhalb von 30 Minuten empfangen wird oder nicht gelesen werden kann, wird die Verbindung beendet.

CX Cloud Agent verwendet Diagnosescan

F. Welche Scanbefehle werden auf dem Gerät ausgeführt?

A. Befehle, die für den Scan auf dem Gerät ausgeführt werden müssen, werden während des Scanvorgangs dynamisch bestimmt. Die Befehlssätze können sich im Laufe der Zeit ändern, auch für das gleiche Gerät (und ohne Kontrolle über die Diagnosescans).

Frage: Wo werden die Scan-Ergebnisse gespeichert und in einem Profil festgehalten?

A. Die gescannten Ergebnisse werden im Cisco Backend gespeichert und in einem Profil festgehalten.

Frage: Werden die Duplikate (nach Hostname oder IP) im Cisco DNA Center dem Diagnosescan hinzugefügt, wenn die Cisco DNA Center-Quelle angeschlossen wird?

A. Nein, Duplikate werden so gefiltert, dass nur die eindeutigen Geräte extrahiert werden.

F. Was passiert, wenn einer der Befehlsscans fehlschlägt?

A. Der Gerätescan wird vollständig beendet und als nicht erfolgreich markiert.

F. Was passiert, wenn mehrere Scans überlappen?

A. Die gleichzeitige Ausführung mehrerer Diagnosescans kann den Scanvorgang verlangsamen und möglicherweise zu Scanfehlern führen. Cisco empfiehlt, Diagnosescans zu planen oder bedarfsgesteuerte Scans einzuleiten, die sich mindestens sechs bis sieben Stunden von den Zeitplänen für die Bestandserfassung unterscheiden, damit sie sich nicht überschneiden.

CX Cloud Agent-Systemprotokolle

Frage: Welche Integritätsinformationen werden an das CX Cloud-Portal gesendet?

A. Anwendungsprotokolle, Pod-Status, Details zum Cisco DNA Center, Audit-Protokolle, System- und Hardwaredetails

F. Welche System- und Hardwaredetails werden erfasst?

A. Beispielausgabe: 

Systemdetails":{
"os_details":{
"containerRuntimeVersion":"docker://19.3.12",
"kernelVersion":"5.4.0-47-generic",
"kubeProxyVersion":"v1.15.12",
"kubeletVersion":"v1.15.12",
"machineID":"81edd7df1c1145e7bcc1ab4fe778615f",
"Operating System" (Betriebssystem):"linux",
"osImage":"Ubuntu 20.04.1 LTS",
"systemUUID":"42002151-4131-2ad8-4443-8682911bdadb"
},
"Hardware_Details":{
"total_cpu":"8",
"cpu_usage":"12,5 %",
"Speicher gesamt":"16007 MB",
"freier Speicher":"9994 MB",
"hdd_size":"214G",
"free_hdd_size":"202G"
}
}
}

F. Wie werden Gesundheitsdaten an das Backend gesendet?

A. Mit CX Cloud Agent streamt der Integritätsdienst (Wartungsfreundlichkeit) die Daten an das Cisco Backend.

Frage: Welche Aufbewahrungsrichtlinie für das Integritätsdatenprotokoll des CX Cloud Agent befindet sich im Backend?

A. Die Aufbewahrungsrichtlinie für das Integritätsdatenprotokoll des CX Cloud Agent im Backend beträgt 120 Tage.

Frage: Welche Arten von Uploads sind verfügbar?

Antwort: 

1. Bestands-Upload
2. Syslog-Upload
3. Hochladen der Agentenintegrität, einschließlich des Integritäts-Hochladevorgangs
   1. Services Health - Alle fünf (5) Minuten
   2. Podlog - Jede (1) Stunde
   3. Audit-Protokoll - Alle (1) Stunde

Fehlerbehebung

Problem: Kein Zugriff auf die konfigurierte IP-Adresse.

Lösung: SSH mit konfigurierter IP ausführen. Bei einer Verbindungsunterbrechung liegt der mögliche Grund in einer falschen IP-Konfiguration. Führen Sie in diesem Fall eine Neuinstallation durch, indem Sie eine gültige IP-Adresse konfigurieren. Dies kann über das Portal mit der Neuinstallationsoption auf der Admin CenterSeite erfolgen.

Problem: Wie kann ich nach der Registrierung überprüfen, ob die Services einsatzbereit sind?

Lösung: Befolgen Sie die unten aufgeführten Schritte, um sicherzustellen, dass die PODs betriebsbereit sind:

1. SSH auf die konfigurierte IP als cxcadmin
2. Geben Sie das Kennwort an
3. Führen Sie den Befehl kubectl get pods aus.

PODs können sich in einem beliebigen Zustand befinden (Wird ausgeführt, Initialisiert oder Erstellen eines Containers). Nach 20 Minuten müssen sich die PODs im Running-Status befinden.

Wenn der Status nicht ausgeführt wird oder Pod initialisiert, überprüfen Sie die POD-Beschreibung mit dem Befehl kubectl description pod <podname>.

Die Ausgabe enthält Informationen zum POD-Status.


Problem: Wie kann überprüft werden, ob der SSL-Interceptor beim Kundenproxy deaktiviert ist?
Lösung: Führen Sie den hier gezeigten curl-Befehl aus, um den Abschnitt für das Serverzertifikat zu überprüfen. Die Antwort enthält die Zertifikatdetails des consoweb-Servers.

curl -v —header 'Authorization: Basic xxxxxx' https://concsoweb-prd.cisco.com/

* Serverzertifikat:

* Betreff: C=USA; ST=Kalifornien; L=San Jose; O=Cisco Systems, Inc; CN=concsoweb-prd.cisco.com

* Startdatum: 16. Februar 11:55:11 Uhr GMT

* Gültig bis: 16.02.2022 12:05:00 GMT

* BetreffAltName: Host "concsoweb-prd.cisco.com" entspricht "concsoweb-prd.cisco.com"

* Aussteller: C=US; O=HydrantID (Avalanche Cloud Corporation); CN=HydrantID SSL CA G3

* SSL-Zertifikat überprüft OK.

> GET/HTTP/1.1

Problem: kubectl-Befehle fehlgeschlagen und zeigt den Fehler als "Die Verbindung zum Server X.X.X.X:6443 wurde abgelehnt - haben Sie den richtigen Host oder Port angegeben"
Lösung:

• sollten Sie die Verfügbarkeit der Ressourcen überprüfen. [Beispiel: CPU, Arbeitsspeicher].
• Warten Sie, bis der Kubernetes Service gestartet wird .

Problem: Wie erhalte ich die Details eines Erfassungsfehlers für einen Befehl/ein Gerät?

Lösung:

• Führen Sie den Sammlungs-Pod aus, kubectl get pods und rufen Sie ihn ab.
• Führen Sie diesen Schritt aus, kubectl logs <collectionPodName> um die befehls-/gerätespezifischen Details abzurufen.

Problem: kubectl-Befehl funktioniert nicht mit Fehler "[authentication.go:64] Die Anforderung kann aufgrund eines Fehlers nicht authentifiziert werden: [x509: Zertifikat ist abgelaufen oder noch nicht gültig, x509: Zertifikat ist abgelaufen oder noch nicht gültig]"

Lösung: Führen Sie die hier gezeigten Befehle als cxcroot-Benutzer aus

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

Reaktionen auf Erfassungsfehler

Ursache für Erfassungsfehler können Einschränkungen oder Probleme mit dem hinzugefügten Controller oder den im Controller vorhandenen Geräten sein.

Die hier abgebildete Tabelle enthält den Fehlerausschnitt für Anwendungsfälle, der während des Erfassungsprozesses unter dem Collection-Mikrodienst angezeigt wird.

Anwendungsfall	Protokoll-Snippet im Microservice "Erfassung"
Wenn das angeforderte Gerät in Cisco DNA Center nicht gefunden wird	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": " Kein Gerät mit der ID 02eb08be-b13f-4d25-9d63-eaf4e882f71a gefunden " }
Wenn das angeforderte Gerät nicht über Cisco DNA Center erreichbar ist	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler beim Ausführen des Befehls: show version\nFehler beim Herstellen der Verbindung mit dem Gerät [Host: 172.21.137.221:22]No route to host: No route to host " }
Wenn das angeforderte Gerät nicht über Cisco DNA Center erreichbar ist	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler beim Ausführen des Befehls: show version\nFehler beim Herstellen der Verbindung mit dem Gerät [Host: X.X.X.X.X]Zeitüberschreitung der Verbindung: /X.X.X.X:22 : Zeitüberschreitung der Verbindung: /X.X.X.X:22" }
Wenn der angeforderte Befehl auf dem Gerät nicht verfügbar ist	{   "Befehl": "show run-config",   "Status": "Erfolg",   "commandResponse": " Fehler beim Ausführen des Befehls: show run-config\n\nshow run-config\n ^\n% Ungültige Eingabe bei Marker \u0027^\u0027 erkannt.\n\nXXCT5760#",   "errorMessage": "" }
Wenn das angeforderte Gerät nicht über SSHv2 verfügt und Cisco DNA Center versucht, das Gerät mit SSHv2 zu verbinden	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler beim Ausführen des Befehls : show version\nSSH2 channel closed : Remote-Teilnehmer verwendet inkompatibles Protokoll, nicht SSH-2-kompatibel." }
Wenn der Befehl im Microservice "Erfassung" deaktiviert ist	{   "command": "config paging disable",   "Status": "Command_Disabled",   "commandResponse": "Befehlssammlung ist deaktiviert",   "errorMessage": "" }
Wenn die Command Runner-Aufgabe fehlgeschlagen ist und die Aufgaben-URL nicht von Cisco DNA Center zurückgegeben wird	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler beim Befehlsrunner-Task für Gerät %s. Task-URL ist leer." }
Wenn die Command Runner-Aufgabe in Cisco DNA Center nicht erstellt werden konnte	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler bei der Befehlsausführeraufgabe für Gerät %s, RequestURL: %s. Keine Aufgabendetails." }
Wenn der Collection-Microservice keine Antwort auf eine Command Runner-Anfrage vom Cisco DNA Center erhält.	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler bei der Befehlsausführeraufgabe für Gerät %s, RequestURL: %s." }
Wenn Cisco DNA Center die Aufgabe nicht innerhalb der konfigurierten Zeitüberschreitung abschließt (5 Minuten pro Befehl im Microservice "Erfassung")	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage" (Fehlermeldung): "Operation Timeout. Fehler bei der Befehlsausführeraufgabe für Gerät %s, Anforderungs-URL: %s. Keine Fortschrittsdetails." }
Wenn der Command Runner-Task fehlgeschlagen ist und die Datei-ID für den von Cisco DNA Center übermittelten Task leer ist	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler bei der Befehlsausführeraufgabe für Gerät %s, RequestURL: %s. Datei-ID ist leer." }
Wenn der Command Runner Task fehlgeschlagen ist und das Datei-ID-Tag nicht vom Cisco DNA Center zurückgegeben wird	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler bei der Befehlsausführeraufgabe für Gerät %s, RequestURL: %s. Keine Datei-ID-Details." }
Wenn das Gerät nicht für die Ausführung durch den Command Runner geeignet ist	{     "command": "config paging disable",     "status": "Failed",     "commandResponse": "",     "errorMessage" (Fehlermeldung): "Angeforderte Geräte befinden sich nicht im Bestand. Versuchen Sie es mit anderen im Bestand verfügbaren Geräten."   }
Wenn der Befehl "runner" für den Benutzer deaktiviert ist	{ "Befehl": "Version anzeigen", "status": "Failed", "commandResponse": "", "errorMessage": "{\"message\":\"Die Rolle verfügt nicht über gültige Berechtigungen für den Zugriff auf die API\"}\n" }

Reaktionen auf Diagnosescanfehler

Fehler beim Scannen und die Ursachen können von einer beliebigen der aufgeführten Komponenten stammen.

Wenn Benutzer eine Suche über das Portal starten, wird diese gelegentlich als "fehlgeschlagen: Interner Serverfehler" angezeigt.

Die Ursache des Problems ist eine der aufgeführten Komponenten

• Kontrollpunkt
• Netzwerk-Datengateway
• Anschluss
• Diagnosescan
• CX Cloud Agent Microservice [Gerätemanager, Erfassung]
• Cisco DNA Center
• APIX
• Mashery
• Ping-Zugriff
• IRONBANK
• IRONBANK GW
• Big Data Broker (BDB) 

Protokolle anzeigen:

1. Melden Sie sich bei der CX Cloud Agent-Konsole an.
2. Durchführung.kubectl get pods 
3. Rufen Sie den PoD-Namen für Sammlung, Anschluss und Betriebsfähigkeit ab.
4. Zum Überprüfen der Microservice-Protokolle für Erfassung, Anschluss und Betriebsbereitschaft

• Durchführung  kubectl logs <collectionpodname>
• Durchführung kubectl logs <connector>
• Durchführung kubectl logs <servicability>

In der Tabelle unten wird der Fehlerausschnitt angezeigt, der in den Protokollen des Collection-Mikrodiensts und des Service-Mikrodiensts enthalten ist und aufgrund von Problemen/Einschränkungen mit den Komponenten auftritt.

Anwendungsfall	Protokoll-Snippet im Microservice "Erfassung"
Das Gerät kann erreichbar sein und wird unterstützt, aber die Befehle, die auf diesem Gerät ausgeführt werden sollen, werden im Collection-Microservice blockiert.	{   "command": "config paging disable",   "Status": "Command_Disabled",   "commandResponse": "Befehlssammlung ist deaktiviert", }
Wenn das Gerät für eine Suche nicht verfügbar ist. Tritt in einem Szenario auf, wenn ein Synchronisierungsproblem zwischen den Komponenten wie Portal, Diagnosescan, CX-Komponente und Cisco DNA Center besteht	Kein Gerät mit der ID 02eb08be-b13f-4d25-9d63-eaf4e882f71a gefunden
Wenn das zu scannende Gerät ausgelastet ist, wenn dasselbe Gerät Teil eines anderen Auftrags war und keine parallelen Anfragen von Cisco DNA Center für das Gerät verarbeitet werden	Alle angeforderten Geräte werden bereits in einer anderen Sitzung vom Befehlsrunner abgefragt. Versuchen Sie es mit anderen Geräten.
Wenn das Gerät den Scanvorgang nicht unterstützt.	Die angeforderten Geräte befinden sich nicht im Bestand. Versuchen Sie es mit anderen im Bestand verfügbaren Geräten.
Wenn das Gerät nicht erreichbar ist	"Fehler beim Ausführen des Befehls: show udi\nFehler beim Herstellen der Verbindung mit dem Gerät [Host: x.x.x.x:22] Keine Route zum Host: Keine Route zum Host
Wenn Cisco DNA Center über den Cloud Agent nicht erreichbar ist oder der Microservice "Erfassung" des Cloud Agent keine Antwort auf eine Command Runner-Anfrage vom Cisco DNA Center erhält.	{   "Befehl": "Version anzeigen",   "status": "Failed",   "commandResponse": "",   "errorMessage": "Fehler bei der Befehlsausführeraufgabe für Gerät %s, RequestURL: %s." }

Anwendungsfall	Protokoll-Snippet im Microservice "Kontrollpunkt-Agent"
Wenn bei der Scananfrage Zeitplandetails fehlen.	Anfrage konnte nicht ausgeführt werden {"message":"23502: NULL-Wert in Spalte \"schedule\" verletzt Nicht-Null-Einschränkung"}
Wenn bei der Scananfrage Gerätedetails fehlen.	Fehler beim Erstellen der Scanrichtlinie. Keine gültigen Geräte in der Anforderung
Wenn die Verbindung zwischen CPA und Netzwerkverbindungen unterbrochen ist.	Anfrage konnte nicht ausgeführt werden
Wenn das angeforderte Gerät in den Diagnosescans nicht zum Scannen verfügbar ist.	Fehler beim Übermitteln der Scananforderung. Ursache = {\"Nachricht\":\"Gerät mit Hostname=x.x.x.x' wurde nicht gefunden\"}