Cette documentation de référence décrit les différentes statistiques collectées à partir des nœuds de transport hôtes ESXi dans votre déploiement NSX.

La première section de ce document décrit les statistiques du nœud de transport hôte qui sont visibles dans l'interface utilisateur NSX Manager.

Les sections restantes de ce document décrivent les statistiques collectées par les différents modules de chemin de données qui s'exécutent dans les nœuds de transport hôtes ESXi. Pour afficher ces statistiques, vous devez utiliser les API NSX ou NSX Central CLI. La colonne Statistiques dans ces sections fait référence au nom de la statistique, comme indiqué dans la sortie de l'API. Pour en savoir plus sur le workflow d'API permettant d'afficher les statistiques du nœud de transport hôte, reportez-vous à la section Surveiller les statistiques des nœuds de transport hôtes NSX à l'aide d'API.

Onglet Statistiques du chemin de données

Cet onglet affiche les valeurs agrégées des statistiques d'un nœud de transport hôte dans l'interface utilisateur NSX Manager.

Statistiques Description Version introduite

Paquets de diffusion reçus

Taux de paquets de diffusion reçus par le VDS de la machine virtuelle. Cette statistique est mappée en interne à la statistique - rxbcastpkts.

 4.2.0

Paquets de diffusion transmis

Taux de paquets de diffusion envoyés par le VDS à la machine virtuelle. Cette statistique est mappée en interne à la statistique - txbcastpkts.

 4.2.0

Abandons de paquets limitant le taux de diffusion

Nombre de paquets entrants ou sortants abandonnés en fonction de la limite de débit de diffusion.

Des limites de débit sont utilisées pour protéger le réseau ou les machines virtuelles d'événements, tels que les tempêtes de diffusion. Vous pouvez configurer des valeurs de limite de débit dans l'interface utilisateur NSX Manager dans Mise en réseau > Segments > Profil de segment > Sécurité du segment.

Cette statistique correspond en interne à ces statistiques détaillées : rx_rate_limit_bcast_drops, rx_rate_limit_mcast_drops, tx_rate_limit_bcast_drops, tx_rate_limit_mcast_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

DFW

Nombre total de paquets abandonnés par le module DFW pour diverses raisons.

Cliquez sur le lien Chemin de données NSX dans l'interface utilisateur pour comprendre les détails des abandons.

 4.2.0

Chemin de données L3

Nombre total de paquets abandonnés par le module L3 du chemin de données pour diverses raisons.

Cliquez sur le lien Chemin de données NSX dans l'interface utilisateur pour comprendre les détails des abandons.

 4.2.0

Erreur de système du chemin de données

Nombre total de paquets abandonnés en raison d'erreurs système internes critiques. Si ces statistiques augmentent de manière cohérente, cela signifie que l'hôte ESXi manque de ressources. Le déplacement de certaines machines virtuelles vers d'autres hôtes peut faciliter la charge.

Cette statistique correspond en interne à ces statistiques détaillées : leaf_rx_system_err_drops, uplink_rx_system_err_drops, pkt_attr_error_drops, tx_dispatch_queue_too_long_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Chemin rapide

Nombre total de paquets abandonnés par le module Fastpath pour diverses raisons.

Cliquez sur le lien Chemin de données NSX dans l'interface utilisateur pour comprendre les détails des abandons.

 4.2.0

Réussite du flux du chemin d'accès rapide

Taux de correspondances de la table de flux dans le module ENS/cache de flux. Cette statistique est mappée en interne à la statistique - correspondances.

 4.2.0

Échec du flux du chemin d'accès rapide

Taux de paquets traités par le chemin lent en raison d'un échec de flux. Cette statistique ne chevauche pas celle de la ligne suivante. Cette statistique est mappée en interne à la statistique - échec.

 4.2.0

Abandons de paquets du chemin d'accès rapide

Nombre total de paquets abandonnés par le chemin d'accès rapide du cache de flux, dans la direction de réception ou de transmission à tous les ports.

Cette statistique correspond en interne à ces statistiques détaillées : rx_drops, tx_drops, rx_drops_uplink, tx_drops_uplink, rx_drops_sp, tx_drops_sp. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets de limite de propagation de pare-feu

Nombre de paquets abandonnés en raison de divers protocoles qui dépassent la limite. Une limite de propagation est configurée pour différents protocoles dans l'interface du noyau.

Cette statistique est mappée en interne à ces statistiques détaillées : udp_flood_overlimit_drops, tcp_flood_overlimit_drops, icmp_flood_overlimit_drops, other_flood_overlimit_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets d'erreurs internes de pare-feu

Nombre de paquets abandonnés par le pare-feu en raison d'erreurs internes.

Cette statistique correspond en interne à ces statistiques détaillées : memory_drops, state_insert_drops, l7_attr_error_drops, lb_reject_drops, src_limit_misc. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets incorrects du pare-feu

Nombre de paquets incorrects abandonnés par le pare-feu.

Cette statistique correspond en interne à ces statistiques détaillées : fragment_drops, short_drops, normalize_drops, bad_timestamp_drops, proto_cksum_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Rejets de paquets de pare-feu

Nombre de paquets rejetés par le pare-feu pour diverses raisons.

Cette statistique correspond en interne à ces statistiques détaillées : rx_ipv4_reject_pkts, tx_ipv4_reject_pkts, rx_ipv6_reject_pkts, tx_ipv6_reject_pkts. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets reçus pour la règle de pare-feu

Nombre de paquets reçus abandonnés par abandon ou rejet de la règle de pare-feu distribué.

Cette statistique est mappée en interne à la statistique - match_drop_rule_rx_drops.

 4.2.0

Abandons de paquets transmis par la règle de pare-feu

Nombre de paquets transmis abandonnés en atteignant l'abandon ou le rejet de la règle de pare-feu distribué.

Cette statistique est mappée en interne à la statistique - match_drop_rule_tx_drops.

 4.2.0

Abandons de paquets de vérification de l'état du pare-feu

Nombre de paquets abandonnés en raison de vérifications liées à l'état.

Ces statistiques correspondent en interne à ces statistiques détaillées : 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. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets complets de la table d'état du pare-feu

Nombre de paquets abandonnés en raison de la limite maximale d'états atteinte. Par exemple, si le nombre d'états TCP est supérieur à la limite, cela entraîne une baisse. Cette statistique est mappée en interne à la statistique - state_limit_drops.

 4.2.0

Nombre total d'abandons de paquets du pare-feu

Nombre total de paquets abandonnés par le pare-feu pour diverses raisons.

Ces statistiques correspondent en interne à ces statistiques détaillées : 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. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets d'incompatibilité de réseau de commutateur hôte

Nombre de paquets de monodiffusion, de multidiffusion et de diffusion abandonnés en raison d'une incompatibilité de balise VNI ou VLAN.

Cette statistique correspond en interne à ces statistiques détaillées : 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. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Le commutateur hôte a reçu de faux abandons de paquets MAC

Nombre de paquets abandonnés en tant qu'abandons forgés en raison de la différence de l'adresse MAC source du paquet par rapport à l'adresse MAC de l'adaptateur de machine virtuelle.

Les transmissions forgées ou la désactivation de l'apprentissage MAC sur le segment entraînent ces abandons. L'activation de l'apprentissage MAC ou des transmissions forgées sur le segment devrait atténuer le problème.

Cette statistique est mappée en interne à la statistique - forged_transmit_rx_drops.

 4.2.0

Abandons de paquets de limite de tronçons L3

Nombre de paquets IPv4 ou IPv6 abandonnés en raison d'une TTL faible (durée de vie). Chaque instance de routeur logique déduira 1 de la valeur TTL. Utilisez la capture de paquets pour déterminer quels paquets ont des valeurs TTL faibles.

Cette statistique est mappée en interne à ces statistiques détaillées : ttl_ip4_drops, ttl_ipv6_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets inaccessibles du voisin L3

Nombre de paquets IPv4 ou IPv6 abandonnés en raison de l'échec de la résolution de voisin.

Cette statistique est mappée en interne à ces statistiques détaillées : arp_hold_pkt_drops, ns_hold_pkt_drops.

 4.2.0

Abandons de paquets sans route L3

Chaque instance de routeur logique dispose de sa propre table de routage pour les recherches d'itinéraires. Cette statistique augmente lorsque des paquets IPv4 sont abandonnés en raison de l'absence de routes correspondantes pour cette instance de routeur logique.

Cette statistique est mappée en interne à ces statistiques détaillées : no_route_ipv4_drops, no_route_ipv6_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets de transfert de chemin inverse L3

Nombre de paquets IPv4 ou IPv6 abandonnés en raison d'un échec de la vérification du transfert de chemin inverse. Le routeur distribué peut vérifier si l'adresse IP source des paquets provient d'une source valide (accessible) et peut abandonner les paquets en fonction de la configuration.

Vous pouvez modifier ce paramètre dans l'interface utilisateur NSX Manager.

Cette statistique est mappée en interne à ces statistiques détaillées : rpf_ipv4_drops, rpf_ipv6_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Tableau d'apprentissage Mac complet

Taux d'abandons de paquets en raison d'échecs de mise à jour de la table MAC au moment de l'apprentissage MAC à partir du plan de contrôle central (CCP) ou pour les paquets reçus du réseau de sous-couche.

Vérifiez si la table MAC est pleine sur le nœud de transport hôte à l'aide de la commande suivante :

$ nsxcli -c "get segment mac-table"

Si nécessaire, augmentez la taille de la table MAC.

Cette statistique correspond en interne à ces statistiques détaillées : mac_tbl_update_full, mac_tbl_lookup_full. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Paquets de multidiffusion reçus

Taux de paquets de multidiffusion reçus par le VDS de la machine virtuelle.

Cette statistique est mappée en interne à la statistique - rx_mcast_pkts.

 4.2.0

Paquets de multidiffusion transmis

Taux de paquets de multidiffusion envoyés par le VDS à la machine virtuelle.

Cette statistique est mappée en interne à la statistique - tx_mcast_pkts.

 4.2.0

Chemin de données de superposition L2

Nombre total de paquets abandonnés par le module de couche 2 du chemin de données de superposition pour diverses raisons.

Cliquez sur le lien Chemin de données NSX dans l'interface utilisateur pour comprendre les détails des abandons.

 4.2.0

Chemin de données de superposition transmis à la liaison montante

Taux de paquets de monodiffusion saturés vers les VTEP distants en raison d'un échec de recherche de la table MAC. Les valeurs grandes impliquent des problèmes de mise à jour de la table MAC ou de flux L2 unidirectionnels.

Vérifiez si la table MAC est pleine sur le nœud de transport hôte à l'aide de la commande suivante :

$ nsxcli -c "get segment mac-table"

Si nécessaire, augmentez la taille de la table MAC.

Cette statistique est mappée en interne à la statistique - mac_tbl_lookup_flood.

 4.2.0

Résolution de voisin assistée du plan de contrôle de superposition infructueuse

Taux d'abandon de paquets en raison de l'impossibilité du plan de contrôle d'aider à la résolution du voisin. Cela peut être dû au fait que CCP n'a pas encore appris le mappage IP-MAC ou que le système ne dispose pas de ressources de tampon de paquets.

Cette statistique correspond en interne à ces statistiques détaillées : 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. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets reçus par la superposition

Nombre d'abandons de paquets dans VDL2LeafInput pour différentes raisons. Reportez-vous aux motifs d'abandon de l'autre feuille reçue pour identifier la raison spécifique des abandons.

Cette statistique est mappée en interne à ces statistiques détaillées : leaf_rx_ref_port_not_found_drops, leaf_rx_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets transmis par la superposition

Nombre total d'abandons sur VDL2LeafOutput pour diverses raisons. Reportez-vous aux autres raisons d'abandon transmises par la feuille pour identifier la raison spécifique des abandons.

Cette statistique est mappée en interne à la statistique - leaf_tx_drops.

 4.2.0

Abandons de paquets reçus par la liaison montante de superposition

Nombre de paquets abandonnés au niveau de VDL2UplinkInput pour diverses raisons. Reportez-vous aux autres raisons d'abandon de liaison montante reçues pour identifier la raison spécifique des abandons.

Cette statistique correspond en interne à ces statistiques détaillées : uplink_rx_drops, uplink_rx_guest_vlan_drops, uplink_rx_invalid_encap_drops, mcast_proxy_rx_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets transmis par la liaison montante de superposition

Nombre total d'abandons de paquets dans VDL2UplinkOutput pour différentes raisons. Reportez-vous aux autres raisons d'abandon transmises par la liaison montante pour identifier la raison spécifique des abandons.

Cette statistique correspond en interne à ces statistiques détaillées : uplink_tx_drops, nested_tn_mcast_proxy_same_vlan_tx_drops, nested_tn_mcast_proxy_diff_vlan_tx_drops, mcast_poxy_tx_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

PNIC reçue (Mbits/s)

Mégabits reçus par seconde. Cette statistique est mappée en interne à la statistique - rxmbps.

 4.2.0

PNIC reçue (pps)

Paquets reçus par seconde. Cette statistique est mappée en interne à la statistique - rxpps.

Abandons reçus par PNIC
Erreurs reçues par seconde. Une valeur non nulle indique généralement les deux cas suivants :
  1. La taille de l'anneau RX de la PNIC est trop petite et l'anneau peut être facilement rempli en raison d'un pic de charge de travail. Vous pouvez envisager d'augmenter la taille de l'anneau.
  2. Le débit de paquets est trop élevé pour que l'invité gère. L'invité ne peut pas extraire des paquets de l'anneau RX de la PNIC, ce qui entraîne des abandons de paquets.

