Routage de superposition SD-WAN

Citrix SD-WAN fournit une connectivité résiliente et robuste entre les sites distants, les centres de données et les réseaux cloud. La solution SD-WAN peut y parvenir en établissant des tunnels entre les appliances SD-WAN du réseau permettant la connectivité entre les sites en appliquant des tables de routage qui superposent le réseau de sous-couche existant. Les tables de routage SD-WAN peuvent remplacer ou coexister avec l’infrastructure de routage existante.

Les appliances Citrix SD-WAN mesurent les chemins disponibles unidirectionnellement en termes de disponibilité, de perte, de latence, de gigue et de congestion, et sélectionnent le meilleur chemin par paquet. Cela signifie que le chemin choisi entre le site A et le site B, ne doit pas nécessairement être le chemin choisi du site B au site A. Le meilleur chemin à un moment donné est choisi indépendamment dans chaque direction. Citrix SD-WAN offre une sélection de chemin basé sur des paquets pour une adaptation rapide à toute modification du réseau. Les appliances SD-WAN peuvent détecter les pannes de chemin après seulement deux ou trois paquets manquants, ce qui permet un basculement subsecondaire continu du trafic d’applications vers le chemin WAN le plus proche. Les appliances SD-WAN recalculent chaque état de liaison WAN en environ 50 ms. L’article suivant fournit une configuration de routage détaillée au sein du réseau Citrix SD-WAN.

Table de routage Citrix SD-WAN

Le SD-WAN autorise des entrées de route statiques pour des sites spécifiques et des entrées de route apprises du réseau sous-jacent via des protocoles de routage pris en charge, tels que OSPF, eBGP et iBGP. Les itinéraires ne sont pas seulement définis par leur prochain saut, mais par leur type de service. Cela détermine le mode de transfert de l’itinéraire. Les principaux types de services utilisés sont les suivants :

• Service local : désigne tout itinéraire ou sous-réseau local vers l’appliance SD-WAN. Cela inclut les sous-réseaux Virtual Interface (crée automatiquement des itinéraires locaux) et toute route locale définie dans la table de routage (avec un saut suivant local). La route est annoncée pour d’autres appliances SD-WAN qui ont un chemin virtuel vers ce site local où cette route est configurée lorsqu’elle est approuvée en tant que partenaire.

Remarque

Soyez prudent lorsque vous ajoutez des itinéraires par défaut et des itinéraires récapitulatifs en tant qu’itinéraires locaux, car ceux-ci peuvent entraîner des itinéraires de chemins virtuels sur d’autres sites. Vérifiez toujours les tables de routage pour vous assurer que le routage correct est en vigueur.

• Chemin virtuel  : désigne tout itinéraire local appris à partir d’un site SD-WAN distant accessible sur les chemins virtuels. Ces routes sont normalement automatiques, mais une route de chemin virtuel peut être ajoutée manuellement sur un site. Tout trafic pour cette route est transféré vers le chemin virtuel défini pour cette route de destination (sous-réseau).

• Intranet  : indique les routes accessibles via une liaison WAN privée (MPLS, P2P, VPN, etc.). Par exemple, une succursale distante qui se trouve sur le réseau MPLS mais ne possède pas d’appliance SD-WAN. Il est supposé que ces routes doivent être transmises à un certain routeur WAN. Le service Intranet n’est pas activé par défaut. Tout trafic correspondant à cette route (sous-réseau) est classé comme intranet pour cette appliance en vue de sa remise à un site ne disposant pas d’une solution SD-WAN.

Remarque

Notez que lors de l’ajout d’une route Intranet, il n’y a pas de saut suivant, mais plutôt de transfert vers un service Intranet. Le Service est associé à une liaison WAN donnée.

• Internet  : similaire à l’intranet, mais il est utilisé pour définir le trafic circulant vers des liens WAN Internet publics plutôt que vers des liens WAN privés. Une différence unique est que le service Internet peut être associé à plusieurs liaisons WAN et réglé sur l’équilibre de charge (par flux) ou être actif/sauvegarde. Une route Internet par défaut est créée lorsque le service Internet est activé (il est désactivé par défaut). Tout trafic correspondant à cette route (sous-réseau) est classé comme Internet pour cette appliance en vue de sa remise aux ressources Internet publiques.

