Il servizio di allarme è sovraccarico.

Quando viene rilevato l'evento: "A causa del volume elevato di allarmi segnalati, il servizio di allarme è temporaneamente sovraccarico. L'interfaccia utente NSX e il comando GET /api/v1/alarms di NSX API hanno interrotto la segnalazione di nuovi allarmi; tuttavia, le voci syslog e i trap SNMP (se attivati) continuano a segnalare i dettagli dell'evento sottostante. Una volta risolti i problemi sottostanti che causano un elevato volume di allarmi, il servizio di allarme ricomincerà a segnalare i nuovi allarmi. "

Quando l'evento viene risolto: "Il volume elevato di allarmi è cessato e vengono segnalati nuovi allarmi. "

Esaminare tutti gli allarmi attivi utilizzando la pagina Allarmi nell'interfaccia utente di NSX oppure il comando GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED di NSX API. Per ogni allarme attivo, individuare la causa principale eseguendo l'azione consigliata per l'allarme. Una volta risolto un numero sufficiente di allarmi, il servizio ricomincerà a segnalare i nuovi allarmi.

Rilevato un volume elevato di un tipo di allarme specifico.

Quando viene rilevato l'evento: "A causa del volume di allarmi elevato {event_id}, il servizio di allarme ha temporaneamente interrotto la segnalazione di questo tipo di allarmi. L'interfaccia utente NSX e il comando GET/api/v1/alarms di NSX API non segnalano nuove istanze di questi allarmi; tuttavia, le voci syslog e i trap SNMP (se attivati) continuano a segnalare i dettagli dell'evento sottostante. Una volta risolti i problemi sottostanti che causano un volume di allarmi elevato {event_id}, quando verranno rilevati nuovi problemi il servizio ricomincerà a segnalare i nuovi allarmi {event_id}. "

Quando l'evento viene risolto: "Il volume elevato di allarmi {event_id} è cessato e vengono segnalati nuovi allarmi di questo tipo. "

Esaminare tutti gli allarmi attivi di tipo {event_id} utilizzando la pagina Allarmi nell'interfaccia utente di NSX oppure il comando GET /api/v1/alarms?status=OPEN,ACKNOWLEDGED,SUPPRESSED di NSX API. Per ogni allarme attivo, individuare la causa principale eseguendo l'azione consigliata per l'allarme. Una volta risolto un numero sufficiente di allarmi, il servizio ricomincerà a segnalare i nuovi allarmi {event_id}.

Impossibile scrivere in almeno uno dei file di registro monitorati.

Quando viene rilevato l'evento: "Almeno uno dei file di registro monitorati dispone di autorizzazioni di sola lettura o la proprietà utente/gruppo è errata nei nodi di Manager, Global Manager, Edge, gateway del cloud pubblico, KVM o server fisico di Linux. Oppure la cartella del registro non è presente nei nodi del server fisico Windows. Oppure rsyslog.log non è presente nei nodi di Manager, Global Manager, Edge o del gateway del cloud pubblico. "

Quando l'evento viene risolto: "Tutti i file di registro monitorati dispongono delle autorizzazioni e della proprietà corrette per i file nei nodi di Manager, Global Manager, Edge, gateway del cloud pubblico, KVM o server fisico di Linux. E la cartella del registro esiste nei nodi del server fisico Windows. E rsyslog.log esiste nei nodi di Manager, Global Manager, Edge o del gateway del cloud pubblico. "

1. Nei nodi di Manager e Global Managaer, nonché nei nodi di Edge e del gateway del cloud pubblico, i nodi host KVM di Ubuntu garantiscono che le autorizzazioni per la directory /var/log sia 775 e la proprietà sia root:syslog. I nodi host KVM e BMS di Rhel garantiscono che l'autorizzazione per la directory /var/log sia 755 e la proprietà sia root:root.
2. Nei nodi di Manager e Global Manager, assicurarsi che le autorizzazioni dei file per auth.log, nsx-audit.log, nsx-audit-write.log, rsyslog.log, e syslog in /var/log sia 640 e la proprietà sia syslog:admin.
3. Nei nodi Edge e Gateway cloud pubblico, assicurarsi che le autorizzazioni dei file per rsyslog.log e syslog in /var/log sia 640 e la proprietà sia syslog:admin.
4. Nei nodi host KVM di Ubuntu e del server fisico Ubuntu, assicurarsi che le autorizzazioni dei file di auth.log e vmware/nsx-syslog in /var/log siano 640 e la proprietà sia syslog:admin.
5. Nei nodi host KVM di Rhel e nei nodi del server fisico Centos/Rhel/Sles, assicurarsi che l'autorizzazione del file di vmware/nsx-syslog in /var/log sia 640 e la proprietà sia root:root.
6. Se uno di questi file presenta autorizzazioni o proprietà errate, richiamare i comandi chmod &ltmode&gt &ltpath&gt e chown &ltuser&gt:&ltgroup&gt &ltpath&gt.
7. Se rsyslog.log non è presente nei nodi di Manager, Global Manager, Edge o del gateway del cloud pubblico, richiamare il comando della CLI NSX restart service syslog che riavvia il servizio di registrazione e rigenera /var/log/rsyslog.log.
8. Nei nodi del server fisico Windows, assicurarsi che sia presente la cartella del registro: C:\ProgramData\VMware\NSX\Logs. In caso contrario, reinstallare NSX nei nodi del server fisico Windows.

I messaggi del registro non sono recapitabili a causa di una configurazione errata del server di registrazione remota.

Quando viene rilevato l'evento: "Non è possibile recapitare i messaggi del registro al server di registrazione {hostname_or_ip_address_with_port} ({entity_id}) probabilmente a causa di un FQDN non risolvibile, di un certificato TLS non valido o di una regola iptables dell'appliance NSX mancante. "

Quando l'evento viene risolto: "La configurazione del server di registrazione {hostname_or_ip_address_with_port} ({entity_id}) è corretta. "

1. Assicurarsi che {hostname_or_ip_address_with_port} sia il nome host o l'indirizzo IP e la porta corretti.
2. Se il server di registrazione viene specificato utilizzando un FQDN, assicurarsi che l'FQDN sia risolvibile dall'appliance NSX utilizzando il comando NSX della CLI nslookup &ltfqdn&gt. Se non risolvibile, verificare che sia specificato il nome di dominio completo corretto e che il server DNS di rete disponga della voce richiesta per il nome di dominio completo.
3. Se il server di registrazione è configurato per l'utilizzo di TLS, verificare che il certificato specificato sia valido. Ad esempio, verificare che il server di registrazione utilizzi effettivamente il certificato o che il certificato non sia scaduto utilizzando il comando openssl openssl x509 -in &ltcert-file-path&gt -noout -dates.
4. Le appliance NSX utilizzano regole iptables per consentire esplicitamente il traffico in uscita. Verificare che la regola iptables per il server di registrazione sia configurata correttamente richiamando il comando della CLI di NSX verify logging-servers che configura nuovamente le regole iptables del server di registrazione in base alle esigenze.
5. Se per qualsiasi motivo il server di registrazione non è configurato correttamente, deve essere eliminato utilizzando il comando della CLI di NSX "del logging-server &lthostname-or-ip-address[:port]&gt proto &ltproto&gt level &ltlevel&gt" e aggiunto nuovamente con la configurazione corretta.

È stata violata una soglia di capacità minima.

Quando viene rilevato l'evento: Il numero di oggetti definiti nel sistema per {capacity_display_name} è {capacity_usage_count}, ovvero un valore superiore alla soglia di capacità minima {min_capacity_threshold}%. "

Quando l'evento viene risolto: Il numero di oggetti definiti nel sistema per {capacity_display_name} è {capacity_usage_count}, ovvero un valore minore o uguale alla soglia di capacità minima {min_capacity_threshold}%. "

Passare alla pagina Capacità nell'interfaccia utente di NSX ed esaminare l'utilizzo corrente rispetto ai limiti di soglia. Se è previsto l'utilizzo corrente, considerare di aumentare i valori della soglia minima. Se l'utilizzo corrente è inaspettato, esaminare i criteri di rete configurati per ridurre l'utilizzo allo stesso livello o al di sotto della soglia minima.

È stata violata una soglia di capacità massima.

Quando viene rilevato l'evento: Il numero di oggetti definiti nel sistema per {capacity_display_name} è {capacity_usage_count}, ovvero un valore superiore alla soglia di capacità massima {max_capacity_threshold}%. "

Quando l'evento viene risolto: Il numero di oggetti definiti nel sistema per {capacity_display_name} è {capacity_usage_count}, ovvero un valore minore o uguale alla soglia di capacità massima {max_capacity_threshold}%. "

Passare alla pagina Capacità nell'interfaccia utente di NSX ed esaminare l'utilizzo corrente rispetto ai limiti di soglia. Se l'utilizzo corrente è previsto, considerare l'aumento dei valori di soglia massima. Se l'utilizzo corrente è inaspettato, esaminare i criteri di rete configurati per ridurre l'utilizzo a un livello minore o uguale rispetto alla soglia massima.

È stata violata una capacità massima.

Quando viene rilevato l'evento: Il numero di oggetti definiti nel sistema per {capacity_display_name} è {capacity_usage_count}, ovvero un valore superiore al numero massimo supportato di {max_supported_capacity_count}. "

Quando l'evento viene risolto: Il numero di oggetti definiti nel sistema per {capacity_display_name} è {capacity_usage_count}, ovvero un valore minore o uguale al numero massimo supportato di {max_supported_capacity_count}. "

Assicurarsi che il numero di oggetti di NSX creati rientra nei limiti supportati da NSX. Se sono presenti oggetti inutilizzati, eliminarli utilizzando la rispettiva interfaccia utente o l'API di NSX dal sistema. È consigliabile aumentare il fattore di forma di tutti i nodi di Manager e/o i nodi Edge. Si noti che il fattore modulo di ogni tipo di nodo deve essere lo stesso. In caso contrario, vengono utilizzati i limiti di capacità per il fattore di forma più basso distribuito.

Un certificato è scaduto.

Quando viene rilevato l'evento: "Il certificato {entity_id} è scaduto. "

Quando l'evento viene risolto: "Il certificato scaduto {entity_id} è stato rimosso o non è più scaduto. "

Assicurarsi che i servizi che attualmente utilizzano il certificato vengano aggiornati in modo da utilizzare un nuovo certificato non scaduto. Quando il certificato scaduto non è più in uso, deve essere eliminato richiamando l'NSX API DELETE {api_collection_path}{entity_id}. Se il certificato scaduto viene utilizzato da NAPP Platform, la connessione tra NSX e NAPP Platform viene interrotta. Consultare il documento di risoluzione dei problemi di NAPP Platform per utilizzare un certificato CA NAPP autofirmato per il ripristino della connessione.

Un certificato sta per scadere.

Quando viene rilevato l'evento: "Il certificato {entity_id} sta per scadere. "

Quando l'evento viene risolto: "Il certificato in scadenza {entity_id} è stato rimosso o non sta più per scadere. "

Assicurarsi che i servizi che attualmente utilizzano il certificato vengano aggiornati in modo da utilizzare un nuovo certificato non in scadenza. Quando il certificato in scadenza non è più in uso, deve essere eliminato richiamando l'NSX API DELETE {api_collection_path}{entity_id}.

Un certificato sta per scadere.

Quando viene rilevato l'evento: "Il certificato {entity_id} sta per scadere. "

Quando l'evento viene risolto: "Il certificato in scadenza {entity_id} è stato rimosso o non sta più per scadere. "

Assicurarsi che i servizi che attualmente utilizzano il certificato vengano aggiornati in modo da utilizzare un nuovo certificato non in scadenza. Quando il certificato in scadenza non è più in uso, deve essere eliminato richiamando l'NSX API DELETE {api_collection_path}{entity_id}.

È consigliabile aggiornare un bundle CA attendibile.

Quando viene rilevato l'evento: "Il bundle CA attendibile {entity_id} è stato aggiornato più di {ca_bundle_age_threshold} giorni fa. È consigliabile aggiornare il bundle CA attendibile. "

Quando l'evento viene risolto: Il bundle CA attendibile {entity_id} è stato rimosso, aggiornato o non è più in uso. "

Assicurarsi che i servizi che attualmente utilizzano il bundle CA attendibile vengano aggiornati in modo da utilizzare un bundle CA attendibile aggiornato di recente. A meno che non sia un bundle fornito dal sistema, il bundle può essere aggiornato utilizzando l'NSX API PUT /policy/api/v1/infra/cabundles/{entity_id}. Quando il bundle scaduto non è più in uso, deve essere eliminato (se non fornito dal sistema) richiamando l'NSX API DELETE /policy/api/v1/infra/cabundles/{entity_id}.

Si consiglia di aggiornare un bundle CA attendibile.

Quando viene rilevato l'evento: "Il bundle CA attendibile {entity_id} è stato aggiornato più di {ca_bundle_age_threshold} giorni fa. È consigliabile aggiornare il bundle CA attendibile. "

Quando l'evento viene risolto: Il bundle CA attendibile {entity_id} è stato rimosso, aggiornato o non è più in uso. "

Assicurarsi che i servizi che attualmente utilizzano il bundle CA attendibile vengano aggiornati in modo da utilizzare un bundle CA attendibile aggiornato di recente. A meno che non sia un bundle fornito dal sistema, il bundle può essere aggiornato utilizzando l'NSX API PUT /policy/api/v1/infra/cabundles/{entity_id}. Quando il bundle scaduto non è più in uso, deve essere eliminato (se non fornito dal sistema) richiamando l'NSX API DELETE /policy/api/v1/infra/cabundles/{entity_id}.

Un certificato è scaduto.

Quando viene rilevato l'evento: "Il certificato per il nodo di trasporto {entity_id} è scaduto. "

Quando l'evento viene risolto: "Il certificato scaduto per il nodo di trasporto {entity_id} è stato sostituito o non è più scaduto. "

Sostituire il certificato del nodo di trasporto {entity_id} con un certificato non scaduto. Il certificato scaduto deve essere sostituito richiamando l'NSX API POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}. Se il certificato scaduto viene utilizzato dal nodo di trasporto, la connessione tra il nodo di trasporto e il nodo di gestione viene interrotta.

Un certificato sta per scadere.

Quando viene rilevato l'evento: "Il certificato per il nodo di trasporto {entity_id} sta per scadere. "

Quando l'evento viene risolto: "Il certificato in scadenza per il nodo di trasporto {entity_id} è stato rimosso o non sta più per scadere. "

Sostituire il certificato del nodo di trasporto {entity_id} con un certificato non scaduto. Il certificato scaduto deve essere sostituito richiamando l'NSX API POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}. Se il certificato non viene sostituito, alla scadenza la connessione tra il nodo di trasporto e il nodo di Manager verrà interrotta.

Un certificato sta per scadere.

Quando viene rilevato l'evento: "Il certificato per il nodo di trasporto {entity_id} sta per scadere. "

Quando l'evento viene risolto: "Il certificato in scadenza per il nodo di trasporto {entity_id} è stato rimosso o non sta più per scadere. "

Sostituire il certificato del nodo di trasporto {entity_id} con un certificato non scaduto. Il certificato scaduto deve essere sostituito richiamando l'NSX API POST /api/v1/trust-management/certificates/action/replace-host-certificate/{entity_id}. Se il certificato non viene sostituito, alla scadenza la connessione tra il nodo di trasporto e il nodo di Manager verrà interrotta.

Membro del gruppo inattivo.

Quando viene rilevato l'evento: "Il membro del gruppo {manager_node_id} del servizio {group_type} è inattivo. "

Quando l'evento viene risolto: "Il membro del gruppo {manager_node_id} di {group_type} è attivo. "

1. Richiamare il comando "get cluster status" della CLI di NSX per visualizzare lo stato dei membri del gruppo del cluster.
2. Assicurarsi che il servizio per {group_type} sia in esecuzione nel nodo. Richiamare l'NSX API GET /api/v1/node/services/&ltservice_name>/status o il comando della CLI di NSX get service &ltservice_name&gt per determinare se il servizio è in esecuzione. Se non è in esecuzione, richiamare l'NSX API POST /api/v1/node/services/&ltservice_name&gt?action=restart o il comando della CLI di NSX restart &ltservice_name&gt per riavviare il servizio.
3. Controllare /var/log/ del servizio {group_type} per verificare se sono stati segnalati errori.

Tutti i membri del gruppo del servizio sono inattivi.

Quando viene rilevato l'evento: "Tutti i membri del gruppo {manager_node_ids} del servizio {group_type} sono inattivi. "

Quando l'evento viene risolto: "Tutti i membri del gruppo {manager_node_ids} del servizio {group_type} sono attivi. "

1. Assicurarsi che il servizio per {group_type} sia in esecuzione nel nodo. Richiamare l'NSX API GET /api/v1/node/services/&ltservice_name>/status o il comando della CLI di NSX get service &ltservice_name&gt per determinare se il servizio è in esecuzione. Se non è in esecuzione, richiamare l'NSX API POST /api/v1/node/services/&ltservice_name&gt?action=restart o il comando della CLI di NSX restart &ltservice_name&gt per riavviare il servizio.
2. Controllare /var/log/ del servizio {group_type} per verificare se sono stati segnalati errori.

L'Hyperbus nella DPU non può comunicare con il nodo di Manager.

Quando viene rilevato l'evento: "Hyperbus nella DPU {dpu_id} non può comunicare con il nodo di Manager. "

Quando l'evento viene risolto: "Hyperbus nella DPU {dpu_id} può comunicare con il nodo di Manager. "

È possibile che manchi l'interfaccia hyperbus vmkernel (vmk50) nella DPU {dpu_id}. Fare riferimento all'articolo della Knowledge Base https://kb.vmware.com/s/article/67432.

Hyperbus non può comunicare con il nodo di Manager.

Quando viene rilevato l'evento: "Hyperbus non può comunicare con il nodo di Manager. "

Quando l'evento viene risolto: "Hyperbus può comunicare con il nodo di Manager. "

È possibile che manchi l'interfaccia hyperbus vmkernel (vmk50). Fare riferimento all'articolo della Knowledge Base https://kb.vmware.com/s/article/67432.

L'agente di raccolta specificato non può essere raggiunto tramite vmknic in un DVS specificato nella DPU.

Quando viene rilevato l'evento: "Il {collector_ip} dell'agente di raccolta {vertical_name} non può essere raggiunto tramite vmknic (stack {stack_alias}) in DVS {dvs_alias} nella DPU {dpu_id}, ma è raggiungibile tramite vmknic (stack {stack_alias}) su altri DVS. "

Quando l'evento viene risolto: "L'agente di raccolta {vertical_name} {collector_ip} può essere raggiunto tramite vmknic (stack {stack_alias}) in DVS {dvs_alias} nella DPU {dpu_id} oppure l'agente di raccolta l'{collector_ip} {vertical_name} non è completamente raggiungibile. "

Se l'avviso è attivo, non significa che l'agente di raccolta è irraggiungibile. I flussi esportati generati verticalmente in base al DVS {dvs_alias} possono comunque raggiungere l'agente di raccolta {collector_ip} tramite vmknic nei DVS oltre che nei DVS {dvs_alias}. Se questa situazione non è accettabile, l'utente può provare a creare vmknic con stack {stack_alias} in DVS {dvs_alias} e configurarlo con l'indirizzo IPv4(6) appropriato, quindi verificare se l'{collector_ip} dell'agente di raccolta {vertical_name} può essere raggiunto tramite i vmknic appena creati nella DPU {dpu_id} richiamando vmkping {collector_ip} -S {stack_alias} -I vmkX con da SSH a DPU tramite ESXi abilitato.

L'agente di raccolta specificato non può essere raggiunto tramite vmknic esistenti nella DPU.

Quando viene rilevato l'evento: "L'agente di raccolta {vertical_name} {collector_ip} non può essere raggiunto tramite vmknic esistenti (stack {stack_alias}) in qualsiasi DVS nella DPU {dpu_id}. "

Quando l'evento viene risolto: "L'agente di raccolta {vertical_name} {vertical_name} può essere raggiunto con vmknic (stack {stack_alias}) esistenti nella DPU {dpu_id}. "

Per rendere l'agente di raccolta raggiungibile per il verticale specificato in DVS, l'utente deve verificare che siano presenti vmknic con stack {stack_alias} previsto creato e configurato con indirizzi IPv4(6) appropriati e che anche la connessione di rete all'agente di raccolta {vertical_name} {collector_ip} sia valida. L'utente deve quindi eseguire il controllo della DPU {dpu_id} ed eseguire la configurazione richiesta per assicurarsi che la condizione venga soddisfatta. Infine, se vmkping {collector_ip} -S {stack_alias} con da SSH a DPU tramite ESXi abilitata riesce, significa che il problema è stato eliminato.

La latenza di rete media tra i nodi di Manager è elevata.

Quando viene rilevato l'evento: "La latenza di rete media tra i nodi di Manager {manager_node_id} ({appliance_address}) e {remote_manager_node_id} ({remote_appliance_address}) è superiore a 10 ms negli ultimi 5 minuti. "

Quando l'evento viene risolto: "La latenza di rete media tra i nodi di Manager {manager_node_id} ({appliance_address}) e {remote_manager_node_id} ({remote_appliance_address}) rientra nei 10 ms. "

Assicurarsi che tra i nodi di Manager non siano presenti regole del firewall che blocchino il traffico ping. Se sono presenti altri server con larghezza di banda elevata e applicazioni che condividono la rete locale, è consigliabile spostarle in una rete diversa.

La connessione del piano di controllo del nodo di trasporto al nodo di gestione resta inattiva per molto tempo.

Quando viene rilevato l'evento: "La connessione del piano di controllo del nodo di trasporto {entity_id} al nodo di Manager {appliance_address} è inattiva per almeno {timeout_in_minutes} minuti dal punto di vista del nodo di trasporto. "

Quando l'evento viene risolto: "Il nodo di trasporto {entity_id} ripristina la connessione del piano di controllo al nodo di Manager {appliance_address}. "

1. Controllare la connettività dal nodo di trasporto {entity_id} all'interfaccia del nodo di Manager {appliance_address} tramite un ping. Se non è possibile eseguire il ping, verificare l'affidabilità della connettività di rete.
2. Verificare che le connessioni TCP siano stabilite utilizzando l'output netstat per vedere se il servizio Controller sul nodo di Manager {appliance_address} è in ascolto delle connessioni sulla porta 1235. In caso contrario, controllare le regole iptables (o) del firewall per verificare se la porta 1235 sta bloccando le richieste di connessione del nodo di trasporto {entity_id}. Assicurarsi che nell'underlay non siano presenti firewall host o firewall di rete che bloccano le porte IP necessarie tra i nodi di gestione e i nodi di trasporto. Questo è documentato nello strumento per porte e protocolli disponibile qui: https://ports.vmware.com/.
3. È possibile che il nodo di trasporto {entity_id} sia ancora in modalità di manutenzione. È possibile verificarlo tramite la seguente API: GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt. Quando è impostata la modalità di manutenzione, il nodo di trasporto non viene connesso al servizio Controller. Ciò si verifica in genere quando è in corso l'aggiornamento dell'host. Attendere alcuni minuti e verificare nuovamente la connettività.

La connessione del piano di controllo del nodo di trasporto al nodo di gestione è inattiva.

Quando viene rilevato l'evento: "La connessione del piano di controllo del nodo di trasporto {entity_id} al nodo di Manager {appliance_address} è inattiva per almeno {timeout_in_minutes} minuti dal punto di vista del nodo di trasporto. "

Quando l'evento viene risolto: "Il nodo di trasporto {entity_id} ripristina la connessione del piano di controllo al nodo di Manager {appliance_address}. "

1. Controllare la connettività dal nodo di trasporto {entity_id} all'interfaccia del nodo di Manager {appliance_address} tramite un ping. Se non è possibile eseguire il ping, verificare l'affidabilità della connettività di rete.
2. Verificare che le connessioni TCP siano stabilite utilizzando l'output netstat per vedere se il servizio Controller sul nodo di Manager {appliance_address} è in ascolto delle connessioni sulla porta 1235. In caso contrario, controllare le regole iptables (o) del firewall per verificare se la porta 1235 sta bloccando le richieste di connessione del nodo di trasporto {entity_id}. Assicurarsi che nell'underlay non siano presenti firewall host o firewall di rete che bloccano le porte IP necessarie tra i nodi di gestione e i nodi di trasporto. Questo è documentato nello strumento per porte e protocolli disponibile qui: https://ports.vmware.com/.
3. È possibile che il nodo di trasporto {entity_id} sia ancora in modalità di manutenzione. È possibile verificarlo tramite la seguente API: GET https://&ltnsx-mgr&gt/api/v1/transport-nodes/&lttn-uuid&gt Quando è impostata la modalità di manutenzione, il nodo di trasporto non viene connesso al servizio Controller. Ciò si verifica in genere quando è in corso l'aggiornamento dell'host. Attendere alcuni minuti e verificare nuovamente la connettività. Nota: questo allarme non è critico e deve essere risolto. Non è necessario contattare GSS per la notifica di questo allarme, a meno che l'allarme non venga risolto nel corso di un intervallo di tempo esteso.

La connessione del nodo di trasporto al servizio Controller è inattiva.

Quando viene rilevato l'evento: "Connessione del servizio Controller del nodo di Manager {appliance_address} ({central_control_plane_id}) al nodo di trasporto {transport_node_name} ({entity_id}) inattiva per almeno tre minuti dal punto di vista del servizio Controller. "

