Fonctionnement du réseau
Lors du déploiement de CSO en tant que déploiement sur site, il est utile de connaître le fonctionnement du réseau et les protocoles utilisés. Lorsqu’il s’agit d’un déploiement hébergé dans le cloud, les concepts sont tous les mêmes, mais les détails et le contrôle sont invisibles pour les abonnés . ils sont de la responsabilité de l’équipe qui installe CSO dans le cloud.
Comme pour la plupart des réseaux, la solution Contrail SD-WAN fonctionne généralement sur deux plans :
Plan de contrôle – OAM et trafic de routage
Plan de données (transfert) - trafic utilisateur
Control Plane Operation
Le plan de contrôle de la solution Contrail SD-WAN s’articule autour de la plate-forme CSO. Plus précisément :
La couche NSC (Network Service Controller) de CSO implémente le plan de contrôle à l’aide de vRR.
Tous les sites de tous les locataires établissent des appairages MP-IBGP avec le vRR.
CSO utilise un seul numéro AS privé pour tous les locataires, avec des cibles de routage pour la séparation des locataires.
La séparation des routes des locataires est assurée à la fois par le vRR et par les équipements hub multi-locataires utilisant des communautés étendues BGP.
Conception vRR
Tous les déploiements CSO comprennent une ou plusieurs instances vRR, qui fournissent des fonctionnalités de plan de contrôle pour l’environnement SD-WAN. La figure 1 montre un exemple général où les équipements sur site de chaque site appairent le vRR.
vRR unique
La figure 2 montre un exemple de la sortie CLI de la vRR.
Résilience du plan de contrôle
CSO version 3.3 et versions ultérieures prend en charge l’installation de plusieurs vRR pour assurer la redondance et l’évolutivité. CSO sépare les vRR en deux groupes de redondance (RG) et rend une seule adresse IP virtuelle visible pour le réseau. Dans le cadre de la configuration d’un site, CSO établit des sessions d’appairage BGP entre l’équipement et un vRR dans chaque RG. En cas d’échec du vRR principal ou de perte de connectivité, le deuxième vRR continue de recevoir et d’annoncer des routes LAN pour les sites connectés, offrant ainsi une redondance. Cette conception est illustrée en figure 3.
multi-vRR
Distribution et séparation des routes
La solution Contrail SD-WAN utilise des instances de routage et de transfert virtuel (VRF) Junos OS et des cibles de routage MP-BGP pour assurer la séparation des routes des locataires et permettre une location multi-locataire.
Ces concepts peuvent être bien illustrés à l’aide d’un environnement VPN MPLS par exemple. Comme le montre la figure 4, chaque client se voit attribuer une valeur cible de routage unique, et tous les sites du VPN client utilisent cette valeur cible de routage. Lorsqu’un routeur annonce les informations de routage d’un client, il attache la valeur cible de routage appropriée en fonction de la VRF du client à l’origine des publicités. Le routeur de réception utilise la valeur cible de route jointe pour identifier le VRF client dans lequel les informations de routage reçues doivent être placées.
MPLS
Un environnement en étoile VPN MPLS utilise les cibles de route différemment, comme le montre la figure 5. Pour chaque client, chaque VRF en parlant attache la même valeur cible de routage lors de l’envoi d’informations de routage. Le routeur de réception accepte les routes avec la même valeur cible de routage et les installe dans le hub VRF. En revanche, le hub VRF attache une valeur cible de routage différente lors de l’envoi d’informations de routage, et les routeurs récepteurs acceptent et installent des routes avec la même valeur cible de route dans des VRF en étoile.
Avec cette configuration, seul le hub VRF accepte les routes des VRF en étoile, et seuls les VRF en étoile acceptent les routes du hub VRF. Grâce à cette méthode, les sites en étoile ont besoin de très peu d’informations de routage (peut-être juste un routage par défaut) car ils n’ont besoin que d’une accessibilité vers le site hub, ce qui permet de garder les tables de routage petites et sans churn.
MPLS en étoile
L’exemple du hub and spoke ci-dessus constitue une bonne base, car la solution Contrail SD-WAN implémente la distribution et la séparation des routes de la même manière lors du transfert de trafic d’un site vers un autre, ou lors de la rupture du trafic vers l’Internet local.
La figure 6 montre un exemple de site en spoke où l’équipement en spoke est configuré avec deux tunnels overlay et un breakout local, avec tout le trafic sortant de la même interface. Chaque chemin de trafic dispose de sa propre VRF, et les cibles de routage sont attribuées de manière appropriée sur les sites en étoile et sur le hub pour garantir une séparation appropriée des routes des locataires.
en rayon SD-WAN
Gestion APBR et SLA - Plan de contrôle
Le routage avancé basé sur des stratégies (APBR) vous permet de définir le comportement de routage et la sélection des chemins par application (groupe). Le mécanisme APBR classe les sessions en fonction des applications connues et des signatures d’applications définies par l’utilisateur, et utilise les intentions de stratégie pour identifier le meilleur itinéraire possible pour l’application. Le routage dynamique basé sur les applications permet de définir des stratégies qui changeront les liaisons WAN à la volée en fonction des paramètres SLA définis par l’application.
Real-Time Optimized - AppQoE
À partir de la version 3.3.1, CSO prend en charge la qualité de l’expérience applicative (AppQoE), un mécanisme au niveau du plan de données qui offre une meilleure évolutivité et une prise de décision plus rapide. En conjonction avec APBR, AppQoE fonctionne au niveau de l’équipement ; c’est-à-dire que les équipements eux-mêmes mesurent les SLA sur les liaisons WAN disponibles, puis mappent dynamiquement le trafic de l’application au chemin qui répond le mieux aux exigences des SLA de l’application. Le tout sans avoir besoin du contrôleur CSO pour distribuer des routes spécifiques aux SLA.
Avec AppQoE, en cas de violation des SLA, seul le trafic correspondant à l’application qui a signalé la violation des SLA est déplacé vers une autre liaison ; tout autre trafic utilisant la liaison n’est pas affecté.
Avec une gestion des SLA optimisée en temps réel, seule la VRF par défaut est requise, comme le montre la figure 7. Le VRF par défaut utilise ECMP sur toutes les liaisons. La sélection du saut suivant par SLA s’effectue dans le chemin de données (décrit dans la section plan de données).
Dans ce cas, le label MPLS est utilisé uniquement pour identifier le locataire.
AppQoE est activé lorsque le mode SD-WAN du locataire est défini sur Optimisation en temps réel. Il s’agit du mode par défaut pour les déploiements SD-WAN.
Notez les éléments suivants concernant AppQoE :
Pris en charge uniquement sur les équipements SRX et vSRX.
Les deux extrémités doivent utiliser la même version de Junos OS et la même configuration.
Le multi-homing est pris en charge.
Fonctionnement du plan de données
Cette section explique comment un paquet est transféré dans une topologie en étoile.
Lorsqu’un utilisateur d’un site en étoile envoie du trafic via l’équipement CPE sur site et que le paquet n’est pas transféré localement ou directement sur Internet, il est envoyé par un tunnel vers l’équipement hub. Ce paquet du LAN client est d’abord encapsulé dans un en-tête MPLSoGRE avec la destination GRE comme l’une des liaisons WAN de l’équipement hub. Le label MPLS de l’en-tête MPLSoGRE identifie le VRF à utiliser pour le transfert du paquet sur le site du hub. L’en-tête de paquet qui en résulte est illustré en figure 8.
Si le tunnel entre le site en étoile et le site hub est configuré pour utiliser IPsec, le paquet MPLSoGRE est ensuite chiffré et encapsulé dans un en-tête IPsec qui utilise le mode tunnel. L’en-tête de paquet obtenu est illustré en figure 9.
Au niveau du hub, l’en-tête IPsec est d’abord déchiffré. L’en-tête MPLSoGRE du paquet résultant est utilisé pour terminer le tunnel GRE et effectuer une recherche dans le VRF approprié, comme identifié à l’aide du label MPLS. En fonction de la recherche de route dans le VRF, le paquet est soit transféré vers un autre site en spoke, soit depuis l’environnement SD-WAN. S’il est transféré vers un autre spoke, l’équipement hub encapsule le paquet comme décrit ci-dessus.
Design Options
La figure 10 illustre comment les tunnels sont généralement déployés à l’aide des en-têtes de paquets décrits ci-dessus. Les tunnels GREoIPSec sont généralement utilisés sur le chemin Internet, étant donné le besoin de sécuriser le transport de paquets sur le réseau public. Les tunnels GRE sont généralement utilisés sur des chemins MPLS, bien que l’option GREoIPSec puisse également être utilisée selon le cas.
de conception de tunnel
APBR and SLA Management - Data Plane
Comme mentionné précédemment, les locataires peuvent choisir un seul mode de gestion des SLA SD-WAN pour le trafic applicatif :
Optimisé en temps réel – Gestion des SLA au niveau des équipements à l’aide d’AppQoE
AppQoE est un mécanisme au niveau du plan de données qui offre une meilleure évolutivité et une prise de décision plus rapide. Avec AppQoE, la commutation de liaison s’effectue au niveau de l’application dans le chemin de données des équipements ; les équipements effectuent eux-mêmes des mesures sla sur les liaisons WAN disponibles, sans avoir besoin du contrôleur CSO.
La surveillance des liaisons s’effectue à l’aide de deux types de sondes inline :
Sondes passives
Sondes inline qui accompagnent le trafic applicatif
Imitez l’explosivité des flux applicatifs
Activer la surveillance de la RTT, de la gigue et de la perte de paquets pour la session d’application
Utilisé pour surveiller le chemin actuellement utilisé pour la conformité des SLA et détecter les violations de SLA
Sondes actives
Sondes périodiques (basées sur la configuration) qui recueillent des données SLA sur tous les chemins potentiels
Utilisé pour déterminer le meilleur chemin d’origine pour le trafic
Utilisé pour surveiller les chemins alternatifs
AppQoE est activé lorsque le mode SD-WAN du locataire est défini sur Optimisation en temps réel.
Tunnel Liveliness
Pour éviter que le trafic ne souille, des vérifications appropriées de l’exactitude sont appliquées dans le réseau overlay. La solution Contrail SD-WAN utilise deux mécanismes pour garantir la vie :
Détection des pairs morts (DPD) IPsec, où elle est utilisée
Les avantages de la sécurité GRE
Étiquettes de maillage et VPN à maillage dynamique
Comme mentionné dans la discussion sur les modèles de déploiement, le maillage dynamique est l’implémentation par Juniper de VPN à maillage complet au sein de CSO. Cette section décrit le fonctionnement des balises de maillage et des VPN de maillage dynamique qu’elles permettent.
Mesh Tags
Les étiquettes de maillage sont des étiquettes basées sur du texte appliquées aux interfaces WAN des équipements CPE et hub pendant le processus d’intégration dans CSO. CSO est livré avec deux balises maillées par défaut : Internet et MPLS. Vous pouvez créer vos propres balises de maillage à l’aide du portail d’administration CSO. Les VPN à la demande ou dynamiques ne peuvent être formés qu’entre des interfaces WAN qui partagent la même balise de maillage.
La discussion suivante explique comment fonctionnent les étiquettes de maillage et certains des cas d’utilisation auxquels elles s’appliquent.
Comme mentionné ci-dessus, une balise de maillage est appliquée à chaque interface WAN de l’équipement CPE sur chaque site. Sur les équipements en rayon comme les NFX150 et NFX250, et la plupart des équipements SRX, une seule balise de maillage peut être appliquée à chaque interface WAN. Sur les hubs des fournisseurs et les équipements de hub d’entreprise tels que les équipements SRX4x00 Series, plusieurs balises de maillage peuvent être appliquées à chaque interface en raison des capacités VPN accrues des équipements.
La liste suivante permet d’illustrer les différents cas d’utilisation dans lesquels les balises de maillage et les VPN de maillage dynamique entrent en jeu.
Connecting Different Underlay Links
Site-to-Site Tunnels Based on Capacity
Geo-Based Meshing
With Dual CPE
Dynamic Mesh Load Balancing
Redundant Link
Dynamic Mesh VPNs
La figure 11 montre une topologie VPN de maillage dynamique entre trois sites en spoke et décrit comment le VPN de site à site est mis en place.
du maillage dynamique
|
1
—
Sites et tunnels vers les sites Hub provisionnés à l’aide de ZTP. Le trafic de site à site passe par le site jusqu’aux tunnels de données du hub.
|
4
—
CSO configure des tunnels de site à site à la demande entre les paires de sites.
|
|
2
—
CSO reçoit des messages syslog des équipements contenant des détails sur les débits de trafic.
|
5
—
Le trafic de site à site passe désormais aux tunnels nouvellement formés.
|
|
3
—
CSO reconnaît que le trafic entre le site 1 de Phoenix et le site 2 de Houston dépasse les seuils de KPI.
|
La suppression des tunnels est également contrôlée et automatisée par CSO à l’aide de seuils de trafic et de messages syslog.
Internet Breakout
Alors que le trafic destiné à Internet peut être envoyé à travers les tunnels overlay et via un site central, les tunnels sont généralement destinés à prendre en charge le trafic de site à site. Pour les destinations non SD-WAN, le breakout local offre la possibilité d’envoyer le trafic de l’équipement local directement vers Internet. Le breakout local permet au locataire d’utiliser la bande passante de son réseau de manière optimale sur chaque site et d’éviter les coûts de transport de tout le trafic vers le site central.
Le breakout local est une fonctionnalité importante dans les déploiements SD-WAN, car de nombreuses entreprises utilisent aujourd’hui des services SaaS hébergés en dehors du réseau d’entreprise. Étant donné que la plupart de ces applications SaaS utilisent SSL comme transport et prennent également en charge l’authentification unique avec les systèmes AAA d’entreprise, les problèmes de sécurité sont résolus malgré l’envoi de trafic directement sur Internet.
WAN Interface Options
Les interfaces WAN (MPLS et Internet) d’un équipement sur site peuvent prendre en charge le trafic breakout local et tunnelisé dans n’importe quelle combinaison :
Trafic tunnelisé uniquement
Trafic breakout local et tunnelisé
Trafic breakout local uniquement
Design Options
En fonction des exigences de conception, il existe plusieurs façons d’implémenter un breakout local.
Breakout at Spoke
Le breakout local sur les sites en étoile permet aux utilisateurs d’accéder directement à Internet sans avoir à envoyer de trafic sur le réseau overlay vers le hub, ce qui contribue à économiser la bande passante du tunnel. Cette option peut être implémentée sur Internet ou sur les liaisons WAN MPLS. La figure 12 illustre ce concept.
Lorsque vous utilisez un breakout local, vous pouvez spécifier un NAT basé sur une interface ou un pool.
Breakout at Provider Hub (Central Breakout)
Le breakout central d’un site de fournisseur permet des déploiements en étoile où les sites en étoile transfèrent le trafic Internet à destination d’Internet via le réseau overlay vers l’équipement hub du fournisseur, qui transfère ensuite le trafic vers Internet, comme illustré en figure 13.
Le breakout central sur le site du hub est activé différemment que sur un site en étoile. Il peut être configuré manuellement dans CSO via des modèles d’étape 2.
Un breakout central peut également être fourni aux sites en étoile via un site Hub d’entreprise. Dans ce scénario, le hub d’entreprise peut réaliser un breakout local à l’aide d’un réseau sous-jacent pour le transfert, ou il peut recevoir le routage par défaut du service datacenter et le propager vers les rayons.
Lorsque le breakout central est proposé à la fois au hub fournisseur et au hub d’entreprise par la méthode de routage par défaut, le routage par défaut à partir du hub d’entreprise est préféré en utilisant les préférences locales BGP.
Cloud Breakout
Une autre option de breakout pour le trafic à destination d’Internet, Cloud Breakout, est disponible pour les sites en étoile et les hubs d’entreprise. Lorsque le breakout cloud est activé, le site en étoile ou le site du hub d’entreprise transfère le trafic Internet à Zscaler pour un traitement supplémentaire lié à la sécurité avant qu’il ne soit envoyé à Internet. Le compte Zscaler doit être actif et accessible avant d’envoyer du trafic via le breakout.
Usage Notes for Cloud Breakout
Les tunnels d’encapsulation de routage générique (GRE) qui utilisent des adresses IP publiques pour les liaisons WAN sont pris en charge pour le breakout cloud.
Lorsque vous utilisez des tunnels GRE, les équipements CPE ne peuvent pas être derrière nat.
Lorsque vous configurez les paramètres de breakout cloud, vous pouvez spécifier les paramètres de phase 1 IPsec, les paramètres de phase 2 et le nom du domaine.
Vous pouvez spécifier la validation de l’adresse IP ou du nom d’hôte pour les nœuds breakout cloud.
CSO remplit automatiquement le FQDN, les clés prépartagées et les informations de liaison WAN et offre la possibilité de modifier les valeurs remplies automatiquement.
CSO prend en charge la haute disponibilité entre les liaisons WAN d’un site SD-WAN spoke et le nœud breakout cloud.
Les nœuds de liaison WAN peuvent être configurés en tant qu’actifs/passifs ou actifs/actifs.
Un maximum de deux liaisons WAN peut être définie entre le site SD-WAN spoke et le nœud breakout cloud.
Order of Preference for Scenarios with Multiple Breakout Options
Si plusieurs options de breakout sont disponibles pour le CPE sur le site en spoke et qu’aucune stratégie de breakout n’est spécifiée, alors l’ordre de préférence pour le breakout est :
Centre de données/hub d’entreprise
Breakout local/Breakout cloud
Hub fournisseur (central)
Si plusieurs options de breakout sont disponibles pour un site hub d’entreprise, l’ordre de préférence pour le trafic breakout est :
Sans stratégie SD-WAN :
Service datacenter
Centre
Avec la stratégie SD-WAN :
Breakout local/Breakout cloud
Service datacenter
Hub fournisseur (central)
Use Cases for Local Breakout
Certains cas d’utilisation du breakout local sont décrits ci-dessous.
Service Provider Data Center
Dans ce cas d’utilisation, l’entreprise cliente utilise le service SD-WAN du fournisseur de services pour l’inter-connectivité site à site. Le client utilise également des services à valeur ajoutée hébergés dans le centre de données du fournisseur de services.
Sur le site spoke, l’interface WAN MPLS de l’équipement sur site est configurée pour prendre en charge à la fois le trafic breakout local et tunnelisé. Comme le montre la figure 14, le trafic traverse le réseau comme suit :
Le trafic inter-site (SD-WAN) circule sur le réseau MPLS à l’aide du tunnel overlay.
Le trafic à destination du centre de données utilise un breakout local et se déplace directement sur le réseau MPLS sous-jacent.
Dans ce scénario, le centre de données pourrait être situé ailleurs sur le réseau MPLS, peut-être au niveau d’un POP, comme le montre la figure 16. dans ce cas, les flux de trafic restent généralement les mêmes que ci-dessus.
Autre variante de ce scénario, le trafic à destination du centre de données pourrait utiliser le tunnel overlay, le breakout au niveau de l’équipement hub et le double retour vers le centre de données, comme le montre la figure 16.
Cette option présente quelques inconvénients :
Il utilise plus de bande passante de tunnel.
Il peut augmenter la latence à mesure que l’équipement sur site sur site en spoke traite et encapsule plus de trafic.
Il augmente la charge sur l’équipement hub.
Il crée un chemin sous-optimal, ce qui fait passer le trafic à travers les tunnels jusqu’à l’équipement hub, avant de devoir doubler pour atteindre le centre de données.
Cependant, il présente également quelques avantages :
Grâce aux tunnels overlay, le trafic à destination des centres de données peut tirer parti des services SLA et choisir le meilleur chemin de manière dynamique, améliorant ainsi les performances réseau pour ces applications.
Des fonctions de sécurité supplémentaires peuvent être proposées de manière centralisée.
Migration to SD-WAN
Dans ce cas d’utilisation, l’entreprise cliente dispose de plusieurs grands sites et utilise le service MPLS existant du fournisseur de services pour fournir un maillage complet entre les sites. Le client souhaite migrer vers le SD-WAN, et l’implémentation est susceptible d’être incrémentielle. Néanmoins, il est essentiel de maintenir la connectivité entre les sites en tout temps.
La figure 17 illustre un scénario dans lequel la migration est en cours. La fonctionnalité SD-WAN a été ajoutée aux sites 3 et 4, tandis que les autres sites n’ont pas encore été migrés. Sur chaque site compatible SD-WAN, l’interface WAN MPLS de l’équipement sur site est configurée pour prendre en charge à la fois le trafic breakout local et tunnelisé. Le trafic traverse le réseau comme suit :
Le trafic entre les sites compatibles SD-WAN peut utiliser le tunnel overlay.
Le trafic entre un site compatible SD-WAN et un site hérité utilise un breakout local et se déplace directement sur le réseau MPLS sous-jacent.
Dans ce cas, le breakout local est la clé pour maintenir la connectivité entre les sites migrés et les sites hérités.
Local breakout and NAT
Lorsque le trafic transite d’un locataire VRF vers Internet, le NAT doit généralement être utilisé pour traduire de l’espace réseau privé du locataire vers l’espace réseau Internet (public).
Sur les sites en spoke, les équipements sur site peuvent utiliser le NAT automatique pour exécuter automatiquement le NAT source sur tout le trafic breakout local. Sur les hubs, l’auto-NAT n’est pas disponible ; toutefois, l’interface utilisateur CSO prend en charge la création manuelle de règles NAT pour ces équipements sur site.
Local Breakout and DNS
La configuration d’un équipement sur site en tant que serveur DHCP pour les segments LAN vous permet de spécifier les informations de serveur DNS pour les hôtes finaux. Pour un site dont le breakout local est activé, il est généralement recommandé de spécifier plusieurs serveurs de noms : un serveur interne pour la résolution des noms de domaine de l’entreprise et un serveur public ou un serveur ISP pour le trafic breakout local à destination d’Internet.
Sécurité du réseau
L’une des considérations de sécurité importantes pour les architectures SD-WAN est d’assurer la sécurité des données non seulement au repos, mais aussi en mouvement. La sécurité des données a été améliorée pour permettre l’utilisation d’une PKI multi-niveaux pour les données et les tunnels OAM. Cela permet à CSO de recevoir des certificats CA multi-niveaux d’un serveur de CA, d’envoyer plusieurs certificats CA vers des équipements CPE, de renouveler et de révoquer des certificats CA multiples sur les équipements CPE.
CSO prend en charge le protocole SCEP (Simple Certificate Inscription Protocol) à partir de la version 4.1 de CSO. CSO peut ainsi :
Agir en tant que serveur SCEP
Agir en tant que SCEP brillant
Révocation de certificat
Renouvellement automatique du certificat
Déployer des certificats vers un CPE/site
Gérer les certificats sur CPE (site)
Fournir une prise en charge de l’interface graphique pour les informations du serveur CA
Renouvellements de certificat de site/CPE
Prise en charge de Microsoft CA/NDES
Certificats de courtier pour chaque site/CPE
Une API back-end est fournie pour l’accès programmatique aux fonctionnalités PKI.
Data Plane
Les connexions de plan de données peuvent être configurées pour utiliser IPsec avec une authentification basée sur la PKI. Lorsqu’il est utilisé, l’équipement local chiffre le trafic avant de le transmettre sur le réseau au site distant et l’authentification est gérée à l’aide de paires de clés publiques et privées.
Management and Control Plane
CSO se connecte et configure les équipements sur site à l’aide de SSH pour les connexions console et NETCONF. À partir de la version 4.0 de CSO, les tunnels de superposition OAM dédiés permettent d’améliorer les communications sécurisées de bout en bout entre les équipements sur site et CSO. Les tunnels OAM chiffrés IPsec et PKI authentifiés, illustrés en figure 18, permettent aux équipements en étoile sur site d’envoyer la gestion, le routage et la journalisation du trafic sur le réseau en toute sécurité vers un hub fournisseur. Le hub transfère ensuite le trafic vers CSO.
OAM sécurisé
Pour plus de détails, consultez la section Réseau OAM sécurisé et redondant plus tôt dans ce guide.