Remarque

Les routes de service Internet peuvent être publiées sur les autres appliances SD-WAN ou ne pas être exportées selon que vous utilisez ou non l’accès Internet via les chemins virtuels.

• Passthrough  : ce service agit en dernier recours ou en remplacement lorsqu’une appliance est en mode en ligne. Si une adresse IP de destination ne correspond pas à une autre route, l’appliance SD-WAN la transmet simplement sur le saut suivant du lien WAN. Un itinéraire par défaut : le coût 0.0.0.0/0 de 16 itinéraires pass-through est créé automatiquement. Passthrough ne fonctionne pas lorsque l’appliance SD-WAN est déployée hors chemin ou en mode Edge/Gateway. Tout trafic correspondant à cet itinéraire (sous-réseau) est classé comme passthrough pour cette appliance. Il est recommandé que le trafic de transit soit limité autant que possible.

Remarque

La transmission peut être utile lors de l’exécution d’un POC pour éviter d’avoir à configurer de nombreuses gammes, mais soyez prudent en production car le SD-WAN ne tient pas compte de l’utilisation de la liaison WAN pour le trafic envoyé au passage. Il est également utile lorsque vous résolvez des problèmes et que vous souhaitez retirer un certain flux IP de la livraison sur le chemin virtuel.

• Discard - Ce n’est pas un service mais un itinéraire de dernier recours qui supprime les paquets s’il correspond. Normalement, cela ne se produit pas s’attendre lorsque l’appliance SD-WAN est déployée hors du chemin d’accès. Vous devez avoir un service Intranet ou une route locale en tant que catch all itinéraire, sinon le trafic est rejeté car il n’y a pas de service passthrough (même si une route passthrough par défaut sera présente).

La table de routage du nœud client local peut être surveillée sur la page Surveillance > Statistiques avec Itinéraires sélectionnées dans la liste déroulante Afficher.

Chaque itinéraire pour les sous-réseaux de succursales distantes est annoncé en tant que service via le chemin virtuel qui se connecte via le MCN, la colonne Site étant renseignée avec le nœud client où réside la destination en tant que sous-réseau local.

Dans l’exemple suivant, lorsque le transfert WAN vers WAN (Routes Export) est activé, la branche A dispose d’une entrée de table de routage pour le sous-réseau Branche B (10.2.2.0/24) via le MCN en tant que saut suivant.

Comment le trafic Citrix SD-WAN correspond sur des itinéraires définis

Le processus de correspondance pour les itinéraires définis sur Citrix SD-WAN est basé sur la correspondance de préfixe la plus longue pour le sous-réseau de destination (similaire à une opération de routeur). Plus l’itinéraire est spécifique, plus le changement est élevé. Le tri se fait dans l’ordre suivant :

1. Correspondances de préfixe les plus longues
2. Coût
3. Service

Par conséquent, un itinéraire /32 précède toujours un itinéraire /31. Pour deux routes /32, un itinéraire Coût 4 précède toujours un itinéraire Coût 5. Pour deux /32 coût 5 routes, les routes sont choisies en fonction de l’hôte IP commandé. La commande de service est la suivante : Local, Chemin virtuel, Intranet, Internet, Passthrough, Ignorer.

À titre d’exemple, considérez les deux routes suivantes comme suit :

• 192.168.1.0/24 Coût 5

• 192.168.1.64/26 Coût 10

Un paquet destiné à l’hôte 192.168.1.65 utiliserait cette dernière route même si le coût est plus élevé. Sur cette base, il est courant que la configuration soit en place uniquement pour les routes destinées à être livrées via la superposition de chemin virtuel avec d’autres trafic entrant dans la capture de toutes les routes telles qu’une route par défaut vers le service de passage.

Les itinéraires peuvent être configurés dans une table de routage de noeud de site qui a le même préfixe. Le saut de connexion passe ensuite au coût de l’itinéraire, au type de service (chemin virtuel, intranet, Internet, etc.) et à l’adresse IP de saut suivant.

Flux de paquets de routage Citrix SD-WAN

