Présentation des tunnels VPN sur IP-IP de couche 3 BGP

Les services VPN traditionnels utilisent la technique de transfert MPLS basée sur les étiquettes. Certains réseaux peuvent passer d’un réseau MPLS à un réseau central de fabric IP. L’étiquette VPN n’est pas prise en charge dans le réseau central de fabric IP.

Nous introduisons la prise en charge des tunnels VPN sur IP sur IP (IP-IP) BGP de couche 3 pour créer un service de transport qui ne nécessite pas d’étiquette VPN pour identifier le VRF à la sortie PE. Cette offre permet de transporter différents types de trafic en utilisant la même infrastructure et la même topologie BGP avec des cibles de RD et de routage sur le réseau IP-IP. Les tunnels IP-IP se terminent par un VRF de couche service, vous n’avez donc pas besoin d’utiliser d’étiquette de service. Cette fonctionnalité permet l’interopérabilité entre le nouveau VRF et le VRF traditionnel, de sorte que les deux types de superpositions peuvent coexister dans votre réseau. Vous pouvez utiliser cette fonctionnalité pour passer d’un réseau MPLS à un réseau central de fabric IP et pour protéger votre réseau contre les attaques par déni de service distribué (DDoS).

Dans la figure 1, PE1 est un PE de sortie qui prend en charge à la fois les types de tunnels traditionnels et les nouveaux types de tunnels, de sorte qu’il annoncera ces deux types de tunnels dans ses routes L3VPN. PE2 est un Ingress PE qui utilise un nouveau type de tunnel pour atteindre CE1 et PE3 est un Ingress PE qui utilise un tunnel traditionnel pour atteindre CE1. Si un tunnel IP-IP est sélectionné pour transférer le trafic, l’étiquette du service d’application est ignorée et un filtre de pare-feu est utilisé pour démultiplexer le trafic. Le trafic L3VPN est décapsulé, puis effectuez une recherche de route dans le VRF tandis que le trafic IPv4/IPv6 est décapsulé, puis effectuez une recherche de route dans la table inet.0/inet6.0.

Les préfixes du système d’atténuation des menaces sont échangés via les mises à jour unicast BGP, inetvpn ou inet6vpn. Ces mises à jour BGP portent des attributs d’encapsulation de tunnel. Le BGP L3VPN sépare le préfixe d’atténuation des menaces des routes Internet et n’affecte pas la sélection du meilleur chemin de la route Internet, minimisant ainsi la probabilité de formation d’une boucle de routage. Dans Junos OS 20.3R1 et versions ultérieures, vous pouvez choisir d’utiliser VPN sur transport MPLS ou de basculer vers un tunnel IP sur IP en fonction de l’attribut tunnel. Si le routeur récepteur s’exécute sous Junos OS 20.2 ou des versions antérieures, l’attribut de chemin est ignoré et utilise le service de transport MPLS traditionnel.

Pour utiliser un VPN sur un tunnel IP-IP, vous devez configurer un attribut tunnel. Lorsque les routes sont annoncées directement à partir de la table VRF, vous pouvez utiliser une stratégie d’exportation BGP ou VRF pour attacher l’attribut tunnel. Lorsque l’instruction advertise-from-main-vpn-tables est activée, ou lorsque l’équipement agit en tant que réflecteur de route ou routeur de limite AS, vous devez attacher l’attribut tunnel à l’aide d’une stratégie d’exportation BGP sous BGP.

Vous pouvez configurer le récepteur pour qu’il programme le tunnel dynamique à l’aide de l’attribut tunnel afin d’activer l’attribut tunnel sur les homologues BGP approuvés. Le réflecteur de route est capable de refléter l’itinéraire avec l’attribut tunnel même si celui-ci n’est pas configuré.