Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Architectures de déploiement Contrail SD-WAN

Une implémentation SD-WAN offre un moyen flexible et automatisé d’acheminer le trafic d’un site à l’autre. Comme le montre la Figure 1, une architecture SD-WAN de base ne comprend que quelques éléments de base

  • Sites multiples

  • Connexions multiples entre les sites qui forment le réseau sous-jacent

  • Tunnels de superposition multiples

  • Un contrôleur

Figure 1 : architecture SD-WAN Architecture SD-WAN

Le contrôleur SD-WAN, intégré à CSO, agit comme une couche d’orchestration et fournit une interface permettant à l’opérateur de configurer et de gérer les équipements sur les sites.

Architecture de référence Contrail SD-WAN

L’architecture de la solution Contrail SD-WAN de Juniper Networks, illustrée à la Figure 2 , utilise une topologie en étoile , avec des équipements CPE situés sur les sites des clients. Sur le côté local du site, les équipements CPE se connectent aux segments LAN et participent à des protocoles de routage dynamique avec d’autres équipements LAN. Sur le WAN, les équipements CPE se connectent via au moins deux liaisons à un équipement du hub du fournisseur. Le modèle SD-WAN utilisant une topologie en étoile, le trafic transite par le hub du fournisseur. Par défaut, le trafic à destination d’Internet transite également par l’appareil du concentrateur du fournisseur.

Figure 2 : architecture Contrail SD-WAN Reference Architecture de référence de Contrail SD-WAN

Les fonctions d’orchestrateur et de contrôleur SD-WAN sont mises en uvre via un logiciel Juniper Networks Contrail Service Orchestration (CSO). La plate-forme CSO utilise des stratégies et des paramètres SLA pour différencier et diriger les flux de trafic sur les chemins disponibles, comme vous le souhaitez.

Les sections suivantes décrivent ces éléments architecturaux plus en détail.

Appareils à rayons

Dans le modèle SD-WAN, l’équipement CPE situé sur les sites distants d’une entreprise cliente agit comme un appareil en étoile. L’appareil joue également le rôle de routeur de passerelle et assure la connectivité entre le site de la filiale et d’autres sites du réseau locataire et Internet. Il existe deux types d’appareils spoke : les spoke sur site et les spoke cloud.

Appareils spoke sur site

Les périphériques spoke sur site peuvent être des périphériques NFX Series ou des périphériques SRX Series spécifiques.

NFX Series Plate-forme de services réseau

Un NFX Series Plate-forme de services réseau utilisé comme périphérique spoke sur site peut héberger une gamme de VNF multifournisseurs, prendre en charge le chaînage de services et être géré par un logiciel d’orchestration dans le cloud. Les équipements NFX Series éliminent la complexité opérationnelle liée au déploiement de plusieurs équipements réseau physiques sur un site client et offrent une amélioration substantielle par rapport aux équipements CPE traditionnels à fonction unique.

Une VNF clé prise en charge sur la plate-forme NFX Series est le pare-feu virtuel vSRX. Dans la solution Contrail SD–WAN, c’est l’instance vSRX dotée de fonctionnalités de routage et de commutation qui assure la fonction de routeur de passerelle. Il fournit également les mêmes services de sécurité riches en fonctionnalités que l’on trouve sur les équipements SRX Series standard. Le Tableau 1 présente le matériel NFX Series que vous pouvez implémenter en tant que périphérique spoke sur site.

Note:

Le NFX150 intègre un pare-feu SRX à la place de la fonctionnalité vSRX des autres équipements NFX Series.

Tableau 1 : matériel NFX Series – Périphériques spoke sur site

Plate-forme

Modèles pris en charge

Plate-forme de services réseau NFX150

  • NFX150–S1

  • NFX150–S1E

  • NFX150–C–S1

  • NFX150–C–S1–AE/AA

  • NFX150–C–S1E–AE/AA

Plate-forme de services réseau NFX250

  • NFX250–LS1

  • NFX250–S1

  • NFX250–S2

Équipements SRX Series et pare-feu virtuels vSRX

Un équipement de sécurité physique SRX Series peut être utilisé à la place de la plate-forme NFX Series pour fournir la fonction de routeur de passerelle, tout comme une instance vSRX installée sur un serveur. Le Tableau 2 présente les pare-feu matériels SRX et virtuels vSRX que vous pouvez implémenter en tant que périphériques spoke sur site.

Tableau 2 : matériel SRX Series et pare-feu vSRX – Périphériques spoke sur site

Plate-forme