Quando l'evento viene risolto: "Il servizio Controller del nodo di Manager {appliance_address} ({central_control_plane_id}) ripristina la connessione al nodo di trasporto {entity_id}. "

1. Verificare la connettività dal servizio Controller {central_control_plane_id} e dall'interfaccia del nodo di trasporto {entity_id} tramite un ping e traceroute. Questa operazione può essere eseguita nella CLI admin del nodo di NSX Manager. Il test di ping non dovrebbe visualizzare interruzioni e ha valori di latenza coerenti. VMware consiglia valori di latenza di 150 ms o inferiori.
2. Passare a Sistema | Infrastruttura | Nodi | Nodo di trasporto {entity_id} nell'interfaccia utente NSX per verificare se le connessioni TCP tra il servizio Controller nel nodo di Manager {appliance_address} ({central_control_plane_id}) e il nodo di trasporto {entity_id} sono stabilite. In caso contrario, controllare le regole del firewall sulla rete e sugli host per vedere se la porta 1235 sta bloccando le richieste di connessione del nodo di trasporto {entity_id}. Assicurarsi che nell'underlay non siano presenti firewall host o firewall di rete che bloccano le porte IP necessarie tra i nodi di gestione e i nodi di trasporto. Questo è documentato nello strumento per porte e protocolli disponibile qui: https://ports.vmware.com/.

La connessione del nodo di trasporto al servizio controller è inattiva per troppo tempo.

Quando viene rilevato l'evento: "Connessione del servizio Controller del nodo di Manager {appliance_address} ({central_control_plane_id}) al nodo di trasporto {transport_node_name} ({entity_id}) inattiva per almeno 15 minuti dal punto di vista del servizio Controller. "

Quando l'evento viene risolto: "Il servizio Controller del nodo di Manager {appliance_address} ({central_control_plane_id}) ripristina la connessione al nodo di trasporto {entity_id}. "

1. Verificare la connettività dal servizio Controller {central_control_plane_id} e dall'interfaccia del nodo di trasporto {entity_id} tramite un ping e traceroute. Questa operazione può essere eseguita nella CLI admin del nodo di NSX Manager. Il test di ping non dovrebbe visualizzare interruzioni e ha valori di latenza coerenti. VMware consiglia valori di latenza di 150 ms o inferiori.
2. Passare a Sistema | Infrastruttura | Nodi | Nodo di trasporto {entity_id} nell'interfaccia utente NSX per verificare se le connessioni TCP tra il servizio Controller nel nodo di Manager {appliance_address} ({central_control_plane_id}) e il nodo di trasporto {entity_id} sono stabilite. In caso contrario, controllare le regole del firewall sulla rete e sugli host per vedere se la porta 1235 sta bloccando le richieste di connessione del nodo di trasporto {entity_id}. Assicurarsi che nell'underlay non siano presenti firewall host o firewall di rete che bloccano le porte IP necessarie tra i nodi di gestione e i nodi di trasporto. Questo è documentato nello strumento per porte e protocolli disponibile qui: https://ports.vmware.com/.

Il canale di controllo verso il canale di gestione è inattivo.

Quando viene rilevato l'evento: La comunicazione tra la funzione di gestione e la funzione di controllo non è riuscita nel nodo di Manager {manager_node_name} ({appliance_address}). "

Quando l'evento viene risolto: La comunicazione tra la funzione di gestione e la funzione di controllo è stata ripristinata nel nodo di Manager {manager_node_name} ({appliance_address}). "

1. Nel nodo di Manager {manager_node_name} ({appliance_address}), richiamare il seguente comando della CLI di NSX: get service applianceproxy per controllare lo stato del servizio periodicamente per 60 minuti.
2. Se il servizio non è in esecuzione per più di 60 minuti, richiamare il seguente comando della CLI di NSX: restart service applianceproxy e ricontrollare lo stato. Se il servizio è ancora inattivo, contattare l'assistenza VMware.

Il canale di gestione verso il nodo di trasporto è inattivo.

Quando viene rilevato l'evento: "Il canale di gestione verso il nodo di trasporto {transport_node_name} ({transport_node_address}) è inattivo per 5 minuti. "

Quando l'evento viene risolto: Il canale di gestione verso il nodo di trasporto {transport_node_name} ({transport_node_address}) è attivo. "

Verificare la connettività di rete tra i nodi di Manager e il nodo di trasporto {transport_node_name} ({transport_node_address}) e che nessun firewall stia bloccando il traffico tra i nodi. Nei nodi di trasporto di Windows, verificare che il servizio nsx-proxy sia in esecuzione nel nodo di trasporto richiamando il comando C:\NSX\nsx-proxy\nsx-proxy.ps1 status in Windows PowerShell. Se non è in esecuzione, riavviarlo richiamando il comando C:\NSX\nsx-proxy\nsx-proxy.ps1 restart. In tutti gli altri nodi di trasporto, verificare che il servizio nsx-proxy sia in esecuzione nel nodo di trasporto richiamando il comando: /etc/init.d/nsx-proxy status. Se non è in esecuzione, riavviarlo richiamando il comando /etc/init.d/nsx-proxy restart.

Il canale di gestione verso il nodo di trasporto è inattivo troppo a lungo.

Quando viene rilevato l'evento: "Il canale di gestione verso il nodo di trasporto {transport_node_name} ({transport_node_address}) è inattivo per 15 minuti. "

Quando l'evento viene risolto: Il canale di gestione verso il nodo di trasporto {transport_node_name} ({transport_node_address}) è attivo. "

Verificare la connettività di rete tra i nodi di Manager e il nodo di trasporto {transport_node_name} ({transport_node_address}) e che nessun firewall stia bloccando il traffico tra i nodi. Nei nodi di trasporto di Windows, verificare che il servizio nsx-proxy sia in esecuzione nel nodo di trasporto richiamando il di comando he Transport node by invoking the command C:\NSX\nsx-proxy\nsx-proxy.ps1 status in Windows PowerShell. Se non è in esecuzione, riavviarlo richiamando il comando C:\NSX\nsx-proxy\nsx-proxy.ps1 restart. In tutti gli altri nodi di trasporto, verificare che il servizio nsx-proxy sia in esecuzione nel nodo di trasporto richiamando il comando: /etc/init.d/nsx-proxy status. Se non è in esecuzione, riavviarlo richiamando il comando /etc/init.d/nsx-proxy restart.

Ricerca DNS non riuscita per il nome di dominio completo del nodo di gestione.

Quando viene rilevato l'evento: "Ricerca DNS non riuscita per il nodo di Manager {entity_id} con FQDN {appliance_fqdn} ed è stato impostato il contrassegno publish_fqdns. "

Quando l'evento viene risolto: "La ricerca dell'FQDN è riuscita per il nodo di Manager {entity_id} con FQDN {appliance_fqdn} o il contrassegno del publish_fqdns è stato cancellato. "

1. Assegnare i nomi di dominio completi corretti a tutti i nodi di gestione e verificare che la configurazione DNS sia corretta per la ricerca corretta dei nomi di dominio completi di tutti i nodi di gestione.
2. In alternativa, disabilitare l'utilizzo dei nomi di dominio completi richiamando l'NSX API PUT /api/v1/configs/management con publish_fqdns impostato su False nel corpo della richiesta. Dopo di che le chiamate dai nodi di trasporto e dalla federazione ai nodi di gestione in questo cluster utilizzeranno solo indirizzi IP.

Ricerca DNS inversa non riuscita per l'indirizzo IP del nodo di gestione.

Quando viene rilevato l'evento: "Ricerca DNS inversa non riuscita per nodo di Manager {entity_id} con indirizzo IP {appliance_address} ed è stato impostato il contrassegno publish_fqdns. "

Quando l'evento viene risolto: "La ricerca DNS inversa è riuscita per il nodo di Manager {entity_id} con indirizzo IP {appliance_address} o il contrassegno publish_fqdns è stato cancellato. "

1. Assegnare i nomi di dominio completi corretti a tutti i nodi di gestione e verificare che la configurazione DNS sia corretta per la ricerca inversa avvenuta con successo dell'indirizzo IP del nodo di gestione.
2. In alternativa, disabilitare l'utilizzo dei nomi di dominio completi richiamando l'NSX API PUT /api/v1/configs/management con publish_fqdns impostato su False nel corpo della richiesta. Dopo di che le chiamate dai nodi di trasporto e dalla federazione ai nodi di gestione in questo cluster utilizzeranno solo indirizzi IP.

Il canale di gestione verso il nodo di Manager è inattivo.

Quando viene rilevato l'evento: "Il canale di gestione al nodo di Manager {manager_node_id} ({appliance_address}) è inattivo per 5 minuti. "

Quando l'evento viene risolto: Il canale di gestione verso il nodo di Manager {manager_node_id} ({appliance_address}) è attivo. "

Verificare la connettività di rete tra il nodo di trasporto {transport_node_id} e il nodo di Manager master. Assicurarsi inoltre che il traffico tra i nodi non venga bloccato da alcun firewall. Assicurarsi che il servizio di gestione messaggi sia in esecuzione nei nodi di Manager richiamando il comando /etc/init.d/messaging-manager status. Se il servizio di gestione messaggi non è in esecuzione, riavviarlo richiamando il comando /etc/init.d/messaging-manager restart.

Il canale di gestione verso il nodo di Manager è inattivo troppo a lungo.

Quando viene rilevato l'evento: "Il canale di gestione al nodo di Manager {manager_node_id} ({appliance_address}) è inattivo per 15 minuti. "

Quando l'evento viene risolto: Il canale di gestione verso il nodo di Manager {manager_node_id} ({appliance_address}) è attivo. "

Verificare la connettività di rete tra il nodo di trasporto {transport_node_id} e i nodi di Manager master. Assicurarsi inoltre che il traffico tra i nodi non venga bloccato da alcun firewall. Assicurarsi che il servizio di gestione messaggi sia in esecuzione nei nodi di Manager richiamando il comando /etc/init.d/messaging-manager status. Se il servizio di gestione messaggi non è in esecuzione, riavviarlo richiamando il comando /etc/init.d/messaging-manager restart.

La latenza della rete di gestione verso il nodo di trasporto è elevata.

Quando viene rilevato l'evento: La latenza di rete media tra i nodi del gestore e l'host {transport_node_name} ({transport_node_address}) è superiore a 150 ms per 5 minuti. "

Quando l'evento viene risolto: La latenza di rete media tra i nodi del gestore e l'host {transport_node_name} ({transport_node_address}) è normale. "

1. Attendere 5 minuti per verificare se l'allarme viene risolto automaticamente.
2. Eseguire il ping del nodo di trasporto di NSX dal nodo di Manager. Il test di ping non dovrebbe visualizzare interruzioni e ha valori di latenza coerenti. VMware consiglia valori di latenza di 150 ms o inferiori.
3. Verificare se sono presenti altri problemi del livello di rete fisica. Se il problema persiste, contattare l'assistenza VMware.

Gli indirizzi IP di un pool di IP sono esauriti.

Quando viene rilevato l'evento: "Gli indirizzi nel pool di IP {entity_id} del server DHCP {dhcp_server_id} sono esauriti. L'ultima richiesta DHCP non è riuscita e le richieste future non riusciranno. "

Quando l'evento viene risolto: "Il pool di IP {entity_id} del server DHCP {dhcp_server_id} non è più esaurito. Viene allocato un lease all'ultima richiesta DHCP. "

Esaminare la configurazione del pool DHCP nell'interfaccia utente di NSX o nel nodo Edge in cui il server DHCP è in esecuzione richiamando il comando della CLI di NSX get dhcp ip-pool. Esaminare anche i lease attualmente attivi nel nodo Edge richiamando il comando della CLI di NSX get dhcp lease. Confrontare i lease con il numero di macchine virtuali attive. È consigliabile ridurre la durata del lease nella configurazione del server DHCP se il numero di macchine virtuali è basso rispetto al numero di lease attivi. È inoltre consigliabile espandere l'intervallo di pool per il server DHCP nella pagina Rete | Segmenti | Segmento nell'interfaccia utente di NSX.

Un pool di IP è sovraccarico.

Quando viene rilevato l'evento: "L'utilizzo del pool di IP {entity_id} del server DHCP {dhcp_server_id} sta per esaurirsi, con il {dhcp_pool_usage}% di IP allocati. "

Quando l'evento viene risolto: "Il pool di IP {entity_id} del server DHCP {dhcp_server_id} è sceso al di sotto della soglia di utilizzo elevato. "

Esaminare la configurazione del pool DHCP nell'interfaccia utente di NSX o nel nodo Edge in cui il server DHCP è in esecuzione richiamando il comando della CLI di NSX get dhcp ip-pool. Esaminare anche i lease attualmente attivi nel nodo Edge richiamando il comando della CLI di NSX get dhcp lease. Confrontare i lease con il numero di macchine virtuali attive. È consigliabile ridurre la durata del lease nella configurazione del server DHCP se il numero di macchine virtuali è basso rispetto al numero di lease attivi. È inoltre consigliabile espandere l'intervallo di pool per il server DHCP nella pagina Rete | Segmenti | Segmento nell'interfaccia utente di NSX.

L'utilizzo della CPU DFW è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU DFW nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU DFW nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host. Esaminare la progettazione della sicurezza per l'ottimizzazione. Ad esempio, utilizzare la configurazione applicabile se le regole non sono applicabili all'intero data center.

L'utilizzo della CPU DFW è molto elevato in DPU.

Quando viene rilevato l'evento: "L'utilizzo della CPU DFW nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}% nella DPU {dpu_id} che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU DFW nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}% nella DPU {dpu_id}, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host. Esaminare la progettazione della sicurezza per l'ottimizzazione. Ad esempio, utilizzare la configurazione applicabile se le regole non sono applicabili all'intero data center.

L'utilizzo della memoria DFW è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria DFW {heap_type} nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria DFW {heap_type} nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Visualizzare l'utilizzo corrente della memoria DFW richiamando il comando della CLI di NSX get firewall thresholds nell'host. È consigliabile bilanciare di nuovo i carichi di lavoro di questo host rispetto agli altri host.

L'utilizzo della memoria DFW è molto elevato in DPU.

Quando viene rilevato l'evento: "L'utilizzo della memoria DFW {heap_type} nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}% nella DPU {dpu_id} che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria DFW {heap_type} nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}% nella DPU {dpu_id} che è inferiore al valore di soglia molto elevato di {system_usage_threshold}%. "

Visualizzare l'utilizzo corrente get firewall Soglia della memoria DFW richiamando il comando della CLI di NSX get firewall thresholds nella DPU. È consigliabile bilanciare di nuovo i carichi di lavoro di questo host rispetto agli altri host.

DFW vMotion non riuscito, porta disconnessa.

Quando viene rilevato l'evento: "La vMotion DFW per il filtro DFW {entity_id} nell'host di destinazione {transport_node_name} non è riuscita e la porta per l'entità è stata disconnessa. "

Quando l'evento viene risolto: "La configurazione DFW per il filtro DFW {entity_id} nell'host di destinazione {transport_node_name} è riuscita e l'errore è causato da un errore vMotion DFW cancellato. "

Controllare le macchine virtuali nell'host in NSX Manager, quindi eseguire manualmente il push della configurazione di DFW tramite l'interfaccia utente di NSX Manager. Il criterio DFW di cui rieseguire il push può essere tracciato dal filtro DFW {entity_id}. È inoltre consigliabile trovare la macchina virtuale a cui è collegato il filtro DFW e riavviarla.

Il limite del flood DFW ha raggiunto il livello di avviso.

Quando viene rilevato l'evento: "Il limite del flood DFW per il filtro DFW {entity_id} nell'host {transport_node_name} ha raggiunto il livello di avviso dell'80% del limite configurato per il protocollo {protocol_name}. "

Quando l'evento viene risolto: "La condizione del limite del flood di avviso per il filtro DFW {entity_id} nell'host {transport_node_name} per il protocollo {protocol_name} è stata cancellata. "

Controllare le macchine virtuali nell'host in NSX Manager. Controllare il livello di avviso del flood configurato del filtro DFW {entity_id} per il protocollo {protocol_name}.

Il limite del flood DFW ha raggiunto il livello critico.

Quando viene rilevato l'evento: "Il limite del flood DFW per il filtro DFW {entity_id} nell'host {transport_node_name} ha raggiunto il livello critico del 98% del limite configurato per il protocollo {protocol_name}. "

Quando l'evento viene risolto: "La condizione del limite del flood critico per il filtro DFW {entity_id} nell'host {transport_node_name} per il protocollo {protocol_name} è stata cancellata. "

Controllare le macchine virtuali nell'host in NSX Manager. Controllare il livello critico del flood configurato del filtro DFW {entity_id} per il protocollo {protocol_name}.

Il numero di sessioni DFW è elevato.

Quando viene rilevato l'evento: "Il numero di sessioni DFW è elevato nel nodo di trasporto {entity_id}, ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia del {system_usage_threshold}%. "

Quando l'evento viene risolto: "Il conteggio sessioni DFW nel nodo di trasporto {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia del {system_usage_threshold}%. "

Esaminare il livello di carico del traffico di rete dei carichi di lavoro nell'host. È consigliabile bilanciare di nuovo i carichi di lavoro di questo host rispetto agli altri host.

Il limite delle regole DFW per vNIC sta per superare il limite massimo.

Quando viene rilevato l'evento: "Il limite delle regole DFW per il VIF {entity_id} nell'host di destinazione {transport_node_name} sta per superare il limite massimo. "

Quando l'evento viene risolto: "Il limite delle regole DFW per i VIF {entity_id} nell'host di destinazione {transport_node_name} è sceso al di sotto del limite massimo. "

Accedere all'host ESX {transport_node_name} e richiamare il comando della CLI di NSX get firewall &ltVIF_UUID&gt ruleset rules per ottenere le statistiche della regola per le regole configurate nella VIF corrispondente. Ridurre il numero di regole configurate per VIF {entity_id}.

Il limite delle regole DFW per vNIC si avvicina al limite massimo.

Quando viene rilevato l'evento: "Il limite delle regole DFW per il VIF {entity_id} nell'host di destinazione {transport_node_name} sta per superare il limite massimo. "

Quando l'evento viene risolto: "Il limite delle regole DFW per i VIF {entity_id} nell'host di destinazione {transport_node_name} è sceso al di sotto della soglia. "

Accedere all'host ESX {transport_node_name} e richiamare il comando della CLI di NSX get firewall &ltVIF_UUID&gt ruleset rules per ottenere le statistiche della regola per le regole configurate nella VIF corrispondente. Ridurre il numero di regole configurate per VIF {entity_id}.

Il limite delle regole DFW per host sta per superare il limite massimo.

Quando viene rilevato l'evento: "Il limite delle regole DFW per l'host {transport_node_name} sta per superare il limite massimo. "

Quando l'evento viene risolto: "Il limite delle regole DFW per l'host {transport_node_name} è sceso al di sotto del limite massimo. "

Accedere all'host ESX {transport_node_name} e richiamare il comando della CLI di NSX get firewall rule-stats total per ottenere le statistiche della regola per le regole configurate nell'host ESX {transport_node_name}. Ridurre il numero di regole configurate per l'host {transport_node_name}. Controllare il numero di regole configurate per vari VIF utilizzando il comando della CLI di NSX get firewall &ltVIF_UUID&gt ruleset rules. Ridurre il numero di regole configurate per i vari VIF.

Il limite delle regole DFW per host si avvicina al limite massimo.

Quando viene rilevato l'evento: "Il limite delle regole DFW per l'host {transport_node_name} si avvicina al limite massimo. "

Quando l'evento viene risolto: "Il limite delle regole DFW per l'host {transport_node_name} è sceso al di sotto della soglia. "

Accedere all'host ESX {transport_node_name} e richiamare il comando della CLI di NSX get firewall rule-stats total per ottenere le statistiche della regola per le regole configurate nell'host ESX {transport_node_name}. Ridurre il numero di regole configurate per l'host {transport_node_name}. Controllare il numero di regole configurate per vari VIF utilizzando il comando della CLI di NSX get firewall &ltVIF_UUID&gt ruleset rules. Ridurre il numero di regole configurate per i vari VIF.

È stato raggiunto il numero massimo consentito di eventi di intrusione.

Quando viene rilevato l'evento: "Il numero di eventi di intrusione nel sistema è {ids_events_count}, che è maggiore del numero massimo consentito {max_ids_events_allowed}. "

Quando l'evento viene risolto: "Il numero di eventi di intrusione nel sistema è {ids_events_count}, che è inferiore al numero massimo consentito {max_ids_events_allowed}. "

Non è necessario alcun intervento manuale. Ogni 3 minuti verrà avviato automaticamente un processo di eliminazione che eliminerà il 10% dei record precedenti per riportare il numero totale di eventi di intrusione nel sistema al di sotto del valore di soglia di 1,5 milioni.

L'utilizzo della memoria del motore NSX-IDPS raggiunge il 75% o superiore.

Quando viene rilevato l'evento: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del 75%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del 75%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della memoria del motore NSX-IDPS raggiunge almeno il 75% in DPU.

Quando viene rilevato l'evento: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del 75% nella DPU {dpu_id}. "

Quando l'evento viene risolto: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto nella DPU {dpu_id} il {system_resource_usage}%, che è inferiore al valore di soglia elevato del 75%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della memoria del motore NSX-IDPS raggiunge l'85% o superiore.

Quando viene rilevato l'evento: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia medio alto dell'85%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia medio alto dell'85%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della memoria del motore NSX-IDPS raggiunge l'85% o superiore nella DPU.

Quando viene rilevato l'evento: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia medio alto dell'85% nella DPU {dpu_id}. "

Quando l'evento viene risolto: L'utilizzo della memoria del motore NSX-IDPS ha raggiunto nella DPU {dpu_id} il {system_resource_usage}%, che è inferiore al valore di soglia medio alto dell'85%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della memoria del motore NSX-IDPS raggiunge il 95% o superiore.

Quando viene rilevato l'evento: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del 95%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato dell'95%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della memoria del motore NSX-IDPS raggiunge il 95% o superiore nella DPU.

Quando viene rilevato l'evento: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato dell'95% nella DPU {dpu_id}. "

Quando l'evento viene risolto: "L'utilizzo della memoria del motore NSX-IDPS ha raggiunto nella DPU {dpu_id} il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato dell'95%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della CPU del motore NSX-IDPS raggiunge il 75% o superiore.

Quando viene rilevato l'evento: "L'utilizzo della CPU del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del 75%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del 75%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della CPU del motore NSX-IDPS raggiunge il 85% o superiore.

Quando viene rilevato l'evento: "L'utilizzo della CPU del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia medio alto del 85%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia medio alto dell'85%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

L'utilizzo della CPU del motore NSX-IDPS supera il 95% o superiore.

Quando viene rilevato l'evento: "L'utilizzo della CPU del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del 95%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del motore NSX-IDPS ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato dell'95%. "

È consigliabile bilanciare di nuovo i carichi di lavoro della macchina virtuale in questo host rispetto agli altri host.

NSX IDPS è abilitato tramite il criterio NSX e le regole IDPS sono configurate, ma il motore NSX-IDPS è inattivo.

Quando viene rilevato l'evento: "NSX IDPS è attivato tramite il criterio NSX e le regole IDPS sono configurate, ma il motore NSX-IDPS è inattivo. "

Quando l'evento viene risolto: "NSX IDPS si trova in uno dei casi seguenti. 1. NSX IDPS è disabilitato tramite il criterio NSX. 2. Il motore NSX IDPS è abilitato, il motore NSX-IDPS e vdpi sono attivi, NSX IDPS è stato abilitato e le regole IDPS vengono configurate tramite il criterio NSX. "

1. Verificare in /var/log/ nsx-syslog.log se sono segnalati errori.
2. Richiamare il comando della CLI di NSX get ids engine status per verificare se l'IDPS distribuito di NSX è disabilitato. In tal caso, richiamare /etc/init.d/nsx-idps start per avviare il servizio.
3. Richiamare il comando /etc/init.d/nsx-vdpi status per verificare che nsx-vdpi sia in esecuzione. In caso contrario, richiamare il comando /etc/init.d/nsx-vdpi start per avviare il servizio.

NSX IDPS è abilitato tramite il criterio NSX e le regole IDPS sono configurate, ma il motore NSX-IDPS è inattivo in DPU.

Quando viene rilevato l'evento: "NSX IDPS è abilitato tramite il criterio NSX e le regole IDPS sono configurate, ma il motore NSX-IDPS è inattivo nella DPU {dpu_id}. "

Quando l'evento viene risolto: "NSX IDPS si trova in uno dei casi seguenti nella DPU {dpu_id}. 1. NSX IDPS è disabilitato tramite il criterio NSX. 2. Il motore NSX IDPS è abilitato, il motore NSX-IDPS e vdpi sono attivi, NSX IDPS è stato abilitato e le regole IDPS vengono configurate tramite il criterio NSX. "

1. Controllare /var/log/nsx-idps/nsx-idps.log e /var/log/nsx-syslog.log per verificare se sono stati segnalati errori.
2. Richiamare il comando della CLI di NSX get ids engine status per verificare se l'IDPS distribuito di NSX è disabilitato. In tal caso, richiamare /etc/init.d/nsx-idps start per avviare il servizio.
3. Richiamare il comando /etc/init.d/nsx-vdpi status per verificare che nsx-vdpi sia in esecuzione. In caso contrario, richiamare il comando /etc/init.d/nsx-vdpi start per avviare il servizio.

