4. VPN Route Distribution via BGP

4. Distribution des routes VPN via BGP (VPN Route Distribution via BGP)

Les routeurs PE utilisent BGP pour distribuer les routes VPN entre eux (plus précisément, pour permettre que les routes VPN soient distribuées entre eux).

Nous autorisons chaque VPN à avoir son propre espace d'adressage (address space), ce qui signifie qu'une adresse donnée peut faire référence à des systèmes différents dans différents VPN. Si deux routes vers un même préfixe (prefix) d'adresse IP sont en réalité des routes vers des systèmes différents, il est important que BGP ne les traite pas comme des routes comparables ; sinon, BGP pourrait n'en installer qu'une seule, rendant l'autre système injoignable. De plus, nous devons nous assurer que la politique (policy) est utilisée pour décider quels paquets sont envoyés sur quelles routes — une fois que BGP en a installé plusieurs, un seul de ces chemins peut apparaître dans un VRF donné.

Nous atteignons ces objectifs en utilisant une nouvelle famille d'adresses (address family), comme décrit ci-dessous.

4.1. La famille d'adresses VPN-IPv4 (The VPN-IPv4 Address Family)

Les extensions multiprotocoles de BGP [BGP-MP] permettent à BGP de transporter des routes de plusieurs « familles d'adresses ». Nous introduisons le concept de « famille d'adresses VPN-IPv4 ». Une adresse VPN-IPv4 est une quantité de 12 octets, commençant par un discriminateur de route (Route Distinguisher, ou RD) de 8 octets, suivi d'une adresse IPv4 de 4 octets. Si plusieurs VPN utilisent le même préfixe d'adresse IPv4, les PE convertissent ces préfixes en préfixes d'adresse VPN-IPv4 uniques. Cela garantit que si une même adresse est utilisée dans plusieurs VPN différents, BGP peut tout de même transporter plusieurs routes totalement distinctes vers cette adresse, une par VPN.

Étant donné que les adresses VPN-IPv4 et les adresses IPv4 appartiennent à des familles d'adresses différentes, BGP ne les traitera jamais comme des adresses comparables.

Le RD n'est qu'un nombre ; il ne contient aucune information intrinsèque. Il n'identifie ni l'origine de la route, ni l'ensemble des VPN auxquels la route sera distribuée. Le seul usage du RD est de permettre la création de routes distinctes pour un préfixe d'adresse IPv4 public commun. Quant à l'endroit où redistribuer la route, cela requiert d'autres moyens (voir section 4.3).

Le RD peut aussi être utilisé pour créer plusieurs routes distinctes vers un même système. Nous avons discuté du cas où la route vers un serveur (server) particulier doit être différente pour le trafic d'intranet et le trafic d'extranet. Cela peut être réalisé en créant deux routes VPN-IPv4 ayant la même partie IPv4 mais des RD différents. Cela permet à BGP d'installer plusieurs routes distinctes vers un même système, et d'utiliser la politique (voir section 4.3.5) pour décider quels paquets utilisent quelle route.

