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 réaliser cette connectivité en établissant des tunnels entre les appliances SD-WAN du réseau. L’établissement de tunnels permet la connectivité entre les sites en appliquant des tables de routage qui recouvrent le réseau sous-jacent 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 de manière unidirectionnelle en termes de disponibilité, de perte, de latence, de gigue et de congestion. Les appliances sélectionnent ensuite le meilleur chemin par paquet. Cela signifie que le chemin choisi du site A au site B ne doit pas nécessairement être le chemin choisi du site B au site A. Le meilleur chemin à un moment donné est sélectionné 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 de routage statiques pour des sites spécifiques et des entrées de routage tirées du réseau de sous-couche via des protocoles de routage pris en charge, tels que OSPF, eBGP et iBGP. Les itinéraires sont définis par leur prochain saut et par leur type de service. Il détermine la manière dont l’itinéraire est transféré. 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. Il inclut les sous-réseaux de l’interface virtuelle (crée automatiquement des routes locales) et toute route locale définie dans la table de routage (avec un saut local suivant). 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 cela peut donner lieu à des itinéraires de chemin 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 trafic intranet.

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 — Semblable à l’intranet mais 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.

• Intercommunication  : agit en tant que service de dernier recours ou de remplacement lorsqu’un appareil est en mode 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

Le relais peut être utile lors de la réalisation d’un POC pour éviter d’avoir à configurer de nombreux routages. Soyez prudent en production, car le SD-WAN ne prend pas en compte l’utilisation de la liaison WAN pour le trafic envoyé au relais. 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.

• Supprimer : il ne s’agit pas d’un service mais d’un itinéraire de dernier recours qui supprime les paquets s’ils correspondent. Normalement, cela ne se produit pas normalement lorsque l’appliance SD-WAN est déployée hors du chemin. Vous devez disposer d’un service Intranet ou d’un itinéraire local comme itinéraire incontournable. Dans le cas contraire, le trafic est supprimé car il n’y a pas de service relais (même si une route par défaut est présente).

  < ! —L’éditeur de configuration SD-WAN permet de personnaliser 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.

• Routes statiques définies par l’administrateur sur une base par site, qui sont définies 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’un des itinéraires précédents. Outre le coût de l’itinéraire, incluez un type de service, un saut suivant ou une passerelle en fonction du type de service. Un coût d’itinéraire par défaut est automatiquement ajouté à chaque type d’itinéraire (consultez le tableau suivant 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 sont uniquement utilisés par l’appliance locale.

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. Cette fonctionnalité permet la connectivité IP entre les hôtes situés sur 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 lapageSurveillance>Statistiques avec les itinéraires sélectionnés dans la listedéroulanteAfficher. —>

Chaque route pour les sous-réseaux des succursales distantes est annoncée en tant que service via le chemin virtuel se connectant via le MCN. La colonne Site est renseignée avec le nœud client où se trouve la destination en tant que sous-réseau local.

Dans l’exemple suivant, le transfert WAN vers WAN (exportation de routes) est activé. La branche A possède une entrée de table de routage pour le sous-réseau de la 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é. Il est courant que la configuration soit en place pour les itinéraires destinés à être fournis via la superposition de chemins virtuels, les autres trafics tombant dans des itinéraires « catch all », tels qu’un itinéraire par défaut vers le service de transit.

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. L’interface LAN reçoit et traite le trafic entrant.

  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, le moteur de règles traite la trame et crée un flux dans la base de données de flux.

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

  1. Le SD-WAN reçoit le trafic Virtual Path du tunnel et le traite.

  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, le moteur de règles traite la trame et crée un flux 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 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 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 et fonctionnant sur le réseau sous-jacent peut être effectué quel que soit le mode de déploiement du SD-WAN (mode Inline, 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. C’est utile lorsque vous introduisez la solution SD-WAN dans un réseau dont 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 dotés d’IGP sur l’ensemble de l’infrastructure (sur le WAN). Cela complique la façon dont les routes annoncées par le SD-WAN sont utilisées. L’EIGRP est largement utilisé sur le marché et le SD-WAN n’interagit pas avec ce protocole.

Lors de l’introduction de protocoles de routage dans un déploiement SD-WAN, 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 les itinéraires publicitaires à partir de l’appliance SD-WAN dans un premier temps. 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 sur trois de ces sites. Nous utilisons également le SD-WAN pour créer un réseau WAN hybride dans lequel les liaisons MPLS et Internet WAN sont utilisées pour fournir un WAN virtualisé. Dallas ne disposant pas d’un périphérique SD-WAN, nous devons réfléchir à la meilleure façon d’intégrer les protocoles de routage existants vers ce site. Il garantit une connectivité complète entre les réseaux sous-jacents et les réseaux superposés 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. L’appliance est la passerelle par défaut pour le sous-réseau de San Francisco et participe également à 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 en amont (C) reste la passerelle par défaut pour le sous-réseau de Londres.
• Le site de San Francisco est un site récemment introduit dans ce réseau. L’idée est de déployer le SD-WAN en mode Edge/Gateway et de faire en sorte que l’appliance fasse office de passerelle 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 en tant que connexion directe. À partir de la table de routage, nous identifions que la route par défaut est 172.10.10.3 (Firewall E). Nous pouvons également 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 (routeur MPLS A). Les coûts de la route indiquent qu’ils ont été tirés de l’eBGP.

Remarque

Dans l’exemple fourni, San Francisco ne figure pas dans la liste des itinéraires. C’est parce que nous n’avons pas encore déployé le site avec le 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.

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 Dallas D :

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

Prenons l’exemple du 172.10.10.0/24, qui se trouve 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.

Le préfixe est égal et le coût est différent. Le 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é.

• Le SD-WAN apprend également cette route via BGP au même coût. Cette route peut donc être préférée à la route Virtual Path.

Nous voyons également une route de passage et de rejet avec le coût 16. Ces itinéraires sont automatiques et ne peuvent pas être supprimés. Si l’appareil est en ligne, l’itinéraire de transit est utilisé en dernier recours. Ainsi, si un paquet ne peut pas être associé à une route plus spécifique, le SD-WAN le transmet au saut suivant du groupe d’interfaces. 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.

Pour le site de New York, nous voulons que le trafic destiné à des 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.

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. Le site doit disposer d’un chemin virtuel statique configuré et connecté à au moins deux autres nœuds clients. Une autre exigence de conception est d’activer le transfert WAN vers WAN. Cela permettrait d’annoncer tous les itinéraires de tous les sites aux nœuds clients où le chemin virtuel dynamique est souhaité. < ! — L’optionActiver le site en tant que nœud intermédiaire doit être activée en plus du transfert WAN vers WAN pour ce site intermédiaire afin de surveiller la communication entre les nœuds clients et de déterminer quand le chemin dynamique doit être établi et démonté. —>

Plusieurs groupes de transfert WAN vers WAN peuvent être autorisés dans la configuration SD-WAN. Il permet un contrôle total de l’établissement des chemins 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 routage de l’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 : service appliqué pour l’itinéraire

• Zone de pare-feu : classification de la route par zone de pare-feu

• Accessible — Identifie si l’état du chemin virtuel est actif pour le 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 connexions : nombre de fois que l’itinéraire a été utilisé par paquet. Ces informations seraient utilisées pour vérifier qu’une route est correctement empruntée.

• Admissibles

• Type d’admissibilité

• Valeur d’admissibilité

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