Mise en place du BGP Multi-AS sur Extreme VOSS/Fabric Engine

Section 1: Introduction au BGP sur Extreme VOSS/Fabric Engine

1.1 Rôle du BGP dans les Environnements Multi-AS

Le Border Gateway Protocol (BGP) est le protocole de passerelle extérieure (EGP) standard de facto utilisé pour échanger des informations de routage et d’accessibilité entre des systèmes autonomes (AS) indépendants sur Internet ou entre de grands réseaux d’entreprise.1 Un système autonome est un ensemble de réseaux IP et de routeurs sous le contrôle d’une seule entité administrative, possédant une politique de routage interne commune. Chaque AS se voit attribuer un numéro unique, l’ASN (Autonomous System Number).

Le scénario principal abordé dans ce document est la connexion de deux ASN distincts, une configuration connue sous le nom d’eBGP (External BGP). Dans ce contexte, BGP est essentiel pour déterminer les chemins que les données emprunteront pour traverser différentes frontières de réseaux autonomes. Au-delà de la simple connectivité, BGP joue un rôle crucial dans l’application des politiques de routage, permettant aux administrateurs de contrôler comment le trafic entre et sort de leur AS. Il assure également la scalabilité et la stabilité nécessaires au routage inter-domaines à grande échelle.[1]

1.2 Aperçu de l’Implémentation BGP dans VOSS/Fabric Engine

VOSS (Virtual Services Platform Operating System Software), également connu sous le nom de Fabric Engine, est le système d’exploitation d’Extreme Networks pour ses commutateurs VSP (Virtual Services Platform).4 VOSS intègre une prise en charge robuste de BGP, y compris BGPv4 pour l’adressage IPv4 et BGP+ (ou MP-BGP) pour l’adressage IPv6 et d’autres familles d’adresses.[2]

Les plateformes VOSS supportent un large éventail de fonctionnalités BGP standard, notamment :

• eBGP et iBGP (Internal BGP) : Pour le peering entre différents AS et au sein du même AS.
• Route Reflection et Confédérations : Pour améliorer la scalabilité des déploiements iBGP.
• Numéros d’AS 4 octets : Pour prendre en charge l’espace ASN étendu.
• Agrégation de routes (Route Summarization) : Pour réduire la taille des tables de routage BGP.
• Attributs de chemin BGP et Communautés : Pour une manipulation fine des politiques de routage.
• Route Dampening : Pour pénaliser les routes instables.
• ECMP (Equal Cost Multipath) : Pour l’équilibrage de charge sur plusieurs chemins de coût égal.
• Authentification MD5 : Pour sécuriser les sessions BGP.
• Redistribution de routes : Pour échanger des informations de routage avec d’autres protocoles (statiques, OSPF, IS-IS).[2]

Une caractéristique distinctive de VOSS est son intégration native avec Fabric Connect, une technologie basée sur le protocole SPB (Shortest Path Bridging) et IS-IS.[12]
Bien que BGP fonctionne comme un protocole de routage standard sur VOSS, son interaction avec l’environnement Fabric Connect nécessite une attention particulière, notamment lors du peering en périphérie du fabric.

La configuration de BGP sur VOSS peut être réalisée via l’interface de ligne de commande (CLI), qui sera le focus principal de ce guide, ou via l’Enterprise Device Manager (EDM), une interface graphique de gestion.[6]

Il est pertinent de noter une nuance observée : bien que la documentation officielle détaille un ensemble complet de fonctionnalités BGP standard dans VOSS [2], certains retours d’expérience de la communauté d’utilisateurs suggèrent que VOSS pourrait être perçu comme moins adapté aux scénarios de routage BGP très complexes ou “sérieux” par rapport aux plateformes de fournisseurs spécialisés en routage comme Juniper ou Arista.[5] Cela pourrait indiquer que, bien que VOSS implémente les fonctionnalités BGP de base conformément aux normes, sa conception principale pourrait privilégier l’intégration avec Fabric Connect et les scénarios de campus ou de data center, potentiellement au détriment d’une flexibilité ou d’une granularité extrême dans les politiques BGP avancées requises pour certains rôles de routage en périphérie Internet très complexes. La facilité d’utilisation souvent vantée de VOSS/Fabric [12] pourrait impliquer un compromis avec certaines options de configuration BGP très pointues. Néanmoins, pour le cas d’usage standard d’un peering eBGP entre deux AS avec des besoins de politique typiques, VOSS est très probablement suffisant et performant. Les utilisateurs doivent évaluer si les capacités BGP de VOSS répondent à leurs exigences spécifiques en termes de complexité et d’échelle.

1.3 Terminologie Clé

• AS (Autonomous System) : Un groupe de réseaux IP gérés par une seule entité administrative.
• ASN (Autonomous System Number) : Un numéro unique identifiant un AS.
• eBGP (External BGP) : Session BGP établie entre des routeurs appartenant à des AS différents.
• iBGP (Internal BGP) : Session BGP établie entre des routeurs appartenant au même AS.
• Voisin (Neighbor) / Pair (Peer) : Routeurs BGP qui ont établi une session pour échanger des informations de routage.
• Route Reflector (RR) : Un routeur iBGP qui peut refléter les routes apprises d’un pair iBGP vers d’autres pairs iBGP, évitant ainsi la nécessité d’un maillage complet (full mesh).
• Confédérations : Une méthode pour diviser un grand AS en sous-AS plus petits pour simplifier la topologie iBGP.
• VRF (Virtual Routing and Forwarding) : Une technologie qui permet à plusieurs instances de tables de routage d’exister et de fonctionner simultanément au sein du même routeur physique. Cela permet la segmentation du réseau.[2]

Section 2: Prérequis pour le Déploiement BGP

Avant de configurer BGP sur un commutateur VOSS, plusieurs prérequis doivent être satisfaits pour assurer une mise en œuvre réussie et stable.

2.1 Configuration des Interfaces IP

BGP nécessite des interfaces IP configurées sur le commutateur VOSS pour établir des sessions de peering. Ces interfaces servent de points de terminaison locaux pour les connexions BGP. Plusieurs types d’interfaces peuvent être utilisés :

• Interfaces VLAN : Il s’agit de l’approche la plus courante pour les connexions de peering. Une interface VLAN est créée, une adresse IP lui est assignée, et le port physique connecté au voisin BGP est assigné à ce VLAN.[15]
  Les commandes CLI typiques incluent create vlan <vlan_id>, configure vlan <vlan_id> ipaddress <ip_address>/<mask_length>, et enable ipforwarding vlan <vlan_id>.[25]