La structure du RD est conçue de sorte que chaque fournisseur de services puisse gérer son propre espace de numérotation (numbering space, c'est-à-dire assigner ses propres RD) sans entrer en conflit avec les assignations de RD faites par d'autres fournisseurs. Un RD se compose de trois champs : un champ de type (type) de 2 octets, un champ d'administrateur (administrator) et un champ de numéro assigné (assigned number). La valeur du champ de type détermine la longueur des deux autres champs, ainsi que la sémantique du champ d'administrateur. Le champ d'administrateur identifie une autorité (authority) ayant assigné le numéro, et le champ de numéro assigné contient un numéro assigné par cette autorité pour un usage particulier. Par exemple, un RD peut avoir un champ d'administrateur contenant un numéro de système autonome (Autonomous System number, ou ASN), et un (autre) champ de 4 octets contenant un numéro assigné par l'espace de numérotation géré par le SP auquel l'ASN a été attribué.

La raison d'être de cette structure de RD est de garantir qu'un SP fournissant le service de réseau dorsal VPN puisse toujours créer un RD unique quand nécessaire. Cependant, cette structure n'a aucun sens pour BGP — lorsque BGP compare ces deux préfixes d'adresse, il ignore totalement la structure.

Les PE doivent être configurés de sorte que les routes vers un CE particulier soient associées à un RD particulier. Cette configuration peut amener toutes les routes vers un CE particulier à être associées au même RD, ou peut amener différentes routes à être associées à différents RD, même si elles mènent vers un même CE.

4.2. Codage des discriminateurs de route (Encoding of Route Distinguishers)

Comme indiqué précédemment, une adresse VPN-IPv4 est composée d'un discriminateur de route de 8 octets suivi d'une adresse IPv4 de 4 octets. Le codage du RD est le suivant :

• Champ de type (Type Field) : 2 octets
• Champ de valeur (Value Field) : 6 octets

L'interprétation du champ de valeur dépend de la valeur du champ de type. Trois valeurs du champ de type sont actuellement définies : 0, 1 et 2.

• Type 0 : le champ de valeur se compose de deux sous-champs :

  • Sous-champ administrateur (Administrator subfield) : 2 octets
  • Sous-champ numéro assigné (Assigned Number subfield) : 4 octets

  Le sous-champ administrateur doit contenir un numéro de système autonome. Si cet ASN provient de l'espace d'ASN public, il doit avoir été attribué par l'autorité appropriée (l'utilisation de valeurs ASN de l'espace privé est fortement découragée). Le sous-champ numéro assigné contient un numéro de l'espace de numérotation géré par l'entreprise à laquelle l'ASN a été attribué.

• Type 1 : le champ de valeur se compose de deux sous-champs :

  • Sous-champ administrateur : 4 octets
  • Sous-champ numéro assigné : 2 octets

  Le sous-champ administrateur doit contenir une adresse IP. Si cette adresse IP provient de l'espace d'adressage IP public, elle doit avoir été attribuée par l'autorité appropriée (l'utilisation d'adresses de l'espace privé est fortement découragée). Le sous-champ numéro assigné contient un numéro de l'espace de numérotation géré par l'entreprise à laquelle l'adresse IP a été attribuée.

• Type 2 : le champ de valeur se compose de deux sous-champs :

  • Sous-champ administrateur : 4 octets
  • Sous-champ numéro assigné : 2 octets

  Le sous-champ administrateur doit contenir un numéro de système autonome de 4 octets (Autonomous System number) [BGP-AS4]. Si cet ASN provient de l'espace d'ASN public, il doit avoir été attribué par l'autorité appropriée (l'utilisation de valeurs ASN de l'espace privé est fortement découragée). Le sous-champ numéro assigné contient un numéro de l'espace de numérotation géré par l'entreprise à laquelle l'ASN a été attribué.

4.3. Contrôle de la distribution des routes (Controlling Route Distribution)

Dans cette section, nous discutons comment contrôler la distribution des routes VPN-IPv4.

Si un routeur PE est « attaché » à un VPN donné via sa connexion à un CE particulier de ce VPN, il apprendra certaines routes IP de ce VPN à partir du routeur CE concerné. Les routes apprises depuis un routeur CE particulier via un circuit de raccordement donné peuvent être installées dans le VRF associé à ce circuit de raccordement. Lesquelles de ces routes sont ainsi installées dépend de la façon dont le PE apprend les routes depuis le CE. En particulier, lorsque PE et CE sont des pairs du protocole de routage (routing protocol), cela est déterminé par le processus décisionnel (decision process) de ce protocole de routage, comme discuté à la section 7.

Ces routes sont ensuite converties en routes VPN-IPv4 et « exportées » (export) vers BGP. Si plusieurs routes vers un préfixe d'adresse VPN-IPv4 donné existent, BGP utilisera son processus décisionnel pour n'en sélectionner qu'une seule, la « meilleure » (best). Cette route est ensuite distribuée par BGP aux autres PE qui ont besoin de la connaître. Chez ces autres PE, BGP sélectionnera à nouveau la meilleure route VPN-IPv4 pour un préfixe d'adresse VPN-IPv4 donné. La route VPN-IPv4 sélectionnée est alors reconvertie en route IP et « importée » (import) dans un ou plusieurs VRF. Son installation effective dans un VRF dépend du processus décisionnel BGP et du processus décisionnel du protocole utilisé entre le PE et le CE. Enfin, toute route installée dans un VRF peut être distribuée aux routeurs CE associés.

4.3.1. L'attribut Route Target (The Route Target Attribute)

Chaque VRF est associé à un ou plusieurs attributs Route Target (RT, cible de route).

