Exploitation du réseau
Lorsque vous déployez CSO sur site, il est utile de connaître le fonctionnement du réseau et les protocoles utilisés. Lorsque vous travaillez avec 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 sous la responsabilité de l’équipe qui installe CSO dans le cloud.
Comme 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 contrôleur de service réseau (NSC) de CSO implémente le plan de contrôle à l’aide de vRR.
Tous les sites, quel que soit le locataire, établissent des appairages MP-IBGP avec le vRR.
CSO utilise un numéro AS privé unique 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 du hub multi-tenant à l’aide des communautés étendues BGP.
Conception vRR
Tous les déploiements CSO incluent une ou plusieurs instances vRR, qui fournissent une fonctionnalité de plan de contrôle pour l’environnement SD-WAN. La figure 1 montre un exemple général où les appareils locaux de chaque site sont appairés avec le vRR.
vRR unique
La figure 2 montre un exemple de sortie CLI du vRR.
Résilience du plan de contrôle
Les versions 3.3 et ultérieures de CSO prennent 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 sur le réseau. Dans le cadre de la configuration d’un site, CSO établit des sessions d’appairage BGP entre l’appareil et un vRR dans chaque RG. Si le vRR principal tombe en panne ou si la connectivité est perdue, le second vRR continue de recevoir et d’annoncer les routes LAN pour les sites connectés, assurant ainsi la redondance. Cette conception est illustrée à la figure 3.
multi-vRR
Distribution et séparation des routes
La solution Contrail SD-WAN utilise des instances VRF (virtual routing and forwarding) Junos OS et des cibles de route MP-BGP pour séparer les routes des locataires et permettre la mutualisation.
Ces concepts peuvent être bien illustrés en prenant l’exemple d’un environnement VPN MPLS. Comme illustré sur la Figure 4, chaque client se voit attribuer une valeur cible de route unique, et tous les sites du VPN client utilisent cette valeur cible de route. Lorsqu’un routeur publie les informations de routage d’un client, il joint la valeur cible de route appropriée, en fonction du VRF client à l’origine des annonces. Le routeur de réception utilise la valeur cible de route attachée pour identifier le VRF client dans lequel les informations de routage reçues doivent être placées.
Un environnement VPN MPLS en étoile utilise les cibles de route différemment, comme illustré sur la Figure 5. Pour chaque client, chaque VRF spoke attache la même valeur de cible de route lors de l’envoi des informations de routage. Le routeur de réception accepte les routes ayant la même valeur cible de route et les installe dans le VRF du hub. En revanche, le VRF du hub attache une valeur cible de route différente lors de l’envoi des informations de routage, et les routeurs récepteurs acceptent et installent des routes avec la même valeur de cible de route dans les VRF spoke.
Avec cette configuration, seul le VRF du hub accepte les routes des VRF à rayons, et seuls les VRF à rayons acceptent les routes à partir du VRF du hub. Avec cette méthode, les sites spoke n’ont besoin que de très peu d’informations de routage (peut-être juste un itinéraire par défaut) car ils n’ont besoin que d’une accessibilité au site hub, ce qui permet de réduire la taille des tables de routage et d’éviter les désabonnements.
MPLS en étoile
L’exemple de réseau en étoile 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 à un autre, ou lors de la répartition du trafic vers l’Internet local.
La figure 6 montre un exemple de site spoke où le périphérique spoke est configuré avec deux tunnels de superposition et un breakout local, tout le trafic transitant par la même interface. Chaque chemin de trafic possède son propre VRF, et les cibles de routage sont affectées de manière appropriée sur les sites spoke et hub afin de garantir une séparation correcte des itinéraires des locataires.
SD-WAN en étoile
Gestion des APBR et des 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’application définies par l’utilisateur, et utilise les intentions de stratégie pour identifier le meilleur chemin possible pour l’application. Le routage dynamique basé sur les applications permet de définir des stratégies qui basculeront 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 ; En d’autres termes, les appareils effectuent eux-mêmes des mesures de SLA sur les liaisons WAN disponibles, puis mappent dynamiquement le trafic de l’application vers le chemin qui répond le mieux aux exigences de SLA de l’application. Tout cela sans que le contrôleur CSO n’ait besoin de distribuer des routes spécifiques aux SLA.
Avec AppQoE, lorsqu’une violation de SLA se produit, seul le trafic correspondant à l’application qui a signalé la violation de SLA est déplacé vers un autre lien ; Le reste du trafic utilisant le lien n’est pas affecté.
Avec une gestion des SLA optimisée en temps réel, seul le VRF par défaut est requis, comme illustré sur la Figure 7. Le VRF par défaut utilise ECMP sur toutes les liaisons. La sélection du saut suivant par SLA se produit dans le chemin de données (décrit dans la section plan de données).
Dans ce cas, l’étiquette MPLS est utilisée uniquement pour identifier le locataire.
AppQoE est activé lorsque le mode SD-WAN du locataire est défini sur Optimisé en temps réel. Il s’agit du mode par défaut pour les déploiements SD-WAN.
Notez ce qui suit à propos d’AppQoE :
Uniquement pris en charge sur les périphériques SRX et pare-feu virtuel vSRX.
Les deux extrémités doivent utiliser la même version de Junos OS et la même configuration.
Le multihébergement 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 spoke envoie du trafic via l’équipement CPE local, et que le paquet n’est pas commuté localement ou envoyé directement sur Internet, il est envoyé via un tunnel à l’équipement central. Ce paquet provenant du réseau local 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. L’étiquette MPLS dans l’en-tête MPLSoGRE identifie le VRF à utiliser pour transférer le paquet sur le site du hub. L’en-tête de paquet résultant est illustré à la Figure 8.
Si le tunnel entre le spoke et le site hub est configuré pour utiliser IPsec, le paquet MPLSoGRE est alors chiffré davantage et encapsulé dans un en-tête IPsec qui utilise le mode tunnel. L’en-tête de paquet résultant est illustré à la 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é, identifié à l’aide de l’étiquette MPLS. En fonction de la recherche de route dans le VRF, le paquet est ensuite transféré vers un autre site spoke ou hors de l’environnement SD-WAN. S’il est transféré vers un autre rayon, le concentrateur 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, compte tenu de la nécessité d’un transport sécurisé des 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 les besoins.
conception de tunnel
APBR and SLA Management - Data Plane
Comme indiqué précédemment, les locataires peuvent choisir un mode SD-WAN de gestion des SLA pour le trafic applicatif :
Optimisé en temps réel : gestion des SLA au niveau de l’appareil, avec AppQoE
L’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 appareils. les appareils 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 en ligne :
Sondes passives
Des sondes en ligne qui suivent le trafic applicatif
Imitez l’éclatement des flux applicatifs
Activer la surveillance du RTT, de la gigue et de la perte de paquets pour la session d’application
Permet de surveiller le chemin actuellement utilisé pour vérifier la conformité aux SLA et détecter les violations de SLA
Sondes actives
Sondes périodiques (en fonction de la configuration) qui collectent 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 Optimisé en temps réel.
Tunnel Liveliness
Pour éviter le blackholing du trafic, des contrôles d’activité appropriés sont appliqués dans le réseau superposé. La solution Contrail SD-WAN utilise deux mécanismes pour assurer la vivacité :
IPsec Dead Peer Detection (DPD), lorsqu’il est utilisé
Keepalives GRE
Balises de maillage et VPN de maillage dynamique
Comme mentionné dans la discussion sur les modèles de déploiement, le maillage dynamique est l’implémentation de VPN à maillage complet de Juniper dans CSO, qui permet d’économiser des ressources. Cette section décrit le fonctionnement des balises de maillage et des VPN de maillage dynamique qu’elles activent.
Mesh Tags
Les balises de maillage sont des étiquettes textuelles appliquées aux interfaces WAN des équipements CPE et hub pendant le processus d’intégration dans CSO. CSO est livré avec deux balises de maillage 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 partageant la même balise de maillage.
La discussion suivante explique le fonctionnement des balises 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 appareils spoke tels que les NFX150 et NFX250, ainsi que sur la plupart des pare-feu SRX Series, une seule balise de maillage peut être appliquée à chaque interface WAN. Sur les concentrateurs du fournisseur et des concentrateurs d’entreprise tels que les appareils de la série SRX4x00, plusieurs balises de maillage peuvent être appliquées à chaque interface en raison des capacités VPN accrues des appareils.
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 étoile et décrit comment le VPN de site à site est mis en place.
de maillage dynamique
|
1
—
Sites et tunnels vers les sites Hub provisionnés à l’aide du protocole ZTP. Le trafic de site à site passe par les tunnels de données du site au hub. |
4
—
CSO configure des tunnels de site à site à la demande entre les paires de sites. |
|
deux
—
CSO reçoit des messages syslog des périphériques contenant des détails sur les taux de trafic. |
5
—
Le trafic de site à site bascule désormais vers les nouveaux tunnels de site à site. |
|
3
—
CSO reconnaît que le trafic entre le site 1 de Phoenix et le site 2 de Houston dépasse les seuils des KPI. |
La suppression des tunnels est également contrôlée et automatisée par CSO à l’aide de seuils de trafic et de la messagerie syslog.
Point d’accès à Internet
Alors que le trafic destiné à Internet peut être envoyé à travers les tunnels overlay et via un site central, les tunnels sont plus 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 sur site 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 d’avoir à acheminer l’ensemble du trafic vers le site central.
La répartition locale 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 moyen de 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
Il existe plusieurs façons d’implémenter le breakout local, en fonction des exigences de conception.
Breakout at Spoke
Le breakout local sur les sites en étoile permet aux utilisateurs d’accéder directement à Internet sans avoir à envoyer du trafic sur le réseau overlay vers le hub, ce qui permet d’économiser la bande passante du tunnel. Cette option peut être mise en œuvre sur des liaisons WAN Internet ou MPLS. La figure 12 illustre ce concept.
Lorsque vous utilisez le breakout local, vous pouvez spécifier un NAT basé sur l’interface ou sur le pool.
Breakout at Provider Hub (Central Breakout)
Le breakout central sur un site de hub de fournisseur permet des déploiements en étoile où les sites spoke transfèrent le trafic destiné à Internet via le réseau overlay vers le périphérique de hub du fournisseur, qui transfère ensuite le trafic vers Internet, comme illustré à la Figure 13.
L’activation du breakout central sur le site du hub est différente de celle sur un site en étoile. Il peut être configuré manuellement dans CSO via des modèles de l’étape 2.
Un breakout central peut également être fourni aux sites spoke par le biais d’un site Enterprise Hub. Dans ce scénario, le hub d’entreprise peut effectuer un breakout local à l’aide d’un réseau sous-jacent pour le transfert, ou recevoir la route par défaut du service Datacenter et la propager aux rayons.
Lorsque la répartition centralisée est proposée à la fois au niveau du hub fournisseur et du hub d’entreprise via la méthode de routage par défaut, la route par défaut à partir du hub d’entreprise est préférée à l’aide de la préférence locale BGP.
Cloud Breakout
Une autre option de breakout pour le trafic à destination d’Internet, Cloud Breakout, est disponible pour les sites spoke et les hubs d’entreprise. Lorsque le breakout cloud est activé, le site spoke ou le site du hub d’entreprise transfère le trafic à destination d’Internet à Zscaler pour un traitement ultérieur lié à la sécurité avant qu’il ne soit envoyé sur Internet. Le compte Zscaler doit être actif et accessible avant d’envoyer du trafic via le breakout.
Usage Notes for Cloud Breakout
Les tunnels GRE (Generic Routing Encapsulation) qui utilisent des adresses IP publiques pour les liaisons WAN sont pris en charge pour le breakout cloud.
Lors de l’utilisation de tunnels GRE, les périphériques CPE ne peuvent pas se trouver derrière le NAT.
Lorsque vous configurez les paramètres de répartition cloud, vous pouvez spécifier les paramètres IPsec phase 1, les paramètres phase 2 et le nom de domaine.
Vous pouvez spécifier une validation d’adresse IP ou de nom d’hôte pour les nœuds de breakout cloud.
CSO remplit automatiquement les informations relatives au nom de domaine complet, aux clés prépartagées et aux liaisons WAN, et offre la possibilité de modifier les valeurs renseignées automatiquement.
CSO prend en charge la haute disponibilité entre les liaisons WAN d’un site SD-WAN en étoile et le nœud de breakout cloud.
Les nœuds de liaison WAN peuvent être configurés comme 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 de breakout cloud.
Order of Preference for Scenarios with Multiple Breakout Options
Si plusieurs options de répartition sont disponibles pour le CPE sur le site spoke et qu’aucune stratégie de répartition n’est spécifiée, l’ordre de préférence pour la répartition est le suivant :
Département de centre de données/pôle d’entreprise
Breakout local/breakout cloud
Hub de fournisseurs (Centre)
Si plusieurs options de répartition sont disponibles pour un site hub d’entreprise, l’ordre de préférence pour le trafic de répartition est le suivant :
Sans stratégie SD-WAN :
Département Datacenter
Centre
Avec stratégie SD-WAN :
Breakout local/breakout cloud
Département Datacenter
Hub de fournisseurs (Centre)
Use Cases for Local Breakout
Certains cas d’utilisation de la répartition locale sont décrits ci-dessous.
Service Provider Data Center
Dans ce cas d’usage, l’entreprise cliente utilise le service SD-WAN du fournisseur de services pour assurer l’interconnectivité entre les sites. 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 en étoile, l’interface WAN MPLS de l’équipement sur site est configurée pour prendre en charge à la fois le trafic tunnelisé et le trafic breakout local. Comme illustré sur la Figure 14, le trafic circule sur le réseau comme suit :
Le trafic intersite (SD-WAN) traverse le réseau MPLS à l’aide du tunnel de superposition.
Le trafic destiné au centre de données utilise un breakout local et traverse directement le réseau MPLS sous-jacent.
À titre de variante de ce scénario, le centre de données pourrait être situé ailleurs sur le réseau MPLS, peut-être au niveau d’un point de présence, comme illustré sur la Figure 16. Dans ce cas, les flux de trafic restent globalement les mêmes que ci-dessus.
Autre variante de ce scénario, le trafic destiné au centre de données pourrait utiliser le tunnel de superposition, le breakout au niveau du concentrateur et le double retour vers le datacenter (comme illustré sur la Figure 16).
Cette option présente quelques inconvénients :
Il utilise davantage de bande passante de tunnel.
Cela peut augmenter la latence, car l’équipement local sur le site spoke traite et encapsule davantage de trafic.
Il augmente la charge sur l’équipement central.
Il crée un chemin sous-optimal, faisant transiter le trafic à travers les tunnels jusqu’à l’équipement central, avant de devoir redoubler pour atteindre le centre de données.
Cependant, il présente également certains avantages :
Grâce aux tunnels superposés, le trafic destiné aux datacenters peut tirer parti des services SLA et choisir dynamiquement le meilleur chemin, améliorant ainsi les performances du 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’usage, 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 à tout moment.
La figure 17 illustre un scénario où 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 tunnelisé et le trafic breakout local. Le trafic circule sur 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 transite directement par le réseau MPLS sous-jacent.
Dans ce cas, la répartition locale est essentielle pour maintenir la connectivité entre les sites migrés et les sites existants.
Local breakout and NAT
Lorsque le trafic transite d’un VRF de locataire vers Internet, NAT doit généralement être utilisé pour effectuer la traduction de l’espace réseau privé du locataire vers l’espace réseau Internet (public).
Sur les sites en étoile, les appareils locaux peuvent utiliser la NAT automatique pour effectuer automatiquement la NAT source sur l’ensemble du trafic breakout local. Sur les hubs, l’Auto-NAT n’est pas disponible ; Toutefois, l’interface utilisateur de CSO prend en charge la création manuelle de règles NAT pour ces équipements locaux.
Local Breakout and DNS
La configuration d’un périphérique local en tant que serveur DHCP pour les segments LAN vous permet de spécifier des informations de serveur DNS pour les hôtes finaux. Pour un site sur lequel 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 d’entreprise et un serveur public ou FAI 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 la sécurité des données non seulement au repos, mais aussi en mouvement. La sécurité des données a été renforcée pour permettre l’utilisation d’une PKI multi-niveaux pour les tunnels de données et OAM. Cela permet à CSO de recevoir des certificats d’autorité de certification à plusieurs niveaux à partir d’un serveur d’autorité de certification, d’envoyer plusieurs certificats d’autorité de certification aux équipements CPE, de renouveler et de révoquer plusieurs certificats d’autorité de certification sur les équipements CPE.
CSO prend en charge le protocole SCEP (Simple Certificate Enrollment Protocol) à partir de la version 4.1 de CSO. Cela permet à CSO de :
Agir en tant que serveur SCEP
Agir en tant que SCEP
Révocation de certificat
Renouvellement automatique du certificat
Déployer des certificats sur un CPE/site
Gérer les certificats sur CPE (site)
Fournir une interface graphique pour les informations du serveur CA
Renouvellements de certificats de site/CPE
Prise en charge des CA/NDES Microsoft
Certificats de broker pour chaque site/CPE
Une API back-end est fournie pour l’accès programmatique aux fonctionnalités PKI.
Data Plane
Les connexions au plan de données peuvent être configurées pour utiliser IPsec avec authentification basée sur PKI. Lorsqu’il est utilisé, l’équipement local sur site 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 publique-privée.
Management and Control Plane
CSO se connecte et configure les équipements locaux à l’aide de SSH pour les connexions de 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 authentifiés PKI (illustrés à la Figure 18) permettent aux périphériques spoke sur site d’envoyer en toute sécurité le trafic de gestion, de routage et de journalisation vers un hub de fournisseur via le réseau. Le hub transfère ensuite le trafic à CSO.
OAM sécurisé
Pour plus d’informations, consultez la section Réseau OAM sécurisé et redondant plus haut dans ce guide.