L'utilizzo della CPU per il motore IDPS distribuito è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU per il motore IDPS distribuito è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU per il motore IDPS distribuito è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare il motivo dell'oversubscription. Spostare determinate applicazioni in un host diverso.

L'utilizzo della CPU per il motore IDPS distribuito è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU per il motore IDPS distribuito è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU per il motore IDPS distribuito è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare il motivo dell'oversubscription. Spostare determinate applicazioni in un host diverso.

L'utilizzo della rete per il motore IDPS distribuito è elevato.

Quando viene rilevato l'evento: "L'utilizzo della rete per il motore IDPS distribuito è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della rete per il motore IDPS distribuito è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare il motivo dell'oversubscription. Rivedere il motivo dell'oversubscription. Rivedere le regole IDPS per ridurre la quantità di traffico soggetto al servizio IDPS.

L'utilizzo della rete per il motore IDPS distribuito è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della rete per il motore IDPS distribuito è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della rete per il motore IDPS distribuito è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare il motivo dell'oversubscription. Rivedere il motivo dell'oversubscription. Rivedere le regole IDPS per ridurre la quantità di traffico soggetto al servizio IDPS.

Traffico interrotto dal motore IDPS distribuito a causa dell'oversubscription della CPU.

Quando viene rilevato l'evento: "Il motore IDPS non dispone di risorse CPU sufficienti e non è in grado di tenere il passo con il traffico in entrata, causando l'annullamento del traffico in eccesso. Per ulteriori dettagli, accedere all'host ESX ed eseguire il comando seguente: vsipioctl getdpiinfo -s e controllare le statistiche dell'oversubscription. "

Quando l'evento viene risolto: "Il motore IDPS distribuito dispone di risorse CPU adeguate e non rilascia alcun traffico. "

Esaminare il motivo dell'oversubscription. Spostare determinate applicazioni in un host diverso.

Traffico interrotto dal motore IDPS distribuito a causa dell'oversubscription della rete.

Quando viene rilevato l'evento: "Il motore IDPS non è in grado di tenere il passo con la velocità del traffico in entrata, causando l'annullamento del traffico in eccesso. Per ulteriori dettagli, accedere all'host ESX ed eseguire il comando seguente: vsipioctl getdpiinfo -s e controllare le statistiche dell'oversubscription. "

Quando l'evento viene risolto: "Il motore IDPS distribuito non rilascia alcun traffico. "

Esaminare il motivo dell'oversubscription. Rivedere il motivo dell'oversubscription. Rivedere le regole IDPS per ridurre la quantità di traffico soggetto al servizio IDPS.

Il motore IDPS distribuito ha ignorato il traffico a causa dell'oversubscription della CPU.

Quando viene rilevato l'evento: "Il motore IDPS non dispone di risorse CPU sufficienti e non è in grado di tenere il passo con il traffico in entrata, ignorando il traffico in eccesso. Per ulteriori dettagli, accedere all'host ESX ed eseguire il comando seguente: vsipioctl getdpiinfo -s e controllare le statistiche dell'oversubscription. "

Quando l'evento viene risolto: "Il motore IDPS distribuito dispone di risorse CPU adeguate e non ignora alcun traffico. "

Esaminare il motivo dell'oversubscription. Spostare determinate applicazioni in un host diverso.

Il motore IDPS distribuito ha ignorato il traffico a causa dell'oversubscription della rete.

Quando viene rilevato l'evento: "Il motore IDPS non è in grado di tenere il passo con la velocità del traffico in entrata, ignorando il traffico in eccesso. Per ulteriori dettagli, accedere all'host ESX ed eseguire il comando seguente: vsipioctl getdpiinfo -s e controllare le statistiche dell'oversubscription. "

Quando l'evento viene risolto: "Il motore IDPS distribuito non ignora alcun traffico. "

Esaminare il motivo dell'oversubscription. Rivedere il motivo dell'oversubscription. Rivedere le regole IDPS per ridurre la quantità di traffico soggetto al servizio IDPS.

Un server di inoltro DNS è inattivo.

Quando viene rilevato l'evento: "Il server di inoltro DNS {entity_id} non è in esecuzione. Questo influisce sul server di inoltro DNS configurato attualmente attivato. "

Quando l'evento viene risolto: "Il server di inoltro DNS {entity_id} è di nuovo in esecuzione. "

1. Richiamare il comando della CLI di NSX get dns-forwarders status per verificare se lo stato del server di inoltro DNS è inattivo.
2. Verificare in /var/log/syslog se sono segnalati errori.
3. Raccogliere un bundle di supporto e contattare il team di supporto di NSX.

Un server di inoltro DNS è disattivato.

Quando viene rilevato l'evento: "Il server di inoltro DNS {entity_id} è disabilitato. "

Quando l'evento viene risolto: "Il server di inoltro DNS {entity_id} è abilitato. "

1. Richiamare il comando della CLI di NSX get dns-forwarders status per verificare se lo stato del server di inoltro DNS è disabilitato.
2. Utilizzare l'API dei criteri NSX o l'API Manager per abilitare il server di inoltro DNS, che non deve trovarsi nello stato disabilitato.

Timeout di un server upstream di inoltro DNS.

Quando viene rilevato l'evento: "Il server di inoltro DNS {intent_path}({dns_id}) non ha ricevuto una risposta tempestiva dal server upstream {dns_upstream_ip}. Ciò potrebbe influire sulla connettività dell'istanza di elaborazione ai nomi di dominio completi in timeout. "

Quando l'evento viene risolto: "Il server upstream di inoltro DNS {intent_path}({dns_id}) {dns_upstream_ip} è normale. "

1. Richiamare l'NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt&server_ip={dns_upstream_ip}&source_ip=&ltsource_ip&gt. Questa richiesta API attiva una ricerca DNS nel server upstream nello spazio dei nomi della rete del server di inoltro DNS. &ltaddress&gt è l'indirizzo IP o l'FQDN dello stesso dominio del server upstream. &ltsource_ip&gt è un indirizzo IP nella zona del server upstream. Se l'API restituisce una risposta con timeout della connessione, è probabile che si verifichi un errore di rete o un problema del server upstream. Controllare il motivo per cui le ricerche DSN non raggiungono il server upstream o il motivo per cui il server upstream non restituisce una risposta. Se la risposta dell'API indica che il server upstream risponde, procedere con il passaggio 2.
2. Richiamare l'NSX API GET /api/v1/dns/forwarders/{dns_id}/nslookup? address=&ltaddress&gt. Questa richiesta API attiva una ricerca DNS per il server di inoltro DNS. Se l'API restituisce una risposta valida, è possibile che il server upstream sia stato ripristinato e che questo allarme venga risolto entro alcuni minuti. Se l'API restituisce una risposta di connessione scaduta, procedere con il passaggio 3.
3. Richiamare il comando della CLI di NSX "get dns-forwarder {dns_id} live-debug server-ip {dns_upstream_ip}". Questo comando attiva il debug in tempo reale sul server upstream e registra i dettagli e le statistiche che mostrano il motivo per cui il server di inoltro DNS non riceve una risposta.

Impostazioni del nodo Edge non corrispondenti.

Quando viene rilevato l'evento: "La configurazione delle impostazioni del nodo Edge {entity_id} non corrisponde alla configurazione dello scopo del criterio. La configurazione del nodo Edge visibile per l'utente nell'interfaccia utente o nell'API non è identica a quella realizzata. Le modifiche al nodo Edge apportate dall'utente all'esterno di NSX Manager vengono visualizzate nei dettagli di questo allarme e tutte le modifiche apportate nell'interfaccia utente o nell'API sovrascriveranno la configurazione realizzata. I campi che differiscono per il nodo Edge sono elencati nei dati di runtime {edge_node_setting_mismatch_reason} "

Quando l'evento viene risolto: "Le impostazioni del nodo {entity_id} del nodo Edge ora sono coerenti con l'intento del criterio. "

Esaminare le impostazioni di questo nodo di trasporto Edge {entity_id}. Per risolvere l'allarme -
1, eseguire una delle seguenti azioni. Aggiornare manualmente lo scopo del criterio di impostazione del nodo di trasporto Edge utilizzando l'API PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Accettare le impostazioni del nodo Edge intenzionali o realizzate per questo nodo di trasporto Edge tramite il relativo resolver per risolvere questo allarme.
3. Risolvere l'allarme accettando la configurazione delle impostazioni del nodo Edge utilizzando l'API di aggiornamento POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.

Impostazioni vSphere macchina virtuale Edge non corrispondenti.

Quando viene rilevato l'evento: La configurazione del nodo Edge {entity_id} in vSphere non corrisponde alla configurazione dell'intento del criterio. La configurazione del nodo Edge visibile per l'utente nell'interfaccia utente o nell'API non è identica a quella realizzata. Le modifiche al nodo Edge apportate dall'utente all'esterno di NSX Manager vengono visualizzate nei dettagli di questo allarme e tutte le modifiche apportate nell'interfaccia utente o nell'API sovrascriveranno la configurazione realizzata. I campi che differiscono per il nodo Edge sono elencati nei dati di runtime {edge_vm_vsphere_settings_mismatch_reason} "

Quando l'evento viene risolto: "Le impostazioni vSphere della macchina virtuale del nodo edge {entity_id} ora sono coerenti con l'intento del criterio. "

Esaminare la configurazione vSphere di questo nodo di trasporto Edge {entity_id}. Per risolvere l'allarme -
1, eseguire una delle seguenti azioni. Accettare la configurazione del nodo Edge intenzionale o realizzata di vSphere realizzate per questo nodo di trasporto Edge tramite il relativo resolver per risolvere questo allarme.
2. Risolvere l'allarme accettando la configurazione realizzata del nodo Edge di vSphere utilizzando l'API di aggiornamento POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.

Le impostazioni del nodo Edge e le impostazioni vSphere sono cambiate.

Quando viene rilevato l'evento: "Le impostazioni del nodo Edge {entity_id} e la configurazione di vSphere sono state modificate e non corrispondono alla configurazione intenzionale del criterio. La configurazione del nodo Edge visibile per l'utente nell'interfaccia utente o nell'API non è identica a quella realizzata. Le modifiche al nodo Edge apportate dall'utente all'esterno di NSX Manager vengono visualizzate nei dettagli di questo allarme e tutte le modifiche apportate nell'interfaccia utente o nell'API sovrascriveranno la configurazione realizzata. I campi che differiscono per le impostazioni del nodo Edge e la configurazione di vSphere sono elencati nei dati di runtime {edge_node_settings_and_vsphere_settings_mismatch_reason} "

Quando l'evento viene risolto: "Le impostazioni del nodo {entity_id} del nodo Edge e le impostazioni di vSphere ora sono coerenti con l'intento del criterio. "

Esaminare le impostazioni del nodo e la configurazione di vSphere per questo nodo di trasporto Edge {entity_id}. Per risolvere l'allarme -
1, eseguire una delle seguenti azioni. Aggiornare manualmente lo scopo del criterio di impostazione del nodo di trasporto Edge utilizzando l'API: PUT https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt.
2. Accettare la configurazione del nodo Edge intenzionale o realizzata di vSphere o le impostazioni del nodo Edge realizzate per questo nodo di trasporto Edge tramite il relativo resolver per risolvere questo allarme.
3. Risolvere l'allarme accettando le impostazioni del nodo Edge e la configurazione realizzata di vSphere utilizzando l'API di aggiornamento POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.

Posizione vSphere Edge non corrispondente.

Quando viene rilevato l'evento: "Il nodo Edge {entity_id} è stato spostato tramite vMotion. Il nodo Edge {entity_id} e la configurazione in vSphere non corrispondono alla configurazione intenzionale del criterio. La configurazione del nodo Edge visibile per l'utente nell'interfaccia utente o nell'API non è identica a quella realizzata. I dettagli di questo allarme illustrano le modifiche apportate al nodo Edge realizzate dall'utente al di fuori di NSX Manager. I campi che differiscono per il nodo Edge sono elencati nei dati di runtime {edge_vsphere_location_mismatch_reason} "

Quando l'evento viene risolto: "Le impostazioni vSphere del nodo {entity_id} del nodo Edge ora sono coerenti con l'intento del criterio. "

Esaminare la configurazione vSphere di questo nodo di trasporto Edge {entity_id}. Per risolvere l'allarme -
1, eseguire una delle seguenti azioni. Risolvere l'allarme accettando la Configurazione realizzata del nodo Edge di vSphere utilizzando l'API di aggiornamento POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=refresh_node_configuration&resource_type=EdgeNode.
2. Se si desidera tornare alla posizione precedente, utilizzare l'NSX API di ridistribuzione POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy. Il ripristino di vMotion all'host originale non è supportato.

La macchina virtuale Edge automatica è presente nell'inventario NSX ma non in vCenter.

Quando viene rilevato l'evento: "La macchina virtuale {policy_edge_vm_name} con ID moref {vm_moref_id} corrispondente al nodo di trasporto Edge {entity_id}, i parametri di posizionamento di vSphere sono presenti nell'inventario di NSX ma non sono presenti in vCenter. Verificare che la macchina virtuale sia stata rimossa in vCenter o che sia presente con un ID moref di macchina virtuale diverso."

Quando l'evento viene risolto: "Il nodo Edge {entity_id} con ID MoRef di macchina virtuale {vm_moref_id} è presente nell'inventario NSX e in vCenter. "

Il riferimento all'oggetto gestito ID moref di una macchina virtuale ha la forma vm-number, che è visibile nell'URL quando si seleziona la macchina virtuale Edge nell'interfaccia utente di vCenter. Esempio vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary Individuare la macchina virtuale {policy_edge_vm_name} con ID moref {vm_moref_id} in vCenter per questo nodo di trasporto Edge {entity_id}. Se la macchina virtuale Edge è presente in vCenter con un ID moref diverso, procedere con l'azione seguente. Utilizzare l'API di posizionamento di NSX con le proprietà del payload della richiesta JSON vm_id e vm_deployment_config per aggiornare il nuovo ID moref della macchina virtuale e i parametri di distribuzione vSphere. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=addOrUpdatePlacementReferences. Se la macchina virtuale Edge con nome {policy_edge_vm_name} non è presente in vCenter, utilizzare l'API di ridistribuzione NSX per distribuire una nuova macchina virtuale per il nodo Edge. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

La macchina virtuale Edge automatica non è presente nell'inventario NSX e in vCenter.

Quando viene rilevato l'evento: "La macchina virtuale {policy_edge_vm_name} con ID moref {vm_moref_id} corrispondente al nodo di trasporto Edge {entity_id}, i parametri di posizionamento di vSphere non sono presenti nell'inventario di NSX e di vCenter. I parametri di posizionamento nella configurazione di vSphere di questo nodo di trasporto Edge {entity_id} fanno riferimento alla macchina virtuale con moref {vm_moref_id}. "

Quando l'evento viene risolto: "Il nodo Edge {entity_id} con ID MoRef di macchina virtuale {vm_moref_id} è presente nell'inventario NSX e in vCenter. "

Il riferimento all'oggetto gestito ID moref di una macchina virtuale ha la forma vm-number, che è visibile nell'URL quando si seleziona la macchina virtuale Edge nell'interfaccia utente di vCenter. Esempio vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary Individuare la macchina virtuale {policy_edge_vm_name} con ID moref {vm_moref_id} in vCenter per questo nodo di trasporto Edge {entity_id}. Eseguire la seguente azione per risolvere l'allarme: controllare se la macchina virtuale è stata eliminata in vSphere o è presente con un ID moref diverso.
1. Se la macchina virtuale è ancora presente in vCenter, attivare la modalità di manutenzione per il nodo di trasporto Edge e quindi disattivare ed eliminare la macchina virtuale Edge in vCenter. Utilizzare l'API di ridistribuzione NSX per distribuire una nuova macchina virtuale per il nodo Edge. Il traffico dei dati per il nodo di trasporto Edge verrà interrotto durante il periodo di tempo iniziale se la macchina virtuale Edge inoltra il traffico.
2. Se la macchina virtuale non è presente in vCenter, utilizzare l'API di ridistribuzione per distribuire una nuova macchina virtuale per il nodo Edge. POST https://&ltmanager-ip&gt/api/v1/transport-nodes/&lttn-id&gt?action=redeploy.

Operazione di disattivazione ed eliminazione non riuscita per la macchina virtuale Edge precedente in vCenter durante la ridistribuzione.

Quando viene rilevato l'evento: "Impossibile disattivare ed eliminare la macchina virtuale {entity_id} del nodo Edge con ID moref {vm_moref_id} in vCenter durante l'operazione di ridistribuzione. È stata distribuita una nuova macchina virtuale Edge con ID moref {new_vm_moref_id}. Le macchine virtuali precedenti e nuove di questo Edge funzionano nello stesso momento e possono causare conflitti IP e problemi di rete. "

Quando l'evento viene risolto: "Il nodo Edge {entity_id} con ID moref della macchina virtuale {vm_moref_id} non è stato trovato nell'inventario NSX né in vCenter. La nuova macchina virtuale distribuita con ID moref {new_vm_moref_id} è presente sia nell'inventario NSX sia in vCenter. "

Il riferimento all'oggetto gestito ID moref di una macchina virtuale ha la forma vm-number, che è visibile nell'URL quando si seleziona la macchina virtuale Edge nell'interfaccia utente di vCenter. Esempio vm-12011 in https://&ltvc-url>/ui/app/vm;nav=h/urn:vmomi:VirtualMachine:vm-12011:164ff798-c4f1-495b-a0be-adfba337e5d2/summary Individuare la macchina virtuale {policy_edge_vm_name} con ID moref {vm_moref_id} in vCenter per questo nodo di trasporto Edge {entity_id}. Disattivare ed eliminare la macchina virtuale Edge {policy_edge_vm_name} precedente con ID moref {vm_moref_id} in vCenter.

La versione dell'hardware del nodo dell'Edge non corrisponde.

Quando viene rilevato l'evento: "La versione dell'hardware del nodo Edge {transport_node_name} nel cluster Edge {edge_cluster_name} è {edge_tn_hw_version}, ovvero precedente alla versione dell'hardware più recente {edge_cluster_highest_hw_version} nel cluster Edge. "

Quando l'evento viene risolto: "La mancata corrispondenza della versione dell'hardware del nodo Edge {transport_node_name} è stata risolta. "

Per risolvere l'allarme di mancata corrispondenza della versione dell'hardware del nodo Edge {transport_node_name}, vedere l'articolo della Knowledge Base.

Allarme errore di riposizionamento del membro del cluster Edge

Quando viene rilevato l'evento: "L'operazione nel cluster Edge {edge_cluster_id} per trasferire tutto il contesto del servizio non è riuscita per l'indice del membro del cluster Edge {member_index_id} con ID nodo di trasporto {transport_node_id}"

Quando l'evento viene risolto: "Il nodo Edge con errore di riposizionamento {transport_node_id} è stato risolto ora. "

Esaminare la capacità disponibile per il cluster Edge. Se è necessaria più capacità, scalare il cluster Edge. Riprovare l'operazione di riposizionamento del membro del cluster Edge.

L'utilizzo della CPU del nodo Edge è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo Edge. È consigliabile regolare le dimensioni del fattore di forma dell'appliance Edge o bilanciare di nuovo i servizi rispetto agli altri nodi Edge per il carico di lavoro applicabile.

L'utilizzo della CPU del nodo Edge è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo Edge. È consigliabile regolare le dimensioni del fattore di forma dell'appliance Edge o bilanciare di nuovo i servizi rispetto agli altri nodi Edge per il carico di lavoro applicabile.

L'utilizzo della memoria del nodo Edge è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo Edge. È consigliabile regolare le dimensioni del fattore di forma dell'appliance Edge o bilanciare di nuovo i servizi rispetto agli altri nodi Edge per il carico di lavoro applicabile.

L'utilizzo della memoria del nodo Edge è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo Edge. È consigliabile regolare le dimensioni del fattore di forma dell'appliance Edge o bilanciare di nuovo i servizi rispetto agli altri nodi Edge per il carico di lavoro applicabile.

L'utilizzo del disco del nodo Edge è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione del disco del nodo Edge {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione del disco del nodo Edge {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la partizione con utilizzo elevato e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

L'utilizzo del disco del nodo Edge è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione del disco del nodo Edge {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione del disco del nodo Edge {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la partizione con utilizzo elevato e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

L'utilizzo della CPU del percorso dati del nodo Edge è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del percorso dati nel nodo Edge {entity_id} ha raggiunto per almeno due minuti il {datapath_resource_usage}%, che è pari o superiore al valore di soglia molto elevato. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo Edge {entity_id} ha raggiunto un valore inferiore alla soglia molto elevata. "

Esaminare le statistiche della CPU nel nodo Edge richiamando il comando della CLI di NSX get dataplane cpu stats per visualizzare la velocità dei pacchetti per core CPU. È previsto un utilizzo maggiore della CPU con velocità di pacchetti più elevate. È consigliabile aumentare le dimensioni del fattore di forma dell'appliance Edge e bilanciare di nuovo i servizi di questo nodo Edge rispetto agli altri nodi Edge dello stesso o di altri cluster Edge.

L'utilizzo della CPU del percorso dati del nodo Edge è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del percorso dati nel nodo Edge {entity_id} ha raggiunto per almeno due minuti il {datapath_resource_usage}%, che è pari o superiore al valore di soglia elevato. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo Edge {entity_id} ha raggiunto un valore inferiore al valore di soglia elevato. "

Esaminare le statistiche della CPU nel nodo Edge richiamando il comando della CLI di NSX get dataplane cpu stats per visualizzare la velocità dei pacchetti per core CPU. È previsto un utilizzo maggiore della CPU con velocità di pacchetti più elevate. È consigliabile aumentare le dimensioni del fattore di forma dell'appliance Edge e bilanciare di nuovo i servizi di questo nodo Edge rispetto agli altri nodi Edge dello stesso o di altri cluster Edge.

Configurazione del percorso dati del nodo Edge non riuscita.

Quando viene rilevato l'evento: "Impossibile attivare il percorso dati nel nodo Edge dopo tre tentativi. "

Quando l'evento viene risolto: "Il percorso dati nel nodo Edge è stato attivato correttamente. "

Assicurarsi che la connettività del nodo Edge al nodo Manager sia integra. Dalla CLI di NSX del nodo Edge, richiamare il comando get services per verificare l'integrità dei servizi. Se il servizio del piano dati viene interrotto, richiamare il comando start service dataplane per avviarlo.

Il driver di crittografia del nodo Edge è inattivo.

Quando viene rilevato l'evento: "Il driver di crittografia del nodo Edge {edge_crypto_drv_name} è inattivo. "

Quando l'evento viene risolto: "Il driver di crittografia del nodo Edge {edge_crypto_drv_name} è attivo. "

Aggiornare il nodo Edge in base alle esigenze.

Il pool di memoria del percorso dati del nodo Edge è elevato.