• Ports Physiques Routés (Brouter Ports) : Il est également possible de configurer directement une adresse IP sur un port physique.[18]
  La commande ip address <ip_address>/<mask_length> est utilisée dans le contexte de configuration de l’interface (interface GigabitEthernet <slot/port>).
• Interfaces Circuitless IP (CLIP) : Les CLIPs sont des interfaces virtuelles (similaires aux interfaces Loopback) qui ne sont pas liées à un port physique spécifique.[22]
  Elles sont fortement recommandées comme source pour les sessions BGP, en particulier pour iBGP ou lorsque plusieurs chemins physiques existent vers un pair eBGP.
  L’utilisation d’une CLIP améliore la stabilité de la session BGP car elle reste active tant que le routeur est joignable via n’importe quel chemin physique.[1]

Il est également important de distinguer les interfaces utilisées pour le peering BGP de celles utilisées pour la gestion (Management). VOSS offre plusieurs options pour la gestion IP, comme le port Out-of-Band (OOB), un VLAN de gestion dédié, ou une CLIP de gestion.[15]
Il est généralement recommandé de séparer le trafic de gestion du trafic de données et de peering BGP.

2.2 Assurer l’Accessibilité du Réseau Sous-jacent

BGP ne fonctionne pas de manière isolée ; il s’appuie sur une connectivité IP sous-jacente pour établir des sessions TCP avec ses pairs sur le port 179.
L’adresse IP du voisin BGP doit être joignable via la table de routage IP du commutateur VOSS.[1]
Cette accessibilité peut être assurée par :

• Connexion Directe : Si les pairs BGP sont sur le même segment de réseau (par exemple, connectés via un VLAN commun), la connectivité est directe.
• Routes Statiques : Des routes statiques peuvent être configurées pour atteindre le réseau du voisin BGP.[18] La commande configure iproute add <destination_prefix>/<length> next-hop <neighbor_ip> est utilisée.[26]
• Protocole de Routage Interne (IGP) : Lorsque les pairs ne sont pas directement connectés, ou lors de l’utilisation d’interfaces CLIP comme source, un IGP (tel qu’OSPF ou IS-IS) est nécessaire pour fournir l’accessibilité entre les adresses IP source et destination des pairs BGP.[1]
  VOSS supporte OSPF et IS-IS, ce dernier étant le protocole de contrôle fondamental de Fabric Connect/SPB.[15]

2.3 Considérations Relatives aux VRF pour le Peering BGP

BGP sur VOSS peut fonctionner soit dans la table de routage globale (GRT, correspondant à VRF 0), soit au sein de VRF définis par l’utilisateur.[2]
La configuration de BGP dans un VRF spécifique nécessite une attention particulière :

• Contexte de Configuration : Il faut entrer dans le contexte de configuration du VRF (router vrf <vrf_name>) avant de configurer les paramètres BGP.[11]
• Préfixe de Commande : De nombreuses commandes BGP globales doivent être préfixées par ip bgp lorsqu’elles sont appliquées dans un contexte VRF.[11]
• Déclencheur RP (RP Trigger) : Le VRF doit être configuré avec un déclencheur de protocole de routage (RP Trigger) pour BGP afin que le protocole puisse fonctionner au sein de ce VRF.[16]
• Limitations : Certaines fonctionnalités BGP, comme le rafraîchissement de route (route refresh), peuvent ne pas être supportées sur les VRF non par défaut dans certaines versions de VOSS.[11]

2.4 Sélection de l’ID de Routeur BGP et Meilleures Pratiques

L’ID de routeur BGP (Router ID) est un identifiant unique de 32 bits, généralement formaté comme une adresse IPv4, qui identifie un routeur BGP au sein du réseau.[1]
Il est utilisé dans les messages BGP et pour la détection de boucles.

• Configuration : Sur VOSS, l’ID de routeur est configuré en mode de configuration BGP à l’aide de la commande router-id {A.B.C.D}.[11]
• Meilleure Pratique : Il est fortement recommandé d’utiliser une adresse IP stable et toujours joignable comme ID de routeur, idéalement l’adresse IP d’une interface CLIP.[1] Utiliser l’IP d’une interface physique est déconseillé car si cette interface tombe, cela peut provoquer une instabilité de la session BGP. Les CLIPs, étant virtuelles, restent actives tant que le routeur fonctionne, assurant ainsi la stabilité de l’ID.[27]
• Interaction avec OSPF : Si OSPF est également utilisé sur le même routeur VOSS, il est impératif que l’ID de routeur BGP soit identique à l’ID de routeur OSPF.[1] Par défaut, VOSS tente d’utiliser l’ID OSPF comme ID BGP. Cette cohérence est essentielle pour une redistribution correcte des routes entre les protocoles et pour éviter les boucles de routage. Si les ID diffèrent, BGP pourrait mal interpréter l’origine des routes apprises via OSPF.[1]
• Dépendance de Configuration : Pour garantir la cohérence, l’ID de routeur OSPF doit être configuré avant d’activer BGP globalement. Si BGP est déjà actif et que l’ID OSPF doit être défini ou modifié, il peut être nécessaire de désactiver BGP, de configurer l’ID OSPF, puis de réactiver BGP.[1]
• ID Illégal : Le paramètre ignore-illegal-rtrid enable (activé par défaut) permet à VOSS d’accepter des sessions même si un pair envoie un ID de routeur de 0.0.0.0.[11]

L’importance d’un ID de routeur stable et cohérent ne peut être sous-estimée. Un ID instable peut entraîner des réinitialisations inutiles des sessions BGP. La cohérence avec l’ID OSPF est fondamentale pour l’interopérabilité et la prévention des boucles lors de la redistribution. Si les ID diffèrent, BGP pourrait mal interpréter l’origine ou la fiabilité des routes apprises via OSPF, affectant potentiellement la sélection du chemin ou la capacité à annoncer correctement les routes. L’utilisation d’interfaces CLIP comme source pour l’ID de routeur est donc une pratique fondamentale pour un fonctionnement BGP stable et prévisible sur VOSS.

2.5 Comprendre le Processus de Sélection de Route BGP

Dans un environnement multi-AS, il est fréquent qu’un routeur BGP apprenne plusieurs chemins vers la même destination. Le processus de sélection du meilleur chemin BGP est un algorithme séquentiel qui évalue différents attributs de chemin pour choisir la route optimale à installer dans la table de routage IP et à annoncer aux pairs eBGP. Comprendre cet algorithme est essentiel pour prédire et influencer le comportement du routage.

