Après une première partie assez facile finalement, on va rentrer un peu plus dans le coeur du produit cette fois-ci en créant une petite topologie purement NSX-T avec de l’overlay, du edge node et dur logical router. Super simple, vous allez voir. Quoi, vous n’êtes pas convaincu ? Prenez la pilule rouge et suivez-moi au fond du gouffre …

Avant d’aller plus loin, juste un petit rappel, qui tombe sous le sens en fait, mais qui permet de démystifier un peu ce qu’on va faire ici. NSX, c’est quoi finalement ? Ce n’est ni plus ni moins qu’un logiciel qui “virtualise” l’ensemble des concepts réseaux utilisés au quotidien dans le monde physique. Oui, mais il doit aussi gérer une complexité de plus, établir un pont entre le virtuel et le physique, comme l’ont fait les hyperviseurs à leurs débuts. Switch, routeur, firewall, QoS, port, tout cela est repris à l’identique ou presque et le plus difficile consiste en fait à bien visualiser ce qu’on veut faire et où aller chercher les bons menus pour faire ce qu’on veut. Je vous rassure, sans formation NSX-T initiale je m’y suis un peu perdu ce week-end en rédigeant le début de cette série d’articles. Ce n’est qu’en revenant aux fondamentaux et un peu de papier/crayon que j’ai retrouvé mon chemin. Et histoire de mettre un peu de piment dans ce récit, vous pourrez lire une jolie découverte durant ce récit.

Notre objectif

Pour avoir justement un guide à suivre, nous allons construire un environnement assez simple constitué d’un routeur tier0 unique, sur lequel on va brancher un segment constitué de deux/trois vms et quelques règles de sécurité. Un petit environnement qui va nous permettre de bien comprendre la logique de construction et des flux. Commençons d’abord par les fondamentaux.

On repart d’une page blanche : transportZones, Transport Node

Commençons par la création et la configuration des transportZones. Je ne vais pas trop détailler cette partie, sachant qu’on a déjà vu ce process lors de la partie 1. Voici le schéma de construction que nous allons utiliser :

En effet, nous allons devoir créer cette fois-ci deux transport zones, une de type overlay GENEVE, qui assurera les fonctions de communication entre Edge Node(s) et Transport Node(s), et une seconde de type VLAN qui va être utilisée pour assurer la communication de notre Edge vers l’extérieur (le réseau physique). Chaque transport zone s’appuiera sur un NVDS spécifique, comme vous pouvez le voir sur le schéma plus haut. Chaque NVDS sera connecté au réseau physique sur une vmnic dédié, coté ESXi (transport node).

Nous allons aussi créer, contrairement à la dernière fois, un profil d’uplink spécifique à chaque transport zone. On va même commencer par ça. Pour la transport zone de type GENEVE, on va indiquer spécifiquement le vlan de transport 300 (champ “Transport VLAN”) ainsi que le MTU à 9000. Pour l’autre, on laisse tel quel.

Ensuite, on va configurer notre Transport Node avec ces deux transport zones geneveTZ et vlanTZ. Vous noterez que pour le nvds-geneve-tz, on a rajouté un IPpool (qui est grisé sur le nvds-vlan-tz) qui va permettre à ce node de récupérer une ip spécifique pour son interface TEP GENEVE (TEP = Tunnel EndPoint). Vous verrez plus tard que notre Edge Node va aussi aller piocher une IP dans ce pool afin justement de pouvoir discuter GENEVE avec le transport node.

Déploiement du Edge Node

Voici le schéma de construction logique de notre système Edge Node / Logical Router / Logical Switch “edge” :

On s’attaque maintenant à la création de la Edge Node. Cette virtual appliance (qui peut également être déployée en bare-metal dans des environnements ou les débits réseau sont très importants) va s’occuper d’héberger les différents distributed routers (tier0 et éventuellement tier1). Normalement, il faut en déployer au moins deux pour pouvoir assurer une disponibilité suffisante à ce composant critique de NSX-T, mais on va se contenter d’une seule instance.