Modèles pris en charge

SRX Series

  • SRX4200

  • SRX4100

  • SRX1500

  • SRX550M

  • Le SRX380

  • Le SRX345

  • Le SRX340

  • Le SRX320

  • Le SRX300

Pare-feu virtuels vSRX

vSRX

vSRX 3.0

Note:

Pour obtenir les informations les plus récentes sur la prise en charge matérielle et logicielle de CSO, consultez les Notes de mise à jour de Contrail Service Orchestration.

Appareils spoke dans le cloud

Un équipement Contrail SD-WAN en étoile dans le cloud, sous la forme d’un vSRX, peut être localisé dans un VPC AWS. Le vSRX sert de spoke device dans le cloud. Une fois que le point de terminaison est en ligne, il agit comme n’importe quel autre appareil spoke.

Redondance des rayons

Deux périphériques CPE redondants peuvent être utilisés sur les sites spoke pour se protéger contre les pannes d’équipements et de liaisons. Pour plus d’informations, consultez la section Résilience et haute disponibilité. du Guide de conception et d’architecture Contrail SD-WAN.

Appareils du Provider Hub

La solution Contrail SD-WAN prend en charge deux topologies de déploiement (abordées plus loin dans ce guide) : le maillage dynamique et le réseau en étoile. Dans un déploiement de maillage dynamique, chaque site dispose d’un équipement CPE qui se connecte aux autres sites et à l’équipement du hub d’entreprise. Dans un déploiement en étoile, il existe au moins un équipement Provider Hub et un ou plusieurs appareils spoke.

Le concentrateur du fournisseur termine les tunnels MPLS/GRE et IPsec des périphériques spoke.

Hubs de fournisseurs

Dans un environnement de fournisseur de services (SP), le fournisseur de services héberge un équipement de concentrateur fournisseur sur son réseau. L’équipement du concentrateur du fournisseur agit comme un point de présence (POP) ou un point de connexion. Il s’agit généralement d’un appareil partagé, fournissant une fonctionnalité de hub à plusieurs clients (locataires) grâce à l’utilisation d’instances VRF (Virtual Routing and Forwarding Instances). L’administrateur SP et l’administrateur OpCo peuvent tous deux gérer l’appareil du concentrateur fournisseur.Pour CSOaaS, le rôle d’administrateur SP est exercé par Juniper Networks en tant qu’utilisateur cspadmin (ou équivalent). Le rôle d’administrateur OpCo peut être attribué à un utilisateur par l’administrateur SP, mais l’administrateur OpCo ne dispose pas de privilèges d’administrateur SP.Le Tableau 3 répertorie les équipements Provider Hub pris en charge dans un environnement CSO SD-WAN.

Tableau 3 : Appareils Provider Hub

Rôle

Types d’appareils pris en charge

Hub de fournisseurs

  • SRX4600

  • SRX4200

  • SRX4100

  • SRX1500

  • vSRX

  • vSRX 3.0

Note:

Pour obtenir les informations les plus récentes sur la prise en charge matérielle et logicielle de CSO, consultez les Notes de mise à jour de Contrail Service Orchestration.

Redondance des concentrateurs de fournisseurs

Il est possible d’utiliser deux concentrateurs fournisseurs redondants sur un seul point de présence afin de protéger contre les défaillances d’appareils et de liaisons, et d’assurer le multihébergement en amont des sites spoke. Pour plus d’informations, consultez la rubrique Résilience et haute disponibilité de ce guide.

Sites et appareils Enterprise Hub

Un type spécial de périphérique spoke, appelé périphérique de hub d’entreprise, peut être déployé en tant que CPE sur un site spoke local. Les appareils SRX1500, SRX4100 et SRX4200 peuvent remplir cette fonction. Le site spoke qui fonctionne de cette façon doit être configuré en tant que site hub d’entreprise lors de la création du site. La création d’un site hub d’entreprise ouvre des fonctionnalités supplémentaires pour le site :

  • Peut servir de point d’ancrage pour les communications de site à site sur le réseau du client.

  • Peut faire office de nœud de breakout central pour le réseau du client.

  • Offre un département spécialisé appelé le département de centre de données.

  • Prend en charge les segments LAN dynamiques du centre de données avec des importations de routes BGP et OSPF, y compris les routes par défaut, à partir de l’équipement de couche 3 côté LAN.

  • Permet aux profils de répartition basés sur l’intention de créer un comportement de rupture granulaire en fonction du service, de l’application, du site, etc.