• Correspondance de l’itinéraire de trafic LAN vers WAN (chemin virtuel) :

  1. Le trafic entrant est reçu par l’interface LAN et est traité.

  2. La trame reçue est comparée à la table de routage pour la correspondance de préfixe la plus longue.

  3. Si une correspondance est trouvée, la trame est traitée par le moteur de règles et un flux est créé dans la base de données de flux.

• Correspondance de l’itinéraire de trafic WAN vers LAN (chemin virtuel) :

  1. Le trafic de chemin virtuel est reçu par SD-WAN à partir du tunnel et est traité.

  2. l’appliance compare l’adresse IP source pour vérifier si la source est locale.

     • Si oui, alors éligible au WAN et faites correspondre la destination IP à la table de route/chemin virtuel.

     • Si non, alors la vérification du transfert WAN vers WAN est activée.

  3. (Transfert WAN vers WAN désactivé) Transférer vers LAN en fonction des itinéraires locaux.

  4. (Transfert WAN vers WAN activé) Transférer vers le chemin virtuel en fonction de la table de routage.

• Trafic de chemin non virtuel :

  1. Le trafic entrant est reçu sur l’interface LAN et est traité.

  2. La trame reçue est comparée à la table de routage pour la correspondance de préfixe la plus longue.

  3. Si une correspondance est trouvée, la trame est traitée par le moteur de règles et un flux est créé dans la base de données de flux.

Prise en charge du protocole de routage Citrix SD-WAN

Citrix SD-WAN version 9.1 introduit les protocoles de routage OSPF et BGP dans la configuration. L’introduction de protocoles de routage au SD-WAN a facilité l’intégration du SD-WAN dans des réseaux de sous-couche plus complexes où les protocoles de routage sont activement utilisés. Avec les mêmes protocoles de routage activés sur le service SD-WAN Orchestrator, la configuration des sous-réseaux désignés pour utiliser la superposition SD-WAN a été facilitée. En outre, les protocoles de routage permettent la communication entre les sites SD-WAN et non-SD-WAN avec communication directe avec les routeurs périphériques clients existants à l’aide du protocole de routage commun. Citrix SD-WAN participant aux protocoles de routage fonctionnant dans le réseau sous-jacent peut être fait quel que soit le mode de déploiement du SD-WAN (mode Inline, mode Virtual Inline ou mode Edge/Gateway). En outre, le SD-WAN peut être déployé en mode « apprentissage seulement » où le SD-WAN peut recevoir des itinéraires mais ne pas annoncer des itinéraires de retour à la sous-couche. Ceci est utile lors de l’introduction de la solution SD-WAN dans un réseau où l’infrastructure de routage est complexe ou incertaine.

Important

Il est facile de fuir la route indésirable, si vous n’êtes pas prudent.

La table de routage SD-WAN Virtual Path fonctionne comme un protocole EGP (External Gateway Protocol), similaire à BGP (pensez site à site). Par exemple, lorsque SD-WAN annonce des itinéraires de l’appliance SD-WAN vers OSPF, ils sont généralement considérés comme externes au site et au protocole.

Remarque

Soyez conscient des environnements qui ont des IGP sur l’ensemble de l’infrastructure (via le WAN) car cela complique l’utilisation des itinéraires annoncés par SD-WAN. L’EIGRP est largement utilisé sur le marché et le SD-WAN n’interagit pas avec ce protocole.

L’une des difficultés rencontrées lors de l’introduction des protocoles de routage à un déploiement SD-WAN est que la table de routage n’est pas disponible tant que le service SD-WAN n’est pas activé et ne fonctionne pas sur le réseau. Par conséquent, il n’est pas recommandé d’activer initialement la publicité des itinéraires à partir de l’appliance SD-WAN. Utilisez les filtres d’importation et d’exportation pour une introduction progressive des protocoles de routage sur SD-WAN.

Jetons un coup d’oeil de plus près en examinant l’exemple suivant :

