Présentation de l’interconnexion des VPN de couche 2 avec des VPN de couche 3
Alors que les services de couche 2 basés sur MPLS augmentent de plus en plus, de nouveaux défis se posent aux fournisseurs de services pour pouvoir interagir avec les services de couche 2 et de couche 3 et offrir à leurs clients des services à valeur ajoutée. Junos OS dispose 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é Junos OS utilise un pic de tunnel pour boucler les paquets vers le moteur de transfert de paquets et 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 logique imposées par le PIC du tunnel.
Interconnexion des VPN de couche 2 avec les applications VPN de couche 3
L’interconnexion d’un VPN de couche 2 avec un VPN de couche 3 offre les avantages suivants :
Une seule ligne d’accès pour fournir plusieurs services : les VPN traditionnels sur les circuits de couche 2 nécessitent le provisionnement et la maintenance de réseaux distincts pour les services IP et VPN. En revanche, les VPN de couche 2 permettent de partager l'infrastructure réseau centrale d'un fournisseur entre les services IP et VPN de couche 2, réduisant ainsi le coût de fourniture de ces services.
Flexibilité : le fournisseur de services peut prendre en charge de nombreux types de réseaux différents. 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 localisé dans plusieurs VPN.
Large éventail de stratégies possibles : vous pouvez donner à chaque site d’un VPN un itinéraire différent par rapport à chaque autre site, ou vous pouvez forcer le trafic entre certaines paires de sites routés via un troisième site et ainsi passer certains trafics par un pare-feu.
Réseau évolutif : cette conception améliore l'évolutivité, car elle élimine le besoin de routeurs de périphérie des fournisseurs (PE) pour maintenir tous les routes VPN du fournisseur de services. Chaque routeur PE maintient une table VRF pour chacun de ses sites directement connectés. Chaque connexion client (comme un PVC de relais de trames, un ATM PVC ou un VLAN) est mappée à une table VRF spécifique. Il s’agit donc 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 prend en charge la séparation des informations de routage par VPN.
Utilisation de réflecteurs de route : les routeurs de périphérie des fournisseurs peuvent maintenir des sessions IBGP pour acheminer des réflecteurs, en alternative à 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 la maintenance de tous les routes VPN.
Plusieurs VPN sont séparés et distincts les uns des autres. Les routeurs de périphérie du client ne sont pas appairants les uns avec les autres. Deux sites ont une connectivité IP sur le réseau dorsal commun uniquement, et uniquement s’il y a 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 d’utilisation pour les clients : les clients peuvent obtenir des services dorsaux IP auprès d’un fournisseur de services, et ils n’ont pas besoin de maintenir leurs propres dorsales.