FRnOG 37 - Robin Douine : Building a SD-WAN solution based on Wireguard tunnels
Robin Douine : Building a SD-WAN solution based on Wireguard tunnels #FRnOG
Transcript
00:00 Bonjour à tous, je m'appelle Robin Dwin et je vais vous présenter la solution d'SD-WAN qu'on a mis en place au sein de Criteo.
00:06 C'est pas ouf.
00:11 Donc déjà un peu de contexte, à Criteo en fait on a plusieurs DC à travers le monde, chacun c'est une matrice de clôt.
00:18 Sur chacun des DC on a la propre connectivité internet
00:22 et ces DC sont reliés entre eux avec des lease lines, donc la plupart du temps des Waves en Gig pour former un WAN.
00:29 La cible c'était de rajouter une solution SD-WAN par dessus.
00:33 Quand je parle de SD-WAN je parle de la création de tunnels à travers internet et de passer justement le
00:40 trafic entre les DC à partir de ces tunnels.
00:43 Alors pourquoi on voulait le faire ? Déjà pour une histoire de fiabilité.
00:48 Le fait de rajouter une solution nous rajoute forcément de la fiabilité par rapport à ce qu'on a déjà existant
00:57 et le fait de, comment ça s'appelle, on a déjà eu une expérience au Japon où on a eu un typhon
01:03 qui est passé et en fait compte on avait trois liens,
01:09 trois waves différentes qui passaient par trois chemins différents
01:13 qui ont été coupés alors que la connectivité internet elle était toujours là.
01:18 Le second point c'est le temps de déploiement.
01:20 Une Wave par exemple entre
01:24 continental c'est plusieurs mois pour le délivrer
01:28 alors que si on parle de tunnels à travers internet c'est quelques minutes
01:33 même si on doit augmenter notre capacité de transit c'est quelques semaines on va dire.
01:37 Le dernier point c'est le modèle de pricing.
01:42 Quand vous prenez une Wave 100 Gbps par exemple
01:45 vous l'utilisez ou vous ne l'utilisez pas à 100 Gbps, vous le paierez à la fin du mois
01:51 alors qu'en se basant sur le trafic internet vous ne payez que ce que vous allez consommer.
01:58 Exit par rapport au CDR etc.
02:01 Alors les objectifs techniques de la solution
02:04 on avait besoin qu'elle supporte plusieurs centaines de gigabits par rapport à nos besoins
02:08 on veut qu'elle puisse changer dynamiquement le routage en fonction de l'état des transits
02:14 on voulait qu'elle n'utilise que des
02:19 des composants standards c'est à dire pas de
02:22 protocoles propriétaires, pas de software propriétaire
02:25 et de même pour le hardware on veut que du community hardware donc en gros des serveurs et pas d'appliance réseau ou
02:31 d'hardware spécifique pour du chiffrement genre de choses.
02:34 Donc la solution on l'a appelée Routing CTL et elle a été écrite en gros
02:39 elle est composée de trois principaux composants donc BGP CTL, un contrôleur et les gatewans
02:46 donc un jeu de mots entre gateway et WAN
02:49 les gatewans portant les tunnels
02:51 et donc en gros la partie data plane
02:54 on les a mis sur des serveurs physiques par contre les deux autres peut être très très bien mis sur des conteneurs.
03:01 Donc le premier composant c'est les gatewans donc comme on l'a vu ceux qui vont partir des tunnels donc en gros la première
03:09 la première chose à faire avec les gatewans c'est qu'elles se découvrent
03:12 donc les gatewans distantes et donc on va utiliser Cerf alors Cerf c'est pas forcément connu en tant que standalone mais c'est le protocole
03:19 le gossip protocole utilisé par consul
03:21 donc en gros on va construire un mesh grâce à ça
03:24 une fois que les sessions entre les gatewans sont créées en fait elles vont s'échanger des données
03:29 donc en premier forcément les préfixes locaux au niveau des sites et bien sûr les clés de chiffrement pour WireGuard.
03:38 Donc une fois qu'on a ces clés de chiffrement on va pouvoir créer les tunnels à travers chacun des ISP
03:45 donc chaque gatewan a une IP différente pour chaque ISP et on va essayer de créer le plus de combinaisons possibles d'avoir le plus
03:52 de tunnels possibles pour avoir le plus de choix au niveau des tunnels.
03:56 Une fois qu'on a les tunnels on va
03:58 faire du probing à l'intérieur pour récupérer des métriques et de calculer la loss, la latence, le jitter.
04:05 Donc voilà à quoi ça ressemble une fois qu'on a un tunnel établi
04:09 donc si on regarde principalement ces éléments donc là on voit c'est un tunnel entre Dallas et Singapour
04:15 donc là on voit les networks en haut donc ça c'est les préfixes locaux de Singapour qu'on récupère, on voit une capacité
04:21 là qui est d'un gig, je reparlerai juste un peu après
04:23 et on voit les
04:26 comment s'appelle le résultat du probing donc on voit qu'on n'a pas de loss sur 10 mesurements on voit qu'il n'y a pas de loss,
04:30 qu'on a une latence en moyenne de 224 millisecondes, du jitter c'est à la microseconde donc c'est très bien
04:35 et on voit l'interface donc qui s'appelle SD-152 c'est l'interface WireGuard au niveau du kernel
04:42 et le reste ce sont les IP publiques qui ont été utilisées pour établir le tunnel et les IP
04:46 à l'intérieur du tunnel les IPv4 et v6 donc on est exclusivement on ne fait que de l'IPv6 au niveau externe
04:53 Donc maintenant qu'on a vu au niveau des gatewans comment
04:58 elles peuvent créer des tunnels, un des soucis qu'on va avoir c'est comment acheminer le trafic au niveau des gatewans
05:04 donc là on aurait pu faire en sorte que les gatewans
05:07 advertise le trafic
05:11 en BGP dans la matrice do-clos les préfixes qu'ils ont récupéré
05:15 le problème c'est qu'on va avoir un problème de load balancing puisque si vous avez
05:19 les serveurs dans le même pod que
05:21 forcément les gatewans, ces serveurs là vont forcément préférer celle là
05:25 et donc vous allez avoir un problème de load balancing. On va le faire à un plus haut niveau qui est au niveau du pod edge
05:30 et donc ce qu'on va faire c'est qu'on va
05:32 laisser le serveur envoyer son trafic de façon habituelle et c'est au niveau du edge pod qu'on va prendre
05:38 ce trafic là, l'encapsuler dans du VXLAN pour le diriger au niveau de la gatewan
05:43 Deuxième gros composant donc c'est le contrôleur. Donc le contrôleur son rôle c'est assez simple il va récupérer tout le travail qu'a fait les gatewans
05:54 donc il va récupérer tous les tunnels, tout le probing et il va les trier
05:58 en fonction d'une policie il va choisir des tunnels donc la policie elle est assez simple par exemple on veut que des tunnels qui n'ont
06:05 pas de loss et on va les sortir, les trier en fonction de la latence, on veut la latence la plus faible
06:11 une fois qu'il a choisi ses tunnels il va choisir ses tunnels jusqu'à atteindre une capacité
06:17 requise donc là j'ai parlé tout à l'heure de la capacité des liens on voyait que la capacité du lien était d'un gig
06:23 là ce qu'il faut imaginer c'est par exemple entre Singapour et Dallas on voudrait
06:27 40 gig donc ça veut dire avec des liens d'une capacité d'un gig
06:32 40 tunnels et donc
06:35 bien sûr il va faire attention à ne pas dépasser la capacité maximale d'un serveur donc par exemple si vous avez un serveur avec une
06:42 carte 10 gig
06:42 on peut
06:44 estimer que voilà la capacité maximale du serveur est de
06:46 8 gig pour laisser un petit peu de marge et donc en gros il va faire en sorte de ne pas saturer les serveurs
06:52 donc une fois qu'il a choisi les tunnels
06:54 il va tout simplement les envoyer donc aux gatewans
06:58 pour qu'elles puissent installer les routes donc les routes c'est à dire en gros on sait les préfixes du site distant
07:04 et donc on sait quels sont les tunnels choisis c'est là qu'il va installer les routes quand les paquets arriveront sur la gatewan il sera
07:10 dans quel tunnel les forwarder
07:12 et il va bien sûr aussi les envoyer à bgpctl donc le dernier composant
07:17 alors bgpctl c'est simple il y a deux missions la première c'est de récupérer les préfixes locaux au site
07:23 donc ceux par exemple agrégés par le edge router
07:27 pour le renvoyer au contrôleur qui va le renvoyer aux gatewans et comme on a vu juste avant qui va le renvoyer aux gatewans
07:32 distance
07:33 son autre but c'est bien sûr de récupérer donc les ordres du contrôleur et les transformer en bgp-evpn-route-type-5
07:40 donc celui là qu'on appelle prefix-route donc pour ceux qui voient pas trop ce que c'est en gros c'est le fait d'assimiler
07:46 d'associer un préfixe à un tunnel VXLAN pour faire simple
07:51 donc
07:53 comme je disais toute la solution est fait en gros et donc bgpctl est basé sur gobgp et donc ce qui est intéressant c'est
07:58 qu'on peut utiliser directement en fait le client de gobgp pour l'interroger
08:02 et donc là par exemple on voit la output d'un
08:05 bgpctl donc d'ordre donc là on voit que c'est de l'evpn-type-5
08:10 on voit type-préfix, le route-distinguisher, le prefix, le 5 c'est pas le fait que ça soit type-5 c'est le VINI donc c'est
08:17 l'id du VXLAN
08:19 l'annex-top donc c'est de la gate-1 et vu que le VXLAN c'est de la couche 2 il nous faut une MAC et donc ça c'est
08:25 stocké dans une communauté
08:27 Voilà donc ensuite la solution mis tout ensemble au sein de
08:32 l'architecture donc en gros on voit les différents gate-1, ça parle en gRPC j'en ai pas évoqué mais on parlait de go donc voilà
08:39 avec le contrôleur et on a bgpctl qui peer directement avec les edge-routers
08:47 Maintenant on va regarder, on a vu la partie contrôle-plaine, on va voir comment se passe la partie data-plaine donc la vie des petits paquets
08:53 donc là on imagine voilà on a deux serveurs
08:56 dans chacun des DC et on va regarder comment les serveurs
09:01 de DC1 va pouvoir envoyer du trafic à DC2 donc au début il va envoyer son trafic classique
09:08 vers le serveur distant et donc il va l'envoyer
09:12 il va suivre sa route par défaut, il va l'envoyer au niveau du top-of-rack
09:16 qui lui va le ramener
09:18 remonter, suivre la route par défaut jusqu'à arriver au edge-router donc là on a vu il a reçu lui des routes par bgpctl
09:25 donc il va avoir installé dans sa RIB le fait que tel préfixe et bah c'est tel tunnel VXLAN donc le VTEP et le VNI
09:33 là il encapsule le paquet, le paquet va aller jusqu'à la gate-1 de façon naturelle
09:39 la gate-1 va le décapsuler et va regarder sa table de routage donc normalement il a reçu des ordres
09:46 comme quoi ces tunnels-là seront utilisés donc là on voit les routes qui ont été installées il va suivre
09:52 il va utiliser un des tunnels wire-guard, le tunnel va être chiffré
09:58 ça va passer à travers internet, ça va arriver sur la gate-1 distante
10:02 qui va le décapsuler et naturellement après il le renvoie sur son interface classique et la matrice de clou va le rerouter jusqu'au serveur
10:10 qu'on voulait
10:13 Alors quelles sont en gros les faiblesses de la solution ?
10:16 le fait que le debugging est complexe forcément il y a plusieurs composants c'est beaucoup plus compliqué qu'un simple lien, une simple wave
10:26 on a un problème aussi on va dire de bootstrapping si par exemple pour bootstrapper un nouveau DC vous avez
10:32 besoin d'un autre DC donc d'un DC distant pour bootstrapper par exemple les serveurs d'un nouveau DC
10:38 vu que là vous avez besoin de serveurs pour créer la solution ça va pas le faire
10:42 et le dernier point c'est
10:44 vous êtes basé sur
10:45 ça se passe sur internet donc vous êtes complètement vulnérable aux DDoS, si votre port se retrouve saturé suite à un DDoS
10:50 forcément ça ne fonctionnera plus non plus
10:52 Alors les next step nous pour la solution on doit améliorer les performances au niveau des tunnels donc là c'est vraiment du talking au niveau
11:00 du linux
11:01 là on voit que la capacité elle était dans 1 gigabit alors bien sûr on parle non pas gigabit puisque au niveau de wire-guard on va parler de
11:06 paquets par seconde donc là c'est de faire en sorte que un tunnel puisse
11:10 gérer le plus de paquets par seconde tout simplement
11:13 et on veut rajouter bien sûr plus de
11:16 comment ça s'appelle de paramètres au niveau de l'algorithme du contrôleur donc par exemple le fait que il est
11:24 l'usage des interfaces des transits donc par exemple si on imagine il y a deux transits qui fassent attention à
11:30 si les tunnels au niveau des choix c'est correct vous avez pas de loss
11:34 de passer sur l'autre transitaire par exemple parce que le premier vous commencez à le saturer
11:38 genre de choses et bien sûr par exemple le coste peut être aussi très intéressant
11:42 conclusion bah la solution fonctionne on est plutôt content
11:45 et c'est bien géré c'est flexible d'un point de vue que c'est quelque chose qui peut être juste mis en tant que backup pour certains
11:53 certains liens d'autres fois ça peut être juste utilisé comme de l'offload donc quand on en quand les liens commencent à saturer de pouvoir offloader
12:01 une partie du trafic
12:03 Et
12:06 comment s'appelle le comment s'appelle le sinon on peut aussi l'utiliser en nominal tout dépend la situation
12:11 Voilà je vous remercie
12:15 Une fois n'est pas coutume moi j'ai une question c'est publié c'est open source
12:26 alors non pas encore on s'était dans l'idée à la création le problème c'est bien deux problèmes par rapport à l'open source c'est la documentation
12:34 on a beaucoup de choses à documenter dont aussi l'infrastructure
12:38 c'est à dire qu'en gros là j'ai masqué un petit peu de la complexité mais par exemple au niveau des gait one c'est il ya une
12:44 toute une partie système qui est pas au niveau juste de la partie code qu'il faut intégrer en fait dedans
12:48 au niveau de la documentation donc c'est pour ça
12:51 Bonjour j'avais une question par rapport au schéma des paquets si j'ai bien compris en fait un paquet passe deux fois dans le
12:58 parti edge si on fait un aller-retour et oui il fait que ça pose un problème de capacité
13:04 effectivement c'est pour l'aller en tout cas il ya un trafic
13:07 sud nord nord sud qui va être utilisé alors que on fait un compte on aimerait faire du trafic est ouest
13:12 alors on ça nous gêne pas parce que d'un point de vue du load balancing c'est préférable en fait que le load balancing soit bien
13:18 fait à travers les gait one plutôt que d'essayer de se dire on va essayer de faire du ls ouest
13:22 Est ce qu'il ya une autre question oui
13:27 Voilà
13:29 Sur les flux inter dc la plupart du temps on a envie de faire du jumbo frame oui comment vous gérez ça on peut pas
13:39 1420 parce que c'est de wire guard ipv6 donc la mtu de 1420 alors avec le paf mtu ça marche bien on peut arriver à redescendre
13:46 il n'y a pas de problème au sein du dc mais effectivement le jumbo n'est pas possible
13:51 oui bonjour merci pour votre présentation ben en fait je suis quasiment à la même question plus quand on mélange sd1 et
13:57 interco l2 du coup on dégrade la mtu quand on passe par le wire guard et on a une tu classique en interco ou du coup
14:03 on dégrade la mtu en fait c'est ouais c'est pas fait mtu qui va faire le travail
14:07 donc après c'est plus si on fait du routage asymétrique que là ça commence parce que là en fait
14:11 dans l'exemple que j'ai montré on voit bien que le paquet il arrive d'un dc vers un autre par contre le paquet retour il n'est
14:16 pas il va pas passer forcément par le même tunnel soit il passe par aussi un autre tunnel parce qu'on dit on active aussi la
14:23 solution sd1 de l'autre côté soit il va passer par le
14:25 la web par exemple le l2 classique
14:28 et du coup mss clamping obligatoire pour pouvoir passer
14:31 il peut avoir ça et sinon après voilà c'est vraiment c'est le pmtu qui est censé faire son travail avec ses désavantages
14:38 Est-ce qu'il y a encore une autre question dernière
14:44 on est bon parfait merci
14:46 Allez
14:52 Et au niveau des
14:53 de vos gateway vous faites comment du coup pour choisir le transit en particulier du coup
14:58 pour la sortie c'est une bonne question alors en gros dans ça j'ai pas voulu l'expliquer c'est un peu complexe mais en gros il ya deux
15:05 façons de faire il ya pas deux façons de faire mais il ya deux moyens pour le faire c'est qu'en gros pour le traffic input il
15:10 faut que utiliser soit des ip que le provider va fournir
15:13 soit par exemple vu qu'on parle d'ipv6 claquer un /48 en disant je vais le dédier à cet opérateur là donc ça c'est bon pour
15:19 le traffic input après pour l'output nous ce qu'on fait c'est qu'on a un exab gp sur les gateway qui va faire du flow spec
15:25 et qui va dire à quand tu vas voir cette tel ip source tu vas vers tel nextop qui est le bon opérateur
15:30 Merci
15:35 (Applaudissements)