Cette statistique est mappée en interne à la statistique - rxeps.

 4.2.0

PNIC transmise (Mbits/s)

Mégabits transmis par seconde. Cette statistique est mappée en interne à la statistique - txmbps

 4.2.0

PNIC transmise (pps)

Paquets transmis par seconde. Cette statistique est mappée en interne à la statistique - txpps.

 4.2.0

Abandons transmis par PNIC

Erreurs transmises par seconde. Cette statistique est mappée en interne à la statistique - txeps.

 4.2.0

PNIC

Nombre de cartes réseau physiques. Cette statistique est mappée en interne à la statistique - num_pnics.

 4.2.0

Abandons d'erreur d'analyse de paquets

Nombre de paquets Neighbor Discovery (ND) IPv6 qui n'ont pas été correctement analysés. Recherchez les messages d'erreur dans les journaux. Effectuez des captures de paquets au niveau du port pour déterminer si les paquets sont incorrects.

Cette statistique est mappée en interne à la statistique - nd_parse_errors.

 4.2.0

Slowpath uniquement

Taux de paquets qui sont toujours traités en chemin lent selon la conception. Par exemple, le paquet de diffusion.

Cette statistique est mappée en interne à la statistique - chemin lent.

 4.2.0

Abandons de paquets de protection contre l'usurpation

Nombre de paquets IPv4/IPv6/ARP abandonnés par SpoofGuard. SpoofGuard protège contre l'usurpation d'adresse IP en conservant une table de référence des noms et des adresses IP de la machine virtuelle/MAC. Cette valeur sera incrémentée uniquement si SpoofGuard est activé sur le segment ou le port de segment.

Cette statistique est mappée en interne à ces statistiques détaillées : spoof_guard_ipv4_drops, spoof_guard_arp_drops, spoof_guard_ipv6_drops, spoof_guard_nd_drops spoof_guard_non_ip_drops. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Sécurité de commutateur

Nombre total de paquets abandonnés par le module Sécurité des commutateurs pour diverses raisons. Cliquez sur le lien Chemin de données NSX dans l'interface utilisateur pour comprendre les détails des abandons.

 4.2.0

Point de terminaison de tunnel inconnu

Taux d'abandons de paquets pour lequel l'adresse MAC externe source ne peut pas être apprise, car l'étiquette GENEVE entrante est inconnue.

Des valeurs élevées de cette statistique peuvent pointer vers des mises à jour VTEP distantes manquantes sur le nœud de transport à partir du plan de contrôle. Utilisez l'interface de ligne de commande pour vérifier la table VTEP distante sur le nœud de transport.

Cette statistique est mappée en interne à la statistique - uplink_rx_skip_mac_learn.

 4.2.0

VNIC reçue (Mbits/s)

Mégabits reçus par seconde. Cette statistique est mappée en interne à la statistique - rxmbps.

 4.2.0

VNIC reçue (pps)

Paquets reçus par seconde. Cette statistique est mappée en interne à la statistique - rxpps.

 4.2.0

Abandons reçus par VNIC
Erreurs reçues par seconde. Une valeur non nulle indique généralement les deux cas suivants :
  1. La taille de l'anneau RX de la VNIC est trop petite et l'anneau peut être facilement rempli en raison d'un pic de charge de travail. Vous pouvez envisager d'augmenter la taille de l'anneau.
  2. Le débit de paquets est trop élevé pour que l'invité gère. L'invité ne peut pas extraire des paquets de l'anneau RX de la VNIC, ce qui entraîne des abandons de paquets.

Cette statistique est mappée en interne à la statistique - rxeps.

 4.2.0

VNIC transmise (Mbits/s)

Mégabits transmis par seconde. Cette statistique est mappée en interne à la statistique - txmbps.

 4.2.0

VNIC transmise (pps)

Paquets transmis par seconde. Cette statistique est mappée en interne à la statistique - txpps.

 4.2.0

Abandons transmis par VNIC
Erreurs transmises par seconde. Une valeur non nulle indique généralement ce qui suit :
  • Le débit de paquets est trop élevé pour que la liaison montante gère.
  • La liaison montante ne peut pas extraire des paquets de la file d'attente de la pile réseau, ce qui entraîne des abandons de paquets.

Cette statistique est mappée en interne à la statistique - txeps.

 4.2.0

vNIC

Nombre de cartes réseau virtuelles. Cette statistique est mappée en interne à la statistique - num_vnics.

 4.2.0

Abandons de paquets de filtre BPDU de charge de travail

Nombre de paquets abandonnés par le filtrage BPDU. Lorsque le filtre BPDU est activé, le trafic vers les adresses MAC de destination du BPDU est abandonné.

Cette statistique est mappée en interne à la statistique - bpdu_filter_drops.

 4.2.0

Abandons de paquets DHCP non autorisés

Nombre de paquets DHCPv4 ou DHCPv6 abandonnés par le bloc client/serveur DHCP.

Cette statistique est mappée en interne à ces statistiques détaillées : 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. Pour plus de détails, reportez-vous aux définitions de statistiques individuelles.

 4.2.0

Abandons de paquets de protection des annonces du routeur IPv6 de charge de travail

Nombre de paquets d'annonce du routeur IPv6 abandonnés par RA Guard. La fonctionnalité RA Guard filtre les annonces du routeur IPv6 (type ICMPv6 134) transmises à partir des machines virtuelles. Dans un déploiement IPv6, les routeurs reçoivent périodiquement des messages d'annonce du routeur multidiffusion, qui sont utilisés par les hôtes pour la configuration automatique.

Vous pouvez utiliser RA Guard pour protéger votre réseau contre les messages RA non autorisés générés par des routeurs non autorisés ou mal configurés se connectant au segment de réseau. Vous pouvez configurer RA Guard dans l'interface utilisateur NSX Manager à l'adresse Mise en réseau > Segments > Profil de segment > Sécurité du segment.

Cette statistique est mappée en interne à la statistique - ra_guard_drops.

 4.2.0

vSwitch

Nombre total de paquets abandonnés par le module vSwitch pour diverses raisons.

Cliquez sur le lien Chemin de données NSX dans l'interface utilisateur pour comprendre les détails des abandons.

vSwitch reçu de la liaison montante

Taux de paquets reçus d'une ou de plusieurs liaisons montantes vers le vSwitch qui sont monodiffusion inconnues saturées vers d'autres ports du même domaine de diffusion par le vSwitch.

Cette statistique augmente lorsque des paquets monodiffusion inconnus sont saturés en présence de segments ou de ports de réception activés pour l'apprentissage MAC. Une saturation de monodiffusion inconnue se produit lorsque l'adresse MAC de destination du paquet est introuvable dans la table d'adresses MAC de vSwitch.

Cette statistique augmente lorsqu'une adresse MAC de destination sort de la table d'adresses MAC en présence de l'apprentissage MAC. Cette statistique est mappée en interne à la statistique - unknown_unicast_rx_uplink_pkts.

 4.2.0

vSwitch transmis à la liaison montante

Taux de paquets monodiffusion inconnus saturés par le vSwitch vers une ou plusieurs liaisons montantes.

Les statistiques s'incrémentent lorsque des paquets monodiffusion inconnus sont saturés en présence de segments ou de ports de réception activés pour l'apprentissage MAC. Une saturation de monodiffusion inconnue se produit lorsque l'adresse MAC de destination du paquet est introuvable dans la table d'adresses MAC de vSwitch.

Cette statistique augmente lorsqu'une adresse MAC de destination sort de la table d'adresses MAC en présence de l'apprentissage MAC. Cette statistique est mappée en interne à la statistique - unknown_unicast_tx_uplink_pkts.

 4.2.0

Module : host_enhanced_fastpath

Ce module de chemin de données fournit des statistiques d'hôte/d'infrastructure pour le module de chemin de données ENS. Ce module de chemin de données est appelé host-fastpath-ens dans NSX Central CLI.

Statistiques Description Version introduite

flow_table_occupancy_0_pct

Histogramme : nombre de tables de flux avec une utilisation comprise entre 0 et 25 %.

 4.2.0

flow_table_occupancy_25_pct

Histogramme : nombre de tables de flux avec utilisation de 25 à 50 %.

 4.2.0

flow_table_occupancy_50_pct

Histogramme : nombre de tables de flux avec une utilisation de 50 à 75 %.

 4.2.0

flow_table_occupancy_75_pct

Histogramme : nombre de tables de flux avec utilisation de 75 à 90 %.

 4.2.0

flow_table_occupancy_90_pct

Histogramme : nombre de tables de flux avec utilisation de 90 à 95 %. Si le nombre de flux actifs devient supérieur à la taille du tableau de flux, vous pouvez voir une augmentation des échecs de flux, ce qui entraîne une dégradation des performances. Les statistiques de l'histogramme de l'occupation de la table de flux sont utiles pour déterminer si les tables de flux sont saturées.

L'augmentation de la taille de la table de flux n'améliore pas toujours les performances si des connexions de courte durée continuent d'arriver. La table de flux peut être toujours pleine, quelle que soit la taille de la table de flux. Une grande taille de table de flux ne serait pas utile dans ce cas. EDP a une logique pour détecter cela et activer/désactiver automatiquement les tables de flux pour gérer un tel cas.

 4.2.0

flow_table_occupancy_95_pct

Histogramme : nombre de tables de flux avec utilisation de 95 %. Si le nombre de flux actifs devient supérieur à la taille du tableau de flux, vous pouvez voir une augmentation des échecs de flux, ce qui entraîne une dégradation des performances. Les statistiques de l'histogramme de l'occupation de la table de flux sont utiles pour déterminer si les tables de flux sont saturées.

L'augmentation de la taille de la table de flux n'améliore pas toujours les performances si des connexions de courte durée continuent d'arriver. La table de flux peut être toujours pleine, quelle que soit la taille de la table de flux. Une grande taille de table de flux ne serait pas utile dans ce cas. EDP a une logique pour détecter cela et activer/désactiver automatiquement les tables de flux pour gérer un tel cas.

 4.2.0

flow_table_size

Taille maximale de la table de flux dans EDP.

 4.2.0

correspondances

Nombre d'accès à la table de flux dans le module ENS. Cette statistique peut être utilisée pour calculer le taux de réussite/échec/chemin lent du flux ou pour calculer le rapport réussite/échec/chemin lent.

 4.2.0

insertion_errors

Nombre d'erreurs d'insertion de la table de flux. Cela peut se produire lorsqu'une table de flux est pleine (ou presque complète) et qu'il existe des collisions de hachage.

 4.2.0

échec

Paquets traités par le chemin lent en raison d'un échec de flux. Cette statistique ne chevauche pas la statistique à chemin lent décrite plus loin dans ce tableau. Cette statistique peut être utilisée pour calculer le taux de réussite/échec/chemin lent du flux ou pour calculer le rapport réussite/échec/chemin lent.

 4.2.0

num_flow_tables

Nombre de tables de flux utilisées pour EDP. EDP dispose d'une table de flux par thread EDP. Cela est utile pour voir le nombre de tables de flux créées et utilisées.

 4.2.0

num_flows

Nombre de flux dans l'EDP.

 4.2.0

num_flows_created

Nombre de flux créés dans l'EDP. Utilisez cette statistique pour calculer le taux de création de flux, ce qui sera utile pour déterminer les caractéristiques de la charge de travail. Les statistiques de l'histogramme de l'occupation de la table de flux vous indiqueront si les tables de flux sont pleines ou non.

Si le taux de création de flux est faible et qu'il n'y a pas de modification significative des statistiques num_flows ou d'occupation de flux, cela indique que le trafic est stable et dans un état constant. Le nombre de flux actifs reste stable. Si le taux de création de flux est élevé et que num_flows augmente, cela signifie que le nombre de flux actifs augmente. Les tableaux de flux finissent par être saturés si le taux de création de flux ne diminue pas.

Si le taux de création de flux est élevé et que la taille de flux moyenne n'est pas petite, vous devez envisager d'augmenter la taille de la table de flux. Taille moyenne du flux = taux de réussite/taux de num_flows_created.

Une petite valeur pour la taille moyenne de flux signifie que les flux sont de courte durée. Les correspondances et les num_flows_created sont accumulés. Vous pouvez d'abord calculer les valeurs de taux pour obtenir la taille moyenne du flux pendant une période spécifique.

 4.2.0

chemin lent

Paquets qui sont toujours traités en chemin lent par conception. Par exemple, le paquet de diffusion. Cette statistique peut être utilisée pour calculer le taux de réussite/échec/chemin lent du flux ou pour calculer le rapport réussite/échec/chemin lent.

 4.2.0

Module : host_fastpath_ens_lcore

Ce module de chemin de données fournit les statistiques d'utilisation Lcore estimées pour le module ENS. Jusqu'à 16 Lcores classés par utilisation sont affichés. Si moins de 16 Lcores sont configurés, seuls les fichiers Lcore avec des ID valides s'affichent. Ce module de chemin de données est appelé host-fastpath-ens-lcore dans NSX Central CLI.

Statistiques Description Version introduite

lcorerank01_lcoreid

ID du thread de noyau de rang 1 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank01_lcoreusage

Utilisation du CPU du Lcore de rang 1. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank02_lcoreid

ID du thread de noyau de rang 2 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank02_lcoreusage

Utilisation du CPU du Lcore de rang 2. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank03_lcoreid