Lorsqu'un routeur PE crée une route VPN-IPv4 à partir d'une route IPv4 apprise d'un CE, la route est associée à un ou plusieurs attributs Route Target. Ces attributs sont transportés par BGP comme attributs de la route.

Toute route associée à la cible de route T doit être distribuée à chaque routeur PE possédant un VRF associé à la cible de route T. Lorsqu'un routeur PE reçoit une telle route, elle est éligible pour être installée dans les VRF de ce PE associés à la cible de route T. (Elle n'est réellement installée que si le résultat des processus décisionnels BGP et IGP le permet.)

Un attribut Route Target peut être considéré comme identifiant un ensemble de sites (bien que, plus précisément, on devrait le considérer comme identifiant un ensemble de VRF). Associer un attribut Route Target particulier à une route rend cette route éligible pour être placée dans les VRF utilisés pour router le trafic en provenance des sites correspondants.

Il existe un ensemble de cibles de route que les routeurs PE attachent aux routes apprises depuis un site S ; appelons-le les « cibles d'export » (Export Targets). Il existe également un ensemble de cibles de route que les PE utilisent pour décider si une route reçue d'un autre PE peut être placée dans le VRF associé au site S ; appelons-le les « cibles d'import » (Import Targets). Ces deux ensembles sont distincts et ne sont pas nécessairement identiques. Notez qu'une route VPN-IPv4 donnée n'est éligible pour être installée dans un VRF particulier que s'il existe une cible de route qui est à la fois l'une des cibles de route de la route et l'une des cibles d'import de ce VRF.

La fonction remplie par l'attribut Route Target est similaire à celle remplie par l'attribut BGP Communities. Cependant, le format de ce dernier est insuffisant pour l'usage présent, car il ne permet qu'un espace de numérotation de 2 octets. Nous prévoyons de structurer le format comme décrit pour le RD (voir section 4.2), de sorte qu'un champ de type définit la longueur du champ d'administrateur, et le reste de l'attribut provient de l'espace de numérotation de l'administrateur spécifié. Cela peut être réalisé en utilisant les communautés étendues BGP (BGP Extended Communities). Les cibles de route discutées ici sont codées comme des communautés étendues BGP Route Target [BGP-EXTCOMM], et ont une structure similaire à celle du RD.

Lorsqu'un orateur (speaker) BGP reçoit plusieurs routes vers un même préfixe VPN-IPv4, les règles de préférence de route (route preference) de BGP sont utilisées pour sélectionner la route VPN-IPv4 installée.

Notez qu'une route ne peut avoir qu'un seul RD, mais peut avoir plusieurs cibles de route. Dans BGP, l'utilisation d'une seule route avec plusieurs attributs (plutôt que de multiples routes) améliore l'évolutivité (scalability). On pourrait éliminer l'attribut Route Target en créant davantage de routes (c'est-à-dire en utilisant davantage de RD), mais cela dégraderait l'évolutivité.

Comment le PE décide-t-il quels attributs Route Target associer à une route donnée ? Plusieurs approches sont possibles. Le PE peut être configuré pour associer toutes les routes vers un site donné à une cible de route spécifiée. Alternativement, le PE peut être configuré pour associer certaines routes vers un site donné à une cible de route, et d'autres à une autre cible de route.

Si PE et CE sont eux-mêmes des pairs BGP (voir section 7), le SP peut, dans une certaine mesure, autoriser le client à spécifier la façon dont ses routes sont distribuées. Le SP et le client doivent s'entendre au préalable sur l'ensemble des RT que le client est autorisé à attacher aux routes de son VPN. Le CE peut alors attacher une ou plusieurs de ces RT à chacune des routes IP qu'il distribue au PE. Cela permet au client de spécifier en temps réel, dans des limites convenues, sa politique de distribution de routes. Si le CE est autorisé à attacher des RT à ses routes, le PE doit filtrer toutes les routes contenant des RT que le client n'est pas autorisé à utiliser. Sans cela, le PE doit supprimer la RT avant de convertir la route du client en route VPN-IPv4.

4.3.2. Distribution des routes entre PE via BGP (Route Distribution Among PEs by BGP)

Si deux sites d'un VPN sont raccordés à des PE situés dans le même système autonome (Autonomous System), ces PE peuvent se distribuer mutuellement des routes VPN-IPv4 via leurs connexions IBGP. (« IBGP » désigne l'ensemble des protocoles et procédures utilisés sur une connexion BGP lorsque les deux orateurs BGP sont dans le même système autonome. Cela diffère d'« EBGP » — l'ensemble des procédures utilisées entre deux orateurs BGP dans des systèmes autonomes différents.) Alternativement, chaque PE peut établir une connexion IBGP avec un réflecteur de route (route reflector) [BGP-RR].

