Hello mesdames/messieurs, nous en étions resté à un souci assez compliqué à expliquer et comprendre techniquement au sujet de l’implémentation de NSX-T sur du distributed vSwitch 7.0. Apparemment mes explications ont été suffisamment claires pour que des experts me ping/contactent sur Twitter et Slack. Et on a fini par trouver ! Enfin, quand je dis « on » … mais trêve d’intro, passons aux explications hyper-intéressantes.
Il y a eu pas mal d’échange sur twitter après la publication de mon dernier billet (lire ici, commencez par ça, si vous l’avez loupé). Mais finalement, c’est un ami de VMworld depuis plusieurs années, chez VMware, avec qui j’échange régulièrement et dont je vous ai déjà parlé, appelons-le Timo (warf, comme si c’était impossible à retrouver …) qui a trouvé le pot-aux-roses. Après le billet, Timo a mis le doigt quasiment tout de suite sur la cause probable de mes soucis. Il y a des affaires encore « troubles » dans la root cause, mais ce qui est sûr c’est que le MTU, pour une fois, n’était pas en cause.
Rappelez-vous, les Edge Nodes n’arrivaient pas à discuter Geneve avec les Transport Node de mon installation NSX. Ca pinguait, mais il y avait au moins un comportement bizarre vis à vis des payload (la piste du MTU, donc). En réalité c’est le design de l’implémentation lui-même qui était spécifique et qui m’a enduit d’erreur. Comme déjà mentionné, les Edge Nodes sont des machines virtuelles directement montées sur le cluster constitué par les Transport Node. J’ai appris que dans cette configuration particulière, je vais le dire avec mes mots, une VM Edge Node ne sait pas discuter « de l’intérieur » avec un host ayant aussi le rôle de Transport Node. Plus simple encore : quel que soit votre setup, vos transport nodes ne peuvent capter et traiter du traffic geneve QUE depuis un port physique de la machine. Dans la pratique, sans trop se poser de question, vous avez deux solutions pour vous en sortir : soit router en N3 votre traffic GENEVE, en plaçant par exemple les Edges sur un autre subnet que vos transports nodes, soit utiliser non pas un portGroup de votre DVS mais carrément un segment NSX-T via la transport zone VLAN.
J’avoue que même si j’ai compris le principe, comment cela s’articule exactement reste encore assez flou. Je pense qu’il faudrait rentrer dans le code ou le schéma de cablage interne de NSX-T à travers le DVS pour mieux appréhender la situation. Je ne désespère pas qu’on me fasse un petit workshop spécifique. En tout cas, j’ai essayé de vous faire un petit schéma de ce que j’ai compris. J’espère qu’il n’est pas trop déconnant, mais en substance, si vous appliquez ça (faire du routage N3 ou faire ça a travers un segment vlan NSX), ça marchera.
Pour ajouter du contexte, l’excellent blog virten.net avait déjà constaté ce mode de fonctionnement particulier il y a quelques temps et proposé des solutions. Le pire dans l’histoire c’est que j’avais lu – en diagonale – cet article mais je n’avais pas percuté à l’époque. Je vous encourage à vous y rendre pour le lire ici.
Le ponpon est venu d’une info de Timo, encore lui, qui m’a confirmé que, depuis la 3.1 de NSX-T, ces configurations spécifiques sont désormais supportées …. et documentées ! Alors, ok, au final on va dire que c’est de ma faute et que je n’avais pas lu TOUTE la doc. RTFM. Sauf que se palucher les centaines de pages de doc, les tonnes de release notes partout sur vSphere, NSX, et tout le reste … clairement, nous ne sommes pas staffés pour cela chez nous.
Je mettrai à jour ce billet au fur et à mesure que je recevrai des éclairages complémentaires. Si vous êtes un expert NSX-T et que vous passez par là, n’hésitez pas.