Cloud onRamp est l’ensemble des solutions qui permettent de simplifier, optimiser et sécuriser les accès au cloud grâce à Cisco SD-WAN. Le cloud ? Un vase mot pour définir de nombreuses choses très différentes : du SaaS, du IaaS, des connexions optimisées aux CDN à travers des colos… C’est pour cela que Cloud onRamp se décline en plusieurs moutures :
- Cloud onRamp for SaaS : offre la meilleure performance vers vos applications SaaS en utilisant le lien WAN le plus adéquat (voir vidéo reseauxblog)
- Cloud onRamp for IaaS : workflows simplifiés permettant l’interconnexion simple aux plateformes IaaS (voir vidéo reseauxblog)
- Cloud onRamp for colocation : workflow permettant de virtualiser complètement votre DMZ sur des hubs telco (voir solution guide)
- Cloud onRamp for Multi-Cloud, le dernier né de la famille, que je vais détailler ci-dessous.
Disponible depuis la version 17.3 de cet été, cloud onRamp for Multi-Cloud permet d’interconnecter votre infrastructure Cisco SD-WAN à la Transit Gateway AWS (et à Azure VWAN à partir de la 17.4 incessamment sous peu).
Après avoir indiqué vos paramètres de connexion à AWS ou Azure sur la console vManage, portail de management de la solution Cisco SD-WAN, vous pourrez créer une “cloud gateway” sur la région de votre choix.
Cette cloud Gateway est composée de la TGW AWS et d’un VPC SD-WAN dans lequel le vManage instancie les WAN Edge désirés (VWAN et SD-WAN avec Azure très bientôt). Nul besoin de se connecter sur votre infrastructure IaaS, le vManage s’occupe de tout. Il crée le host VPC dans lequel les WAN Edges sont instanciés, il crée la transit gateway et l’interconnecte aux WAN Edges via tunnels IPsec et peerings BGP.
Une fois cette cloud Gateway crée, vous pourrez y connecter les host VPC de votre choix simplement via quelques clics depuis le vManage. Ce dernier va découvrir tous les host VPC de associés à votre compte et va vous proposer de les “tagguer”, c’est-à-dire de les catégoriser avec un label que vous pourrez définir. J’ai évidemment maqué sur la capture d’écran ci-dessous les informations confidentielles (Informations sur les VPC et compte AWS)
Une fois le tagging fait, vous pourrez simplement définir votre intention (Intent-Based, vous vous rappelez ?) via une GUI on ne peut plus simple dans le vManage.
En autorisant la communication entre un tag et vos VPN SD-WAN (un seul VPN représenté ici), cela ajoute la TGW dans les host VPC taggués et assure ainsi la connexion de ceux-ci vers le VPN SD-WAN choisi, offrant ainsi la segmentation escomptée. Il est possible également, sur option, de programmer automatiquement une route par défaut sur les host VPC sélectionnés vers la cloud gateway.
Avec ce workflow ultra simple, vous vous épargnez un travail fastidieux de configuration de réseau sur vos infrastructure IaaS. Quelque-soit votre provider IaaS, vous pouvez gérer votre infrastructure réseau de manière uniforme depuis le vManage, en prolongeant vos service SD-WAN et leur agilité vers le cloud. Les tests que j’ai pu réaliser dernièrement montrent que la solution apporte vraiment un plus, et ce dès la première gateway créée ! Je ne doute pas que vous allez apprécier, et que le support d’Azure Virtual WAN en 17.4 en fin de mois vous plaira aussi.
Pour en savoir plus, consultez notre guide de configuration Cloud onRamp for Multi-Cloud.
Authors
2 commentaires
Salut Jérôme,
Merci pour cet article, très claire comme d'habitude. Quelques questions pour l'intégration avec AWS:
– si je comprends bien l'assemblage, les tunnels IPSec entre les edge et TGW sont des AWS s2s VPN. Ces tunnels étant limités à 1.25Gbps, les edge peuvent-ils faire de l'ECMP sur plusieurs VPN?
– si ce sont bien des AWS s2s VPN, comment cela gère la limitation de 100 routes d'AWS? Il n'est pas toujours possible d'avoir des summary malheureusement…
– est-il possible de ne pas déléguer la création des resources AWS à l'orchestrateur? Je pense à la création des resources IAM, VPC (transit et hosts), des routes et des VPN. Quitte à laisser tomber certaines features, je voudrais savoir si l'orchestrateur peut s'occuper que du control plane des edge
– pour le routage inter région AWS, est-ce l'orchestration de TGW peering où cela se passe entre edge via VPC peering ou VPN?
– j'imagine que la segmentation entre VPN s'étend au travers des TGW grâce au multiple RTB. Une TGW supporte max 20 RTB, l'orchestrateur instancie-t-il plusieurs TGW quand on veut plus de 20 VPN? Heureusement personne n'a besoin de ça et ça coûterait assez cher rien qu'en VPN 😉
Cheers,
Matthieu
Merci Matthieu pour ton feedback et d'avoir pris le temps de remonter tes questions. Je ne suis pas expert AWS (je progresse cependant!) je vais essayer de répondre à tes questions en suivant l'ordre:
– Les tunnels IPsec entre TGW et WAN Edges sont en effet en IPsec/BGP avec la limite AWS à 1.25Gbps chacun. Il est possible via policy de répartir les flux (sur les 2 WAN Edges, et sur les tunnels IPsec). Le WAN Edge est un routeur, il assure donc les fonctions de base d'un routeur, dont ECMP est supporté. Je ne parlerai pas de VPN ici car la signification diffère entre Cisco SDWAN (=VRF) et AWS (=tunnel)
– En effet à plus de 100 routes ton peering va tomber, j'ai découvert cela. Du coup il faut rajouter une route-policy sur tes peerings BGP (ou bien sur OMP) pour contrôler qu'on ne dépasse pas 100.
– Le workflow cloud onramp est "prescriptif" et gère la totale. Maintenant si tu souhaites créer la TGW, le VPC SD-WAN, les WAN Edge et interconnecter tout cela à la main pas de problèmes, j'ai des clients qui ont déjà fait cela… Est-ce que tout le monde a envie de gérer cela sur 30 régions et sur plusieurs infras IaaS différentes, là est la question. Le SD-WAN gèrera le routage (le WAN Edge dans le cloud est managé comme n'importe quel routeur de la fabric SD-WAN)
– Le routage entre région peut se faire via la TGW. On a apporté en 17.3.2 le support de "Transit Gateway Peering" pour améliorer encore le contrôle de tout cela. On peut aussi décider si l'on autorise ou pas le routage entre régions via le SD-WAN (attention ca marche beaucoup moins bien si tu agrèges tes routes car on va filtrer les préfixes selon leur AS de provenance)
– Je doute fortement qu'on crée une seconde TGW au delà de 20 VPNs, la doc dit d'ailleurs qu'on ne peut créer qu'une seule cloud gateway par région. Je rappelle qu'on a le workflow cloud onramp for IaaS depuis des années qui permet de se passer de la TGW et de ses limites (s2s direct entre WAN Edge et host VPC). Maintenant si tu vois un besoin concret je suis certain que mes collègues côté BU seront ravis de rajouter cela à la TODO list!
A bientot et merci pour ton intérêt! Je vais creuser des points je reposerai ici des compléments.
Jerome