Lorsqu'un routeur PE distribue une route VPN-IPv4 via BGP, il utilise sa propre adresse comme « prochain saut BGP » (BGP next hop). Cette adresse est codée comme une adresse VPN-IPv4 dont le RD est 0. ([BGP-MP] exige que l'adresse du prochain saut soit de la même famille d'adresses que les NLRI — Network Layer Reachability Information.) Il alloue et distribue également une étiquette (label) MPLS. (Essentiellement, le routeur PE distribue non pas une route VPN-IPv4, mais une « route VPN-IPv4 avec étiquette » — Labeled VPN-IPv4 route. Voir [MPLS-BGP].) Lorsqu'un PE traite un paquet reçu avec cette étiquette au sommet de la pile, le PE dépile (pop) la pile et traite le paquet de manière appropriée.

Ce PE peut distribuer l'ensemble exact des routes présentes dans le VRF, ou peut effectuer une agrégation (summarization) et distribuer un agrégat (aggregate) de ces routes, ou une combinaison des deux.

Supposons qu'un PE ait alloué une étiquette L pour la route R et ait distribué cette correspondance d'étiquette via BGP. Si R est un agrégat d'un ensemble de routes dans le VRF, alors ce PE sait que les paquets arrivant du réseau dorsal portant cette étiquette doivent avoir leur adresse de destination recherchée dans un VRF. Lorsque le PE recherche cette étiquette dans sa base d'informations d'étiquettes (Label Information Base), il apprend quel VRF utiliser. D'autre part, si R n'est pas un agrégat, lorsque le PE recherche l'étiquette, il apprend le circuit de raccordement de sortie (egress attachment circuit) et l'en-tête d'encapsulation du paquet. Dans ce cas, aucune recherche dans un VRF n'est effectuée.