Dans cet exemple, nous examinons un cas d’utilisation du protocole de routage. Le réseau précédent compte quatre emplacements : New York, Dallas, Londres et San Francisco. Nous déployons des appliances SD-WAN à trois de ces emplacements et utilisons SD-WAN pour créer un réseau WAN hybride où MPLS et Internet WAN Links seront utilisés pour fournir un WAN virtualisé. Étant donné que Dallas n’aura pas de périphérique SD-WAN, nous devons réfléchir à la meilleure façon d’intégrer les protocoles de route existants à ce site afin d’assurer une connectivité complète entre les réseaux de superposition et de sous-couche SD-WAN.

Dans l’exemple de réseau, eBGP est utilisé entre les quatre emplacements du réseau MPLS. Chaque emplacement possède son propre numéro de système autonome (ASN).

Dans le centre de données de New York, OSPF est en cours d’exécution pour annoncer les sous-réseaux de centre de données principaux sur les sites distants et également annoncer une route par défaut à partir du pare-feu de New York (E). Dans cet exemple, tout le trafic Internet est rétroacheminé vers le centre de données, même si les succursales de Londres et de San Francisco ont un chemin vers Internet.

Le site de San Francisco doit également être noté pour ne pas avoir de routeur. Le SD-WAN est déployé en mode Edge/Gateway, cette appliance étant la Gateway par défaut pour le sous-réseau de San Francisco et participant également à l’eBGP vers le MPLS.

• Avec le centre de données de New York, notez que le SD-WAN est déployé en mode Virtual Inline. L’intention est de participer au protocole de routage OSPF existant afin de transférer le trafic vers l’appliance en tant que Gateway préférée.
• Le site de Londres est déployé en mode traditionnel en ligne. Le routeur WAN (C) en amont sera toujours la Gateway par défaut pour le sous-réseau London.
• Le site de San Francisco est un site nouvellement introduit à ce réseau et le SD-WAN est prévu pour être déployé en mode Edge/Gateway et servir de Gateway par défaut pour le nouveau sous-réseau de San Francisco.

Passez en revue certaines tables de routage de sous-couche existantes avant de mettre en œuvre le SD-WAN.

Routeur Core de New York B :

Les sous-réseaux locaux de New York (172.x.x.x) sont disponibles sur le routeur B comme étant directement connecté, et à partir de la table de routage, nous identifions que la route par défaut est 172.10.10.3 (Pare-feu E). En outre, nous pouvons voir que les sous-réseaux Dallas (10.90.1.0/24) et Londres (10.100.1.0/24) sont disponibles via 172.10.10.1 (MPLS Router A). Les coûts de la route indiquent qu’ils ont été tirés de l’eBGP.

Remarque

Dans l’exemple fourni, San Francisco n’est pas répertorié comme itinéraire, car nous n’avons pas encore déployé le site avec SD-WAN en mode Edge/Gateway pour ce réseau.

Pour le routeur WAN de New York (A), les itinéraires et les itinéraires appris par OSPF à travers le MPLS via eBGP sont répertoriés. Notez les coûts de l’itinéraire. BGP est le domaine administratif inférieur et le coût par défaut 20/1 par rapport à OSPF 110/10.

Routeur D de Dallas :

Pour le routeur WAN (D) de Dallas, toutes les routes sont apprises à travers le MPLS.

Remarque

Dans cet exemple, vous pouvez ignorer le sous-réseau 192.168.65.0/24. Il s’agit d’un réseau de gestion qui n’est pas pertinent pour l’exemple. Tous les routeurs sont connectés au sous-réseau de gestion, mais ils ne sont annoncés dans aucun protocole de routage.

L’eBGP s’est associé l’un à l’autre emplacement. Chaque ASN est différent.

Il est important de comprendre comment les routes sont passées entre la table de routage Virtual Path et les protocoles de routage dynamiques utilisés. Il est facile de créer des boucles de routage ou d’annoncer des itinéraires d’une manière défavorable. Le mécanisme de filtre nous donne la possibilité de contrôler ce qui entre et sort de la table de routage. Nous considérons chaque emplacement à tour de rôle.