Sur VOSS, le processus de sélection suit généralement cet ordre 3 :

1. Poids (Weight) le plus élevé : Attribut spécifique à Cisco, mais supporté par VOSS. Il a une signification locale au routeur. Plus le poids est élevé, plus la route est préférée.
2. Préférence Locale (Local Preference) la plus élevée : Attribut ayant une signification globale au sein de l’AS local. Utilisé pour influencer le chemin de sortie de l’AS. Plus la valeur est élevée, plus la route est préférée.
3. Préférence pour les Routes Originées Localement : Les routes injectées localement via les commandes network, redistribute, ou aggregate sont préférées aux routes apprises des voisins. Les routes issues de network ou redistribute sont préférées à celles de aggregate.
4. Chemin AS (AS_PATH) le plus court : Le nombre d’AS traversés. Un chemin plus court est préféré. La longueur de la séquence de confédération (AS_CONFED_SEQUENCE) est également prise en compte.
5. Type d’Origine (Origin) le plus bas : Indique comment la route a été introduite dans BGP. L’ordre de préférence est : IGP (0) < EGP (1) < Incomplete (2).
6. MED (Multi-Exit Discriminator) le plus bas : Utilisé pour influencer le chemin d’entrée dans un AS voisin lorsque plusieurs points de connexion existent. Une valeur plus basse est préférée. Le comportement dépend des paramètres Always Compare MED ou Deterministic MED et Missing Is Worst.3 Par défaut, le MED n’est comparé que si les routes proviennent du même AS voisin.
7. Métrique IGP la plus basse vers le Prochain Saut (Next-Hop) BGP : Si plusieurs chemins existent vers le même next-hop BGP via l’IGP, celui avec la métrique IGP la plus basse est choisi.
8. Préférence pour les chemins eBGP sur iBGP : Les routes apprises via eBGP sont préférées à celles apprises via iBGP.
9. Considération ECMP : Si ECMP est activé (bgp multiple-paths), plusieurs chemins de coût égal peuvent être installés.
10. ID de Routeur le plus bas : Utilisé comme bris d’égalité final.

Tableau 2.1: Attributs de Sélection du Meilleur Chemin BGP sur VOSS

Ce tableau fournit une référence structurée pour le processus complexe de sélection de chemin BGP. La compréhension de cet ordre est fondamentale pour concevoir des politiques de routage efficaces, en particulier lorsque plusieurs chemins existent entre les ASN.

Section 3: Configuration eBGP de Base (CLI)

Cette section détaille les commandes CLI essentielles pour établir une session eBGP de base entre deux AS sur VOSS.

3.1 Activation du Processus BGP et Définition de l’AS Local

La première étape consiste à activer le processus BGP sur le routeur VOSS et à lui assigner son numéro d’AS local.

1. Accéder au mode de configuration globale[15]:

   enable  
   configure terminal
   

2. Définir l’ASN local et activer BGP pour la table de routage globale (VRF 0) [11]:

   router bgp <local_as_number> [enable]
   

   Remplacez <local_as_number> par le numéro d’AS attribué à votre réseau. Ce numéro doit être différent de zéro pour que BGP puisse être activé. [11]
   Le mot-clé enable assure explicitement que le processus est destiné à être actif, bien qu’il puisse être implicite dans certaines versions ou contextes. [16] VOSS supporte les ASN 4 octets (plage 1 à 4294967295). [2]

3. Pour configurer BGP dans un VRF non par défaut :
   Entrer dans le contexte du VRF :

   router vrf <vrf_name>
   

   Utiliser les commandes spécifiques au VRF, par exemple [2]:

   ip bgp <local_as_number>
   ip bgp enable.
   

Il est crucial d’être conscient du contexte (GRT ou VRF spécifique) lors de l’application des commandes.
Une erreur fréquente lors de la configuration initiale est d’utiliser des commandes destinées au GRT dans un contexte VRF ou vice-versa.
Vérifier l’invite de commande ou utiliser show running-config aide à éviter ces erreurs.[2]

3.2 Configuration des Voisins eBGP

Une fois le processus BGP local activé, l’étape suivante consiste à définir les voisins eBGP.

1. Accéder au mode de configuration du routeur BGP :
   • Pour le GRT (si vous n’y êtes pas déjà après l’étape 3.1):

router bgp

• Pour une VRF :

router vrf <vrf_name>

puis potentiellement entrer dans un sous-mode ip bgp si nécessaire selon la version/commande. [7]
2. Définir le voisin eBGP et son AS distant [7]:

   neighbor <neighbor_ip_address> remote-as <remote_as_number>

• <neighbor_ip_address> est l’adresse IP de l’interface du routeur pair.
• <remote_as_number> est l’ASN du système autonome auquel appartient le voisin. Pour eBGP, ce numéro sera différent du <local_as_number>.

3. Activer la connexion avec le voisin [7] :

neighbor <neighbor_ip_address> enable 

Par défaut, les voisins nouvellement configurés peuvent être administrativement désactivés.[[24]]  

4. Options supplémentaires courantes pour eBGP :
   • Description : Ajouter une description pour identifier le voisin : neighbor <neighbor_ip_address> description .[[015]]
   • eBGP Multihop : Si le pair eBGP n’est pas directement connecté (plus d’un saut IP), spécifier le TTL : neighbor <neighbor_ip_address> ebgp-multihop <ttl_value>.[33]
   • Authentification MD5 : Pour sécuriser la session, configurer un mot de passe sur les deux pairs :

     neighbor <neighbor_ip_address> password <password_string>  
     neighbor <neighbor_ip_address> MD5-authentication enable

3.3 Vérification de l’Adjacence des Voisins

Après la configuration, il est essentiel de vérifier que la session BGP s’établit correctement.

• Utiliser la commande show bgp neighbors ou show ip bgp neighbors.2
• Observer le champ State (ou Pstat / PeerState). L’état souhaité est Established. D’autres états comme Idle, Connect, Active, OpenSent, OpenConfirm indiquent des étapes de connexion ou des problèmes.
• Vérifier la configuration appliquée avec show running-config | section router bgp.15

Tableau 3.1: Commandes CLI Essentielles pour la Configuration eBGP de Base sur VOSS

Ce tableau résume les commandes fondamentales pour établir une session eBGP simple et sécurisée entre deux AS sur VOSS.

Section 4: Annonce et Réception des Préfixes Réseau