Quando viene rilevato l'evento: "L'utilizzo del pool di memoria percorso dati per {mempool_name} nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del pool di memoria percorso dati per {mempool_name} nel nodo Edge {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente root e richiamare il comando edge-appctl -t /var/run/vmware/edge/dpd.ctl mempool/show e edge-appctl -t /var/run/vmware/edge/dpd.ctl memory/show malloc_heap per controllare l'utilizzo della memoria DPDK.

L'utilizzo della tabella ARP globale del nodo Edge è elevato.

Quando viene rilevato l'evento: "L'utilizzo della tabella ARP globale nel nodo Edge {entity_id} ha raggiunto per oltre due minuti il {datapath_resource_usage}%, che è superiore al valore di soglia elevato. "

Quando l'evento viene risolto: "L'utilizzo della tabella ARP globale nel nodo Edge {entity_id} è sceso al di sotto del valore di soglia elevato. "

Accedere come utente root e richiamare il comando edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/show e verificare che l'utilizzo della cache adiacente sia normale. Se è normale, richiamare il comando edge-appctl -t /var/run/vmware/edge/dpd.ctl neigh/set_param max_entries per aumentare le dimensioni della tabella ARP.

La scheda NIC del nodo Edge ha temporaneamente esaurito i buffer di anello RX.

Quando viene rilevato l'evento: "Il buffer dell'anello di ricezione NIC dell'Edge {edge_nic_name} ha superato il {rx_ring_buffer_overflow_percentage}% nel nodo Edge {entity_id}. Il conteggio dei pacchetti persi è {rx_misses} e il conteggio dei pacchetti elaborati è {rx_processed}. "

Quando l'evento viene risolto: "L'utilizzo del buffer dell'anello di ricezione NIC dell'Edge {edge_nic_name} nel nodo Edge {entity_id} non è più in overflow. "

Eseguire il comando della CLI di NSX get dataplane cpu stats nel nodo Edge e controllare:
1. Se l'utilizzo della CPU è elevato, ad esempio > 90%, acquisire una cattura pacchetto nell'interfaccia utilizzando il comando "start capture interface &ltinterface-name&gt direction input o start capture interface &ltinterface-name&gt direction input core &ltcore-id&gt" (per acquisire i pacchetti in ingresso in un core specifico il cui utilizzo è elevato). Analizzare quindi l'acquisizione per vedere se sono presenti la maggior parte dei pacchetti frammentati o dei pacchetti IPSec. Se sì, è previsto un comportamento. In caso contrario, è probabile che il percorso dati sia occupato con altre operazioni. Se l'allarme dura più di 2-3 minuti, contattare l'assistenza VMware.
2. Se l'utilizzo della CPU non è elevato, ad esempio < 90%, verificare che rx pps sia alto utilizzando il comando get dataplane cpu stats (per assicurarsi che la velocità del traffico sia in aumento). Aumentare quindi la dimensione dell'anello di 1024 utilizzando il comando set dataplane ring-size rx . NOTA: l'aumento continuo della dimensione dell'anello di 1024 fattori può causare alcuni problemi di prestazioni. Se anche dopo aver aumentato le dimensioni dell'anello, il problema persiste, è un'indicazione che l'Edge ha bisogno di una distribuzione di fattori di forma più grande per accogliere il traffico.
3. Se l'allarme continua a scadere, ossia si attiva e risolve molto presto, il problema è dovuto a un traffico bursty. In questo caso, verificare rx pps come descritto in precedenza. Se non è alto durante il periodo di attivazione dell'allarme, contattare l'assistenza VMware. Se pps è alto, conferma il traffico bursty. È consigliabile eliminare l'allarme. NOTA: non è presente alcun benchmark specifico per decidere ciò che si verifica come un valore di pps elevato. Dipende dall'infrastruttura e dal tipo di traffico. È possibile effettuare il confronto prendendo annotazioni quando l'allarme è inattivo e quando è attivo.

La scheda NIC del nodo Edge ha temporaneamente esaurito i buffer di anello TX.

Quando viene rilevato l'evento: "Il buffer dell'anello di trasmissione NIC dell'Edge {edge_nic_name} ha superato il {rx_ring_buffer_overflow_percentage}% nel nodo Edge {entity_id}. Il conteggio dei pacchetti persi è {tx_misses} e il conteggio dei pacchetti elaborati è {tx_processed}. "

Quando l'evento viene risolto: "L'utilizzo del buffer dell'anello di trasmissione NIC dell'Edge {edge_nic_name} nel nodo Edge {entity_id} non è più in overflow. "

1. Se l'hypervisor ospita molte macchine virtuali insieme all'Edge è possibile che la macchina virtuale edge non disponga di tempo per l'esecuzione, quindi i pacchetti potrebbero non essere recuperati dall'hypervisor. È quindi consigliabile migrare la macchina virtuale edge in un host con un minor numero di macchine virtuali.
2. Aumentare le dimensioni dell'anello di 1024 utilizzando il comando "set dataplane ring-size tx ". Se anche dopo aver aumentato le dimensioni dell'anello, il problema persiste, contattare l'assistenza VMware perché il buffer dell'anello di trasmissione lato ESX potrebbe avere un valore inferiore. Se non si verifica alcun problema sul lato ESX, indica che l'Edge deve essere scalato in base a una distribuzione di fattori di forma più grande per accogliere il traffico.
3. Se l'allarme continua a scadere, ossia si attiva e risolve molto presto, il problema è dovuto a un traffico bursty. In questo caso, verificare se tx pps utilizza il comando get dataplane cpu stats. Se non è alto durante il periodo di attivazione dell'allarme, contattare l'assistenza VMware. Se pps è alto, conferma il traffico bursty. È consigliabile eliminare l'allarme. NOTA: non è presente alcun benchmark specifico per decidere ciò che si verifica come un valore di pps elevato. Dipende dall'infrastruttura e dal tipo di traffico. È possibile effettuare il confronto prendendo annotazioni quando l'allarme è inattivo e quando è attivo.

Il collegamento alla scheda NIC del nodo Edge è inattivo.

Quando viene rilevato l'evento: "Il collegamento alla scheda NIC del nodo Edge {edge_nic_name} è inattivo. "

Quando l'evento viene risolto: "Il collegamento alla NIC {edge_nic_name} del nodo Edge è attivo. "

Nel nodo Edge verificare che il collegamento della NIC sia fisicamente inattivo richiamando il comando della CLI di NSX get interfaces. Se è inattivo, verificare la connessione via cavo.

Il disco del nodo Edge è di sola lettura.

Quando viene rilevato l'evento: "Le seguenti partizioni del disco nel nodo Edge sono in modalità di sola lettura: {disk_partition_name}"

Quando l'evento viene risolto: "Le seguenti partizioni del disco nel nodo Edge sono state ripristinate dalla modalità di sola lettura: {disk_partition_name}"

Esaminare la partizione di sola lettura per verificare se il riavvio risolve il problema o se è necessario sostituire il disco. Per ulteriori informazioni, contattare GSS.

Il thread del percorso dati del nodo Edge è in condizione di blocco critico.

Quando viene rilevato l'evento: "Il thread del percorso dati del nodo Edge {edge_thread_name} è bloccato. "

Quando l'evento viene risolto: "Il thread del percorso dati del nodo Edge {edge_thread_name} è libero da deadlock. "

Riavviare il servizio piano dati richiamando il comando della CLI di NSX restart service dataplane.

La velocità effettiva della scheda NIC del nodo Edge è molto elevata.

Quando viene rilevato l'evento: "La velocità effettiva della NIC del percorso dati per {edge_nic_name} nel nodo Edge {entity_id} ha raggiunto il {nic_throughput}%, che è pari o superiore al valore di soglia molto elevato del {nic_throughput_threshold}%. "

Quando l'evento viene risolto: "La velocità effettiva della NIC del percorso dati per {edge_nic_name} nel nodo Edge {entity_id} ha raggiunto il {nic_throughput}%, che è inferiore al valore di soglia molto elevato del {nic_throughput_threshold}%. "

Esaminare i livelli di velocità del traffico nella NIC e determinare se sono necessarie modifiche della configurazione. Il comando "get dataplane thoughput &ltseconds&gt" può essere utilizzato per monitorare la velocità effettiva.

La velocità effettiva della scheda NIC del percorso dati del nodo Edge è elevato.

Quando viene rilevato l'evento: "La velocità effettiva della NIC del percorso dati per {edge_nic_name} nel nodo Edge {entity_id} ha raggiunto il {nic_throughput}%, che è pari o superiore al valore di soglia elevato del {nic_throughput_threshold}%. "

Quando l'evento viene risolto: "La velocità effettiva della NIC del percorso dati per {edge_nic_name} nel nodo Edge {entity_id} ha raggiunto il {nic_throughput}%, che è inferiore al valore di soglia elevato del {nic_throughput_threshold}%. "

Esaminare i livelli di velocità di velocità del traffico nella NIC e determinare se sono necessarie modifiche della configurazione. Il comando "get dataplane thoughput &ltseconds&gt" può essere utilizzato per monitorare la velocità effettiva.

Tutti i membri del dominio di errore sono inattivi.

Quando viene rilevato l'evento: "Tutti i membri di dominio {transport_node_id} con errore sono inattivi. "

Quando l'evento viene risolto: "Tutti i membri del dominio con errore {transport_node_id} sono raggiungibili. "

1. Nel nodo Edge identificato da {transport_node_id}, controllare la connettività ai piani di gestione e controllo richiamando il comando della CLI di NSX get managers e get controllers.
2. Richiamare il comando della CLI di NSX get interface eth0 per controllare lo stato dell'interfaccia di gestione.
3. Richiamare i seguenti della CLI get services per controllare lo stato dei servizi principali come dataplane/local-controller/nestdb/router e così via.
4. Esaminare /var/log/syslog per trovare l'errore sospetto.
5. Riavviare il nodo Edge.

La frequenza di successo della cache del flusso micro diminuisce e la CPU del percorso dati è elevata.

Quando viene rilevato l'evento: "La frequenza di successo della cache del flusso micro nel nodo dell'Edge {entity_id} è diminuita al di sotto della soglia specificata del {flow_cache_threshold}% per il core {core_id}e l'utilizzo della CPU del percorso dati è aumentato negli ultimi 30 minuti. "

Quando l'evento viene risolto: "La frequenza di successo della cache del flusso è nell'intervallo normale. "

La frequenza di successo del flusso della cache è diminuita negli ultimi 30 minuti, il che indica che potrebbe verificarsi un peggioramento delle prestazioni dell'Edge. Il traffico continuerà a essere inoltrato e potrebbe non verificarsi alcun problema. Controllare l'utilizzo della CPU del percorso dati per l'Edge {entity_id} core {core_id} se è elevato negli ultimi 30 minuti. L'Edge avrà una bassa frequenza di successo della cache del flusso quando vengono creati continuamente nuovi flussi perché il primo pacchetto di un nuovo flusso verrà utilizzato per configurare la cache-flusso per l'elaborazione rapida del percorso. È possibile aumentare le dimensioni dell'appliance Edge o il numero di nodi Edge utilizzati per i gateway attivi/attivi.

La frequenza di successo della cache del flusso mega diminuisce e la CPU del percorso dati è elevata.

Quando viene rilevato l'evento: "La frequenza di successo della cache del flusso mega nel nodo dell'Edge {entity_id} è diminuita al di sotto della soglia specificata del {flow_cache_threshold}% per il core {core_id}e l'utilizzo della CPU del percorso dati è aumentato negli ultimi 30 minuti. "

Quando l'evento viene risolto: "La frequenza di successo della cache del flusso è nell'intervallo normale. "

La frequenza di successo del flusso della cache è diminuita negli ultimi 30 minuti, il che indica che potrebbe verificarsi un peggioramento delle prestazioni dell'Edge. Il traffico continuerà a essere inoltrato e potrebbe non verificarsi alcun problema. Controllare l'utilizzo della CPU del percorso dati per l'Edge {entity_id} core {core_id} se è elevato negli ultimi 30 minuti. L'Edge avrà una bassa frequenza di successo della cache del flusso quando vengono creati continuamente nuovi flussi perché il primo pacchetto di un nuovo flusso verrà utilizzato per configurare la cache-flusso per l'elaborazione rapida del percorso. È possibile aumentare le dimensioni dell'appliance Edge o il numero di nodi Edge utilizzati per i gateway attivi/attivi.

Il servizio ESX Agent Manager (EAM) in un gestore delle risorse di elaborazione è inattivo.

Quando viene rilevato l'evento: "Il servizio ESX Agent Manager (EAM) nel gestore delle risorse di elaborazione {entity_id} è inattivo. "

Quando l'evento viene risolto: "Il servizio ESX Agent Manager (EAM) nel gestore delle risorse di elaborazione {entity_id} è attivo o il gestore delle risorse di elaborazione {entity_id} è stato rimosso. "

Avviare il servizio ESX Agent Manager (EAM). Accedere tramite SSH a vCenter e richiamare il comando service vmware-eam start.

Il modulo host e la connessione SVM partner sono inattivi.

Quando viene rilevato l'evento: "La connessione tra il modulo host e la SVM partner {entity_id} è inattiva. "

Quando l'evento viene risolto: "La connessione tra il modulo host e la SVM partner {entity_id} è attiva. "

Fare riferimento a https://kb.vmware.com/s/article/85844 e assicurarsi che la SVM partner {entity_id} sia nuovamente connessa al modulo host.

Router adiacente BGP RTEP inattivo.

Quando viene rilevato l'evento: "La sessione BGP RTEP (Endpoint tunnel remoto) dall'IP di origine {bgp_neighbor_ip} all'IP adiacente {bgp_neighbor_ip} della posizione remota {remote_site_name} è inattiva. Motivo: {failure_reason}. "

Quando l'evento viene risolto: "La sessione BGP RTEP (Endpoint tunnel remoto) dall'IP di origine {bgp_neighbor_ip} all'IP adiacente {bgp_neighbor_ip} della posizione remota {remote_site_name} è stabilita. "

1. Richiamare il comando della CLI di NSX get logical-routers nel nodo Edge interessato.
2. Passare al contesto REMOTE_TUNNEL_VRF.
3. Richiamare il comando della CLI di NSX get bgp neighbor summary per controllare lo stato del router adiacente BGP.
4. In alternativa, richiamare l'NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary per ottenere lo stato del router adiacente BGP.
5. Richiamare il comando della CLI di NSX get interfaces e verificare che all'interfaccia con nome remote-tunnel-endpoint sia assegnato l'indirizzo IP RTEP corretto.
6. Verificare che il ping funzioni correttamente tra l'indirizzo IP RTEP assegnato {bgp_source_ip} e l'IP del router adiacente {bgp_neighbor_ip} della posizione remota {remote_site_name}.
7. Verificare la presenza di eventuali errori relativi a BGP in /var/log/syslog.
8. Richiamare l'NSX API GET o PUT /api/v1/transport-nodes/&lttransport-node-id&gt per ottenere/aggiornare la configurazione remote_tunnel_endpoint nel nodo Edge. In questo modo verrà aggiornato l'IP RTEP assegnato al nodo Edge interessato. Se il motivo mostra Edge non è pronto, verificare il motivo per cui lo stato del nodo Edge non è appropriato.
1. Richiamare il comando della CLI di NSX get edge-cluster status per verificare il motivo per cui il nodo Edge potrebbe essere inattivo.
2. Richiamare i comandi della CLI di NSX get bfd-config e get bfd-sessions per verificare che BFD sia in esecuzione.
3. Controllare eventuali allarmi relativi all'integrità Edge per ottenere ulteriori informazioni.

La sincronizzazione tra le posizioni remote non è riuscita per più di 3 minuti.

Quando viene rilevato l'evento: "La sincronizzazione tra {site_name}({site_id}) e {remote_site_name}({remote_site_id}) non è riuscita per più di 3 minuti. "

Quando l'evento viene risolto: "Le posizioni remote {site_name}({site_id}) e {remote_site_name}({remote_site_id}) ora sono sincronizzate. "

1. Richiamare il comando della CLI di NSX get site-replicator remote-sites per ottenere lo stato della connessione tra le posizioni remote. Se una posizione remota è connessa ma non sincronizzata, è possibile che la posizione sia ancora in fase di risoluzione master. In questo caso, attendere circa 10 secondi e provare a richiamare nuovamente il comando CLI per verificare lo stato della posizione remota. Se una posizione è disconnessa, provare con il passaggio successivo.
2. Controllare la connettività dal Local Manager (LM) nella posizione {site_name}({site_id}) agli LM nella posizione {remote_site_name}({remote_site_id}) tramite ping. Se non è possibile eseguire il ping, verificare l'affidabilità della connettività WAN. Se non si verificano problemi di connettività di rete fisica, provare con il passaggio successivo.
3. Controllare il file /var/log/cloudnet/nsx-ccp.log nei nodi di Manager nel cluster locale nella posizione {site_name}({site_id}) che ha attivato l'allarme per verificare se sono presenti errori di comunicazione tra siti. Cercare inoltre gli errori registrati dal sottocomponente nsx-appl-proxy in /var/log/syslog.

La sincronizzazione tra le posizioni remote non è riuscita per più di 15 minuti.

Quando viene rilevato l'evento: "La sincronizzazione tra {site_name}({site_id}) e {remote_site_name}({remote_site_id}) non è riuscita per più di 15 minuti. "

Quando l'evento viene risolto: "I siti remoti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) ora sono sincronizzati. "

1. Richiamare il comando della CLI di NSX get site-replicator remote-sites per ottenere lo stato della connessione tra le posizioni remote. Se una posizione remota è connessa ma non sincronizzata, è possibile che la posizione sia ancora in fase di risoluzione master. In questo caso, attendere circa 10 secondi e provare a richiamare nuovamente il comando CLI per verificare lo stato della posizione remota. Se una posizione è disconnessa, provare con il passaggio successivo.
2. Controllare la connettività dal Local Manager (LM) nella posizione {site_name}({site_id}) agli LM nella posizione {remote_site_name}({remote_site_id}) tramite ping. Se non è possibile eseguire il ping, verificare l'affidabilità della connettività WAN. Se non si verificano problemi di connettività di rete fisica, provare con il passaggio successivo.
3. Controllare il file /var/log/cloudnet/nsx-ccp.log nei nodi di Manager nel cluster locale nella posizione {site_name}({site_id}) che ha attivato l'allarme per verificare se sono presenti errori di comunicazione tra siti. Cercare inoltre gli errori registrati dal sottocomponente nsx-appl-proxy in /var/log/syslog.

Connettività della posizione RTEP persa.

Quando viene rilevato l'evento: "Il nodo Edge {transport_node_name} ha perso la connettività RTEP (Endpoint tunnel remoto) con la posizione remota {remote_site_name}. "

Quando l'evento viene risolto: "Il nodo Edge {transport_node_name} ha ripristinato la connettività RTEP (Endpoint tunnel remoto) con la posizione remota {remote_site_name}. "

1. Richiamare il comando della CLI di NSX get logical-routers nel nodo Edge interessato {transport_node_name}.
2. Passare al contesto REMOTE_TUNNEL_VRF.
3. Richiamare il comando della CLI di NSX get bgp neighbor summary per controllare lo stato del router adiacente BGP.
4. In alternativa, richiamare l'NSX API GET /api/v1/transport-nodes/&lttransport-node-id&gt/inter-site/bgp/summary per ottenere lo stato del router adiacente BGP.
5. Richiamare il comando della CLI di NSX get interfaces e verificare che all'interfaccia con nome remote-tunnel-endpoint sia assegnato l'indirizzo IP RTEP corretto.
6. Verificare che il ping funzioni correttamente tra l'indirizzo IP RTEP assegnato e gli indirizzi IP RTEP nella posizione remota {remote_site_name}.
7. Verificare la presenza di eventuali errori relativi a BGP in /var/log/syslog.
8. Richiamare l'NSX API GET o PUT /api/v1/transport-nodes/&lttransport-node-id&gt per ottenere/aggiornare la configurazione remote_tunnel_endpoint nel nodo Edge. In questo modo verrà aggiornato l'IP RTEP assegnato al nodo Edge interessato {transport_node_name}.

Più nodi di Global Manager sono attivi contemporaneamente.

Quando viene rilevato l'evento: "Più nodi di Global Manager sono attivi: {active_global_managers}. Uso solo nodo di Global Manager deve essere attivo in qualsiasi momento. "

Quando l'evento viene risolto: "Il nodo di Global Manager {active_global_manager} ora è l'unico nodo di Global Manager attivo. "

Configurare un solo nodo di Global Manager attivo e tutti gli altri come standby.

La latenza tra i Global Manager è più elevata del previsto per più di 2 minuti

Quando viene rilevato l'evento: "La latenza tra i Global Manager {from_gm_path} e {to_gm_path} è più alta del previsto. "

Quando l'evento viene risolto: "La latenza tra i Global Manager {from_gm_path} e {to_gm_path} è inferiore ai livelli previsti. "

Controllare la connettività da Global Manager {from_gm_path}({site_id}) a Global Manager {to_gm_path}({remote_site_id}) tramite ping. Se non è possibile eseguire il ping, verificare l'affidabilità della connettività WAN.

Impossibile sincronizzare il Global Manager attivo e quello di standby

Quando viene rilevato l'evento: "Non è possibile sincronizzare il Global Manager attivo {from_gm_path} e quello di standby {to_gm_path}. "

Quando l'evento viene risolto: "La sincronizzazione tra il nodo di Global Manager attivo {from_gm_path} e quello di standby {to_gm_path} è integra. "

Controllare la connettività da Global Manager {from_gm_path}({site_id}) a Global Manager {to_gm_path}({remote_site_id}) tramite ping.

Impossibile sincronizzare il Global Manager attivo e quello di standby per più di 5 minuti

Quando viene rilevato l'evento: "Non è possibile sincronizzare il Global Manager attivo {from_gm_path} e quello di standby {to_gm_path} per più di 5 minuti. "

Quando l'evento viene risolto: "La sincronizzazione tra il nodo di Global Manager attivo {from_gm_path} e quello di standby {to_gm_path} è integra. "

Controllare la connettività da Global Manager {from_gm_path}({site_id}) a Global Manager {to_gm_path}({remote_site_id}) tramite ping.

La sincronizzazione dei dati tra il Global Manager (GM) e il Local Manager (LM) non è riuscita.

Quando viene rilevato l'evento: "La sincronizzazione dei dati tra i siti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) non è riuscita per {flow_identifier}. Motivo: {sync_issue_reason}"

Quando l'evento viene risolto: "I siti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) ora sono sincronizzati per {flow_identifier}. "

1. Controllare la connettività di rete tra il sito remoto e il sito locale tramite ping.
2. Assicurarsi che il traffico della porta TCP/1236 sia consentito tra i siti locali e remoti.
3. Assicurarsi che il servizio async-replicator sia in esecuzione su siti locali e remoti. Richiamare l'NSX API GET /api/v1/node/services/async_replicator/status o il comando della CLI di NSX get service async_replicator per determinare se il servizio è in esecuzione. Se non è in esecuzione, richiamare l'NSX API POST /api/v1/node/services/async_replicator?action=restart o il comando della CLI di NSX restart service async_replicator per riavviare il servizio.
4. Verificare in /var/log/async-replicator/ar.log se sono segnalati errori.

La sincronizzazione dei dati tra il Global Manager (GM) e il Local Manager (LM) non è riuscita per un periodo di tempo prolungato.

Quando viene rilevato l'evento: "La sincronizzazione dei dati tra i siti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) non è riucita per {flow_identifier} per un periodo di tempo prolungato. Motivo: {sync_issue_reason}. "

Quando l'evento viene risolto: "I siti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) ora sono sincronizzati per {flow_identifier}. "

1. Controllare la connettività di rete tra il sito remoto e il sito locale tramite ping.
2. Assicurarsi che il traffico della porta TCP/1236 sia consentito tra i siti locali e remoti.
3. Assicurarsi che il servizio async-replicator sia in esecuzione su siti locali e remoti. Richiamare l'NSX API GET /api/v1/node/services/async_replicator/status o il comando della CLI di NSX get service async_replicator per determinare se il servizio è in esecuzione. Se non è in esecuzione, richiamare l'NSX API POST /api/v1/node/services/async_replicator?action=restart o il comando della CLI di NSX restart service async_replicator per riavviare il servizio.
4. Verificare in /var/log/async-replicator/ar.log se sono segnalati errori.
5. Raccogliere un bundle di supporto e contattare il team di supporto di NSX.

È stata superata la soglia di avviso della dimensione di occupazione della coda.

Quando viene rilevato l'evento: "La coda ({queue_name}) utilizzata per sincronizzare i dati tra i siti {site_name} ({site_id}) e {remote_site_name} ({remote_site_id}) ha raggiunto la dimensione {queue_size}, valore pari o superiore alla soglia massima del {queue_size_threshold}%. "

Quando l'evento viene risolto: "La coda ({queue_name}) utilizzata per sincronizzare i dati tra i siti {site_name}({site_id}) e {remote_site_name} ({remote_site_id}) ha raggiunto la dimensione {queue_size}, valore inferiore alla soglia massima del {queue_size_threshold}%. "

Le dimensioni della coda possono superare la soglia a causa di un problema di comunicazione con il sito remoto o un sistema sovraccarico. Verificare le prestazioni del sistema e /var/log/async-replicator/ar.log per verificare se sono presenti errori segnalati.

La latenza tra il Global Manager e il Local Manager è più elevata del previsto per più di 2 minuti.

Quando viene rilevato l'evento: "La latenza tra i siti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) ha raggiunto {latency_value} che è superiore al valore di soglia di {latency_threshold}. "

Quando l'evento viene risolto: "La latenza tra i siti {site_name}({site_id}) e {remote_site_name}({remote_site_id}) ha raggiunto {latency_value} che è inferiore al valore di soglia di {latency_threshold}. "

1. Controllare la connettività di rete tra il sito remoto e il sito locale tramite ping.
2. Assicurarsi che il traffico della porta TCP/1236 sia consentito tra i siti locali e remoti.
3. Verificare in /var/log/async-replicator/ar.log se sono segnalati errori.

Local Manager viene ripristinato durante l'importazione della configurazione in Global Manager.

Quando viene rilevato l'evento: "L'importazione della configurazione dal sito {site_name}({site_id}) è in corso. Tuttavia, il sito {site_name}({site_id}) viene ripristinato dal backup dall'amministratore, lasciandolo in uno stato incoerente. "

Quando l'evento viene risolto: "L'incoerenza di configurazione nel sito {site_name} ({site_id}) è stata risolta. "

1. Accedere alla CLI dell'appliance NSX Global Manager.
2. Passare alla root.
3. Richiamare l'NSX API DELETE http://localhost:64440 /gm/api/v1/infra/sites/&ltsite-name&gt/onboarding/status in modalità locale, in questo modo lo stato di onboarding del sito per Global Manager verrà eliminato.
4. Avviare nuovamente l'onboarding della configurazione.

L'utilizzo della tabella di flusso del firewall del gateway per il traffico IP è elevato. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "Utilizzo della tabella di flusso del firewall del gateway per IP nel router logico {entity_id} ha raggiunto {firewall_ip_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway per i flussi non IP nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per i flussi IP. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

La tabella di flusso del firewall del gateway per il traffico IP ha superato la soglia impostata. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "Utilizzo della tabella di flusso del firewall del gateway per il traffico IP nel router logico {entity_id} ha raggiunto {firewall_ip_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per i flussi IP. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

L'utilizzo della tabella di flusso del firewall del gateway per il traffico UDP è elevato. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "Utilizzo della tabella di flusso del firewall del gateway per UDP nel router logico {entity_id} ha raggiunto {firewall_udp_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway per UDP nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per i flussi UDP. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

La tabella di flusso del firewall del gateway per il traffico UDP ha superato la soglia impostata. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "Utilizzo della tabella di flusso del firewall del gateway per il traffico UDP nel router logico {entity_id} ha raggiunto {firewall_udp_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per i flussi UDP. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

L'utilizzo della tabella di flusso del firewall del gateway per il traffico ICMP è elevato. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "L'utilizzo della tabella di flusso del firewall del gateway per ICMP nel router logico {entity_id} ha raggiunto il {firewall_icmp_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway per ICMP nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per i flussi ICMP. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

La tabella di flusso del firewall del gateway per il traffico ICMP ha superato la soglia impostata. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "Utilizzo della tabella di flusso del firewall del gateway per il traffico ICMP nel router logico {entity_id} ha raggiunto {firewall_icmp_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per i flussi ICMP. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

L'utilizzo della tabella di flusso del firewall del gateway per il traffico TCP half-open è elevato. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "L'utilizzo della tabella di flusso del firewall del gateway per TCP nel router logico {entity_id} ha raggiunto il {firewall_halfopen_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway per il traffico TCP semiaperto nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e la tabella di flusso di controllo utilizzata per il flusso TCP semiaperto. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

La tabella di flusso del firewall del gateway per il traffico mezzo aperto TCP ha superato la soglia impostata. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo.

Quando viene rilevato l'evento: "L'utilizzo della tabella di flusso del firewall del gateway per il metà apertura traffico TCP nel router logico {entity_id} ha raggiunto il {firewall_halfopen_flow_usage}% che è pari o superiore al valore della soglia elevata di {system_usage_threshold}%. I nuovi flussi verranno eliminati dal firewall del gateway quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo della tabella di flusso del firewall del gateway nel router logico {entity_id} è sceso al di sotto del valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt interface stats | json utilizzando l'UUID dell'interfaccia corretta e l'utilizzo della tabella di flusso di controllo utilizzata per i flussi TCP semiaperti. Il controllo dei flussi del traffico che attraversano il gateway non è un attacco DOS o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aumentare la soglia dell'allarme o instradare il nuovo traffico verso un altro nodo Edge.

Il numero totale di elementi del gruppo convertiti ha superato il limite massimo.

Quando viene rilevato l'evento: "Il gruppo {group_id} include almeno {group_size} elementi convertiti, che è un numero pari o superiore al limite massimo di numeri di {group_max_number_limit}. Ciò può causare tempi di elaborazione lunghi, timeout e interruzioni. Il conteggio corrente per ogni tipo di elemento è il seguente. Set di IP:{ip_count}, set di MAC:{mac_count}, VIFS:{vif_count}, porte commutatore logico:{lsp_count}, porte router logici:{lrp_count}, AdGroup:{sid_count}. "

Quando l'evento viene risolto: "Il numero totale di elementi nel gruppo {group_id} è inferiore al limite massimo di {group_max_number_limit}. "

1. È consigliabile regolare gli elementi del gruppo nel gruppo sovradimensionato {group_id}.
2. Prendere in considerazione la possibilità di dividere i gruppi sovradimensionati {group_id} in gruppi più piccoli e distribuire i membri del gruppo sovradimensionato in questi gruppi.

Failover di un gateway di livello 0.

Quando viene rilevato l'evento: "Il failover del gateway di livello 0 {entity_id} da {previous_gateway_state} a {current_gateway_state}, router di servizio {service_router_id}"

Quando l'evento viene risolto: "Il gateway di livello 0 {entity_id} ora è attivo. "

Richiamare il comando della CLI di NSX get logical-router &ltservice_router_id&gt per identificare l'ID vrf del router del servizio di livello 0. Passare al contesto vrf context richiamando il comando vrf &ltvrf-id&gt, quindi richiamare il comando get high-availability status per determinare il servizio inattivo.

Failover di un gateway di livello 1.

Quando viene rilevato l'evento: "Il failover del gateway di livello 1 {entity_id} da {previous_gateway_state} a {current_gateway_state}, router di servizio {service_router_id}"

Quando l'evento viene risolto: "Il gateway di livello 1 {entity_id} ora è attivo. "

Richiamare il comando della CLI di NSX get logical-router &ltservice_router_id&gt per identificare l'ID vrf del router del servizio di livello 1. Passare al contesto vrf context richiamando il comando vrf &ltvrf-id&gt, quindi richiamare il comando get high-availability status per determinare il servizio inattivo.

Il gruppo di servizi non dispone di un'istanza attiva.

Quando viene rilevato l'evento: "Il cluster del gruppo di servizi {entity_id} al momento non dispone di un'istanza attiva. Si trova nello stato {ha_state} (dove 0 indica che è inattivo, 1 indica che è in standby e 2 indica che è attivo) nel nodo Edge {transport_node_id} e nello stato {ha_state2} nel nodo Edge {transport_node_id2}. "

Quando l'evento viene risolto: "Il cluster del gruppo di servizi di livello 0 {entity_id} ora dispone di un'istanza attiva nel nodo Edge {transport_node_id}. "

Richiamare il comando della CLI di NSX get logical-router &ltservice_router_id&gt service_group per controllare tutti i gruppi di servizi configurati in un determinato router di servizio. Esaminare l'output per cercare il motivo per cui un gruppo di servizi lascia lo stato attivo.

Il gruppo di servizi non dispone di un'istanza attiva.

Quando viene rilevato l'evento: "Il cluster del gruppo di servizi {entity_id} al momento non dispone di un'istanza attiva. Si trova nello stato {ha_state} (dove 0 indica che è inattivo, 1 indica che è in standby e 2 indica che è attivo) nel nodo Edge {transport_node_id} e nello stato {ha_state2} nel nodo Edge {transport_node_id2}. "

Quando l'evento viene risolto: "Il cluster del gruppo di servizi di livello 1 {entity_id} ora dispone di un'istanza attiva nel nodo Edge {transport_node_id}. "

Richiamare il comando della CLI di NSX get logical-router &ltservice_router_id&gt service_group per controllare tutti i gruppi di servizi configurati in un determinato router di servizio. Esaminare l'output per cercare il motivo per cui un gruppo di servizi lascia lo stato attivo.

Un'istanza di standby in un gruppo di servizi non è riuscita.

Quando viene rilevato l'evento: "Il cluster del gruppo di servizi {entity_id} collegato al router di servizio di livello 0 {service_router_id} nel nodo Edge {transport_node_id} non è riuscito. Di conseguenza, il cluster del gruppo di servizi al momento non dispone di un'istanza di standby. "

Quando l'evento viene risolto: "Il cluster del gruppo di servizi {entity_id} si trova nello stato {ha_state} (dove 0 indica che è inattivo, 1 indica che è in standby e 2 indica che è attivo) nel nodo Edge {transport_node_id} e nello stato {ha_state2} nel nodo Edge {transport_node_id2}. "

Richiamare il comando della CLI di NSX get logical-router &ltservice_router_id&gt service_group per controllare tutti i gruppi di servizi configurati in un determinato router di servizio. Esaminare l'output per cercare il motivo dell'errore per un gruppo di servizi in standby precedente.

Un'istanza di standby in un gruppo di servizi non è riuscita.

Quando viene rilevato l'evento: "Il cluster del gruppo di servizi {entity_id} collegato al router di servizio di livello 1 {service_router_id} nel nodo Edge {transport_node_id} non è riuscito. Di conseguenza, il cluster del gruppo di servizi al momento non dispone di un'istanza di standby. "

Quando l'evento viene risolto: "Il cluster del gruppo di servizi {entity_id} si trova nello stato {ha_state} (dove 0 indica che è inattivo, 1 indica che è in standby e 2 indica che è attivo) nel nodo Edge {transport_node_id} e nello stato {ha_state2} nel nodo Edge {transport_node_id2}. "

Richiamare il comando della CLI di NSX get logical-router &ltservice_router_id&gt service_group per controllare tutti i gruppi di servizi configurati in un determinato router di servizio. Esaminare l'output per cercare il motivo dell'errore per un gruppo di servizi in standby precedente.

La connettività al server LDAP viene persa.

Quando viene rilevato l'evento: "La connettività al server LDAP {ldap_server} è stata persa. "

Quando l'evento viene risolto: "La connettività al server LDAP {ldap_server} è stata ripristinata. "

Controllare
1. Il server LDAP è raggiungibile dai nodi NSX.
2. I dettagli del server LDAP sono configurati correttamente in NSX.
3. Il server LDAP è in esecuzione.
4. Non sono presenti firewall che bloccano l'accesso tra il server LDAP e i nodi NSX. Una volta risolto il problema, utilizzare TEST CONNECTION nell'interfaccia utente di NSX in AD firewall identità per testare la connessione.

Si sono verificati errori durante l'esecuzione della sincronizzazione delta.

Quando viene rilevato l'evento: "Si sono verificati errori durante l'esecuzione della sincronizzazione delta con {directory_domain}. "

Quando l'evento viene risolto: "Non si è verificato alcun errore durante l'esecuzione della sincronizzazione delta con {directory_domain}. "

1. Verificare se è presente una connettività agli allarmi di perdita del server LDAP.
2. Individuare i dettagli dell'errore in /var/log/syslog. Intorno all'ora di attivazione dell'allarme, cercare il testo: Si è verificato un errore durante la sincronizzazione degli oggetti LDAP.
3. Consultare l'amministratore di AD se sono presenti recenti modifiche di AD che possono causare errori.
4. Se gli errori persistono, raccogliere il bundle del supporto tecnico e contattare l'assistenza tecnica VMware.

Lo stato del tunnel di un nodo Edge è inattivo.

Quando viene rilevato l'evento: "Lo stato generale del tunnel del nodo Edge {entity_id} è inattivo. "

Quando l'evento viene risolto: "I tunnel del nodo Edge {entity_id} sono stati ripristinati. "

Richiamare il comando della CLI di NSX get tunnel-ports per ottenere tutte le porte del tunnel, quindi controllare le statistiche di ciascun tunnel richiamando il comando della CLI di NSX get tunnel-port &ltUUID&gt stats per verificare se sono presenti interruzioni. Controllare inoltre /var/log/syslog se sono presenti errori relativi a tunnel.

Lo stato del servizio nella DPU è anomalo.

Quando viene rilevato l'evento: "Il servizio {service_name} nella DPU {dpu_id} non risponde da 10 secondi. "

Quando l'evento viene risolto: "Il servizio {service_name} nella DPU {dpu_id} risponde di nuovo. "

Verificare che il servizio {service_name} nella DPU {dpu_id} sia ancora in esecuzione richiamando lo stato /etc/init.d/ di {service_name}. Se il servizio viene segnalato come in esecuzione, potrebbe essere necessario riavviarlo; ciò può essere eseguito tramite il riavvio /etc/init.d/ di {service_name}. Eseguire nuovamente il comando status per verificare che il servizio sia ora in esecuzione. Se il riavvio del servizio non risolve il problema o se il problema si ripresenta dopo un riavvio corretto, contattare l'assistenza VMware.

Lo stato del servizio è anomalo.

Quando viene rilevato l'evento: "l servizio {service_name} non risponde da 10 secondi. "

Quando l'evento viene risolto: "l servizio {service_name} risponde di nuovo. "

Verificare che il servizio {service_name} sia ancora in esecuzione richiamando lo stato /etc/init.d/ di {service_name}. Se il servizio viene segnalato come in esecuzione, potrebbe essere necessario riavviarlo; ciò può essere eseguito tramite il riavvio /etc/init.d/ di {service_name}. Eseguire nuovamente il comando status per verificare che il servizio sia ora in esecuzione. Se lo script /etc/init.d/{service_name} non è disponibile, richiamare lo stato systemctl {service_name} e riavviare mediante systemctl {service_name} con privilegi root. Se il riavvio del servizio non risolve il problema o se il problema si ripresenta dopo un riavvio corretto, contattare l'assistenza VMware.

Impossibile consegnare le metriche alla destinazione specificata.

Quando viene rilevato l'evento: "Impossibile fornire le metriche da SHA alla destinazione {metrics_target_alias}({metrics_target_address}:{metrics_target_port}). "

Quando l'evento viene risolto: "Consegna delle metriche a destinazione {metrics_target_alias}({metrics_target_address}:{metrics_target_port}) ripristinata. "

L'utente deve eseguire i controlli seguenti per escludere il problema che causa l'errore: 1. Controllare se l'indirizzo di destinazione {metrics_target_address} e la porta {metrics_target_port} (il valore predefinito è 443 nel caso in cui la porta non sia specificata) passata per la connessione siano la destinazione prevista, 2. Verificare che il certificato sia corretto tramite /opt/vmware/nsx-nestdb/bin/nestdb-cli --cmd "put vmware.nsx.nestdb.CommonAgentHostConfigMsg", 3. Controllare se {metrics_target_address} di destinazione è raggiungibile, 4. Verificare che il gestore delle metriche in {metrics_target_address} di destinazione sia in esecuzione da docker ps | grep metrics_manager, 5. Verificare se la porta {metrics_target_port} è aperta da netstat -a | grep {metrics_target_port} nella destinazione, 6. Verificare che nel nodo sia installata la regola firewall ALLOW tramite iptables -S OUTPUT | grep {metrics_target_port}(EDGE/UA) o localcli network firewall ruleset list | grep nsx-sha-tsdb(ESX), 7. Riavviare il daemon SHA per verificare se può essere risolto tramite /etc/init.d/netopa restart(ESX) o /etc/init.d/nsx-netopa restart(EDGE) o /etc/init.d/nsx-sha restart(UA).

Il servizio Edge è inattivo per almeno un minuto.

Quando viene rilevato l'evento: "Il servizio {edge_service_name} è inattivo per almeno un minuto. {service_down_reason}"

Quando l'evento viene risolto: "Il servizio {edge_service_name} è attivo. "

Nel nodo Edge, verificare che il servizio non sia stato disattivato a causa di un errore durante la ricerca dei file core nella directory /var/log/core. Richiamare inoltre il comando della CLI di NSX get services per confermare se il servizio è stato interrotto. In tal caso, richiamare il comando start service &ltservice-name&gt per riavviare il servizio.

Lo stato del servizio Edge è stato modificato.

Quando viene rilevato l'evento: "Il servizio {edge_service_name} è stato modificato da {previous_service_state} a {current_service_state}. {service_down_reason}"

Quando l'evento viene risolto: "Il servizio {edge_service_name} è stato modificato da {previous_service_state} a {current_service_state}. "

Nel nodo Edge, verificare che il servizio non sia stato disattivato a causa di un errore durante la ricerca dei file core nella directory /var/log/core. Richiamare inoltre il comando della CLI di NSX get services per confermare se il servizio è stato interrotto. In tal caso, richiamare il comando start service &ltservice-name&gt per riavviare il servizio.

L'applicazione si è arrestata in modo anomalo e ha generato un dump core.

Quando viene rilevato l'evento: "L'applicazione nel nodo NSX {node_display_or_host_name} si è arrestata in modo anomalo. Il numero di file core trovati è {core_dump_count}. Raccogliere il bundle di supporto, inclusi i file di dump principale e contattare il team dell'assistenza VMware. "

Quando l'evento viene risolto: "Tutti i file di dump core vengono ritirati dal sistema. "

Raccogliere il bundle di supporto per il nodo NSX {node_display_or_host_name} utilizzando l'interfaccia utente o l'API di NSX Manager. Nota: i dump principali possono essere impostati per essere spostati o copiati nel bundle di supporto tecnico di NSX per rimuovere o conservare la copia locale nel nodo. La copia del bundle di supporto con i file di dump core è essenziale per consentire al team di assistenza VMware di risolvere il problema ed è consigliabile salvare una copia più recente del bundle di supporto tecnico che includa i file di dump principali prima di rimuovere i file di dump principali dal sistema. Per ulteriori dettagli, fare riferimento all'articolo della KB.

Un nodo di trasporto è disconnesso dal broker di messaggistica del nodo di Intelligence. Questo influisce sulla raccolta dati.

Quando viene rilevato l'evento: "L'utilità di esportazione del flusso nel nodo di trasporto {entity_id} si è disconnessa dal broker di messaggistica del nodo di Intelligence. Questo influisce sulla raccolta dati. "

Quando l'evento viene risolto: "L'utilità di esportazione del flusso nel nodo di trasporto {entity_id} si è riconnessa al broker di messaggistica del nodo di Intelligence. "

Riavviare il servizio di messaggistica se non è in esecuzione nel nodo di Intelligence. Risolvere l'errore di connessione di rete tra l'utilità di esportazione del flusso del nodo di trasporto e il nodo di Intelligence.

L'utilizzo della CPU del nodo di Intelligence è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Utilizzare il comando top per verificare quali processi hanno il maggior numero di utilizzi della CPU, quindi controllare /var/log/syslog e i registri locali di questi processi per verificare se sono presenti errori in sospeso da risolvere.

L'utilizzo della CPU del nodo di Intelligence è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Utilizzare il comando top per verificare quali processi hanno il maggior numero di utilizzi della CPU, quindi controllare /var/log/syslog e i registri locali di questi processi per verificare se sono presenti errori in sospeso da risolvere.

L'utilizzo della memoria del nodo di Intelligence è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Utilizzare il comando top per verificare quali processi hanno il maggior numero di utilizzi della memoria, quindi controllare /var/log/syslog e i registri locali di questi processi per verificare se sono presenti errori in sospeso da risolvere.

L'utilizzo della memoria del nodo di Intelligence è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Utilizzare il comando top per verificare quali processi hanno il maggior numero di utilizzi della memoria, quindi controllare /var/log/syslog e i registri locali di questi processi per verificare se sono presenti errori in sospeso da risolvere.

L'utilizzo del disco del nodo di Intelligence è molto elevato.

Quando viene rilevato l'evento: L'utilizzo del disco della partizione del disco {disk_partition_name} nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: L'utilizzo del disco della partizione del disco {disk_partition_name} nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la partizione del disco {disk_partition_name} e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

L'utilizzo del disco del nodo di Intelligence è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco della partizione del disco {disk_partition_name} nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco della partizione del disco {disk_partition_name} nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la partizione del disco {disk_partition_name} e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

L'utilizzo della partizione del disco dati del nodo di Intelligence è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco della partizione/data del disco nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco della partizione/data del disco nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Interrompere la raccolta dei dati NSX Intelligence finché l'utilizzo del disco non è inferiore alla soglia. Nell'interfaccia utente di NSX passare a Sistema | Appliance | Appliance NSX Intelligence. Quindi Fare clic su AZIONI, Interrompi raccolta dati.

L'utilizzo della partizione del disco dati del nodo di Intelligence è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco della partizione/data del disco nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco della partizione/data del disco nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Interrompere la raccolta dei dati NSX Intelligence finché l'utilizzo del disco non è inferiore alla soglia. Esaminare la partizione del disco/dati e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

La latenza di archiviazione del nodo di Intelligence è elevata.

Quando viene rilevato l'evento: "La latenza di archiviazione della partizione del disco {disk_partition_name} nel nodo di Intelligence {intelligence_node_id} è superiore al valore di soglia elevato del {system_usage_threshold} millisecondi. "

Quando l'evento viene risolto: "La latenza di archiviazione della partizione del disco {disk_partition_name} nel nodo di Intelligence {intelligence_node_id} è inferiore al valore di soglia elevato del {system_usage_threshold} millisecondi. "

È possibile che si verifichi una latenza di archiviazione elevata transitoria a causa del picco di richieste di I/O. Se la latenza di archiviazione rimane alta per più di 30 minuti, è consigliabile distribuire l'appliance NSX Intelligence in un disco a bassa latenza o non condividere lo stesso dispositivo di archiviazione con altre macchine virtuali.

Lo stato del nodo di Intelligence è danneggiato.

Quando viene rilevato l'evento: Il nodo di Intelligence {intelligence_node_id} è danneggiato. "

Quando l'evento viene risolto: "Il nodo di Intelligence {intelligence_node_id} è in esecuzione. "

Richiamare l'NSX API GET /napp/api/v1/platform/monitor/category/health per verificare quale pod specifico è inattivo e il motivo. Richiamare il seguente comando della CLI per riavviare il servizio danneggiato: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt

L'utilizzo del blocco IP è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del blocco IP {intent_path} è molto elevato. Blocco IP prossimo alla sua capacità totale. La creazione di una subnet che utilizza il blocco IP potrebbe non riuscire. "

Quando l'evento viene risolto: "L'utilizzo del blocco IP di {intent_path} è inferiore al livello di soglia. "

Esaminare l'utilizzo del blocco IP. Utilizzare il nuovo blocco IP per la creazione delle risorse o eliminare subnet IP inutilizzata dal blocco IP. Per controllare la subnet utilizzata per il blocco IP. Dall'interfaccia utente di NSX, passare alla scheda Rete | Pool di indirizzi IP| Pool di indirizzi IP. Selezionare i pool di IP in cui viene utilizzato il blocco IP, controllare la colonna Subnet e IP allocati nell'interfaccia utente. Se per il pool di IP non è stata utilizzata alcuna allocazione e non verrà utilizzato in futuro, eliminare la subnet o il pool IP. Utilizzare l'API seguente per verificare se il blocco di IP è utilizzato dal pool di IP e verificare anche la presenza di allocazioni di IP: Per ottenere le subnet configurate di un pool IP, richiamare l'NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-subnets Per ottenere le allocazioni IP, richiamare l'NSX API GET /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations Nota: l'eliminazione del pool o della subnet IP deve essere eseguita solo se non dispone di alcun IP allocato e non verrà utilizzata in futuro.

L'utilizzo del pool di IP è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del pool di IP {intent_path} è molto elevato. Pool di IP prossimo alla sua capacità totale. La creazione dell'entità o del servizio dipende dal fatto che l'IP allocato dal pool di IP non riesca. "

Quando l'evento viene risolto: "L'utilizzo del pool di IP di {intent_path} ora è normale. "

Esaminare l'utilizzo del pool di IP. Rilasciare le allocazioni IP inutilizzate dal pool IP o creare un nuovo pool di IP e utilizzarlo. Dall'interfaccia utente di NSX passare alla scheda Rete | Pool di indirizzi IP| Pool di indirizzi IP. Selezionare i pool IP e controllare la colonna IP allocati per visualizzare gli IP allocati dal pool di IP. Se l'utente visualizza IP che non sono utilizzati, tali IP possono essere rilasciati. Per rilasciare le allocazioni IP inutilizzate, richiamare l'NSX API DELETE /policy/api/v1/infra/ip-pools/&ltip-pool&gt/ip-allocations/&ltip-allocation&gt

Una licenza è scaduta.

Quando viene rilevato l'evento: "La chiave di licenza {license_edition_type} che termina con {displayed_license_key} è scaduta. "

Quando l'evento viene risolto: "La chiave di licenza {license_edition_type} scaduta che termina con {displayed_license_key} è stata rimossa o aggiornata oppure non sta più per scadere. "

Aggiungere una nuova licenza non scaduta utilizzando l'interfaccia utente di NSX passando a Sistema | Licenze, quindi fare clic su AGGIUNGI e specificare la chiave della nuova licenza. La licenza scaduta deve essere eliminata selezionando la casella di controllo della licenza e facendo clic su ELIMINA.

Una licenza sta per scadere.

Quando viene rilevato l'evento: "La chiave di licenza {license_edition_type} che termina con {displayed_license_key} sta per scadere. "

Quando l'evento viene risolto: "La chiave di licenza {license_edition_type} in scadenza che termina con {displayed_license_key} è stata rimossa o aggiornata oppure non sta più per scadere. "

La licenza scadrà tra diversi giorni. È consigliabile aggiungere una nuova licenza non scaduta utilizzando l'interfaccia utente di NSX passando a Sistema | Licenze, quindi fare clic su AGGIUNGI e specificare la chiave della nuova licenza. La licenza scaduta deve essere eliminata selezionando la casella di controllo della licenza e facendo clic su ELIMINA.

L'utilizzo della CPU del bilanciamento del carico è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del bilanciamento del carico {entity_id} è molto elevato. La soglia è {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del bilanciamento del carico {entity_id} è insufficiente. La soglia è {system_usage_threshold}%. "

Se l'utilizzo della CPU del bilanciamento del carico è maggiore della soglia di utilizzo del sistema, il carico di lavoro è troppo elevato per questo bilanciamento del carico. Ridimensionare il servizio di bilanciamento del carico modificando le dimensioni del bilanciamento del carico da piccole a medie o da medie a grandi. Se l'utilizzo della CPU di questo bilanciamento del carico è ancora elevato, è consigliabile modificare le dimensioni del fattore di forma dell'appliance Edge o spostare i servizi di bilanciamento del carico in altri nodi Edge per il carico di lavoro applicabile.

Il servizio di bilanciamento del carico è danneggiato.

Quando viene rilevato l'evento: "Il servizio di bilanciamento del carico {entity_id} è danneggiato. "

Quando l'evento viene risolto: "Il servizio di bilanciamento del carico {entity_id} non è danneggiato. "

Per il bilanciamento del carico centralizzato: Controllare lo stato del bilanciamento del carico nel nodo Edge di standby perché lo stato danneggiato indica che lo stato del bilanciamento del carico nel nodo Edge di standby non è pronto. Nel nodo Edge di standby, richiamare il comando della CLI di NSX get load-balancer &ltlb-uuid&gt status. Se lo stato LB del servizio del bilanciamento del carico è not_ready o non è presente alcun output, attivare la modalità di manutenzione per il nodo Edge, quindi uscire dalla modalità di manutenzione. Per il bilanciamento del carico distribuito:
1. Per ottenere lo stato dettagliato, richiamare l'NSX API GET /policy/api/v1/infra/lb-services/&ltLBService&gt/detailed-status?source=realtime
2. Dall'output API, trovare l'host ESXi che segnala un instance_number diverso da zero con stato NOT_READY o CONFLITTO.
3. Nel nodo host ESXi, richiamare il comando della CLI di NSX "get load-balancer &ltlb-uuid&gt status". Se viene segnalato 'LSP di conflitto', verificare che questo LSP sia collegato a un altro servizio di bilanciamento del carico. Verificare che questo conflitto sia accettabile. Se viene segnalato "LSP non pronto", controllare lo stato di questo LSP richiamando il comando della CLI di NSX get logical-switch-port status. Nota: è consigliabile ignorare l'allarme se può essere risolto automaticamente in 5 minuti perché lo stato danneggiato può essere uno stato temporaneo.

Il servizio di bilanciamento del carico distribuito è inattivo.

Quando viene rilevato l'evento: "Il servizio di bilanciamento del carico distribuito {entity_id} è inattivo. "

Quando l'evento viene risolto: "Il servizio di bilanciamento del carico distribuito {entity_id} è attivo. "

Nel nodo host ESXi, richiamare il comando della CLI di NSX "get load-balancer &ltlb-uuid&gt status". Se viene segnalato 'LSP di conflitto', verificare che questo LSP sia collegato a un altro servizio di bilanciamento del carico. Verificare che questo conflitto sia accettabile. Se viene segnalato "LSP non pronto", controllare lo stato di questo LSP richiamando il comando della CLI di NSX get logical-switch-port status.

Il servizio di bilanciamento del carico centralizzato è inattivo.

Quando viene rilevato l'evento: "Il servizio di bilanciamento del carico centralizzato {entity_id} è inattivo. "

Quando l'evento viene risolto: "Il servizio di bilanciamento del carico centralizzato {entity_id} è attivo. "

Nel nodo Edge attivo, controllare lo stato del bilanciamento del carico richiamando il comando della CLI di NSX get load-balancer &ltlb-uuid&gt status. Se lo stato LB del servizio del bilanciamento del carico è not_ready o non è presente alcun output, attivare la modalità di manutenzione per il nodo Edge, quindi uscire dalla modalità di manutenzione.

Il servizio virtuale del bilanciamento del carico è inattivo.

Quando viene rilevato l'evento: "Il server virtuale di bilanciamento del carico {entity_id} è inattivo. "

Quando l'evento viene risolto: "Il server virtuale di bilanciamento del carico {entity_id} è attivo. "

Consultare il pool di bilanciamento del carico per determinarne lo stato e verificarne la configurazione. Se configurato in modo errato, riconfigurarlo e rimuovere il pool di bilanciamento del carico dal server virtuale, quindi aggiungerlo nuovamente al server virtuale.

Il pool di bilanciamento del carico è inattivo.

Quando viene rilevato l'evento: "Lo stato del pool di bilanciamento del carico {entity_id} è inattivo. "

Quando l'evento viene risolto: "Lo stato del pool di bilanciamento del carico {entity_id} è attivo"

Consultare il pool di bilanciamento del carico per determinare quali membri sono inattivi richiamando il comando della CLI di NSX get load-balancer &ltlb-uuid&gt pool &ltpool-uuid&gt status o l'NSX API GET /policy/api/v1/infra/lb-services/&ltlb-service-id&gt/lb-pools/&ltlb-pool-id&gt/detailed-status Se viene segnalato INATTIVO o SCONOSCIUTO, verificare il membro del pool. Controllare la connettività di rete dal bilanciamento del carico ai membri del pool interessati. Convalidare l'integrità dell'applicazione per ogni membro del pool. Convalidare inoltre l'integrità di ciascun membro del pool utilizzando il monitor configurato. Quando viene stabilita l'integrità del membro, lo stato del membro del pool viene aggiornato come integro in base alla configurazione 'Numero controlli positivi' nel monitor. Correggere il problema riavviando il membro del pool o impostando la modalità di manutenzione per il nodo Edge, quindi uscire dalla modalità di manutenzione.

L'utilizzo del bilanciamento del carico è elevato.

Quando viene rilevato l'evento: "L'utilizzo del servizio di bilanciamento del carico nel nodo edge {entity_id} è elevato. La soglia è {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del servizio di bilanciamento del carico nel nodo edge {entity_id} è insufficiente. La soglia è {system_usage_threshold}%. "

Se sono state configurate più istanze LB in questo nodo Edge, distribuire un nuovo nodo Edge e spostare alcune istanze LB in quest'ultimo. Se è stata configurata solo una singola istanza LB (piccola/media/ecc.) in un nodo Edge delle stesse dimensioni (piccola/media/ecc.), distribuire un nuovo Edge di dimensioni maggiori e spostare l'istanza LB in quest'ultimo.

L'utilizzo del membro del pool di bilanciamento del carico è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo dei membri del pool nel nodo Edge {entity_id} è molto elevato. La soglia è {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo dei membri del pool nel nodo Edge {entity_id} è insufficiente. La soglia è {system_usage_threshold}%. "

Distribuire un nuovo nodo Edge e spostare il servizio di bilanciamento del carico dai nodi Edge esistenti al nodo Edge appena distribuito.

La configurazione del bilanciamento del carico non è stata realizzata a causa dell'utilizzo elevato della memoria nel nodo Edge.

Quando viene rilevato l'evento: "La configurazione del bilanciamento del carico {entity_id} non è realizzata a causa dell'utilizzo elevato della memoria nel nodo Edge {transport_node_id}. "

Quando l'evento viene risolto: "La configurazione del bilanciamento del carico {entity_id} è stata eseguita in {transport_node_id}. "

Preferire la definizione dei bilanciamenti del carico di piccole e medie dimensioni rispetto ai bilanciamenti del carico di grandi dimensioni. Distribuire i servizi di bilanciamento del carico tra i nodi Edge disponibili. Ridurre il numero di server virtuali definiti.

Lo stato del servizio è inattivo.

Quando viene rilevato l'evento: "Il servizio {mps_service_name} non è in esecuzione in {transport_node_name}. "

Quando l'evento viene risolto: "Il servizio {mps_service_name} è in esecuzione correttamente in {transport_node_name}. "

1. Nel nodo Edge identificato da {nsx_edge_tn_name}, richiamare il comando della CLI di NSX get services per verificare lo stato di {mps_service_name}. Esaminare /var/log/syslog per trovare gli errori sospetti.
2. Nel nodo host identificato da {nsx_esx_tn_name}, accedere alla macchina virtuale del servizio di prevenzione malware associato {entity_id} e controllare lo stato di {mps_service_name}. Esaminare /var/log/syslog nlla macchina virtuale del servizio di prevenzione malware associata {entity_id} per individuare eventuali errori sospetti.

Lo stato del servizio è danneggiato.

Quando viene rilevato l'evento: "Il servizio{mps_service_name} è danneggiato in {transport_node_name}. Impossibile comunicare con la funzionalità di estrazione del file. Tutte le capacità di estrazione dei file in {transport_node_name} sono in pausa. "

Quando l'evento viene risolto: "Il servizio {mps_service_name} è in esecuzione correttamente in {transport_node_name}. "

1. Nel nodo Edge identificato da {nsx_edge_tn_name}, richiamare il comando della CLI di NSX get ids engine status per verificare lo stato del servizio file_extraction (IDS). Esaminare /var/log/syslog per trovare eventuali errori sospetti con il servizio di estrazione del file (IDS) e/o {mps_service_name}.
2. Nel nodo host identificato da {nsx_esx_tn_name}, accedere alla macchina virtuale del servizio di prevenzione malware associato {entity_id} e controllare lo stato del servizio di estrazione del file (NXGI). Esaminare /var/log/syslog nlla macchina virtuale del servizio di prevenzione malware associata {entity_id} per individuare eventuali errori sospetti.

Lo stato del servizio è danneggiato.

Quando viene rilevato l'evento: "Il servizio {mps_service_name} è danneggiato in NSX Application Platform. Non è in grado di comunicare con il database per la prevenzione malware. "

Quando l'evento viene risolto: "Il servizio {mps_service_name} è correttamente in esecuzione in NSX Application Platform. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali per verificare quale servizio è danneggiato. Richiamare l'NSX API GET /napp/api/v1/platform/monitor/feature/health per verificare quale servizio specifico è inattivo e il motivo. Richiamare il seguente comando della CLI per riavviare il servizio danneggiato: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt Determinare lo stato del servizio Database per la prevenzione malware.

Lo stato del servizio è danneggiato.

Quando viene rilevato l'evento: "Il servizio {mps_service_name} è danneggiato in NSX Application Platform. Non è in grado di comunicare con il servizio analyst_api. I verdetti dei file ispezionati potrebbero non essere aggiornati. "

Quando l'evento viene risolto: "Il servizio {mps_service_name} è correttamente in esecuzione in NSX Application Platform. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali per verificare quale servizio è danneggiato. Richiamare l'NSX API GET /napp/api/v1/platform/monitor/feature/health per verificare quale servizio specifico è inattivo e il motivo. Richiamare il seguente comando della CLI per riavviare il servizio danneggiato: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt Determinare lo stato del servizio Connettore cloud per la prevenzione malware.

Lo stato del servizio è danneggiato.

Quando viene rilevato l'evento: "Il servizio {mps_service_name} è danneggiato in NSX Application Platform. Non è in grado di comunicare con il servizio di reputazione NTICS. Le reputazioni dei file ispezionati potrebbe non essere aggiornata. "

Quando l'evento viene risolto: "Il servizio {mps_service_name} è correttamente in esecuzione in NSX Application Platform. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali per verificare quale servizio è danneggiato. Richiamare l'NSX API GET /napp/api/v1/platform/monitor/feature/health per verificare quale servizio specifico è inattivo e il motivo. Richiamare il seguente comando della CLI per riavviare il servizio danneggiato: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt Determinare se l'accesso al servizio NTICS è inattivo.

L'utilizzo della CPU del nodo di Manager è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo di Manager. È consigliabile modificare la dimensione del fattore di forma dell'appliance Manager.

L'utilizzo della CPU del nodo di Manager è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo di Manager. È consigliabile modificare la dimensione del fattore di forma dell'appliance Manager.

L'utilizzo della memoria del nodo di Manager è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo di Manager. È consigliabile modificare la dimensione del fattore di forma dell'appliance Manager.

L'utilizzo della memoria del nodo di Manager è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria nel nodo di Manager {entity_id} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la configurazione, i servizi in esecuzione e il dimensionamento di questo nodo di Manager. È consigliabile modificare la dimensione del fattore di forma dell'appliance Manager.

L'utilizzo del disco del nodo di Manager è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione del disco del nodo di Manager {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione del disco del nodo di Manager {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Esaminare la partizione con utilizzo elevato e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

L'utilizzo del disco del nodo di Manager è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione del disco del nodo di Manager {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione del disco del nodo di Manager {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Esaminare la partizione con utilizzo elevato e verificare se sono presenti file di grandi dimensioni non previsti che possono essere rimossi.

L'utilizzo del disco di configurazione del nodo di Manager è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione /config del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. Questo può indicare un utilizzo elevato del disco da parte del servizio NSX Datastore nella directory /config/corfu. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione /config del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Eseguire lo strumento seguente e contattare GSS se vengono segnalati problemi /opt/vmware/tools/support/inspect_checkpoint_issues.py

L'utilizzo del disco di configurazione del nodo di Manager è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione /config del disco del nodo di Manager {disk_partition_name} ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. Questo può indicare un aumento dell'utilizzo del disco da parte del servizio NSX Datastore nella directory /config/corfu. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione /config del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Eseguire lo strumento seguente e contattare GSS se vengono segnalati problemi /opt/vmware/tools/support/inspect_checkpoint_issues.py

L'utilizzo del disco di non configurazione del nodo di Manager è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione /nonconfig del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia molto elevato del {system_usage_threshold}%. Questo può indicare un utilizzo elevato del disco da parte del servizio NSX Datastore nella directory /nonconfig/corfu directory. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione /nonconfig del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Eseguire lo strumento seguente e contattare GSS se vengono segnalati problemi /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

L'utilizzo del disco di non configurazione del nodo di Manager è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco per la partizione /nonconfig del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è pari o superiore al valore di soglia elevato del {system_usage_threshold}%. Questo può indicare un aumento dell'utilizzo del disco da parte del servizio NSX Datastore nella directory /nonconfig/corfu. "

Quando l'evento viene risolto: "L'utilizzo del disco per la partizione /nonconfig del disco del nodo di Manager ha raggiunto il {system_resource_usage}%, che è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Eseguire lo strumento seguente e contattare GSS se vengono segnalati problemi /opt/vmware/tools/support/inspect_checkpoint_issues.py --nonconfig

L'indirizzo IP del nodo di Manager è utilizzato da un altro dispositivo.

Quando viene rilevato l'evento: "L'indirizzo IP {duplicate_ip_address} del nodo di Manager {entity_id} attualmente è utilizzato da un altro dispositivo nella rete. "

Quando l'evento viene risolto: Il dispositivo che utilizza l'indirizzo IP assegnato al nodo di Manager {entity_id} non usa più {duplicate_ip_address}. "

1. Determinare quale dispositivo sta utilizzando l'indirizzo IP di Manager e assegnare al dispositivo un nuovo indirizzo IP. Nota: la riconfigurazione di Manager per l'uso di un nuovo indirizzo IP non è supportata.
2. Assicurarsi che il pool di indirizzi IP statici o il server DHCP siano configurati correttamente.
3. Correggere l'indirizzo IP del dispositivo se è assegnato manualmente.

Il disco del nodo di Manager è di sola lettura.

Quando viene rilevato l'evento: "La seguente partizione del disco nel nodo di Manager {entity_id} è in modalità di sola lettura: {disk_partition_name}"

Quando l'evento viene risolto: "La seguente partizione del disco nel nodo di Manager {entity_id} è stata ripristinata dalla modalità di sola lettura: {disk_partition_name}"

Esaminare la partizione di sola lettura per verificare se il riavvio risolve il problema o se è necessario sostituire il disco. Per ulteriori informazioni, contattare GSS.

Voce DNS mancante per il nome di dominio completo di Manager.

Quando viene rilevato l'evento: "La configurazione DNS per il nodo di Manager {manager_node_name} ({entity_id}) non è corretta. Il nodo di Manager è dual stack e/o viene utilizzato il certificato dell'API firmato dall'autorità di certificazione, ma gli indirizzi IP del nodo di Manager non vengono risolti in un FQDN o vengono risolti in FQDN diversi. "

Quando l'evento viene risolto: "La configurazione DNS per il nodo di Manager {manager_node_name} ({entity_id}) è corretta. Il nodo di Manager non è dual stack e non viene più utilizzato il certificato dell'API firmato dall'autorità di certificazione oppure gli indirizzi IP del nodo di Manager vengono risolti nello stesso FQDN. "

1. Assicurarsi che nel nodo di Manager siano configurati i server DNS appropriati.
2. Assicurarsi che nei server DNS siano configurati record A e record PTR appropriati in modo che la ricerca inversa degli indirizzi IP del nodo di Manager restituisca lo stesso FQDN e la ricerca diretta dell'FQDN restituisca tutti gli indirizzi IP del nodo di Manager.
3. In alternativa, se il nodo di Manager non è dual stack, sostituire il certificato firmato dall'autorità di certificazione per il tipo di servizio API con un certificato autofirmato.

Voce FQDN mancante per il VIP di Manager.

Quando viene rilevato l'evento: "In caso di un certificato API dual stack o firmato da un'autorità di certificazione per un NSX Manager, l'indirizzo IPv4 virtuale {ipv4_address} e l'indirizzo IPv6 virtuale {ipv6_address} per il nodo di Manager {entity_id} devono essere risolti nello stesso FQDN. "

Quando l'evento viene risolto: Indirizzi VIP dual stack per il nodo di Manager {entity_id} risolti nello stesso FQDN. "

Esaminare la voce DNS per gli indirizzi VIP per verificare se vengono risolti nello stesso FQDN.

Configurazione MTU non corrispondente tra i nodi di trasporto collegati alla stessa zona di trasporto.

Quando viene rilevato l'evento: Configurazione MTU non corrispondente tra i nodi di trasporto (ESXi, KVM ed Edge) collegati alla stessa zona di trasporto. I valori di MTU in tutti gli switch collegati alla stessa zona di trasporto non sono coerenti causano problemi di connettività. "

Quando l'evento viene risolto: "Tutti i valori MTU tra i nodi di trasporto collegati alla stessa zona di trasporto sono ora coerenti. "

1. Passare a Sistema | Infrastruttura | Impostazioni | Controllo configurazione MTU | Incoerente nell'interfaccia utente NSX per controllare ulteriori dettagli non corrispondenti.
2. Impostare lo stesso valore MTU in tutti i commutatori collegati alla stessa zona di trasporto richiamando il comando dell'NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt con mtu nel corpo della richiesta oppure il comando dell'API PUT /api/v1/global-configs/SwitchingGlobalConfig con physical_uplink_mtu nel corpo della richiesta.

La configurazione MTU del router globale è maggiore del valore MTU della zona di trasporto overlay.

Quando viene rilevato l'evento: "La configurazione MTU del router globale è maggiore del valore MTU dei commutatori nella zona di trasporto overlay che si connettono al livello 0 o al livello 1. Il valore MTU del router globale deve essere inferiore al valore MTU di tutti i commutatori di almeno 100 poiché sono necessarie 100 quote per l'incapsulamento Geneve. "

Quando l'evento viene risolto: "Il valore MTU del router globale è ora inferiore al valore MTU della zona di trasporto overlay. "

1. Passare a Sistema | Infrastruttura | Impostazioni | Controllo configurazione MTU | Incoerente nell'interfaccia utente NSX per controllare ulteriori dettagli non corrispondenti.
2. Impostare lo stesso MTU maggiore nei commutatori richiamando il comando dell'NSX API PUT /api/v1/host-switch-profiles/&lthost-switch-profile-id&gt con mtu nel corpo della richiesta oppure il comando dell'API PUT /api/v1/global-configs/SwitchingGlobalConfig con physical_uplink_mtu nel corpo della richiesta.
3. In alternativa, impostare il valore MTU più piccolo della configurazione del router globale richiamando l'NSX API PUT /api/v1/global-configs/RoutingGlobalConfig con logical_uplink_mtu nel corpo della richiesta.

L'utilizzo della porta SNAT nel gateway è elevato.

Quando viene rilevato l'evento: "L'utilizzo delle porte SNAT nel router logico {entity_id} per l'IP SNAT {snat_ip_address} ha raggiunto il valore di soglia elevato del {system_usage_threshold}%. I nuovi flussi non verranno attivati con SNAT quando l'utilizzo raggiunge il limite massimo. "

Quando l'evento viene risolto: "L'utilizzo delle porte SNAT nel router logico {entity_id} per l'IP SNAT {snat_ip_address} ha raggiunto un valore inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Accedere come utente amministratore nel nodo Edge e richiamare il comando della CLI di NSX get firewall &ltLR_INT_UUID&gt connection state utilizzando l'UUID dell'interfaccia corretta e controllare le varie mappature SNAT per l'IP SNAT {snat_ip_address}. Verificare che i flussi di traffico che attraversano il gateway non siano un attacco di tipo Denial of Service o un burst anomalo. Se il traffico sembra trovarsi all'interno del carico normale ma si verifica una soglia di allarme, è consigliabile aggiungere più indirizzi IP SNAT per distribuire il carico o instradare il nuovo traffico verso un altro nodo Edge.

Il nodo di Manager ha rilevato che NCP è inattivo o non è integro.

Quando viene rilevato l'evento: "Il nodo di Manager ha rilevato che NCP è inattivo o non è integro. "

Quando l'evento viene risolto: "Il nodo di Manager ha rilevato che l'NCP è di nuovo attivo o integro. "

Per individuare i cluster in cui si verificano problemi, utilizzare l'interfaccia utente di NSX e passare alla pagina Allarmi. Il valore Nome entità per questa istanza dell'allarme identifica il nome del cluster. In alternativa, richiamare l'NSX API GET /api/v1/systemhealth/container-cluster/ncp/status per recuperare tutti gli stati dei cluster e determinare il nome di tutti i cluster che segnalano INATTIVO o SCONOSCIUTO. Quindi nella pagina dell'interfaccia utente NSX Inventario | Container | Cluster trovare il cluster in base al nome e fare clic sulla scheda Nodi, in cui sono elencati tutti i membri dei cluster PAS e Kubernetes. Per i cluster Kubernetes:
1. Verificare la presenza di pod NCP trovando il nodo master K8s da tutti i membri del cluster e accedere al nodo master. Richiamare quindi il comando kubectl get pods --all-namespaces. Se si verifica un problema con il pod NCP, utilizzare il comando kubectl logs per verificare il problema e risolvere l'errore.
2. Controllare la connessione tra NCP e il server dell'API Kubernetes. È possibile utilizzare la CLI NSX nel pod NCP per controllare questo stato di connessione richiamando i comandi seguenti dalla macchina virtuale master. kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-k8s-api-server status Se si verifica un problema relativo alla connessione, controllare sia la configurazione della rete sia quella di NCP.
3. Verificare la connessione tra NCP e NSX Manager. È possibile utilizzare la CLI NSX nel pod NCP per controllare questo stato di connessione richiamando il comando seguente dalla macchina virtuale master. kubectl exec -it &ltNCP-Pod-Name&gt -n nsx-system bash nsxcli get ncp-nsx status Se si verifica un problema relativo alla connessione, controllare sia la configurazione della rete sia quella di NCP. Per il cluster PAS:
1. Controllare le connessioni di rete tra le macchine virtuali e risolvere eventuali problemi di rete.
2. Controllare lo stato di nodi e servizi e correggere i servizi o i nodi con arresto anomalo. Richiamare il comando bosh vms e bosh instances -p per controllare lo stato di nodi e servizi.

Gli agenti in esecuzione nella macchina virtuale del nodo risultano inattivi nella DPU.

Quando viene rilevato l'evento: "Gli agenti in esecuzione nella macchina virtuale del nodo risultano inattivi nella DPU {dpu_id}. "

Quando l'evento viene risolto: "Gli agenti nella macchina virtuale del nodo sono in esecuzione nella DPU {dpu_id}. "

1. Se nella DPU {dpu_id} non è presente Vmk50, fare riferimento a questo articolo della Knowledge Base https://kb.vmware.com/s/article/67432.
2. Se nella DPU {dpu_id} Hyperbus 4094 non è presente, è necessario riavviare nsx-cfgagent in DPU {dpu_id} o riavviare la macchina virtuale host del container.
3. Se la VIF dell'host del container è bloccata, verificare la connessione al controller per verificare che tutte le configurazioni siano state inviate.
4. Se nella DPU {dpu_id} nsx-cfg-agent è stato interrotto, riavviare nsx-cfgagent nella DPU {dpu_id}.
5. Se il pacchetto nodo-agente non è presente, verificare che il pacchetto nodo-agente sia stato installato correttamente nella macchina virtuale host del container.
6. Se l'interfaccia per il nodo-agente nella macchina virtuale host del container è inattiva, controllare lo stato dell'interfaccia eth1 nella macchina virtuale host del container.

Gli agenti in esecuzione nella macchina virtuale del nodo risultano inattivi.

Quando viene rilevato l'evento: "Gli agenti in esecuzione nella macchina virtuale del nodo risultano inattivi. "

Quando l'evento viene risolto: "Gli agenti all'interno della macchina virtuale del nodo sono in esecuzione. "

Per ESX:
1. Se Vmk50 non è presente, fare riferimento a questo articolo della Knowledge Base https://kb.vmware.com/s/article/67432.
2. Se Hyperbus 4094 non è presente, provare a riavviare nsx-cfgagent o la macchina virtuale host del container.
3. Se la VIF dell'host del container è bloccata, verificare la connessione al controller per verificare che tutte le configurazioni siano state inviate.
4. Se nsx-cfg-agent si è interrotto, riavviare nsx-cfgagent. Per KVM:
1. Se lo spazio dei nomi Hyperbus non è presente, riavviando nsx-opsagent è possibile che venga ricreato lo spazio dei nomi.
2. Se l'interfaccia di Hyperbus non è presente nello spazio dei nomi hyperbus, provare a riavviare nsx-opsagent.
3. Se nsx-agent si è interrotto, riavviare nsx-agent. Sia per ESX che per KVM:
1. Se il pacchetto nodo-agente non è presente, verificare che il pacchetto nodo-agente sia stato installato correttamente nella macchina virtuale host del container.
2. Se l'interfaccia per il nodo-agente nella macchina virtuale host del container è inattiva, controllare lo stato dell'interfaccia eth1 nella macchina virtuale host del container.

Il cluster di NSX Application Platform è disconnesso dal cluster di gestione NSX.

Quando viene rilevato l'evento: "Il cluster di NSX Application Platform {napp_cluster_id} è disconnesso dal cluster di gestione NSX. "

Quando l'evento viene risolto: "Il cluster di NSX Application Platform {napp_cluster_id} è riconnesso al cluster di gestione NSX. "

Verificare che il certificato del cluster di Manager, i certificati del nodo di Manager, il certificato Kafka e il certificato in ingresso corrispondano sia in NSX Manager sia nel cluster di NSX Application Platform. Controllare le date di scadenza dei certificati indicati precedentemente per assicurarsi che siano validi. Controllare la connessione di rete tra NSX Manager e il cluster di NSX Application Platform e risolvere eventuali errori di connessione di rete.

È stata rilevata un'elaborazione lenta nel flusso di dati RAW dell'argomento di messaggistica.

Quando viene rilevato l'evento: Il numero di messaggi in sospeso nel flusso di dati RAW dell'argomento di messaggistica è superiore alla soglia dei messaggi in sospeso di {napp_messaging_lag_threshold}. "

Quando l'evento viene risolto: Il numero di messaggi in sospeso nel flusso di dati RAW dell'argomento di messaggistica è inferiore alla soglia dei messaggi in sospeso di {napp_messaging_lag_threshold}. "

Aggiungere i nodi e scalare verticalmente il cluster di NSX Application Platform. Se l'impedimento può essere attributo a un servizio specifico, ad esempio il servizio di analisi, scalare verticalmente il servizio specifico quando vengono aggiunti nuovi nodi.

È stata rilevata un'elaborazione lenta nell'overflow dei dati dell'argomento di messaggistica.

Quando viene rilevato l'evento: "Il numero di messaggi in sospeso nell'overflow dei dati dell'argomento di messaggistica è superiore alla soglia dei messaggi in sospeso di {napp_messaging_lag_threshold}. "

Quando l'evento viene risolto: "Il numero di messaggi in sospeso nell'overflow dei dati dell'argomento di messaggistica è inferiore alla soglia dei messaggi in sospeso di {napp_messaging_lag_threshold}. "

Aggiungere i nodi e scalare verticalmente il cluster di NSX Application Platform. Se l'impedimento può essere attributo a un servizio specifico, ad esempio il servizio di analisi, scalare verticalmente il servizio specifico quando vengono aggiunti nuovi nodi.

Un nodo di trasporto è disconnesso dal broker di messaggistica del cluster di NSX Application Platform. Questo influisce sulla raccolta dati.

Quando viene rilevato l'evento: "L'utilità di esportazione del flusso nel nodo di trasporto {entity_id} è disconnessa dal broker di messaggistica del cluster di NSX Application Platform. Questo influisce sulla raccolta dati. "

Quando l'evento viene risolto: "L'utilità di esportazione del flusso nel nodo di trasporto {entity_id} si è riconnessa al broker di messaggistica del cluster di NSX Application Platform. "

Riavviare il servizio di messaggistica se non è in esecuzione nel cluster di NSX Application Platform. Risolvere l'errore di connessione di rete tra l'utilità di esportazione del flusso del nodo di trasporto e il cluster di NSX Application Platform.

Un nodo di trasporto è disconnesso dal broker di messaggistica del nodo di Intelligence. Questo influisce sulla raccolta dati nella DPU.

Quando viene rilevato l'evento: "L'utilità di esportazione del flusso nella DPU {dpu_id} del nodo di trasporto {entity_id} è disconnessa dal broker di messaggistica del nodo di Intelligence. Questo influisce sulla raccolta dati. "

Quando l'evento viene risolto: "L'utilità di esportazione del flusso nella DPU {dpu_id} del nodo di trasporto {entity_id} è stata riconnessa al broker di messaggistica del nodo di Intelligence. "

Riavviare il servizio di messaggistica se non è in esecuzione nel nodo di Intelligence. Risolvere l'errore di connessione di rete tra l'utilità di esportazione del flusso del nodo di trasporto e il nodo di Intelligence.

L'utilizzo della CPU del cluster di NSX Application Platform è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del cluster di NSX Application Platform {napp_cluster_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del cluster di NSX Application Platform {napp_cluster_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Carico di sistema dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se è necessaria maggiore potenza di elaborazione, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo della CPU del cluster di NSX Application Platform è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del cluster di NSX Application Platform {napp_cluster_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del cluster di NSX Application Platform {napp_cluster_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Carico di sistema dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se è necessaria maggiore potenza di elaborazione, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo della memoria del cluster di NSX Application Platform è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del cluster di NSX Application Platform {napp_cluster_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del cluster di NSX Application Platform {napp_cluster_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Memoria dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se è necessaria più memoria, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo della memoria del cluster di NSX Application Platform è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del cluster di NSX Application Platform {napp_cluster_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del cluster di NSX Application Platform {napp_cluster_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Memoria dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se è necessaria più memoria, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo del disco del cluster di NSX Application Platform è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del cluster di NSX Application Platform {napp_cluster_id} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del cluster di NSX Application Platform {napp_cluster_id} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Archivio dei singoli servizi per vedere quale servizio è sotto pressione. Verificare se è possibile ridurre il carico. Se è necessario ulteriore storage su disco, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse. Se il servizio di archiviazione dei dati è sottoposto a un carico di lavoro, è possibile fare clic sul pulsante Scalabilità verticale per aumentare le dimensioni del disco.

L'utilizzo del disco del cluster di NSX Application Platform è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del cluster di NSX Application Platform {napp_cluster_id} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del cluster di NSX Application Platform {napp_cluster_id} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Archivio dei singoli servizi per vedere quale servizio è sotto pressione. Verificare se è possibile ridurre il carico. Se è necessario ulteriore storage su disco, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse. Se il servizio di archiviazione dei dati è sottoposto a un carico di lavoro, è possibile fare clic sul pulsante Scalabilità verticale per aumentare le dimensioni del disco.

Lo stato globale del cluster NSX Application Platform è danneggiato.

Quando viene rilevato l'evento: "Lo stato globale del cluster {napp_cluster_id} NSX Application Platform è danneggiato. "

Quando l'evento viene risolto: "Il cluster di NSX Application Platform {napp_cluster_id} è in esecuzione. "

Ottenere ulteriori informazioni dagli allarmi di nodi e servizi.

Lo stato globale del cluster NSX Application Platform è inattivo.

Quando viene rilevato l'evento: "Lo stato globale del cluster {napp_cluster_id} NSX Application Platform è inattivo. "

Quando l'evento viene risolto: "Il cluster di NSX Application Platform {napp_cluster_id} è in esecuzione. "

Ottenere ulteriori informazioni dagli allarmi di nodi e servizi.

L'utilizzo della CPU del nodo NSX Application Platform è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del nodo di NSX Application Platform {napp_node_name} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del nodo di NSX Application Platform {napp_node_name} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Carico di sistema dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se solo una piccola parte dei nodi ha un utilizzo elevato della CPU, per impostazione predefinita Kubernetes ripianificherà automaticamente i servizi. Se la maggior parte dei nodi ha un utilizzo elevato della CPU e il carico non può essere ridotto, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo della CPU del nodo NSX Application Platform è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del nodo di NSX Application Platform {napp_node_name} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del nodo di NSX Application Platform {napp_node_name} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Carico di sistema dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se solo una piccola parte dei nodi ha un utilizzo elevato della CPU, per impostazione predefinita Kubernetes ripianificherà automaticamente i servizi. Se la maggior parte dei nodi ha un utilizzo elevato della CPU e il carico non può essere ridotto, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo della memoria del nodo NSX Application Platform è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del nodo di NSX Application Platform {napp_node_name} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del nodo di NSX Application Platform {napp_node_name} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Memoria dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se solo una piccola parte dei nodi ha un utilizzo elevato della memoria, per impostazione predefinita Kubernetes ripianificherà automaticamente i servizi. Se la maggior parte dei nodi ha un utilizzo elevato della memoria e il carico non può essere ridotto, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo della memoria del nodo NSX Application Platform è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del nodo di NSX Application Platform {napp_node_name} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del nodo di NSX Application Platform {napp_node_name} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Memoria dei singoli servizi per verificare quale servizio è sottoposto a pressione. Verificare se è possibile ridurre il carico. Se solo una piccola parte dei nodi ha un utilizzo elevato della memoria, per impostazione predefinita Kubernetes ripianificherà automaticamente i servizi. Se la maggior parte dei nodi ha un utilizzo elevato della memoria e il carico non può essere ridotto, fare clic sul pulsante Scalabilità orizzontale per richiedere ulteriori risorse.

L'utilizzo del disco del nodo NSX Application Platform è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del nodo di NSX Application Platform {napp_node_name} è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del nodo di NSX Application Platform {napp_node_name} è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Archivio dei singoli servizi per vedere quale servizio è sotto pressione. Pulire i dati o il registro inutilizzati per liberare risorse del disco e verificare se è possibile ridurre il carico. Se è necessario più spazio di storage su disco, scalare orizzontalmente il servizio in caso di pressione. Se il servizio di archiviazione dei dati è sottoposto a un carico di lavoro, è possibile fare clic sul pulsante Scalabilità verticale per aumentare le dimensioni del disco.

L'utilizzo del disco del nodo NSX Application Platform è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del nodo di NSX Application Platform {napp_node_name} è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del nodo di NSX Application Platform {napp_node_name} è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali e controllare il campo Archivio dei singoli servizi per vedere quale servizio è sotto pressione. Pulire i dati o il registro inutilizzati per liberare risorse del disco e verificare se è possibile ridurre il carico. Se è necessario più spazio di storage su disco, scalare orizzontalmente il servizio in caso di pressione. Se il servizio di archiviazione dei dati è sottoposto a un carico di lavoro, è possibile fare clic sul pulsante Scalabilità verticale per aumentare le dimensioni del disco.

Lo stato del nodo NSX Application Platform è danneggiato.

Quando viene rilevato l'evento: "Il nodo NSX Application Platform {napp_node_name} è danneggiato. "

Quando l'evento viene risolto: "Il nodo di NSX Application Platform {napp_node_name} è in esecuzione. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Risorse per verificare quale nodo è danneggiato. Controllare l'utilizzo di rete, memoria e CPU del nodo. Riavviare il nodo se si tratta di un nodo di lavoro.

Lo stato del nodo NSX Application Platform è inattivo.

Quando viene rilevato l'evento: "Il nodo NSX Application Platform {napp_node_name} non è in esecuzione. "

Quando l'evento viene risolto: "Il nodo di NSX Application Platform {napp_node_name} è in esecuzione. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Risorse per verificare quale nodo è inattivo. Controllare l'utilizzo di rete, memoria e CPU del nodo. Riavviare il nodo se si tratta di un nodo di lavoro.

L'utilizzo della CPU del servizio Archivio dati è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio di Archivio dati è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Archivio dati è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di archiviazione dei dati.

L'utilizzo della CPU del servizio Archivio dati è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio di Archivio dati è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Archivio dati è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di archiviazione dei dati.

L'utilizzo della CPU del servizio di messaggistica è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio di messaggistica è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Messaggi è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di messaggistica.

L'utilizzo della CPU del servizio di messaggistica è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio di messaggistica è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Messaggi è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di messaggistica.

L'utilizzo della CPU del servizio Database configurazione è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio del database di configurazione è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Database configurazione è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della CPU del servizio Database configurazione è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio del database di configurazione è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Database configurazione è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della CPU del servizio di metriche è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio Metriche è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Metriche è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della CPU del servizio di metriche è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio Metriche è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio Metriche è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della CPU del servizio di analisi è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio di analisi è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio di analisi è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio Analytics.

L'utilizzo della CPU del servizio di analisi è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio funzionalità di analisi è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU del servizio funzionalità di analisi è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio Analytics.

L'utilizzo della CPU del servizio Platform Services è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio Platform Services è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU di Servizi di Platform è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della CPU del servizio Platform Services è elevato.

Quando viene rilevato l'evento: "L'utilizzo della CPU del servizio Platform Services è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della CPU di Servizi di Platform è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della memoria del servizio Archivio dati è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio di Archivio dati è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Archivio dati è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di archiviazione dei dati.

L'utilizzo della memoria del servizio Archivio dati è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio di Archivio dati è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Archivio dati è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di archiviazione dei dati.

L'utilizzo della memoria del servizio di messaggistica è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio di messaggistica è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Messaggi è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di messaggistica.

L'utilizzo della memoria del servizio di messaggistica è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio di messaggistica è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Messaggi è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio di messaggistica.

L'utilizzo della memoria del servizio Database configurazione è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio del database di configurazione è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Database configurazione è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della memoria del servizio Database configurazione è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio del database di configurazione è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Database configurazione è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della memoria del servizio delle metriche è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio Metriche è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Metriche è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della memoria del servizio delle metriche è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio Metriche è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio Metriche è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della memoria del servizio di analisi è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio di analisi è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio di analisi è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio Analytics.

L'utilizzo della memoria del servizio di analisi è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio di analisi è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria del servizio di analisi è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi o il servizio Analytics.

L'utilizzo della memoria del servizio Platform Services è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio Platform Services è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria di Servizi di Platform è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo della memoria del servizio Platform Services è elevato.

Quando viene rilevato l'evento: "L'utilizzo della memoria del servizio Platform Services è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo della memoria di Servizi di Platform è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente tutti i servizi.

L'utilizzo del disco del servizio Archivio dati è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Archiviazione dei dati è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Archiviazione dei dati è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Scalare orizzontalmente o scalare il servizio di archiviazione dei dati.

L'utilizzo del disco del servizio Archivio dati è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Archiviazione dei dati è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Archiviazione dei dati è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Scalare orizzontalmente o scalare il servizio di archiviazione dei dati.

L'utilizzo del disco del servizio di messaggistica è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio di messaggistica è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio di messaggistica è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi o il servizio di messaggistica.

L'utilizzo del disco del servizio di messaggistica è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio di messaggistica è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio di messaggistica è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi o il servizio di messaggistica.

L'utilizzo del disco del servizio Database configurazione è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Database configurazione è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Database configurazione è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi.

L'utilizzo del disco del servizio Database configurazione è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Database configurazione è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Database configurazione è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi.

L'utilizzo del disco del servizio delle metriche è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Metriche è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Metriche è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi.

L'utilizzo del disco del servizio delle metriche è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Metriche è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Metriche è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi.

L'utilizzo del disco del servizio di analisi è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio di analisi è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio di analisi è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi o il servizio Analytics.

L'utilizzo del disco del servizio di analisi è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio di analisi è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio di analisi è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi o il servizio Analytics.

L'utilizzo del disco del servizio Platform Services è molto elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Platform Services è superiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Platform Services è inferiore al valore di soglia molto elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi.

L'utilizzo del disco del servizio Platform Services è elevato.

Quando viene rilevato l'evento: "L'utilizzo del disco del servizio Platform Services è superiore al valore di soglia elevato del {system_usage_threshold}%. "

Quando l'evento viene risolto: "L'utilizzo del disco del servizio Platform Services è inferiore al valore di soglia elevato del {system_usage_threshold}%. "

Non è necessario eliminare file. Scalare orizzontalmente tutti i servizi.

Lo stato del servizio è danneggiato.

Quando viene rilevato l'evento: "Il servizio {napp_service_name} è danneggiato. Il servizio potrebbe ancora raggiungere il quorum mentre i pod associati a {napp_service_name} non sono tutti stabili. Le risorse utilizzate da questi pod instabili potrebbero essere rilasciate. "

Quando l'evento viene risolto: "Il servizio {napp_service_name} è in esecuzione. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali per verificare quale servizio è danneggiato. Richiamare l'NSX API GET /napp/api/v1/platform/monitor/feature/health per verificare quale servizio specifico è danneggiato e il motivo. Richiamare il seguente comando della CLI per riavviare il servizio danneggiato se necessario: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt I servizi danneggiati possono funzionare correttamente ma le prestazioni non sono ottimali.

Lo stato del servizio è inattivo.

Quando viene rilevato l'evento: "Il servizio {napp_service_name} non è in esecuzione. "

Quando l'evento viene risolto: "Il servizio {napp_service_name} è in esecuzione. "

Nell'interfaccia utente di NSX, passare a Sistema | NSX Application Platform | Servizi principali per verificare quale servizio è danneggiato. Richiamare l'NSX API GET /napp/api/v1/platform/monitor/feature/health per verificare quale servizio specifico è inattivo e il motivo. Richiamare il seguente comando della CLI per riavviare il servizio danneggiato: kubectl rollout restart &ltstatefulset/deployment&gt &ltservice_name&gt -n &ltnamespace&gt

Servizio danneggiato.

Quando viene rilevato l'evento: "Il servizio {nsxaas_service_name} è danneggiato. Nello stato corrente, il servizio potrebbe funzionare con una ridotta efficienza e questo potrebbe influire sui carichi di lavoro del cliente. {service_down_reason}"

Quando l'evento viene risolto: "Il servizio {nsxaas_service_name} non è più in uno stato danneggiato. "

Esaminare i dati inclusi nella descrizione dell'allarme che identifica il servizio, dove il servizio viene distribuito e ulteriori dati acquisiti dal servizio di monitoraggio dell'integrità. Esaminare anche i dati cronologici registrati dal servizio Metriche o da Wavefront come applicabile.

Servizio inattivo.

Quando viene rilevato l'evento: "Il servizio {nsxaas_service_name} è inattivo. {service_down_reason}"

Quando l'evento viene risolto: "Il servizio {nsxaas_service_name} è nuovamente disponibile. "

Esaminare i dati inclusi nella descrizione dell'allarme che identifica il servizio, dove il servizio viene distribuito e ulteriori dati acquisiti dal servizio di monitoraggio dell'integrità. Esaminare anche i dati cronologici registrati dal servizio Metriche o da Wavefront come applicabile.

La password dell'utente è scaduta.

Quando viene rilevato l'evento: "La password per l'utente {username} è scaduta. "

Quando l'evento viene risolto: "La password per l'utente {username} è stata modificata correttamente o non è più scaduta oppure l'utente non è più attivo. "

Per accedere al sistema, è necessario modificare la password dell'utente {username}. Ad esempio, per applicare una nuova password a un utente, richiamare l'NSX API seguente con una password valida nel corpo della richiesta: PUT /api/v1/node/users/&ltuserid&gt dove &ltuserid&gt è l'ID dell'utente. Se la password dell'utente amministratore (con &ltuserid&gt 10000) è scaduta, l'amministratore deve accedere al sistema tramite SSH (se attivato) o la console per poter modificare la password. Dopo aver immesso la password scaduta corrente, all'amministratore verrà richiesto di immettere una nuova password.

La password dell'utente è quasi scaduta.

Quando viene rilevato l'evento: "La password per l'utente {username} scadrà tra {password_expiration_days} giorni. "

Quando l'evento viene risolto: "La password per l'utente {username} è stata modificata correttamente o non è più scaduta oppure l'utente non è più attivo. "

Assicurarsi che la password per l'utente {username} venga modificata immediatamente. Ad esempio, per applicare una nuova password a un utente, richiamare l'NSX API seguente con una password valida nel corpo della richiesta: PUT /api/v1/node/users/&ltuserid&gt dove &ltuserid&gt è l'ID dell'utente.

La password dell'utente sta per scadere.

Quando viene rilevato l'evento: "La password per l'utente {username} scadrà tra {password_expiration_days} giorni. "

Quando l'evento viene risolto: "La password per l'utente {username} è stata modificata correttamente o non è più scaduta oppure l'utente non è più attivo. "

È necessario cambiare subito la password dell'utente {username}. Ad esempio, per applicare una nuova password a un utente, richiamare l'NSX API seguente con una password valida nel corpo della richiesta: PUT /api/v1/node/users/&ltuserid&gt dove &ltuserid&gt è l'ID dell'utente.

Installazione del server fisico (BMS) non riuscita.

Quando viene rilevato l'evento: "Installazione del server fisico {transport_node_name} ({entity_id}) non riuscita. "

Quando l'evento viene risolto: Installazione del server fisico {transport_node_name} ({entity_id}) completata. "

Passare a Sistema > Infrastruttura > Nodi > Nodi di trasporto host e risolvere l'errore nel nodo.

Aggiornamento del server fisico (BMS) non riuscito.

Quando viene rilevato l'evento: "Aggiornamento del server fisico {transport_node_name} ({entity_id}) non riuscito. "

Quando l'evento viene risolto: "Aggiornamento del server fisico {transport_node_name} ({entity_id}) completato. "

Passare a Sistema > Aggiornamento e risolvere l'errore, quindi riattivare l'aggiornamento.

Disinstallazione del server fisico (BMS) non riuscita.

Quando viene rilevato l'evento: "Disinstallazione del server fisico {transport_node_name} ({entity_id}) non riuscita. "

Quando l'evento viene risolto: "Disinstallazione del server fisico {transport_node_name} ({entity_id}) completata. "

Passare a Sistema > Infrastruttura > Nodi > Nodi di trasporto host e risolvere l'errore nel nodo.

Il numero di entità ha raggiunto il limite del vincolo del criterio.

Quando viene rilevato l'evento: "Il numero di entità per il tipo {constraint_type} in {constraint_type_path} è attualmente pari a {current_count} e ha raggiunto il limite massimo di {constraint_limit}. "

Quando l'evento viene risolto: "Il conteggio di {constraint_type} è inferiore alla soglia. "

Esaminare l'utilizzo di {constraint_type}. Aggiornare il vincolo per aumentare il limite o eliminare i {constraint_type} inutilizzati.

La sessione BFD è inattiva.

Quando viene rilevato l'evento: "Nel router {lr_id} la sessione BFD per il peer {peer_address} è inattiva. "

Quando l'evento viene risolto: "Nel router {lr_id} la sessione BFD per il peer {peer_address} è attiva. "

1. Richiamare il comando NSX della CLI get logical-routers.
2. Passare al router di servizio {sr_id}
3. Richiamare il ping di comando NSX della CLI ping {peer_address} per controllare lo stato della connettività.

Route statica rimossa.

Quando viene rilevato l'evento: "Nel router {Ir_id} la route statica {entity_id} ({static_address}) è stata rimossa perché il protocollo BFD era inattivo. "

Quando l'evento viene risolto: "Nel router {lr_id} la route statica {entity_id} ({static_address}) è stata aggiunta nuovamente perché il protocollo BFD è stato ripristinato. "

La voce del routing statico è stata rimossa perché la sessione BFD era inattiva.
1. Richiamare il comando NSX della CLI get logical-routers.
2. Passare al router di servizio {sr_id}.
3. Richiamare il comando della CLI di NSX ping &ltBFD peer IP address&gt per verificare la connettività. Verificare inoltre la configurazione sia in NSX che nel peer BFD per assicurarsi che i timer non siano stati modificati.

Router adiacente BGP inattivo.

Quando viene rilevato l'evento: "Nel router {lr_id}, il router adiacente BGP {entity_id} ({bgp_neighbor_ip}) è inattivo. Motivo: {failure_reason}. "

Quando l'evento viene risolto: "Nel router {lr_id}, il router adiacente BGP {entity_id} ({bgp_neighbor_ip}) è attivo. "

1. Richiamare il comando NSX della CLI get logical-routers.
2. Passare al router di servizio {sr_id}. Se il motivo indica Errore di rete o di configurazione -
3. Richiamare il comando della CLI di NSX get bgp neighbor summary per controllare lo stato del router adiacente BGP. Se il motivo mostra Edge non è pronto, verificare il motivo per cui lo stato del nodo Edge non è appropriato.
4. Richiamare il comando della CLI di NSX get edge-cluster status per verificare il motivo per cui il nodo Edge potrebbe essere inattivo.
5. Richiamare i comandi della CLI di NSX get bfd-config e get bfd-sessions per verificare che BFD sia in esecuzione.
6. Controllare eventuali allarmi relativi all'integrità Edge per ottenere ulteriori informazioni. Verificare in /var/log/syslog se sono presenti errori relativi alla connettività BGP.

ARP del proxy non configurato per l'IP del servizio.

Quando viene rilevato l'evento: "L'ARP del proxy per l'IP del servizio {service_ip} e l'entità del servizio {entity_id} non è configurato perché il numero di voci ARP del proxy generate a causa della sovrapposizione dell'IP del servizio con subnet di lrport {lrport_id} nel router {lr_id} ha superato il limite di soglia consentito di 16384. "

Quando l'evento viene risolto: "Il proxy ARP per l'entità di servizio {entity_id} è stato generato correttamente perché la sovrapposizione dell'IP del servizio con la subnet di lrport {lrport_id} nel router {lr_id} rientra nel limite consentito di 16384 voci. "

Riconfigurare l'IP del servizio {service_ip} per l'entità del servizio {entity_id} o modificare la subnet di lrport {lrport_id} nel router {lr_id} in modo che le voci ARP del proxy generate a causa della sovrapposizione tra l'IP del servizio e la subnet di lrport siano inferiori al limite di soglia consentito di 16384.

Tutte le sessioni BGP/BFD sono inattive.

Quando viene rilevato l'evento: "Tutte le sessioni BGP/BFD sono inattive. "

Quando l'evento viene risolto: "Almeno una sessione BGP/BFD attiva. "

Richiamare il comando della CLI di NSX get logical-routers per ottenere il router del servizio di livello 0 e passare a questo VRF, quindi richiamare i comandi della CLI di NSX seguenti.
1. ping &ltBFD peer IP address&gt per verificare la connettività.
2. get bfd-config e get bfd-sessions per verificare che BFD sia in esecuzione correttamente.
3. get bgp neighbor summary per verificare che BGP sia in esecuzione correttamente. Inoltre, verificare in /var/log/syslog se sono presenti errori relativi alla connettività BGP.

Il router adiacente OSPF è passato dallo stato completo a un altro stato.

Quando viene rilevato l'evento: "Il router adiacente OSPF {peer_address} è passato da completo a un altro stato. "

Quando l'evento viene risolto: "Il router adiacente OSPF {peer_address} è passato allo stato completo. "

1. Richiamare il comando della CLI di NSX get logical-routers per ottenere l'ID VRF e passare al router del servizio di LIVELLO 0.
2. Eseguire get ospf neighbor per controllare lo stato corrente di questo router adiacente. Se il router adiacente non è elencato nell'output, il router adiacente è diventato inattivo o esterno alla rete.
3. Richiamare il comando della CLI di NSX ping &ltOSPF neighbor IP address&gt per verificare la connettività.
4. Verificare inoltre la configurazione di NSX e del router peer per assicurarsi che i timer e l'ID area corrispondano.
5. Verificare in /var/log/syslog se sono presenti errori relativi alla connettività.

Si sta per superare il limite massimo di route IPv4 nel nodo Edge.

Quando viene rilevato l'evento: "Il limite di route IPv4 ha raggiunto {route_limit_threshold} nel gateway di livello 0 e tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

Quando l'evento viene risolto: "Le route IPv4 rientrano nel limite di {route_limit_threshold} nel gateway di livello 0 e in tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

1. Controllare i criteri di ridistribuzione della route e le route ricevute da tutti i peer esterni.
2. È consigliabile ridurre il numero di route applicando di conseguenza criteri e filtri di routing.

Si sta per superare il limite massimo di route IPv6 si nel nodo Edge.

Quando viene rilevato l'evento: "Il limite di route IPv6 ha raggiunto {route_limit_threshold} nel gateway di livello 0 e tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

Quando l'evento viene risolto: "Le route IPv6 rientrano nel limite di {route_limit_threshold} nel gateway di livello 0 e in tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

1. Controllare i criteri di ridistribuzione della route e le route ricevute da tutti i peer esterni.
2. È consigliabile ridurre il numero di route applicando di conseguenza criteri e filtri di routing.

È stato superato il limite massimo di route IPv4 nel nodo Edge.

Quando viene rilevato l'evento: "Le route IPv4 hanno superato il limite di {route_limit_maximum} nel gateway di livello 0 e tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

Quando l'evento viene risolto: "Le route IPv4 rientrano nel limite di {route_limit_maximum} nel gateway di livello 0 e in tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

1. Controllare i criteri di ridistribuzione della route e le route ricevute da tutti i peer esterni.
2. È consigliabile ridurre il numero di route applicando di conseguenza criteri e filtri di routing.

È stato superato il limite massimo di route IPv6 nel nodo Edge.

Quando viene rilevato l'evento: "Le route IPv6 hanno superato il limite di {route_limit_maximum} nel gateway di livello 0 e tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

Quando l'evento viene risolto: "Le route IPv6 rientrano nel limite di {route_limit_maximum} nel gateway di livello 0 e in tutti i VRF di livello 0 nel nodo Edge {edge_node}. "

1. Controllare i criteri di ridistribuzione della route e le route ricevute da tutti i peer esterni.
2. È consigliabile ridurre il numero di route applicando di conseguenza criteri e filtri di routing.

Si sta per superare il numero massimo di prefissi IPv4 ricevuti dal router adiacente BGP.

Quando viene rilevato l'evento: "Il numero di prefissi IPv4 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} raggiunge {prefixes_count_threshold}. Il limite definito per questo peer è {prefixes_count_max}. "

Quando l'evento viene risolto: "Il numero di prefissi IPv4 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} non supera il limite {prefixes_count_threshold}. "

1. Controllare i criteri di routing BGP nel router esterno.
2. È consigliabile ridurre il numero di route annunciate dal peer BGP applicando criteri e filtri di routing al router esterno.
3. Se necessario, aumentare le impostazioni massime dei prefissi nella sezione di configurazione del router adiacente BGP.

Si sta per superare il numero massimo di prefissi IPv6 ricevuti dal router adiacente BGP.

Quando viene rilevato l'evento: "Il numero di prefissi IPv6 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} raggiunge {prefixes_count_threshold}. Il limite definito per questo peer è {prefixes_count_max}. "

Quando l'evento viene risolto: "Il numero di prefissi IPv6 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} non supera il limite {prefixes_count_threshold}. "

1. Controllare i criteri di routing BGP nel router esterno.
2. È consigliabile ridurre il numero di route annunciate dal peer BGP applicando criteri e filtri di routing al router esterno.
3. Se necessario, aumentare le impostazioni massime dei prefissi nella sezione di configurazione del router adiacente BGP.

È stato superato il numero massimo di prefissi IPv4 ricevuti dal router adiacente BGP.

Quando viene rilevato l'evento: "Il numero di prefissi IPv4 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} ha superato il limite definito per questo peer, ovvero {prefixes_count_max}. "

Quando l'evento viene risolto: "Il numero di prefissi IPv4 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} non supera il limite {prefixes_count_max}. "

1. Controllare i criteri di routing BGP nel router esterno.
2. È consigliabile ridurre il numero di route annunciate dal peer BGP applicando criteri e filtri di routing al router esterno.
3. Se necessario, aumentare le impostazioni massime dei prefissi nella sezione di configurazione del router adiacente BGP.

È stato superato il numero massimo di prefissi IPv6 ricevuti dal router adiacente BGP.

Quando viene rilevato l'evento: "Il numero di prefissi IPv6 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} ha superato il limite definito per questo peer, ovvero {prefixes_count_max}. "

Quando l'evento viene risolto: "Il numero di prefissi IPv6 {subsequent_address_family} ricevuti da {bgp_neighbor_ip} non supera il limite {prefixes_count_max}. "

1. Controllare i criteri di routing BGP nel router esterno.
2. È consigliabile ridurre il numero di route annunciate dal peer BGP applicando criteri e filtri di routing al router esterno.
3. Se necessario, aumentare le impostazioni massime dei prefissi nella sezione di configurazione del router adiacente BGP.

Lo stato di sicurezza di NSX non è conforme a NDcPP.

Quando viene rilevato l'evento: "Uno dei requisiti di conformità di NDcPP è stato violato. Ciò significa che lo stato di NSX è attualmente non conforme per quanto riguarda NDcPP. "

Quando l'evento viene risolto: "Tutti i problemi relativi alla conformità a NDcPP sono stati risolti. "

Eseguire il report di conformità dal menu dell'interfaccia utente Home - Monitoraggio e dashboard - Report di conformità e risolvere tutti i problemi contrassegnati con il nome della conformità NDcPP.

Lo stato di sicurezza di NSX non è conforme a EAL4+.

Quando viene rilevato l'evento: "Uno dei requisiti di conformità EAL4+ è stato violato. Ciò significa che lo stato di NSX è attualmente non conforme per quanto riguarda EAL4+. "

Quando l'evento viene risolto: "Tutti i problemi relativi alla conformità a EAL4+ sono stati risolti. "

Eseguire il report di conformità dal menu dell'interfaccia utente Home - Monitoraggio e dashboard - Report di conformità e risolvere tutti i problemi contrassegnati con il nome della conformità EAL4+.

La configurazione di sicurezza di NSX non è conforme a NDcPP.

Quando viene rilevato l'evento: "Uno dei requisiti di conformità di NDcPP è stato violato. Ciò significa che la configurazione di NSX è attualmente non conforme per quanto riguarda NDcPP. "

Quando l'evento viene risolto: "Tutti i problemi relativi alla conformità a NDcPP sono stati risolti. "

Eseguire il report di conformità dal menu dell'interfaccia utente Home - Monitoraggio e dashboard - Report di conformità e risolvere tutti i problemi contrassegnati con il nome della conformità NDcPP.

La configurazione di sicurezza di NSX non è conforme a EAL4+.

Quando viene rilevato l'evento: "Uno dei requisiti di conformità EAL4+ è stato violato. Ciò significa che la configurazione di NSX è attualmente non conforme a EAL4+. "

Quando l'evento viene risolto: "Tutti i problemi relativi alla conformità a EAL4+ sono stati risolti. "

Eseguire il report di conformità dal menu dell'interfaccia utente Home - Monitoraggio e dashboard - Report di conformità e risolvere tutti i problemi contrassegnati con il nome della conformità EAL4+.

Distribuzione del servizio completata.

Quando viene rilevato l'evento: "La distribuzione del servizio {entity_id} per il servizio {v} nel cluster {vcenter_cluster_id} è stata completata. "

Quando l'evento viene risolto: "La distribuzione del servizio {entity_id} nel cluster {vcenter_cluster_id} è stata completata. Nessuna azione necessaria. "

Nessuna azione necessaria.

Distribuzione del servizio non riuscita.

Quando viene rilevato l'evento: "La distribuzione del servizio {entity_id} per il servizio {service_name} nel cluster {vcenter_cluster_id} non è riuscita. Motivo: {failure_reason}"

Quando l'evento viene risolto: "La distribuzione del servizio {entity_id} non riuscita è stata rimossa. "

Eliminare la distribuzione del servizio utilizzando l'interfaccia utente o l'API NSX. Eseguire le azioni correttive dalla KB e riprovare la distribuzione del servizio.

Eliminazione della distribuzione del servizio completata.

Quando viene rilevato l'evento: "L'eliminazione del servizio {entity_id} per il servizio {v} nel cluster {vcenter_cluster_id} è stata completata. "

Quando l'evento viene risolto: "L'eliminazione del servizio {entity_id} nel cluster {vcenter_cluster_id} è stata completata. Nessuna azione necessaria. "

Nessuna azione necessaria.

Eliminazione della distribuzione del servizio non riuscita.

Quando viene rilevato l'evento: "L'eliminazione del servizio {entity_id} per il servizio {service_name} nel cluster {vcenter_cluster_id} non è riuscita. Motivo: {failure_reason}"

Quando l'evento viene risolto: "Il nome della distribuzione del servizio non riuscita {entity_id} è stata rimossa. "

Eliminare la distribuzione del servizio utilizzando l'interfaccia utente o l'API NSX. Eseguire le azioni correttive dalla KB e riprovare a eliminare la distribuzione del servizio. Risolvere manualmente l'allarme dopo aver verificato che tutte le macchine virtuali e gli oggetti siano stati eliminati.

SVM è in servizio.

Quando viene rilevato l'evento: "Il controllo dello stato della SVM {entity_id} per il servizio {service_name} funziona correttamente in {hostname_or_ip_address_with_port}. "

Quando l'evento viene risolto: "La SVM {entity_id} funziona correttamente. Nessuna azione necessaria. "

Nessuna azione necessaria.

SVM non funzionante nel servizio.

Quando viene rilevato l'evento: "Il controllo dello stato della SVM {entity_id} per il servizio {hostname_or_ip_address_with_port} funziona correttamente in {hostname_or_ip_address_with_port}. Motivo: {failure_reason}. "

Quando l'evento viene risolto: "È stata rimossa la SVM {entity_id} con stato errato. "

Eliminare la distribuzione del servizio utilizzando l'interfaccia utente o l'API NSX. Eseguire le azioni correttive dalla KB e riprovare la distribuzione del servizio, se necessario.

Stato dell'infrastruttura di inserimento del servizio inattivo e non abilitato nell'host.

Quando viene rilevato l'evento: "SPF non abilitato a livello di porta nell'host {transport_node_id} e lo stato è inattivo. Motivo: {failure_reason}. "

Quando l'evento viene risolto: "Lo stato dell'infrastruttura di inserimento del servizio è attivo ed è stato correttamente abilitato nell'host. "

Eseguire eventuali azioni correttive della KB e verificare che lo stato sia attivo. Risolvere manualmente l'allarme dopo aver controllato lo stato.

Stato attività SVM inattivo.

Quando viene rilevato l'evento: "Lo stato di attività SVM è inattivo su {entity_id} e questo influisce sul flusso del traffico. "

Quando l'evento viene risolto: "Lo stato di attività SVM è attivo e configurato come previsto. "

Eseguire eventuali azioni correttive della KB e verificare che lo stato sia attivo.

Percorso della catena di servizi inattivo.

Quando viene rilevato l'evento: "Il percorso della catena di servizi è inattivo su {entity_id} e questo influisce sul flusso del traffico. "

Quando l'evento viene risolto: "Il percorso della catena di servizi è attivo e configurato come previsto. "

Eseguire eventuali azioni correttive della KB e verificare che lo stato sia attivo.

Nuovo host aggiunto nel cluster.

Quando viene rilevato l'evento: "Nuovo host aggiunto nel cluster {vcenter_cluster_id} e la SVM verrà distribuita. "

Quando l'evento viene risolto: "Nuovo host aggiunto correttamente. "

Verificare lo stato di distribuzione della macchina virtuale e attendere che venga accesa.

TEP non è integro.

Quando viene rilevato l'evento: "Il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id}. Nei carichi di lavoro overlay che utilizzano questo TEP si verifica un'interruzione della rete. Motivo: {vtep_fault_reason}. "

Quando l'evento viene risolto: "Il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} è integro. "

1. Controllare se il TEP ha un IP valido o eventuali altri problemi di connettività underlay.
2. Abilitare HA TEP per eseguire il failover dei carichi di lavoro in altri TEP integri.

HA TEP attivata.

Quando viene rilevato l'evento: "HA TEP attivata per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id}. "

Quando l'evento viene risolto: "HA di TEP cancellata per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id}. "

Abilitare AutoRecover o richiamare il ripristino manuale per il TEP {vtep_name} nel VDS {dvs_name} nel nodo di trasporto {transport_node_id}.

Ripristino automatico riuscito.

Quando viene rilevato l'evento: "Ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} riuscito. "

Quando l'evento viene risolto: "Il ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} è stato cancellato. "

nessuna.

Ripristino automatico non riuscito.

Quando viene rilevato l'evento: "Ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} non riuscito. I carichi di lavoro overlay che utilizzano questo TEP eseguiranno il failover in altri TEP integri. Se non sono presenti altri TEP integri, nei carichi di lavoro overlay si verifica un'interruzione della rete. "

Quando l'evento viene risolto: "Il ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} è stato cancellato. "

Controllare se il TEP ha un IP valido o eventuali altri problemi di connettività underlay.

TEP non è integro nella DPU.

Quando viene rilevato l'evento: "Il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id}. Nei carichi di lavoro overlay che utilizzano questo TEP si verifica un'interruzione della rete. Motivo: {vtep_fault_reason}. "

Quando l'evento viene risolto: "Il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id} è integro. "

1. Controllare se il TEP ha un IP valido o eventuali altri problemi di connettività underlay.
2. Abilitare HA TEP per eseguire il failover dei carichi di lavoro in altri TEP integri.

HA TEP attivata nella DPU.

Quando viene rilevato l'evento: "HA TEP attivata per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id}. "

Quando l'evento viene risolto: "HA di TEP cancellata per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id}. "

Abilitare AutoRecover o richiamare il ripristino manuale per il TEP {vtep_name} nel VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id}.

Ripristino automatico riuscito nella DPU.

Quando viene rilevato l'evento: "Ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id} riuscito. "

Quando l'evento viene risolto: "Il ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id} è stato cancellato. "

nessuna.

Ripristino automatico non riuscito nella DPU.

Quando viene rilevato l'evento: "Ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id} non riuscito. I carichi di lavoro overlay che utilizzano questo TEP eseguiranno il failover in altri TEP integri. Se non sono presenti altri TEP integri, nei carichi di lavoro overlay si verifica un'interruzione della rete. "

Quando l'evento viene risolto: "Il ripristino automatico per il TEP {vtep_name} del VDS {dvs_name} nel nodo di trasporto {transport_node_id} nella DPU {dpu_id} è stato cancellato. "

Controllare se il TEP ha un IP valido o eventuali altri problemi di connettività underlay.

L'uplink nella DPU sta diventando inattivo.

Quando viene rilevato l'evento: "L'uplink nella DPU {dpu_id} sta diventando inattivo. "

Quando l'evento viene risolto: !L'uplink nella DPU {dpu_id} sta diventando attivo. "

Controllare lo stato delle schede NIC fisiche degli uplink nella DPU {dpu_id}. Individuare il nome mappato di questa NIC fisica nell'host, quindi eseguire il controllo dell'interfaccia utente.
1. Nell'interfaccia utente di NSX passare a Infrastruttura | Nodi | Nodi di trasporto | Nodi di trasporto host.
2. Nell'elenco Nodi di trasporto host controllare la colonna Stato nodo. Individuare il nodo di trasporto con stato danneggiato o inattivo.
3. Selezionare &lttransport node&gt | Monitora. Controllare i dettagli dello stato del bond (uplink) che segnala uno stato danneggiato o inattivo. Per evitare uno stato danneggiato, assicurarsi che tutte le interfacce di uplink siano connesse e attive, indipendentemente dal fatto che siano in uso.

Membro di creazione report LACP nella DPU inattivo.

Quando viene rilevato l'evento: "Il membro di creazione report LACP nella DPU {dpu_id} è inattivo. "

Quando l'evento viene risolto: "Il membro di creazione report LACP nella DPU {dpu_id} è attivo. "

Controllare lo stato della connessione dei membri LAG nella DPU {dpu_id}. Individuare il nome mappato della relativa NIC fisica nell'host, quindi eseguire il controllo dell'interfaccia utente.
1. Nell'interfaccia utente di NSX passare a Infrastruttura | Nodi | Nodi di trasporto | Nodi di trasporto host.
2. Nell'elenco Nodi di trasporto host controllare la colonna Stato nodo. Individuare il nodo di trasporto con stato danneggiato o inattivo.
3. Selezionare &lttransport node&gt | Monitora. Trovare il bond (uplink) che segnala lo stato danneggiato o inattivo.
4. Controllare i dettagli dello stato del membro LACP accedendo alla DPU non riuscita {dpu_id} e richiamando il comando esxcli network vswitch dvs vmware lacp status get.

L'uplink sta diventando inattivo.

Quando viene rilevato l'evento: "L'uplink sta diventando inattivo. "

Quando l'evento viene risolto: "L'uplink sta diventando attivo. "

Controllare lo stato delle schede NIC fisiche degli uplink negli host.
1. Nell'interfaccia utente di NSX passare a Infrastruttura | Nodi | Nodi di trasporto | Nodi di trasporto host.
2. Nell'elenco Nodi di trasporto host controllare la colonna Stato nodo. Individuare il nodo di trasporto con stato danneggiato o inattivo.
3. Selezionare &lttransport node&gt | Monitora. Controllare i dettagli dello stato del bond (uplink) che segnala uno stato danneggiato o inattivo. Per evitare uno stato danneggiato, assicurarsi che tutte le interfacce di uplink siano connesse e attive, indipendentemente dal fatto che siano in uso.

L'uplink sta diventando inattivo.

Quando viene rilevato l'evento: "L'uplink sta diventando inattivo. "

Quando l'evento viene risolto: "L'uplink sta diventando attivo. "

Controllare lo stato delle schede NIC fisiche degli uplink negli host.
1. Nell'interfaccia utente di NSX passare a Infrastruttura | Nodi | Nodi di trasporto | Nodi di trasporto host.
2. Nell'elenco Nodi di trasporto host controllare la colonna Stato nodo. Individuare il nodo di trasporto con stato danneggiato o inattivo.
3. Selezionare &lttransport node&gt | Monitora. Controllare i dettagli dello stato del bond (uplink) che segnala uno stato danneggiato o inattivo. Per evitare uno stato danneggiato, assicurarsi che tutte le interfacce di uplink siano connesse e attive, indipendentemente dal fatto che siano in uso.

Membro del report LACP inattivo.

Quando viene rilevato l'evento: "Membro del report LACP inattivo. "

Quando l'evento viene risolto: Membro del report LACP attivo. "

Controllare lo stato della connessione dei membri LAG sugli host.
1. Nell'interfaccia utente di NSX passare a Infrastruttura | Nodi | Nodi di trasporto | Nodi di trasporto host.
2. Nell'elenco Nodi di trasporto host controllare la colonna Stato nodo. Individuare il nodo di trasporto con stato danneggiato o inattivo.
3. Selezionare &lttransport node&gt | Monitora. Trovare il bond (uplink) che segnala lo stato danneggiato o inattivo.
4. Controllare i dettagli dello stato del membro LACP accedendo all'host non riuscito e richiamando il comando esxcli network vswitch dvs vmware lacp status get in un host ESXi o ovs-appctl bond/show e ovs-appctl lacp/show in un host KVM.

Impossibile realizzare completamente Transit Connect.

Quando viene rilevato l'evento: "La configurazione correlata a Transit Connect non è stata realizzata completamente correttamente. I possibili problemi potrebbero causare il mancato recupero delle informazioni del provider o un errore temporaneo di comunicazione del provider. "

Quando l'evento viene risolto: "L'errore di Transit Connect è stato corretto. "

Se l'allarme non viene risolto automaticamente entro 10 minuti, riprovare le richieste relative a Transit Connect più recenti. Ad esempio, se una richiesta API di collegamento TGW attiva questo allarme, riprovare la richiesta dell'API di collegamento TGW. Se l'allarme non viene risolto nonostante il nuovo tentativo, provare a eseguire i passaggi seguenti:
1. Verificare se l'attività continua a non riuscire o se è stata ripristinata. a) Identificare il nodo leader di Manager. Dopo aver effettuato l'accesso a uno dei nodi, eseguire il comando: - su admin - get cluster status verbose Verrà visualizzato il nodo leader di Manager b) Accedere al nodo leader di Manager NSX. Controllare vmc-app.log nel nodo leader di Manager NSX: - tail -f /var/log/policy/vmc-app.log c) Controllare i registri per le stampe seguenti - Se uno di questi messaggi di errore continua a essere visualizzato ogni due minuti, significa che l'attività continua a non riuscire. - Impossibile ottenere la tabella di route TGW per []. Errore: [] - Impossibile ottenere e route TGW per il collegamento [] nella tabella di route []. Errore - Impossibile ottenere l'ID VPC del collegamento TGW per []. Errore: [] - Impossibile ottenere l'ID risorsa del collegamento TGW per []. Errore: Tipo di risorsa sconosciuto - Impossibile ottenere i collegamenti TGW per TGW []. Errore: []- Impossibile ottenere il collegamento TGW locale []. Errore: [] - Impossibile trovare lo stato di TgwAttachment corretto in AWS, stato: [], l'attività di aggiornamento della route TGW verrà ignorata - Il collegamento TGW [] non è associato ad alcuna tabella di route - Non è stato trovato alcun collegamento SDDC TGW locale per []
2. Verificare se tutte le chiamate AWS da NSX Manager non sono riuscite nel nodo leader di Manager. Eseguire comando seguente: - export HTTP_PROXY=http://&ltpop ip&gt:3128 - export HTTPS_PROXY=http://&ltpop ip&gt:3128 - export NO_PROXY=169.254.169.254 - aws ec2 describe-instances --region Se il comando aws non riesce con errore, è possibile che si verifichi un problema di sistema nella configurazione del proxy inverso HTTP nella PoP o che si verifichi un problema sul lato servizio AWS.
3. Verificare se il collegamento TGW esiste ancora in AWS. a) L'ID del collegamento TGW è stato trovato con GET cloud-service/api/v1/infra/associated-groups - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt Se il collegamento TGW è stato eliminato, contattare l'assistenza VMware, condividere l'ID SDDC e l'ID del collegamento TGW. Dopo che il team dell'assistenza VMware ha identificato il problema, eliminare manualmente l'oggetto rimasto, se necessario. b) Verificare che questo collegamento TGW sia presente nella console di AWS. c) Un'altra opzione consiste nell'accedere a NSX Manager, utilizzando il comando aws per verificare lo stato del collegamento TGW: - aws ec2 describe-transit-gateway-attachments --region --transit-gateway-attachment-id &ltTGW attachment ID&gt

