Présentation de l’interconnexion des VPN de couche 2 avec des VPN de couche 3
À mesure que la demande de services de couche 2 basés sur MPLS augmente, de nouveaux défis se posent aux fournisseurs de services qui doivent être en mesure d’interagir avec les services de couche 2 et de couche 3 et de fournir à leurs clients des services à valeur ajoutée. Junos OS possède diverses fonctionnalités pour répondre aux besoins des fournisseurs de services. L’une de ces fonctionnalités est l’utilisation d’une interface de tunnel logique. Cette fonctionnalité de Junos OS utilise un PIC de tunnel pour boucler les paquets depuis et depuis le moteur de transfert de paquets afin de relier le réseau de couche 2 au réseau de couche 3. La solution est limitée par les contraintes de bande passante du tunnel imposées par le PIC de tunnel.
Interconnexion des VPN de couche 2 avec des applications VPN de couche 3
L’interconnexion d’un VPN de couche 2 avec un VPN de couche 3 offre les avantages suivants :
Une ligne d’accès unique pour fournir plusieurs services : les VPN traditionnels sur circuit de couche 2 nécessitent de provisionner et de maintenir des réseaux distincts pour les services IP et pour les services VPN. En revanche, les VPN de couche 2 permettent de partager l'infrastructure réseau centrale d'un fournisseur entre les services IP et les services VPN de couche 2, réduisant ainsi le coût de fourniture de ces services.
Flexibilité : de nombreux types de réseaux peuvent être pris en charge par le fournisseur de services. Si tous les sites d’un VPN appartiennent à la même entreprise, il s’agit d’un intranet. Si plusieurs sites appartiennent à différentes entreprises, le VPN est un extranet. Un site peut être situé dans plusieurs VPN.
Large éventail de stratégies possibles : vous pouvez donner à chaque site d’un VPN un itinéraire différent vers tous les autres sites, ou vous pouvez forcer le trafic entre certaines paires de sites acheminés via un troisième site et ainsi faire passer une partie du trafic à travers un pare-feu.
Réseau évolutif : cette conception améliore l'évolutivité car elle élimine la nécessité pour les routeurs PE (Provider Edge) de gérer toutes les routes VPN du fournisseur de services. Chaque routeur PE gère une table VRF pour chacun de ses sites directement connectés. Chaque connexion client est mappée à une table VRF spécifique. Ainsi, il s’agit d’un port sur le routeur PE et non d’un site associé à une table VRF. Plusieurs ports d’un routeur PE peuvent être associés à une seule table VRF. C’est la capacité des routeurs PE à gérer plusieurs tables de transfert qui permet de séparer les informations de routage par VPN.
Utilisation de réflecteurs de route : les routeurs de périphérie des fournisseurs peuvent gérer des sessions IBGP pour router des réflecteurs au lieu d’un maillage complet de sessions IBGP. Le déploiement de plusieurs réflecteurs de route améliore l’évolutivité du modèle RFC 2547bis, car il élimine le besoin d’un seul composant réseau pour gérer toutes les routes VPN.
Plusieurs VPN restent séparés les uns des autres : les routeurs de périphérie client ne s’appairent pas. Deux sites ont une connectivité IP sur la dorsale commune uniquement, et seulement s’il existe un VPN qui contient les deux sites. Cette fonctionnalité maintient les VPN séparés et distincts les uns des autres, même si deux VPN ont un espace d’adressage qui se chevauche.
Simple à utiliser : les clients peuvent obtenir des services de dorsale IP auprès d’un fournisseur de services sans avoir à entretenir leurs propres dorsales.