Une fois la session eBGP établie, l’étape suivante consiste à échanger des informations de routage (préfixes réseau). VOSS offre plusieurs méthodes pour annoncer des réseaux locaux et contrôler les routes reçues.

4.1 Origination de Routes avec la Commande network

La méthode la plus directe pour annoncer un réseau dans BGP est d’utiliser la commande network. Cette commande indique à BGP d’originer une annonce pour un préfixe spécifique, à condition que ce préfixe existe exactement (préfixe et masque) dans la table de routage IP principale du routeur (appris via une connexion directe, une route statique ou un IGP).23

• Syntaxe (en mode de configuration BGP) [23]:

  network <prefix/length> [metric <med_value>]  
  

• <prefix/length> : Le préfixe IP (IPv4 ou IPv6) et sa longueur à annoncer (ex: 10.1.0.0/16, 2001:db8:1::/48).
• metric <med_value> (Optionnel) : Définit l’attribut MED (Multi-Exit Discriminator) pour cette route lorsqu’elle est annoncée aux pairs eBGP. Une valeur MED plus basse est généralement préférée par l’AS voisin.[23]

4.2 Redistribution de Routes depuis d’autres Protocoles

La redistribution permet d’importer dans BGP des routes apprises via d’autres sources de routage. C’est utile pour annoncer des réseaux internes appris via un IGP ou des routes statiques vers des partenaires eBGP.

• Syntaxe (en mode de configuration BGP) :
  • Statique : redistribute static [enable][route-map <map_name>] [33]
  • OSPF : redistribute ospf [enable][route-map <map_name>][metric ][match <internal | external-1 | external-2>] [33]
  • IS-IS : redistribute isis [enable][route-map <map_name>][metric ][match <internal | external-1 | external-2>] [33]
  • Connecté (Direct) : redistribute direct [enable][route-map <map_name>] [32]
  • Des commandes équivalentes existent pour IPv6 (redistribute ipv6-static, redistribute ospfv3, etc…).[32]
• Contrôle via Route Maps :
  Il est fortement recommandé d’utiliser une route-map avec les commandes de redistribution. Sans route map, toutes les routes du protocole source pourraient être redistribuées, ce qui est rarement souhaitable et potentiellement dangereux.[35]
  La route map permet de filtrer sélectivement les routes à redistribuer et de modifier leurs attributs BGP (comme le MED ou les communautés) lors de l’importation.

La redistribution non contrôlée est une source fréquente de problèmes de routage, incluant les boucles, l’instabilité, et la surcharge des tables de routage BGP.
Le comportement par défaut de BGP de ne pas redistribuer automatiquement protège contre les fuites de routes accidentelles.[1]
L’utilisation systématique de route maps avec des listes de préfixes précises pour la redistribution est une meilleure pratique essentielle pour maintenir le contrôle et la stabilité.[32]

4.3 Exemple de Contrôle de Redistribution avec Route Map

Voici un exemple concret basé sur la redistribution de routes statiques, illustrant l’utilisation d’une route map pour le contrôle [35] :

1. Définir une liste de préfixes (prefix-list) pour identifier la ou les routes statiques spécifiques à redistribuer (ici, dans le contexte du VRF red) :

   router vrf red  
   ip prefix-list "STATIC_TO_BGP" 10.10.10.0/24 id 1 ge 24 le 24 permit  
   exit

2. Définir une route-map qui autorise les routes correspondant à la prefix-list :

   router vrf red  
   route-map "RM_STATIC_TO_BGP" 1 permit  
   enable  
   match network "STATIC_TO_BGP"  
   exit  
   exit

3. Appliquer la route-map à la commande de redistribution BGP :

   router vrf red  
   ip bgp redistribute static enable route-map "RM_STATIC_TO_BGP"  
   exit

4. Activer la redistribution (peut être nécessaire dans certains contextes VRF) [35]:

   ip bgp apply redistribute static vrf red  

Cet exemple garantit que seule la route statique 10.10.10.0/24 sera redistribuée dans BGP au sein du VRF red.

4.4 Vérification des Routes Annoncées et Reçues

Plusieurs commandes show sont disponibles pour vérifier quelles routes sont échangées :

• show ip bgp route ou show bgp route : Affiche la table de routage BGP locale (RIB-Loc), contenant les routes apprises et originées localement.[32]
• show ip route bgp : Affiche les routes BGP qui ont été sélectionnées comme meilleures et installées dans la table de routage IP principale (RIB globale).
• show bgp neighbors <neighbor_ip> advertised-routes : Montre les routes qui sont effectivement envoyées à un voisin spécifique (après application de la politique de sortie).
• show bgp neighbors <neighbor_ip> received-routes : Montre les routes brutes reçues d’un voisin avant l’application de toute politique d’entrée.
• show bgp neighbors <neighbor_ip> routes : Montre les routes reçues d’un voisin après l’application de la politique d’entrée. C’est ce qui est potentiellement éligible pour la sélection du meilleur chemin.

Section 5: Implémentation de la Politique de Routage avec les Route Maps

Les route maps sont le mécanisme principal sur VOSS pour implémenter des politiques de routage BGP complexes, permettant de filtrer les routes et de manipuler leurs attributs.

5.1 Aperçu des Route Maps dans VOSS pour BGP

Les route maps dans VOSS fonctionnent de manière similaire aux route-maps ou policy-statements d’autres fournisseurs.30 Elles sont constituées des éléments suivants :

• Nom : Identifie la politique.
• Numéros de Séquence : Traités par ordre croissant. Chaque séquence contient des conditions match et des actions set.
• Action (Permit/Deny) : Chaque séquence spécifie si les routes correspondantes sont autorisées (permit) ou bloquées (deny).
• Conditions match : Critères utilisés pour sélectionner les routes (ex: préfixe, AS path, communauté). Une route doit correspondre à toutes les conditions match d’une séquence pour que l’action de cette séquence s’applique.
• Actions set : Modifications appliquées aux attributs des routes correspondantes (ex: définir la préférence locale, ajouter une communauté).

Comportement Implicite : Il est crucial de comprendre le comportement par défaut à la fin d’une route map 36 :

• Politiques d’Entrée (Inbound) : Une route qui ne correspond à aucune séquence permit ou deny est implicitement autorisée.
• Politiques de Sortie (Outbound) / Redistribution : Une route qui ne correspond à aucune séquence permit est implicitement refusée. Pour éviter toute ambiguïté, il est souvent recommandé d’inclure une dernière séquence explicite (par exemple, permit sans condition match pour autoriser tout le reste en entrée, ou deny sans condition match pour bloquer tout le reste en sortie).

