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 entièrement remplacer ou coexister avec l’infrastructure de routage existante. L’article ci-dessous 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 la bonne gamme est en vigueur.

  • Chemin virtuel : désigne toute route locale apprise à partir d’un site SD-WAN distant ; c’est ce qui est accessible en bas des chemins virtuels. Ces itinéraires sont normalement automatiques, mais un itinéraire virtuel peut être ajouté manuellement sur un site. Tout trafic pour cet itinéraire est transféré vers le chemin virtuel défini pour cet itinéraire de destination (sous-réseau).

  • Intranet : désigne 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 transférées à 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é de limiter autant que possible le trafic de transit.

Remarque

Le passage peut être utile lors de l’exécution d’un POC afin d’éviter d’avoir à configurer de nombreux routage. Cependant, soyez très prudent en production car le SD-WAN ne tient pas compte de l’utilisation des liaisons WAN pour le trafic envoyé à passthrough. Il est également utile lors du dépannage de problèmes et vous souhaitez retirer un certain flux IP de la livraison via 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 attendre lorsque l’appliance SD-WAN est déployée hors chemin. Vous devez avoir un service Intranet ou une route locale comme un itinéraire catch all, 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 :

image localisée

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

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

  • Les services Internet activés sur un site local remplissent automatiquement une route par défaut (0.0.0.0/0) localement pour l’évasion 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) attrape tous les itinéraires dont le coût 16 est défini comme Passthrough

