Je vous ai menti, je m’en veux, j’en suis désolé. A la fin de la partie 1 de cette chronique, tout semblait rouler et les problèmes d’installation de NSX-T étaient en passe d’être résolus, étant donné que la cause, le MTU, était identifiée. Mais en fait non, le problème était plus profond que cela. Je vous explique.
J’ai abandonné … je vous avais laissé lors de la partie 1 (voir ici) avec un cluster vSphere opérationnel tout comme NSX-T. Mais en fait non. Techniquement j’en étais resté au souci de MTU. Très exactement, voici la situation avant ce piteux abandon.
Concernant m’installation des ESXi transport nodes via l’outillage NSX-T, tout a fonctionné parfaitement. Les serveurs sont configurés et se ping entre eux (plus exactement, ils se vmkpingues ^^) via leur vmknics VXLAN/GENEVE avec des payload de taille variés. Précision tout de même : étant en environnement full vSphere 7, je me dis, tant qu’à faire, utilisons le distributed vSwitch plutôt que le NVDS dédié NSX-T pour le transport SDN.
esxcfg-vmknic -l Interface Port Group/DVPort/Opaque Network IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type NetStack vmk0 36 IPv4 10.167.2.101 255.255.255.0 10.167.2.255 54:ab:3a:72:3e:20 1500 65535 true STATIC defaultTcpipStack vmk2 38 IPv4 10.167.2.141 255.255.255.0 10.167.2.255 00:50:56:6f:25:ac 1500 65535 true STATIC defaultTcpipStack vmk1 7 IPv4 10.167.2.121 255.255.255.0 10.167.2.255 00:50:56:6e:4a:77 1500 65535 true STATIC vmotion vmk10 558ca23f-7e82-46bd-91a4-08783d6a2e9a IPv4 192.168.0.107 255.255.255.0 192.168.0.255 00:50:56:61:e4:d4 9000 65535 true STATIC vxlan vmk50 093cccc5-ff1e-48e6-a8d1-b0bc32d11159 IPv4 169.254.1.1 255.255.0.0 169.254.255.255 00:50:56:6f:a1:7f 9000 65535 true STATIC hyperbus [root@esxtst01:~] vmkping -S vxlan -I vmk10 -s 9000 192.168.0.103 PING 192.168.0.103 (192.168.0.103): 9000 data bytes 9008 bytes from 192.168.0.103: icmp_seq=0 ttl=64 time=0.297 ms 9008 bytes from 192.168.0.103: icmp_seq=1 ttl=64 time=0.258 ms
… dans cet example, l’ESXi 01 ping un de ses conjoints de cluster avec un payload de 9000 octets, sans aucun souci. Et bé alors, c’est bon ? Oui mais non, car après les transport nodes, vient le temps des deux edges nodes, créés sur sein du même cluster. Cette configuration est désormais supportée depuis la 3.0 il me semble. Le déploiement des edges se passe lui aussi très bien, tout ce petit monde ping depuis l’extérieur. Vient le temps d’un vrai test complet. Router TIER0 configuré, un premier segment monté, tout roule. Enfin, vient le temps de placer une VM fraichement clonée sur ce segment.
Là, c’est le drame, rien ne passe, la VM ne communique pas avec le reste du monde. Je note également que chaque edge node a deux tunnels geneve déclarés, mais l’un d’entre eux est down. Le tunnel qui fonctionne bien correspond à celui montée avec sa copine. En gros, les deux edges se voient bien et communiquent correctement. Par contre, pour chaque edge, le tunnel qui ne monte pas essaye de communiquer avec le transport node qui héberge actuellement la machine virtuelle. C’est la que ça se complique et que je passe du temps à débugguer, mais j’arrive tout de même au constat que les transport nodes ping bien les edges nodes MAIS UNIQUEMENT avec des payloads dont la taille est inférieure à 1500 octets. Bingo, je fais le tour des MTU (comme on fait le tour des popottes, en somme), dans les profil d’uplink NSX, dans vSphere sur le dvSwitch 7 utilisé comme support et, évidemment sur l’infra physique. Rien de rien, tout est nickel. Rappelez-vous, les transport node pinguent parfaitement entre eux jusqu’à 9000 !
Pour résumer et histoire d’enfoncer le clou pour les experts qui par hasard me liraient (coucou Woueb ? coucou Mikael ? coucou tous ^^), les deux edges pinguent entre elles parfaitement jusqu’à 9000 octets, les transports nodes entre eux aussi, mais impossible de faire transiter des trames de payload supérieures à 1500 entre edge et transport, forcément, ça marche moins bien … Je rajoute que tout se passe au sein d’un même VLAN, donc pas de MTU qui passerait en N2 mais pas en N3, les edges sont cablés sur le même VLAN physique que les transport nodes Malgré plusieurs appels (notamment auprès de VincentF dont j’ai déjà parlé), des recherches Google et des vérifications complètes, rien n’y fait. En désespoir de cause, il est 15h ce Vendredi, il me reste un peu de temps pour en avoir le coeur net : ma première fois avec un distributed vSwitch 7 n’étant visiblement pas brillante, recommençons avec un bon « vieux » nvds, même si cela m’oblige à monopoliser une vmnic pour ça sur nos vieux serveurs. Je dé-cable logiquement tout ce que j’ai déjà monté en dvs 7 et je reconstruis à l’identique, sans toucher à quoi que ce soit coté physique, ni même sur les profils d’uplink. Je change juste de support overlay en somme. … Et …
… BINGO ! Tout marche du premier coup, les tunnels montent, mes tests DFW, NAT, DHCP fonctionnent parfaitement.
J’en suis là. Personne ne comprend ce qui se passe, alors de deux choses l’une, soit, lors de l’install, j’ai malencontreusement implanté un paramètre spécifique dans les Edges (mais je ne vois pas lequel) lors de leur déploiement qui a fait « merder le machin », soit je suis face à un bug spécifique lié à l’utilisation d’un vDS7 avec une pair de Edge Nodes sur NSX-T 3.1.3.1 et le tout au sein d’un même cluster vSphere.
Je suis en train de me dire que pour pouvoir aller plus loin, il va falloir que je me résolve à casser tout une troisième fois et reconstruire à nouveau un NSX-T basé sur dvs 7. Si ça marche, ça confirmera que j’ai entré un paramètre incorrect à un moment lors du premier essai. Si ça ne marche toujours pas mieux, et la c’est plus intéressant, finalement, l’option « bug » devient de plus en plus probable. De votre coté, avez-vous déjà expérimenté NSX-T à travers l’usage des vDS 7 ?
La suite au prochain épisode …