Mappage d’inventaire VMware NSX-T avec l’infrastructure virtuelle Apstra
Aperçu
Le logiciel Apstra peut se connecter à l’API NSX-T pour collecter des informations sur l’inventaire en termes d’hôtes, de clusters, de VM, de groupes de ports, de vDS/N-vDS et de cartes réseau au sein de l’environnement NSX-T. Apstra peut s’intégrer à NSX-T pour fournir aux administrateurs Apstra une visibilité sur les charges de travail applicatives (appelées VM) en cours d’exécution et les alerter des incohérences susceptibles d’affecter la connectivité des charges de travail. La visibilité sur l’infrastructure virtuelle Apstra fournit une visibilité de corrélation underlay/overlay et utilise les analyses IBA pour l’overlay/underlay.
Vous ne pouvez pas afficher l’inventaire NSX dans Apstra tant que le gestionnaire NSX-T n’est pas associé à un blueprint. 
Comme mentionné ci-dessus, la collecte d’inventaire de capture d’écran pour NSX-T s’effectue via le collecteur de télémétrie extensible Apstra.
Terminologie et corrélation des réseaux NSX-T
NSX-T utilise la terminologie suivante pour ses composants de plan de contrôle et de plan de données. Vous trouverez également une corrélation respective avec Apstra.
- Transport Zones
- N-VDS
- Nœud de transport
- Nœud de périphérie NSX
- Cluster de contrôleurs NSX
- Gestionnaire NSX
Transport Zones
Les zones de transport (TZ) définissent un groupe d’hôtes ESXi capables de communiquer entre eux sur un réseau physique. 
Il existe deux types de zones de transport :
- Zone de transport de superposition : cette zone de transport peut être utilisée par les nœuds de transport ou les périphéries NSX. Lorsqu’un hôte ESXi ou un nœud de transport de périphérie NSX-T est ajouté à une zone de transport de superposition, un N-VDS est installé sur l’hôte ESXi ou le nœud de périphérie NSX.
- Zone de transport VLAN : il peut être utilisé par NSX Edge et les nœuds de transport hôte pour ses liaisons montantes VLAN.
Chaque hôte hyperviseur ne peut appartenir qu’à une seule zone de transport à un moment donné.
Un VLAN VN nouvellement créé marqué vers une interface dans la structure Apstra correspond à une zone de transport basée sur VLAN comme indiqué dans les captures d’écran ci-dessous : 
Ici, le VN VLAN balisé est mappé à la zone de transport respective dans NSX-T avec le type de trafic en tant que VLAN. 
N-VDS
Un commutateur distribué virtuel géré par NSX fournit le transfert sous-jacent et représente le plan de données des nœuds de transport.
Quelques points notables concernant les commutateurs virtuels N-VDS sont les suivants :
- pnics sont des ports physiques sur l’hôte ESXi
- pnics peut être groupé pour former une agrégation de liens (LAG)
- les liaisons montantes sont des interfaces logiques d’un N-VDS
- liaisons montantes sont attribuées pnics ou LAG
Ici, NOUS avons des terminaux de tunnel utilisés pour la mise en réseau de superposition NSX (encapsulation/décapsulation de gènes). Les P1/P2 sont des PNIC mappés au profil de liaison montante(U1/U2).
Les N-VDS sont instanciés au niveau de l’hyperviseur et peuvent être considérés comme un commutateur virtuel connecté aux branches physiques haut de rack comme suit : 
Nœud de transport
Il s’agit d’un nœud capable de participer à un overlay de centre de données NSX-T ou à un réseau VLAN. 
Les machines virtuelles hébergées sur différents nœuds de transport communiquent en toute transparence sur le réseau de superposition. Un nœud de transport peut appartenir à :
- Plusieurs zones de transport VLAN.
- Au plus une zone de transport overlay avec un N-VDS standard.
Il peut être comparé à la définition d’hôtes finaux (serveurs) dans un plan Apstra pour faire partie du VLAN (leaf-local) ou du réseau virtuel VXLAN (entre branches).
Nœud de périphérie NSX
Le NSX Edge fournit des services de routage et une connectivité aux réseaux externes au déploiement NSX-T. Il est nécessaire d’établir une connectivité externe à partir du domaine NSX-T, via un routeur de niveau 0 via BGP ou un routage statique.
Les machines virtuelles de périphérie NSX ont des liaisons montantes vers les feuilles haut de réseau nécessitant une zone de transport VLAN distincte. La structure Apstra doit être configurée avec le réseau virtuel VLAN correspondant. 
NSX-T Edge Les facteurs de forme bare metal ou VM sont des nœuds de transport et sont découverts comme hyperviseurs dans Apstra. Cependant, les nœuds de transport périphérique des MACHINES virtuelles ne peuvent pas être corrélés à la branche toR connectée.
Cluster de contrôleurs NSX
Il fournit des fonctions de plan de contrôle pour les composants de routage et de commutation logique de centre de données NSX-T.
Gestionnaire NSX
Il s’agit d’un nœud qui héberge les services d’API, le plan de gestion et les services d’agent.
Modèle d’inventaire NSX
- Dans NSX-T, les nœuds de transport sont des hôtes hyperviseurs et peuvent être corrélés aux nœuds serveur d’un blueprint connecté aux branches haut de gamme. Dans le centre de données NSX-T, les hôtes ESXi sont préparés en tant que nœud de transport, ce qui permet aux nœuds d’échanger du trafic contre des réseaux virtuels sur Apstra Fabric ou parmi les nœuds du réseau. Vous devez vous assurer que la pile réseau des hyperviseurs (ESXi) envoie des paquets LLDP pour faciliter la corrélation des hôtes ESXi avec les nœuds serveur du plan.
- PNIC est l’adaptateur réseau physique réel sur l’hôte ESXi ou hyperviseur. Les NIC d’hyperviseur peuvent être corrélés à l’interface serveur du blueprint. La configuration LAG ou Teaming est effectuée sur les liaisons mappées à ces cartes réseau physiques. Cela peut être corrélé à la configuration de liaison effectuée sur les branches haut de gamme vers les serveurs finaux.
- Dans l’intégration NSX-T aux réseaux virtuels apstra vm sont découvertes. Ces derniers peuvent être corrélés à des réseaux virtuels blueprint. Dans le cas où les machines virtuelles doivent communiquer entre elles via des tunnels entre hyperviseurs, les VM sont connectées au même commutateur logique dans NSX-T (appelé N-VDS). Chaque commutateur logique dispose d’un identifiant de réseau virtuel (VNI), comme un ID VLAN. Cela correspond aux VNVXLAN comme dans l’infrastructure physique de la structure Apstra.
- Le profil de liaison montante NSX-T définit la configuration de l’interface réseau à la structure en termes de configuration LAG et LACP sur les interfaces PNIC. Le profil de liaison montante est mappé dans le nœud de transport pour les liaisons de l’hyperviseur/ESXi vers les commutateurs haut de baie (top-of-rack) dans Apstra Fabric.
- VNIC définit l’interface virtuelle des nœuds ou machines virtuelles de transport. Le commutateur N-VDS mappe les cartes réseau physiques vers ces interfaces virtuelles de liaison montante. Ces interfaces virtuelles peuvent être corrélées aux ports d’interface serveur d’Apstra Fabric.
Détails du modèle et relation
Hyperviseur
- Hostname: Attribut FQDN du nœud de transport
- Hypervisor_id : Attribut d’id du nœud de transport
- Étiquette: Attribut d’affichage du nom du nœud de transport
- Version: Version NSX-T installée sur le nœud de transport
Pour obtenir une réponse API NSX-T pour les hôtes hyperviseurs respectifs et comprendre la corrélation, vous pouvez utiliser une requête graphique. Pour ouvrir l’explorateur GraphQL, cliquez sur le bouton 
« >_ »
Ensuite, dans l’explorateur de graphiques, nous pouvons saisir une requête graphique sur la gauche comme indiqué dans la capture d’écran ci-dessous à l’aide de GraphQL : 
Pour rechercher l’étiquette respective des nœuds de transport ci-dessous, vous pouvez utiliser :
Demande:
{
hypervisor_nodes{
label
}
}
Réponse:
{
"data": {
"hypervisor_nodes": [
{
"label": "zz-karun-nsxt.cvx.2485377892354-357746820-TN-2"
},
{
"label": "zz-AndyF-nsxt.cvx.2485377892354-4240714876-TN-2"
}
]
}
}
Les hyperviseurs faisant office de nœuds de transport peuvent être visualisés dans Apstra sous l’onglet Actif avec l’option Has Hypervisor = Yes comme ci-dessous : 
Pour obtenir le nom d’hôte respectif des nœuds de transport ci-dessous, la requête peut être utilisée :
Demande:
{
hypervisor_nodes {
hostname
}
}
Réponse:
{
"data": {
"hypervisor_nodes": [
{
"hostname": "localhost"
},
{
"hostname": "ubuntu-bionic-nsxt"
}
]
}
}
PNIC de l’hyperviseur
- Adresse MAC : Attribut d’adresse physique de l’interface de nœud de transport
- Switch_id : Attribut de nom de commutateur de la zone de transport du nœud de transport
- Étiquette: Attribut d’id d’interface de l’interface de nœud de transport
- Neighbor_name : Attribut de nom système de l’interface lldp neighbor du nœud de transport
- Neighbor_intf : Attribut nom de l’interface lldp neighbor du nœud de transport
- MTU: Attribut MTU de l’interface de nœud de transport
Les cartes RÉSEAU physiques sont sélectionnées pour le profil de liaison montante dédié au réseau de superposition. Le profil de liaison montante NSX-T définit la configuration de l’interface réseau pour les interfaces PNIC faisant face à la structure Apstra en termes de configuration LAG et LACP. 
Le profil de liaison montante est donc mappé dans un nœud de transport pour les liaisons du commutateur logique NSX-T des hôtes hyperviseur/ESXi. Il s’oriente vers les commutateurs haut de baie (top-of-rack) dans la structure Apstra.
Requête/réponse d’API NSX pour vérifier l’adresse MAC des interfaces de nœud de transport.
Demande:
{
pnic_nodes {
id mac_address
}
}
Réponse:
{
"data": {
"pnic_nodes": [
{
"id": "1e2162c3-9ce6-4f35-afc2-217bb48ced49",
"mac_address": "52:54:00:88:41:28"
},
{
"id": "9752a438-1939-4648-bc8e-0494addf7c7e",
"mac_address": "52:54:00:04:d5:4f"
}
]
}
}
L’adresse MAC indiquée dans l’exemple ci-dessus est apprise sur une interface LAG d’Apstra Fabric vers le nœud de transport NSX-T. Il s’agit de l’adresse MAC des pNICs hôtes ESXi ayant une liaison LAG vers les branches haut de gamme dans la structure Apstra.
La requête/réponse de l’API NSX ci-dessous vérifie l’attribut de nom du commutateur de la zone de transport du nœud de transport.
Demande:
{
pnic_nodes {
id switch_id
}
}
Réponse:
{
"data": {
"pnic_nodes": [
{
"id": "82586be7-2998-401f-82ba-11afa5bb9730",
"switch_id": "zz-cvx-nsxt.cvx.2485377892354-2902673742"
},
{
"id": "0043d742-405a-454f-9e9b-695d5dd14608",
"switch_id": "zz-cvx-nsxt.cvx.2485377892354-2902673742"
}
]
}
}
L’attribut d’ID de commutateur de la zone de transport respective est lu par l’API NSX-T du gestionnaire NSX comme suit : 
Requête/réponse d’API NSX pour vérifier l’interface du nœud de transport.
Demande:
{
pnic_nodes {
id label
}
}
Réponse:
{
"data": {
"pnic_nodes": [
{
"id": "82586be7-2998-401f-82ba-11afa5bb9730",
"label": "eth2"
},
{
"id": "0043d742-405a-454f-9e9b-695d5dd14608",
"label": "eth1"
},
{
"id": "b91a5725-7500-489b-a454-e05d7c311525",
"label": "eth0"
}
]
}
}
Les nœuds de transport mappent des cartes RÉSEAU physiques qui peuvent être considérées comme des étiquettes conformément aux réponses ci-dessus des API NSX-T. 
Vous trouverez ci-dessous la requête/réponse de L’API NSX pour vérifier l’attribut LLDP voisin du nom du système du nœud de transport.
Demande:
{
pnic_nodes {
id neighbor_name
}
}
Réponse:
{
"data": {
"pnic_nodes": [
{
"id": "82586be7-2998-401f-82ba-11afa5bb9730",
"neighbor_name": "leaf-2-525400C6DD2B"
},
{
"id": "0043d742-405a-454f-9e9b-695d5dd14608",
"neighbor_name": "leaf-2-525400C6DD2B"
},
{
"id": "b91a5725-7500-489b-a454-e05d7c311525",
"neighbor_name": "spine-1"
},
{
"id": "f77575fb-44ea-4ec7-9913-1c75b7af87bc",
"neighbor_name": "leaf-1-5254004D5560"
},
{
"id": "628d0f86-4bc1-4faf-8f3f-f1deb92ceee2",
"neighbor_name": "leaf-2-525400C6DD2B"
},
{
"id": "1e2162c3-9ce6-4f35-afc2-217bb48ced49",
"neighbor_name": "leaf-1-5254004D5560"
}
]
}
}
Ici, les branches 1/2 sont des voisins LLDP des nœuds de transport.
Pour obtenir l’attribut lldp neighbor interface nom ci-dessous de nœud de transport respectif peut être utilisé :
Demande:
{
pnic_nodes {
id neighbor_intf
}
}
Réponse:
{
"data": {
"pnic_nodes": [
{
"id": "82586be7-2998-401f-82ba-11afa5bb9730",
"neighbor_name": "leaf-2-525400C6DD2B"
},
{
"id": "0043d742-405a-454f-9e9b-695d5dd14608",
"neighbor_name": "leaf-2-525400C6DD2B"
},
{
"id": "b91a5725-7500-489b-a454-e05d7c311525",
"neighbor_name": "spine-1"
},
{
"id": "f77575fb-44ea-4ec7-9913-1c75b7af87bc",
"neighbor_name": "leaf-1-5254004D5560"
},
{
"id": "628d0f86-4bc1-4faf-8f3f-f1deb92ceee2",
"neighbor_name": "leaf-2-525400C6DD2B"
},
{
"id": "1e2162c3-9ce6-4f35-afc2-217bb48ced49",
"neighbor_name": "leaf-1-5254004D5560"
}
]
}
}
Requête/réponse D’API NSX pour vérifier l’attribut MTU de l’interface de nœud de transport.
Demande:
{
pnic_nodes {
id neighbor_intf
}
}
Réponse:
{
"data": {
"pnic_nodes": [
{
"id": "82586be7-2998-401f-82ba-11afa5bb9730",
"neighbor_intf": "swp4"
},
{
"id": "0043d742-405a-454f-9e9b-695d5dd14608",
"neighbor_intf": "swp3"
},
{
"id": "b91a5725-7500-489b-a454-e05d7c311525",
"neighbor_intf": "eth0"
}
]
}
}
Une taille MTU de 1600 ou supérieure est requise sur tout réseau transportant le trafic overlay geneve. Par conséquent, dans la réponse NSX-T, nous pouvons remarquer la valeur MTU 1600 sur les interfaces réseau vers les nœuds de transport.
VNIC
- Adresse MAC : Attribut d’adresse physique de l’interface virtuelle de nœud de transport ou de vm
- Étiquette: Attribut d’étiquette VNIC du nœud de transport
- Ipv4_addr : Attribut d’adresse IP de l’interface virtuelle du nœud de transport
- Traffic_types : Il est dérivé du type d’interface virtuelle de nœud de transport
- MTU: Attribut MTU de l’interface virtuelle de nœud de transport
Vous pouvez vérifier l’attribut de l’adresse mac VNIC avec la requête/réponse NSX-API ci-dessous. Il peut s’agir de l’interface virtuelle d’un nœud de transport ou de l’interface virtuelle des machines virtuelles. Pour les nœuds de transport sous les commutateurs hôtes, sélectionnez la carte d’interface réseau virtuelle qui correspond à l’adresse MAC de la carte d’interface réseau virtuelle associée au groupe de ports de liaison montante.
Demande:
{
vnic_nodes{
id mac_address
}
}
Réponse:
{
"data": {
"vnic_nodes": [
{
"id": "c84d8636-c28b-4db3-8747-37fadca4c7aa",
"mac_address": "1e:5c:3b:a2:ea:c3"
},
{
"id": "7d5826d8-0622-4a45-88d7-6b1e88bac62f",
"mac_address": "ca:0f:93:24:24:43"
}
]
}
}
NSX-API Demande/réponse pour vérifier le label VNIC, ce qui signifie l’attribut d’id de l’interface de l’interface virtuelle du nœud de transport ou l’attribut de nom d’équipement de l’interface virtuelle de la machine virtuelle.
Demande:
{
vnic_nodes{
id label
}
}
Réponse:
{
"data": {
"vnic_nodes": [
{
"id": "c84d8636-c28b-4db3-8747-37fadca4c7aa",
"label": "hyperbus"
},
{
"id": "7d5826d8-0622-4a45-88d7-6b1e88bac62f",
"label": "nsx-switch.0"
},
{
"id": "473c2b7d-ab2f-41cd-9a4b-fcf2eb248fd6",
"label": "nsx-switch.0"
},
{
"id": "9553390b-754e-45ef-8976-e63396d554ee",
"label": "nsx-vtep0.0"
},
{
"id": "a00bb649-5032-462f-97e7-b6c4f5f1ac86",
"label": "nsx-vtep0.0"
}
]
}
}
Vous trouverez ci-dessous la requête/réponse NSX-API pour vérifier l’adresse Ipv4 VNIC, ce qui signifie l’attribut d’adresse IP de l’interface virtuelle du nœud de transport ou l’interface virtuelle du port logique.
Demande:
{
vnic_nodes{
id ipv4_addr
}
}
Réponse:
{
"data": {
"vnic_nodes": [
{
"id": "9553390b-754e-45ef-8976-e63396d554ee",
"ipv4_addr": "192.168.1.13"
},
{
"id": "a00bb649-5032-462f-97e7-b6c4f5f1ac86",
"ipv4_addr": "192.168.1.12"
}
]
}
}
Ici, « 192.168.1.13 » et « 192.168.1.12 » sont des adresses ipv4 pour l’interface de pont des nœuds de transport hôtes, c’est-à-dire « nsx-vtep0.0 » qui agit comme un point de terminaison de tunnel virtuel (VTEP) du nœud de transport. Chaque hyperviseur dispose d’un VTEP (Virtual Tunnel Endpoint) chargé d’encapsuler le trafic vm dans un en-tête VLAN et de le acheminer vers un VTEP de destination pour un traitement ultérieur. Vous pouvez le comparer à vXLAN Virtual Network anycast GW VTEP IP.
nsx-vtep0.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1600
inet 192.168.1.12 netmask 255.255.255.224 broadcast 192.168.1.31
inet6 fe80::c8ec:50ff:fe69:536 prefixlen 64 scopeid 0x20<link>
ether ca:ec:50:69:05:36 txqueuelen 1000 (Ethernet)
RX packets 60312 bytes 3975194 (3.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31215 bytes 2675310 (2.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
admin@localhost:~$
Requête/réponse d’API NSX pour vérifier les types de trafic de l’interface virtuelle du nœud de transport. Le type de trafic du nœud de transport peut être de type overlay selon l’exemple ci-dessous ou de type VLAN. On peut ajouter à la fois les zones de transport VLAN et NSX superposées aux nœuds de transport.
La zone de transport basée sur le VLAN est principalement destinée au trafic en liaison montante. Dans le cas où les machines virtuelles sur différents hôtes hyperviseurs doivent communiquer entre elles, alors le réseau de superposition doit être utilisé. Il peut être comparé au réseau virtuel VXLAN dans Apstra Fabric.
Demande:
{
vnic_nodes{
id traffic_types
}
}
Réponse:
{
"data": {
"vnic_nodes": [
{
"id": "9553390b-754e-45ef-8976-e63396d554ee",
"traffic_types": [
"overlay"
]
},
{
"id": "a00bb649-5032-462f-97e7-b6c4f5f1ac86",
"traffic_types": [
"overlay"
]
}
]
}
}
Requête/réponse d’API NSX pour obtenir la taille mtu du nœud de transport. La taille MTU des réseaux qui transportent le trafic overlay doit être supérieure ou supérieure à 1600 car elle transporte le trafic overlay geneve. L’interface du noyau N-VDS et DU NOYAU DE LA plate-forme JUNOs doit toutes avoir la même taille MTU à trames jumbo (c’est-à-dire 1600 ou plus).
Demande:
{
vnic_nodes{
id mtu
}
}
Réponse:
{
"data": {
"vnic_nodes": [
{
"id": "9553390b-754e-45ef-8976-e63396d554ee",
"mtu": 1600
},
{
"id": "a00bb649-5032-462f-97e7-b6c4f5f1ac86",
"mtu": 1600
}
]
}
}
L’interface virtuelle, c’est-à-dire NSX VTEP et vswitch, doit avoir un mtu de 1 600 conformément à la capture d’écran ci-dessus.
Stratégie de canal de port
- Étiquette: Attribut de nom du profil de lag de liaison montante du commutateur hôte
- Mode: Attribut de mode du profil de lag de liaison montante du commutateur hôte
- Hashing_algorithm : Attribut d’équilibre de charge du profil de lag de liaison montante du commutateur hôte
Un profil de liaison montante est mappé à un nœud de transport côté NSX-T avec des stratégies pour les liaisons entre les hôtes de l’hyperviseur et les commutateurs logiques NSX-T. 
Les liens entre les hôtes de l’hyperviseur et les commutateurs logiques NSX-T peuvent comprendre la configuration LAG ou Teaming qui doit être associée à des cartes réseau physiques.
NSX-API Request/Response pour vérifier l’attribut de profil LAG de liaison montante du commutateur logique.
Demande:
{
port_channel_nodes {
id label
} id port_channel_policy_nodes {
id label
}
}
Réponse:
{
"data": {
"port_channel_nodes": [
{
"id": "bd86666b-239d-4baa-8715-d73ca40d7100",
"label": null
},
{
"id": "ff5a5b6b-a103-471a-bbfd-ee3dc8c6e1c7",
"label": null
}
],
"id": "rack-based-blueprint-9dfa0044",
"port_channel_policy_nodes": [
{
"id": "59f60d47-ca48-441d-a4a4-e570af7bdb72",
"label": "PTEST-LAG"
}
]
}
}
L’étiquette de profil de liaison montante peut également être associée à une étiquette récupérée à partir de l’interface graphique dans NSX-T Manager comme suit : 
Vous trouverez ci-dessous une requête/réponse NSX-API pour vérifier l’attribut de mode LACP pour le profil LAG de liaison montante.
Demande:
{
port_channel_nodes {
id
} id port_channel_policy_nodes {
id mode
}
}
Réponse:
{
"data": {
"port_channel_nodes": [
{
"id": "bd86666b-239d-4baa-8715-d73ca40d7100"
},
{
"id": "ff5a5b6b-a103-471a-bbfd-ee3dc8c6e1c7"
}
],
"id": "rack-based-blueprint-9dfa0044",
"port_channel_policy_nodes": [
{
"id": "59f60d47-ca48-441d-a4a4-e570af7bdb72",
"mode": "active"
}
]
}
}
NSX-API Demande/réponse pour vérifier l’attribut de l’algorithme d’équilibrage de charge du profil de liaison montante du commutateur hôte.
Demande:
{
port_channel_nodes {
id
} id port_channel_policy_nodes {
id hashing_algorithm
}
}
Réponse:
{
"data": {
"port_channel_nodes": [
{
"id": "bd86666b-239d-4baa-8715-d73ca40d7100"
},
{
"id": "ff5a5b6b-a103-471a-bbfd-ee3dc8c6e1c7"
}
],
"id": "rack-based-blueprint-9dfa0044",
"port_channel_policy_nodes": [
{
"id": "59f60d47-ca48-441d-a4a4-e570af7bdb72",
"hashing_algorithm": "srcMac"
}
]
}
}
À partir de la capture d’écran de profil LAG ci-dessus, il peut être validé qu’il utilise l’algorithme d’équilibrage de charge basé sur l’adresse MAC source.
Vnet
- Vn_type : Attribut de type de transport de la zone de transport
- Étiquette: Attribut de nom d’affichage du commutateur logique
- switch_label : Attribut de nom de commutateur de la zone de transport
- Vlan: Attribut Vlan du commutateur logique pour la zone de transport vlan
- Vni : attribut vni du commutateur logique pour zone de transport overlay
Pour obtenir l’attribut de type de transport respectif de la zone de transport ci-dessous, la requête peut être utilisée. Cela signifie principalement le type de trafic pour une zone de transport qui peut être de type overlay ou VLAN.
Demande:
{
vnet_nodes {
id vn_type
} id
}
Réponse:
{
"data": {
"vnet_nodes": [
{
"id": "a3320cc6-601e-4a81-abe9-8464ae054f18",
"vn_type": "overlay"
},
{
"id": "6bdd7cd9-82eb-433d-8360-076d9daddd1b",
"vn_type": "vlan"
}
],
"id": "rack-based-blueprint-9dfa0044"
}
}
Le type de trafic peut également être identifié dans l’interface graphique du gestionnaire NSX-T comme suit : 
Requête/réponse NSX-API pour vérifier le nom d’affichage du commutateur logique N-VDS.
Demande:
{
vnet_nodes {
id label
} id
}
Réponse:
{
"data": {
"vnet_nodes": [
{
"id": "241ce8e1-b31d-4093-a1a3-2f99a29ac2f9",
"label": "mahi-nsxt-kvm-ls"
},
{
"id": "fef41435-ac20-4c4d-81c0-b7f3059d977b",
"label": "zz-cvx-nsxt.cvx.2485377892354-2902673742_1000"
},
{
"id": "6bdd7cd9-82eb-433d-8360-076d9daddd1b",
"label": "zz-cvx-nsxt.cvx.2485377892354-2902673742_VLAN-100-UPLINK-PROFILE-LAG"
}
],
"id": "rack-based-blueprint-9dfa0044"
}
}
Conformément à la réponse api ci-dessus, « zz-cvx-nsxt.cvx.2485377892354-2902673742_1000 » est le commutateur logique respectif associé à la zone de transport. 
Vous trouverez ci-dessous la requête/réponse NSX-API pour vérifier l’attribut d’ID VLAN d’un commutateur logique basé sur VLAN pour la zone de transport.
Demande:
{
vnet_nodes {
id vlan
} id
}
Réponse:
{
"data": {
"vnet_nodes": [
{
"id": "e0b29951-7739-4ecb-8c87-5725a61f669a",
"vlan": 123
},
{
"id": "cdd0c6d5-fecb-44d8-84c4-06c685e8ef14",
"vlan": 2000
},
{
"id": "fef41435-ac20-4c4d-81c0-b7f3059d977b",
"vlan": 1000
},
{
"id": "6bdd7cd9-82eb-433d-8360-076d9daddd1b",
"vlan": 200
}
],
"id": "rack-based-blueprint-9dfa0044"
}
}
Ici, les ID VNI d’Apstra Fabric 1000 et 2000 représentent ce réseau virtuel VXLAN pour le trafic étiré de couche 2 est-ouest. Le commutateur logique adossé à un pont sur NSX-T doit avoir les mêmes ID VLAN définis.
Requête/réponse NSX-API pour vérifier l’attribut VNI du commutateur logique de NSX-T
Demande:
{
vnet_nodes {
id vni
} id
}
Réponse:
{
"data": {
"vnet_nodes": [
{
"id": "a3320cc6-601e-4a81-abe9-8464ae054f18",
"vni": 67595
},
{
"id": "b7923224-659b-4075-b69b-3edeb5726a32",
"vni": 67589
},
{
"id": "18b81c81-8ae1-46b1-83ca-05cd5b364a1c",
"vni": 67584
}
],
"id": "rack-based-blueprint-9dfa0044"
}
}