In dieser Referenzdokumentation werden die verschiedenen Statistiken beschrieben, die von den ESXi-Host-Transportknoten in Ihrer NSX-Bereitstellung erfasst werden.
Im ersten Abschnitt dieses Dokuments werden die Statistiken des Host-Transportknotens beschrieben, die in der Benutzeroberfläche von NSX Manager angezeigt werden.
In den restlichen Abschnitten dieses Dokuments werden die Statistiken beschrieben, die von den verschiedenen Datenpfadmodulen erfasst werden, die auf den ESXi-Host-Transportknoten ausgeführt werden. Um diese Statistiken anzuzeigen, müssen Sie entweder die NSX-APIs oder die zentrale NSX-CLI verwenden. Die Spalte Statistik in diesen Abschnitten bezieht sich auf den Namen der Statistik, wie er in der API-Ausgabe angezeigt wird. Weitere Informationen zum API-Workflow zum Anzeigen der Host-Transportknotenstatistiken finden Sie unter Überwachen von Statistiken von NSX Host-Transportknoten mithilfe von APIs.
Registerkarte „Datenpfad-Statistik“
Auf dieser Registerkarte werden die aggregierten Statistikwerte für einen Host-Transportknoten in der Benutzeroberfläche von NSX Manager angezeigt.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| Empfangene Broadcast-Pakete |
Rate der vom VDS von der VM empfangenen Broadcast-Pakete. Diese Statistik wird intern der Statistik „rxbcastpkts“ zugeordnet. |
4.2.0 |
| Übertragene Broadcast-Pakete |
Rate der vom VDS an die VM gesendeten Broadcast-Pakete. Diese Statistik wird intern der Statistik „txbcastpkts“ zugeordnet. |
4.2.0 |
| Broadcast-Rate für die Begrenzung von Paketverlusten |
Anzahl der eingehenden oder ausgehenden Pakete, die durch die Begrenzung der Broadcast-Rate verworfen wurden. Ratenbegrenzungen werden verwendet, um das Netzwerk oder VMs vor Ereignissen wie Broadcast-Stürmen zu schützen. Sie können Ratenbegrenzungen in der Benutzeroberfläche von NSX Manager unter konfigurieren. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: rx_rate_limit_bcast_drops, rx_rate_limit_mcast_drops, tx_rate_limit_bcast_drops, tx_rate_limit_mcast_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| DFW |
Gesamtzahl der Pakete, die vom DFW-Modul aus verschiedenen Gründen verworfen wurden. Klicken Sie auf den Link NSX-Datenpfad auf der Benutzeroberfläche, um Details zu den Verwerfungen zu erhalten. |
4.2.0 |
| Datenpfad L3 |
Gesamtzahl der Pakete, die aus verschiedenen Gründen vom Datenpfad-L3-Modul verworfen wurden. Klicken Sie auf den Link NSX-Datenpfad auf der Benutzeroberfläche, um Details zu den Verwerfungen zu erhalten. |
4.2.0 |
| Datenpfadsystemfehler |
Gesamtzahl der aufgrund von kritischen internen Systemfehlern verworfenen Pakete. Wenn diese Statistiken kontinuierlich steigen, bedeutet dies, dass der ESXi-Host nur noch über wenige Ressourcen verfügt. Das Verschieben bestimmter VMs auf andere Hosts kann dazu beitragen, die Last zu erleichtern. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: leaf_rx_system_err_drops, uplink_rx_system_err_drops, pkt_attr_error_drops, tx_dispatch_queue_too_long_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Fast Path |
Gesamtzahl der Pakete, die vom Fastpath-Modul aus verschiedenen Gründen verworfen wurden. Klicken Sie auf den Link NSX-Datenpfad auf der Benutzeroberfläche, um Details zu den Verwerfungen zu erhalten. |
4.2.0 |
| Fastpath-Flow-Treffer |
Rate der Treffer in der Flow-Tabelle im ENS-/Flow-Cache-Modul. Diese Statistik wird intern der Statistik „hits“ zugeordnet. |
4.2.0 |
| Fastpath-Flow-Fehler |
Rate der Pakete, die aufgrund eines Flow-Fehlers von Slowpath verarbeitet werden. Diese Statistik überschneidet sich nicht mit der Statistik in der nächsten Zeile. Diese Statistik wird intern der Statistik „miss“ zugeordnet. |
4.2.0 |
| Fastpath-Paketverluste |
Gesamtanzahl der Pakete, die vom Flow-Cache-Fastpath in Empfangs- oder Übertragungsrichtung zu allen Ports verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: rx_drops, tx_drops, rx_drops_uplink, tx_drops_uplink, rx_drops_sp, tx_drops_sp. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Firewall-Flood-Grenzwert |
Anzahl der Pakete, die aufgrund des Grenzwerts für die Protokollüberflutung verworfen wurden. Es gibt einen konfigurierten Flood-Grenzwert für verschiedene Protokolle in der Kernel-Schnittstelle. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: udp_flood_overlimit_drops, tcp_flood_overlimit_drops, icmp_flood_overlimit_drops, other_flood_overlimit_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Interner Firewallfehler |
Anzahl der Pakete, die von der Firewall aufgrund interner Fehler verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: memory_drops, state_insert_drops, l7_attr_error_drops, lb_reject_drops, src_limit_misc. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Firewall Falsch formatiert |
Anzahl der falsch formatierten Pakete, die von der Firewall verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: fragment_drops, short_drops, normalize_drops, bad_timestamp_drops, proto_cksum_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketablehnungen durch Firewall |
Anzahl der Pakete, die von der Firewall aus verschiedenen Gründen abgelehnt wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: rx_ipv4_reject_pkts, tx_ipv4_reject_pkts, rx_ipv6_reject_pkts, tx_ipv6_reject_pkts. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Firewallregel empfangen |
Anzahl der empfangenen Pakete, die durch die Regel „Verwerfen“ oder „Ablehnen“ verworfen wurden. Diese Statistik wird intern der Statistik „match_drop_rule_rx_drops“ zugeordnet. |
4.2.0 |
| Paketverluste – Firewallregel übertragen |
Anzahl der übertragenen Pakete, die durch die Regel „Verwerfen“ oder „Ablehnen“ verworfen wurden. Diese Statistik wird intern der Statistik „match_drop_rule_tx_drops“ zugeordnet. |
4.2.0 |
| Paketverluste – Firewallstatusprüfung |
Anzahl der Pakete, die aufgrund von statusbezogenen Prüfungen verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: icmp_err_pkt_drops, alg_handler_drops, syn_expected_drops, ip_option_drops, syn_proxy_drops, spoof_guard_drops, state_mismatch_drops, strict_no_syn_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Firewall-Zustandstabelle voll |
Anzahl der Pakete, die aufgrund des erreichten maximalen Grenzwerts für Zustände verworfen wurden. Wenn beispielsweise die Anzahl der TCP-Zustände höher als der Grenzwert ist, führt dies zu einem Verwerfen. Diese Statistik wird intern der Statistik „state_limit_drops“ zugeordnet. |
4.2.0 |
| Firewallpaketverluste insgesamt |
Die Gesamtanzahl der Pakete, die aus verschiedenen Gründen von der Firewall verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: rx_ipv4_reject_pkts, tx_ipv4_reject_pkts, rx_ipv6_reject_pkts, tx_ipv6_reject_pkts, rx_ipv4_drop_pkts, tx_ipv4_drop_pkts, rx_ipv6_drop_pkts, tx_ipv6_drop_pkts, rx_l2_drop_pkts, tx_l2_drop_pkts. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Host-Switch-Netzwerk stimmt nicht überein |
Anzahl der Unicast-, Multicast- und Broadcast-Pakete, die aufgrund von VNI- oder VLAN-Tag-Nichtübereinstimmungen verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: vlan_tag_mismatch_rx, vlan_tag_mismatch_tx, vni_tag_mismatch_tx, vlan_tag_mismatch_rx_mcast, vlan_tag_mismatch_tx_mcast, vni_tag_mismatch_tx_mcast. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Host-Switch hat gefälschte MAC empfangen |
Anzahl der Pakete, die als gefälscht verworfen wurden, da sich die Quell-MAC des Pakets von der MAC des Adapters der virtuellen Maschine unterscheidet. Gefälschte Übertragungen oder deaktivierte MAC-Lernvorgänge im Segment führen zu diesen Verwerfungen. Die Aktivierung von MAC Learning oder gefälschten Übertragungen im Segment sollte das Problem abmildern. Diese Statistik wird intern der Statistik „forged_transmit_rx_drops“ zugeordnet. |
4.2.0 |
| Paketverluste – L3-Hop-Grenzwert |
Anzahl der IPv4- oder IPv6-Pakete, die aufgrund einer niedrigen TTL (Time-To-Live) verworfen wurden. Jede logische Router-Instanz zieht 1 vom TTL-Wert ab. Verwenden Sie die Paketerfassung, um zu ermitteln, welche Pakete niedrige TTL-Werte aufweisen. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: ttl_ip4_drops, ttl_ipv6_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – L3-Nachbar nicht erreichbar |
Anzahl der IPv4- oder IPv6-Pakete, die aufgrund einer fehlgeschlagenen Nachbarauflösung verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: arp_hold_pkt_drops, ns_hold_pkt_drops. |
4.2.0 |
| Paketverluste – L3 keine Route |
Jede logische Router-Instanz verfügt über eine eigene Routing-Tabelle für die Routensuche. Diese Statistik steigt, wenn IPv4-Pakete verworfen werden, weil keine übereinstimmenden Routen für diese logische Router-Instanz vorhanden sind. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: no_route_ipv4_drops, no_route_ipv6_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Umgekehrte L3-Pfadweiterleitung |
Anzahl der IPv4- oder IPv6-Pakete, die aufgrund eines Fehlers bei der Überprüfung der umgekehrten Pfadweiterleitung verworfen wurden. Der verteilte Router überprüft möglicherweise, ob die Quell-IP der Pakete von einer gültigen (erreichbaren) Quelle stammt, und verwirft die Pakete möglicherweise basierend auf der Konfiguration. Sie können diese Einstellung in der Benutzeroberfläche von NSX Manager ändern. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: rpf_ipv4_drops, rpf_ipv6_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Mac Learning – Tabelle voll |
Rate der Paketverluste aufgrund von Fehlern bei der Aktualisierung der MAC-Tabelle zum Zeitpunkt des MAC-Lernvorgangs entweder von der zentralen Control Plane (CCP) oder für die vom Underlay-Netzwerk empfangenen Pakete. Überprüfen Sie mithilfe des folgenden Befehls, ob die MAC-Tabelle auf dem Host-Transportknoten voll ist: $ nsxcli -c "get segment mac-table" Erhöhen Sie bei Bedarf die MAC-Tabellengröße. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: mac_tbl_update_full, mac_tbl_lookup_full. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Empfangene Multicast-Pakete |
Rate der vom VDS von der VM empfangenen Multicast-Pakete. Diese Statistik wird intern der Statistik „rx_mcast_pkts“ zugeordnet. |
4.2.0 |
| Übertragene Multicast-Pakete |
Rate der vom VDS an die VM gesendeten Multicast-Pakete. Diese Statistik wird intern der Statistik „tx_mcast_pkts“ zugeordnet. |
4.2.0 |
| Overlay-Datenpfad L2 |
Gesamtzahl der Pakete, die aus verschiedenen Gründen vom Overlay-Datenpfad-L2-Modul verworfen wurden. Klicken Sie auf den Link NSX-Datenpfad auf der Benutzeroberfläche, um Details zu den Verwerfungen zu erhalten. |
4.2.0 |
| Overlay-Datenpfad an Uplink übertragen |
Rate der Unicast-Pakete, die aufgrund eines MAC-Tabellen-Lookup-Fehlers an Remote-VTEPs geflutet wurden. Hohe Werte deuten auf Probleme mit unidirektionalen L2-Flows oder MAC-Tabellenaktualisierungen hin. Überprüfen Sie mithilfe des folgenden Befehls, ob die MAC-Tabelle auf dem Host-Transportknoten voll ist: $ nsxcli -c "get segment mac-table" Erhöhen Sie bei Bedarf die MAC-Tabellengröße. Diese Statistik wird intern der Statistik „mac_tbl_lookup_flood“ zugeordnet. |
4.2.0 |
| Overlay nicht erfolgreich – Auflösung des unterstützten Nachbarn der Steuerungsebene |
Rate des Paketverlusts, weil die Steuerungsebene die Nachbarauflösung nicht erfolgreich unterstützen kann. Die Gründe könnten sein, dass CCP die IP-MAC-Zuordnung noch nicht gelernt hat oder dass das System nur über geringe Paketpufferressourcen verfügt. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: nd_proxy_resp_unknown, arp_proxy_resp_unknown, nd_proxy_req_fail_drops, arp_proxy_req_fail_drops, arp_proxy_resp_drops, nd_proxy_resp_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Von Overlay empfangen |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2LeafInput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere empfangene Leaf an, um den spezifischen Grund für die Verworfenen zu identifizieren. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: leaf_rx_ref_port_not_found_drops, leaf_rx_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Overlay übertragen |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2LeafOutput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere gesendete Leaf an, um den spezifischen Grund für die Verworfenen zu identifizieren. Diese Statistik wird intern der Statistik „leaf_tx_drops“ zugeordnet. |
4.2.0 |
| Paketverluste – Von Overlay-Uplink empfangen |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2UplinkInput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere empfangene Uplink an, um den spezifischen Grund für die Verworfenen zu identifizieren. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: uplink_rx_drops, uplink_rx_guest_vlan_drops, uplink_rx_invalid_encap_drops, mcast_proxy_rx_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – Overlay-Uplink Übertragen |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2UplinkOutput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere übertragene Uplink an, um den spezifischen Grund für die Verworfenen zu identifizieren. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: uplink_tx_drops, nested_tn_mcast_proxy_same_vlan_tx_drops, nested_tn_mcast_proxy_diff_vlan_tx_drops, mcast_poxy_tx_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Empfangene PNIC (MBit/s) |
Empfangene Megabit pro Sekunde. Diese Statistik wird intern der Statistik „rxmbps“ zugeordnet. |
4.2.0 |
| Empfangene PNIC (pps) |
Empfangene Pakete pro Sekunde. Diese Statistik wird intern der Statistik „rxpps“ zugeordnet. |
|
| Verworfene empfangene PNIC |
Empfangene Fehler pro Sekunde. Ein anderer Wert als null deutet in der Regel auf die folgenden beiden Fälle hin:
Diese Statistik wird intern der Statistik „rxeps“ zugeordnet. |
4.2.0 |
| Übertragene PNIC (MBit/s) |
Übertragene Megabit pro Sekunde. Diese Statistik wird intern der Statistik „txmbps“ zugeordnet. |
4.2.0 |
| Übertragene PNIC (pps) |
Übertragene Pakete pro Sekunde. Diese Statistik wird intern der Statistik „txpps“ zugeordnet. |
4.2.0 |
| Verloren gegangene übertragene PNIC |
Übertragene Fehler pro Sekunde. Diese Statistik wird intern der Statistik „txeps“ zugeordnet. |
4.2.0 |
| PNICs |
Anzahl physischer Netzwerkkarten. Diese Statistik wird intern der Statistik „num_pnics“ zugeordnet. |
4.2.0 |
| Paketverluste – Paketanalysefehler |
Anzahl der IPv6-ND-Pakete (Neighbor Discovery), die nicht ordnungsgemäß analysiert wurden. Überprüfen Sie die Protokolle auf Fehlermeldungen. Führen Sie Paketerfassungen am Port durch, um festzustellen, ob die Pakete falsch formatiert sind. Diese Statistik wird intern der Statistik „nd_parse_errors“ zugeordnet. |
4.2.0 |
| Nur Slow-Path |
Rate der Pakete, die standardmäßig immer in Slowpath verarbeitet werden. Ein Beispiel ist das Broadcast-Paket. Diese Statistik wird intern der Statistik „Slowpath“ zugeordnet. |
4.2.0 |
| Spoof Guard-Paketverluste |
Anzahl der von SpoofGuard verworfenen IPv4-/IPv6-/ARP-Pakete. SpoofGuard schützt vor IP-Spoofing, indem eine Referenztabelle mit VM-Namen/MAC- und IP-Adressen gepflegt wird. Dies steigt nur, wenn SpoofGuard auf dem Segment oder Segmentport aktiviert ist. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: spoof_guard_ipv4_drops, spoof_guard_arp_drops, spoof_guard_ipv6_drops, spoof_guard_nd_drops, spoof_guard_non_ip_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Switch-Sicherheit |
Gesamtzahl der Pakete, die aus verschiedenen Gründen vom Switch-Sicherheitsmodul verworfen wurden. Klicken Sie auf den Link NSX-Datenpfad auf der Benutzeroberfläche, um Details zu den Verwerfungen zu erhalten. |
4.2.0 |
| Unbekannter Tunnel-Endpoint |
Rate der verworfenen Pakete, für die die äußere Quell-MAC nicht erlernt werden kann, da die eingehende GENEVE-Bezeichnung unbekannt ist. Hohe Werte dieser Statistik können auf fehlende Remote-VTEP-Updates auf dem Transportknoten von der Steuerungsebene hinweisen. Verwenden Sie die CLI, um die Remote-VTEP-Tabelle auf dem Transportknoten zu überprüfen. Diese Statistik wird intern der Statistik „uplink_rx_skip_mac_learn“ zugeordnet. |
4.2.0 |
| Empfangene VNIC (MBit/s) |
Empfangene Megabit pro Sekunde. Diese Statistik wird intern der Statistik „rxmbps“ zugeordnet. |
4.2.0 |
| Empfangene VNIC (pps) |
Empfangene Pakete pro Sekunde. Diese Statistik wird intern der Statistik „rxpps“ zugeordnet. |
4.2.0 |
| Verworfene empfangene VNIC |
Empfangene Fehler pro Sekunde. Ein anderer Wert als null deutet in der Regel auf die folgenden beiden Fälle hin:
Diese Statistik wird intern der Statistik „rxeps“ zugeordnet. |
4.2.0 |
| Übertragene VNIC (MBit/s) |
Übertragene Megabit pro Sekunde. Diese Statistik wird intern der Statistik „txmbps“ zugeordnet. |
4.2.0 |
| Übertragene VNIC (pps) |
Übertragene Pakete pro Sekunde. Diese Statistik wird intern der Statistik „txpps“ zugeordnet. |
4.2.0 |
| Verloren gegangene übertragene VNIC |
Übertragene Fehler pro Sekunde. Ein anderer Wert als null deutet in der Regel auf Folgendes hin:
Diese Statistik wird intern der Statistik „txeps“ zugeordnet. |
4.2.0 |
| VNICs |
Anzahl virtueller Netzwerkkarten. Diese Statistik wird intern der Statistik „num_vnics“ zugeordnet. |
4.2.0 |
| Paketverluste – BPDU-Filter für Arbeitslasten |
Anzahl der Pakete, die durch BPDU-Filterung verworfen wurden. Wenn der BPDU-Filter aktiviert ist, wird der Datenverkehr zu konfigurierten BPDU-Ziel-MAC-Adressen verworfen. Diese Statistik wird intern der Statistik „bpdu_filter_drops“ zugeordnet. |
4.2.0 |
| Paketverluste – Arbeitslast-DHCP für nicht zulässig |
Anzahl der DHCPv4- oder DHCPv6-Pakete, die vom DHCP-Client/Serverblock verworfen wurden. Diese Statistik wird intern diesen detaillierten Statistiken zugeordnet: dhcp_client_block_ipv6_drops, dhcp_server_block_ipv6_drops, dhcp_client_block_ipv4_drops, dhcp_server_block_ipv4_drops, dhcp_client_validate_ipv4_drops. Weitere Einzelheiten finden Sie in den Definitionen der jeweiligen Statistik. |
4.2.0 |
| Paketverluste – IPv6-RA-Guard-Pakete für Arbeitslast |
Anzahl der von RA Guard verworfenen IPv6-Routerankündigungspakete. Die Funktion „RA Guard“ filtert von VMs übertragene IPv6-Routerankündigungen (ICMPv6-Typ 134) heraus. In einer IPv6-Bereitstellung senden Router in regelmäßigen Abständen Multicast-Meldungen zur Routerankündigung, die von Hosts für die automatische Konfiguration verwendet werden. Sie können RA Guard verwenden, um Ihr Netzwerk vor bösartigen RA-Nachrichten zu schützen, die von nicht autorisierten oder nicht ordnungsgemäß konfigurierten Routern generiert werden, die mit dem Netzwerksegment verbunden sind. Sie können RAGuard in der Benutzeroberfläche von NSX Manager unter konfigurieren. Diese Statistik wird intern der Statistik „ra_guard_drops“ zugeordnet. |
4.2.0 |
| vSwitch |
Gesamtzahl der Pakete, die aus verschiedenen Gründen vom vSwitch-Modul verworfen wurden. Klicken Sie auf den Link NSX-Datenpfad auf der Benutzeroberfläche, um Details zu den Verwerfungen zu erhalten. |
|
| vSwitch von Uplink empfangen |
Rate der Pakete, die von einem oder mehreren Uplinks zum vSwitch empfangen wurden, bei denen es sich um unbekannte Unicast-Pakete handelt, die vom vSwitch an andere Ports in derselben Broadcast-Domäne geflutet werden. Diese Statistik steigt, wenn Pakete unbekannte Unicast-Pakete sind, die bei Vorhandensein von MAC Learning-aktivierten Segmenten oder Sink-Ports geflutet werden. Ein unbekanntes Unicast-Flooding tritt auf, wenn sich die Ziel-MAC-Adresse des Pakets nicht in der Tabelle der vSwitch-MAC-Adressen befindet. Diese Statistik steigt, wenn eine Ziel-MAC bei Vorhandensein von MAC Learning aus der MAC-Adresstabelle abläuft. Diese Statistik wird intern der Statistik „unknown_unicast_rx_uplink_pkts“ zugeordnet. |
4.2.0 |
| vSwitch an Uplink übertragen |
Rate der Pakete mit unbekanntem Unicast, die vom vSwitch an einen oder mehrere Uplinks geflutet werden. Diese Statistik steigt, wenn Pakete unbekannte Unicast-Pakete sind, die bei Vorhandensein von MAC Learning-aktivierten Segmenten oder Sink-Ports geflutet werden. Ein unbekanntes Unicast-Flooding tritt auf, wenn sich die Ziel-MAC-Adresse des Pakets nicht in der Tabelle der vSwitch-MAC-Adressen befindet. Diese Statistik steigt, wenn eine Ziel-MAC bei Vorhandensein von MAC Learning aus der MAC-Adresstabelle abläuft. Diese Statistik wird intern der Statistik „unknown_unicast_tx_uplink_pkts“ zugeordnet. |
4.2.0 |
Modul: host_enhanced_fastpath
Dieses Datenpfadmodul gibt Host-/Infrastrukturstatistiken für das ENS-Datenpfadmodul an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-fastpath-ens bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| flow_table_occupancy_0_pct |
Histogramm: Anzahl der Flow-Tabellen mit 0–25 % Auslastung. |
4.2.0 |
| flow_table_occupancy_25_pct |
Histogramm: Anzahl der Flow-Tabellen mit 25–50 % Auslastung. |
4.2.0 |
| flow_table_occupancy_50_pct |
Histogramm: Anzahl der Flow-Tabellen mit 50–75 % Auslastung. |
4.2.0 |
| flow_table_occupancy_75_pct |
Histogramm: Anzahl der Flow-Tabellen mit 75–90 % Auslastung. |
4.2.0 |
| flow_table_occupancy_90_pct |
Histogramm: Anzahl der Flow-Tabellen mit 90–95 % Auslastung. Wenn die Anzahl der aktiven Flows größer als die Größe der Flow-Tabelle ist, kann es zu einem Anstieg der Flow-Fehler kommen, was zu einem Leistungsabfall führt. Die Statistiken im Histogramm der Flow-Tabellenbelegung sind nützlich, um festzustellen, ob die Flow-Tabellen voll werden. Das Erhöhen der Flow-Tabellengröße verbessert nicht immer die Leistung, wenn weiterhin kurzlebige Verbindungen eingehen. Die Flow-Tabelle kann unabhängig von der Größe der Flow-Tabelle immer voll sein. Eine große Flow-Tabellengröße wäre in diesem Fall nicht hilfreich. EDP verfügt über eine Logik, um dies zu erkennen und Flow-Tabellen automatisch zu aktivieren und zu deaktivieren, um einen solchen Fall zu behandeln. |
4.2.0 |
| flow_table_occupancy_95_pct |
Histogramm: Anzahl der Flow-Tabellen mit 95 % Auslastung. Wenn die Anzahl der aktiven Flows größer als die Größe der Flow-Tabelle ist, kann es zu einem Anstieg der Flow-Fehler kommen, was zu einem Leistungsabfall führt. Die Statistiken im Histogramm der Flow-Tabellenbelegung sind nützlich, um festzustellen, ob die Flow-Tabellen voll werden. Das Erhöhen der Flow-Tabellengröße verbessert nicht immer die Leistung, wenn weiterhin kurzlebige Verbindungen eingehen. Die Flow-Tabelle kann unabhängig von der Größe der Flow-Tabelle immer voll sein. Eine große Flow-Tabellengröße wäre in diesem Fall nicht hilfreich. EDP verfügt über eine Logik, um dies zu erkennen und Flow-Tabellen automatisch zu aktivieren und zu deaktivieren, um einen solchen Fall zu behandeln. |
4.2.0 |
| flow_table_size |
Maximale Größe der Flow-Tabelle in EDP. |
4.2.0 |
| hits |
Anzahl der Flow-Tabellentreffer im ENS-Modul. Diese Statistik kann verwendet werden, um die Treffer-/Fehler-/Slowpath-Rate des Flows zu berechnen oder um das Verhältnis von Treffern/Fehlern/Slowpath zu berechnen. |
4.2.0 |
| insertion_errors |
Anzahl der Fehler beim Einfügen in die Flow-Tabelle. Dies kann passieren, wenn eine Flow-Tabelle voll (oder fast voll) ist und Hash-Konflikte auftreten. |
4.2.0 |
| miss |
Pakete, die aufgrund eines Flow-Fehlers von Slowpath verarbeitet werden. Diese Statistik überschneidet sich nicht mit der Slowpath-Statistik, die weiter unten in dieser Tabelle beschrieben wird. Diese Statistik kann verwendet werden, um die Treffer-/Fehler-/Slowpath-Rate des Flows zu berechnen oder um das Verhältnis von Treffern/Fehlern/Slowpath zu berechnen. |
4.2.0 |
| num_flow_tables |
Anzahl der für EDP verwendeten Flow-Tabellen. EDP verfügt über eine Flow-Tabelle pro EDP-Thread. Dies ist nützlich, um zu sehen, wie viele Flow-Tabellen erstellt und verwendet werden. |
4.2.0 |
| num_flows |
Anzahl der Flows in EDP. |
4.2.0 |
| num_flows_created |
Anzahl der in EDP erstellten Flows. Verwenden Sie diese Statistik, um die Flow-Erstellungsrate zu berechnen, was nützlich ist, um die Merkmale der Arbeitslast zu bestimmen. Die Statistiken im Histogramm der Flow-Tabellenbelegung geben an, ob die Flow-Tabellen voll sind oder nicht. Wenn die Flow-Erstellungsrate niedrig ist und keine wesentlichen Änderungen in den Belegungsstatistiken „num_flows“ oder „flow ocupancy“ vorgenommen werden, deutet dies darauf hin, dass der Datenverkehr stabil und in einem stabilen Zustand ist. Die Anzahl der aktiven Flows bleibt stabil. Wenn die Flow-Erstellungsrate hoch ist und die Statistik „num_flows“ steigt, bedeutet dies, dass die Anzahl der aktiven Flows zunimmt. Flow-Tabellen werden schließlich voll, wenn die Flow-Erstellungsrate nicht sinkt. Wenn die Flow-Erstellungsrate hoch ist und die durchschnittliche Flow-Größe nicht klein ist, sollten Sie die Größe der Flow-Tabelle erhöhen. Durchschnittliche Flow-Größe = Trefferrate/num_flows_created-Rate. Ein kleiner Wert für die durchschnittliche Flow-Größe bedeutet, dass Flows kurzlebig sind. Sowohl Treffer als auch num_flows_created werden angesammelt. Sie können zuerst die Ratenwerte berechnen, um die durchschnittliche Flow-Größe während eines bestimmten Zeitraums abzurufen. |
4.2.0 |
| slowpath |
Pakete, die standardmäßig immer in Slowpath verarbeitet werden. Ein Beispiel ist das Broadcast-Paket. Diese Statistik kann verwendet werden, um die Treffer-/Fehler-/Slowpath-Rate des Flows zu berechnen oder um das Verhältnis von Treffern/Fehlern/Slowpath zu berechnen. |
4.2.0 |
Modul: host_fastpath_ens_lcore
Dieses Datenpfadmodul gibt die geschätzten Lcore-Nutzungsstatistiken für das ENS-Modul an. Es werden bis zu 16 nach Nutzung sortierte Lcores angezeigt. Wenn weniger als 16 Lcores konfiguriert sind, werden nur Lcores mit gültigen IDs angezeigt. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-fastpath-ens-lcore bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| lcorerank01_lcoreid |
Die ID des Kernel-Threads mit Rang 1 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank01_lcoreusage |
CPU-Nutzung des Lcore mit Rang 1. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank02_lcoreid |
Die ID des Kernel-Threads mit Rang 2 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank02_lcoreusage |
CPU-Nutzung des Lcore mit Rang 2. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank03_lcoreid |
Die ID des Kernel-Threads mit Rang 3 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank03_lcoreusage |
CPU-Nutzung des Lcore mit Rang 3. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank04_lcoreid |
Die ID des Kernel-Threads mit Rang 4 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank04_lcoreusage |
CPU-Nutzung des Lcore mit Rang 4. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank05_lcoreid |
Die ID des Kernel-Threads mit Rang 5 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank05_lcoreusage |
CPU-Nutzung des Lcore mit Rang 5. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank06_lcoreid |
Die ID des Kernel-Threads mit Rang 6 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank06_lcoreusage |
CPU-Nutzung des Lcore mit Rang 6. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank07_lcoreid |
Die ID des Kernel-Threads mit Rang 7 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank07_lcoreusage |
CPU-Nutzung des Lcore mit Rang 7. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank08_lcoreid |
Die ID des Kernel-Threads mit Rang 8 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank08_lcoreusage |
CPU-Nutzung des Lcore mit Rang 8. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank09_lcoreid |
Die ID des Kernel-Threads mit Rang 9 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank09_lcoreusage |
CPU-Nutzung des Lcore mit Rang 9. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank10_lcoreid |
Die ID des Kernel-Threads mit Rang 10 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank10_lcoreusage |
CPU-Nutzung des Lcore mit Rang 10. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank11_lcoreid |
Die ID des Kernel-Threads mit Rang 11 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank11_lcoreusage |
CPU-Nutzung des Lcore mit Rang 11. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank12_lcoreid |
Die ID des Kernel-Threads mit Rang 12 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank12_lcoreusage |
CPU-Nutzung des Lcore mit Rang 12. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank13_lcoreid |
Die ID des Kernel-Threads mit Rang 13 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
|
| lcorerank13_lcoreusage |
CPU-Nutzung des Lcore mit Rang 13. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank14_lcoreid |
Die ID des Kernel-Threads mit Rang 14 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank14_lcoreusage |
CPU-Nutzung des Lcore mit Rang 14. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank15_lcoreid |
Die ID des Kernel-Threads mit Rang 15 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank15_lcoreusage |
CPU-Nutzung des Lcore mit Rang 15. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank16_lcoreid |
Die ID des Kernel-Threads mit Rang 16 für den EDP-Leistungsmodus in Bezug auf die CPU-Nutzung. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
| lcorerank16_lcoreusage |
CPU-Nutzung des Lcore mit Rang 16. Wird nur angezeigt, wenn die ID gültig ist. |
4.2.0 |
Modul: host_standard_fastpath
Dieses Datenpfadmodul gibt Host-/Infrastrukturstatistiken für das Legacy-Flow-Cache-Datenpfadmodul an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-fastpath-standard bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| flow_table_occupancy_0_pct |
Histogramm: Anzahl der Flow-Tabellen mit 0–25 % Auslastung. |
4.2.0 |
| flow_table_occupancy_25_pct |
Histogramm: Anzahl der Flow-Tabellen mit 25–50 % Auslastung. |
4.2.0 |
| flow_table_occupancy_50_pct |
Histogramm: Anzahl der Flow-Tabellen mit 50–75 % Auslastung. |
4.2.0 |
| flow_table_occupancy_75_pct |
Histogramm: Anzahl der Flow-Tabellen mit 75–90 % Auslastung. |
4.2.0 |
| flow_table_occupancy_90_pct |
Histogramm: Anzahl der Flow-Tabellen mit 90–95 % Auslastung. Wenn die Anzahl der aktiven Flows größer als die Größe der Flow-Tabelle ist, kann es zu einem Anstieg der Flow-Fehler kommen, was zu einem Leistungsabfall führt. Die Statistiken im Histogramm der Flow-Tabellenbelegung sind nützlich, um festzustellen, ob die Flow-Tabellen voll werden. Das Erhöhen der Flow-Tabellengröße verbessert nicht immer die Leistung, wenn weiterhin kurzlebige Verbindungen eingehen. Die Flow-Tabelle kann unabhängig von der Größe der Flow-Tabelle immer voll sein. Eine große Flow-Tabellengröße wäre in diesem Fall nicht hilfreich. EDP verfügt über eine Logik, um dies zu erkennen und Flow-Tabellen automatisch zu aktivieren und zu deaktivieren, um einen solchen Fall zu behandeln. |
4.2.0 |
| flow_table_occupancy_95_pct |
Histogramm: Anzahl der Flow-Tabellen mit 95 % Auslastung. Wenn die Anzahl der aktiven Flows größer als die Größe der Flow-Tabelle ist, kann es zu einem Anstieg der Flow-Fehler kommen, was zu einem Leistungsabfall führt. Die Statistiken im Histogramm der Flow-Tabellenbelegung sind nützlich, um festzustellen, ob die Flow-Tabellen voll werden. Das Erhöhen der Flow-Tabellengröße verbessert nicht immer die Leistung, wenn weiterhin kurzlebige Verbindungen eingehen. Die Flow-Tabelle kann unabhängig von der Größe der Flow-Tabelle immer voll sein. Eine große Flow-Tabellengröße wäre in diesem Fall nicht hilfreich. EDP verfügt über eine Logik, um dies zu erkennen und Flow-Tabellen automatisch zu aktivieren und zu deaktivieren, um einen solchen Fall zu behandeln. |
4.2.0 |
| flow_table_size |
Maximale Größe der Flow-Tabelle in EDP. |
4.2.0 |
| hits |
Anzahl der Flow-Tabellentreffer im ENS-Modul. Diese Statistik kann verwendet werden, um die Treffer-/Fehler-/Slowpath-Rate des Flows zu berechnen oder um das Verhältnis von Treffern/Fehlern/Slowpath zu berechnen. |
4.2.0 |
| insertion_errors |
Anzahl der Fehler beim Einfügen in die Flow-Tabelle. Dies kann passieren, wenn eine Flow-Tabelle voll (oder fast voll) ist und Hash-Konflikte auftreten. |
4.2.0 |
| miss |
Pakete, die aufgrund eines Flow-Fehlers von Slowpath verarbeitet werden. Diese Statistik überschneidet sich nicht mit der Slowpath-Statistik, die weiter unten in dieser Tabelle beschrieben wird. Diese Statistik kann verwendet werden, um die Treffer-/Fehler-/Slowpath-Rate des Flows zu berechnen oder um das Verhältnis von Treffern/Fehlern/Slowpath zu berechnen. |
4.2.0 |
| num_flow_tables |
Anzahl der für EDP verwendeten Flow-Tabellen. EDP verfügt über eine Flow-Tabelle pro EDP-Thread. Dies ist nützlich, um zu sehen, wie viele Flow-Tabellen erstellt und verwendet werden. |
4.2.0 |
| num_flows |
Anzahl der Flows in EDP. |
4.2.0 |
| num_flows_created |
Anzahl der in EDP erstellten Flows. Verwenden Sie diese Statistik, um die Flow-Erstellungsrate zu berechnen, was nützlich ist, um die Merkmale der Arbeitslast zu bestimmen. Die Statistiken im Histogramm der Flow-Tabellenbelegung geben an, ob die Flow-Tabellen voll sind oder nicht. Wenn die Flow-Erstellungsrate niedrig ist und keine wesentlichen Änderungen in den Belegungsstatistiken „num_flows“ oder „flow ocupancy“ vorgenommen werden, deutet dies darauf hin, dass der Datenverkehr stabil und in einem stabilen Zustand ist. Die Anzahl der aktiven Flows bleibt stabil. Wenn die Flow-Erstellungsrate hoch ist und die Statistik „num_flows“ steigt, bedeutet dies, dass die Anzahl der aktiven Flows zunimmt. Flow-Tabellen werden schließlich voll, wenn die Flow-Erstellungsrate nicht sinkt. Wenn die Flow-Erstellungsrate hoch ist und die durchschnittliche Flow-Größe nicht klein ist, sollten Sie die Größe der Flow-Tabelle erhöhen. Durchschnittliche Flow-Größe = Trefferrate/num_flows_created-Rate. Ein kleiner Wert für die durchschnittliche Flow-Größe bedeutet, dass Flows kurzlebig sind. Sowohl Treffer als auch num_flows_created werden angesammelt. Sie können zuerst die Ratenwerte berechnen, um die durchschnittliche Flow-Größe während eines bestimmten Zeitraums abzurufen. |
4.2.0 |
| slowpath |
Pakete, die standardmäßig immer in Slowpath verarbeitet werden. Ein Beispiel ist das Broadcast-Paket. Diese Statistik kann verwendet werden, um die Treffer-/Fehler-/Slowpath-Rate des Flows zu berechnen oder um das Verhältnis von Treffern/Fehlern/Slowpath zu berechnen. |
4.2.0 |
Modul: host_net_thread_nioc
Dieses Datenpfadmodul gibt Netzwerk-Thread-Statistiken im Zusammenhang mit NIOC an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-net-thread-nioc bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| hist_0_pct |
Histogramm: Anzahl der Threads zwischen 0 %–25% |
4.2.0 |
| hist_25_pct |
Histogramm: Anzahl der Threads zwischen 25%–50% |
4.2.0 |
| hist_50_pct |
Histogramm: Anzahl der Threads zwischen 50%–70% |
4.2.0 |
| hist_70_pct |
Histogramm: Anzahl der Threads zwischen 70%–80% |
4.2.0 |
| hist_80_pct |
Histogramm: Anzahl der Threads zwischen 80%–85% |
4.2.0 |
| hist_85_pct |
Histogramm: Anzahl der Threads zwischen 85%–90% |
4.2.0 |
| hist_90_pct |
Histogramm: Anzahl der Threads zwischen 90%–95% |
4.2.0 |
| hist_95_pct |
Histogramm: Anzahl der Threads zwischen 95%–97% |
4.2.0 |
| hist_97_pct |
Histogramm: Anzahl der Threads zwischen 97%–99% |
4.2.0 |
| hist_99_pct |
Histogramm: Anzahl der Threads mit >99 % Auslastung. Netzwerkdatenpfadprobleme zeigen sich an drei Symptomen: Paketverlusten, niedrigem Durchsatz und hoher Latenz. Obwohl diese Symptome sowohl durch funktionale wie auch durch Leistungsprobleme ausgelöst werden, werden sie in den meisten Fällen durch leistungsbezogene Probleme verursacht. Es ist wichtig, dass in einem frühen Stadium der Untersuchung bestimmt wird, ob das Problem leistungsbezogen ist oder nicht. In einem softwaredefinierten Netzwerk, das speziell auf Virtualisierung basiert, ist die CPU die wichtigste Ressource für die Netzwerkleistung. Da auf dem Markt immer schnellere Netzwerkkarten verfügbar sind, wird die Netzwerkbandbreite selten zu einem Engpass. Die Paketverarbeitung im Datenpfad umfasst in der Regel einen Satz von Threads, die in einer Pipeline ausgeführt werden und Warteschlangen und Puffern zugeordnet sind, die Pakete enthalten. Wenn ein Thread in der Pipeline von vCPUs zu Kernel-Netzwerk-Threads überladen wird, können die entsprechenden Warteschlangen und Puffer voll werden, was zu Paketverlusten führt. Dies drosselt den Durchsatz. Zusätzlich zu den herkömmlichen Netzwerkstatistiken ist es wichtig, die CPU-Nutzung von Kernel-Netzwerkthreads zu überwachen. Anstatt CPU-Nutzungszahlen für einzelne Threads zu verwenden, werden sie gruppiert und ein Histogramm wird generiert. Anschließend können Sie die Histogramm-Bins wie 90pct, 95pct, 97pct und 99pct überwachen und so erfahren, bei wie vielen Netzwerkthreads es zu Engpässen kommt. Die Statistik „total_CPU“ ist auch nützlich, um anzuzeigen, wie viel CPU-Zeit mit der Verarbeitung von Paketen im Kernel verbracht wird. |
4.2.0 |
| max_cpu |
Maximale CPU-Thread-Nutzung |
4.2.0 |
| min_cpu |
Minimale CPU-Thread-Nutzung |
4.2.0 |
| num_threads |
Anzahl der Threads, die für die Bereitstellung von Paketen vom NetIOC-Paket-Scheduler zum Uplink verwendet werden. |
4.2.0 |
| total_cpu |
Summe der CPU-Nutzung aller Netzwerk-Threads in der Gruppe. Die Gesamtnutzung der CPUs ist nützlich, um die Verteilung der gesamten CPU-Auslastung zwischen verschiedenen Thread-Gruppen und VMs anzuzeigen. |
4.2.0 |
Modul: host_net_thread_rx
Dieses Datenpfadmodul gibt Netzwerk-Thread-Statistiken im Zusammenhang mit RX an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-net-thread-rx bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| hist_0_pct |
Histogramm: Anzahl der Threads zwischen 0 %–25% |
4.2.0 |
| hist_25_pct |
Histogramm: Anzahl der Threads zwischen 25%–50% |
4.2.0 |
| hist_50_pct |
Histogramm: Anzahl der Threads zwischen 50%–70% |
4.2.0 |
| hist_70_pct |
Histogramm: Anzahl der Threads zwischen 70%–80% |
4.2.0 |
| hist_80_pct |
Histogramm: Anzahl der Threads zwischen 80%–85% |
4.2.0 |
| hist_85_pct |
Histogramm: Anzahl der Threads zwischen 85%–90% |
4.2.0 |
| hist_90_pct |
Histogramm: Anzahl der Threads zwischen 90%–95% |
4.2.0 |
| hist_95_pct |
Histogramm: Anzahl der Threads zwischen 95%–97% |
4.2.0 |
| hist_97_pct |
Histogramm: Anzahl der Threads zwischen 97%–99% |
4.2.0 |
| hist_99_pct |
Histogramm: Anzahl der Threads mit >99 % Auslastung. Netzwerkdatenpfadprobleme zeigen sich an drei Symptomen: Paketverlusten, niedrigem Durchsatz und hoher Latenz. Obwohl diese Symptome sowohl durch funktionale wie auch durch Leistungsprobleme ausgelöst werden, werden sie in den meisten Fällen durch leistungsbezogene Probleme verursacht. Es ist wichtig, dass in einem frühen Stadium der Untersuchung bestimmt wird, ob das Problem leistungsbezogen ist oder nicht. In einem softwaredefinierten Netzwerk, das speziell auf Virtualisierung basiert, ist die CPU die wichtigste Ressource für die Netzwerkleistung. Da auf dem Markt immer schnellere Netzwerkkarten verfügbar sind, wird die Netzwerkbandbreite selten zu einem Engpass. Die Paketverarbeitung im Datenpfad umfasst in der Regel einen Satz von Threads, die in einer Pipeline ausgeführt werden und Warteschlangen und Puffern zugeordnet sind, die Pakete enthalten. Wenn ein Thread in der Pipeline von vCPUs zu Kernel-Netzwerk-Threads überladen wird, können die entsprechenden Warteschlangen und Puffer voll werden, was zu Paketverlusten führt. Dies drosselt den Durchsatz. Zusätzlich zu den herkömmlichen Netzwerkstatistiken ist es wichtig, die CPU-Nutzung von Kernel-Netzwerkthreads zu überwachen. Anstatt CPU-Nutzungszahlen für einzelne Threads zu verwenden, werden sie gruppiert und ein Histogramm wird generiert. Anschließend können Sie die Histogramm-Bins wie 90pct, 95pct, 97pct und 99pct überwachen und so erfahren, bei wie vielen Netzwerkthreads es zu Engpässen kommt. Die Statistik „total_CPU“ ist auch nützlich, um anzuzeigen, wie viel CPU-Zeit mit der Verarbeitung von Paketen im Kernel verbracht wird. |
4.2.0 |
| max_cpu |
Maximale CPU-Thread-Nutzung |
4.2.0 |
| min_cpu |
Minimale CPU-Thread-Nutzung |
4.2.0 |
| num_threads |
Anzahl der Threads, die für die Bereitstellung von Paketen vom NetIOC-Paket-Scheduler zum Uplink verwendet werden. |
4.2.0 |
| total_cpu |
Summe der CPU-Nutzung aller Netzwerk-Threads in der Gruppe. Die Gesamtnutzung der CPUs ist nützlich, um die Verteilung der gesamten CPU-Auslastung zwischen verschiedenen Thread-Gruppen und VMs anzuzeigen. |
4.2.0 |
Modul: host_net_thread_tx
Dieses Datenpfadmodul gibt Netzwerk-Thread-Statistiken im Zusammenhang mit TX an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-net-thread-tx„host-net-thread-tx“ bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| hist_0_pct |
Histogramm: Anzahl der Threads zwischen 0 %–25% |
4.2.0 |
| hist_25_pct |
Histogramm: Anzahl der Threads zwischen 25%–50% |
4.2.0 |
| hist_50_pct |
Histogramm: Anzahl der Threads zwischen 50%–70% |
4.2.0 |
| hist_70_pct |
Histogramm: Anzahl der Threads zwischen 70%–80% |
4.2.0 |
| hist_80_pct |
Histogramm: Anzahl der Threads zwischen 80%–85% |
4.2.0 |
| hist_85_pct |
Histogramm: Anzahl der Threads zwischen 85%–90% |
4.2.0 |
| hist_90_pct |
Histogramm: Anzahl der Threads zwischen 90%–95% |
4.2.0 |
| hist_95_pct |
Histogramm: Anzahl der Threads zwischen 95%–97% |
4.2.0 |
| hist_97_pct |
Histogramm: Anzahl der Threads zwischen 97%–99% |
4.2.0 |
| hist_99_pct |
Histogramm: Anzahl der Threads mit >99 % Auslastung. Netzwerkdatenpfadprobleme zeigen sich an drei Symptomen: Paketverlusten, niedrigem Durchsatz und hoher Latenz. Obwohl diese Symptome sowohl durch funktionale wie auch durch Leistungsprobleme ausgelöst werden, werden sie in den meisten Fällen durch leistungsbezogene Probleme verursacht. Es ist wichtig, dass in einem frühen Stadium der Untersuchung bestimmt wird, ob das Problem leistungsbezogen ist oder nicht. In einem softwaredefinierten Netzwerk, das speziell auf Virtualisierung basiert, ist die CPU die wichtigste Ressource für die Netzwerkleistung. Da auf dem Markt immer schnellere Netzwerkkarten verfügbar sind, wird die Netzwerkbandbreite selten zu einem Engpass. Die Paketverarbeitung im Datenpfad umfasst in der Regel einen Satz von Threads, die in einer Pipeline ausgeführt werden und Warteschlangen und Puffern zugeordnet sind, die Pakete enthalten. Wenn ein Thread in der Pipeline von vCPUs zu Kernel-Netzwerk-Threads überladen wird, können die entsprechenden Warteschlangen und Puffer voll werden, was zu Paketverlusten führt. Dies drosselt den Durchsatz. Zusätzlich zu den herkömmlichen Netzwerkstatistiken ist es wichtig, die CPU-Nutzung von Kernel-Netzwerkthreads zu überwachen. Anstatt CPU-Nutzungszahlen für einzelne Threads zu verwenden, werden sie gruppiert und ein Histogramm wird generiert. Anschließend können Sie die Histogramm-Bins wie 90pct, 95pct, 97pct und 99pct überwachen und so erfahren, bei wie vielen Netzwerkthreads es zu Engpässen kommt. Die Statistik „total_CPU“ ist auch nützlich, um anzuzeigen, wie viel CPU-Zeit mit der Verarbeitung von Paketen im Kernel verbracht wird. |
4.2.0 |
| max_cpu |
Maximale CPU-Thread-Nutzung |
4.2.0 |
| min_cpu |
Minimale CPU-Thread-Nutzung |
4.2.0 |
| num_threads |
Anzahl der Threads, die für die Bereitstellung von Paketen vom NetIOC-Paket-Scheduler zum Uplink verwendet werden. |
4.2.0 |
| total_cpu |
Summe der CPU-Nutzung aller Netzwerk-Threads in der Gruppe. Die Gesamtnutzung der CPUs ist nützlich, um die Verteilung der gesamten CPU-Auslastung zwischen verschiedenen Thread-Gruppen und VMs anzuzeigen. |
4.2.0 |
Modul: host_pcpu
Dieses Datenpfadmodul gibt die Nutzung physischer CPUs an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-pcpu„host-pcpu“ bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| hist_0_pct |
Histogramm: Anzahl der CPUs zwischen 0 %–50 % |
4.2.0 |
| hist_50_pct |
Histogramm: Anzahl der CPUs zwischen 50%–70% |
4.2.0 |
| hist_75_pct |
Histogramm: Anzahl der CPUs zwischen 75%–85% |
4.2.0 |
| hist_85_pct |
Histogramm: Anzahl der CPUs zwischen 85%–90% |
4.2.0 |
| hist_90_pct |
Histogramm: Anzahl der CPUs zwischen 90%–95% |
4.2.0 |
| hist_95_pct |
Histogramm: Anzahl der CPUs zwischen 95%–100% |
4.2.0 |
| total_cpu |
Gesamte Host-CPU-Nutzung. Summe der Nutzung aller physischen CPU-Kerne auf dem Host. Netzwerkdatenpfadprobleme zeigen sich an drei Symptomen: Paketverlusten, niedrigem Durchsatz und hoher Latenz. Obwohl diese Symptome sowohl durch funktionale wie auch durch Leistungsprobleme ausgelöst werden, werden sie in den meisten Fällen durch leistungsbezogene Probleme verursacht. Es ist wichtig, dass in einem frühen Stadium der Untersuchung bestimmt wird, ob das Problem leistungsbezogen ist oder nicht. In einem softwaredefinierten Netzwerk, das speziell auf Virtualisierung basiert, ist die CPU die wichtigste Ressource für die Netzwerkleistung. Da auf dem Markt immer schnellere Netzwerkkarten verfügbar sind, wird die Netzwerkbandbreite selten zu einem Engpass. Die Paketverarbeitung im Datenpfad umfasst in der Regel einen Satz von Threads, die in einer Pipeline ausgeführt werden und Warteschlangen und Puffern zugeordnet sind, die Pakete enthalten. Wenn ein Thread in der Pipeline von vCPUs zu Kernel-Netzwerk-Threads überladen wird, können die entsprechenden Warteschlangen und Puffer voll werden, was zu Paketverlusten führt. Dies drosselt den Durchsatz. Zusätzlich zu den herkömmlichen Netzwerkstatistiken ist es wichtig, die CPU-Nutzung von Kernel-Netzwerkthreads zu überwachen. Anstatt CPU-Nutzungszahlen für einzelne Threads zu verwenden, werden sie gruppiert und ein Histogramm wird generiert. Anschließend können Sie die Histogramm-Bins wie 90pct, 95pct, 97pct und 99pct überwachen und so erfahren, bei wie vielen Netzwerkthreads es zu Engpässen kommt. Die Statistik „total_CPU“ ist auch nützlich, um anzuzeigen, wie viel CPU-Zeit mit der Verarbeitung von Paketen im Kernel verbracht wird. |
4.2.0 |
Modul: host_uplink
Dieses Datenpfadmodul gibt die Verwendung physischer Uplink-Netzwerkkarten an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-uplink bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| num_pnics |
Anzahl physischer Netzwerkkarten |
4.2.0 |
| rx_error_total |
Treiberstatistik: Empfangene Fehler insgesamt. Normalerweise sollte diese Statistik einen ähnlichen Wert wie „rx_missed“ aufweisen.
Ein anderer Wert als null deutet in der Regel auf zwei Fälle hin:
|
4.2.0 |
| rx_missed |
Treiberstatistik: Empfangen ausgelassen. Normalerweise sollte diese Statistik einen ähnlichen Wert wie „rx_error_total“ aufweisen.
Ein anderer Wert als null deutet in der Regel auf zwei Fälle hin:
|
4.2.0 |
| rxeps |
Empfangene Fehler pro Sekunde
Ein anderer Wert als null deutet in der Regel auf zwei Fälle hin:
|
4.2.0 |
| rxmbps |
Empfangene Megabit pro Sekunde |
4.2.0 |
| rxpps |
Empfangene Pakete pro Sekunde |
4.2.0 |
| txeps |
Übertragene Fehler pro Sekunde |
4.2.0 |
| txmbps |
Übertragene Megabit pro Sekunde |
4.2.0 |
| txpps |
Übertragene Pakete pro Sekunde |
4.2.0 |
Modul: host_vnic
Dieses Datenpfadmodul gibt die Nutzung virtueller Netzwerkkarten an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-vNIC bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| num_vnics |
Anzahl virtueller Netzwerkkarten. |
4.2.0 |
| rxeps |
Empfangene Fehler pro Sekunde
Ein anderer Wert als null deutet in der Regel auf die folgenden beiden Fälle hin:
|
4.2.0 |
| rxmbps |
Empfangene Megabit pro Sekunde. |
4.2.0 |
| rxpps |
Empfangene Pakete pro Sekunde |
4.2.0 |
| txeps |
Übertragene Fehler pro Sekunde
Ein anderer Wert als null deutet in der Regel auf die folgenden beiden Fälle hin:
|
4.2.0 |
| txmbps |
Übertragene Megabit pro Sekunde. |
4.2.0 |
| txpps |
Übertragene Pakete pro Sekunde |
4.2.0 |
Modul: host_vcpu
Dieses Datenpfadmodul gibt die Nutzung virtueller CPUs an. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als host-vcpu bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| hist_0_pct |
Histogramm: Anzahl der CPUs zwischen 0 %–50 %. |
4.2.0 |
| hist_50_pct |
Histogramm: Anzahl der CPUs zwischen 50%–70%. |
4.2.0 |
| hist_75_pct |
Histogramm: Anzahl der CPUs zwischen 75%–85% |
4.2.0 |
| hist_85_pct |
Histogramm: Anzahl der CPUs zwischen 85%–90%. |
4.2.0 |
| hist_90_pct |
Histogramm: Anzahl der CPUs zwischen 90%–95%. |
4.2.0 |
| hist_95_pct |
Histogramm: Anzahl der CPUs zwischen 95%–100%. Netzwerkdatenpfadprobleme zeigen sich an drei Symptomen: Paketverlusten, niedrigem Durchsatz und hoher Latenz. Obwohl diese Symptome sowohl durch funktionale wie auch durch Leistungsprobleme ausgelöst werden, werden sie in den meisten Fällen durch leistungsbezogene Probleme verursacht. Es ist wichtig, dass in einem frühen Stadium der Untersuchung bestimmt wird, ob das Problem leistungsbezogen ist oder nicht. In einem softwaredefinierten Netzwerk, das speziell auf Virtualisierung basiert, ist die CPU die wichtigste Ressource für die Netzwerkleistung. Da auf dem Markt immer schnellere Netzwerkkarten verfügbar sind, wird die Netzwerkbandbreite selten zu einem Engpass. Die Paketverarbeitung im Datenpfad umfasst in der Regel einen Satz von Threads, die in einer Pipeline ausgeführt werden und Warteschlangen und Puffern zugeordnet sind, die Pakete enthalten. Wenn ein Thread in der Pipeline von vCPUs zu Kernel-Netzwerk-Threads überladen wird, können die entsprechenden Warteschlangen und Puffer voll werden, was zu Paketverlusten führt. Dies drosselt den Durchsatz. Zusätzlich zu den herkömmlichen Netzwerkstatistiken ist es wichtig, die CPU-Nutzung von Kernel-Netzwerkthreads zu überwachen. Anstatt CPU-Nutzungszahlen für einzelne Threads zu verwenden, werden sie gruppiert und ein Histogramm wird generiert. Anschließend können Sie die Histogramm-Bins überwachen und so erfahren, bei wie vielen Netzwerkthreads es zu Engpässen kommt. Die Statistik „total_CPU“ ist auch nützlich, um anzuzeigen, wie viel CPU-Zeit mit der Verarbeitung von Paketen im Kernel verbracht wird. |
4.2.0 |
| total_cpu |
Gesamtnutzung der vCPUs. Summe der CPU Nutzung aller VMs auf dem Host. Die Gesamtnutzung der CPUs ist nützlich, um die Verteilung der gesamten CPU-Auslastung zwischen verschiedenen Thread-Gruppen und VMs anzuzeigen. |
4.2.0 |
Modul: fastpath
Fastpath enthält Datenpfadmodule für Flow-Cache (FC) und den erweiterten Netzwerk-Stack (ENS) für eine verbesserte Datenpfad-Paketverarbeitung. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als nsxt-fp bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| rx_bytes |
Die Anzahl der empfangenen Byte durch Flow-Cache-Fastpath in Empfangsrichtung von Ports. |
4.2.0 |
| rx_drops |
Die Anzahl der durch Flow-Cache-Fastpath in Empfangsrichtung von Ports verworfenen Pakete. Dies gilt nicht für Flow-Cache im Nicht-ENS-Modus. |
4.2.0 |
| rx_drops_sp |
Verworfene empfangene Pakete, wenn Pakete vom Flow-Cache-Fastpath an den Slowpath gesendet werden. Nicht anwendbar für Flow-Cache im Nicht-ENS-Modus und im Standard-Switch-Modus. |
4.2.0 |
| rx_drops_uplink |
Die Anzahl der durch Flow-Cache-Fastpath in Empfangsrichtung von Uplink-Ports verworfenen Pakete. Nicht anwendbar für Flow-Cache im Nicht-ENS-Modus und im Standard-Switch-Modus. |
4.2.0 |
| rx_pkts |
Die Anzahl der durch Flow-Cache-Fastpath in Empfangsrichtung von Ports empfangenen Pakete. |
4.2.0 |
| rx_pkts_sp |
Empfangene Pakete, wenn Pakete vom Flow-Cache-Fastpath an den Slowpath gesendet werden. Nicht anwendbar für Flow-Cache im Nicht-ENS-Modus und im Standard-Switch-Modus. |
4.2.0 |
| rx_pkts_uplink |
Die Anzahl der durch Flow-Cache-Fastpath in Empfangsrichtung von Uplink-Ports empfangenen Pakete. |
4.2.0 |
| tx_bytes |
Die Anzahl der durch Flow-Cache-Fastpath übertragenen Byte in Übertragungsrichtung zu Ports. |
4.2.0 |
| tx_drops |
Die Anzahl der durch Flow-Cache-Fastpath in Übertragungsrichtung zu Ports verworfenen Pakete. |
4.2.0 |
| tx_drops_sp |
Durch Fastpath übertragene verworfene Pakete, wenn Pakete von Slowpath wieder in den Flow-Cache-Fastpath eingefügt werden. Nicht anwendbar für Flow-Cache im Nicht-ENS-Modus und im Standard-Switch-Modus. |
4.2.0 |
| tx_drops_uplink |
Die Anzahl der durch Flow-Cache-Fastpath in Übertragungsrichtung zu Uplink-Ports verworfenen Pakete. |
4.2.0 |
| tx_pkts |
Die Anzahl der durch Flow-Cache-Fastpath in Übertragungsrichtung zu Ports übertragenen Pakete. |
4.2.0 |
| tx_pkts_sp |
Von Fastpath übertragene Pakete, wenn Pakete von Slowpath wieder in den Flow-Cache-Fastpath eingefügt werden. Nicht anwendbar für den Standard-Switch-Modus. |
4.2.0 |
| tx_pkts_uplink |
Die Anzahl der durch Flow-Cache-Fastpath in Übertragungsrichtung von Uplink-Ports übertragenen Pakete. |
4.2.0 |
Modul: switch_security
Dieses Datenpfadmodul bietet statusfreie L2- und L3-Sicherheit, indem der Datenverkehr zum Segment überprüft und von VMs gesendete nicht autorisierte Pakete verworfen werden. In dieser Tabelle bezeichnet „Rx“ Pakete, die „vom Switch“ empfangen wurden, und „Rx“ bezeichnet Pakete, die „an den Switch“ gesendet wurden. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als nsxt-swsec bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| bpdu_filter_drops |
Anzahl der Pakete, die durch BPDU-Filterung verworfen wurden. Wenn der BPDU-Filter aktiviert ist, wird der Datenverkehr zu konfigurierten BPDU-Ziel-MAC-Adressen verworfen. |
4.2.0 |
| dhcp_client_block_ipv4_drops |
Anzahl der von der DHCP-Clientblockierung verworfenen IPv4-DHCP-Pakete. Die DHCP-Clientblockierung verhindert, dass eine VM eine DHCP-IP-Adresse erhält, indem DHCP-Anforderungen blockiert werden. Wenn dies nicht erwartet wird, können Sie die DHCPv4-Clientblockierung im Segmentsicherheitsprofil eines Segments oder eines Segmentports deaktivieren. Navigieren Sie dazu in NSX Manager zu . |
4.2.0 |
| dhcp_client_block_ipv6_drops |
Anzahl der von der DHCP-Clientblockierung verworfenen IPv6-DHCP-Pakete. Die DHCP-Clientblockierung verhindert, dass eine VM eine DHCP-IP-Adresse erhält, indem DHCP-Anforderungen blockiert werden. Wenn dies nicht erwartet wird, können Sie die DHCPv6-Clientblockierung im Segmentsicherheitsprofil eines Segments oder eines Segmentports deaktivieren. Navigieren Sie dazu in NSX Manager zu . |
4.2.0 |
| dhcp_client_validate_ipv4_drops |
Anzahl der aufgrund ungültiger Adressen in der Nutzlast verworfenen IPv4-DHCP-Pakete. Eine böswillige VM im Netzwerk kann versuchen, ungültige DHCP-Pakete zu senden, z. B. ohne Quell-IP, mit nicht mit der Quell-MAC übereinstimmender Client-Hardwareadresse usw. |
4.2.0 |
| dhcp_server_block_ipv4_drops |
Anzahl der von der DHCP-Serverblockierung verworfenen IPv4-DHCP-Pakete. Die DHCP-Serverblockierung blockiert Datenverkehr von einem DHCP-Server an einen DHCP-Client. Wenn dies nicht erwartet wird, können Sie die DHCP-Serverblockierung im Segmentsicherheitsprofil eines Segments oder eines Segmentports deaktivieren. Navigieren Sie dazu in NSX Manager zu . |
4.2.0 |
| dhcp_server_block_ipv6_drops |
Anzahl der vom DHCP-Serverblock verworfenen DHCPv6-Pakete. Die DHCP-Serverblockierung blockiert Datenverkehr von einem DHCP-Server an einen DHCP-Client. Wenn dies nicht erwartet wird, können Sie die DHCPv6-Serverblockierung über das Segmentsicherheitsprofil eines Segments oder eines Segmentports deaktivieren. Navigieren Sie dazu in NSX Manager zu . |
4.2.0 |
| nd_parse_errors |
Anzahl der IPv6-ND-Pakete (Neighbor Discovery), die nicht ordnungsgemäß analysiert wurden. Überprüfen Sie die Protokolle auf Fehlermeldungen. Führen Sie Paketerfassungen am Port durch, um festzustellen, ob die Pakete falsch formatiert sind. |
4.2.0 |
| ra_guard_drops |
Anzahl der von RA Guard verworfenen IPv6-Routerankündigungspakete. Die Funktion „RA Guard“ filtert von VMs übertragene IPv6-Routerankündigungen (ICMPv6-Typ 134) heraus. In einer IPv6-Bereitstellung senden Router in regelmäßigen Abständen Multicast-Meldungen zur Routerankündigung, die von Hosts für die automatische Konfiguration verwendet werden. Sie können RA Guard verwenden, um Ihr Netzwerk vor bösartigen RA-Nachrichten zu schützen, die von nicht autorisierten oder nicht ordnungsgemäß konfigurierten Routern generiert werden, die mit dem Netzwerksegment verbunden sind. Sie können RAGuard in der Benutzeroberfläche von NSX Manager unter konfigurieren. |
4.2.0 |
| rx_arp_pkts |
Anzahl der vom VDS von der VM empfangenen ARP-Pakete. |
4.2.0 |
| rx_garp_pkts |
Anzahl der vom VDS von der VM empfangenen GARP-Pakete (Gratuitous ARP). |
4.2.0 |
| rx_ipv4_pkts |
Anzahl der vom VDS von der VM empfangenen IPv4-Pakete. |
4.2.0 |
| rx_ipv6_pkts |
Anzahl der vom VDS von der VM empfangenen IPv6-Pakete. |
4.2.0 |
| rx_na_pkts |
Anzahl der vom VDS von der VM empfangenen IPv6-ND-NA-Pakete (Neighbor Discovery, Neighbor Advertisement). |
4.2.0 |
| rx_non_ip_pkts |
Anzahl der vom VDS von der VM empfangenen Nicht-IP-Pakete. |
4.2.0 |
| rx_ns_pkts |
Anzahl der vom VDS von der VM empfangenen IPv6-ND-NS-Pakete (Neighbor Discovery, Neighbor Solicitation). |
4.2.0 |
| rx_rate_limit_bcast_drops |
Anzahl der eingehenden Pakete, die durch die Begrenzung der Broadcast-Rate verworfen wurden. Ratenbegrenzungen können verwendet werden, um das Netzwerk oder VMs vor Ereignissen wie Broadcast-Stürmen zu schützen. Sie können Ratenbegrenzungen in der Benutzeroberfläche von NSX Manager unter konfigurieren. |
4.2.0 |
| rx_rate_limit_mcast_drops |
Anzahl der eingehenden Pakete, die durch die Begrenzung der Multicast-Rate verworfen wurden. Ratenbegrenzungen können verwendet werden, um das Netzwerk oder VMs vor Ereignissen wie Multicast-Stürmen zu schützen. Sie können Ratenbegrenzungen in der Benutzeroberfläche von NSX Manager unter konfigurieren. |
4.2.0 |
| rx_unsolicited_na_pkts |
Anzahl der vom VDS von der VM empfangenen, nicht angeforderten IPv6-ND-NA-Pakete (Neighbor Discovery, Neighbor Advertisement). |
4.2.0 |
| rxbcastpkts |
Anzahl der vom VDS von der VM empfangenen Broadcast-Pakete. |
4.2.0 |
| rxmcastpkts |
Anzahl der vom VDS von der VM empfangenen Multicast-Pakete. |
4.2.0 |
| spoof_guard_arp_drops |
Anzahl der von SpoofGuard verworfenen ARP-Pakete. SpoofGuard schützt vor böswilligen ARP-Spoofing-Angriffen, indem MAC- und IP-Adressen nachverfolgt werden. Diese Statistik steigt nur, wenn SpoofGuard auf dem Segment oder Segmentport aktiviert ist. () |
4.2.0 |
| spoof_guard_ipv4_drops |
Anzahl der von SpoofGuard verworfenen IPv4-Pakete. SpoofGuard schützt vor IP-Spoofing, indem eine Referenztabelle mit VM-Namen und IP-Adressen gepflegt wird. Diese Statistik steigt nur, wenn SpoofGuard auf dem Segment oder Segmentport aktiviert ist. () |
4.2.0 |
| spoof_guard_ipv6_drops |
Anzahl der von SpoofGuard verworfenen IPv6-Pakete. SpoofGuard schützt vor IP-Spoofing, indem eine Referenztabelle mit VM-Namen und IP-Adressen gepflegt wird. Diese Statistik steigt nur, wenn SpoofGuard auf dem Segment oder Segmentport aktiviert ist. () |
4.2.0 |
| spoof_guard_nd_drops |
Anzahl der von SpoofGuard verworfenen IPv6-ND-Pakete (Neighbor Discovery). SpoofGuard schützt vor ND-Spoofing, indem ND-Pakete herausgefiltert werden, deren Adressen nicht mit der Adresse der VM übereinstimmen. Diese Statistik steigt nur, wenn SpoofGuard auf dem Segment oder Segmentport aktiviert ist. () |
4.2.0 |
| spoof_guard_non_ip_drops |
Anzahl der von SpoofGuard verworfenen Nicht-IP-Pakete. Diese Statistik steigt nur, wenn SpoofGuard auf dem Segment oder Segmentport aktiviert ist. () |
4.2.0 |
| tx_arp_pkts |
Anzahl der vom VDS an die VM gesendeten ARP-Pakete. |
4.2.0 |
| tx_ipv4_pkts |
Anzahl der vom VDS an die VM gesendeten IPv4-Pakete. |
4.2.0 |
| tx_ipv6_pkts |
Anzahl der vom VDS an die VM gesendeten IPv6-Pakete. |
4.2.0 |
| tx_non_ip_pkts |
Anzahl der vom VDS an die VM gesendeten Nicht-IP-Pakete. |
4.2.0 |
| tx_rate_limit_bcast_drops |
Anzahl der ausgehenden Pakete, die durch die Begrenzung der Broadcast-Rate verworfen wurden. Ratenbegrenzungen können verwendet werden, um das Netzwerk oder VMs vor Ereignissen wie Broadcast-Stürmen zu schützen. Sie können Ratenbegrenzungen in der Benutzeroberfläche von NSX Manager unter konfigurieren. |
4.2.0 |
| tx_rate_limit_mcast_drops |
Anzahl der ausgehenden Pakete, die durch die Begrenzung der Multicast-Rate verworfen wurden. Ratenbegrenzungen können verwendet werden, um das Netzwerk oder VMs vor Ereignissen wie Multicast-Stürmen zu schützen. Sie können Ratenbegrenzungen in der Benutzeroberfläche von NSX Manager unter konfigurieren. |
4.2.0 |
| txbcastpkts |
Anzahl der vom VDS an die VM gesendeten Broadcast-Pakete. |
4.2.0 |
| txmcastpkts |
Anzahl der vom VDS an die VM gesendeten Multicast-Pakete. |
4.2.0 |
Modul: overlay_datapath_l2
Dieses Datenpfadmodul ist für die Arbeitslastkonnektivität verantwortlich. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als nsxt-vdl2 bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| arp_proxy_req_fail_drops |
Anzahl der ARP-Anforderungen, die nicht für datenpfadbasiertes Lernen erneut auf Uplink gesendet werden konnten, wenn CCP nicht über eine IP-MAC-Bindung verfügt, was zu einem Fehler bei der ARP-Unterdrückung führt. Eine Statistik ungleich null weist darauf hin, dass das System nur noch über geringe Paketpufferressourcen verfügt. Ein stetiger Anstieg sollte als kritischer Fehler erachtet werden. |
4.2.0 |
| arp_proxy_req_suppress |
Anzahl der ARP-Anforderungen, die von VDL2 unterdrückt wurden, weil CCP abgefragt wurde, um die IP-MAC-Bindung zu finden. Diese ARP-Pakete werden nur dann auf Uplink gesendet, wenn CCP die Bindung nicht kennt. |
4.2.0 |
| arp_proxy_resp |
Anzahl der gültigen IP-MAC-Bindungsantworten von CCP für jede ARP-Unterdrückungsanforderung von diesem Transportknoten. |
4.2.0 |
| arp_proxy_resp_drops |
Anzahl der ARP-Antworten, die der IP-MAC-Bindungsantwort von CCP entsprechen und die nicht an den Switchport gesendet werden konnten, der die ARP-Anforderung angefordert hat. |
4.2.0 |
| arp_proxy_resp_filtered |
Anzahl der ARP-Antworten, die anhand der IP-MAC-Bindungsantwort von CCP generiert wurden und nicht an den Switch-Port gesendet werden, der die ARP-Anforderung initiiert hat. Dies kann vorkommen, wenn ARP aufgrund von Traceflow angefordert wurde oder der Port, der die ARP-Anforderung initiiert hat, nicht mehr im Transportknoten vorhanden war. |
4.2.0 |
| arp_proxy_resp_unknown |
Anzahl der unbekannten IP-MAC-Bindungen in der Steuerungsebene für jede IP-MAC-Anforderung von diesem Transportknoten. Beim Empfang dieser Meldung übermittelt das VDL2-Modul die ARP-Anforderung erneut auf den Uplink, um die IP-MAC-Bindung über den Datenpfad zu erlernen. |
4.2.0 |
| leaf_rx |
Diese Statistik steigt für ein Segment (logischer Switch), wenn ein durch eine Arbeitslast generiertes Paket erfolgreich in der IOChain „VDL2LeafInput (Overlay L2)“ empfangen wird. Diese Pakete werden an VDS gesendet, wenn keine anderen verworfen empfangenen Leafs vorhanden sind. |
4.2.0 |
| leaf_rx_drops |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2LeafInput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere empfangene Leaf an, um den spezifischen Grund für die Verworfenen zu identifizieren. |
4.2.0 |
| leaf_rx_ref_port_not_found_drops |
Anzahl der Paketverluste bei Leaf „VDL2LeafInput“. Dies kann passieren, wenn der Stamm-Port nicht Teil des Segments ist. |
4.2.0 |
| leaf_rx_system_err_drops |
Anzahl der Paketverwerfungen bei VDL2LeafInput aufgrund verschiedener Systemfehler wie Arbeitsspeicherfehler und Aktualisierungsfehler bei Paketattributen. Dies bedeutet im Allgemeinen, dass der ESXi-Host nur noch über geringe Ressourcen verfügt. Das Verschieben bestimmter VMs auf andere Hosts kann dazu beitragen, die Last zu erleichtern. |
4.2.0 |
| leaf_tx |
Diese Statistik steigt, wenn ein Paket erfolgreich von der IOChain „VDL2LeafOutput (Overlay L2)“ für einen Switch-Port verarbeitet wird. |
4.2.0 |
| leaf_tx_drops |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2LeafOutput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere gesendete Leaf an, um den spezifischen Grund für die Verworfenen zu identifizieren. |
4.2.0 |
| mac_tbl_lookup_flood |
Anzahl der Unicast-Pakete, die aufgrund eines MAC-Tabellen-Lookup-Fehlers an Remote-VTEPs geflutet wurden. Hohe Werte deuten auf Probleme mit unidirektionalen L2-Flows oder MAC-Tabellenaktualisierungen hin. Überprüfen Sie mithilfe des folgenden Befehls, ob die MAC-Tabelle auf dem Host-Transportknoten voll ist: $ nsxcli -c "get segment mac-table" Erhöhen Sie bei Bedarf die MAC-Tabellengröße. |
4.2.0 |
| mac_tbl_lookup_full |
Anzahl der Fehler bei Ziel-MAC-Abfragen an die Steuerungsebene für Datenverkehr zu Remote-VMs, da die MAC-Tabelle bereits voll war. Überprüfen Sie mithilfe des folgenden Befehls, ob die MAC-Tabelle auf dem Host-Transportknoten voll ist: $ nsxcli -c "get segment mac-table" Erhöhen Sie bei Bedarf die MAC-Tabellengröße. |
4.2.0 |
| mac_tbl_update_full |
Anzahl der Fehler beim Aktualisieren der MAC-Tabelle zum Zeitpunkt des MAC-Lernvorgangs für die vom Underlay empfangenen Pakete. Überprüfen Sie mithilfe des folgenden Befehls, ob die MAC-Tabelle auf dem Host-Transportknoten voll ist: $ nsxcli -c "get segment mac-table" Erhöhen Sie bei Bedarf die MAC-Tabellengröße. |
4.2.0 |
| mcast_proxy_rx_drops |
Anzahl der auf dem Uplink des MTEP-Transportknotens empfangenen BUM-Pakete, die beim Replizieren auf andere VTEPs verworfen werden. |
4.2.0 |
| mcast_proxy_tx_drops |
Anzahl der BUM-Pakete, die aus den Arbeitslasten im Transportknoten stammen und nach der Replizierung bei der Uplink-Ausgabe verworfen werden. Diese Statistik steigt, wenn uplink_tx_invalid_state_drops oder aufgrund von Systemfehlern wie nicht genügend Arbeitsspeicher auftreten. |
4.2.0 |
| nd_proxy_req_fail_drops |
Anzahl der ND-Anforderungen, die nicht für datenpfadbasiertes Lernen erneut auf Uplink gesendet werden konnten, wenn CCP nicht über eine IP-MAC-Bindung verfügt, was zu einem Fehler bei der ND-Unterdrückung führt. Eine Statistik ungleich null weist darauf hin, dass das System nur noch über geringe Paketpufferressourcen verfügt. Ein stetiger Anstieg sollte als kritischer Fehler erachtet werden. |
4.2.0 |
| nd_proxy_req_suppress |
Anzahl der ND-Anforderungen, die von VDL2 unterdrückt wurden, weil CCP abgefragt wurde, um die IP-MAC-Bindung zu finden. Diese ND-Pakete werden nur dann auf Uplink gesendet, wenn CCP die Bindung nicht kennt. |
4.2.0 |
| nd_proxy_resp |
Anzahl der gültigen IP-MAC-Bindungsantworten von CCP für jede ND-Unterdrückungsanforderung von diesem Transportknoten. Diese ND-Antworten können das Ergebnis einer direkten CCP-Antwort sein oder auf einen bereits zwischengespeicherten ND-Eintrag im Transportknoten zurückzuführen sein. |
4.2.0 |
| nd_proxy_resp_drops |
Anzahl der ND-Antworten, die der IP-MAC-Bindungsantwort von CCP entsprechen und die nicht an den Switchport gesendet werden konnten, der das ND-Paket initiiert hat. |
4.2.0 |
| nd_proxy_resp_filtered |
Anzahl der ND-Antworten, die anhand der IP-MAC-Bindungsantwort von CCP generiert wurden und nicht an den Switch-Port gesendet werden, der die ND-Anforderung initiiert hat. Dies kann vorkommen, wenn ND aufgrund von Traceflow angefordert wurde oder der Port, der die ND-Anforderung initiiert hat, nicht mehr im Transportknoten vorhanden war. |
4.2.0 |
| nd_proxy_resp_unknown |
Anzahl der unbekannten IPv6-MAC-Bindungen in der Steuerungsebene für jede IPv6-MAC-Anforderung von diesem Transportknoten. Beim Empfang dieser Meldung übermittelt das VDL2-Modul die ND-Pakete erneut auf den Uplink, um die IPv6-MAC-Bindung über den Datenpfad zu erlernen. |
4.2.0 |
| nested_tn_mcast_proxy_diff_vlan_tx_drops |
Anzahl der verworfenen BUM-Pakete, die für den verschachtelten Transportknoten repliziert wurden. Der verschachtelte Transportknoten und dieser Transportknoten sind mit einer anderen Transport-VLAN-ID konfiguriert. Überprüfen Sie, ob die VTEP-GW-IP von den VTEP-VMK-Schnittstellen dieses Transportknotens aus erreichbar ist. |
4.2.0 |
| nested_tn_mcast_proxy_same_vlan_tx_drops |
Anzahl der verworfenen BUM-Pakete, die für den verschachtelten Transportknoten repliziert wurden. Der verschachtelte Transportknoten und dieser Transportknoten sind mit derselben Transport-VLAN-ID konfiguriert. |
4.2.0 |
| uplink_rx |
Anzahl der Pakete, die am Uplink-Port vom TOR-Switch empfangen werden. Diese Pakete werden an VDS gesendet, wenn es keine Verwerfungen bei Uplink-Rx gibt. |
4.2.0 |
| uplink_rx_drops |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2UplinkInput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere empfangene Uplink an, um den spezifischen Grund für die Verworfenen zu identifizieren. |
4.2.0 |
| uplink_rx_filtered |
Anzahl der vom TOR-Switch gesendeten Pakete, die vom VDL2-Uplink aus Gründen wie IGMP-Berichten von Peer-ESXi-Transportknoten gefiltert wurden. |
4.2.0 |
| uplink_rx_guest_vlan_drops |
Anzahl der Paketverluste bei VDL2UplinkInput, wenn das Entfernen des Gast-VLAN-Tags für das innere Paket aufgrund eines Systemfehlers fehlschlägt. |
4.2.0 |
| uplink_rx_invalid_encap_drops |
Anzahl der Pakete, die beim Uplink vom Underlay empfangen und aufgrund falscher Kapselungs-Header verworfen werden. Um den genauen Fehler zu erfahren, führen Sie die Paketerfassung durch und überprüfen Sie die Kapselungs-Header (Protokollversion, Prüfsumme, Länge usw.), indem Sie den folgenden Befehl ausführen: pktcap-uw --capture UplinkRcvKernel --uplink --ng -o uplink.pcap |
4.2.0 |
| uplink_rx_mcast_invalid_dr_uplink_drops |
Anzahl der IP-Multicast-Paketverluste bei der VDL2-Uplink-Eingabe, da der vdrPort diesem Uplink nicht zugeordnet ist. Dies kann passieren, wenn der TOR-Switch den Multicast-Datenverkehr auf alle Uplinks des Transportknotens flutet. Überprüfen Sie den vdrPort und die Uplink-Zuordnung mithilfe des folgenden Befehls und überprüfen Sie dann, ob das verworfene Paket auf dem nicht zugeordneten Uplink empfangen wurde: nsxdp-cli vswitch instance list |
4.2.0 |
| uplink_rx_skip_mac_learn |
Anzahl der Pakete, für die die äußere Quell-MAC nicht erlernt werden kann, da die eingehende GENEVE-Bezeichnung unbekannt ist. Hohe Werte dieser Statistik können auf fehlende Remote-VTEP-Updates auf dem Transportknoten von der Steuerungsebene hinweisen. Verwenden Sie die folgenden CLI-Befehle, um die Remote-VTEP-Tabelle auf dem Transportknoten zu überprüfen: nsxcli -c "get global-vtep-table" $ nsxcli -c "get segment vtep-table" Eine mögliche Problemumgehung kann darin bestehen, den lokalen Steuerungsebenen-Agenten (CfgAgent) auf dem Transportknoten neu zu starten, um eine vollständige Synchronisierung zu erzwingen, indem Sie den folgenden Befehl ausführen: $ /etc/init.d/nsx-cfgagent restart |
4.2.0 |
| uplink_rx_system_err_drops |
Anzahl der Paketverwerfungen bei VDL2UplinkInput aufgrund verschiedener Systemfehler wie Arbeitsspeicherfehler und Aktualisierungsfehler bei Paketattributen. Dies bedeutet im Allgemeinen, dass der ESXi-Host nur noch über geringe Ressourcen verfügt. Das Verschieben bestimmter VMs auf andere Hosts kann dazu beitragen, die Last zu erleichtern. |
4.2.0 |
| uplink_rx_wrong_dest_drops |
Die Anzahl der vom Underlay empfangenen und verworfenen Pakete, da die Ziel-IP des Pakets mit keinem der auf dem Host konfigurierten VTEPs übereinstimmt. |
4.2.0 |
| uplink_tx |
Anzahl der vom VDS gesendeten Pakete, die an der IOChain „VDL2“ des Uplink-Ports empfangen werden. Diese Pakete werden an das Underlay-Netzwerk gesendet, wenn es keine Verworfenen bei Uplink Tx gibt. |
4.2.0 |
| uplink_tx_drops |
Anzahl der Pakete, die aus verschiedenen Gründen bei VDL2UplinkOutput verworfen wurden. Sehen Sie sich die Gründe für das verworfene andere übertragene Uplink an, um den spezifischen Grund für die Verworfenen zu identifizieren. |
4.2.0 |
| uplink_tx_flood_rate_limit |
Anzahl der unbekannten Unicast-Pakete, die auf Uplinks mit begrenzter Rate geflutet wurden. |
4.2.0 |
| uplink_tx_ignore |
Anzahl der von VDS gesendeten Pakete, die bei der VDL2-Uplink-Ausgabe gefiltert und nicht an das Underlay weitergeleitet wurden. BUM-Pakete werden beispielsweise gefiltert, wenn keine VTEPs im Segment vorhanden sind, auf die die Pakete repliziert werden sollen. |
4.2.0 |
| uplink_tx_invalid_frame_drops |
Anzahl der Pakete, die bei der VDL2-Uplink-Ausgabe verworfen wurden, da entweder der Encap-Header nicht gefunden werden konnte oder das auf dem inneren Frame festgelegte TSO nicht durchgeführt werden konnte. Dies ist auf große TCP-Pakete zurückzuführen. |
4.2.0 |
| uplink_tx_invalid_state_drops |
Anzahl der Pakete, die bei der VDL2-Uplink-Ausgabe aufgrund einer falschen Transport-VLAN-Konfiguration verworfen wurden. Dies ist auf eine falsche Uplink-Profilzuordnung auf dem Transportknoten oder auf eine nicht aufgelöste Gateway-MAC zurückzuführen. Verwenden Sie das folgende Verfahren, um auf einem ESXi-Knoten zu überprüfen, ob die VTEP-Gateway-IP von den VTEP-VMK-Schnittstellen dieses Transportknotens aus erreichbar ist.
|
4.2.0 |
| uplink_tx_nested_tn_repl_drops |
Anzahl der BUM-Pakete, die bei der VDL2-Uplink-Ausgabe während der Replizierung auf den geschachtelten Transportknoten aufgrund einer falschen VTEP-Zuordnung verworfen werden. Verwenden Sie den folgenden Befehl, um die Zuordnung zwischen Quell-Switchport und Uplink zu überprüfen: nsxdp-cli vswitch instance list |
4.2.0 |
| uplink_tx_non_unicast |
Anzahl der auf Remote-VTEPs replizierten Broadcast- oder Multicast-Pakete. Eine hohe Rate bedeutet, dass der Transportknoten diese Pakete auf Remote-VTEPs replizieren muss, was zu einer Belastung der übertragenen Warteschlangen der Uplink-Ebene führen kann. |
4.2.0 |
| uplink_tx_teaming_drops |
Anzahl der Pakete, die bei VDL2UplinkOutput aufgrund der Nichtverfügbarkeit des VTEP verworfen werden, der mit dem Switchport verknüpft ist, der den Datenverkehr ausgelöst hat. Verwenden Sie den folgenden Befehl, um die Uplink-Zuordnung des Arbeitslast-Switchports und den Teaming-Status zu überprüfen: nsxdp-cli vswitch instance list |
4.2.0 |
| uplink_tx_ucast_flood |
Anzahl der unbekannten Unicast-Pakete, die bei der Uplink-Ausgabe geflutet wurden. Hohe Werte deuten auf Probleme mit unidirektionalem L2-Flow oder MAC-Tabellenaktualisierungen hin. Überprüfen Sie, ob der unidirektionale Flow erwartet wird oder ob die MAC-Tabelle voll ist. |
4.2.0 |
Modul: datapath_l3
Dieses Datenpfadmodul, auch als Virtual Distributed Routing (VDR) bezeichnet, leitet Pakete auf jedem ESXi-Host weiter. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als nsxt-vdrb bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| arp_hold_pkt_drops |
Wenn der verteilte Router gerade einen IPv4-ARP-Eintrag auflöst, werden die Pakete, die diesen ARP-Eintrag verwenden, in die Warteschlange gestellt. Die Anzahl der Pakete, die in die Warteschlange gestellt werden können, ist pro logischer Router-Instanz begrenzt. Wenn die Obergrenze erreicht ist, werden die ältesten Pakete verworfen und diese Statistik um die Anzahl der verworfenen alten Pakete erhöht. |
4.2.0 |
| arpfaildrops (lta) |
IPv4-Paketverwerfungen aufgrund eines ARP-Fehlers. |
4.2.0 |
| consumed_icmpv4 |
Anzahl der IPv4-Pakete, die für die IP-Adresse eines logischen Routing-Ports des verteilten Routers bestimmt sind, die einem bestimmten Segment entspricht. Beachten Sie, dass die Statistik nach dem Routing des Pakets aus dem Quellsubnetz steigt. |
4.2.0 |
| consumed_icmpv6 |
Anzahl der IPv6-Pakete, die für die IP-Adresse eines logischen Routing-Ports des verteilten Routers bestimmt sind, die einem bestimmten Segment entspricht. Beachten Sie, dass die Statistik nach dem Routing des Pakets aus dem Quellsubnetz steigt. |
4.2.0 |
| drop_route_ipv4_drops |
Anzahl der IPv4-Pakete, die mit „Drop-Routen“ übereinstimmen. Drop-Routen sind die Routen, die so konfiguriert sind, dass die entsprechenden Pakete absichtlich verworfen werden. Wenn dies nicht erwartet wird, überprüfen Sie die Routen auf dem ESXi-Host und die Konfiguration in der Management Plane. |
4.2.0 |
| drop_route_ipv6_drops |
Anzahl der IPv6-Pakete, die mit „Drop-Routen“ übereinstimmen. Drop-Routen sind die Routen, die so konfiguriert sind, dass die entsprechenden Pakete absichtlich verworfen werden. Wenn dies nicht erwartet wird, überprüfen Sie die Routen auf dem ESXi-Host und die Konfiguration in der Management Plane. |
4.2.0 |
| ndfaildrops (lta) |
IPv6-Paketverwerfungen aufgrund eines Fehlers bei der Nachbarerkennung. |
4.2.0 |
| no_nbr_ipv4 |
Kein IPv4-ARP-Eintrag in der ARP-Tabelle des verteilten Routers gefunden. |
4.2.0 |
| no_nbr_ipv6 |
Kein IPv6-Nachbareintrag in der Nachbartabelle des verteilten Routers gefunden. |
4.2.0 |
| no_route_ipv4_drops |
Jede logische Router-Instanz verfügt über eine eigene Routing-Tabelle für die Routensuche. Diese Statistik steigt, wenn IPv4-Pakete verworfen werden, weil keine übereinstimmende Route für diese logische Router-Instanz vorhanden ist. |
4.2.0 |
| no_route_ipv6_drops |
Jede logische Router-Instanz verfügt über eine eigene Routing-Tabelle für die Routensuche. Diese Statistik steigt, wenn IPv6-Pakete verworfen werden, weil keine übereinstimmende Route für diese logische Router-Instanz vorhanden ist. |
4.2.0 |
| ns_hold_pkt_drops |
Wenn der verteilte Router gerade einen IPv6-Nachbareintrag auflöst, werden die Pakete, die diesen Nachbareintrag verwenden, in die Warteschlange gestellt. Die Anzahl der Pakete, die in die Warteschlange gestellt werden können, ist pro logischer Router-Instanz begrenzt. Wenn die Obergrenze erreicht ist, werden die ältesten Pakete verworfen und diese Statistik um die Anzahl der verworfenen alten Pakete erhöht. |
4.2.0 |
| pkt_attr_error_drops |
Anzahl der Pakete, bei denen der Attributvorgang fehlgeschlagen ist. NSX verwendet Paketattribute, um die Paketverarbeitung zu erleichtern. Die Paketattribute können zugeteilt, festgelegt oder nicht festgelegt werden. Normalerweise schlägt der Vorgang nicht fehl.
Einige mögliche Gründe für einen Anstieg dieser Statistik sind die folgenden:
|
4.2.0 |
| relayed_dhcpv4_req |
Weitergeleitete DHCPv4-Anforderungen. |
4.2.0 |
| relayed_dhcpv4_rsp |
Weitergeleitete DHCPv4-Antworten. |
4.2.0 |
| relayed_dhcpv6_req |
Weitergeleitete DHCPv6-Anforderungen. |
4.2.0 |
| relayed_dhcpv6_rsp |
Weitergeleitete DHCPv6-Antworten. |
4.2.0 |
| rpf_ipv4_drops |
Anzahl der IPv4-Pakete, die aufgrund eines Fehlers bei der Überprüfung der umgekehrten Pfadweiterleitung verworfen wurden. Der verteilte Router überprüft möglicherweise, ob die Quell-IP der Pakete von einer gültigen (erreichbaren) Quelle stammt, und verwirft die Pakete möglicherweise basierend auf der Konfiguration. Sie können diese Einstellung in der Benutzeroberfläche von NSX Manager ändern.
Führen Sie die folgenden Schritte aus, um die aktuelle Konfiguration auf der Benutzeroberfläche von
NSX Manager zu überprüfen:
|
4.2.0 |
| rpf_ipv6_drops |
Anzahl der IPv6-Pakete, die aufgrund eines Fehlers bei der Überprüfung der umgekehrten Pfadweiterleitung verworfen wurden. Der verteilte Router überprüft möglicherweise, ob die Quell-IP der Pakete von einer gültigen (erreichbaren) Quelle stammt, und verwirft die Pakete möglicherweise basierend auf der Konfiguration. Sie können diese Einstellung in der Benutzeroberfläche von NSX Manager ändern.
Führen Sie die folgenden Schritte aus, um die aktuelle Konfiguration auf der Benutzeroberfläche von
NSX Manager zu überprüfen:
|
4.2.0 |
| rx_arp_req |
Anzahl der ARP-Anforderungspakete, die vom logischen Router-Port eines verteilten Routers empfangen werden, der einem bestimmten Segment entspricht. |
4.2.0 |
| rx_ipv4 |
Anzahl der IPv4-Pakete, die an einem logischen Routing-Port eines verteilten Routers ankommen, der einem bestimmten Segment entspricht. |
4.2.0 |
| rx_ipv6 |
Anzahl der IPv6-Pakete, die an einem logischen Routing-Port eines Distributed Routers ankommen, der einem bestimmten Segment entspricht. |
4.2.0 |
| rx_pkt_parsing_error_drops |
Anzahl der Paketanalysefehler für vom verteilten Router empfangene Pakete. Der verteilte Router führt die Paketanalyse für jedes empfangene Paket durch, um Metadaten und Header zu lesen. Wenn Sie eine hohe Zahl bei dieser Statistik sehen, könnte dies daran liegen, dass die Pakete nicht korrekt strukturiert sind. Überwachen Sie, ob Datenverkehrsfehler vorliegen, und führen Sie für weiteres Debugging die Paketerfassung durch. |
4.2.0 |
| rxgarp (lta) |
Gratuitous GARP wurde auf einem verteilten Router empfangen. |
4.2.0 |
| ttl_ipv4_drops |
Anzahl der IPv4-Pakete, die aufgrund einer niedrigen TTL (Time-To-Live) verworfen wurden. Jede logische Router-Instanz zieht 1 vom TTL-Wert ab. Verwenden Sie die Paketerfassung, um zu ermitteln, welche Pakete niedrige TTL-Werte aufweisen. Wenn die TTL an der Quelle eher groß ist, sind mögliche Gründe zu viele Routing-Hops auf dem Pfad oder das Paket durchläuft eine Schleife, was selten ist. |
4.2.0 |
| ttl_ipv6_drops |
Anzahl der IPv6-Pakete, die aufgrund einer niedrigen TTL (Time-To-Live) verworfen wurden. Jede logische Router-Instanz zieht 1 vom TTL-Wert ab. Verwenden Sie die Paketerfassung, um zu ermitteln, welche Pakete niedrige TTL-Werte aufweisen. Wenn die TTL an der Quelle eher groß ist, sind mögliche Gründe zu viele Routing-Hops auf dem Pfad oder das Paket durchläuft eine Schleife, was selten ist. |
4.2.0 |
| tx_arp_rsp |
Anzahl der ARP-Anforderungspakete, die vom logischen Router-Port eines verteilten Routers gesendet werden, der einem bestimmten Segment entspricht. |
4.2.0 |
| tx_dispatch_queue_too_long_drops |
Anzahl der Pakete, die in der Übertragungs-Dispatch-Warteschlange verworfen werden. Die Übertragungs-Dispatch-Warteschlange enthält selbst generierte Pakete für den verteilten Router wie ARP-Pakete, NS-Erkennung usw. Jedes Paket verbraucht Systemressourcen für die Paketverarbeitung. Wenn zu viele Pakete in der Warteschlange anfallen, begrenzen Sie die Warteschlangengröße und verwerfen Sie die letzten Pakete. |
4.2.0 |
| tx_ipv4 |
Anzahl der IPv4-Pakete, die von einem logischen Router-Port eines verteilten Routers ausgehen, der einem bestimmten Segment entspricht. |
4.2.0 |
| tx_ipv6 |
Anzahl der IPv6-Pakete, die von einem logischen Router-Port eines verteilten Routers ausgehen, der einem bestimmten Segment entspricht. |
4.2.0 |
Modul: distributed_firewall
Dieses Datapth-Modul bietet Funktionen für verteilte Firewalls. In dieser Tabelle bezieht sich Rx auf Pakete, die vom Switchport empfangen werden (von der VM gesendet), und Tx bezieht sich auf Pakete, die vom Switchport übertragen werden (von der VM empfangen). Dieses Datenpfadmodul wird in der zentralen NSX-CLI als nsxt-vsip bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| alg_handler_drops |
Anzahl der Pakete, die aufgrund der ALG-Verarbeitung verworfen wurden. Verfolgt Fehler bei der Verarbeitung von ALG-Status-Decoder-Paketen. |
4.2.0 |
| bad_offset_drops |
Anzahl der Pakete, die aufgrund eines fehlerhaften Offset verworfen wurden. |
4.2.0 |
| bad_timestamp_drops |
Anzahl der Pakete, die aufgrund eines ungültigen Zeitstempels verworfen wurden. Beispielsweise sollten ACK-Pakete mit einem alten Zeitstempel und empfangene Pakete mit unerwartetem Zeitstempel verworfen werden. |
4.2.0 |
| congestion_drops |
Anzahl der Pakete, die aufgrund einer Überlastung verworfen wurden. Beispielsweise bei einer erkannten Überlastung in der Warteschlange für eine Netzwerkschnittstelle. |
4.2.0 |
| fragment_drops |
Anzahl der Pakete, die aufgrund einer fehlgeschlagenen Neuzusammensetzung fragmentierter Pakete verworfen wurden. Fragmentierung bricht Pakete in kleinere Fragmente auf, sodass die resultierenden Teile einen Link passieren können, dessen MTU kleiner als die ursprüngliche Paketgröße ist. |
4.2.0 |
| handshake_error_drops |
Anzahl der Pakete, die aufgrund eines TCP-Dreiwege-Handshake-Fehlers verworfen wurden. Dies kann passieren, wenn sowohl der Absender als auch der Empfänger während des Dreiwege-Handshakes in SYN gesendet werden. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| icmp_err_pkt_drops |
Anzahl der Pakete, die aufgrund zusätzlicher ICMP-Fehlerantwortpakete verworfen wurden. Diese Statistik verfolgt die zusätzlichen Pakete der ICMP-Fehlerantwort, die verworfen werden. |
4.2.0 |
| icmp_error_drops |
Anzahl der Pakete, die aufgrund eines Sequenzfehlers in der ICMP-Fehlerantwort auf das TCP-Paket verworfen wurden. Wenn Sequenznummern außerhalb des erwarteten Bereichs liegen, führt dies zu einer Verwerfung. |
4.2.0 |
| icmp_flood_overlimit_drops |
Anzahl der Pakete, die aufgrund der Überschreitung eines ICMP-Flood-Grenzwerts verworfen wurden. Es ist ein konfigurierter ICMP-Flood-Grenzwert in der Kernel-Schnittstelle vorhanden. |
4.2.0 |
| ignored_offloaded_fpdrops |
Anzahl der Pakete, die aufgrund eines an die Hardware ausgelagerten Flows verworfen wurden. Das Auslagern des Flows auf die Hardware bedeutet, dass die Verbindungsverfolgung durch die Hardware-Paketpipeline einer smartNIC durchgeführt wird. In diesem Fall ist der Erhalt eines Pakets in der Software unerwartet. Das Paket kann nicht in der Software verarbeitet werden, da die Software über keine aktuellen CT-Informationen (z. B. Zustände, Sequenznummern) verfügt. Daher muss der Datenverkehr verworfen werden. Dieser Fall kann auftreten, weil das Auslagern eines Flows auf die Hardware einige Zeit in Anspruch nimmt und es zu einem Wettlauf mit Paketen kommen kann, die bereits in die Warteschlange gestellt wurden, um an VSIP geliefert zu werden. Dieser Verwerfungsgrund gilt für die ENS-Fastpath-Pakete. |
4.2.0 |
| ignored_offloaded_spdrops |
Anzahl der Pakete, die aufgrund eines an die Hardware ausgelagerten Flows verworfen wurden. Das Auslagern des Flows auf die Hardware bedeutet, dass die Verbindungsverfolgung durch die Hardware-Paketpipeline einer smartNIC durchgeführt wird. In diesem Fall ist der Erhalt eines Pakets in der Software unerwartet. Das Paket kann nicht in der Software verarbeitet werden, da die Software über keine aktuellen CT-Informationen (z. B. Zustände, Sequenznummern) verfügt. Daher muss der Datenverkehr verworfen werden. Dieser Fall kann auftreten, weil das Auslagern eines Flows auf die Hardware einige Zeit in Anspruch nimmt und es zu einem Wettlauf mit Paketen kommen kann, die bereits in die Warteschlange gestellt wurden, um an VSIP geliefert zu werden. Dieser Verwerfungsgrund gilt für den IOChain-Codepfad, der in diesem Kontext auch als Slowpath bezeichnet wird. |
4.2.0 |
| ip_option_drops |
Anzahl der verworfenen Pakete aufgrund nicht zulässiger IP-Optionen. Wenn „allow_opts“ in der Firewallregel nicht festgelegt ist, wird das Paket, das auf diese Regel trifft, verworfen. |
4.2.0 |
| l7_alert_drops |
Die L7-Regel ist vorhanden, aber es gibt keine Übereinstimmung. Eine Warnung wird generiert. |
4.2.0 |
| l7_attr_error_drops |
Anzahl der Pakete, die aufgrund eines Fehlers beim Festlegen von Statusattributen verworfen wurden. Dies tritt auf, wenn das Zuteilen oder Ändern von |
4.2.0 |
| l7_pending_misc |
Diese Statistik verfolgt die Pakete, die derzeit von DPI analysiert werden, wobei die Regelübereinstimmung aussteht. Sobald die Übereinstimmung der L7-Regel eintritt, wird die entsprechende Regelaktion für das Paket durchgeführt. |
4.2.0 |
| lb_reject_drops |
Diese Statistik verfolgt Verwerfungen aufgrund von Paketen, die vom Load Balancer abgelehnt wurden. Pakete werden verworfen, wenn sie mit einem virtuellen Server des Load Balancer übereinstimmen, aber kein Poolmitglied ausgewählt ist. |
4.2.0 |
| match_drop_rule_rx_drops |
Anzahl der empfangenen Pakete, die durch die Regel „Verwerfen“ oder „Ablehnen“ verworfen wurden. |
4.2.0 |
| match_drop_rule_tx_drops |
Anzahl der übertragenen Pakete, die durch die Regel „Verwerfen“ oder „Ablehnen“ verworfen wurden. |
4.2.0 |
| memory_drops |
Anzahl der Pakete, die aufgrund eines Mangels an Arbeitsspeicher verworfen wurden. Dies ist ein Fehler auf Kapazitätsebene. |
4.2.0 |
| normalize_drops |
Anzahl der Pakete, die aufgrund falsch formatierter Pakete verworfen wurden. In diesen Fällen stimmt beispielsweise die IP-Version nicht überein oder der TCP-Header-Offset stimmt nicht mit der Gesamtlänge der Paketbeschreibung überein |
4.2.0 |
| other_flood_overlimit_drops |
Anzahl der Pakete, die aufgrund eines anderen Grenzwerts für die Protokollüberflutung verworfen wurden. Es ist ein konfigurierter Überflutungsgrenzwert in der Kernel-Schnittstelle für andere Protokolle vorhanden. |
4.2.0 |
| pkts_frag_queued_v4_misc |
Während der Paketfragmentierung werden die Paketfragmente zur Fragmentwarteschlange hinzugefügt. Diese Paketfragmente werden nicht notwendigerweise verworfen. Ein erfolgreiches Zusammensetzen von Paketen bedeutet, dass keine fragmentierten Pakete verworfen werden. Diese Statistik verfolgt IPv4-Pakete, die der Fragmentwarteschlange hinzugefügt werden. |
4.2.0 |
| pkts_frag_queued_v6_misc |
Während der Paketfragmentierung werden die Paketfragmente zur Fragmentwarteschlange hinzugefügt. Diese Paketfragmente werden nicht notwendigerweise verworfen. Ein erfolgreiches Zusammensetzen von Paketen bedeutet, dass keine fragmentierten Pakete verworfen werden. Diese Statistik verfolgt IPv6-Pakete, die der Fragmentwarteschlange hinzugefügt werden. |
4.2.0 |
| proto_cksum_drops |
Anzahl der Pakete, die aufgrund einer falschen Protokollprüfsumme verworfen wurden. Dies tritt auf, wenn die Prüfsummenvalidierung des Pakets fehlschlägt. |
4.2.0 |
| rx_ipv4_drop_pkts |
Anzahl der empfangenen verworfenen IPv4-Pakete. |
4.2.0 |
| rx_ipv4_pass_pkts |
Anzahl der empfangenen weitergegebenen IPv4-Pakete. |
4.2.0 |
| rx_ipv4_reject_pkts |
Anzahl der empfangenen abgelehnten IPv4-Pakete. |
4.2.0 |
| rx_ipv6_drop_pkts |
Anzahl der empfangenen verworfenen IPv6-Pakete. |
4.2.0 |
| rx_ipv6_pass_pkts |
Anzahl der empfangenen weitergegebenen IPv6-Pakete. |
4.2.0 |
| rx_ipv6_reject_pkts |
Anzahl der empfangenen abgelehnten IPv6-Pakete. |
4.2.0 |
| rx_l2_drop_pkts |
Anzahl der empfangenen verworfenen Layer-2-Pakete. |
4.2.0 |
| seqno_bad_ack_drops |
Anzahl der Pakete, die aufgrund von TCP-Bestätigungen für die Weiterleitung von mehr als einem Fenster verworfen wurden. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| seqno_gt_max_ack_drops |
Anzahl der Pakete, die verworfen wurden, weil die TCP-Sequenznummer größer als die maximale ACK-Zahl ist. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| seqno_lt_minack_drops |
Anzahl der Pakete, die verworfen wurden, weil die TCP-Sequenznummer kleiner als die minimale ACK-Zahl ist. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| seqno_old_ack_drops |
Anzahl der Pakete, die aufgrund der TCP-Bestätigung von mehr als einem Fragment verworfen wurden. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| seqno_old_retrans_drops |
Anzahl der Pakete, die aufgrund einer TCP-Neuübertragung verworfen wurden, die älter als ein Fenster ist. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| seqno_outside_window_drops |
Anzahl der Pakete, die aufgrund der TCP-Sequenznummer außerhalb des Fensters verworfen wurden. Dieser Grund für eine Verwerfung ist ein Typ von nicht übereinstimmendem TCP-Status. |
4.2.0 |
| short_drops |
Anzahl der verworfenen kurzen Pakete. Kurze Pakete sind Pakete mit falscher Länge, z. B. Pakete mit falsch formatiertem Wert für |
4.2.0 |
| spoof_guard_drops |
Anzahl der Pakete, die aufgrund der SpoofGuard-Prüfung verworfen wurden. SpoofGuard ist ein Tool, das virtuelle Maschinen in Ihrer Umgebung daran hindert, Datenverkehr von einer nicht für das Senden berechtigten IP-Adresse zu senden. |
4.2.0 |
| src_limit_misc |
Anzahl der Pakete, die den Quellgrenzwert erreichen. Dies hängt mit der Verarbeitung von Paketen durch die Firewall zusammen. Dies tritt aufgrund eines Fehlers beim Einfügen des Quellknotens in die RB-Struktur (Rot-Schwarz) auf, da der Grenzwert erreicht wurde. |
4.2.0 |
| state_insert_drops |
Anzahl der Pakete, die aufgrund eines statusbezogenen Einfügungsfehlers verworfen wurden. Dies ist auf das Einfügen eines doppelten Zustands zurückzuführen. |
4.2.0 |
| state_limit_drops |
Anzahl der Pakete, die aufgrund des erreichten maximalen Grenzwerts für Zustände verworfen wurden. Wenn beispielsweise die Anzahl der TCP-Zustände höher als der Grenzwert ist, führt dies zu einem Verwerfen. |
4.2.0 |
| state_mismatch_drops |
Anzahl der Pakete, die aufgrund eines Zustandskonflikts verworfen wurden. Es gibt mehrere mögliche Gründe für den Abbruch, z. B. STRICTNOSYN, HANDSHAKE_SYNSENT, SEQ_GT_SEQHI usw. |
4.2.0 |
| strict_no_syn_drops |
Anzahl der Pakete, die aufgrund des strengen Erzwingungsmodus ohne SYN verworfen wurden. Es wird erwartet, dass das SYN-Paket im strengen Modus erkannt wird. |
4.2.0 |
| syn_expected_drops |
Das Paket stimmt mit einem virtuellen Server des Load Balancer überein, es handelt sich jedoch nicht um ein SYN-Paket. Daher sollte das System keinen Zustand dafür erstellen. Das führt zu einem verworfenen Paket. Diese Statistik verfolgt diese Verwerfung. |
4.2.0 |
| syn_proxy_drops |
Anzahl der Pakete, die aufgrund von Synproxy verworfen wurden. Dies dient dem Schutz von TCP-Servern vor Angriffen wie SYN FLOOD. |
4.2.0 |
| tcp_flood_overlimit_drops |
Anzahl der Pakete, die aufgrund der Überschreitung eines TCP-Flood-Grenzwerts verworfen wurden. Es ist ein konfigurierter TCP-Flood-Grenzwert in der Kernel-Schnittstelle vorhanden. |
4.2.0 |
| tx_ipv4_drop_pkts |
Anzahl der übertragenen verworfenen IPv4-Pakete. |
4.2.0 |
| tx_ipv4_pass_pkts |
Anzahl der übertragenen weitergegebenen IPv4-Pakete. |
4.2.0 |
| tx_ipv4_reject_pkts |
Anzahl der übertragenen abgelehnten IPv4-Pakete. |
4.2.0 |
| tx_ipv6_drop_pkts |
Anzahl der übertragenen verworfenen IPv6-Pakete. |
4.2.0 |
| tx_ipv6_pass_pkts |
Anzahl der übertragenen weitergegebenen IPv6-Pakete. |
4.2.0 |
| tx_ipv6_reject_pkts |
Anzahl der übertragenen abgelehnten IPv6-Pakete. |
4.2.0 |
| tx_l2_drop_pkts |
Anzahl der übertragenen verworfenen Layer-2-Pakete. |
4.2.0 |
| udp_flood_overlimit_drops |
Anzahl der Pakete, die aufgrund der Überschreitung eines UDP-Flood-Grenzwerts verworfen wurden. Es ist ein konfigurierter UDP-Flood-Grenzwert in der Kernel-Schnittstelle vorhanden. |
4.2.0 |
Modul: virtual_switch
Dieses Layer-2-Datenpfadmodul ist für die Bereitstellung von Switching-Funktionen verantwortlich. Dieses Modul leitet Pakete innerhalb einer Broadcast-Domäne basierend auf denjenigen VLAN und VNI weiter, auf denen eine Schnittstelle ein Paket empfängt. In dieser Tabelle bezieht sich Rx auf Pakete, die „an den Switch“ gesendet wurden, und Tx bezieht sich auf Pakete, die „vom Switch“ empfangen wurden. Mcast bezieht sich auf Multicast-Pakete. Dieses Datenpfadmodul wird in der zentralen NSX-CLI als nsxt-vswitch bezeichnet.
| Statistik | Beschreibung | Version eingeführt |
|---|---|---|
| forged_transmit_rx_drops |
Anzahl der Pakete, die als gefälscht verworfen wurden, da sich die Quell-MAC des Pakets von der MAC des Adapters der virtuellen Maschine unterscheidet. Gefälschte Übertragungen oder deaktivierte MAC-Lernvorgänge im Segment führen zu diesen Verwerfungen. Die Aktivierung von MAC Learning oder gefälschten Übertragungen im Segment sollte das Problem abmildern. |
4.2.0 |
| unknown_unicast_rx_pkts |
Anzahl der vom vSwitch empfangenen unbekannten Unicast-Pakete, die an andere Ports in derselben Broadcast-Domäne geflutet werden. Diese Statistik steigt, wenn Pakete unbekannte Unicast-Pakete sind, die bei Vorhandensein von MAC Learning-aktivierten Segmenten oder Sink-Ports geflutet werden. Ein unbekanntes Unicast-Flooding tritt auf, wenn sich die Ziel-MAC-Adresse des Pakets nicht in der Tabelle der vSwitch-MAC-Adressen befindet. Diese Statistik steigt, wenn eine Ziel-MAC bei Vorhandensein von MAC Learning aus der MAC-Adresstabelle abläuft. |
4.2.0 |
| unknown_unicast_rx_uplink_pkts |
Anzahl der Pakete, die von einem oder mehreren Uplinks zum vSwitch empfangen wurden, bei denen es sich um unbekannte Unicast-Pakete handelt, die vom vSwitch an andere Ports in derselben Broadcast-Domäne geflutet werden. Diese Statistik steigt, wenn Pakete unbekannte Unicast-Pakete sind, die bei Vorhandensein von MAC Learning-aktivierten Segmenten oder Sink-Ports geflutet werden. Ein unbekanntes Unicast-Flooding tritt auf, wenn sich die Ziel-MAC-Adresse des Pakets nicht in der Tabelle der vSwitch-MAC-Adressen befindet. Diese Statistik steigt, wenn eine Ziel-MAC bei Vorhandensein von MAC Learning aus der MAC-Adresstabelle abläuft. |
4.2.0 |
| unknown_unicast_tx_pkts |
Anzahl der unbekannten Unicast-Pakete, die vom vSwitch an andere Ports in derselben Broadcast-Domäne geflutet wurden. Diese Statistik steigt, wenn Pakete unbekannte Unicast-Pakete sind, die bei Vorhandensein von MAC Learning-aktivierten Segmenten oder Sink-Ports geflutet werden. Ein unbekanntes Unicast-Flooding tritt auf, wenn sich die Ziel-MAC-Adresse des Pakets nicht in der Tabelle der vSwitch-MAC-Adressen befindet. Diese Statistik steigt, wenn eine Ziel-MAC bei Vorhandensein von MAC Learning aus der MAC-Adresstabelle abläuft. |
4.2.0 |
| unknown_unicast_tx_uplink_pkts |
Anzahl der unbekannten Unicast-Pakete, die vom vSwitch auf einen oder mehrere Uplinks geflutet wurden. Diese Statistik steigt, wenn Pakete unbekannte Unicast-Pakete sind, die bei Vorhandensein von MAC Learning-aktivierten Segmenten oder Sink-Ports geflutet werden. Ein unbekanntes Unicast-Flooding tritt auf, wenn sich die Ziel-MAC-Adresse des Pakets nicht in der Tabelle der vSwitch-MAC-Adressen befindet. Diese Statistik steigt, wenn eine Ziel-MAC bei Vorhandensein von MAC Learning aus der MAC-Adresstabelle abläuft. |
4.2.0 |
| vlan_tag_mismatch_rx |
Anzahl der Unicast- und Broadcast-Pakete, die aufgrund einer VLAN-Tag-Nichtübereinstimmung verworfen wurden. Diese Verwerfungen treten auf, wenn das VLAN-Tag eines Pakets gemäß der VLAN-Richtlinie des Segments nicht zulässig ist. Das Problem kann durch das Ändern der VLAN-Richtlinie des Segments oder das Senden von Paketen mit einem zulässigen VLAN-Tag verringert werden. |
4.2.0 |
| vlan_tag_mismatch_rx_mcast |
Anzahl der Multicast-Pakete, die aufgrund einer VLAN-Tag-Nichtübereinstimmung verworfen wurden. Diese Verwerfungen treten auf, wenn das VLAN-Tag eines Pakets gemäß der VLAN-Richtlinie des Segments nicht zulässig ist. Das Problem kann durch das Ändern der VLAN-Richtlinie des Segments oder das Senden von Paketen mit einem zulässigen VLAN-Tag verringert werden. |
4.2.0 |
| vlan_tag_mismatch_tx |
Anzahl der Unicast-Pakete, die aufgrund einer VLAN-Tag-Nichtübereinstimmung verworfen wurden. Der Host-Switch sucht auf Basis der Zieladresse des Pakets einen Eintrag in seiner Suchtabelle. Beim Versuch, das Paket von einem Port aus weiterzuleiten, treten diese Verwerfungen auf, wenn das VLAN-Tag eines Pakets gemäß der VLAN-Richtlinie des Segments nicht zulässig ist. Das Problem kann durch das Ändern der VLAN-Richtlinie des Segments oder das Senden von Paketen mit einem zulässigen VLAN-Tag verringert werden. |
4.2.0 |
| vlan_tag_mismatch_tx_mcast |
Anzahl der Multicast-Pakete, die aufgrund einer VLAN-Tag-Nichtübereinstimmung verworfen wurden. Der Host-Switch sucht auf Basis der Zieladresse des Pakets einen Eintrag in seiner Suchtabelle. Beim Versuch, das Paket von einem Port aus weiterzuleiten, treten diese Verwerfungen auf, wenn das VLAN-Tag eines Pakets gemäß der VLAN-Richtlinie des Segments nicht zulässig ist. Das Problem kann durch das Ändern der VLAN-Richtlinie des Segments oder das Senden von Paketen mit einem zulässigen VLAN-Tag verringert werden. |
4.2.0 |
| vni_tag_mismatch_tx |
Anzahl der Unicast-Pakete, die aufgrund einer VNI-Tag-Nichtübereinstimmung verworfen wurden. Der Host-Switch sucht auf Basis der Zieladresse des Pakets einen Eintrag in seiner Suchtabelle. Beim Versuch, das Paket von einem Port aus weiterzuleiten, treten diese Verwerfungen auf, wenn das VNI-Tag eines Pakets gemäß der VNI-Richtlinie des Segments nicht zulässig ist. Das Problem kann durch das Verschieben der Ziel-VM in dieses Overlay-Segment behoben werden. |
4.2.0 |
| vni_tag_mismatch_tx_mcast |
Anzahl der Multicast-Pakete, die aufgrund einer VNI-Tag-Nichtübereinstimmung verworfen wurden. Der Host-Switch sucht auf Basis der Zieladresse des Pakets einen Eintrag in seiner Suchtabelle. Beim Versuch, das Paket von einem Port aus weiterzuleiten, treten diese Verwerfungen auf, wenn das VNI-Tag eines Pakets gemäß der VNI-Richtlinie des Segments nicht zulässig ist. Das Problem kann durch das Verschieben der Ziel-VM in dieses Overlay-Segment behoben werden. |
4.2.0 |