ID du thread de noyau de rang 3 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank03_lcoreusage

Utilisation du CPU du Lcore de rang 3. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank04_lcoreid

ID du thread de noyau de rang 4 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank04_lcoreusage

Utilisation du CPU du Lcore de rang 4. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank05_lcoreid

ID du thread de noyau de rang 5 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank05_lcoreusage

Utilisation du CPU du Lcore de rang 5. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank06_lcoreid

ID du thread de noyau de rang 6 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank06_lcoreusage

Utilisation du CPU du Lcore de rang 6. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank07_lcoreid

ID du thread de noyau de rang 7 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank07_lcoreusage

Utilisation du CPU du Lcore de rang 7. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank08_lcoreid

ID du thread de noyau de rang 8 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank08_lcoreusage

Utilisation du CPU du Lcore de rang 8. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank09_lcoreid

ID du thread de noyau de rang 9 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank09_lcoreusage

Utilisation du CPU du Lcore de rang 9. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank10_lcoreid

ID du thread de noyau de rang 10 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank10_lcoreusage

Utilisation du CPU de rang 10 Lcore. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank11_lcoreid

ID du thread de noyau de rang 11 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank11_lcoreusage

Utilisation du CPU du Lcore de rang 11. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank12_lcoreid

ID du thread de noyau de rang 12 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank12_lcoreusage

Utilisation du CPU du Lcore de rang 12. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank13_lcoreid

ID du thread de noyau de rang 13 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

lcorerank13_lcoreusage

Utilisation du CPU de rang 13 Lcore. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank14_lcoreid

ID du thread de noyau de rang 14 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank14_lcoreusage

Utilisation du CPU du Lcore de rang 14. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank15_lcoreid

ID du thread de noyau de rang 15 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank15_lcoreusage

Utilisation du CPU de rang 15 Lcore. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank16_lcoreid

ID du thread de noyau de rang 16 pour le mode de performances EDP en termes d'utilisation du CPU. Ne s'affiche que si l'ID est valide.

 4.2.0

lcorerank16_lcoreusage

Utilisation du CPU de rang 16 Lcore. Ne s'affiche que si l'ID est valide.

 4.2.0

Module : host_standard_fastpath

Ce module de chemin de données fournit des statistiques d'hôte/d'infrastructure pour le module de chemin de données du cache de flux hérité. Ce module de chemin de données est appelé host-fastpath-standard dans NSX Central CLI.

Statistiques Description Version introduite

flow_table_occupancy_0_pct

Histogramme : nombre de tables de flux avec une utilisation comprise entre 0 et 25 %.

 4.2.0

flow_table_occupancy_25_pct

Histogramme : nombre de tables de flux avec utilisation de 25 à 50 %.

 4.2.0

flow_table_occupancy_50_pct

Histogramme : nombre de tables de flux avec une utilisation de 50 à 75 %.

 4.2.0

flow_table_occupancy_75_pct

Histogramme : nombre de tables de flux avec utilisation de 75 à 90 %.

 4.2.0

flow_table_occupancy_90_pct

Histogramme : nombre de tables de flux avec utilisation de 90 à 95 %. Si le nombre de flux actifs devient supérieur à la taille du tableau de flux, vous pouvez voir une augmentation des échecs de flux, ce qui entraîne une dégradation des performances. Les statistiques de l'histogramme de l'occupation de la table de flux sont utiles pour déterminer si les tables de flux sont saturées.

L'augmentation de la taille de la table de flux n'améliore pas toujours les performances si des connexions de courte durée continuent d'arriver. La table de flux peut être toujours pleine, quelle que soit la taille de la table de flux. Une grande taille de table de flux ne serait pas utile dans ce cas. EDP a une logique pour détecter cela et activer/désactiver automatiquement les tables de flux pour gérer un tel cas.

 4.2.0

flow_table_occupancy_95_pct

Histogramme : nombre de tables de flux avec utilisation de 95 %. Si le nombre de flux actifs devient supérieur à la taille du tableau de flux, vous pouvez voir une augmentation des échecs de flux, ce qui entraîne une dégradation des performances. Les statistiques de l'histogramme de l'occupation de la table de flux sont utiles pour déterminer si les tables de flux sont saturées.

L'augmentation de la taille de la table de flux n'améliore pas toujours les performances si des connexions de courte durée continuent d'arriver. La table de flux peut être toujours pleine, quelle que soit la taille de la table de flux. Une grande taille de table de flux ne serait pas utile dans ce cas. EDP a une logique pour détecter cela et activer/désactiver automatiquement les tables de flux pour gérer un tel cas.

 4.2.0

flow_table_size

Taille maximale de la table de flux dans EDP.

 4.2.0

correspondances

Nombre d'accès à la table de flux dans le module ENS. Cette statistique peut être utilisée pour calculer le taux de réussite/échec/chemin lent du flux ou pour calculer le rapport réussite/échec/chemin lent.

 4.2.0

insertion_errors

Nombre d'erreurs d'insertion de la table de flux. Cela peut se produire lorsqu'une table de flux est pleine (ou presque complète) et qu'il existe des collisions de hachage.

 4.2.0

échec

Paquets traités par le chemin lent en raison d'un échec de flux. Cette statistique ne chevauche pas la statistique à chemin lent décrite plus loin dans ce tableau. Cette statistique peut être utilisée pour calculer le taux de réussite/échec/chemin lent du flux ou pour calculer le rapport réussite/échec/chemin lent.

 4.2.0

num_flow_tables

Nombre de tables de flux utilisées pour EDP. EDP dispose d'une table de flux par thread EDP. Cela est utile pour voir le nombre de tables de flux créées et utilisées.

 4.2.0

num_flows

Nombre de flux dans l'EDP.

 4.2.0

num_flows_created

Nombre de flux créés dans l'EDP. Utilisez cette statistique pour calculer le taux de création de flux, ce qui sera utile pour déterminer les caractéristiques de la charge de travail. Les statistiques de l'histogramme de l'occupation de la table de flux vous indiqueront si les tables de flux sont pleines ou non.

Si le taux de création de flux est faible et qu'il n'y a pas de modification significative des statistiques num_flows ou d'occupation de flux, cela indique que le trafic est stable et dans un état constant. Le nombre de flux actifs reste stable. Si le taux de création de flux est élevé et que num_flows augmente, cela signifie que le nombre de flux actifs augmente. Les tableaux de flux finissent par être saturés si le taux de création de flux ne diminue pas.

Si le taux de création de flux est élevé et que la taille de flux moyenne n'est pas petite, vous devez envisager d'augmenter la taille de la table de flux. Taille moyenne du flux = taux de réussite/taux de num_flows_created.

Une petite valeur pour la taille moyenne de flux signifie que les flux sont de courte durée. Les correspondances et les num_flows_created sont accumulés. Vous pouvez d'abord calculer les valeurs de taux pour obtenir la taille moyenne du flux pendant une période spécifique.

 4.2.0

chemin lent

Paquets qui sont toujours traités en chemin lent par conception. Par exemple, le paquet de diffusion. Cette statistique peut être utilisée pour calculer le taux de réussite/échec/chemin lent du flux ou pour calculer le rapport réussite/échec/chemin lent.

 4.2.0

Module : host_net_thread_nioc

Ce module de chemin de données fournit des statistiques de thread réseau liées à NIOC. Ce module de chemin de données est appelé host-net-thread-nioc dans NSX Central CLI.

Statistiques Description Version introduite

hist_0_pct

Histogramme : nombre de threads compris entre 0 % et 25 %

 4.2.0

hist_25_pct

Histogramme : nombre de threads compris entre 25 % et 50 %

 4.2.0

hist_50_pct

Histogramme : nombre de threads compris entre 50 % et 70 %

 4.2.0

hist_70_pct

Histogramme : nombre de threads compris entre 70 % et 80 %

 4.2.0

hist_80_pct

Histogramme : nombre de threads compris entre 80 % et 85 %

 4.2.0

hist_85_pct

Histogramme : nombre de threads compris entre 85 % et 90 %

 4.2.0

hist_90_pct

Histogramme : nombre de threads compris entre 90 % et 95 %

 4.2.0

hist_95_pct

Histogramme : nombre de threads compris entre 95 % et 97 %

 4.2.0

hist_97_pct

Histogramme : nombre de threads compris entre 97 % et 99 %

 4.2.0

hist_99_pct

Histogramme : nombre de threads avec utilisation >99 %.

Les problèmes de chemin de données réseau sont exprimés sous la forme de trois symptômes : abandons de paquets, débit faible et latence élevée. Bien que ces symptômes soient partagés par des problèmes fonctionnels et de performances, ils sont le plus souvent dus à des problèmes liés aux performances. Il est essentiel d'écarter si le problème est lié ou non au rendement à un stade précoce de l'enquête.

Dans la mise en réseau définie par logiciel spécialement basée sur la virtualisation, le CPU est la ressource la plus critique qui affecte les performances du réseau. Avec des cartes réseau plus rapides disponibles sur le marché, la bande passante réseau devient rarement un goulot d'étranglement.

Le traitement des paquets dans le chemin de données implique généralement un ensemble de threads exécutés dans un pipeline, associés à des files d'attente et des tampons qui contiennent des paquets. Lorsqu'un thread dans le pipeline, des vCPU aux threads réseau du noyau est surchargé, les files d'attente et les tampons correspondants peuvent être pleins, ce qui entraîne des abandons de paquets. Cela limite le débit.

Il est essentiel de surveiller l'utilisation du CPU des threads réseau du noyau en plus des statistiques réseau traditionnelles. Au lieu d'utiliser des nombres d'utilisation de CPU pour des threads individuels, nous les groupons et générons un histogramme. Ensuite, vous pouvez surveiller les bacs d'histogramme comme 90pct, 95pct, 97pct, 99pct, qui vous indiquent combien de threads de mise en réseau sont dans un goulot d'étranglement. La statistique total_CPU est également utile pour indiquer combien de temps CPU est consacré au traitement des paquets dans le noyau.

 4.2.0

max_cpu

Utilisation maximale du CPU de thread

 4.2.0

min_cpu

Utilisation minimale du CPU du thread

 4.2.0

num_threads

Nombre de threads utilisés pour la livraison de paquets du planificateur de paquets NetIOC à la liaison montante.

 4.2.0

total_cpu

Somme de l’utilisation du CPU de tous les threads réseau dans le groupe. Le CPU total est utile pour afficher les distributions globales d'utilisation du CPU entre les différents groupes de threads et les machines virtuelles.

 4.2.0

Module : host_net_thread_rx

Ce module de chemin de données fournit des statistiques de thread réseau liées à RX. Ce module de chemin de données est appelé host-net-thread-rx dans NSX Central CLI.

Statistiques Description Version introduite

hist_0_pct

Histogramme : nombre de threads compris entre 0 % et 25 %

 4.2.0

hist_25_pct

Histogramme : nombre de threads compris entre 25 % et 50 %

 4.2.0

hist_50_pct

Histogramme : nombre de threads compris entre 50 % et 70 %

 4.2.0

hist_70_pct

Histogramme : nombre de threads compris entre 70 % et 80 %

 4.2.0

hist_80_pct

Histogramme : nombre de threads compris entre 80 % et 85 %

 4.2.0

hist_85_pct

Histogramme : nombre de threads compris entre 85 % et 90 %

 4.2.0

hist_90_pct

Histogramme : nombre de threads compris entre 90 % et 95 %

 4.2.0

hist_95_pct

Histogramme : nombre de threads compris entre 95 % et 97 %

 4.2.0

hist_97_pct

Histogramme : nombre de threads compris entre 97 % et 99 %

 4.2.0

hist_99_pct

Histogramme : nombre de threads avec utilisation >99 %.

Les problèmes de chemin de données réseau sont exprimés sous la forme de trois symptômes : abandons de paquets, débit faible et latence élevée. Bien que ces symptômes soient partagés par des problèmes fonctionnels et de performances, ils sont le plus souvent dus à des problèmes liés aux performances. Il est essentiel d'écarter si le problème est lié ou non au rendement à un stade précoce de l'enquête.

Dans la mise en réseau définie par logiciel spécialement basée sur la virtualisation, le CPU est la ressource la plus critique qui affecte les performances du réseau. Avec des cartes réseau plus rapides disponibles sur le marché, la bande passante réseau devient rarement un goulot d'étranglement.

Le traitement des paquets dans le chemin de données implique généralement un ensemble de threads exécutés dans un pipeline, associés à des files d'attente et des tampons qui contiennent des paquets. Lorsqu'un thread dans le pipeline, des vCPU aux threads réseau du noyau est surchargé, les files d'attente et les tampons correspondants peuvent être pleins, ce qui entraîne des abandons de paquets. Cela limite le débit.

Il est essentiel de surveiller l'utilisation du CPU des threads réseau du noyau en plus des statistiques réseau traditionnelles. Au lieu d'utiliser des nombres d'utilisation de CPU pour des threads individuels, nous les groupons et générons un histogramme. Ensuite, vous pouvez surveiller les bacs d'histogramme comme 90pct, 95pct, 97pct, 99pct, qui vous indiquent combien de threads de mise en réseau sont dans un goulot d'étranglement. La statistique total_CPU est également utile pour indiquer combien de temps CPU est consacré au traitement des paquets dans le noyau.

 4.2.0

max_cpu

Utilisation maximale du CPU de thread

 4.2.0

min_cpu

Utilisation minimale du CPU du thread

 4.2.0

num_threads