• L’emplacement de San Francisco comporte deux sous-réseaux locaux 10.80.1.0/24 et 10.81.1.0/24 . Nous voulons les faire connaître via eBGP afin que des sites comme Dallas puissent encore atteindre le site de San Francisco via le réseau de sous-couche et que des sites comme Londres et New York puissent encore atteindre San Francisco via le réseau de superposition Virtual Path. Nous voulons également apprendre de l’accessibilité d’eBGP à tous les sites dans le cas où la superposition du chemin virtuel SD-WAN tombe en panne et que l’environnement doit revenir à l’utilisation du MPLS uniquement. Nous ne voulons pas non plus republier tout ce que le SD-WAN apprend de eBGP aux routeurs SD-WAN. Pour ce faire, les filtres doivent être configurés comme suit :

• Importez toutes les routes depuis eBGP. Ne pas republier/exporter les routes vers des appliances SD-WAN.

• Exporter des itinéraires locaux vers eBGP

La règle par défaut pour l’exportation consiste à tout exporter. La règle 200 est utilisée pour remplacer la règle d’erreur pour ne pas republier les routes. Toute route correspondant à un préfixe SD-WAN a appris sur les chemins virtuels.

Une fois les appliances Citrix SD-WAN déployées, nous pouvons jeter un regard actualisé sur les tables de routage du routeur BGP sur le site de Dallas. Nous voyons les sous-réseaux 10.80.1.0/24 et 10.81.1.0/24 sont vus correctement via eBGP du SD-WAN de San Francisco.

Routeur D de Dallas :

En outre, la table de routage Citrix SD-WAN peut être affichée sur la page Surveillance > Statistiques > Afficher les itinéraires .

Citrix SD-WAN de San Francisco :

Citrix SD-WAN affiche toutes les routes apprises, y compris les routes disponibles via la superposition Virtual Path.

Considérons 172.10.10.0/24, qui est situé dans le centre de données de New York. Cette voie est apprise de deux façons :

• En tant que route de chemin virtuel (numéro 3), service = NYC-SFO avec un coût de 5 et tapez statique. Il s’agit d’un sous-réseau local annoncé par l’appliance SD-WAN à New York. Il est statique en ce sens qu’il est directement connecté à l’appliance ou qu’il s’agit d’une route statique manuelle entrée dans la configuration. Il est accessible car le chemin virtuel entre les sites est en état de travail/de mise en marche.

• Comme une route annoncée par BGP (numéro 6), avec un coût de 6. Ceci est maintenant considéré comme une route de secours.

Étant donné que le préfixe est égal et que le coût est différent, SD-WAN utilise la route Virtual Path, à moins qu’elle ne devienne indisponible, auquel cas la route de secours est apprise via BGP.

Maintenant, considérons la route 172.20.20.0/24.

• Ceci est appris comme une route de chemin virtuel (numéro 9) mais a un type de dynamique et un coût de 6. Cela signifie que l’appliance SD-WAN distante a appris cette route via un protocole de routage, dans ce cas OSPF. Par défaut, le coût de l’itinéraire est plus élevé.

• SD-WAN apprend également cette route via BGP avec le même coût, donc dans ce cas cette route peut être préférée à la route Virtual Path.

Pour garantir un routage correct, nous devons augmenter le coût de l’itinéraire BGP pour nous assurer que nous avons un itinéraire Virtual Path et qu’il s’agit de l’itinéraire préféré. Cela peut être fait en ajustant le poids de la route du filtre d’importation pour qu’il soit supérieur à la valeur par défaut de 6.

Après avoir effectué l’ajustement, nous pouvons actualiser la table de routage SD-WAN sur l’appliance San Francisco pour voir les coûts d’itinéraire ajustés. Utilisez l’option de filtre pour focaliser la liste affichée.

Enfin, regardons l’itinéraire par défaut appris sur le SD-WAN de San Francisco. Nous voulons rediriger tout le trafic Internet vers New York. Nous pouvons voir que nous l’envoyons en utilisant le chemin virtuel, s’il est en place, ou via le réseau MPLS comme un secours.

Nous voyons également une route de passage et de rejet avec le coût 16. Il s’agit de routes automatiques qui ne peuvent pas être supprimées. Si le périphérique est en ligne, la route passthrough est utilisée en dernier recours, donc si un paquet ne peut pas être mis en correspondance avec une route plus spécifique, SD-WAN le transmettra au saut suivant du groupe d’interface. Si le SD-WAN est hors chemin ou en mode bord/passerelle, il n’y a pas de service passthrough, auquel cas SD-WAN supprime le paquet en utilisant la route de rejet par défaut. Le nombre d’accès indique le nombre de paquets qui atteignent chaque route, ce qui peut être utile lors du dépannage.

