Les réseaux de télécommunication actuels et les centres de données infonuagiques transportent les flux de centaines d'organisations distinctes sur une infrastructure matérielle partagée. Dans le routage IP classique, chaque routeur maintient une table globale unique. Si deux entreprises indépendantes se connectent au même équipement tout en utilisant des sous-réseaux privés identiques conformes à la RFC 1918, des collisions de routage se produisent inévitablement, provoquant des ruptures de service et des fuites de données.

Afin de résoudre ce problème de routage multi-tenant, l'IETF a standardisé les réseaux privés virtuels BGP/MPLS IP dans la RFC 4364 (originellement RFC 2547). Désignée dans l'industrie sous le nom de BGP L3VPN, cette architecture cloisonne les domaines de routage clients au niveau de la couche 3 grâce aux instances de routage virtuel VRF (Virtual Routing and Forwarding), au protocole MP-BGP (RFC 4760) et à un mécanisme de commutation d'étiquettes MPLS à deux niveaux.

Le dilemme du routage multi-tenant dans les réseaux d'entreprise

Lorsque des entreprises bâtissent des réseaux étendus multisites, s'interconnectent avec des environnements cloud ou souscrivent des liaisons spécialisées auprès d'opérateurs, leurs flux transitent par des dorsales partagées.

Une approche élémentaire consisterait à séparer physiquement les liens ou à monter des tunnels de chiffrement point à point entre chaque site. Cependant, relier des centaines de succursales crée un goulot d'étranglement quadratique $O(N^2)$, générant de lourdes contraintes d'exploitation :

  1. Les routeurs de cœur de réseau doivent mémoriser des millions de routes clientes, saturant la mémoire matérielle TCAM.
  2. Les plages d'adressage se chevauchent lorsque plusieurs entreprises exploitent les blocs standards 10.0.0.0/8 ou 192.168.1.0/24.
  3. La charge de configuration augmente de façon exponentielle à chaque intégration de nouveau site.

La RFC 4364 lève ces contraintes structurelles. En concentrant l'intelligence VPN sur les routeurs périphériques de l'opérateur (Provider Edge, PE) et en maintenant un cœur (Provider, P) dédié uniquement à la commutation d'étiquettes légères, BGP L3VPN assure des communications directes avec une étanchéité mathématique rigoureuse.

+-----------------------------------------------------------------------------+
|                     TOPOLOGIE RÉSEAU BGP L3VPN (RFC 4364)                   |
+-----------------------------------------------------------------------------+
[ CE-A1 ] ---> [ PE 1 ] ======================== [ PE 2 ] ---> [ CE-A2 ] (Client A)
                  ||     (Cœur P : commutation étiquettes) ||
[ CE-B1 ] ---> [ PE 1 ] ======================== [ PE 2 ] ---> [ CE-B2 ] (Client B)

Virtual Routing and Forwarding (VRF) : segmentation des tables et de la mémoire

Le pilier fondamental du cloisonnement de couche 3 est le Virtual Routing and Forwarding (VRF). Au lieu de gérer une table de routage monolithique, le routeur PE subdivise ses plans de contrôle et de données en plusieurs routeurs virtuels autonomes.

Chaque instance VRF dispose de sa propre base d'informations de routage (RIB) et d'acheminement (FIB). Les interfaces physiques ou les sous-interfaces logiques associées à des balises VLAN IEEE 802.1Q sont rattachées directement à une VRF définie.

Séparation du plan de contrôle et des bases d'acheminement FIB

Lorsqu'un routeur périphérique client (Customer Edge, CE) annonce des préfixes au nœud PE 1 via BGP, OSPF ou du routage statique :

  • La mise à jour est enregistrée exclusivement dans la table RIB de la VRF correspondante.
  • Les processus s'exécutant dans une VRF n'ont aucune visibilité sur les autres VRF du châssis.
  • Les paquets entrant par une interface client consultent uniquement la base FIB de la VRF associée.

La consultation étant confinée à l'instance virtuelle attribuée, un paquet du Client A ne peut jamais être envoyé vers le Client B, même si son adresse IP de destination coïncide avec un préfixe de la table du Client B.