5.2 Filtrage des Routes

Les route maps utilisent divers critères match pour filtrer les routes :

• Listes de Préfixes (Prefix Lists) : Définies séparément (ip prefix-list <name> <prefix/len> id <id> [ge <len>][le <len>] permit/deny), elles permettent de correspondre à des préfixes IP spécifiques. Utilisées dans la route map avec match network <prefix_list_name>.[35]
• Listes de Chemins AS (AS Path Lists) : Définies avec ip as-path <name> <regex> permit/deny, elles utilisent des expressions régulières pour correspondre à des séquences d’AS dans l’attribut AS_PATH. Utilisées avec match as-path <as_path_list_name>.[2] Très utiles pour filtrer en fonction de l’origine ou des AS de transit.
• Listes de Communautés (Community Lists) : Définies avec ip community-list standard <name> permit/deny <community_value> ou ip community-list expanded <name> permit/deny <regex>, elles permettent de correspondre aux attributs de communauté BGP standard ou étendus. Utilisées avec match community <community_list_name> ou match extcommunity <ext_community_list_name>.[2] Essentielles pour les politiques basées sur les communautés.
• Autres Critères : match interface, match metric, match next-hop, match route-type, match tag, etc., peuvent être utilisés selon le contexte d’application de la politique.[36]

5.3 Modification des Attributs BGP

Les actions set dans les route maps permettent de modifier les attributs des routes correspondantes pour influencer le processus de sélection de chemin ou pour marquer les routes :

• set local-preference <value> : Modifie la préférence locale (plus élevée = préférée). Utilisé typiquement en entrée pour influencer le chemin de sortie de l’AS local.[36]
• set metric <value> : Modifie le MED (plus bas = préféré). Utilisé typiquement en sortie pour influencer le chemin d’entrée de l’AS voisin.[36]
• set weight <value> : Modifie le poids (plus élevé = préféré). Attribut local au routeur, utilisé en entrée.[36]
• set community <value | list_name> [additive] : Ajoute (avec additive) ou remplace les communautés BGP.[36]
• set as-path prepend <asn> <asn>... : Ajoute des ASN au début de l’AS_PATH pour le rendre artificiellement plus long et donc moins préférable.[36] Utilisé en sortie.
• set next-hop <ip_address> : Modifie l’adresse du prochain saut. À utiliser avec précaution, souvent lié à des scénarios iBGP.[36]
• set origin <igp | egp | incomplete> : Modifie l’attribut d’origine BGP.[36]

Tableau 5.1: Critères Match/Set Courants pour les Politiques BGP VOSS

Ce tableau, dérivé de [36], résume les blocs de construction clés pour élaborer des politiques de routage BGP sur VOSS.

5.4 Application des Politiques aux Voisins (Entrée et Sortie)

Une fois la route map définie, elle doit être appliquée à un voisin BGP spécifique pour prendre effet :

• Politique d’Entrée (Inbound) : Appliquée aux routes reçues d’un voisin.[33]

  neighbor <neighbor_ip> in-route-map <map_name>
  

• Politique de Sortie (Outbound) : Appliquée aux routes annoncées à un voisin.[33]

  neighbor <neighbor_ip> out-route-map <map_name>  
  

• Des commandes équivalentes existent pour IPv6 (ipv6-in-route-map, ipv6-out-route-map).[33]

Activation des Changements de Politique : Un point critique souvent négligé est que la simple configuration ou modification d’une route map appliquée ne la rend pas immédiatement active pour les routes existantes. Le processus BGP doit être invité à réévaluer les routes en utilisant la nouvelle politique. La méthode recommandée est la reconfiguration douce (soft reconfiguration), qui évite de couper la session TCP BGP.[1]

• Activer la capacité de reconfiguration douce en entrée (nécessite de stocker les routes non modifiées) : neighbor <neighbor_ip> soft-reconfiguration-in enable.[33]
• Déclencher la réévaluation de la politique (ici, pour l’entrée dans un VRF) [37]:

  ip bgp restart-bgp neighbor <neighbor_ip> vrf <vrf_name> soft-reconfiguration in
  

(Utiliser out pour la politique de sortie). Un redémarrage complet (restart-bgp sans soft-reconfiguration) peut également être utilisé, mais il interrompt la session.
Oublier cette étape d’activation signifie que la nouvelle politique n’est pas appliquée, conduisant à un comportement de routage incorrect et à des difficultés de dépannage.

5.5 Exemple: Politique de Filtrage eBGP Simple

Scénario :

• AS 65001 (local) pair avec AS 65002 (distant, IP 192.0.2.2).
• Entrée : Accepter uniquement le préfixe 172.16.10.0/24 de AS 65002, et lui attribuer une préférence locale de 150.
• Sortie : Annoncer uniquement le préfixe local 10.1.0.0/16 à AS 65002, avec un MED de 50.

Configuration :

! Définir les listes de préfixes  
ip prefix-list "ACCEPT_FROM_AS65002" 172.16.10.0/24 id 1 ge 24 le 24 permit  
ip prefix-list "ADVERTISE_TO_AS65002" 10.1.0.0/16 id 1 ge 16 le 16 permit

! Définir la route map d'entrée  
route-map "RM_IN_AS65002" 10 permit  
 enable  
 match network "ACCEPT_FROM_AS65002"  
 set local-preference 150  
exit  
! (Optionnel: Séquence implicite 'permit' ou explicite 'deny' à la fin si nécessaire)

! Définir la route map de sortie  
route-map "RM_OUT_AS65002" 10 permit  
 enable  
 match network "ADVERTISE_TO_AS65002"  
 set metric 50  