Dans un environnement d’entreprise, le hub d’entreprise appartient au client (locataire) et réside généralement dans un centre de données d’entreprise. Seuls les sites spoke du client peuvent se connecter à l’équipement du hub d’entreprise. Les administrateurs OpCo et les administrateurs de locataires peuvent gérer le hub d’entreprise. Le Tableau 4 répertorie les équipements du hub d’entreprise pris en charge dans un environnement SD-WAN CSO.

Tableau 4 : équipements du hub d’entreprise

Rôle

Types d’appareils pris en charge

Hub d’entreprise

  • SRX4600

  • SRX4200

  • SRX4100

  • SRX1500

  • Le SRX380

  • vSRX

  • vSRX 3.0

Note:

Pour obtenir les informations les plus récentes sur la prise en charge matérielle et logicielle de CSO, consultez les Notes de mise à jour de Contrail Service Orchestration.

Réseau sous-jacent (physique)

Le réseau sous-jacent comprend la connectivité physique entre les équipements de l’environnement SD-WAN. Cette couche du réseau n’a aucune connaissance des segments LAN des clients, elle assure simplement l’accessibilité entre les équipements sur site.

La figure 3 montre un exemple de réseau sous-jacent pour un déploiement SD-WAN en étoile (les détails s’appliquent également à une configuration de maillage dynamique). Chaque site spoke dispose généralement de plusieurs chemins d’accès au site du hub ; dans ce cas, l’un via le cloud MPLS privé et l’autre via Internet.

Figure 3 : réseau SD-WAN Underlay Network sous-jacent SD-WAN

Chaque équipement (ou site) sur site peut avoir jusqu’à quatre liaisons WAN, y compris une liaison satellite qui peut être utilisée pour OAM. Lors de la configuration, CSO identifie les interfaces WAN des équipements comme étant WAN_0 à WAN_3.

Notez que :

  • Les interfaces WAN peuvent être étiquetées VLAN ou non, selon les exigences de conception.

  • Les interfaces Internet des appareils sur site peuvent être rattachées à différents réseaux de fournisseurs de services.

Options d’accès WAN

Chaque type d’accès WAN répertorié ci-dessous peut être utilisé pour le trafic ZTP, de données ou OAM. Toutes les liaisons peuvent être exploitées simultanément pour le trafic de données.

  • MPLS

  • Ethernet

  • LTE

    Note:

    Accès WAN LTE pris en charge à l’aide d’un dongle sur les équipements NFX250 Series.

    Accès WAN LTE pris en charge à l’aide d’une interface intégrée sur les équipements NFX150 Series.

    Accès WAN LTE pris en charge à l’aide d’un mini-PIM dans l’emplacement 1 des équipements SRX300 Series.

    Toutes les interfaces LTE mentionnées précédemment sont prises en charge pour ZTP.

    Uniquement pris en charge pour les déploiements SD-WAN en étoile avec un seul CPE.

    Les déploiements NAT à cône complet et restrictifs sont pris en charge.

    Les configurations CPE doubles ne sont pas prises en charge.

    Les paramètres APN LTE peuvent être localisés pour la région d’installation pendant le processus ZTP.

  • ADSL/VDSL (prise en charge ADSL/VDSL des liaisons WAN et ZTP sur les équipements NFX Series à partir de CSO version 4.0.0 et prise en charge ADSL sur la gamme de passerelles de services SRX300 à partir de CSO version 5.2.0.)

  • Large bande

  • MPLS et haut débit

  • Liaison satellite

Types d’interfaces WAN : données et OAM

Les interfaces WAN sont principalement utilisées pour envoyer et recevoir du trafic utilisateur (données). Au moins une des interfaces WAN doit également être utilisée pour le trafic de gestion (OAM). L’interface OAM est utilisée pour communiquer avec CSO et permet à CSO de gérer l’appareil local.

La Figure 4 illustre ces deux types d’interfaces.

Figure 4 : types d’interfaces WAN Interface Types WAN

Notez que :

  • L’interface OAM de l’appareil local doit pouvoir atteindre CSO. La connectivité peut être fournie strictement à l’aide de réseaux de superposition orchestrés par CSO. Pour cela, vous n’avez pas besoin d’une connectivité réseau sous-jacente préexistante. À partir de la version 5.0.1 de CSO, CSO sélectionne automatiquement une adresse IP pour l’interface OAM de l’appareil local. Cela garantit que l’adresse est unique dans l’ensemble du déploiement CSO et évite les erreurs humaines.

  • Pour garantir une communication sécurisée sur le WAN, l’équipement sur site établit la connexion au CSO.

  • Les connexions initiées par l’appareil peuvent fonctionner sur des équipements NAT intermédiaires.

  • L’interface utilisateur et OAM-data peut utiliser une seule adresse IP pour les deux fonctions.