Nombre de threads utilisés pour la livraison de paquets du planificateur de paquets NetIOC à la liaison montante.

 4.2.0

total_cpu

Somme de l’utilisation du CPU de tous les threads réseau dans le groupe. Le CPU total est utile pour afficher les distributions globales d'utilisation du CPU entre les différents groupes de threads et les machines virtuelles.

 4.2.0

Module : host_net_thread_tx

Ce module de chemin de données fournit des statistiques de thread réseau liées à TX. Ce module de chemin de données est appelé host-net-thread-txhost-net-thread-tx dans NSX Central CLI.

Statistiques Description Version introduite

hist_0_pct

Histogramme : nombre de threads compris entre 0 % et 25 %

 4.2.0

hist_25_pct

Histogramme : nombre de threads compris entre 25 % et 50 %

 4.2.0

hist_50_pct

Histogramme : nombre de threads compris entre 50 % et 70 %

 4.2.0

hist_70_pct

Histogramme : nombre de threads compris entre 70 % et 80 %

 4.2.0

hist_80_pct

Histogramme : nombre de threads compris entre 80 % et 85 %

 4.2.0

hist_85_pct

Histogramme : nombre de threads compris entre 85 % et 90 %

 4.2.0

hist_90_pct

Histogramme : nombre de threads compris entre 90 % et 95 %

 4.2.0

hist_95_pct

Histogramme : nombre de threads compris entre 95 % et 97 %

 4.2.0

hist_97_pct

Histogramme : nombre de threads compris entre 97 % et 99 %

 4.2.0

hist_99_pct

Histogramme : nombre de threads avec utilisation >99 %.

Les problèmes de chemin de données réseau sont exprimés sous la forme de trois symptômes : abandons de paquets, débit faible et latence élevée. Bien que ces symptômes soient partagés par des problèmes fonctionnels et de performances, ils sont le plus souvent dus à des problèmes liés aux performances. Il est essentiel d'écarter si le problème est lié ou non au rendement à un stade précoce de l'enquête.

Dans la mise en réseau définie par logiciel spécialement basée sur la virtualisation, le CPU est la ressource la plus critique qui affecte les performances du réseau. Avec des cartes réseau plus rapides disponibles sur le marché, la bande passante réseau devient rarement un goulot d'étranglement.

Le traitement des paquets dans le chemin de données implique généralement un ensemble de threads exécutés dans un pipeline, associés à des files d'attente et des tampons qui contiennent des paquets. Lorsqu'un thread dans le pipeline, des vCPU aux threads réseau du noyau est surchargé, les files d'attente et les tampons correspondants peuvent être pleins, ce qui entraîne des abandons de paquets. Cela limite le débit.

Il est essentiel de surveiller l'utilisation du CPU des threads réseau du noyau en plus des statistiques réseau traditionnelles. Au lieu d'utiliser des nombres d'utilisation de CPU pour des threads individuels, nous les groupons et générons un histogramme. Ensuite, vous pouvez surveiller les bacs d'histogramme comme 90pct, 95pct, 97pct, 99pct, qui vous indiquent combien de threads de mise en réseau sont dans un goulot d'étranglement. La statistique total_CPU est également utile pour indiquer combien de temps CPU est consacré au traitement des paquets dans le noyau.

 4.2.0

max_cpu

Utilisation maximale du CPU de thread

 4.2.0

min_cpu

Utilisation minimale du CPU du thread

 4.2.0

num_threads

Nombre de threads utilisés pour la livraison de paquets du planificateur de paquets NetIOC à la liaison montante.

 4.2.0

total_cpu

Somme de l’utilisation du CPU de tous les threads réseau dans le groupe. Le CPU total est utile pour afficher les distributions globales d'utilisation du CPU entre les différents groupes de threads et les machines virtuelles.

 4.2.0

Module : host_pcpu

Ce module de chemin de données fournit l'utilisation des CPU physiques. Ce module de chemin de données est appelé host-pcpuhost-pcpu dans NSX Central CLI.

Statistiques Description Version introduite

hist_0_pct

Histogramme : nombre de CPU compris entre 0 % et 50 %

 4.2.0

hist_50_pct

Histogramme : nombre de CPU compris entre 50 % et 70 %

 4.2.0

hist_75_pct

Histogramme : nombre de CPU compris entre 75 % et 85 %

 4.2.0

hist_85_pct

Histogramme : nombre de CPU compris entre 85 % et 90 %

 4.2.0

hist_90_pct

Histogramme : nombre de CPU compris entre 90 % et 95 %

 4.2.0

hist_95_pct

Histogramme : nombre de CPU compris entre 95 % et 100 %

 4.2.0

total_cpu

Utilisation totale du CPU de l'hôte. Somme de l'utilisation de tous les cœurs de CPU sur l'hôte.

Les problèmes de chemin de données réseau sont exprimés sous la forme de trois symptômes : abandons de paquets, débit faible et latence élevée. Bien que ces symptômes soient partagés par des problèmes fonctionnels et de performances, ils sont le plus souvent dus à des problèmes liés aux performances. Il est essentiel d'écarter si le problème est lié ou non au rendement à un stade précoce de l'enquête.

Dans la mise en réseau définie par logiciel spécialement basée sur la virtualisation, le CPU est la ressource la plus critique qui affecte les performances du réseau. Avec des cartes réseau plus rapides disponibles sur le marché, la bande passante réseau devient rarement un goulot d'étranglement.

Le traitement des paquets dans le chemin de données implique généralement un ensemble de threads exécutés dans un pipeline, associés à des files d'attente et des tampons qui contiennent des paquets. Lorsqu'un thread dans le pipeline, des vCPU aux threads réseau du noyau est surchargé, les files d'attente et les tampons correspondants peuvent être pleins, ce qui entraîne des abandons de paquets. Cela limite le débit.

Il est essentiel de surveiller l'utilisation du CPU des threads réseau du noyau en plus des statistiques réseau traditionnelles. Au lieu d'utiliser des nombres d'utilisation de CPU pour des threads individuels, nous les groupons et générons un histogramme. Ensuite, vous pouvez surveiller les bacs d'histogramme comme 90pct, 95pct, 97pct, 99pct, qui vous indiquent combien de threads de mise en réseau sont dans un goulot d'étranglement. La statistique total_CPU est également utile pour indiquer combien de temps CPU est consacré au traitement des paquets dans le noyau.

 4.2.0

Module : host_uplink

Ce module de chemin de données fournit l'utilisation des cartes réseau de liaison montante physique. Ce module de chemin de données est appelé host-uplink dans NSX Central CLI.

Statistiques Description Version introduite

num_pnics

Nombre de cartes réseau physiques

 4.2.0

rx_error_total

Statistiques du pilote : nombre total d'erreurs reçues. En général, cette statistique doit avoir une valeur similaire à rx_missed.

Une valeur non nulle indique généralement deux cas :
  1. La taille de l'anneau RX de la PNIC est trop petite et l'anneau peut être facilement rempli en raison d'un pic de charge de travail. Vous pouvez envisager d'augmenter la taille de l'anneau.
  2. Le débit de paquets est trop élevé pour que l'invité gère. L'invité ne peut pas extraire des paquets de l'anneau RX de la PNIC, ce qui entraîne des abandons de paquets.
 4.2.0

rx_missed

Statistiques du pilote : reçu manqué. En général, cette statistique doit avoir une valeur similaire à rx_error_total.

Une valeur non nulle indique généralement deux cas :
  1. La taille de l'anneau RX de la PNIC est trop petite et l'anneau peut être facilement rempli en raison d'un pic de charge de travail. Vous pouvez envisager d'augmenter la taille de l'anneau.
  2. Le débit de paquets est trop élevé pour que l'invité gère. L'invité ne peut pas extraire des paquets de l'anneau RX de la PNIC, ce qui entraîne des abandons de paquets.
 4.2.0

rxeps

Erreurs reçues par seconde.

Une valeur non nulle indique généralement deux cas :
  1. La taille de l'anneau RX de la PNIC est trop petite et l'anneau peut être facilement rempli en raison d'un pic de charge de travail. Vous pouvez envisager d'augmenter la taille de l'anneau.
  2. Le débit de paquets est trop élevé pour que l'invité gère. L'invité ne peut pas extraire des paquets de l'anneau RX de la PNIC, ce qui entraîne des abandons de paquets.
 4.2.0

rxmbps

Mégabits reçus par seconde

 4.2.0

rxpps

Paquets reçus par seconde

 4.2.0

txeps

Erreurs transmises par seconde

 4.2.0

txmbps

Mégabits transmis par seconde

 4.2.0

txpps

Paquets transmis par seconde

 4.2.0

Module : host_vnic

Ce module de chemin de données fournit l'utilisation des cartes réseau virtuelles. Ce module de chemin de données est appelé host-vNIC dans NSX Central CLI.

Statistiques Description Version introduite

num_vnics

Nombre de cartes réseau virtuelles.

 4.2.0

rxeps

Erreurs reçues par seconde.

Une valeur non nulle indique généralement les deux cas suivants :
  1. La taille de l'anneau RX de la VNIC est trop petite et l'anneau peut être facilement rempli en raison d'un pic de charge de travail. Vous pouvez envisager d'augmenter la taille de l'anneau.
  2. Le débit de paquets est trop élevé pour que l'invité gère. L'invité ne peut pas extraire des paquets de l'anneau RX de la VNIC, ce qui entraîne des abandons de paquets.
 4.2.0

rxmbps

Mégabits reçus par seconde.

 4.2.0

rxpps

Paquets reçus par seconde.

 4.2.0

txeps

Erreurs transmises par seconde.

Une valeur non nulle indique généralement les deux cas suivants :
  1. Le débit de paquets est trop élevé pour que la liaison montante gère.
  2. La liaison montante ne peut pas extraire des paquets de la file d'attente de la pile réseau, ce qui entraîne des abandons de paquets.
 4.2.0

txmbps

Mégabits transmis par seconde.

 4.2.0

txpps

Paquets transmis par seconde.

 4.2.0

Module : host_vcpu

Ce module de chemin de données fournit l'utilisation des CPU virtuels. Ce module de chemin de données est appelé host-vcpu dans NSX Central CLI.

Statistiques Description Version introduite

hist_0_pct

Histogramme : nombre de CPU compris entre 0 % et 50 %.

 4.2.0

hist_50_pct

Histogramme : nombre de CPU compris entre 50 % et 70 %.

 4.2.0

hist_75_pct

Histogramme : nombre de CPU compris entre 75 % et 85 %

 4.2.0

hist_85_pct

Histogramme : nombre de CPU compris entre 85 % et 90 %.

 4.2.0

hist_90_pct

Histogramme : nombre de CPU compris entre 90 % et 95 %.

 4.2.0

hist_95_pct

Histogramme : nombre de CPU compris entre 95 % et 100 %.

Les problèmes de chemin de données réseau sont exprimés sous la forme de trois symptômes : abandons de paquets, débit faible et latence élevée. Bien que ces symptômes soient partagés par des problèmes fonctionnels et de performances, ils sont le plus souvent dus à des problèmes liés aux performances. Il est essentiel d'écarter si le problème est lié ou non au rendement à un stade précoce de l'enquête.

Dans la mise en réseau définie par logiciel spécialement basée sur la virtualisation, le CPU est la ressource la plus critique qui affecte les performances du réseau. Avec des cartes réseau plus rapides disponibles sur le marché, la bande passante réseau devient rarement un goulot d'étranglement.

Le traitement des paquets dans le chemin de données implique généralement un ensemble de threads exécutés dans un pipeline, associés à des files d'attente et des tampons qui contiennent des paquets. Lorsqu'un thread dans le pipeline, des vCPU aux threads réseau du noyau est surchargé, les files d'attente et les tampons correspondants peuvent être pleins, ce qui entraîne des abandons de paquets. Cela limite le débit.

Il est essentiel de surveiller l'utilisation du CPU des threads réseau du noyau en plus des statistiques réseau traditionnelles. Au lieu d'utiliser des nombres d'utilisation de CPU pour des threads individuels, nous les groupons et générons un histogramme. Ensuite, vous pouvez surveiller les compartiments d'histogramme, qui vous indiquent combien de threads de mise en réseau sont dans un goulot d'étranglement. La statistique total_CPU est également utile pour indiquer combien de temps CPU est consacré au traitement des paquets dans le noyau.

 4.2.0

total_cpu

Utilisation totale du vCPU. Somme de l'utilisation CPU de toutes les machines virtuelles sur l'hôte. Le CPU total est utile pour afficher les distributions globales d'utilisation du CPU entre les différents groupes de threads et les machines virtuelles.

 4.2.0

Module : chemin d'accès rapide

Le chemin d'accès rapide inclut des modules de chemin de données de cache de flux (FC) et de pile réseau améliorée (ENS) pour le traitement amélioré des paquets du chemin de données. Ce module de chemin de données est appelé nsxt-fp dans NSX Central CLI.

Statistiques Description Version introduite

rx_bytes

Nombre d'octets reçus par chemin d'accès rapide du cache de flux, dans le sens de réception des ports.

 4.2.0

rx_drops

Nombre de paquets abandonnés par chemin d'accès rapide du cache de flux, dans le sens de réception des ports. Cela ne s'applique pas au cache de flux en mode non-ENS.

 4.2.0

rx_drops_sp

Les paquets reçus sont abandonnés lorsque des paquets sont envoyés au chemin lent à partir du chemin d'accès rapide du cache de flux. Non applicable au cache de flux en mode non-ENS et en mode de commutateur standard.

 4.2.0