Maintenant, nous nous concentrons sur le site de New York, nous voulons que le trafic destiné aux sites distants (Londres et San Francisco) soit dirigé vers l’appliance SD-WAN lorsque le chemin virtuel est actif.

Il existe plusieurs sous-réseaux disponibles sur le site de New York :

• 172.10.10.0/24 (directement connecté)

• 172.20.20.0/24 (annoncé via OSPF à partir du routeur principal B)

• 172.30.30.0/24 (annoncé via OSPF à partir du routeur principal B)

Nous sommes également tenus de fournir le flux de trafic vers Dallas (10.100.1.0/24) via MPLS.

Enfin, nous voulons tout le trafic lié à Internet vers le pare-feu E à travers 172.10.10.3 comme un prochain saut. SD-WAN apprend cette route par défaut via OSPF et à faire de la publicité sur le chemin virtuel. Les filtres pour le site de New York sont les suivants :

Le site SD-WAN de New York importe toutes les routes du réseau de gestion. Cela peut être ignoré. On peut se concentrer sur le filtre 200.

Le filtre 200 est utilisé pour importer 192.168.10.0/24 (notre noyau MPLS) pour l’accessibilité, mais pas pour l’exporter vers le chemin virtuel. Activez la case à cocher Inclure et vérifiez que la case à cocher Exporter la route vers Citrix Appliances est désactivée. Toutes les autres routes sont ensuite incluses.

Pour les filtres d’exportation, nous pouvons exclure la route pour 192.168.10.0/24. En effet, en tant que sous-réseau directement connecté sur le site de San Francisco, nous ne pouvons pas filtrer cette route à la source, donc elle est supprimée à cette fin.

Passons maintenant en revue la table des itinéraires actualisés à partir de la route principale sur le site de New York.

Routeur de New York B :

Nous pouvons voir les sous-réseaux de San Francisco (10.80.1.0 et 10.81.1.0) et de Londres (10.90.1.0) maintenant annoncés via l’appliance SD-WAN de New York (172.10.10.10). La route 10.100.1.0/24 est toujours annoncée par le biais du routeur MPLS A. Passons en revue la table de routage SD-WAN du site de New York.

Site de New York SD-WAN Tableau d’itinéraire :

Nous pouvons voir les routes correctes pour les sous-réseaux locaux appris via OSPF, une route vers le site de Dallas apprise par le routeur MPLS A et les sous-réseaux distants pour les sites de San Francisco et de Londres. Voyons le routeur MPLS A. Ce routeur participe à OSPF et BGP.

A partir de la table de routage, ce routeur A apprend les sous-réseaux distants via BGP et OSPF avec la distance administrative et le coût de la route BGP (20/5) étant inférieurs à OSPF (110/10) et donc préférés. Dans cet exemple, réseau où il n’y a qu’une seule route principale, cela peut ne pas causer de problème. Toutefois, le trafic arrivant ici serait livré via le réseau MPLS plutôt que d’être envoyé à l’appliance SD-WAN (172.10.10.10). Si nous voulons maintenir une symétrie de routage complète, nous aurions besoin d’une carte de route pour ajuster le coût AD/métrique afin qu’il y ait une préférence de route de la route provenant de 172.10.10.10 plutôt que de la route apprise via eBGP.

Alternativement, une route « backdoor » peut être configurée pour forcer le routeur à préférer la route OSPF à la route BGP. Notez la route statique de l’adresse IP virtuelle SD-WAN vers l’appliance SD-WAN du site de Londres.

Ceci est nécessaire pour vous assurer que le chemin virtuel est réacheminé vers l’appliance SD-WAN du site de New York si le chemin MPLS tombe en panne. Comme il y a un itinéraire pour le 10.90.1.0/24 annoncé via 172.10.10.10 (New York SD-WAN). Il est également recommandé de créer une règle de service de remplacement pour supprimer tous les paquets UDP 4 980 sur l’appliance SD-WAN afin d’empêcher le chemin virtuel de revenir à lui-même.