Gestion des chevauchements d'adresses privées selon la RFC 1918

Comme les VRF cloisonnent l'état de routage au niveau du noyau, plusieurs clients peuvent employer des sous-réseaux IPv4 identiques sans le moindre conflit.

Par exemple, le Client A et le Client B peuvent utiliser simultanément 10.50.0.0/24. Sur l'équipement PE :

  • Le trafic du Client A interroge la table FIB de VRF-Alpha pour joindre CE-A2.
  • Le trafic du Client B interroge la table FIB de VRF-Beta pour joindre CE-B2.

Cependant, dès que ces routes franchissent le PE pour être distribuées dans la dorsale via MP-BGP, le routage IPv4 standard ne peut plus différencier les deux blocs 10.50.0.0/24. La RFC 4364 résout cette ambiguïté en introduisant les Route Distinguishers.

Route Distinguishers (RD) : unicité globale des préfixes réseau

Un Route Distinguisher (RD) est une valeur numérique de 8 octets (64 bits) configurée pour chaque VRF. Quand un routeur PE réinjecte un préfixe IPv4 d'une VRF client dans MP-BGP, il préfixe l'adresse IPv4 de 4 octets par ce RD de 8 octets.

La structure globale de 12 octets (96 bits) obtenue forme un préfixe VPN-IPv4 (AFI=1, SAFI=128) :

+-----------------------------------------------------------------------------+
|                 STRUCTURE D'ADRESSE VPN-IPV4 SELON LA RFC 4364              |
+-----------------------------------------------------------------------------+
|     Route Distinguisher (64 bits)   |          Préfixe IPv4 (32 bits)       |
+-------------------------------------+---------------------------------------+

La RFC 4364 formalise trois formats types pour le champ RD :

  • Type 0 : Numéro d'AS (ASN) sur 2 octets et valeur numérique sur 4 octets (ex. 65001:100).
  • Type 1 : Adresse IPv4 sur 4 octets et valeur numérique sur 2 octets (ex. 198.51.100.1:100).
  • Type 2 : Numéro d'AS sur 4 octets et valeur numérique sur 2 octets (ex. 4200000001:100).

En associant 65001:100 au réseau du Client A et 65001:200 à celui du Client B, les adresses deviennent 65001:100:10.50.0.0/24 et 65001:200:10.50.0.0/24. Pour MP-BGP, il s'agit d'entrées distinctes pouvant cohabiter dans la même table sans interférence.

Route Targets (RT) : communautés étendues BGP et politiques de distribution

Une erreur classique consiste à penser que le Route Distinguisher dicte quelle VRF doit recevoir une route. En réalité, le RD ne transporte aucune règle de politique ; il confère uniquement l'unicité aux adresses.

L'acheminement et le filtrage des routes entre différentes VRF sont pris en charge par les Route Targets (RT), transmis sous forme de communautés étendues BGP (RFC 4360).

[ VRF Alpha PE 1 ] ---> Exporte RT 65001:101 ---> [ Cœur MP-BGP ]
                                                         |
[ VRF Alpha PE 2 ] <--- Importe RT 65001:101 <-----------+

Chaque VRF maintient deux listes de communautés autonomes :

  • Export Route Targets : Attribuées aux routes clientes lors de leur réinjection dans MP-BGP.
  • Import Route Targets : Utilisées lors de la réception des annonces VPN-IPv4. Si une annonce comprend un RT inscrit dans la liste d'importation locale, la route est délestée de son RD et intégrée dans la table RIB de la VRF.

Maîtrise des topologies d'interconnexion : Hub-and-Spoke et Full-Mesh