rx_drops_uplink

Nombre de paquets abandonnés par le chemin d'accès rapide du cache de flux dans le sens de réception des ports de liaison montante. Non applicable au cache de flux en mode non-ENS et en mode de commutateur standard.

 4.2.0

rx_pkts

Nombre de paquets reçus par chemin d'accès rapide du cache de flux dans la direction de réception des ports.

 4.2.0

rx_pkts_sp

Paquets reçus lorsque des paquets sont envoyés vers le chemin lent à partir du chemin d'accès rapide du cache de flux. Non applicable au cache de flux en mode non-ENS et en mode de commutateur standard.

 4.2.0

rx_pkts_uplink

Nombre de paquets reçus par faspath du cache de flux dans le sens de réception des ports de liaison montante.

 4.2.0

tx_bytes

Nombre d'octets transmis par chemin d'accès rapide du cache de flux dans le sens de transmission aux ports.

 4.2.0

tx_drops

Nombre de paquets abandonnés par chemin d'accès rapide du cache de flux dans la direction de transmission aux ports.

 4.2.0

tx_drops_sp

Les paquets transmis sont abandonnés par fastapth lorsque des paquets sont réinjectés dans le chemin d'accès rapide du cache de flux à partir du chemin lent. Non applicable au cache de flux en mode non-ENS et en mode de commutateur standard.

 4.2.0

tx_drops_uplink

Nombre de paquets abandonnés par chemin d'accès rapide du cache de flux dans le sens de transmission aux ports de liaison montante.

 4.2.0

tx_pkts

Nombre de paquets transmis par chemin d'accès rapide du cache de flux dans le sens de transmission aux ports.

 4.2.0

tx_pkts_sp

Paquets transmis par chemin d'accès rapide lorsque des paquets sont réinjectés dans le chemin d'accès rapide du cache de flux à partir du chemin lent. Non applicable pour le mode de commutateur standard.

 4.2.0

tx_pkts_uplink

Nombre de paquets transmis par chemin d'accès rapide du cache de flux dans le sens de transmission à partir des ports de liaison montante.

 4.2.0

Module : switch_security

Ce module de chemin de données fournit une sécurité L2 et L3 sans état en vérifiant le trafic vers le segment et en abandonnant les paquets non autorisés envoyés à partir de machines virtuelles. Dans ce tableau, Rx fait référence aux paquets reçus « depuis » le commutateur, et Rx fait référence aux paquets envoyés « au » commutateur. Ce module de chemin de données est appelé nsxt-swsec dans NSX Central CLI.

Statistiques Description Version introduite

bpdu_filter_drops

Nombre de paquets abandonnés par le filtrage BPDU. Lorsque le filtre BPDU est activé, le trafic vers les adresses MAC de destination du BPDU est abandonné.

 4.2.0

dhcp_client_block_ipv4_drops

Nombre de paquets DHCP IPv4 abandonnés par le bloc de client DHCP.

Bloc de client DHCP empêche une VM d'acquérir une adresse IP DHCP en bloquant les demandes DHCP. Si cela n'est pas attendu, vous pouvez désactiver le bloc de client DHCPv4 à partir du profil de sécurité de segment d'un segment ou d'un port de segment. Pour effectuer cela dans NSX Manager, accédez à Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

dhcp_client_block_ipv6_drops

Nombre de paquets DHCP IPv6 abandonnés par le bloc de client DHCP.

Bloc de client DHCP empêche une VM d'acquérir une adresse IP DHCP en bloquant les demandes DHCP. Si cela n'est pas attendu, vous pouvez désactiver le bloc de client DHCPv6 à partir du profil de sécurité de segment d'un segment ou d'un port de segment. Pour effectuer cela dans NSX Manager, accédez à Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

dhcp_client_validate_ipv4_drops

Nombre de paquets DHCP IPv4 abandonnés, car les adresses dans la charge utile n'étaient pas valides.

Il est possible qu'une machine virtuelle malveillante sur le réseau tente d'envoyer des paquets DHCP non valides, par exemple sans adresse IP source, adresse matérielle du client ne correspondant pas à l'adresse MAC source, et ainsi de suite.

 4.2.0

dhcp_server_block_ipv4_drops

Nombre de paquets DHCP IPv4 abandonnés par le bloc de serveur DHCP. Bloc de serveur DHCP bloque le trafic entre un serveur DHCP et un client DHCP.

Si cela n'est pas attendu, vous pouvez désactiver le bloc de serveur DHCP à partir du profil de sécurité de segment d'un segment ou d'un port de segment. Pour effectuer cela dans NSX Manager, accédez à Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

dhcp_server_block_ipv6_drops

Nombre de paquets DHCPv6 abandonnés par le bloc de serveur DHCP.

Bloc de serveur DHCP bloque le trafic entre un serveur DHCP et un client DHCP. Si cela n'est pas attendu, vous pouvez désactiver le bloc du serveur DHCPv6 à partir du profil de sécurité de segment d'un segment ou d'un port de segment. Pour effectuer cela dans NSX Manager, accédez à Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

nd_parse_errors

Nombre de paquets IPv6 Neighbor Discovery (ND) qui n'ont pas été correctement analysés.

Recherchez les messages d'erreur dans les journaux. Effectuez des captures de paquets au niveau du port pour déterminer si les paquets sont incorrects.

 4.2.0

ra_guard_drops

Nombre de paquets d'annonce du routeur IPv6 abandonnés par RA Guard.

La fonctionnalité RA Guard filtre les annonces du routeur IPv6 (type ICMPv6 134) transmises à partir des machines virtuelles. Dans un déploiement IPv6, les routeurs reçoivent périodiquement des messages d'annonce du routeur multidiffusion, qui sont utilisés par les hôtes pour la configuration automatique.

Vous pouvez utiliser RA Guard pour protéger votre réseau contre les messages RA non autorisés générés par des routeurs non autorisés ou mal configurés se connectant au segment de réseau. Vous pouvez configurer RA Guard dans l'interface utilisateur NSX Manager à l'adresse Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

rx_arp_pkts

Nombre de paquets ARP reçus par le VDS de la machine virtuelle.

 4.2.0

rx_garp_pkts

Nombre de paquets ARP gratuits (GARP) reçus par le VDS de la machine virtuelle.

 4.2.0

rx_ipv4_pkts

Nombre de paquets IPv4 reçus par le VDS de la machine virtuelle.

 4.2.0

rx_ipv6_pkts

Nombre de paquets IPv6 reçus par le VDS de la machine virtuelle.

 4.2.0

rx_na_pkts

Nombre de paquets IPv6 ND (Neighbor Discovery) NA (Neighbor Advertisement) reçus par le VDS de la machine virtuelle.

 4.2.0

rx_non_ip_pkts

Nombre de paquets non IP reçus par le VDS de la machine virtuelle

 4.2.0

rx_ns_pkts

Nombre de paquets IPv6 ND (Détection des voisins) NS (Sollicitation de voisin) reçus par le VDS de la machine virtuelle.

 4.2.0

rx_rate_limit_bcast_drops

Nombre de paquets entrants abandonnés par la limite de débit de diffusion.

Des limites de débit peuvent être utilisées pour protéger le réseau ou les machines virtuelles d'événements, tels que les tempêtes de diffusion. Vous pouvez configurer des valeurs de limite de débit dans l'interface utilisateur NSX Manager dans Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

rx_rate_limit_mcast_drops

Nombre de paquets entrants abandonnés par la limite de débit de multidiffusion.

Des limites de débit peuvent être utilisées pour protéger le réseau ou les machines virtuelles d'événements, tels que les tempêtes de multidiffusion. Vous pouvez configurer des valeurs de limite de débit dans l'interface utilisateur NSX Manager dans Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

rx_unsolicited_na_pkts

Nombre de paquets IPv6 ND (Neighbor Discovery) NA (Neighbor Advertisement) non sollicités reçus par le VDS de la VM.

 4.2.0

rxbcastpkts

Nombre de paquets de diffusion reçus par le VDS de la machine virtuelle.

 4.2.0

rxmcastpkts

Nombre de paquets de multidiffusion reçus par le VDS de la machine virtuelle.

 4.2.0

spoof_guard_arp_drops

Nombre de paquets ARP abandonnés par SpoofGuard.

SpoofGuard protège contre les attaques d'usurpation ARP malveillantes en gardant une trace des adresses MAC et IP. Cette statistique sera incrémentée uniquement lorsque SpoofGuard est activé sur le segment ou le port de segment. (Mise en réseau > Segments > Profil de segment > SpoofGuard)

 4.2.0

spoof_guard_ipv4_drops

Nombre de paquets IPv4 abandonnés par SpoofGuard.

SpoofGuard protège contre l'usurpation d'adresse IP en conservant une table de référence des noms et des adresses IP de la machine virtuelle. Cette statistique sera incrémentée uniquement lorsque SpoofGuard est activé sur le segment ou le port de segment. (Mise en réseau > Segments > Profil de segment > SpoofGuard)

 4.2.0

spoof_guard_ipv6_drops

Nombre de paquets IPv6 abandonnés par SpoofGuard.

SpoofGuard protège contre l'usurpation d'adresse IP en conservant une table de référence des noms et des adresses IP de la machine virtuelle. Cette statistique sera incrémentée uniquement lorsque SpoofGuard est activé sur le segment ou le port de segment. (Mise en réseau > Segments > Profil de segment > SpoofGuard)

 4.2.0

spoof_guard_nd_drops

Nombre de paquets IPv6 Neighbor Discovery (ND) abandonnés par SpoofGuard.

SpoofGuard protège contre l'usurpation de ND en filtrant les paquets ND dont les adresses ne correspondent pas à l'adresse de la machine virtuelle. Cette statistique sera incrémentée uniquement lorsque SpoofGuard est activé sur le segment ou le port de segment. (Mise en réseau > Segments > Profil de segment > SpoofGuard)

 4.2.0

spoof_guard_non_ip_drops

Nombre de paquets non IP abandonnés par SpoofGuard.

Cette statistique sera incrémentée uniquement lorsque SpoofGuard est activé sur le segment ou le port de segment. (Mise en réseau > Segments > Profil de segment > SpoofGuard)

 4.2.0

tx_arp_pkts

Nombre de paquets ARP envoyés par le VDS à la machine virtuelle.

 4.2.0

tx_ipv4_pkts

Nombre de paquets IPv4 envoyés par le VDS à la machine virtuelle.

 4.2.0

tx_ipv6_pkts

Nombre de paquets IPv6 envoyés par le VDS à la machine virtuelle.

 4.2.0

tx_non_ip_pkts

Nombre de paquets non IP envoyés par le VDS à la machine virtuelle.

 4.2.0

tx_rate_limit_bcast_drops

Nombre de paquets sortants abandonnés par limite de débit de diffusion.

Des limites de débit peuvent être utilisées pour protéger le réseau ou les machines virtuelles d'événements, tels que les tempêtes de diffusion. Vous pouvez configurer des valeurs de limite de débit dans l'interface utilisateur NSX Manager dans Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

tx_rate_limit_mcast_drops

Nombre de paquets sortants abandonnés par la limite de débit de multidiffusion.

Des limites de débit peuvent être utilisées pour protéger le réseau ou les machines virtuelles d'événements, tels que les tempêtes de multidiffusion. Vous pouvez configurer des valeurs de limite de débit dans l'interface utilisateur NSX Manager dans Mise en réseau > Segments > Profil de segment > Sécurité du segment.

 4.2.0

txbcastpkts

Nombre de paquets de diffusion envoyés par le VDS à la machine virtuelle.

 4.2.0

txmcastpkts

Nombre de paquets de multidiffusion envoyés par le VDS à la machine virtuelle.

 4.2.0

Module : overlay_datapath_l2

Ce module de chemin de données est responsable de la connectivité de la charge de travail. Ce module de chemin de données est appelé nsxt-vdl2 dans NSX Central CLI.

Statistiques Description Version introduite

arp_proxy_req_fail_drops

Le nombre de demandes ARP n'a pas pu être renvoyé sur la liaison montante pour l'apprentissage basé sur le chemin de données lorsque CCP ne dispose pas d'une liaison IP-MAC, ce qui entraîne l'échec de la suppression ARP.

Les statistiques non nulles indiquent que le système manque de ressources de tampon de paquets et que l'incrément continu doit être traité comme une erreur critique.

 4.2.0

arp_proxy_req_suppress

Nombre de demandes ARP qui sont supprimées par VDL2 en interrogeant CCP pour rechercher la liaison IP-MAC.

Ces paquets ARP sont envoyés sur la liaison montante uniquement lorsque CCP ne connaît pas la liaison.

 4.2.0

arp_proxy_resp

Nombre de réponses de liaison IP-MAC valides du CCP pour chaque demande de suppression ARP à partir de ce nœud de transport.

 4.2.0

arp_proxy_resp_drops

Nombre de réponses ARP correspondant à la réponse de liaison IP-MAC de CCP qui n'ont pas pu être envoyées au port de commutateur qui a demandé la demande ARP.

 4.2.0

arp_proxy_resp_filtered

Nombre de réponses ARP générées en fonction de la réponse de liaison IP-MAC du CCP qui ne sont pas envoyées au port de commutateur qui a initié la demande ARP.

Cela est possible, car ARP a été demandé en raison de Traceflow ou le port qui a initié la demande ARP n'était plus présent dans le nœud de transport.

 4.2.0

arp_proxy_resp_unknown