Chemins virtuels dynamiques

Les chemins virtuels dynamiques peuvent être autorisés entre deux nœuds clients pour créer des chemins virtuels à la demande pour une communication directe entre les deux sites. L’avantage d’un chemin virtuel dynamique est que le trafic peut circuler directement d’un nœud client au second sans avoir à traverser le MCN ou deux chemins virtuels, ce qui peut ajouter de la latence au flux de trafic. Les chemins virtuels dynamiques sont créés et supprimés dynamiquement en fonction des seuils de trafic définis par l’utilisateur. Ces seuils sont définis comme étant des paquets par seconde (pps) ou de la bande passante (kbps). Cette fonctionnalité active une topologie de superposition SD-WAN à maillage complet dynamique.

Une fois que les seuils pour les chemins virtuels dynamiques sont atteints, les nœuds clients créent dynamiquement leur chemin virtualisé les uns vers les autres en utilisant tous les chemins WAN disponibles entre les sites et en tirent pleinement parti de la manière suivante :

• Envoyez des données en vrac s’il y en a et vérifiez qu’aucune perte, puis

• Envoyez des données interactives et vérifiez aucune perte, puis

• Envoyer des données en temps réel une fois que les données Bulk et Interactive sont considérées comme stables (pas de perte ou de niveaux acceptables)

• S’il n’y a pas de données groupées ou interactives, envoyez des données en temps réel après que le chemin virtuel dynamique soit stable pendant une période

• Si les données utilisateur sont inférieures aux seuils configurés pour une période définie par l’utilisateur, le chemin virtuel dynamique est déchiré

Les chemins virtuels dynamiques ont le concept d’un site intermédiaire. Le site intermédiaire peut être un site MCN ou tout autre site du réseau sur lequel le chemin virtuel statique est configuré et connecté à deux ou plusieurs autres nœuds clients. Une autre exigence de conception est d’activer le transfert WAN vers WAN, ce qui permet de publier toutes les routes de tous les sites vers les nœuds clients où le chemin virtuel dynamique est souhaité.

Plusieurs groupes de transfert WAN vers WAN sont autorisés dans le SD-WAN, ce qui permet un contrôle total de l’établissement du chemin entre certains nœuds clients et pas d’autres.

Chaque périphérique SD-WAN possède sa propre table de routage unique avec les détails suivants définis pour chaque itinéraire :

• Num — ordre de route de cette appliance basé sur le processus de correspondance (Num le plus bas traité en premier)

• Adresse réseau — adresse de sous-réseau ou d’hôte

• Passerelle si nécessaire

• Service — quel service est appliqué pour cette route

• Zone de pare-feu — classification de la zone de pare-feu de l’itinéraire

• Reachable — Identifie si l’état du chemin virtuel est actif pour ce site

• Site — Nom du site sur lequel l’itinéraire doit exister

• Type — Identification du type d’itinéraire (statique ou dynamique)

• Voisin Direct

• Coût - coût de l’itinéraire spécifique

• Nombre de coups — combien de fois la route a été utilisée par paquet. Cela serait utilisé pour vérifier qu’une route est touchée correctement.

• Admissibles

• Type d’admissibilité

• Valeur d’admissibilité

Voici un exemple de table de routage de site SD-WAN :

Notez dans la table de routage SD-WAN précédente qu’il y a plus d’éléments qui ne sont pas normalement disponibles dans les routeurs traditionnels. La plus remarquable est la colonne « Reachable », qui rend l’itinéraire actif ou inactif (oui/non) en fonction de l’état du chemin WAN. Les routes répertoriées ici sont supprimées en fonction des différents états du service (le chemin virtuel étant désactivé à titre d’exemple). Les autres événements qui peuvent forcer une route à être inéligible sont l’état du chemin vers le bas, le saut suivant inaccessible ou le lien WAN vers le bas.

Dans le tableau précédent, nous pouvons voir 14 itinéraires définis. Une description des itinéraires ou des groupes de routes est décrite comme suit :

• Route 0 — Sur le MCN, il s’agit d’une route de sous-réseau hôte qui réside sur le site DC. 172.16.10.0/24 réside dans le LAN DC et 192.168.15.1 est la Gateway sur le LAN qui est le prochain saut qui arrivera à ce sous-réseau.