Il servizio IPSec è inattivo.

Quando viene rilevato l'evento: "Il servizio IPsec {entity_id} è inattivo. Motivo: {service_down_reason}. "

Quando l'evento viene risolto: "Il servizio IPsec {entity_id} è attivo. "

1. Disabilitare e abilitare il servizio IPSec dall'interfaccia utente NSX Manager.
2. Se il problema persiste, verificare la presenza di registri degli errori in syslog e contattare l'assistenza VMware.

La sessione VPN IPsec basata su criterio è inattiva.

Quando viene rilevato l'evento: "La sessione VPN IPSec basata su criterio {entity_id} è inattiva. Motivo: {session_down_reason}. "

Quando l'evento viene risolto: "La sessione VPN IPSec basata su criterio {entity_id} è attiva. "

Controllare la configurazione della sessione VPN IPSec e risolvere gli errori in base al motivo dell'inattività della sessione.

La sessione VPN IPSec basata su route è inattiva.

Quando viene rilevato l'evento: "La sessione VPN IPSec basata su route {entity_id} è inattiva. Motivo: {session_down_reason}. "

Quando l'evento viene risolto: "La sessione VPN IPSec basata su route {entity_id} è attiva. "

Controllare la configurazione della sessione VPN IPSec e risolvere gli errori in base al motivo dell'inattività della sessione.

