Premier épisode d'une longue série ! Dans cette série, je vais essayer de démythifier le WAN et pour ce faire, je vais virtualiser tous les services (ou du moins ce que je peux) d'un backbone opérateur. Cet épisode posera les bases de mon projet et quelques définitions seront données pour que vous puissiez comprendre mon vocabulaire (qui n'est toujours pas très clair, je le reconnais !)
Présentation de l'infra
Parlons Hardware :
Pour virtualiser un backbone opérateur, il me fallait une grosse machine. Pas l'envie d'acheter un Dell rackable, le bruit et l'énergie sont très contraignant et l'héberger dans un datacenter reviendrait assez cher. Il existe aussi les mini pc, qui, sont, certes efficaces, mais pour les besoins que j'ai, il m'en aurait fallu un très puissant donc cher et j'avais envie de prendre une machine dans le cloud !
J'ai donc opté pour un serveur dédié low-cost SYS-2-SSD-32 chez OVH. Pour 29,99€ par mois, j'ai un Intel Xeon D1540 - 8c/16t, 32 Go de RAM et 450 Go de NVMe en RAID 0. Amplement suffisant pour mes besoins (même si les vEOS d'Arista sont assez lourdes, on en parle juste en dessous).
Par la suite, je vais acheter un petit NUC que je poserai chez moi et je monterai un IPsec avec ce serveur pour virtualiser mes différents services (Radius, Ldap, Tacacs, Grafana/Prometheus, ELK, etc). 4 coeurs et 16 Go de RAM devraient être amplement suffisant. On en parlera dans un autre épisode ! Et si jamais l'envie me prend, pourquoi pas un cluster de Proxmox en 8.X pour faire de l'EVPN/VXLAN directement avec les spines et avec du CEPH pour le stockage !
Parlons Virtualisation :
Plusieurs solutions se sont sur le marché : GNS3, EVE-NG et .......... c'est tout ! Pas grand chose de viable enfaite.
Personnellement, je n'aime pas GNS3. Très peu de documentation et obligation d'installer leur client lourd, du moins à l'époque. Je suis donc parti sur EVE-NG (https://www.eve-ng.net/). Une version communauté gratuite est disponible et une autre payante. Leur documentation est très claire et c'est simple à installer. C'est basé sur Ubuntu (20.04 et 22.04) avec deux méthodes d'installation : un script .sh ou directement avec l'ISO.
Parlons IOS :
C'est bien beau d'avoir un serveur de configuré mais il faut bien des images pour virtualiser des switchs et des routeurs.
Je suis parti sur du Cisco, de l'Arista et des Mikrotik. Toutes les images sont disponible gratuitement. Celle des Arista et des Mikrotik sont disponibles sur leur site Web et pour Cisco, j'utilise les vIOS qui sont gratuits tant qu'ils ne sont pas utilisés dans un cadre commercial.
Pourquoi ces 3 constructeurs ? Cisco car Cisco 😝. Malheureusement, c'est très compliqué de s'en séparer. Ils peuvent être remplacés par du Juniper/Nokia mais je n'aime pas le langage. Ils serviront uniquement pour mes besoins de LNS. Arista car ils ont développé leur produit avec comme ligne de conduite le VXLAN. Et pour les Mikrotik, c'est pas cher, puissant, le langage se rapproche d'un Linux et sont très utilisés en tant que CPE.
Par contre, les Arista sont très lourds (1 Coeur/2go Ram par switch). Quant aux autres, ils sont suffisamment légers pour dire qu'ils sont négligeables par rapport aux Arista !
C'est bien beau tout ce blabla mais avec un schéma, c'est tout de suite plus compréhensible !
Voici l'architecture que je vais utiliser au début. Au fur et à mesure du projet, elle risque de bouger.
Mais déjà plein de mots inconnus !! Je vais vous expliquer pourquoi cette architecture et quelques définitions.
Définitions
Pour qu'on parle tous le même langage, je suis obligé de faire le prof (juste une petite dizaine 😄).
Internet = Interconnexion de beaucoup de réseau
Niveau X = Niveau sur le modèle OSI (1 = physique, 2 = Ethernet, 3 = IP, etc)
OI = Opérateur d'Infrastructure (possédent le niveau 1)
OC = Opérateur Commercial (Opérateur BtoB et BtoC alternatif)
Backbone = Coeur de réseau
CPE = Customer Premises Equipment (Routeur en bout de ligne chez le client)
Collecte = Une manière, que l'OC possède, de pouvoir proposer des liaisons fibres/cuivre à des utilisateurs finaux
RFC = Request For Comment (Définition de tout l'Internet)
PPP = Point-To-Point Protocol (RFC 1661). Utilisé pour délivrer une IP pour le CPE
LNS = L2TP Network Server. Serveur où va terminer les liaisons PPP
Radius = Serveur d'authentification (AAA)
BR = Border Router (le routeur le plus proche d'Internet dans le backbone)
J'en détaillerai d'autres par la suite et je reviendrai même sur quelques unes pour les approfondir.
Architecture
La partie la plus passionnante !
Il existait (encore aujourd'hui) une topologie très utilisée qui est l'architecture tier 3 dans laquelle il y a des switchs d'accès, de distribution et de coeur :
Le problème de cette architecture est la présence du protocole spanning-tree. Pour rappel, il est utilisé en prévention pour éviter toute boucle de niveau 2 et donc il va bloquer certains ports. Dans un environnement datacenter,il y a très peu de coupures inter-baies. Mais si tous les switchs sont sur le même niveau 2 alors quand il y a coupure d'un lien, cela va engendrer une perte de tous les services pendant +/- 30 secondes (en fonction de la version du STP utilisé : STP, RSTP, PVST+, MSTP). Assez catastrophique quand beaucoup d'opérateurs promettent les 99,999% de taux de disponibilité ! Imaginez un niveau 2 commun sur une dizaine/vingtaine de datacenters, géographiquement distancé de plusieurs centaines de km ? Ca deviendrait l'enfer.
Pour éviter cela, on pourrait désactiver ce protocole, mais il faudrait vérifier, revérifier et encore rerevérifier quand on souhaite propager un VLAN dans le backbone pour éviter toute boucle. De plus, en fonction, d'où est le terminal (routeur, PC ou autres), le nombre de sauts parcouru par le paquet peut être variable.
Et pour finir, on est limité à 4096 VLANs.
Enfin bref, une architecture que je n'aime pas et qui est jetée aux oubliettes 😊
La nouvelle à la mode est le Spine and Leaf. Chaque Leaf (feuille) est branché à chaque Spine (Tronc).
Sont branchés sur les Leafs, les terminaux et sur les Spines, les VTEP (ce terme sera expliqué dans l'épisode 2). Ici les leafs sont des switchs mais ils pourraient être très bien des EXSI / Proxmox / un linux avec FRR / etc.
Là encore, le spanning-tree vient nous embêter. Si on l'active, il va encore nous bloquer des ports et probablement entrainer des coupures. En plus, qui n'aimerait pas utiliser tous les liens en même temps ? Coucou l'ECMP.
Par contre, le problème du nombre de saut effectué par le paquet est résolu car peu importe où se trouve le terminal, il va toujours faire 2 sauts. Un problème en moins, c'est déjà ça !
Par exemple, un PC branché sur Leaf1 veut communiquer avec un PC branché sur Leaf4. Le paquet passera par Spine2 et c'est tout. Vous pouvez faire le jeu avec n'importe quel PC branché sur n'importe quel Leaf, ça sera toujours le même résultat.
Pour rappel, le spanning-tree est utilisé dans un niveau 2. Et si les intercos entre les Leaf et les Spines étaient en niveau 3 (IPv4 ou v6), cela résoudrait le problème ?
Bah bien sûr que oui mais ............ je ne pourrai pas utiliser de VLANs vu qu'il n'y a plus de niveau 2 ? Comment feraient 2 machines virtuelles sur le même VLAN pour communiquer ? Ca semble être une mauvaise idée tout compte fait.
Mais non, c'est une excellente idée ! On va utiliser VXLAN ! Défini dans la RFC 7348 (https://datatracker.ietf.org/doc/html/rfc7348), Virtual eXtensible Local Area Network va virtualiser un niveau 2 au dessus d'un niveau 3. En somme, il va permettre d'encapsuler du niveau 2 dans du niveau 3 en étant transporté par UDP. Et en plus, VXLAN va permettre de dépasser la limite de 4096 VLANs, 16 millions de VNI possible (équivalement à un VLAN). Sacré protocole !
Euh, oulah, c'est un peu compliqué, par contre, là non ?
Mais non, regardez en dessous, un exemple de trame avec du VXLAN :
On part de la gauche à la droite :
- L'entête Ethernet (les MACs des 2 interfaces de niveau 3, en l'occurrence, celles des intercos Leaf/Spine)
- L'entête IP (les IPs des intercos Leaf/Spine)
- L'entête UDP (qui va transporter le VXLAN)
- Puis le VXLAN, où on va retrouver l'adresse MAC du terminal, son IP et les données contenues (de l'HTML par exemple !)
Génial, n'est ce pas ? Imaginons, si tout le coeur de réseau utilise ce protocole alors plus besoin de spanning-tree vu qu'il n'y a plus de niveau 2 car les VLANs vont être encapsulés dans de l'UDP donc au dessus du niveau 3 ! On va même pouvoir utiliser tous les liens en même temps. A l'heure du 100G, du 400G, de la consommation excessive des utilisateurs finaux, la question de bande passante disponible est très discutée.
Enfin bref, beaucoup de blabla, c'est un peu compliqué à expliquer sans des cas concrets. Les 2 prochains épisodes seront dédiés à la configuration de la Fabric VXLAN (Underlay et Overlay).
Conclusion
Premier épisode plein de blabla. Mon but va être de virtualiser au mieux un backbone opérateur, et pour ce faire, je vais utiliser plein de protocoles stylés : VXLAN, EVPN, PPP et d'autres ! Tout en vous expliquant le mieux possible ce que je fais.
C'est mon premier blog, soyez indulgents sur ma syntaxe, c'est un exercice assez difficile. 😜
Je termine sur un petit mot de fin : Lisez Naruto 🥷🥷