Les administrateurs peuvent configurer l’un des itinéraires ci-dessus, mais également inclure un type de service, un saut suivant ou une Gateway en fonction du type de service, en plus du coût d’itinéraire. Un coût d’itinéraire par défaut sera automatiquement ajouté à chaque type d’itinéraire (consultez le tableau ci-dessous pour 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 ne sont utilisés que par l’appliance locale.

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

image localisée

Lorsque le transfert WAN à 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 avec la communication circulant via le MCN. La table de routage du noeud client local peut être surveillée sur la page Surveillance > Statistiques avec l’option Itinéraires sélectionnée pour la liste déroulante Afficher .

image localisée

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ù la destination réside en tant que sous-réseau local.

Dans l’exemple ci-dessous, avec le transfert WAN-to-WAN (Export de routes) activé, la branche A a une entrée de table de routage pour le sous-réseau Branch B (10.2.2.0/24) via le MCN comme saut suivant.

image localisée

Correspondance du trafic Citrix SD-WAN sur des itinéraires définis

Le processus de correspondance pour les routes définies 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é. L’ordre de service est le suivant : Local, Chemin virtuel, Intranet, Internet, Passthrough, Rejeter.

À titre d’exemple, considérez les deux itinéraires suivants ci-dessous :

  • 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 sur la superposition de chemin virtuel avec d’autres trafic entrant dans toutes les routes, comme une route par défaut vers le service de passage.

Les itinéraires peuvent être configurés dans une table de routage de nœud de site qui a le même préfixe. Le tie-break va ensuite au coût de l’itinéraire, au type de service (Virtual Path, Intranet, Internet, etc.) et à l’IP du 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. Le Citrix SD-WAN participant à des protocoles de routage fonctionnant dans le réseau de sous-couche peut être effectué quel que soit le mode de déploiement du SD-WAN (mode Inline, Virtual Inline ou Edge/Gateway). En outre, le SD-WAN peut être déployé en mode « apprentissage uniquement », 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 très facile de fuir route indésirable, si vous n’êtes pas prudent.

La table de routage du chemin virtuel SD-WAN fonctionne comme un protocole EGP (External Gateway Protocol), très similaire à BGP (pensez site à site). Par exemple, lorsque le SD-WAN annonce des itinéraires depuis 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 dans l’ensemble de l’infrastructure (sur le réseau étendu) car cela complique l’utilisation des routes annoncées SD-WAN. EIGRP est largement utilisé sur le marché et le SD-WAN n’interopère pas avec ce protocole.

L’un des problèmes liés à 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 fonctionne dans le réseau. Par conséquent, il n’est pas recommandé d’activer initialement les routes publicitaires à 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.

Regardons de plus près en examinant l’exemple suivant :

image localisée

Dans cet exemple, nous examinons un cas d’utilisation du protocole de routage. Le réseau susmentionné compte quatre emplacements : New York, Dallas, Londres et San Francisco. Nous déployons des appliances SD-WAN à trois de ces emplacements, et utilisons le SD-WAN pour créer un réseau WAN hybride où les liaisons MPLS et Internet WAN seront utilisées 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 annoncer également un itinéraire par défaut à partir du pare-feu de New York (E). Dans cet exemple, tout le trafic Internet est relié au 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é de ne pas avoir de routeur. Le SD-WAN est déployé en mode Edge/Gateway, cette appliance étant la Gateway par défaut du sous-réseau San Francisco et participant également à 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 :

image localisée

Les sous-réseaux locaux de New York (172.x.x.x) sont disponibles sur le routeur B comme directement connecté, et à partir de la table de routage, nous identifions que la route par défaut est 172.10.10.3 (Firewall 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é en tant que route, car nous n’avons pas encore déployé le site avec SD-WAN en mode Edge/Gateway pour ce réseau.

image localisée

Pour le routeur WAN de New York (A), les routes apprises OSPF et les routes apprises à travers le MPLS via eBGP sont répertoriées. 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 Dallas D :

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

image localisée

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 le n’est annoncé 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 :

image localisée

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 un itinéraire appris interne (intra-zone), donc les routes annoncées par SD-WAN peuvent ne pas avoir priorité.

Lorsque OSPF est utilisé sur le réseau 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 indiqué ci-dessous.

image localisée

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 du système autonome de 13.

image localisée

image localisée

L’eBGP est homologuée l’un avec 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 annoncer via eBGP afin que des sites comme Dallas puissent encore atteindre le site de San Francisco via le réseau de sous-couche et aussi des sites comme Londres et San Francisco puissent toujours atteindre San Francisco via le réseau de superposition Virtual Path. Nous voulons également apprendre de la facilité d’accès d’eBGP à tous les sites au cas où la superposition du chemin virtuel SD-WAN disparaissait et que l’environnement devrait revenir à l’utilisation du MPLS. Nous ne voulons pas non plus lire tout ce que SD-WAN apprend d’eBGP aux routeurs SD-WAN. Pour ce faire, les filtres doivent être configurés comme suit :

  • Importer toutes les routes depuis eBGP. Ne pas lire et exporter des routes vers des appliances SD-WAN.

image localisée

  • 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. Tout itinéraire correspondant à un préfixe SD-WAN a appris à travers les chemins virtuels.

image localisée

Après le déploiement des appliances Citrix SD-WAN, nous pouvons examiner de nouveau 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 :

image localisée

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 :

image localisée

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 s’apprend de deux façons :

  • En tant que route Virtual Path (Nr 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 fonctionnement/de mise à niveau.

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

Comme le préfixe est égal et que le coût est différent, SD-WAN utilise l’itinéraire Virtual Path à moins qu’il 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 Virtual Path (Num 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 l’itinéraire du filtre d’importation pour qu’il soit supérieur à la valeur par défaut de 6.

image localisée

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 de routage ajustés. Utilisez l’option de filtre pour centrer la liste affichée.

image localisé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 solution de secours.

image localisée

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 :

image localisée

Le site SD-WAN de New York importe toutes les routes pour le réseau de gestion. Cela peut être ignoré. Nous pouvons nous concentrer sur le filtre 200.

image localisée

Filtre 200 est utilisé pour importer 192.168.10.0/24 (notre noyau MPLS) pour l’accessibilité, mais il n’est pas annoncé dans la superposition Virtual Path. Tous les autres itinéraires sont ensuite inclus.

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

image localisée

Passons maintenant en revue la table de routage actualisée à partir de la route principale dans le site de New York.

Routeur de New York B :

image localisée

Nous pouvons voir les sous-réseaux de San Francisco (10.80.1.0 & 10.81.1.0) et de Londres (10.90.1.0) actuellement annoncés via le New York SD-WAN Appliance (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 :

image localisée

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

image localisée

À 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érieur à OSPF (110/10) et donc préféré. Dans cet exemple, le réseau où il n’y a qu’un seul itinéraire central, cela peut ne pas causer de problème. Toutefois, le trafic arrivant ici serait acheminé via le réseau MPLS plutôt que vers 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 l’itinéraire statique de l’adresse IP virtuelle SD-WAN vers l’appliance SD-WAN du site de Londres.

image localisée

Ceci est nécessaire pour s’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 deux sites. L’avantage d’un chemin virtuel dynamique est que le trafic peut circuler directement d’un nœud client à un autre sans avoir à parcourir 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 en vrac ou interactives, envoyez des données en temps réel après que le chemin virtuel dynamique a été 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ée

    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-to-WAN, ce qui permet à toutes les routes de tous les sites d’être annoncées 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-to-WAN pour que ce site intermédiaire puisse surveiller la communication du nœud client et dicter quand le chemin dynamique doit être établi et déchirée.

image localisée

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

image localisée

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.

image localisée

Chaque périphérique SD-WAN a 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’éligibilité

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

image localisée

Notez dans la table de routage SD-WAN ci-dessus qu’il y a plus d’éléments qui ne sont normalement pas disponibles dans les routeurs traditionnels. Le plus notable est la colonne « Reachable », qui rend la route active ou inactive (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 à ne pas être éligible sont l’état chemin vers le bas, le saut suivant inaccessible ou la liaison WAN vers le bas.

Dans le tableau ci-dessus, nous pouvons voir 14 itinéraires définis. Une description des itinéraires ou groupes d’itinéraires est décrite ci-dessous :

  • 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 va accéder à 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 l’évasion Internet directe pour ce site local.

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

  • Route 12 — Rejeter 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 :

image localisée

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

image localisée

Vous remarquez que les itinéraires peuvent être liés à la disponibilité du chemin virtuel ou de la passerelle IP. 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). SD-WAN peut également empêcher les sous-réseaux locaux d’être annoncés en rendant l’adresse IP virtuelle (VIP) privée.

image localisé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) attraper tous les itinéraires avec un coût maximum

  • Ne supposez pas que Passthrough fonctionne, il doit être teste/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 fonctionnalité d’apprentissage de routage 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