Réseau de superposition (tunnels)

Le réseau superposé comprend la connectivité du tunnel logique entre les équipements de l’environnement SD-WAN. Cette couche du réseau connaît les segments LAN des clients et est responsable du transport du trafic des clients entre les sites.

La figure 5 illustre un réseau superposé pour un environnement en étoile. Chaque site spoke dispose de deux tunnels pour acheminer le trafic vers le hub : l’un via le cloud MPLS privé et l’autre via Internet.

Figure 5 : superposition SD-WAN Hub-and-Spoke Overlay de réseaux en étoile SD-WAN

Les tunnels disposent de deux options d’encapsulation : MPLSoGRE ou MPLSoGREoIPsec. CSO provisionne et établit automatiquement ces tunnels dans le cadre du processus de déploiement.

Topologies de déploiement de superposition

La solution SD-WAN prend en charge les topologies de déploiement en étoile ou de maillage dynamique. Une topologie de maillage dynamique est similaire à une topologie de maillage complet, dans laquelle chaque site est capable de se connecter directement à n’importe quel autre site. Mais avec le maillage dynamique, les connexions (tunnels) sont mises en place à la demande, réduisant ainsi la charge continue sur un site donné. Un seul locataire peut prendre en charge à la fois les topologies en étoile et de maillage dynamique.

Hub and Spoke

Avec la topologie en étoile, tous les sites en étoile sont connectés à au moins un site de moyeu, comme illustré sur la Figure 6. Les sites spoke ne peuvent pas communiquer directement avec d’autres sites spoke.

Figure 6 : topologie SD-WAN Hub-and-Spoke Topology en étoile du SD-WAN

Les sites de hub utilisés peuvent être des sites de hub de fournisseur ou d’entreprise. Lorsqu’un site hub d’entreprise est utilisé, le hub fournisseur (le cas échéant) est utilisé comme sauvegarde uniquement. Cette topologie est privilégiée lorsque les applications et les services sont centralisés sur le site du hub.

Dynamic Mesh

Avec la topologie de maillage dynamique, des tunnels de superposition entre les sites participants permettent aux sites de communiquer directement entre eux, comme illustré sur la Figure 7. Bien que la figure montre la connexion DATA_AND_OAM sur la liaison MPLS, WAN_0, cette fonction peut être exécutée sur les liaisons MPLS ou Internet.

Figure 7 : topologie SD-WAN Dynamic Mesh Topology de maillage dynamique SD-WAN

Cette topologie est particulièrement adaptée aux déploiements où les applications et les services ne sont pas centralisés.

Note:

Les topologies en étoile et de maillage intégral nécessitent d’ajouter une superposition de réseau OAM sécurisée, et donc un hub OAM, au déploiement.

Lorsque des périphériques spoke sont ajoutés à une topologie de maillage dynamique, l’administrateur qui configure les sites doit attribuer une balise de maillage à chaque interface WAN. Seuls deux appareils avec des balises de maillage correspondantes peuvent former la connexion VPN pour permettre la communication. Les interfaces avec des balises de maillage incompatibles ne peuvent jamais communiquer directement.

Orchestration et contrôle

Les fonctions d’orchestration et de contrôleur sont implémentées via le logiciel Contrail Service Orchestration (CSO) de Juniper. Comme illustré sur la Figure 8, le logiciel CSO offre une interface utilisateur Web pour gérer l’environnement SD-WAN. La figure 8 est un exemple d’image et le numéro de version CSO y figure à titre de référence uniquement.

Figure 8 : écran CSO Login Screen de connexion CSO

La couche d’orchestration des services contient Network Service Orchestrator (NSO). Le logiciel d’orchestration offre une vue globale de toutes les ressources et permet la gestion des locataires, offrant ainsi une orchestration, une visibilité et une surveillance du trafic de bout en bout. La couche d’orchestration de domaine contient le contrôleur de service réseau (NSC). Le logiciel d’orchestration fonctionne de concert avec le contrôleur pour gérer les équipements sur site (CPE) et fournir des fonctionnalités de gestion de la topologie et du cycle de vie CPE.

Au niveau de l’utilisateur, CSO fournit l’interface pour déployer, gérer et surveiller les équipements du réseau SD-WAN via le NSC. Au niveau du réseau, NSC inclut un vRR qui permet à chaque site d’annoncer ses routes locales aux sites distants.