Nous prévoyons que le cas le plus courant est celui où la route n'est pas un agrégat. Cependant, l'agrégat est très utile lorsque le VRF contient un grand nombre de routes d'hôte (host route, par exemple lors d'un accès par composition — dial-in), ou lorsque le VRF est associé à une interface de réseau local (Local Area Network, ou LAN) (où chaque système sur le LAN a un en-tête de couche 2 de sortie différent, mais où l'on ne distribue pas une route distincte pour chacun de ces systèmes).

Le fait que chaque route possède sa propre étiquette est un choix d'implémentation. Plusieurs algorithmes permettent de décider si deux routes se voient assigner la même étiquette :

• On peut choisir de faire partager un seul label à tout le VRF, de sorte que toutes les routes de ce VRF partagent le même label. Ainsi, lorsque le PE de sortie reçoit un paquet portant ce label, il doit rechercher l'adresse de destination IP du paquet dans ce VRF (le « VRF de sortie » du paquet) pour déterminer le circuit de sortie et l'encapsulation de liaison de données (data link) correspondante.

• On peut choisir de faire partager un seul label à chaque circuit de raccordement, de sorte que toutes les routes ayant le même « circuit de raccordement de sortie » partagent le même label. Cela permet d'éviter une recherche dans le VRF de sortie, bien qu'une recherche puisse encore être nécessaire pour déterminer l'encapsulation de liaison de données, par exemple une recherche ARP (Address Resolution Protocol).

• On peut choisir de donner à chaque route un label indépendant. Ainsi, si une route peut être atteinte via l'un de plusieurs circuits de raccordement, le routage PE/CE peut basculer le chemin préféré de la route d'un circuit à l'autre sans avoir à distribuer un nouveau label pour cette route.

D'autres algorithmes sont possibles. Le choix de l'algorithme est laissé à la discrétion du PE de sortie ; il est par ailleurs transparent.

En utilisant les étiquettes MPLS distribuées via BGP de cette manière, nous supposons qu'un paquet MPLS portant une telle étiquette peut être tunnelisé (tunnel) du routeur ayant installé la route BGP correspondante vers le routeur qui est le prochain saut BGP de cette route. Cela requiert soit un chemin de commutation d'étiquettes (label switched path) entre ces deux routeurs, soit la possibilité d'utiliser une autre technologie de tunnel (par exemple [MPLS-in-IP-GRE]).

Le tunnel peut suivre un routage « meilleur effort » (best effort), ou un routage avec ingénierie de trafic (traffic-engineered). Entre une paire de routeurs donnée, il peut y avoir un tel tunnel, ou plusieurs, éventuellement avec différentes caractéristiques de qualité de service (Quality of Service, ou QoS). Pour l'architecture VPN, l'essentiel est qu'un tel tunnel existe. Pour garantir l'interopérabilité (interoperability) entre les systèmes mettant en œuvre cette architecture VPN en utilisant des chemins de commutation d'étiquettes MPLS comme technologie de tunnel, tous ces systèmes doivent prendre en charge le protocole de distribution d'étiquettes (Label Distribution Protocol, ou LDP) [MPLS-LDP]. En particulier, le mode non sollicité en aval (Downstream Unsolicited) doit être pris en charge sur les interfaces autres que LC-ATM (Label Controlled ATM) [MPLS-ATM] et LC-FR (Label Controlled Frame Relay) [MPLS-FR], et le mode à la demande en aval (Downstream on Demand) doit être pris en charge sur les interfaces LC-ATM et LC-FR.

Si le tunnel suit un routage meilleur effort, le PE trouve la route vers l'extrémité distante (remote endpoint) en recherchant son adresse IP dans la table de transit par défaut.

Un routeur PE, à moins qu'il ne soit un réflecteur de route (voir section 4.3.3) ou un ASBR (Autonomous System Border Router) d'un VPN multi-fournisseurs (voir section 10), ne doit pas installer une route VPN-IPv4 à moins qu'il n'ait au moins un VRF dont l'une des cibles d'import soit identique à l'un des attributs Route Target de la route. Un filtrage entrant (inbound filtering) doit être utilisé pour ignorer de telles routes. Si un nouveau target d'import est ensuite ajouté à un VRF d'un PE (une opération « Jonction VPN » — VPN Join), ce PE doit ensuite acquérir les routes qu'il aurait pu ignorer précédemment. Cela peut être réalisé en utilisant le mécanisme de rafraîchissement (refresh) décrit dans [BGP-RFSH]. Le mécanisme de filtrage de routes sortant (outbound route filtering) de [BGP-ORF] peut également être utilisé pour rendre le filtrage plus dynamique.

De même, si un target d'import particulier n'existe plus dans aucun VRF d'un PE (à la suite d'une ou plusieurs opérations « Élagage VPN » — VPN Prune), ce PE peut ignorer toutes les routes qui, de ce fait, n'ont plus aucun target d'import de ce PE parmi leurs attributs Route Target.

