Mappage d’inventaire NSX-T à l’infrastructure virtuelle Apstra
Aperçu
Le logiciel Apstra peut se connecter à l’API NSX-T pour collecter des informations sur l’inventaire d’hôtes, de clusters, de machines virtuelles, 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 (ou VM) en cours d’exécution et les alerter de toute incohérence susceptible d’affecter la connectivité des charges de travail. La visibilité sur l’infrastructure virtuelle d’Apstra permet de fournir une visibilité sur la corrélation underlay/overlay et d’utiliser 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 indiqué ci-dessus, la collecte de l’inventaire des captures 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. Veuillez également trouver la corrélation respective par rapport à Apstra.
Transport Zones
Les zones de transport (TZ) définissent un groupe d’hôtes ESXi qui peuvent 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 à la fois par les nœuds de transport ou par les dispositifs NSX Edge. Lorsqu’un hôte ESXi ou un nud de transport NSX-T Edge est ajouté à une zone de transport de superposition, un N-VDS est installé sur l’hôte ESXi ou le nœud NSX Edge.
- Zone de transport VLAN : elle peut être utilisée par NSX Edge et les nœuds de transport hôtes pour ses liaisons montantes VLAN.
Chaque hôte de l’hyperviseur ne peut appartenir qu’à une seule zone de transport à un moment donné.
Comme indiqué dans les captures d’écran ci-dessous, un VN VLAN nouvellement créé, étiqueté vers une interface de la fabric Apstra, correspond à une zone de transport basée sur le VLAN : 
Ici, le VLAN balisé VN est mappé à la zone de transport respective dans NSX-T avec le type de trafic VLAN. 
N-VDS
Un commutateur distribué virtuel géré par NSX fournit le transfert sous-jacent et constitue le plan de données des nœuds de transport.
Voici quelques avantages notables concernant les commutateurs virtuels N-VDS :
- Les pnic sont des ports physiques sur l’hôte ESXi
- pnic peuvent être regroupés pour former une agrégation de liens (LAG)
- les liaisons montantes sont les interfaces logiques d’un N-VDS
- des cartes réseau ou des LAG sont affectés aux liaisons montantes
Ici, les TEP sont des points de terminaison de tunnel utilisés pour la mise en réseau de superposition NSX (encapsulation/décapsulation de Genève). P1/P2 sont des pNIC mappées 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 des commutateurs virtuels connectés aux périphériques de feuille physiques ToR comme suit : 
Noeud de transport
Il s’agit d’un nœud capable de participer à un réseau VLAN ou à un overlay de centre de données NSX-T. 
Les machines virtuelles hébergées sur différents nœuds de transport communiquent de manière transparente sur le réseau superposé. Un noeud de transport peut appartenir à :
- Plusieurs zones de transport VLAN.
- Au maximum une zone de transport superposée avec un N-VDS standard.
Cela peut être comparé à la configuration d’hôtes finaux (serveurs) dans un blueprint Apstra pour qu’ils fassent partie d’un réseau virtuel VLAN (leaf-local) ou VXLAN (inter-leaf).
Nœud NSX Edge
NSX Edge fournit des services de routage et de connectivité aux réseaux externes au déploiement NSX-T. Il est nécessaire pour établir une connectivité externe à partir du domaine NSX-T, via un routeur de niveau 0 via BGP ou un routage statique.
Les machines virtuelles NSX Edge ont des liaisons montantes vers des feuilles ToR nécessitant une zone de transport VLAN distincte. La structure Apstra doit être configurée avec le réseau virtuel VLAN correspondant. 
Les facteurs de forme NSX-T Edge Bare Metal ou VM sont des nœuds de transport et sont découverts en tant qu’hyperviseurs dans Apstra. Toutefois, les nœuds de transport en périphérie de machine virtuelle ne peuvent pas être corrélés à la feuille ToR connectée.
NSX Controller Cluster
Il fournit des fonctions de plan de contrôle pour les composants logiques de commutation et de routage NSX-T Data Center.
NSX Manager
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 de serveur dans un Blueprint connecté aux équipements de branche ToR. Dans NSX-T Data Center, 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 pour les réseaux virtuels sur la fabric Apstra ou entre les réseaux sur les nuds. 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 nuds de serveur dans le blueprint.
- Le PNIC correspond à la carte réseau physique sur ESXi ou sur l’hôte hyperviseur. Les PNIC de l’hyperviseur peuvent être corrélés à l’interface serveur sur le Blueprint. La configuration du LAG ou de l’association s’effectue sur les liens mappés à ces cartes réseau physiques. Cela peut être corrélé à la configuration de liaison effectuée sur les équipements de branche ToR vers les serveurs finaux.
- Dans l’intégration de NSX-T avec les machines virtuelles Apstra, les réseaux virtuels sont découverts. Celles-ci peuvent être corrélées à des réseaux virtuels directeurs. Dans le cas où les machines virtuelles doivent communiquer entre elles via des tunnels entre hyperviseurs, les machines virtuelles 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), tel qu’un ID de VLAN. Cela correspond aux VNI VXLAN 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 à laquelle la structure est confrontée 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 top-of-rack dans la fabric Apstra.
- La carte d’interface réseau virtuelle définit l’interface virtuelle des nuds de transport ou des machines virtuelles. Le commutateur N-VDS mappe les cartes réseau physiques à ces interfaces virtuelles de liaison montante. Ces interfaces virtuelles peuvent être corrélées aux ports d’interface serveur de la fabric Apstra.
Détails du modèle et relation
Hyperviseur
- Hostname: Attribut FQDN du nœud de transport
- Hypervisor_id : Attribut Id du noeud de transport
- Étiquette: Attribut Nom d’affichage du noeud de transport
- Version: Version de NSX-T installée sur le nœud de transport
Pour obtenir la réponse de l’API NSX-T pour les hôtes de l’hyperviseur respectifs et comprendre la corrélation, vous pouvez utiliser une requête graphique. Pour ouvrir l’explorateur GraphQL, cliquez sur le bouton 
« >_ »
Après cela, dans l’explorateur de graphes, nous pouvons taper une requête graphique sur la gauche, comme indiqué dans la capture d’écran ci-dessous, en utilisant GraphQL : 
Pour vérifier l’étiquette respective pour les nœuds de transport ci-dessous, la requête peut être utilisée :
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 qui agissent comme des 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 pour les 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"
}
]
}
}
Hyperviseur PNIC
- Adresse MAC : Attribut d’adresse physique de l’interface du 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 du nœud de transport
- Neighbor_name : Attribut de nom système du voisin lldp de l’interface du nœud de transport
- Neighbor_intf : Nom attribut du voisin lldp de l’interface du nœud de transport
- MTU: MTU de l’interface du nœud de transport
Les cartes réseau physiques sont sélectionnées pour un profil de liaison montante dédié au réseau overlay. 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. 
Ainsi, le profil de liaison montante est mappé dans le nœud de transport pour les liaisons du commutateur logique NSX-T des hôtes de l’hyperviseur/ESXi. Il pointe vers les commutateurs top-of-rack dans la fabric Apstra.
Demande/réponse NSX-API pour vérifier l’adresse MAC des interfaces du 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 dans Apstra Fabric vers le nœud de transport NSX-T. Il s’agit de l’adresse MAC des cartes réseau PNIC de l’hôte ESXi ayant une liaison LAG vers les équipements Leaf ToR dans la structure Apstra.
La demande/réponse NSX-API ci-dessous vérifie l’attribut de nom de 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"
}
]
}
}
Les attributs d’ID de commutateur de la zone de transport respective sont lus par l’API NSX-T à partir de NSX Manager comme suit : 
Demande/réponse NSX-API 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 ont le mappage des cartes réseau physiques qui peuvent être renvoyées sous forme d’étiquettes en fonction de la réponse de l’API NSX-T ci-dessus. 
Vous trouverez ci-dessous la requête/réponse de NSX-API pour vérifier l’attribut Nom du système voisin LLDP 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 Leaf1/2 sont des voisins LLDP des nœuds de transport.
Pour obtenir l’attribut de nom d’interface voisine LLDP du nœud de transport respectif, la requête ci-dessous peut être utilisée :
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"
}
]
}
}
NSX-API Request/Response pour vérifier l’attribut MTU de l’interface du 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 de MTU égale ou supérieure à 1600 est requise sur tout réseau qui achemine le trafic overlay de Genève. 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.
Carte d’interface réseau virtuelle
- Adresse MAC : Attribut d’adresse physique de l’interface virtuelle du nœud de transport ou de la machine virtuelle
- Étiquette: Attribut d’étiquette de la carte d’interface réseau virtuelle 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 du nœud de transport
- MTU: Attribut MTU de l’interface virtuelle du nœud de transport
Vous pouvez vérifier l’attribut d’adresse MAC de la carte d’interface réseau virtuelle à l’aide de la demande/réponse NSX-API ci-dessous. Il peut s’agir de l’interface du nœud de transport, de l’interface virtuelle ou de l’interface virtuelle des machines virtuelles. Pour les nœuds de transport, sous Commutateurs hôtes, sélectionnez la carte réseau virtuelle qui correspond à l’adresse MAC de la carte réseau de machine virtuelle attaché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"
}
]
}
}
Demande/réponse NSX-API pour vérifier l’étiquette de la carte d’interface réseau qui signifie l’attribut d’ID d’interface de l’interface virtuelle du nœud de transport ou l’attribut de nom de périphérique 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 demande/réponse NSX-API pour vérifier l’adresse VPC4 de la carte d’interface réseau VNIC qui signifie l’attribut d’adresse ip de l’interface virtuelle du nœud de transport ou de 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 point de terminaison de tunnel virtuel (VTEP) chargé d’encapsuler le trafic de la machine virtuelle dans un en-tête VLAN et d’acheminer le paquet vers un VTEP de destination pour un traitement ultérieur. Cela peut être comparé au réseau virtuel VXLAN 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:~$
Demande/réponse NSX-API pour vérifier les types de trafic pour l’interface virtuelle du nœud de transport. Le type de trafic du nœud de transport peut être de type overlay comme dans l’exemple ci-dessous ou il peut être de type VLAN. Il est possible d’ajouter à la fois le VLAN et les zones de transport NSX superposées aux nœuds de transport.
La zone de transport basée sur VLAN est principalement destinée au trafic en liaison montante. Dans le cas où des machines virtuelles sur différents hôtes d’hyperviseur doivent communiquer entre elles, un réseau de superposition doit être utilisé. Il peut être comparé au réseau virtuel VXLAN dans la fabric Apstra.
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"
]
}
]
}
}
Demande/réponse NSX-API pour obtenir la taille mtu du nœud de transport. Pour les réseaux qui acheminent le trafic overlay Geneve, la taille de MTU doit être supérieure ou égale à 1600. Les interfaces du noyau N-VDS et TEP doivent toutes avoir la même taille MTU de trame 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
}
]
}
}
Ainsi, l’interface virtuelle, c’est-à-dire NSX, VTEP et vswitch, doit avoir une MTU de 1600, comme indiqué dans la capture d’écran ci-dessus.
Politique de canal de port
- Étiquette: Nom attribut du profil de décalage de liaison montante du commutateur hôte
- Mode: Attribut de mode du profil de décalage de liaison montante du commutateur hôte
- Hashing_algorithm : Attribut de l’algorithme d’équilibrage de charge du profil de décalage de liaison montante du commutateur hôte
Un profil de liaison montante est mappé dans 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 liaisons entre les hôtes de l’hyperviseur et les commutateurs logiques NSX-T peuvent inclure la configuration LAG ou Teaming qui doit être liée aux cartes réseau physiques.
Demande/réponse NSX-API 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 mise en correspondance avec une étiquette récupérée à partir de l’interface graphique de NSX-T Manager, comme ci-dessous : 
Vous trouverez ci-dessous la demande/réponse de 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"
}
]
}
}
Demande/réponse NSX-API pour vérifier l’attribut d’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 du profil LAG ci-dessus, il peut être confirmé 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 Nom d’affichage du commutateur logique
- switch_label : Attribut Nom du 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 la zone de transport de superposition
Pour obtenir l’attribut de type de transport respectif de la zone de transport ci-dessous, la requête peut être utilisée. Il s’agit principalement du type de trafic d’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 de NSX-T Manager comme suit : 
NSX-API Request/Response 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"
}
}
Ici, selon la réponse de l’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 demande/réponse NSX-API permettant de 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, dans la structure Apstra, les ID VNI 1000 et 2000 représentent un réseau virtuel VXLAN pour le trafic étendu de couche 2 est-ouest. Les mêmes ID de VLAN doivent être définis sur le commutateur logique SDN sur NSX-T.
Demande/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"
}
}