Réseau OAM sécurisé

Les déploiements SD–WAN incluent un réseau OAM sécurisé superposé pour assurer des communications sécurisées de bout en bout entre les équipements sur site et CSO. Pour les CSOaaS, cela est automatiquement fourni dans le cadre du service.

Comme illustré sur la Figure 9, des tunnels OAM dédiés chiffrés par IPsec permettent aux équipements sur site d’envoyer du trafic de gestion, de routage et de journalisation en toute sécurité sur le réseau vers un hub de fournisseur. Le hub du fournisseur transfère ensuite le trafic vers CSO.

Figure 9 : Tunnels OAM sécurisés Secure OAM Tunnels

Intégration avec les topologies de déploiement

Les topologies de déploiement en étoile et de maillage dynamique doivent utiliser des tunnels OAM sécurisés.

Étoile

Avec la topologie en étoile, chaque site spoke dispose désormais de deux ensembles de connexions au site du hub fournisseur : un tunnel de superposition IPsec dédié transportant des données et un tunnel de superposition IPsec dédié distinct transportant le trafic OAM, comme illustré à la Figure 10.

Figure 10 : Tunnels OAM dans la topologie OAM Tunnels in the Hub-and-Spoke Topology en étoile

Maillage dynamique

Étant donné qu’une topologie de maillage complet normale n’inclut pas de périphérique central pour le trafic de données, il est nécessaire d’en ajouter un. Comme illustré sur la Figure 11, chaque site spoke dispose d’une nouvelle connexion : un tunnel overlay IPsec dédié distinct qui achemine le trafic OAM vers le hub du fournisseur.

Figure 11 : Tunnels OAM dans la topologie OAM Tunnels in the Full Mesh Topology à maillage complet

Options de conception du hub OAM

Il existe deux façons d’implémenter le hub OAM dans un déploiement CSO local, en fonction des exigences de conception. Comme illustré sur la Figure 12, les options sont les suivantes :

  • Les tunnels de données et OAM se terminent sur le même équipement de hub de fournisseur : il s’agit d’une bonne option pour les petits déploiements, où l’équipement de hub unique peut gérer à la fois les données et le trafic OAM.

  • Les tunnels de données et OAM se terminent sur des périphériques de hub de fournisseur distincts : cette option peut être utile pour les déploiements plus importants où les ressources de l’équipement de hub principal sont nécessaires pour gérer les tunnels de superposition transportant le trafic de données ; un deuxième équipement de concentrateur peut être utilisé pour terminer les tunnels OAM.

    Figure 12 : Tunnels OAM - Options OAM Tunnels - Provider Hub Design Options de conception du hub fournisseur
Note:

Pour les CSOaaS, le hub OAM est fourni dans le cadre du service.

Toutefois, un administrateur OpCo peut déployer un hub DATA_ONLY ou OAM_AND_DATA. Dans le cas d’un hub DATA_ONLY, le hub DATA dispose d’un tunnel sécurisé IPsec vers le OAM_HUB. Dans le cas d’un hub OAM_AND_DATA, l’administrateur OpCo est tenu de configurer la connexion sécurisée IPsec entre le HUB OAM_AND_DATA et CSO.

Notes d’utilisation sur les options de conception de Provider Hub

  • Un hub OAM peut prendre en charge plusieurs locataires ou être dédié à un seul locataire.

  • La connectivité entre le ou les hubs du fournisseur et CSO doit être privée et sécurisée, car elle n’est pas couverte par les tunnels OAM.

  • Nous vous recommandons d’implémenter plusieurs hubs OAM pour assurer la redondance et éviter toute perte de gestion ou de surveillance des équipements locaux.

    Pour les CSOaaS, la redondance du hub OAM fait partie du service.

  • Lorsqu’un site spoke est multi-hébergé sur plusieurs périphériques, un tunnel OAM doit se terminer sur chaque hub.

  • Les équipements locaux utilisant NAT sont pris en charge pour les déploiements en étoile.

Zero Touch Provisioning