La dissociation des RT d'importation et d'exportation autorise la mise en œuvre de schémas de communication complexes sans altérer le câblage physique :

  • Topologie maillée (Full-Mesh) : Tous les sites exportent et importent le même RT (export 65001:100, import 65001:100), autorisant des flux directs entre l'ensemble des succursales.
  • Topologie en étoile (Hub-and-Spoke) : Les nœuds distants (Spokes) exportent RT-Spoke et importent RT-Hub. Le nœud central (Hub) exporte RT-Hub et importe RT-Spoke. Les liaisons directes entre Spokes sont bloquées, tout le trafic passant obligatoirement par le pare-feu du Hub.
  • Services partagés en Extranet : Une VRF entreprise importe un RT administratif exporté par une VRF de services centraux (serveurs DNS, contrôleurs d'accès), ouvrant l'accès aux ressources sans exposer les réseaux internes.

Pile d'étiquettes à deux niveaux : mécanique de commutation MPLS et VPN

Après l'échange des routes sur le plan de contrôle, le transfert physique des paquets à travers la dorsale repose sur une pile d'étiquettes MPLS à deux niveaux.

Lorsqu'un routeur PE d'entrée encapsule un paquet client, il empile deux étiquettes MPLS indépendantes de 32 bits (RFC 3031) :

+-----------------------------------------------------------------------------+
|                 STRUCTURE DE LA PILE D'ÉTIQUETTES MPLS À DEUX NIVEAUX       |
+-----------------------------------------------------------------------------+
| Trame niveau 2 | Étiquette transport externe | Étiquette VPN interne | Données|
+-----------------------------------------------------------------------------+
  1. Étiquette interne (étiquette VPN / Service) : Distribuée par le PE de sortie via MP-BGP. Elle signale au PE récepteur la VRF de destination ou l'interface de sortie vers laquelle diriger le paquet.
  2. Étiquette externe (étiquette transport / IGP) : Allouée par LDP, RSVP-TE ou Segment Routing. Elle guide le paquet le long des routeurs intermédiaires P vers l'adresse Loopback du PE de sortie.

Étiquettes de transport externes et passage à l'échelle du cœur P

Cette double labellisation garantit la scalabilité globale du réseau :

  • Les routeurs intermédiaires P n'inspectent que l'étiquette de transport externe.
  • Les équipements de cœur commutent les trames à grande vitesse sans lire les en-têtes IP clients ni les étiquettes VPN.
  • Le cœur demeure affranchi de l'état des routes privées et ne gère que les adresses des routeurs de terminaison.

Sur l'avant-dernier saut avant le PE de sortie, le mécanisme Penultimate Hop Popping (PHP) retire l'étiquette externe. Le PE de sortie reçoit le paquet muni de la seule étiquette interne, réalise une consultation instantanée et délivre le paquet IP natif directement sur l'interface du client.

Sécurité du plan de données et risques de fuites VRF dans le cloud

Bien que BGP L3VPN offre un cloisonnement solide, des erreurs de paramétrage peuvent entraîner des risques critiques :

  1. Pollution croisée de Route Target : Une faute de frappe dans la politique d'importation (comme injecter 65001:200 dans VRF-Alpha) fusionne les tables de deux organisations distinctes, établissant des flux illicites entre réseaux non fiables.
  2. Déni de service par saturation de routes : Un équipement CE compromis peut injecter massivement des milliers de préfixes, saturant la mémoire matérielle du PE.
  3. Fuite de routes en environnement multicloud : Lors de l'interconnexion de liaisons cloud AWS Direct Connect ou Azure ExpressRoute, une règle erronée sur les passerelles de transit peut propager des routes par défaut hors de leur zone.

Les administrateurs peuvent vérifier l'intégrité de leurs chemins d'accès publics grâce à l'outil mon adresse IP.

Durcissement de MP-BGP et des routeurs périphériques en production

Sécuriser une architecture L3VPN exige une stricte application des politiques de filtrage sur l'ensemble des équipements PE.

Sous les systèmes d'exploitation modernes (comme FRRouting, Cisco IOS-XR et Junos), les ingénieurs définissent des seuils stricts d'annonces de préfixes. Voici un extrait de configuration FRRouting pour cloisonner une VRF et réinjecter les routes :

# Création de la VRF et assignation du port physique
ip link add dev vrf-tenant-a type vrf table 1001
ip link set dev eth2 master vrf-tenant-a
ip link set dev vrf-tenant-a up

# Configuration du moteur de routage FRR
router bgp 65001
 address-family ipv4 vpn
  neighbor 198.51.100.2 activate
 exit-address-family
 !
 router bgp 65001 vrf vrf-tenant-a
  rd 65001:100
  address-family ipv4 unicast
   route-target export 65001:100
   route-target import 65001:100
   maximum-prefix 5000 80 warning-only
  exit-address-family

Les mesures indispensables comprennent :

  • Limitation du nombre de préfixes : Utilisation de la directive maximum-prefix sur chaque session BGP cliente pour couper automatiquement les liaisons en cas de dépassement anormal.
  • Filtrage des chemins AS-path : Mise en œuvre de listes d'accès AS-path pour écarter les numéros d'AS privés ou falsifiés en provenance des réseaux clients.
  • Authentification de session TCP : Sécurisation des sessions MP-BGP internes reliant les routeurs PE avec TCP-AO (RFC 5925) ou signatures MD5 (RFC 2385) pour bloquer toute injection illicite.

Comment RiceGuard concrétise l'isolation des clients à vitesse de ligne

VPNRice déploie le moteur d'accélération RiceGuard au cœur de ses passerelles de routage internationales. Plutôt que de reposer sur des étiquettes MPLS transmises en clair sur les artères publiques, RiceGuard combine le cloisonnement logique de la RFC 4364 avec un chiffrement matériel de bout en bout.

[ Équipement client ] ---> [ Passerelle d'accès RiceGuard ]
                                       |
    +----------------------------------+----------------------------------+
    | Segmentation VRF logique et aiguillage adaptatif des flux           |
    | Marquage cryptographique interne (isolation par clés symétriques)    |
    +----------------------------------+----------------------------------+
                                       |
                     [ Réseau maillé Anycast sécurisé ]
                                       |
                                       v
                    [ Passerelle de sortie : acheminement étanche ]
  1. Compartimentation VRF cryptographique : RiceGuard lie les tunnels abonnés à des contextes de sécurité matériels isolés, garantissant une étanchéité absolue protégée par des clés éphémères distinctes.
  2. Traitement des étiquettes sans verrouillage : La classification des trames et l'évaluation des règles d'acheminement s'exécutent dans des pipelines noyau sans verrous, préservant les performances multicœurs.
  3. Protection contre l'interception de transit : À la différence des cœurs MPLS historiques acheminant les données brutes sur la fibre, RiceGuard encapsule l'intégralité du trafic inter-régions dans des liaisons WireGuard authentifiées, prévenant l'espionnage sur les liaisons publiques.

Pour assurer la confidentialité de vos échanges et bénéficier d'une connexion stable sur ordinateur et mobile, téléchargez l'application officielle.

Télécharger VPNRice.

Les concepteurs d'infrastructures de réseau peuvent approfondir leurs connaissances avec notre étude sur l'EVPN BGP multi-homing actif-actif et consulter notre dossier sur la détection rapide de pannes BFD. Par ailleurs, prenez connaissance de notre analyse sur les fenêtres anti-rejeu IPsec RFC 4303.

Liste de contrôle pour déploiements BGP L3VPN résilients

La mise en production d'une infrastructure BGP L3VPN robuste implique de valider les points clés suivants :

  • Standardisation du nommage RD et RT : Adoptez une convention stricte (comme ASN:TenantID pour le RD et ASN:ServiceProfile pour le RT) pour éviter toute collision d'attributs.
  • Application de quotas de préfixes CE : Définissez un seuil maximum-prefix strict sur chaque interface client pour préserver les ressources mémoire des routeurs PE.
  • Vérification de la connectivité LSP : Assurez-vous que les protocoles IGP et LDP/SR maintiennent des chemins commutés par étiquettes complets entre toutes les adresses de boucle des équipements PE.
  • Contrôle strict des partages Extranet : Lors de l'ouverture de services entre VRF, restreignez rigoureusement les filtres d'importation de Route Target pour exclure les routes par défaut.
  • Chiffrement du transport en environnement hybride : Sur les liaisons inter-cloud ou transitant par le réseau public, encapsulez le trafic MPLS dans des tunnels IPsec ou WireGuard afin de garantir la confidentialité des données.
  • Supervision de la stabilité du plan de contrôle : Surveillez la fréquence de rafraîchissement des routes BGP VPN-IPv4 dans Prometheus pour détecter les boucles de routage avant qu'elles n'affectent les utilisateurs.