Nombre de liaisons IP-MAC inconnues dans le plan de contrôle pour chaque demande IP-MAC provenant de ce nœud de transport.

Lors de la réception de ce message, le module VDL2 renvoie la demande ARP sur la liaison montante pour apprendre la liaison IP-MAC via le chemin de données.

 4.2.0

leaf_rx

Pour un segment (commutateur logique), cette statistique est incrémentée lorsqu'un paquet généré par la charge de travail est reçu au niveau d'IOChain VDL2LeafInput (Superposition L2). Ces paquets sont envoyés à VDS s'il n'y a pas d'autres abandons de feuille reçus.

 4.2.0

leaf_rx_drops

Nombre d'abandons de paquets dans VDL2LeafInput pour différentes raisons.

Reportez-vous aux motifs d'abandon de l'autre feuille reçue pour identifier la raison spécifique des abandons.

 4.2.0

leaf_rx_ref_port_not_found_drops

Nombre d'abandons de paquets sur la feuille VDL2LeafInput. Cela peut se produire si le port de jonction ne fait pas partie du segment.

 4.2.0

leaf_rx_system_err_drops

Nombre d'abandons de paquets dans VDL2LeafInput en raison de diverses erreurs système, telles qu'une panne de mémoire ou des échecs de mise à jour d'attributs de paquets.

Cela signifie généralement que les ressources de l'hôte ESXi sont insuffisantes. Le déplacement de certaines machines virtuelles vers d'autres hôtes peut faciliter la charge.

 4.2.0

leaf_tx

Cette statistique augmente lorsqu'un paquet est traité correctement par VDL2LeafOutput (Superposition L2) IOChain pour un port de commutateur.

 4.2.0

leaf_tx_drops

Nombre total d'abandons sur VDL2LeafOutput pour diverses raisons.

Reportez-vous aux autres raisons d'abandon transmises par la feuille pour identifier la raison spécifique des abandons.

 4.2.0

mac_tbl_lookup_flood

Nombre de paquets de monodiffusion saturés vers les VTEP distants en raison d'un échec de recherche de la table MAC. Les valeurs grandes impliquent des problèmes de mise à jour de la table MAC ou de flux L2 unidirectionnels.

Vérifiez si la table MAC est pleine sur le nœud de transport hôte à l'aide de la commande suivante :

$ nsxcli -c "get segment mac-table"

Si nécessaire, augmentez la taille de la table MAC.

 4.2.0

mac_tbl_lookup_full

Nombre de fois que la requête MAC de destination vers le plan de contrôle pour le trafic vers les VM distantes a échoué, car la table MAC est déjà pleine.

Vérifiez si la table MAC est pleine sur le nœud de transport hôte à l'aide de la commande suivante :

$ nsxcli -c "get segment mac-table"

Si nécessaire, augmentez la taille de la table MAC.

 4.2.0

mac_tbl_update_full

Nombre d'échecs de mise à jour de la table MAC au moment de l'apprentissage MAC pour les paquets reçus de la sous-couche.

Vérifiez si la table MAC est pleine sur le nœud de transport hôte à l'aide de la commande suivante :

$ nsxcli -c "get segment mac-table"

Si nécessaire, augmentez la taille de la table MAC.

 4.2.0

mcast_proxy_rx_drops

Nombre de paquets BUM reçus sur la liaison montante du nœud de transport MTEP qui sont abandonnés lors de la réplication vers d'autres VTEP.

 4.2.0

mcast_proxy_tx_drops

Nombre de paquets BUM provenant des charges de travail dans le nœud de transport qui sont abandonnés après la réplication à la sortie de la liaison montante.

Cette statistique augmente si uplink_tx_invalid_state_drops augmente ou en raison d'erreurs système telles que la mémoire insuffisante.

 4.2.0

nd_proxy_req_fail_drops

Le nombre de demandes ND n'a pas pu être renvoyé sur la liaison montante pour l'apprentissage basé sur le chemin de données lorsque le CCP ne dispose pas d'une liaison IP-MAC, ce qui entraîne l'échec de la suppression de ND.

Les statistiques non nulles indiquent que le système manque de ressources de tampon de paquets et que l'incrément continu doit être traité comme une erreur critique.

 4.2.0

nd_proxy_req_suppress

Nombre de demandes ND supprimées par VDL2 en interrogeant CCP pour rechercher la liaison IP-MAC.

Ces paquets ND sont envoyés sur la liaison montante uniquement si CCP ne connaît pas la liaison.

 4.2.0

nd_proxy_resp

Nombre de réponses de liaison IP-MAC valides du CCP pour chaque demande de suppression ND à partir de ce nœud de transport.

Ces réponses ND peuvent être le résultat d'une réponse CCP directe ou d'une entrée ND déjà mise en cache dans le nœud de transport.

 4.2.0

nd_proxy_resp_drops

Nombre de réponses ND correspondant à la réponse de liaison IP-MAC de CCP qui n'ont pas pu être envoyées au port de commutateur qui a initié le paquet ND.

 4.2.0

nd_proxy_resp_filtered

Nombre de réponses ND générées en fonction de la réponse de liaison IP-MAC du CCP qui ne sont pas envoyées au port de commutateur qui a initié la demande ND.

Cela est possible, car ND a été demandé en raison de Traceflow ou le port qui a initié la demande ND n'était plus présent dans le nœud de transport.

 4.2.0

nd_proxy_resp_unknown

Nombre de liaisons IPv6-MAC inconnues dans le plan de contrôle pour chaque demande IPv6-MAC à partir de ce nœud de transport.

Lors de la réception de ce message, le module VDL2 renvoie les paquets ND sur la liaison montante pour apprendre la liaison IPv6-MAC via le chemin de données.

 4.2.0

nested_tn_mcast_proxy_diff_vlan_tx_drops

Nombre de paquets BUM abandonnés répliqués vers le nœud de transport imbriqué.

Le nœud de transport imbriqué et ce nœud de transport sont configurés avec un ID de VLAN de transport différent. Vérifiez que l'adresse IP de VTEP GW est accessible à partir des interfaces VMK VTEP de ce nœud de transport.

 4.2.0

nested_tn_mcast_proxy_same_vlan_tx_drops

Nombre de paquets BUM abandonnés répliqués vers le nœud de transport imbriqué.

Le nœud de transport imbriqué et ce nœud de transport sont configurés avec le même ID de VLAN de transport.

 4.2.0

uplink_rx

Nombre de paquets reçus au niveau du port de liaison montante à partir du commutateur TOR.

Ces paquets seront envoyés à VDS lorsqu'il n'y a pas d'abandons sur la liaison montante Rx.

 4.2.0

uplink_rx_drops

Nombre d'abandons de paquets dans VDL2UplinkInput pour différentes raisons.

Reportez-vous aux autres raisons d'abandon de liaison montante reçues pour identifier la raison spécifique des abandons.

 4.2.0

uplink_rx_filtered

Nombre de paquets envoyés par le commutateur TOR, qui sont filtrés sur la liaison montante VDL2 pour des raisons telles que des rapports IGMP à partir de nœuds de transport ESXi homologues.

 4.2.0

uplink_rx_guest_vlan_drops

Nombre d'abandons de paquets au niveau de VDL2UplinkInput lorsque la suppression de la balise VLAN invité échoue pour le paquet interne en raison d'une erreur système.

 4.2.0

uplink_rx_invalid_encap_drops

Nombre de paquets reçus au niveau de la liaison montante à partir de la sous-couche et abandonnés en raison d'en-têtes d'encapsulation incorrects.

Pour comprendre l'erreur exacte, effectuez la capture de paquets et vérifiez les en-têtes d'encapsulation (version du protocole, total de contrôle, longueur, etc.) en exécutant la commande suivante :

pktcap-uw --capture UplinkRcvKernel --uplink --ng -o uplink.pcap

 4.2.0

uplink_rx_mcast_invalid_dr_uplink_drops

Nombre d'abandons de paquets de multidiffusion IP au niveau de l'entrée de liaison montante VDL2, car le vdrPort n'est pas associé à cette liaison montante.

Cela peut se produire lorsque le commutateur TOR sonde le trafic multidiffusion sur toutes les liaisons montantes du nœud de transport.

Vérifiez le vdrPort et l'association de liaison montante à l'aide de la commande suivante, puis vérifiez si le paquet abandonné a été reçu sur la liaison montante non associée :

nsxdp-cli vswitch instance list

 4.2.0

uplink_rx_skip_mac_learn

Nombre de paquets pour lesquels l'adresse MAC externe source ne peut pas être apprise, car l'étiquette GENEVE entrante est inconnue.

Des valeurs élevées pour cette statistique peuvent pointer vers des mises à jour VTEP distantes manquantes au niveau du nœud de transport à partir du plan de contrôle.

Utilisez les commandes d'interface de ligne de commande suivantes pour vérifier la table VTEP distante sur le nœud de transport :

nsxcli -c "get global-vtep-table"

$ nsxcli -c "get segment vtep-table"

Une solution possible consiste à redémarrer l'agent de plan de contrôle local (CfgAgent) sur le nœud de transport pour forcer une synchronisation complète en exécutant la commande suivante :

$ /etc/init.d/nsx-cfgagent restart

 4.2.0

uplink_rx_system_err_drops

Nombre d'abandons de paquets au niveau de VDL2UplinkInput en raison de diverses erreurs système telles qu'une panne de mémoire ou des échecs de mise à jour d'attributs de paquets.

Cela signifie généralement que les ressources de l'hôte ESXi sont insuffisantes. Le déplacement de certaines machines virtuelles vers d'autres hôtes peut faciliter la charge.

 4.2.0

uplink_rx_wrong_dest_drops

Nombre de paquets reçus de la sous-couche et abandonnés, car l'adresse IP de destination du paquet ne correspond à aucun des VTEP configurés sur l'hôte.

 4.2.0

uplink_tx

Nombre de paquets envoyés par le VDS qui sont reçus sur l'IOChain VDL2 du port de liaison montante.

Ces paquets sont envoyés au réseau de sous-couche lorsqu'il n'y a pas d'abandon au niveau de la liaison montante Tx.

 4.2.0

uplink_tx_drops

Nombre total d'abandons de paquets dans VDL2UplinkOutput pour différentes raisons.

Reportez-vous aux autres raisons d'abandon transmises par la liaison montante pour identifier la raison spécifique des abandons.

 4.2.0

uplink_tx_flood_rate_limit

Nombre de paquets de monodiffusion inconnus saturés sur les liaisons montantes dont le débit est limité.

 4.2.0

uplink_tx_ignore

Nombre de paquets envoyés par VDS filtrés à la sortie de liaison montante VDL2 et non transférés à la sous-couche.

Par exemple, les paquets BUM sont filtrés s'il n'existe aucun VTEP sur le segment vers lequel répliquer les paquets.

 4.2.0

uplink_tx_invalid_frame_drops

Nombre de paquets abandonnés à la sortie de liaison montante VDL2, car l'en-tête d'encapsulation est introuvable ou le TSO défini sur la trame interne n'a pas pu être exécuté. Cela est dû à des paquets TCP volumineux.

 4.2.0

uplink_tx_invalid_state_drops

Nombre de paquets abandonnés à la sortie de la liaison montante VDL2 en raison d'une configuration VLAN de transport incorrecte. Cela est dû à une association de profil de liaison montante incorrecte au niveau du nœud de transport ou si l'adresse MAC de la passerelle n'est pas résolue.

Utilisez la procédure suivante pour vérifier sur un nœud ESXi si l'adresse IP de la passerelle VTEP est accessible à partir des interfaces VMK VTEP de ce nœud de transport.

  1. Obtenez le nom de l’adresse IP en exécutant la commande suivante : net-vdl2 -l
  2. Obtenez le nom de l'instance de la pile réseau en exécutant la commande suivante : esxcfg-vmknic -l
  3. Exécutez un ping sur l'adresse IP de la passerelle VTEP en exécutant la commande suivante : vmkping -I vmk10 -S
 4.2.0

uplink_tx_nested_tn_repl_drops

Nombre de paquets BUM qui sont abandonnés à la sortie de la liaison montante VDL2 lors de la réplication vers le nœud de transport imbriqué en raison d'une association VTEP incorrecte.

Utilisez la commande suivante pour vérifier l'association entre le port de commutateur source et la liaison montante :

nsxdp-cli vswitch instance list

 4.2.0

uplink_tx_non_unicast

Nombre de paquets de diffusion ou de multidiffusion répliqués vers des VTEP distants. Un taux élevé implique que le nœud de transport doit répliquer ces paquets vers des VTEP distants, ce qui peut entraîner une contrainte sur les files d'attente transmises de la couche de liaison montante.

 4.2.0

uplink_tx_teaming_drops

Nombre de paquets abandonnés au niveau de VDL2UplinkOutput en raison de la non-disponibilité du VTEP associé au port de commutateur à l'origine du trafic.

Utilisez la commande suivante pour vérifier l'association de liaison montante du port de commutateur de charge de travail et l'état d'association :

nsxdp-cli vswitch instance list

 4.2.0

uplink_tx_ucast_flood

Nombre de paquets de monodiffusion inconnus saturés à la sortie de la liaison montante. Des valeurs grandes impliquent des problèmes de mise à jour de la table MAC ou de flux L2 unidirectionnels.

Vérifiez si le flux unidirectionnel est attendu ou si la table MAC est pleine.

 4.2.0

Module : datapath_l3

Ce module de chemin de données, également appelé VDR (Virtual Distributed Routing), achemine les paquets sur chaque hôte ESXi. Ce module de chemin de données est appelé nsxt-vdrb dans NSX Central CLI.