L’une des principales caractéristiques de la solution Contrail SD–WAN est la possibilité de « brancher et jouer » de nouveaux périphériques spoke à l’aide de la fonction ZTP (auto-installation). Voici une liste générale des étapes effectuées pendant le ZTP :

  • Si vous implémentez la version locale de CSO, vous devez ajouter le certificat SSL CSO approprié au serveur de redirection avant d’effectuer le ZTP.

    Note:

    Si vous déployez la version cloud de CSO, Juniper Networks configure le serveur de redirection pour vous.

  • Lorsqu’un périphérique spoke se connecte pour la première fois, il utilise un serveur DHCP local pour obtenir une adresse IP et des informations sur le serveur de noms.

  • Le périphérique spoke contacte ensuite le serveur de redirection, qui fournit le nom DNS et le certificat pour l’installation CSO.

  • Le périphérique spoke contacte ensuite le serveur CSO pour obtenir sa configuration initiale et la mise à jour du logiciel Junos OS (si nécessaire).

Note:

Les versions 4.1 et ultérieures de CSO incluent des améliorations qui réduisent la bande passante requise pour le ZTP à 2 Mbit/s.

Remarques sur l’utilisation du ZTP

  • Au moins une des interfaces WAN de l’appareil doit obtenir son adresse IP à partir d’un serveur DHCP afin de pouvoir également se voir attribuer un serveur de noms DNS et une route par défaut.

  • CSO et le serveur de redirection doivent être accessibles via la même interface WAN.

  • Le processus ZTP peut être exécuté à partir de n’importe quelle interface WAN de l’appareil spoke, y compris une liaison satellite.

  • Le téléchargement de la configuration initiale peut prendre beaucoup de temps, en particulier sur les liaisons lentes, en raison de la taille de la configuration et du logiciel Junos OS.

Serveur de redirection

Le serveur de redirection est un serveur situé sur Internet, détenu et géré par Juniper, qui fait partie intégrante du processus ZTP. Le serveur permet à chaque périphérique spoke de localiser et de s’authentifier auprès de son instance CSO désignée. Avec l’aide du serveur de redirection, le périphérique spoke peut contacter CSO et recevoir sa configuration initiale, y compris une mise à jour du logiciel Junos OS (si nécessaire).

Pour les déploiements locaux de CSO, l’administrateur configure les ports WAN sur les périphériques spoke pour qu’ils se connectent à la fois à Internet et au serveur de redirection. Pour les CSO hébergés dans le cloud, Juniper Networks gère cette configuration pour vous.

Sur la Figure 13, le serveur de redirection et CSO sont tous deux situés sur Internet. L’appareil spoke obtient et utilise l’adressage IP et d’autres informations fournies par son interface Internet, et peut atteindre à la fois le serveur de redirection et le CSO via cette même interface WAN.

Figure 13 : CSO et serveur de redirection sur Internet CSO and Redirect Server on Internet

Chaînage de services dans Contrail SD-WAN

À partir de la version 4.0 de CSO, le chaînage de services est disponible pour les environnements SD-WAN. Le chaînage de services du service est un concept dans lequel plusieurs services réseau instanciés dans un logiciel et exécutés sur du matériel x86 sont liés, ou enchaînés de manière de bout en bout. Cela permet à un appareil physique de fournir les services normalement fournis par plusieurs équipements. Le chaînage de services du service peut être effectué sur les équipements NFX Series, comme illustré à la Figure 14.

Figure 14 : Chaînage de services dans un environnement Service Chaining in an SD-WAN Environment SD-WAN

À partir de la version 4.0 de CSO, les fonctions réseau virtuelles tierces (VNF) suivantes sont prises en charge : Fortigate-VM et Single-legged Ubuntu VM.

Note:
  • Actuellement, seul le mode VNF de couche 2 est pris en charge dans les chaînes de services SD-WAN.

Trois plans, quatre couches

Pour rassembler tous ces éléments, l’architecture Contrail SD–WAN peut être conçue en trois plans, composés de quatre couches fonctionnelles :

  1. Plan de données :

    • Comprend le réseau sous-jacent ; fournit une connectivité physique

    • Comprend le réseau de superposition ; Fournit des tunnels pour le trafic des données des locataires

  2. Control Plane (Plan de contrôle) : inclut les protocoles de routage qui transitent par les tunnels OAM

  3. Plan de gestion : inclut les tunnels de superposition pour le réseau OAM sécurisé

La figure 15 illustre ce concept.

Figure 15 : trois plans, quatre couches Three Planes, Four Layers
Tableau de l’historique des versions
Libération
Description
4.0
À partir de la version 4.0 de CSO, le chaînage de services est disponible pour les environnements SD-WAN.
4.0
À partir de la version 4.0 de CSO, les fonctions réseau virtuelles tierces (VNF) suivantes sont prises en charge : Fortigate-VM et Single-legged Ubuntu VM.