🚶🏻 👨🏾 👏🏽 VXLAN dans NSX-V - Sous-couche en difficulté 🤥 🧖🏼 🕟

Salutations, et d'abord quelques petites paroles. J'envie parfois mes collègues travaillant à distance - c'est génial de pouvoir travailler de n'importe où dans le monde connecté à Internet, les vacances à tout moment, la responsabilité des projets et des délais, et de ne pas être au bureau de 8 à 17 ans. Mon poste et mes responsabilités professionnelles excluent pratiquement la possibilité d'une longue absence dans le centre de données. Cependant - des cas intéressants comme celui décrit ci-dessous se produisent occasionnellement, et je comprends qu'il y a peu de positions où il y a une telle marge d'expression créative d'un dépanneur interne.

Un petit avertissement - au moment de la rédaction du présent document, le cas n'était pas complètement résolu, mais compte tenu de la rapidité de la réponse des fournisseurs, une solution complète peut prendre encore quelques mois, et je souhaite partager mes conclusions dès maintenant. J'espère, chers lecteurs, que vous me pardonnerez cette hâte. Mais assez d'eau - qu'en est-il de l'affaire?

Première introduction: il existe une entreprise (où je travaille en tant qu'ingénieur réseau) qui héberge des solutions client dans le cloud privé de VMWare. La plupart des nouvelles solutions se connectent aux segments VXLAN contrôlés par NSX-V - je n'évaluerai pas le temps que cette solution m'a donné, en bref - beaucoup. J'ai même réussi à former mes collègues à configurer NSX ESG et les petites solutions clientes sont déployées sans ma participation. Une note importante est le plan de contrôle avec réplication unicast. Les hyperviseurs sont connectés de manière redondante par deux interfaces à des commutateurs physiques Juniper QFX5100 différents (assemblés dans un châssis virtuel) et la route de stratégie de synchronisation basée sur le port virtuel d'origine est complète.

Les solutions client sont très diverses: de Windows IIS, où tous les composants du serveur Web sont installés sur une seule machine à des serveurs assez volumineux - par exemple, fronts Web Apache à charge équilibrée + LB MariaDB dans Galera + ballons de serveur synchronisés à l'aide de GlusterFS. Presque chaque serveur doit être surveillé séparément, et tous les composants n'ont pas d'adresse publique - si vous avez rencontré ce problème et avez une solution plus élégante, je serai heureux de vous conseiller.
Ma solution de surveillance consiste à «connecter» le pare-feu (Fortigate) à chaque réseau client interne (+ SNAT et, bien sûr, à des restrictions strictes sur le type de trafic autorisé) et à surveiller les adresses internes - de cette manière, une certaine unification et simplification de la surveillance est réalisée. La surveillance elle-même provient d'un cluster de serveurs PRTG. Le schéma de surveillance ressemble à ceci:

Alors que nous ne fonctionnions qu'avec VLAN, tout était assez habituel et fonctionnait comme une horloge. Après la mise en œuvre, NSX-V et VXLAN ont fait face à la question - est-il possible de continuer la surveillance à l'ancienne? Au moment de cette question, la solution la plus rapide était de déployer NSX ESG et de connecter l'interface de ligne réseau VXLAN au réseau VTEP. Rapide entre guillemets - puisque l'utilisation de l'interface graphique pour configurer les réseaux clients, les règles SNAT et de pare-feu peuvent et unifient la gestion dans une seule interface vSphere, mais à mon avis, c'est assez lourd et, entre autres choses, limite l'ensemble d'outils de dépannage. Ceux qui ont utilisé le NSX ESG comme substitut d'un «vrai» pare-feu, je pense, seraient d'accord. Bien qu'une telle solution soit probablement plus stable, après tout, tout se passe dans le cadre d'un fournisseur.

Une autre solution consiste à utiliser le NSX DLR en mode pont entre VLAN et VXLAN. Ici, je pense que tout est clair - l'avantage d'utiliser VXLAN est ringard - car dans ce cas, vous devez toujours tirer le VLAN vers l'installation de surveillance. Soit dit en passant, dans le processus d'élaboration de cette solution, j'ai rencontré un problème lorsque le pont DLR n'a pas envoyé de paquets à la machine virtuelle avec laquelle il se trouvait sur le même hôte. Je sais, je sais - dans les livres et guides sur NSX-V, il est explicitement indiqué qu'un cluster séparé devrait être alloué pour NSX Edge, mais c'est dans les livres ... Quoi qu'il en soit, après quelques mois avec le support, nous n'avons pas résolu le problème. En principe, j'ai compris la logique de l'action - le module principal de l'hyperviseur responsable de l'encapsulation VXLAN n'était pas activé si DLR et le serveur surveillé étaient sur le même hôte, car le trafic ne quitte pas l'hôte et, logiquement, il devrait être connecté au segment VXLAN - l'encapsulation n'est pas nécessaire.Avec le support, nous nous sommes installés sur l'interface virtuelle vdrPort, qui combine logiquement les liaisons montantes et effectue également le pontage / l'encapsulation - là, il a été remarqué un décalage dans le trafic entrant, que j'ai pris pour résoudre dans le cas actuel. Mais comme cela a été dit, je n'ai pas terminé ce dossier jusqu'au bout, car il a été transféré à un autre projet et la succursale était initialement sans issue et il n'y avait pas de volonté particulière de le développer. Si je ne me trompe pas, le problème a été observé dans les versions NSX et 6.1.4 et 6.2.puisqu'elle a été transférée sur un autre projet et que la succursale était initialement en impasse et qu'il n'y avait pas de volonté particulière de la développer. Si je ne me trompe pas, le problème a été observé dans les versions NSX et 6.1.4 et 6.2.puisqu'elle a été transférée sur un autre projet et que la succursale était initialement en impasse et qu'il n'y avait pas de volonté particulière de la développer. Si je ne me trompe pas, le problème a été observé dans les versions NSX et 6.1.4 et 6.2.

Et ici - bingo! Le support natif de Fortinet annonsiruet VXLAN . Et pas seulement point à point ou VXLAN sur IPSec, pas de pontage VLAN-VXLAN basé sur un logiciel - ils ont commencé à implémenter tout cela depuis la version 5.4 (et sont présentés par d'autres fournisseurs), mais un véritable support pour l'avion de contrôle unicast. Lors de la mise en œuvre de la solution, j'ai rencontré un autre problème - les serveurs vérifiés «disparaissaient» périodiquement et apparaissaient parfois dans la surveillance, bien que la machine virtuelle elle-même soit toujours en vie. La raison pour laquelle il s'est avéré que j'ai oublié d'activer Ping sur l'interface VXLAN. En cours de rééquilibrage des clusters, les machines virtuelles se sont déplacées et vMotion s'est terminé avec Ping pour indiquer le nouvel hôte ESXI vers lequel la machine s'est déplacée. Ma stupidité, mais ce problème a une fois de plus miné la crédibilité du soutien qui a été produit - en l'occurrence Fortinet. Je ne dis pas que chaque cas lié au VXLAN commence par la question "où est le commutateur logiciel VLAN-VXLAN dans vos paramètres?" Cette fois, on m'a conseillé de changer le MTU - c'est pour Ping, qui est de 32 octets. Puis "jouer" avec tcp-send-mss et tcp-receive-mss dans la politique - pour VXLAN,qui est encapsulé dans UDP. Pouf, je suis désolé - ça bout. En général, j'ai résolu ce problème par moi-même.

Après avoir réussi à réduire le trafic de test, il a été décidé de mettre en œuvre cette solution. Et dans la production, il s'est avéré qu'après un jour ou deux, tout ce qui est surveillé via VXLAN tombe progressivement. La désactivation / l'activation de l'interface a aidé, mais seulement temporairement. Conscient du ralentissement du support, j'ai commencé à faire du dépannage pour ma part - au final, mon entreprise, mon réseau est de ma responsabilité.

Sous le spoiler se trouve le cours de dépannage. Qui est fatigué des lettres et de la vantardise - sautez et allez à la postanalyse.

Dépannage

, — !

, , . . , Fortigate 5.6+, «diagnose debug flow» — . . , , RFC1918, . VXLAN ...15, ...254, VTEP.

VXLAN- . overlay ARP OVSDB, underlay ARP CAM. Fortigate VXLAN FDB OVSDB. :

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=...47 port=4789 vni=5008 ifindex=7

— MAC VTEP ...47. ESXI , , MAC , VTEP . CAM/ARP — ESXI :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz

— ? Juniper' — , — VLAN VTEP . DLR-, VDR — ESXI , VMWare. MAC «97:6e» , vmnic1 — , VTEP ...47 "--dir 2":

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

— ARP . ARP . , ...15 — ICMP ? , . , ( teaming policy), vNIC , , :

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

, . . — — VDR, . , , , . «» Ethernet underlay. - MAC VTEP IP. , , — , . ARP , . Ethernet :

fortigate (root) #get sys arp | grep ...47
...47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep ...42
...42 0 00:50:56:6a:78:86 dmz

Donc, qu'avons-nous à la fin - après la migration de la machine virtuelle, le fortifié essaie d'envoyer du trafic vers VTEP depuis le (correct) VXLAN FDB, mais utilise le mauvais MAC DST et le trafic devrait être rejeté par l'interface d'hyperviseur de réception. De plus, dans un cas sur quatre, ce MAC appartenait à l'hyperviseur d'origine, à partir duquel la migration de la machine a commencé.

Hier, j'ai reçu une lettre du support technique de Fortinet - dans mon cas, ils ont ouvert le bug 615586. Je ne sais pas comment me réjouir ou pleurer: d'une part, le problème n'est pas dans les paramètres, d'autre part, le correctif ne viendra qu'avec la mise à jour du firmware, dans le meilleur des cas le suivant. La FAQ réchauffe également un autre bogue que j'ai découvert le mois dernier, bien qu'à cette époque dans le HTML5 GUI vSphere. Eh bien, le service d'assurance qualité local des fournisseurs est direct ...

Je vais oser suggérer ce qui suit:

1 - le plan de contrôle de multidiffusion ne sera probablement pas affecté par le problème décrit - après tout, les adresses MAC VTEP sont obtenues à partir de l'adresse IP du groupe auquel l'interface est abonnée.

2 - très probablement le problème des fortics dans les sessions de déchargement sur le processeur réseau (approximativement analogue à CEF) - si chaque paquet est passé par le CPU, des tables contenant les informations correctes - au moins visuellement - seront utilisées. En faveur de cette hypothèse, c'est ce qui aide à fermer / ouvrir l'interface ou à attendre un certain temps - plus de 5 minutes.

3 - changer la politique d'association, par exemple, en basculement explicite, ou introduire le LAG ne résoudra pas le problème, car le MAC coincé sur l'hyperviseur d'origine dans les paquets encapsulés a été observé.

À la lumière de cela, je peux partager ce que j'ai récemment découvert un blogoù dans l'un des articles, il a été déclaré que les pare-feu solides et les méthodes de transfert de données en cache sont des béquilles. Eh bien, je n'ai pas autant d'expérience en informatique pour dire la même chose, et je ne suis pas d'accord avec toutes les déclarations des articles de blog tout de suite. Cependant, quelque chose me dit qu'il y a du vrai dans les mots d'Ivan.

Merci de votre attention! Je serai heureux de répondre aux questions et d'entendre des critiques constructives.

VXLAN dans NSX-V - Sous-couche en difficulté

More articles: