Routage de superposition SD-WAN

Citrix SD-WAN offre une connectivité robuste et résiliente 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 dans le réseau, ce qui permet 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

La configuration SD-WAN permet des entrées d’itinéraire statiques pour des sites spécifiques et des entrées d’itinéraire apprises par le réseau de sous-couche 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. Voici les principaux types de services utilisés :

• Service local : désigne tout itinéraire ou sous-réseau local vers l’appliance SD-WAN. Cela inclut les sous-réseaux d’interface virtuelle (crée automatiquement des routes locales) et toute route locale définie dans la table de routage (avec un saut suivant local). La route est annoncée à d’autres appliances SD-WAN qui disposent d’un chemin d’accès virtuel vers ce site local sur lequel cette route est configurée lorsqu’elle est approuvée en tant que partenaire.

Remarque

Soyez prudent lors de l’ajout d’itinéraires par défaut et récapitulez les itinéraires en tant que routes locales, 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  : indique tout itinéraire local appris à partir d’un site SD-WAN distant. C’est ce qui est accessible dans 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 à cet itinéraire (sous-réseau) est classé comme intranet pour cette appliance en vue d’être livré à un site qui ne possède pas de 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 — Ceci est similaire à l’intranet, mais est utilisé pour définir le trafic qui circule vers des liaisons WAN Internet publiques plutôt que des liaisons WAN privées. 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. Un itinéraire Internet par défaut est créé lorsque le service Internet est activé (il est désactivé par défaut). Tout trafic correspondant à cet itinéraire (sous-réseau) est classé comme Internet pour cette appliance en vue de la livraison aux ressources Internet publiques.

Remarque

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

• Passthrough : ce service agit comme un service de dernier recours ou de remplacement lorsqu’une appliance est en mode ligne. Si une adresse IP de destination ne correspond pas à un autre itinéraire, l’appliance SD-WAN la transfère simplement sur le saut suivant de liaison WAN. Un itinéraire par défaut : 0.0.0.0/0 coût de 16 itinéraire pass-through est créé automatiquement. Le passage ne fonctionne pas lorsque l’appliance SD-WAN est déployée hors chemin ou en mode Edge/Passerelle. 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).

  L’éditeur de configuration SD-WAN permet la personnalisation de la table de routage pour chaque site disponible :

Les entrées de la table de routage sont renseignées à partir de différentes entrées :

• Adresse IP virtuelle configurée (VIP) automatiquement renseignée en tant que route locale de type de service. L’Éditeur de configuration empêche la même affectation VIP à différents nœuds de site.

• Les services Internet activés sur un site local renseignent automatiquement une route par défaut (0.0.0.0/0) localement pour une sortie Internet directe.

• Les itinéraires statiques définis par l’administrateur sur une base par site, qui seront également définis comme un itinéraire local de type de service.

• Une valeur par défaut (0.0.0.0/0) capture tous les itinéraires avec le coût 16 défini comme Passthrough

Les administrateurs peuvent configurer l’une des routes précédentes, mais aussi inclure un type de service, un saut suivant ou une Gateway en fonction du type de service, en plus du coût de l’itinéraire. Un coût d’itinéraire par défaut sera automatiquement ajouté à chaque type d’itinéraire (reportez-vous au tableau suivant pour connaître les coûts d’itinéraire par défaut). En outre, seules les routes de confiance sont annoncées sur d’autres appliances SD-WAN. Les itinéraires non approuvés sont uniquement utilisés par l’appliance locale.

Les routes de noeud client sont uniquement annoncées sur le noeud MCN et aucun autre noeud client par défaut. Pour que les routes de noeud client soient visibles par un autre noeud client Le transfert WAN vers WAN doit être activé au niveau du noeud MCN.

Lorsque le transfert WAN vers WAN (modèle d’exportation d’itinéraires) est activé sous Paramètres globaux, le site MCN partage les itinéraires annoncés à tous les clients participant à la superposition SD-WAN. L’activation de cette fonctionnalité permet la connectivité IP entre les hôtes de différents sites de nœuds clients, la communication passant par le MCN. 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 est effectué dans l’ordre suivant :

1. Les 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 /32 itinéraires, un itinéraire de coût 4 précède toujours un itinéraire de coût 5. Pour deux itinéraires /32 coûtent 5, les itinéraires sont choisis 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 :

• 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 du 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 du trafic WAN vers LAN (chemin virtuel) :

  1. Le trafic de chemin virtuel est reçu par SD-WAN 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 réseau WAN et correspond à la destination IP à la table de routage ou au chemin virtuel.

     • Si non, vérifiez le transfert WAN vers WAN activé.

  3. (Retransmission WAN vers WAN désactivée) 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 a introduit les protocoles de routage OSPF et BGP dans la configuration. L’introduction de protocoles de routage au SD-WAN a permis d’intégrer plus facilement le 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 SD-WAN, 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 une communication directe avec les routeurs périphériques clients existants utilisant le 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é. Puisque 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 sous-couche et de superposition 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 virtuel Inline. L’objectif est de participer au protocole de routage OSPF existant pour acheminer le trafic vers l’appliance en tant que Gateway privilégiée.
• Le site londonien est déployé en mode traditionnel en ligne. Le routeur WAN en amont (C) sera toujours la Gateway par défaut pour le sous-réseau London.
• Le site San Francisco est un site nouvellement introduit sur ce réseau et le SD-WAN est prévu pour être déployé en mode Edge/Gateway et agir comme Gateway par défaut pour le nouveau sous-réseau San Francisco.

Examinez 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 London (10.100.1.0/24) sont disponibles via 172.10.10.1 (MPLS Router A). Les coûts de l’itinéraire 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 un 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.

Dans Citrix SD-WAN, nous pouvons ajouter la superposition SD-WAN en activant OSPF sur le SD-WAN situé dans le site de New York sous Connexions > Afficher le site > OSPF > Paramètres de base :

Remarque

Par défaut, le type d’ itinéraire d’exportation OSPF est Type 5 Externe. Cela est dû au fait que la table de routage SD-WAN est considérée comme externe au protocole OSPF et donc OSPF préférera une route apprise interne (intra-zone), donc les routes annoncées par SD-WAN peuvent ne pas avoir priorité.

Lorsque OSPF est utilisé sur le WAN (c’est-à-dire les réseaux MPLS), cela peut être modifié en Type un intra-zone. Les zones OSPF peuvent être configurées comme suit.

Zone 0 ajoutée avec le réseau local dérivé de l’interface virtuelle (172.10.10.0), tous les autres paramètres ont été laissés par défaut.

Pour le nouveau site de San Francisco, nous devons activer eBGP car il sera directement connecté au réseau MPLS et fonctionnera en tant que route périphérique client pour le site. BGP peut être activé sous Connexions > Afficher le site > BGP > Paramètres de base.

Notez le numéro 13 du système autonome.

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 d’itinéraires dynamiques utilisés. Il est facile de créer des boucles de routage ou de faire de la publicité 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 est d’exporter tout. La règle 200 est utilisée pour remplacer la règle d’erreur pour ne pas lire les itinéraires. 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 que les sous-réseaux 10.80.1.0/24 et 10.81.1.0/24 sont correctement vus via eBGP à partir du SD-WAN de San Francisco.

Routeur Dallas D :

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

San Francisco Citrix SD-WAN :

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 que c’est 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 d’itinéraires automatiques qui ne peuvent pas être supprimés. 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 associé à 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 de transmission, auquel cas SD-WAN supprime le paquet en utilisant la route de rejet par défaut. Le nombre de coups indique le nombre de paquets qui touchent chaque route, ce qui peut être utile lors du dépannage.

Maintenant, en nous concentrant 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.

Plusieurs sous-réseaux sont 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 central B)

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

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

Enfin, nous voulons que tout le trafic lié à Internet route vers le pare-feu E à 172.10.10.3 comme un saut suivant. 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 de la sous-couche MPLS Router A. Voyons la table de route 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 routage pour ajuster le coût AD/métrique afin qu’il y ait une préférence de routage provenant de l’itinéraire 172.10.10.10 plutôt que l’itinéraire appris via eBGP.

Alternativement, une route « backdoor » peut être configurée pour forcer le routeur à préférer la route OSPF sur 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 une route pour le 10.90.1.0/24 annoncée 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 sur 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 pourrait 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 en tant que paquets par seconde (pps) ou bande passante (kbps). Cette fonctionnalité permet une topologie dynamique de superposition SD-WAN à maillage complet.

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

• Envoyer des données groupées le cas échéant et vérifier qu’aucune perte n’est perdue, puis

• Envoyez des données Interactives et vérifiez qu’aucune perte n’est perdue, puis

• Envoyer des données en temps réel après que les données groupées et interactives soient considérées comme stables (aucune perte ou 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é à au moins deux 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é. Activer le site en tant que nœud intermédiaire doit être activé en plus du transfert WAN vers WAN pour ce site intermédiaire afin de surveiller la communication du nœud client et de dicter quand le chemin dynamique doit être établi et arraché.

Plusieurs groupes de redirection WAN à WAN peuvent être autorisés dans la configuration SD-WAN, ce qui permet un contrôle total de l’établissement du chemin entre certains nœuds clients et non pas d’autres.

Pour que les nœuds clients fonctionnent en tant que sites intermédiaires, un chemin virtuel statique doit être configuré entre celui-ci et les clients associés à ce groupe de transfert WANà WAN. En outre, les nœuds clients doivent activer l’option Activer le chemin virtuel dynamique activé pour chaque nœud client.

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 d’acheminement de cette appliance basé sur le processus de correspondance (le nombre le plus bas est 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 cet itinéraire

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

• Reachable — Identifie si l’état Virtual Path est actif pour ce site

• Site — Nom du site sur lequel l’itinéraire devrait 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 l’itinéraire a été utilisé par paquet. Cela serait utilisé pour vérifier qu’une route est atteinte correctement.

• Éligible

• 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 de différents états du service (le chemin virtuel étant en panne à 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’un itinéraire local 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’un itinéraire partagé vers un autre nœud client partagé par le MCN avec le statut d’accessibilité Non en raison du chemin virtuel en panne entre ce site et le MCN.

• Route 6—9 — Ces routes existent sur un autre site client. Pour cet itinéraire, un itinéraire Virtual Path est créé pour le trafic d’entrée WAN correspondant 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’itinéraire par défaut :

• Transfert WAN vers WAN — 10

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

• Itinéraires générés automatiquement — 5

• Chemin virtuel — 5

• Local — 5

• Intranet — 5

• Internet — 5

• Passthrough — 5

• Facultatif — l’itinéraire est 0.0.0.0/0 défini comme un 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 répartis entre les flux suivants :

• LAN to WAN (Virtual Path) — Trafic entrant dans le tunnel de superposition SD-WAN

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

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

Le coût d’itinéraire par défaut peut être modifié par site. La configuration se trouve sous Afficher le site > Paramètres de base :

Les itinéraires statiques peuvent être définis par site sous le nœud Connexions > Site > Route s :

Vous remarquez que les routes peuvent être liées au chemin virtuel ou à la disponibilité IP de la passerelle. Les routes Internet peuvent être exportées vers la superposition Virtual Path ou non selon le comportement souhaité. Vous pouvez également créer des routes statiques Virtual Path pour forcer le trafic à un Path Virtuel même si nous n’obtenons pas le préfixe annoncé sur SD-WAN (c’est-à-dire une route coûteuse de dernier recours). Le SD-WAN peut également supprimer la publicité des sous-réseaux locaux en rendant l’adresse IP virtuelle (VIP) privée.

Remarque

La configuration nécessite au moins un VIP non privé dans chaque domaine d’itinéraire.

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 liaison 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 Passthrough, les considérations de conception suivantes sont les suivantes :

• 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

  Voici la limite maximale prise en charge pour plusieurs paramètres de routage :

• 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

• Interfaces virtuelles maximales par zone OSPF : 255

• Filtres d’importation maximum par site : 512

• Filtres d’exportation maximum par site : 512

• Stratégies de routage BGP maximales : 255

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