Un routeur qui n'est raccordé à aucun VPN, et qui n'est pas un réflecteur de route (c'est-à-dire un routeur P), n'installera jamais aucune route VPN-IPv4.

Notez que les opérations de Jonction et d'Élagage VPN sont non perturbatrices (non-disruptive) dès lors que le mécanisme de rafraîchissement de [BGP-RFSH] est utilisé ; aucune connexion BGP n'a besoin d'être rompue.

En raison de ces règles de distribution, aucun PE n'a besoin de maintenir les routes de tous les VPN pris en charge ; c'est une considération d'évolutivité importante.

4.3.3. Utilisation des réflecteurs de route (Use of Route Reflectors)

Plutôt que d'établir un maillage IBGP (mesh) complet entre les PE, il est avantageux d'utiliser les réflecteurs de route BGP [BGP-RR] pour améliorer l'évolutivité. Toutes les techniques habituelles d'utilisation des réflecteurs de route pour l'évolutivité (par exemple une hiérarchie (hierarchy) de réflecteurs de route) sont disponibles.

Les réflecteurs de route sont les seuls systèmes qui ont besoin de connaître les routes de VPN auxquels ils ne sont pas directement raccordés. Cependant, il n'est pas nécessaire qu'un seul réflecteur de route connaisse l'ensemble des routes VPN-IPv4 de tous les VPN pris en charge par le réseau dorsal.

Nous décrivons ci-dessous deux façons différentes de répartir l'ensemble des routes VPN-IPv4 entre un ensemble de réflecteurs de route.

1. Chaque réflecteur de route est préconfiguré avec une liste de cibles de route. Plusieurs réflecteurs de route peuvent être préconfigurés avec la même liste pour la redondance. Le réflecteur de route utilise la liste préconfigurée pour construire son filtrage de routes entrant. Le réflecteur de route peut utiliser les techniques de [BGP-ORF] pour installer, sur chacun de ses pairs (qu'il s'agisse d'un autre réflecteur de route ou d'un PE), l'ensemble de filtres de routes sortants (Outbound Route Filter, ou ORF) contenant sa liste préconfigurée de cibles de route. Notez que le réflecteur de route devrait accepter les ORF d'autres réflecteurs de route, ce qui signifie qu'il devrait annoncer (advertise) la capacité (capability) ORF à d'autres réflecteurs de route.

   Le fournisseur de services peut modifier la liste préconfigurée de cibles de route sur un réflecteur de route. Lorsqu'il le fait, le réflecteur de route modifie les ORF qu'il a installés sur tous ses pairs IBGP. Pour réduire la fréquence des changements de configuration sur les réflecteurs de route, un bloc (block) de cibles de route peut être préconfiguré pour chaque réflecteur de route. Ainsi, lorsqu'un nouveau VPN nécessite une nouvelle cible de route, un ou plusieurs réflecteurs de route ont déjà (pré-)configuré cette cible de route.

   À moins qu'un PE donné ne soit le client de tous les réflecteurs de route, l'ajout d'un nouveau VPN à ce PE (« Jonction VPN ») nécessitera qu'il devienne le client du (ou des) réflecteur(s) de route maintenant les routes de ce VPN. De même, la suppression d'un VPN existant d'un PE (« Élagage VPN ») peut amener une situation où ce PE n'a plus besoin d'être le client de certains réflecteurs de route. Dans les deux cas, l'opération de jonction ou d'élagage est non perturbatrice (à condition d'utiliser [BGP-RFSH]), et ne nécessite jamais de rompre une connexion BGP, seulement de la rétablir.

   (Par « ajout d'un nouveau VPN à un PE », nous entendons : ajout d'un nouveau target d'import à l'un de ses VRF, ou ajout d'un nouveau VRF dont le target d'import n'est celui d'aucun autre VRF de ce PE.)

2. Une autre approche consiste à faire de chaque PE le client d'un ensemble de réflecteurs de route. Plutôt que de préconfigurer une liste de cibles de route et d'appliquer un filtrage de routes entrant sur les routes reçues de ses clients (PE), le réflecteur de route accepte toutes les routes de tous ses clients (PE). Le réflecteur de route suit l'ensemble des cibles de route portées par toutes les routes qu'il reçoit. Lorsqu'il reçoit d'un client une route portant une cible de route absente de cet ensemble, la cible de route est immédiatement ajoutée à l'ensemble. D'autre part, lorsqu'il ne possède plus aucune route portant une cible de route particulière de l'ensemble, le réflecteur de route devrait retarder (de plusieurs heures) la suppression de cette cible de route de l'ensemble.

   Le réflecteur de route utilise cet ensemble pour construire le filtre de routes entrant qu'il applique aux routes reçues d'autres réflecteurs de route. Il peut également utiliser les ORF pour installer le filtrage de sortie approprié sur les autres réflecteurs de route. Comme pour la première méthode, le réflecteur de route devrait accepter les ORF d'autres réflecteurs de route, et devrait donc annoncer la capacité ORF à ces derniers.

   Lorsque le réflecteur de route modifie cet ensemble, il doit modifier immédiatement son filtrage de routes entrant. De plus, si le réflecteur de route utilise les ORF, les ORF doivent être immédiatement modifiés pour refléter le changement de l'ensemble. Si le réflecteur de route n'utilise pas les ORF et ajoute une nouvelle cible de route à l'ensemble, il doit émettre un rafraîchissement BGP (BGP Refresh) vers les autres réflecteurs de route après avoir modifié son filtrage entrant.

   Le délai de « plusieurs heures » permet au réflecteur de route de conserver des routes portant une cible de route donnée, même s'il a perdu son dernier client intéressé par ce type de routes. Cela évite de devoir réacquérir toutes ces routes si la « disparition » du client n'était que temporaire.

   Avec ce processus, les opérations de Jonction et d'Élagage VPN sont également non perturbatrices.

   Notez que cette technique ne fonctionne pas correctement si un PE client a un VRF dont le target d'import n'est l'un de ses targets d'export.

Dans ces procédures, un routeur PE raccordé à un VPN particulier « découvre automatiquement » (auto-discover) les autres PE raccordés au même VPN. L'ajout d'un nouveau routeur PE, ou le raccordement d'un PE existant à un nouveau VPN, ne nécessite aucune reconfiguration des autres routeurs PE.

Tout comme aucun routeur PE n'a besoin de connaître toutes les routes VPN-IPv4 prises en charge par le réseau dorsal, ces règles de distribution garantissent qu'aucun réflecteur de route (RR) n'a besoin de connaître toutes les routes VPN-IPv4 prises en charge. Par conséquent, le nombre total de telles routes que le réseau dorsal peut prendre en charge n'est limité par la capacité d'aucun équipement unique, et peut donc croître presque sans borne.

4.3.4. Comment la NLRI VPN-IPv4 est transportée dans BGP (How VPN-IPv4 NLRI Is Carried in BGP)

Les extensions multiprotocoles de BGP [BGP-MP] sont utilisées pour coder la NLRI. Si le champ AFI (Address Family Identifier) est fixé à 1 et le champ SAFI (Subsequent Address Family Identifier) à 128, la NLRI est une adresse VPN-IPv4 avec étiquette. L'AFI 1 est utilisé car le protocole de couche réseau associé à cette NLRI reste IP. Notez que cette architecture VPN n'exige pas la capacité de distribuer des adresses VPN-IPv4 sans étiquette.

Pour qu deux orateurs BGP puissent échanger des NLRI VPN-IPv4 avec étiquette, ils doivent utiliser l'annonce de capacités (Capabilities Advertisement) de BGP pour s'assurer mutuellement qu'ils peuvent traiter correctement de telles NLRI. Cela se fait conformément à [BGP-MP], en utilisant le code de capacité (capability code) 1 (BGP multiprotocole) avec AFI=1 et SAFI=128.

Le codage de la NLRI VPN-IPv4 avec étiquette est spécifié dans [MPLS-BGP], où le préfixe est composé d'un RD de 8 octets suivi d'un préfixe IPv4.

4.3.5. Construire des VPN en utilisant les cibles de route (Building VPNs Using Route Targets)

En configurant de manière appropriée les cibles d'import et d'export, on peut construire différents types de VPN.

Supposons que l'on souhaite créer un groupe d'utilisateurs fermé (closed user group) maillé, c'est-à-dire un ensemble de sites où chaque site peut envoyer du trafic directement à tout autre site, mais où le trafic ne peut être ni envoyé ni reçu depuis d'autres sites. Alors, chaque site est associé à un VRF ; on choisit un attribut Route Target unique, qu'on désigne à la fois comme target d'import et comme target d'export pour chaque VRF, et on ne désigne pas ce target de route comme target d'import ou d'export pour aucun autre VRF.

Autre cas, supposons que l'on souhaite créer un VPN de type « concentrateur-remote » (hub and spoke). Cela peut se faire en utilisant deux valeurs de cible de route, l'une signifiant « concentrateur » (Hub), l'autre « remote » (Spoke). Sur le VRF raccordé au site concentrateur, « Hub » est la target d'export et « Spoke » est la target d'import. Sur le VRF raccordé au site remote, « Hub » est la target d'import et « Spoke » est la target d'export.

Ainsi, la méthode de contrôle de la distribution des informations de routage entre ensembles de sites est très flexible, ce qui offre à son tour une grande flexibilité dans la construction des VPN.

4.3.6. Distribution des routes entre VRF dans un seul PE (Route Distribution Among VRFs in a Single PE)

Même si deux VRF sont dans le même PE, les routes peuvent être distribuées d'un VRF à l'autre, bien que l'on ne puisse pas dire dans ce cas que la route est distribuée via BGP. Néanmoins, la décision de distribuer une route particulière d'un VRF à un autre VRF dans le même PE est la même que si les VRF étaient sur des PE différents. C'est-à-dire qu'elle dépend de l'attribut Route Target assigné à la route (ou de celui qui aurait été assigné si la route avait été distribuée via BGP), et des cibles d'import du second VRF.