• Route 1 : il s’agit d’une route locale vers ce périphérique SD-WAN qui affiche la table de routage.

• Route 2—4 : il s’agit des sous-réseaux qui font partie des interfaces virtuelles configurées pour le SD-WAN du site DC. Ces sous-réseaux sont dérivés des interfaces virtuelles approuvées définies.

• Route 5 — Il s’agit d’une route partagée vers un autre nœud client qui est partagée par le MCN avec un état d’accessibilité de Non en raison du chemin virtuel vers le bas entre ce site et le MCN.

• Route 6—9 — Ces routes existent sur un autre site client. Pour cette route, une route de chemin virtuel est créée pour correspondre au trafic d’entrée WAN destiné au site distant sur le chemin virtuel.

• Route 10 — Avec le service Internet défini, le système ajoute un catch all route pour le breakout internet direct pour ce site local.

• Route 11 — Passthrough est la route par défaut que le système ajoute toujours pour permettre aux paquets de circuler dans le cas où il n’y aurait pas de correspondance sur les routes existantes. Le Passthrough n’est pas soigné, généralement les émissions locales et le trafic ARP sont mappés à ce service.

• Route 12 — La défausse est la route par défaut que le système ajoute toujours pour supprimer tout ce qui n’est pas défini.

Valeurs de coût d’acheminement par défaut :

• Transfert WAN vers WAN — 10

• Coût d’acheminement direct par défaut — 5

• Routes générées automatiquement — 5

• Chemin virtuel — 5

• Local — 5

• Intranet — 5

• Internet — 5

• Passthrough — 5

• Facultatif : la route est 0.0.0.0/0 définie en tant que niveau de service

Après avoir défini ces itinéraires, il est important de comprendre comment le trafic circule en utilisant les itinéraires définis. Ces flux de trafic sont divisés en flux suivants :

• LAN vers WAN (chemin virtuel) — Trafic entrant dans le tunnel de superposition SD-WAN

• WAN to LAN (chemin virtuel) — Trafic existant dans le tunnel de superposition SD-WAN

• Trafic de chemin non virtuel — Trafic acheminé vers le réseau de sous-couche

Itinéraires Intranet et Internet

Pour les types de services Intranet et Internet, l’utilisateur doit avoir défini une liaison WAN SD-WAN pour prendre en charge ces types de services. Il s’agit d’une condition préalable à toute route définie pour l’un ou l’autre de ces services. Si la liaison WAN n’est pas définie pour prendre en charge le service Intranet, elle est considérée comme une route locale. Les itinéraires Intranet, Internet et Passthrough ne concernent que le site/appliance pour lequel ils sont configurés.

Lors de la définition d’itinéraires intranet, Internet ou relais, les éléments suivants sont pris en compte lors de la conception :

• Le service doit être défini sur le lien WAN (Intranet/Internet — requis)

• Intranet/Internet doit avoir une Gateway définie pour la liaison WAN

• pertinent pour le périphérique SD-WAN local

• Les routes intranet peuvent être apprises via le chemin virtuel, mais le sont à un coût plus élevé

• Avec Internet Service, il y a automatiquement une route par défaut créée (0.0.0.0/0) pour attraper tous les itinéraires avec un coût maximum

• Ne supposez pas que Passthrough fonctionne, il doit être testé/vérifié, également tester avec Virtual Path down/désactivé pour vérifier le comportement souhaité

• Les tables de routage sont statiques, sauf si la fonction d’apprentissage de route est activée

  La limite maximale prise en charge pour plusieurs paramètres de routage est la suivante :

• Domaines de routage maximum : 255

• Interfaces d’accès maximum par liaison WAN : 64

• Nombre maximum de voisins BGP par site : 255

• Superficie maximale OSPF par site : 255

• Nombre maximal d’interfaces virtuelles par zone OSPF : 255

• Filtres d’importation maximum d’apprentissage d’itinéraire par site : 512

• Filtres d’exportation maximum d’apprentissage par route par site : 512

• Stratégies de routage BGP maximales : 255

• Nombre maximal d’objets de chaîne de communauté BGP : 255