exit  
! (Important: Séquence implicite 'deny' à la fin pour ne pas annoncer d'autres routes)

! Appliquer les route maps au voisin BGP  
router bgp 65001  
 neighbor 192.0.2.2 remote-as 65002  
 neighbor 192.0.2.2 in-route-map "RM_IN_AS65002"  
 neighbor 192.0.2.2 out-route-map "RM_OUT_AS65002"  
 neighbor 192.0.2.2 soft-reconfiguration-in enable! Pour la reconfiguration douce en entrée  
 neighbor 192.0.2.2 enable  
exit

! Activer les politiques (après configuration ou modification)  
ip bgp restart-bgp neighbor 192.0.2.2 soft-reconfiguration in  
ip bgp restart-bgp neighbor 192.0.2.2 soft-reconfiguration out

Section 6: Amélioration de la Redondance et des Performances

Au-delà de la configuration de base et des politiques, plusieurs techniques peuvent être utilisées pour améliorer la résilience et les performances des liaisons eBGP sur VOSS.

6.1 Meilleures Pratiques: Utilisation des Interfaces Loopback/CLIP pour la Stabilité du Peering

Comme mentionné précédemment (Section 2.4), l’utilisation d’une adresse IP stable d’une interface CLIP comme source pour les sessions BGP est une pratique essentielle pour la résilience.[1]
Cela découple la session BGP de l’état d’une interface physique unique. Si un lien physique tombe mais qu’un autre chemin vers le pair existe (et que l’adresse CLIP reste joignable via l’IGP ou une route statique), la session BGP ne sera pas interrompue.

• Commande (en mode de configuration BGP) [32]:

  neighbor <neighbor_ip> update-source <clip_interface_ip_address> 

Il faut s’assurer que l’adresse IP du voisin est joignable via une route qui utilise l’interface CLIP comme sortie logique (souvent via l’IGP).

6.2 Équilibrage de Charge avec ECMP

ECMP (Equal Cost Multipath) permet à BGP d’installer plusieurs chemins de “meilleur coût” vers la même destination dans la table de routage, permettant ainsi l’équilibrage de charge du trafic sur ces chemins.[11]

• Activation (en mode de configuration BGP) [11]:

bgp multiple-paths <number>  

Où est le nombre maximal de chemins parallèles à installer (par exemple, 4 ou 8, selon la plateforme et la version VOSS). La valeur par défaut est 1, ce qui désactive ECMP pour BGP.

• Activation : La configuration de bgp multiple-paths ne modifie pas les routes existantes. Un redémarrage de BGP ou la réception de nouvelles mises à jour peut être nécessaire pour que les chemins ECMP soient calculés et installés.[11]
• Support Matériel : La capacité ECMP peut varier selon les plateformes matérielles VSP. Consulter les notes de version (Release Notes) de VOSS est recommandé.1

6.3 Implémentation de BFD pour une Détection Rapide des Pannes

BFD (Bidirectional Forwarding Detection) est un protocole léger conçu spécifiquement pour détecter rapidement les pannes de communication entre routeurs adjacents, beaucoup plus vite que les mécanismes de détection natifs des protocoles de routage comme les timers keepalive/hold de BGP.[31]

• Avantage : Réduit considérablement le temps de convergence en cas de défaillance d’un lien ou d’un voisin BGP.[40]
• Configuration sur VOSS : L’activation de BFD pour BGP implique généralement trois étapes [31] :
  1. Activation Globale de BFD : Un service BFD global doit potentiellement être activé (la commande exacte peut varier, ex: service bfd sur d’autres plateformes [40], vérifier la documentation VOSS spécifique). [39] mentionne une configuration globale.
  2. Activation sur l’Interface : BFD doit être activé sur l’interface IP utilisée pour le peering BGP [32]:

    interface <type> <slot/port_ou_vlan_id>  
     ip bfd enable  
     ipv6 bfd enable! Si IPv6 est utilisé  
    exit
  

  (Note: les commandes exactes peuvent nécessiter ip bfd ou ipv6 bfd sans enable selon le contexte).
  3. Liaison à BGP : Indiquer à BGP d’utiliser BFD pour surveiller le voisin [31]:

    router bgp <asn>  
     neighbor <neighbor_ip> fall-over bfd  
    exit
  

• Support et Limitations : BFD supporte eBGP et iBGP sur IPv4. Il peut y avoir des limitations pour BGPv6 sur les VRF non par défaut.[31]
  BFD doit être configuré de manière cohérente sur les deux pairs BGP pour établir une session BFD.

L’utilisation conjointe d’ECMP et de BFD offre une redondance robuste. ECMP fournit une diversité de chemins lorsque plusieurs liens de coût égal sont disponibles, tandis que BFD assure une détection ultra-rapide de la défaillance de n’importe quel chemin (unique ou faisant partie d’un groupe ECMP), permettant à BGP de réagir et de converger beaucoup plus rapidement que ne le permettraient ses timers natifs.[11] Pour les liaisons eBGP critiques nécessitant une haute disponibilité, la configuration des deux mécanismes est une meilleure pratique.

6.4 Autres Recommandations

• Limites de Préfixes Maximum (max-prefix) : Pour se protéger contre les erreurs de configuration chez le pair ou les fuites de routes massives qui pourraient saturer la mémoire ou le CPU du routeur local, il est prudent de définir une limite au nombre de préfixes acceptés d’un voisin [1]:

  neighbor <neighbor_ip> max-prefix <limit> [threshold <percentage>][warning-only]  
  

  La valeur par défaut est souvent de 12000.[24] Choisir une limite raisonnable basée sur la capacité du routeur et le nombre de routes attendues.
• Cohérence des Politiques : Réitérer la nécessité de politiques de routage coordonnées et cohérentes au sein de l’AS, en particulier sur tous les routeurs de bordure.[1]
• Timers BGP : Les timers Keepalive et Hold peuvent être ajustés (neighbor <neighbor_ip> timers <keepalive> <holdtime>).[24] Cependant, avec BFD disponible, il est généralement préférable de laisser les timers BGP à leurs valeurs par défaut (souvent 60s/180s) et de compter sur BFD pour une détection rapide des pannes.
• Amortissement des Flaps de Route (flap-dampening) : VOSS supporte le mécanisme de flap-dampening (flap-dampening en mode de configuration BGP) pour pénaliser les routes qui apparaissent et disparaissent fréquemment (flapping), améliorant la stabilité globale. Les paramètres spécifiques (seuils, pénalités) peuvent être ajustés.[2]

Section 7: BGP dans les Environnements Fabric Connect (SPB)

L’intégration de BGP dans un réseau basé sur Extreme Fabric Connect (utilisant SPB/IS-IS) nécessite de comprendre comment ces technologies interagissent.

7.1 Considérations pour le Peering en Périphérie du Fabric

Fabric Connect utilise SPB (IEEE 802.1aq) et IS-IS comme plan de contrôle unifié pour les services de niveau 2 et de niveau 3 au sein du domaine fabric.[13]
Dans ce contexte :

• Point de Peering BGP : Le peering BGP (en particulier eBGP) a généralement lieu sur les commutateurs situés en périphérie du fabric, appelés BEB (Backbone Edge Bridges). Ces BEB agissent comme des passerelles entre le domaine Fabric Connect et les réseaux externes (autres AS, Internet).
• Routage Interne vs Externe : Le routage au sein du fabric, y compris pour les L3 VSN (Virtual Service Networks - équivalents VRF étendus sur le fabric), est géré par IS-IS.[18] BGP est utilisé pour la connectivité externe, c’est-à-dire au-delà des frontières du fabric.

7.2 Interaction entre BGP et SPB/IS-IS

L’échange d’informations de routage entre BGP (externe) et IS-IS (interne au fabric) est possible mais doit être géré avec soin :

• Redistribution : Les routes apprises via BGP en périphérie peuvent être redistribuées dans IS-IS pour être connues à l’intérieur du fabric, et inversement, les routes internes (ex: L3 VSN) peuvent être redistribuées dans BGP pour être annoncées à l’extérieur.[33]
  • Commande BGP vers IS-IS : En mode configuration IS-IS, redistribute bgp….
  • Commande IS-IS vers BGP : En mode configuration BGP, redistribute isis….[33]
• Contrôle de la Redistribution : Il est crucial de contrôler finement la redistribution pour éviter de surcharger le domaine IS-IS interne avec potentiellement des centaines de milliers de routes BGP externes. L’utilisation de route maps est essentielle ici. Une pratique courante consiste à ne redistribuer qu’une route par défaut de BGP vers IS-IS, ou des résumés très agrégés.
• Politiques d’Acceptation IS-IS (isis accept-policy) : VOSS permet de configurer des politiques d’acceptation IS-IS qui filtrent les informations de routage échangées entre les nœuds IS-IS au sein du fabric.[18] Cela peut être utilisé pour contrôler la propagation des routes BGP qui auraient été redistribuées dans IS-IS par un BEB, offrant un niveau de contrôle supplémentaire.
• Cohérence des ID de Routeur : Si BGP et IS-IS (ou OSPF) coexistent sur le même BEB, la cohérence des ID de routeur reste primordiale.[1]
• Fabric Extend : Cette technologie permet d’étendre le fabric SPB sur des réseaux non-SPB (WAN, MPLS). BGP peut jouer un rôle dans le réseau sous-jacent (underlay) ou dans la manière dont les informations de routage sont échangées entre les sites étendus.[14]
• Simplification : Un avantage souvent cité de Fabric Connect est sa capacité à unifier les services L2 et L3 sous un seul plan de contrôle IS-IS, réduisant potentiellement la nécessité de protocoles multiples comme BGP, OSPF, PIM, et STP/MSTP à l’intérieur du domaine par rapport aux conceptions traditionnelles.[12]

Dans une architecture Fabric Connect, BGP agit principalement comme le protocole de démarcation à la frontière du fabric. Son rôle est de connecter le fabric au monde extérieur. Pour préserver les avantages de simplicité et de stabilité de Fabric Connect, il est préférable de minimiser et de contrôler strictement la redistribution entre BGP et le domaine IS-IS interne. Inonder IS-IS avec des routes BGP externes peut nuire aux performances et à la stabilité du fabric. L’approche recommandée est d’utiliser BGP pour le routage inter-AS en périphérie et de gérer soigneusement toute injection de routes externes dans le fabric, souvent via des routes par défaut ou des résumés.

Section 8: Dépannage de Base

Même avec une configuration soignée, des problèmes peuvent survenir lors de la mise en place ou de l’exploitation de BGP. Voici une approche systématique pour diagnostiquer les problèmes courants.

8.1 Problèmes d’Adjacence Courants

Si la session BGP ne parvient pas à l’état Established (show bgp neighbors), vérifier les points suivants :

1. Couche Physique et Liaison : Le lien physique est-il actif? L’interface est-elle administrativement active (show interfaces)?
2. Couche IP : Les adresses IP et les masques sont-ils corrects sur les deux pairs? Les pairs peuvent-ils se pinguer? (ping, traceroute).[18] Y a-t-il une route vers l’adresse IP du voisin? (show ip route).
3. Configuration BGP de Base :
   • Les numéros d’AS local et distant sont-ils correctement configurés sur les deux pairs? (show bgp neighbors, show running-config | section bgp). Une non-concordance des ASN est une cause fréquente d’échec eBGP.
   • Le processus BGP est-il activé globalement et le voisin est-il activé (enable)? (show bgp summary, show bgp neighbors).
   • L’adresse IP du voisin est-elle correcte dans la configuration neighbor?
4. Authentification MD5 : Si configurée, les mots de passe correspondent-ils exactement des deux côtés? (show bgp neighbors peut indiquer des problèmes d’authentification).
5. eBGP Multihop : Si les pairs ne sont pas directement connectés, la commande ebgp-multihop est-elle configurée avec un TTL suffisant?
6. Filtrage d’Accès : Y a-t-il des listes de contrôle d’accès (ACL) ou des pare-feux (sur les routeurs ou entre eux) qui bloquent le trafic TCP sur le port 179?
7. Source IP : Si update-source est utilisé, l’adresse source est-elle correcte et joignable par le pair?

8.2 Problèmes de Propagation des Routes

Si la session est établie mais que les routes attendues ne sont pas apprises ou annoncées :

1. Route Annoncée (Côté Émetteur) :
   • La route est-elle correctement injectée dans BGP via network ou redistribute? (show running-config | section bgp).
   • Si network est utilisé, le préfixe exact existe-t-il dans la table de routage IP locale? (show ip route).
   • La politique de sortie (out-route-map) appliquée au voisin bloque-t-elle la route? Vérifier la logique de la route map et utiliser show bgp neighbors <ip> advertised-routes.
2. Route Reçue (Côté Récepteur) :
   • La route est-elle reçue avant la politique d’entrée? Utiliser show bgp neighbors <ip> received-routes.
   • La politique d’entrée (in-route-map) appliquée au voisin bloque-t-elle la route? Vérifier la logique de la route map et utiliser show bgp neighbors <ip> routes (affiche les routes après la politique d’entrée).
   • La route est-elle présente dans la table BGP locale (show ip bgp route) mais non sélectionnée comme meilleure? Examiner les attributs BGP (AS Path, Origin, MED, Local Pref, etc.) pour comprendre pourquoi une autre route est préférée.
   • La route est-elle sélectionnée comme meilleure dans BGP mais pas installée dans la table de routage IP principale? (show ip route bgp). Cela peut être dû à une route provenant d’un autre protocole avec une meilleure préférence administrative (distance). Vérifier les préférences de route VOSS.[2]

8.3 Vérification de l’Application des Politiques

Si une politique de routage (route map) ne semble pas fonctionner comme prévu :

• Vérifier la configuration de la route map : show route-map <map_name>.
• Vérifier les listes de filtrage utilisées (prefix-list, as-path list, community list) : show ip prefix-list, show ip as-path, show ip community-list.
• Comparer la sortie de show bgp neighbors <ip> received-routes (avant politique d’entrée) et show bgp neighbors <ip> routes (après politique d’entrée) pour voir l’effet de in-route-map.
• Vérifier show bgp neighbors <ip> advertised-routes pour voir l’effet de out-route-map.
• Confirmer que la politique a été activée : Une reconfiguration douce (ip bgp restart-bgp neighbor... soft-reconfiguration) a-t-elle été effectuée après la modification de la politique?.[37] C’est une omission fréquente.

8.4 Commandes show et debug Clés

• Commandes show Essentielles :
  • show bgp summary : Vue d’ensemble rapide de l’état des voisins.
  • show bgp neighbors [detail] : Informations détaillées sur les voisins, état, timers, routes reçues/annoncées, etc.
  • show ip bgp route [prefix] : Affiche la table de routage BGP.
  • show ip route bgp : Affiche les routes BGP installées dans la RIB IP.
  • show route-map [name] : Affiche la configuration des route maps.
  • show running-config | section bgp : Affiche la configuration BGP actuelle.
• Commandes debug (à utiliser avec prudence) : Le débogage BGP peut générer un volume important de messages et impacter les performances du routeur. Utiliser de manière ciblée et désactiver dès que possible.
  • Activer l’affichage des messages debug (console ou log) : debug-screen on.[11]
  • Activer le débogage pour des événements spécifiques ou des voisins [11]:

    debug bgp neighbor <ip> events  
    debug bgp neighbor <ip> updates [in|out]  
    debug bgp keepalives  
    debug bgp packets [neighbor <ip>]  

• Utiliser les masques pour un contrôle plus fin : global-debug mask <choices> ou neighbor-debug-all mask <choices>.[11]
• Désactiver tout débogage : no debug all.

Une approche de dépannage logique et par étapes est recommandée : commencer par les couches basses (physique, IP), vérifier l’état de la session BGP, puis examiner l’échange de routes et enfin l’application des politiques.
Comprendre quelles commandes show fournissent des informations avant et après l’application des politiques est crucial. N’utiliser les commandes debug que si les commandes show ne suffisent pas à identifier le problème.

Section 9: Conclusion

9.1 Résumé des Étapes Clés de Configuration

La mise en place d’une connectivité eBGP entre deux systèmes autonomes sur une plateforme Extreme VOSS/Fabric Engine implique une série d’étapes structurées :

1. Prérequis : Assurer la connectivité IP sous-jacente, configurer les interfaces IP appropriées, sélectionner un ID de routeur stable (de préférence via CLIP) et s’assurer de sa cohérence avec les IGP éventuels (OSPF/IS-IS). Comprendre le contexte VRF si applicable.
2. Configuration BGP de Base : Activer le processus BGP, définir l’ASN local et configurer le voisin eBGP en spécifiant son adresse IP et son ASN distant. Activer la session de voisinage.
3. Annonce de Routes : Injecter les préfixes locaux dans BGP soit via la commande network (pour les routes existant dans la RIB IP), soit via la redistribution contrôlée depuis d’autres protocoles (statique, OSPF, IS-IS) en utilisant impérativement des route maps.
4. Implémentation des Politiques : Définir des route maps pour filtrer les routes entrantes/sortantes et/ou manipuler les attributs BGP (Local Preference, MED, Communautés, AS Path Prepending) afin de mettre en œuvre les politiques de routage souhaitées. Appliquer ces route maps aux voisins et activer les changements via une reconfiguration douce.
5. Redondance et Performance : Améliorer la résilience en utilisant des CLIPs comme source BGP, activer ECMP pour l’équilibrage de charge si plusieurs chemins existent, et déployer BFD pour une détection rapide des pannes de liaison/voisin.

9.2 Renforcement des Meilleures Pratiques pour BGP Multi-AS sur VOSS

Pour un déploiement BGP multi-AS réussi et stable sur VOSS, plusieurs meilleures pratiques doivent être suivies :

• Stabilité de l’ID de Routeur : Utiliser systématiquement des interfaces CLIP pour les ID de routeur BGP.
• Cohérence IGP/BGP : Assurer l’identité des ID de routeur si BGP coexiste avec OSPF ou IS-IS.
• Contrôle de la Redistribution : Ne jamais redistribuer sans filtrage ; utiliser des route maps précises.
• Politiques Explicites : Définir clairement les politiques d’acceptation et d’annonce via des route maps, en étant conscient des actions implicites (deny en sortie, permit en entrée).
• Détection Rapide des Pannes : Implémenter BFD pour minimiser les temps de convergence en cas de défaillance.
• Activation des Politiques : Toujours effectuer une reconfiguration douce après avoir modifié une politique appliquée à un voisin.
• Contexte VRF : Être rigoureux sur le contexte de configuration (GRT vs VRF) et l’utilisation des préfixes de commande appropriés.
• Compréhension de la Sélection de Chemin : Maîtriser l’algorithme de sélection de chemin BGP pour concevoir des politiques efficaces.
• Interaction Fabric Connect : Traiter BGP comme le protocole de bordure et gérer avec soin l’interaction (redistribution) avec le domaine IS-IS interne du fabric.

Il convient également de tenir compte des forces de VOSS (intégration Fabric Connect, facilité de gestion pour certains scénarios) et des retours d’expérience suggérant des limitations potentielles pour les déploiements de routage BGP en périphérie extrêmement complexes par rapport aux plateformes spécialisées.

9.3 Ressources Supplémentaires

Pour des informations plus détaillées et spécifiques à votre version de VOSS et à votre matériel VSP :

• Portail de Documentation Extreme Networks : documentation.extremenetworks.com contient les guides utilisateurs, les références CLI et les guides de configuration pour toutes les versions de VOSS/Fabric Engine.[15]
• Communauté Extreme Networks : Les forums de la communauté (community.extremenetworks.com) sont une ressource précieuse pour échanger avec d’autres utilisateurs, partager des expériences et obtenir de l’aide sur des scénarios pratiques.[25]
• Guides de Configuration Techniques (TCG - Technical Configuration Guide) : Rechercher des TCG spécifiques à BGP sur le portail de support Extreme, bien que certains puissent être datés (ex: un TCG BGP de Nov 2020 est mentionné dans [4]). Des guides plus récents sur les meilleures pratiques Fabric peuvent également être pertinents.[44]