Statistiques Description Version introduite

arp_hold_pkt_drops

Lorsque le routeur distribué est en cours de résolution d'une entrée ARP IPv4, les paquets utilisant cette entrée ARP sont mis en file d'attente.

Le nombre de paquets pouvant être mis en file d'attente est limité par instance de routeur logique. Lorsque la limite est atteinte, les paquets les plus anciens sont abandonnés et cette statistique augmente du nombre d'anciens paquets qui sont abandonnés.

 4.2.0

arpfaildrops (lta)

Abandons de paquets IPv4 en raison d'un échec ARP.

 4.2.0

consumed_icmpv4

Nombre de paquets IPv4 destinés à une adresse IP de port de routage logique du routeur distribué correspondant à un segment donné.

Gardez à l'esprit que les statistiques augmenteront après le routage du paquet à partir du sous-réseau source.

 4.2.0

consumed_icmpv6

Nombre de paquets IPv6 destinés à une adresse IP de port de routage logique du routeur distribué correspondant à un segment donné. Gardez à l'esprit que les statistiques augmenteront après le routage du paquet à partir du sous-réseau source.

 4.2.0

drop_route_ipv4_drops

Nombre de paquets IPv4 correspondant aux « routes d'abandon ». Les routes d'abandon sont les routes configurées pour abandonner volontairement les paquets correspondants.

Si ce n'est pas prévu, vérifiez les routes sur l’hôte ESXi et vérifiez la configuration dans le plan de gestion.

 4.2.0

drop_route_ipv6_drops

Nombre de paquets IPv6 correspondant aux « routes abandonnées ».

Les routes d'abandon sont les routes configurées pour abandonner volontairement les paquets correspondants. Si ce n'est pas prévu, vérifiez les routes sur l’hôte ESXi et vérifiez la configuration dans le plan de gestion.

 4.2.0

ndfaildrops (lta)

Abandons de paquets IPv6 en raison d'un échec de la détection de voisins.

 4.2.0

no_nbr_ipv4

Aucune entrée ARP IPv4 trouvée dans la table ARP du routeur distribué.

 4.2.0

no_nbr_ipv6

Aucune entrée de voisin IPv6 trouvée dans la table des voisins du routeur distribué.

 4.2.0

no_route_ipv4_drops

Chaque instance de routeur logique dispose de sa propre table de routage pour les recherches d'itinéraires.

Cette statistique augmente lorsque des paquets IPv4 sont abandonnés en raison de l'absence de route correspondante pour cette instance de routeur logique.

 4.2.0

no_route_ipv6_drops

Chaque instance de routeur logique dispose de sa propre table de routage pour les recherches d'itinéraires.

Cette statistique augmente lorsque des paquets IPv6 sont abandonnés en raison de l'absence de route correspondante pour cette instance de routeur logique.

 4.2.0

ns_hold_pkt_drops

Lorsque le routeur distribué est en train de résoudre une entrée de voisin IPv6, les paquets utilisant cette entrée de voisin sont mis en file d'attente.

Le nombre de paquets pouvant être mis en file d'attente est limité par instance de routeur logique. Lorsque la limite est atteinte, les paquets les plus anciens sont abandonnés et cette statistique augmente du nombre d'anciens paquets qui sont abandonnés.

 4.2.0

pkt_attr_error_drops

Nombre de paquets ayant échoué à l'opération d'attribut. NSX utilise des attributs de paquets pour faciliter le traitement des paquets.

Les attributs de paquet peuvent être alloués, définis ou non définis. Dans des cas réguliers, l'opération n'échouera pas.

Les raisons possibles de l'incrément de cette statistique peuvent être les suivantes :
  • Le segment de mémoire de l'attribut de paquet est épuisé.
  • L'attribut de paquet est corrompu.
 4.2.0

relayed_dhcpv4_req

Demandes DHCPv4 relayées.

 4.2.0

relayed_dhcpv4_rsp

Réponses DHCPv4 relayées.

 4.2.0

relayed_dhcpv6_req

Demandes DHCPv6 relayées.

 4.2.0

relayed_dhcpv6_rsp

Réponses DHCPv6 relayées.

 4.2.0

rpf_ipv4_drops

Nombre de paquets IPv4 abandonnés en raison d'un échec de la vérification du transfert de chemin inverse.

Le routeur distribué peut vérifier si l'adresse IP source des paquets provient d'une source valide (accessible) et peut abandonner les paquets en fonction de la configuration.

Vous pouvez modifier ce paramètre dans l'interface utilisateur NSX Manager.

Pour vérifier la configuration actuelle dans l'interface utilisateur NSX Manager, procédez comme suit :
  1. Accédez à Mise en réseau > Segments.
  2. Modifiez le segment qui vous intéresse.
  3. Accédez à Paramètres supplémentaires.
  4. Vérifiez le mode URPF.
 4.2.0

rpf_ipv6_drops

Nombre de paquets IPv6 abandonnés en raison de l'échec de la vérification du transfert de chemin inverse.

Le routeur distribué peut vérifier si l'adresse IP source des paquets provient d'une source valide (accessible) et peut abandonner les paquets en fonction de la configuration.

Vous pouvez modifier ce paramètre dans l'interface utilisateur NSX Manager.

Pour vérifier la configuration actuelle dans l'interface utilisateur NSX Manager, procédez comme suit :
  1. Accédez à Mise en réseau > Segments.
  2. Modifiez le segment qui vous intéresse.
  3. Accédez à Paramètres supplémentaires.
  4. Vérifiez le mode URPF.
 4.2.0

rx_arp_req

Nombre de paquets de demande ARP reçus par le port de routeur logique d'un routeur distribué correspondant à un segment donné.

 4.2.0

rx_ipv4

Nombre de paquets IPv4 arrivant vers un port de routage logique d'un routeur distribué correspondant à un segment donné.

 4.2.0

rx_ipv6

Nombre de paquets IPv6 arrivant vers un port de routage logique d'un routeur distribué correspondant à un segment donné.

 4.2.0

rx_pkt_parsing_error_drops

Nombre d'échecs d'analyse de paquets pour les paquets du routeur distribué reçus.

Le routeur distribué effectue l'analyse des paquets pour chaque paquet reçu afin de lire les métadonnées et les en-têtes.

Si vous voyez un nombre élevé pour cette statistique, l'une des raisons possibles est que les paquets ne sont pas correctement structurés. Surveillez s'il existe une panne de trafic et effectuez la capture de paquets pour poursuivre le débogage.

 4.2.0

rxgarp (lta)

ARP gratuit (Gratuitous ARP) reçu sur un routeur distribué.

 4.2.0

ttl_ipv4_drops

Nombre de paquets IPv4 abandonnés en raison d'une TTL faible (durée de vie). Chaque instance de routeur logique déduira 1 de la valeur TTL.

Utilisez la capture de paquets pour déterminer quels paquets ont des valeurs TTL faibles. Si la durée de vie est assez importante à la source, les raisons possibles sont un trop grand nombre de sauts de routage sur le chemin ou le paquet est en boucle, ce qui est rare.

 4.2.0

ttl_ipv6_drops

Nombre de paquets IPv6 abandonnés en raison d'une durée de vie faible. Chaque instance de routeur logique déduira 1 de la valeur TTL.

Utilisez la capture de paquets pour déterminer quels paquets ont des valeurs TTL faibles. Si la durée de vie est assez importante à la source, les raisons possibles sont un trop grand nombre de sauts de routage sur le chemin ou le paquet est en boucle, ce qui est rare.

 4.2.0

tx_arp_rsp

Nombre de paquets de demande ARP envoyés par le port de routeur logique d'un routeur distribué correspondant à un segment donné.

 4.2.0

tx_dispatch_queue_too_long_drops

Nombre de paquets abandonnés dans la file d'attente de répartition des transmissions.

La file d'attente de répartition des transmissions contient les paquets générés automatiquement par le routeur distribué, tels que les paquets ARP, la détection NS, etc.

Chaque paquet consomme les ressources système de traitement des paquets. Si trop de paquets sont mis en file d'attente, limitez la taille de la file d'attente et abandonnez les paquets.

 4.2.0

tx_ipv4

Nombre de paquets IPv4 sortant d'un port de routeur logique d'un routeur distribué correspondant à un segment donné.

 4.2.0

tx_ipv6

Nombre de paquets IPv6 sortant d'un port de routeur logique d'un routeur distribué correspondant à un segment donné.

 4.2.0

Module : distributed_firewall

Ce module datapth fournit la capacité de pare-feu distribué. Dans ce tableau, Rx fait référence aux paquets reçus par le port de commutateur (envoyé depuis la VM) et Tx aux paquets transmis à partir du port de commutateur (reçus par la VM). Ce module de chemin de données est appelé nsxt-vsip dans NSX Central CLI.

Statistiques Description Version introduite

alg_handler_drops

Nombre de paquets abandonnés en raison du traitement ALG. Il suit l'erreur de gestion des paquets du décodeur d'état ALG.

 4.2.0

bad_offset_drops

Nombre de paquets abandonnés par décalage incorrect.

 4.2.0

bad_timestamp_drops

Nombre de paquets abandonnés en raison d'un horodatage incorrect. Par exemple, les paquets ACK transportant un ancien horodatage, les paquets reçus avec un horodatage inattendu doivent être abandonnés.

 4.2.0

congestion_drops

Nombre de paquets abandonnés en raison d'un encombrement. Par exemple, un encombrement détecté dans la file d'attente d'une interface réseau.

 4.2.0

fragment_drops

Nombre de paquets abandonnés en raison de l'échec du réassemblage de paquets fragmentés.

La fragmentation divise les paquets en fragments plus petits afin que les éléments résultants puissent passer par un lien avec une MTU inférieure à la taille du paquet d'origine.

4.2.0

handshake_error_drops

Nombre de paquets abandonnés en raison d'une erreur d'établissement de liaison TCP en trois temps.

Cela peut se produire lorsque l'expéditeur et le récepteur sont en SYN envoyé lors de l'établissement d'une liaison en trois temps. Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

icmp_err_pkt_drops

Nombre de paquets abandonnés en raison de paquets de réponse d'erreur ICMP supplémentaires.

Cette statistique suit les paquets de réponse d'erreur ICMP supplémentaires qui sont abandonnés.

 4.2.0

icmp_error_drops

Nombre de paquets abandonnés en raison d'un échec de séquence dans la réponse d'erreur ICMP au paquet TCP.

Lorsque les numéros de séquence sont hors de la plage attendue, cela entraîne un abandon.

 4.2.0

icmp_flood_overlimit_drops

Nombre de paquets abandonnés en raison d'une limite de propagation ICMP. Une limite de propagation ICMP est configurée dans l'interface du noyau.

 4.2.0

ignored_offloaded_fpdrops

Nombre de paquets abandonnés en raison du flux déchargé vers le matériel.

Le flux déchargé sur le matériel signifie que le suivi de la connexion est effectué par le pipeline de paquets matériels d'une carte réseau intelligente. Dans ce cas, l'obtention d'un paquet dans le logiciel est inattendue. Le paquet ne peut pas être traité dans le logiciel, car il ne dispose d'aucune information CT à jour (par exemple, états, numéros de séquence). Le trafic doit donc être abandonné.

Ce cas peut se produire, car le déchargement d'un flux vers le matériel prend un certain temps et peut concurrencer les paquets déjà mis en file d'attente à livrer à VSIP. Cette raison d'abandon concerne les paquets de chemin d'accès rapide ENS.

 4.2.0

ignored_offloaded_spdrops

Nombre de paquets abandonnés en raison du flux déchargé vers le matériel.

Le flux déchargé sur le matériel signifie que le suivi de la connexion est effectué par le pipeline de paquets matériels d'une carte réseau intelligente. Dans ce cas, l'obtention d'un paquet dans le logiciel est inattendue. Le paquet ne peut pas être traité dans le logiciel, car il ne dispose d'aucune information CT à jour (par exemple, états, numéros de séquence). Le trafic doit donc être abandonné.

Ce cas peut se produire, car le déchargement d'un flux vers le matériel prend un certain temps et peut concurrencer les paquets déjà mis en file d'attente à livrer à VSIP. Cette raison d'abandon concerne le chemin de code IOChain, également appelé chemin lent dans ce contexte.

 4.2.0

ip_option_drops

Nombre de paquets abandonnés, car les options IP ne sont pas autorisées.

Si allow_opts dans la règle de pare-feu n'est pas définie, le paquet atteignant cette règle est abandonné.

 4.2.0

l7_alert_drops

La règle L7 est présente, mais il n'existe aucune correspondance. Une alerte est générée.

 4.2.0

l7_attr_error_drops

Nombre de paquets abandonnés en raison de l'échec de la définition des attributs d'état.

Cela se produit lorsque l'allocation ou la modification d'attributs L7 attrconn échoue et entraîne une perte.

 4.2.0

l7_pending_misc

Cette statistique suit les paquets actuellement analysés par DPI. La correspondance des règles est en attente.

Une fois que la correspondance de règle L7 se produit, l'action de règle correspondante est effectuée sur le paquet.

 4.2.0

lb_reject_drops

Cette statistique suit les abandons en raison du rejet de paquets par l'équilibreur de charge.

Les paquets sont abandonnés s'ils correspondent à un serveur virtuel d'équilibreur de charge, mais qu'aucun membre du pool n'est sélectionné.

 4.2.0

match_drop_rule_rx_drops