I tunnel VPN IPsec basati su criteri sono inattivi.

Quando viene rilevato l'evento: "Uno o più tunnel VPN IPSec basati su criteri nella sessione {entity_id} sono inattivi. "

Quando l'evento viene risolto: "Tutti i tunnel VPN IPSec basati su criterio nella sessione {entity_id} sono attivi. "

Controllare la configurazione della sessione VPN IPSec e risolvere gli errori in base al motivo dell'inattività del tunnel.

Il tunnel VPN IPSec basato su route è inattivo.

Quando viene rilevato l'evento: "Il tunnel VPN IPSec basato su route nella sessione {entity_id} è inattivo. Motivo: {tunnel_down_reason}. "

Quando l'evento viene risolto: "Il tunnel VPN IPSec basato su route nella sessione {entity_id} è attivo. "

Controllare la configurazione della sessione VPN IPSec e risolvere gli errori in base al motivo dell'inattività del tunnel.

La sessione VPN L2 è inattiva.

Quando viene rilevato l'evento: "La sessione VPN L2 {entity_id} è inattiva. "

Quando l'evento viene risolto: "La sessione VPN L2 {entity_id} è attiva. "

Controllare lo stato della sessione VPN L2 per individuare il motivo dell'inattività della sessione e risolvere gli errori di conseguenza.