Notre Edge va disposer d’un ensemble de 3 interfaces configurées : une première interface de management, portant l’ip correspondante (192.168.1.8/24), une seconde interface qui va être connecté à notre vlan d’overlay GENEVE, le vlan 300, et une troisième qui va être branché sur un dvPortGroup en mode trunk. Son déploiement est automatique, comme vous pouvez le voir sur le screenshot vSphere. NSX-T importe une ova dans le cluster/host qu’on a indiqué et la paramètre directement.

On termine cette partie en créant un cluster Edge Node, dans lequel on va ajouter la Edge fraichement créée.

Segment, logical router, Tier0 Gateway … j’y comprends plus rien

Maintenant, on va changer de section et passer dans “Advanced Networking & Security”. On commence par créer notre logical switch qui va permettre de raccorder notre Logical Router au monde extérieur. Comme indiqué dans le schéma plus haut, on va faire simple et créer un LS taggé sur le VLAN 200, vlan de sortie ou notre logical router aura une présence “physique” vis à vis du monde.

… et bien NON !..

Mais, qu’est-ce que je raconte ? Pourquoi une mise à jour de ce billet avant même qu’il soit sorti ? Et bien tout simplement parce qu’alors que j’étais en train de l’écrire en ayant orienté une grosse partie de mon tutoriel autour de la section “Advanced Network & Security”, un certain Romain, dont j’ai déjà parlé, m’a ouvert les yeux, ou plutôt, à l’occasion d’une discussion autour des commentaires dans le premier article de cette série, me les a “ré-orienté” vers la section “Networking”. En substance et pour résumer, sachez que cette section “Networking” n’existe que depuis la version 2.4 de NSX-T. En fait, il se trouve que celle-ci est sensé remplacer en grande partie la section “Advanced Networking and security” et utilise une nouvelle terminologie, qui plus est. Oui, vous avez bien lu, VMware a revu sa copie entre la 2.3 et la 2.4 (comme quoi, NSX-T reste un produit jeune ^^) et à choisi de renommer certains concepts et les a appliqué à une nouvelle section “Networking”. Sachez aussi que cette section utilise également un nouveau jeu d’API spécifique. Pour illustrer ça, une seule info, si vous deviez n’en garder qu’une : ceux qui se posaient (comme moi) la question de la différence entre “segment” et “logical switch” …. et bien il n’y en a pas, ce n’est qu’un changement de terminologie !

Bref, toute cette digression pour vous dire qu’il faut désormais travailler plutôt avec la section Networking, au moins pour tout ce qui concerne les “segments” (du coup, je prends le pli tout de suite ^^) et les Tier0/Tier1 Gateways (précédemment appelés Tier0/Tier1 routers).

Pour faire le tour de la question, je vous conseille vivement de faire un tour sur cette page pour faire le tour des concepts NSX et les équivalences récentes, chez VMware ici-même.

Un grand merci à Romain, pour le coup.

Création de notre segment d’interconnexion avec l’extérieur et de notre gateway Tier0

Bon, maintenant que tout est clair, reprenons notre aventure. Nous en étions restés à la fin de la création de notre Edge Cluster. Il faut désormais que l’on créé un segment qui va pointer vers notre VLAN externe cible sur lequel on va connecter notre routeur Tier0 ensuite.

Rendons-nous donc dans la section “Networking” (bon petit soldat ^^) puis dans la partie “Segments”. Nous allons créer un segment très simple connecté au VLAN 200 utilisant la transport zone vlanTZ. Ensuite, on va se placer dans le menu “Tier0 Gateways” et ajouter notre router. Une fois créé on va venir connecter son port uplink directement au segment précédemment créé afin de le brancher sur le vlan 200 de sortie. Je vais lui affecter une ip sur le range de mon vlan 200, à savoir la 192.168.1.250. Enfin, on va rajouter à ce routeur une route statique globale “0.0.0.0/0” qui pointe vers ma gateway interne (une pfSense pour info).

Le pays des merveilles est à notre portée !

Ce deuxième billet est terminé. On est arrivé à nos fin pour la partie infra pure : construire un environnement NSX-T fonctionnel avec un routeur Tier0. Le prochain sera consacré à la création des segments ad-hoc, l’intégration de quelques VM et quelques règles de sécurité associées (et vérifier que ça marche ^^)