Nombre de paquets reçus abandonnés par abandon ou rejet de la règle de pare-feu distribué.

 4.2.0

match_drop_rule_tx_drops

Nombre de paquets transmis abandonnés en atteignant l'abandon ou le rejet de la règle de pare-feu distribué.

 4.2.0

memory_drops

Nombre de paquets abandonnés en raison d'un manque de mémoire. Il s'agit d'une erreur au niveau de la capacité.

 4.2.0

normalize_drops

Nombre de paquets abandonnés en raison de paquets incorrects. Par exemple, la version IP ne correspond pas, le décalage d'en-tête TCP est incohérent avec la longueur totale de description du paquet

 4.2.0

other_flood_overlimit_drops

Nombre de paquets abandonnés en raison d'une autre limite de propagation de protocole. Une limite de propagation est configurée dans l'interface du noyau pour d'autres protocoles.

 4.2.0

pkts_frag_queued_v4_misc

Pendant la fragmentation des paquets, les fragments de paquets sont ajoutés à la file d'attente des fragments. Ces fragments de paquets ne sont pas nécessairement abandonnés. Un réassemblage de paquets réussi signifie qu'aucun paquet fragmenté n'est abandonné.

Cette statistique suit les paquets IPv4 qui sont ajoutés à la file d'attente de fragments.

 4.2.0

pkts_frag_queued_v6_misc

Pendant la fragmentation des paquets, les fragments de paquets sont ajoutés à la file d'attente des fragments. Ces fragments de paquets ne sont pas nécessairement abandonnés. Un réassemblage de paquets réussi signifie qu'aucun paquet fragmenté n'est abandonné.

Cette statistique suit les paquets IPv6 qui sont ajoutés à la file d'attente de fragments.

 4.2.0

proto_cksum_drops

Nombre de paquets abandonnés en raison d'un total de contrôle de protocole incorrect. Cela se produit lorsque la validation du total de contrôle du paquet échoue.

 4.2.0

rx_ipv4_drop_pkts

Nombre de paquets IPv4 reçus abandonnés.

 4.2.0

rx_ipv4_pass_pkts

Nombre de paquets IPv4 reçus transmis.

 4.2.0

rx_ipv4_reject_pkts

Nombre de paquets IPv4 reçus rejetés.

 4.2.0

rx_ipv6_drop_pkts

Nombre de paquets IPv6 reçus abandonnés.

 4.2.0

rx_ipv6_pass_pkts

Nombre de paquets IPv6 reçus transmis.

 4.2.0

rx_ipv6_reject_pkts

Nombre de paquets IPv6 reçus rejetés.

 4.2.0

rx_l2_drop_pkts

Nombre de paquets abandonnés de couche 2 reçus.

 4.2.0

seqno_bad_ack_drops

Nombre de paquets abandonnés en raison de l'accusé de réception TCP et de plusieurs fenêtres.

Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

seqno_gt_max_ack_drops

Nombre de paquets abandonnés en raison du numéro de séquence TCP supérieur au nombre ACK maximal.

Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

seqno_lt_minack_drops

Nombre de paquets abandonnés, car le numéro de séquence TCP est inférieur au nombre ACK minimal.

Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

seqno_old_ack_drops

Nombre de paquets abandonnés en raison de l'accusé de réception TCP de plusieurs fragments.

Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

seqno_old_retrans_drops

Nombre de paquets abandonnés en raison d'une retransmission TCP antérieure à une fenêtre.

Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

seqno_outside_window_drops

Nombre de paquets abandonnés en raison du numéro de séquence TCP en dehors de la fenêtre.

Cette raison de l'abandon fait partie de l'état non-correspondance TCP.

 4.2.0

short_drops

Nombre de paquets courts abandonnés.

Les paquets courts sont des paquets dont la longueur est incorrecte, par exemple, des paquets avec une valeur de ip_len incorrecte.

 4.2.0

spoof_guard_drops

Nombre de paquets abandonnés en raison de la vérification de SpoofGuard.

SpoofGuard est un outil conçu pour empêcher les machines virtuelles de votre environnement d'envoyer du trafic avec une adresse IP depuis laquelle elles ne sont pas autorisées à envoyer du trafic.

 4.2.0

src_limit_misc

Nombre de paquets atteignant la limite de source.

Cela est lié au traitement des paquets du pare-feu. Cela se produit en raison de l'échec de l'insertion du nœud source dans l'arborescence Rouge-Noir (RB) en raison de la limite atteinte.

 4.2.0

state_insert_drops

Nombre de paquets abandonnés en raison d'un échec d'insertion d'état. Cela se produit en raison d'une insertion d'état en double.

 4.2.0

state_limit_drops

Nombre de paquets abandonnés en raison de la limite maximale d'états atteinte.

Par exemple, si le nombre d'états TCP est supérieur à la limite, cela entraîne une baisse.

 4.2.0

state_mismatch_drops

Nombre de paquets abandonnés en raison d'une incompatibilité d'état.

Il existe plusieurs raisons possibles d'abandonner, telles que STRICTNOSYN, HANDSHAKE_SYNSENT, SEQ_GT_SEQHI, etc.

 4.2.0

strict_no_syn_drops

Nombre de paquets abandonnés en raison d'un mode d'application strict sans syn. Le paquet SYN doit être vu en mode strict.

 4.2.0

syn_expected_drops

Le paquet correspond à un serveur virtuel d'équilibreur de charge, mais il ne s'agit pas d'un paquet SYN. Par conséquent, le système ne doit pas créer un état pour celui-ci. Cela entraîne un abandon de paquets. Cette statistique permet de suivre cette baisse.

 4.2.0

syn_proxy_drops

Nombre de paquets abandonnés en raison de synproxy. Cela permet de protéger les serveurs TCP contre les attaques telles que SYN FLOOD.

 4.2.0

tcp_flood_overlimit_drops

Nombre de paquets abandonnés en raison d'une limite de propagation TCP. Une limite de propagation TCP est configurée dans l'interface du noyau.

 4.2.0

tx_ipv4_drop_pkts

Nombre de paquets IPv4 transmis abandonnés.

 4.2.0

tx_ipv4_pass_pkts

Nombre de paquets IPv4 transmis.

 4.2.0

tx_ipv4_reject_pkts

Nombre de paquets IPv4 transmis rejetés.

 4.2.0

tx_ipv6_drop_pkts

Nombre de paquets IPv6 transmis abandonnés.

 4.2.0

tx_ipv6_pass_pkts

Nombre de paquets IPv6 transmis.

 4.2.0

tx_ipv6_reject_pkts

Nombre de paquets IPv6 transmis rejetés.

 4.2.0

tx_l2_drop_pkts

Nombre de paquets de couche 2 transmis abandonnés.

 4.2.0

udp_flood_overlimit_drops

Nombre de paquets abandonnés en raison d'une limite de propagation UDP. Une limite de propagation UDP est configurée dans l'interface du noyau.

 4.2.0

Module : virtual_switch

Ce module de chemin de données de couche 2 est chargé de fournir la fonctionnalité de commutation. Ce module transfère des paquets au sein d'un domaine de diffusion en fonction du VLAN et du VNI sur lequel l'interface reçoit un paquet. Dans ce tableau, Rx fait référence aux paquets envoyés « au » commutateur et Tx fait référence aux paquets reçus « du » commutateur. Mcast fait référence aux paquets de multidiffusion. Ce module de chemin de données est appelé nsxt-vswitch dans NSX Central CLI.

Statistiques Description Version introduite

forged_transmit_rx_drops

Nombre de paquets abandonnés en tant qu'abandons forgés en raison de la différence de l'adresse MAC source du paquet par rapport à l'adresse MAC de l'adaptateur de machine virtuelle.

Les transmissions forgées ou la désactivation de l'apprentissage MAC sur le segment entraînent ces abandons. L'activation de l'apprentissage MAC ou des transmissions forgées sur le segment devrait atténuer le problème.

 4.2.0

unknown_unicast_rx_pkts

Nombre de paquets de monodiffusion inconnus reçus par vSwitch qui sont saturés vers d'autres ports dans le même domaine de diffusion.

Les statistiques s'incrémentent lorsque des paquets monodiffusion inconnus sont saturés en présence de segments ou de ports de réception activés pour l'apprentissage MAC. Une saturation de monodiffusion inconnue se produit lorsque l'adresse MAC de destination du paquet est introuvable dans la table d'adresses MAC de vSwitch.

Cette statistique augmente lorsqu'une adresse MAC de destination sort de la table d'adresses MAC en présence de l'apprentissage MAC.

 4.2.0

unknown_unicast_rx_uplink_pkts

Nombre de paquets reçus d'une ou de plusieurs liaisons montantes vers le vSwitch qui sont une monodiffusion inconnue saturée vers d'autres ports du même domaine de diffusion par le vSwitch.

Les statistiques s'incrémentent lorsque des paquets monodiffusion inconnus sont saturés en présence de segments ou de ports de réception activés pour l'apprentissage MAC. Une saturation de monodiffusion inconnue se produit lorsque l'adresse MAC de destination du paquet est introuvable dans la table d'adresses MAC de vSwitch.

Cette statistique augmente lorsqu'une adresse MAC de destination sort de la table d'adresses MAC en présence de l'apprentissage MAC.

 4.2.0

unknown_unicast_tx_pkts

Nombre de paquets de monodiffusion inconnus saturés vers d'autres ports du même domaine de diffusion par le vSwitch.

Les statistiques s'incrémentent lorsque des paquets monodiffusion inconnus sont saturés en présence de segments ou de ports de réception activés pour l'apprentissage MAC. Une saturation de monodiffusion inconnue se produit lorsque l'adresse MAC de destination du paquet est introuvable dans la table d'adresses MAC de vSwitch.

Cette statistique augmente lorsqu'une adresse MAC de destination sort de la table d'adresses MAC en présence de l'apprentissage MAC.

 4.2.0

unknown_unicast_tx_uplink_pkts

Nombre de paquets monodiffusion inconnus saturés par le vSwitch vers une ou plusieurs liaisons montantes.

Les statistiques s'incrémentent lorsque des paquets monodiffusion inconnus sont saturés en présence de segments ou de ports de réception activés pour l'apprentissage MAC. Une saturation de monodiffusion inconnue se produit lorsque l'adresse MAC de destination du paquet est introuvable dans la table d'adresses MAC de vSwitch.

Cette statistique augmente lorsqu'une adresse MAC de destination sort de la table d'adresses MAC en présence de l'apprentissage MAC.

 4.2.0

vlan_tag_mismatch_rx

Nombre de paquets de monodiffusion et de diffusion abandonnés en raison d'une incompatibilité de balise VLAN.

Ces abandons se produisent lorsque la balise VLAN d'un paquet n'est pas autorisée conformément à la stratégie VLAN du segment. La modification de la stratégie VLAN du segment ou l'envoi de paquets avec une balise VLAN autorisée peut atténuer le problème.

 4.2.0

vlan_tag_mismatch_rx_mcast

Nombre de paquets de multidiffusion abandonnés en raison d'une incompatibilité de balise VLAN.

Ces abandons se produisent lorsque la balise VLAN d'un paquet n'est pas autorisée conformément à la stratégie VLAN du segment. La modification de la stratégie VLAN du segment ou l'envoi de paquets avec une balise VLAN autorisée peut atténuer le problème.

 4.2.0

vlan_tag_mismatch_tx

Nombre de paquets de monodiffusion abandonnés en raison d'une incompatibilité de balise VLAN.

Le commutateur hôte localise une entrée dans sa table de recherche en fonction de l'adresse de destination du paquet. Lorsque vous tentez de transférer le paquet à partir d'un port, ces abandons se produisent lorsque la balise VLAN d'un paquet n'est pas autorisée conformément à la stratégie VLAN du segment. La modification de la stratégie VLAN du segment ou l'envoi de paquets avec une balise VLAN autorisée peut atténuer le problème.

 4.2.0

vlan_tag_mismatch_tx_mcast

Nombre de paquets de multidiffusion abandonnés en raison d'une incompatibilité de balise VLAN.

Le commutateur hôte localise une entrée dans sa table de recherche en fonction de l'adresse de destination du paquet. Lorsque vous tentez de transférer le paquet à partir d'un port, ces abandons se produisent lorsque la balise VLAN d'un paquet n'est pas autorisée conformément à la stratégie VLAN du segment. La modification de la stratégie VLAN du segment ou l'envoi de paquets avec une balise VLAN autorisée peut atténuer le problème.

 4.2.0

vni_tag_mismatch_tx

Nombre de paquets de monodiffusion abandonnés en raison d'une incompatibilité de balise VNI.

Le commutateur hôte localise une entrée dans sa table de recherche en fonction de l'adresse de destination du paquet. Lorsque vous tentez de transférer le paquet à partir d'un port, ces abandons se produisent lorsque la balise VNI d'un paquet n'est pas autorisée conformément à la stratégie VNI du segment. Le déplacement de la machine virtuelle de destination vers ce segment de superposition peut résoudre le problème.

 4.2.0

vni_tag_mismatch_tx_mcast

Nombre de paquets de multidiffusion abandonnés en raison d'une incompatibilité de balise VNI.

Le commutateur hôte localise une entrée dans sa table de recherche en fonction de l'adresse de destination du paquet. Lorsque vous tentez de transférer le paquet à partir d'un port, ces abandons se produisent lorsque la balise VNI d'un paquet n'est pas autorisée conformément à la stratégie VNI du segment. Le déplacement de la machine virtuelle de destination vers ce segment de superposition peut résoudre le problème.

 4.2.0