Configuration des interfaces de tunnel sur les routeurs MX Series et les routeurs PTX Series

• Tunnels basés sur des interfaces (gr-, lt et ip-) : vous pouvez configurer des tunnels basés sur des interfaces lorsque l’application du profil de bande passante est requise.Les tunnels GRE prennent en charge les charges utiles IPv4, IPv6, MPLS, ISO et Ethernet, tandis que les tunnels IP-IP prennent en charge les charges utiles IPv4 et IPv6.

  Vous pouvez configurer des tunnels basés sur des interfaces afin d’implémenter :

  • Tunnelisation sur un réseau IP avec application de la bande passante par tunnel. Par exemple, vers un site distant.

  • Direction pour le nettoyage DDoS.

  • Mise en miroir vers des destinations distantes.

  Au cours du processus GRE, une fois l’en-tête GRE ajouté au paquet, le paquet est renvoyé au même moteur de transfert de paquets pour une deuxième recherche. Le paquet entre dans le pipeline entrant via l’interface de bouclage, qui a une bande passante limitée à 400G. Le paquet encapsulé est ensuite transmis à la destination.

  La désencapsulation du tunnel GRE est implémentée par une terminaison de tunnel en ligne et n’utilise pas le flux de bouclage. Toutefois, les performances globales du moteur de transfert de paquets sont affectées en raison des sauts supplémentaires de la structure lorsque le flux de trafic bascule d’un moteur de transfert de paquets à un autre.

• Interfaces de tunnel flexibles (FTI) : vous pouvez configurer des FTI lorsque l’application du profil de bande passante n’est pas requise. Les FTI prennent en charge les charges utiles IPv4 et IPv6. Vous pouvez configurer les FTI pour mettre en uvre :

  • Mise en miroir vers des destinations distantes.

  • Fabrics IP avec superpositions IP-IP.

  • Direction pour le nettoyage DDoS.

  Les performances des paquets sont réduites en raison de la recherche supplémentaire après l’encapsulation et la désencapsulation.

• Tunnels dynamiques : vous pouvez configurer des tunnels dynamiques pour concevoir des passerelles de centre de données.

  Dans l’implémentation de tunnels dynamiques avec évitement de bouclage, les performances des paquets sont réduites en raison de la recherche supplémentaire après une encapsulation ou une désencapsulation.

• Tunnels basés sur des filtres de pare-feu : ces tunnels prennent en charge :

  • GRE et GRE dans l’encapsulation UDP.

  • GRE, IP-IP et GRE dans la désencapsulation UDP.

  Vous pouvez configurer des tunnels basés sur des filtres de pare-feu pour concevoir des passerelles de centre de données.

  Vous pouvez configurer l’encapsualtion et la désencapsulation basées sur GRE à l’aide d’une action de filtre de pare-feu sans utiliser d’interface de tunnel. L’encapsulation et la désencapsulation se produisent au niveau du moteur de transfert de paquets qui traite le filtre. Les routeurs MX Series prennent en charge les filtres de pare-feu au niveau :

  • Niveau d’interface en entrée (exécuté sur le moteur de transfert de paquets entrant)

  • Niveau d’interface en sortie (exécuté sur le moteur de transfert de paquets sortant)

  • Niveau de la table de transfert (soit avant la recherche d’itinéraire, soit après la recherche d’itinéraire). Dans les deux cas, le filtre est exécuté sur le PFE d’entrée

  Dans ce scénario, les performances des paquets sont réduites en raison de la recherche supplémentaire après l’encapsulation. En cas de désencapsulation, les performances des paquets sont réduites en raison de la configuration du filtre.

Vue d’ensemble des interfaces de tunnel sur les PTX10001-36MR, PTX10004, PTX10008 et PTX10016

Cette section fournit des informations sur la configuration des interfaces de tunnel pour implémenter différentes fonctionnalités sur les routeurs PTX10001-36MR, PTX10004, PTX10008 et PTX10016 avec Junos OS Evolved.

• Interfaces de tunnel flexibles (FTI) : vous pouvez configurer des tunnels FTI pour mettre en uvre :

  • Direction pour le nettoyage DDoS.

  • Dé-encapsulation pour tous les cas d’usage de tunnels dynamiques.

  Ces tunnels prennent en charge les options d’encapsulation et de désencapsulation GRE, UDP et IP-IP. La réduction des performances des paquets dépend de l’option d’encapsulation. L’encapsulation prend en charge la topologie de saut suivant aplatie.

  Vous pouvez configurer les tunnels GRE sur des interfaces de tunnel flexibles. Lorsque vous activez l’instruction tunnel-termination au niveau de la hiérarchie, les tunnels sont arrêtés sur l’interface WAN avant que toute autre action, telle que l’échantillonnage, la mise en miroir des ports ou le [edit interfaces fti0 unit unit-number family (inet | inet6)] filtrage, ne soit appliquée.

• Interfaces de tunnel flexibles (FTI) via un bouclage : vous pouvez configurer les FTI pour mettre en œuvre la mise en miroir vers des destinations distantes.

  Sur un FTI, après l’encapsulation du tunnel, le trafic est envoyé dans l’interface de bouclage (sur le moteur de transfert de paquets entrant) et ultérieurement vers la destination finale. Les destinations peuvent inclure les personnes à l’origine des sauts suivants SR-TE (Segment Routing–Traffic Engineering). L’interface de bouclage a une bande passante limitée à 400G.

  Vous pouvez configurer l’encapsulation de tunnel GRE/IP-in-IP/UDP sur les FTI à l’aide de l’interface de bouclage. Vous pouvez configurer l’encapsulation à l’aide de la commande tunnel encapsulation (gre|ipip|udp) source address destination address dans la [edit interfaces fti0 unit unit-number hiérarchie. Vous devez tenir compte des points suivants lors de la configuration de cette fonctionnalité :

  • L’ajout tunnel-termination rend le tunnel de décapssement uniquement du tunnel et l’encapsulation est désactivée.

  • La spécification de l’adresse source et de l’adresse de destination est obligatoire lorsque vous ne configurez pas la commande.

  • La configuration d’un masque de préfixe variable sur l’adresse source n’est pas autorisée

    Lorsque vous configurez un filtre de pare-feu pour la désencapsulation, le filtre Frewall désencapsule les paquets en fonction des conditions de correspondance et de l’action configurées. Ensuite, les paquets désencapsulés sont remis en circulation vers le bloc d’entrée pour effectuer une recherche d’en-tête interne et transférés en conséquence. Cependant, la terminaison du tunnel s’effectue en une seule passe de traitement des paquets, ce qui améliore les performances par rapport aux processus basés sur des filtres.

    Pour activer le mode de terminaison uniquement, où le tunnel est unidirectionnel, vous pouvez configurer tunnel-termination au niveau de la [edit interfaces fti0 unit unit_number tunnel encapsulation (gre|ipip|udp)]hiérarchie sur la FTI.

    L’adresse source peut être exclue, ce qui indique que le tunnel se termine à l’adresse de destination configurée. L’option tunnel-routing-instance indique qu’après la désencapsulation, la recherche d’adresse IP interne est effectuée avec l’ID VRF correspondant à l’instance de routage.

    Les paquets à désencapsuler sont traités dans l’unité de recherche source. La clé de recherche contient l’adresse de destination IPv4 ou IPv6 et, éventuellement, l’adresse L3VPN si le tunnel n’a pas besoin d’être terminé sur toutes les interfaces. Si la première recherche réussit, aucune autre recherche de source n’est nécessaire et le tunnel est terminé. Si une deuxième recherche est nécessaire sur l’adresse source, l’unité de recherche source effectue une autre recherche en utilisant l’adresse source et le résultat de la première recherche comme clé. Si la deuxième recherche réussit, le tunnel est terminé.

    Lorsque vous activez l’instruction de terminaison de tunnel dans la hiérarchie [edit interfaces fti0 unit unit-number], les tunnels sont arrêtés sur l’interface WAN avant que toute autre action, telle que l’échantillonnage, la mise en miroir de ports ou le filtrage, ne soit appliquée.

    Pour activer la terminaison de tunnel sur l’interface entrante, configurez à la commande tunnel-termination[edit interfaces et fpc/pic/port unit unit_number]

• Tunnels dynamiques : vous pouvez configurer des tunnels dynamiques pour concevoir :

  • Fabrics IP.

  • les superpositions IP.

  • Passerelles de datacenter.

  Ces tunnels prennent en charge l’encapsulation IP-IP.

  Les routeurs PTX Series avec Junos OS Evolved ne prennent pas en charge les tunnels dynamiques pour la désencapsulation. Au lieu de cela, vous pouvez utiliser des tunnels FTI statiques pour la désencapsulation, sans spécifier l’adresse de destination. Les tunnels sont configurés avec l’option de désencapsulation uniquement.

  Vous pouvez configurer des tunnels UDP dynamiques basés sur le saut suivant, également appelés tunnels MPLS sur UDP. Junos OS crée dynamiquement des sauts suivants pour résoudre l’itinéraire de destination du tunnel. Vous pouvez également utiliser le contrôle de stratégie pour résoudre les tunnels MPLS sur UDP sur certains préfixes IP. En effet, lorsque les sauts suivants sont activés par défaut, la fonctionnalité MPLS sur UDP offre un avantage d’évolutivité pour le nombre de tunnels IP pris en charge sur le routeur.

Interfaces de tunnel sur les PTX1000, PTX5000 et PTX10002-50C - Présentation

Cette section fournit des informations sur la configuration des interfaces de tunnel pour implémenter différentes fonctionnalités sur les routeurs PTX1000, PTX5000 et PTX10002-50C avec Junos OS Evolved.

• Interfaces de tunnel flexibles (FTI) : vous pouvez configurer les FTI pour implémenter la structure IP. Nous préférons cette option lorsque nous avons besoin d’atteindre des destinations de tunnel via IP. Ces tunnels prennent en charge :

  • Options d’encapsulation GRE, UDP et IP-IP.

  • Options de désencapsulation UDP et IP-IP.

  Les performances des paquets sont réduites en raison de la recherche supplémentaire après l’encapsulation et la désencapsulation.

• Tunnels dynamiques : vous pouvez configurer des tunnels dynamiques pour concevoir une passerelle de centre de données. Les performances des paquets sont réduites en raison d’une recherche supplémentaire après l’encapsulation et la désencapsulation.

• Tunnels basés sur des filtres de pare-feu : vous pouvez configurer des tunnels basés sur des filtres de pare-feu pour implémenter l’ingénierie d’appairage de sortie (EPE). Les performances des paquets sont réduites lors de l’encapsulation en raison de la recherche supplémentaire.

• Mise en miroir vers une destination distante : vous pouvez implémenter la tunnelisation des paquets mis en miroir vers des destinations distantes. Les performances des paquets sont réduites lors de l’encapsulation en raison de la recherche supplémentaire.

Mise en miroir de ports vers des destinations distantes

Vous pouvez utiliser la mise en miroir des ports pour analyser le trafic sur les routeurs et commutateurs qui, contrairement aux concentrateurs, ne diffusent pas de paquets sur tous les ports de l’équipement de destination. La mise en miroir de ports envoie des copies de tous les paquets ou des exemples de paquets basés sur des stratégies à des analyseurs locaux ou distants où vous pouvez surveiller et analyser les données.

Pour un routeur MX Series configuré en tant que routeur Provider Edge (PE) sur la périphérie client d’un réseau de fournisseur de services, vous pouvez appliquer un filtre de pare-feu de mise en miroir de port de couche 2 aux points d’entrée et de sortie pour refléter le trafic entre le routeur MX Series et les périphériques CE (Customer Edge), tels que les routeurs et les commutateurs Ethernet.

Sur les routeurs MX Series, vous pouvez mettre en miroir le trafic arrivant aux interfaces de tunnel vers plusieurs destinations. Vous spécifiez deux destinations ou plus dans un groupe de sauts suivants, définissez un filtre de pare-feu qui référence le groupe de sauts suivants en tant qu’action de filtre, puis appliquez le filtre à une interface de tunnel logique (lt-) ou à des interfaces de tunnel virtuel (vt-) sur le routeur MX Series.

Reportez-vous aux sections Configuration de la mise en miroir des ports et Configuration de la mise en miroir des ports pour les destinations distantes.

Lorsque le chemin de données traverse un tunnel FTI (Flexible Tunnel Interface), le routeur envoie le paquet de sortie avec l’encapsulation du tunnel. Vous pouvez configurer une configuration qui reflète le paquet d’origine ainsi que le paquet avec toutes les encapsulations à sa sortie de l’interface.

Pour activer la mise en miroir en fonction d’un filtre installé sur le FTI :

• Vous marquez les paquets pour la mise en miroir à l’aide de l’action de stratégie au niveau de la FTI. Le routeur utilise généralement l’action de stratégie pour sélectionner la règle de réécriture de sortie, mais dans ce cas, il utilise l’action de stratégie pour marquer les paquets intéressants avec un attribut de stratégie interne, sans qu’aucune règle de réécriture spéciale ne soit configurée.

• Le logiciel intercepte les paquets qui correspondent à la stratégie spécifique côté WAN de sortie et lance l’action l2-mirror . Les paquets sont signalés avec des informations d’en-tête de couche 2, y compris l’encapsulation du tunnel.

  Voir Exemple : Configuration de la mise en miroir des ports locaux sur les routeurs PTXExemple : Configuration de la mise en miroir des ports locaux sur les routeurs PTX et Exemple : Configuration de la mise en miroir de ports distants sur les routeurs PTX.

Passerelles de datacenter

Les passerelles de centre de données interconnectent Internet ou les VPN d’entreprise d’un côté et les machines virtuelles hébergées sur des serveurs de l’autre côté. Les technologies de transport superposé (MPLS-sur-GRE ou MPLS-sur-UDP) sont intégrées à la conception d’un centre de données. Les routes hôtes sont communiquées à la passerelle de centre de données à partir du contrôleur SDN et importées dans des contextes de routage et de transfert virtuels (VRF) ou de routage Internet. Les serveurs du centre de données sont accessibles via des tunnels dynamiques basés sur les sauts suivants. Les tunnels sont établis sur les serveurs dans le processus de résolution du prochain saut du protocole de routage BGP.

Comme décrit dans la RFC 5549, le trafic IPv4 est tunnelisé depuis les équipements CPE vers les passerelles IPv4 sur IPv6. Ces passerelles sont annoncées aux appareils CPE par le biais d’adresses anycast. Les périphériques de passerelle créent ensuite des tunnels IPv4 sur IPv6 dynamiques vers les équipements CPE distants et annoncent les routes d’agrégation IPv4 pour orienter le trafic. Des réflecteurs de route avec des interfaces programmables injectent les informations du tunnel dans le réseau. Les réflecteurs de route sont connectés via BGP interne (IBGP) aux routeurs de passerelle, qui annoncent les adresses IPv4 des routes hôtes avec des adresses IPv6 comme prochain saut.

Le tunnel MPLS sur UDP est géré comme suit :

1. Une fois qu’un tunnel MPLS sur UDP est configuré, un itinéraire de masque de destination de tunnel avec un tronçon suivant composite de tunnel est créé pour le tunnel dans la table de routage inet.3. Cette route de tunnel IP n’est supprimée que lorsque la configuration du tunnel dynamique est supprimée.

   Les attributs next-hop composites du tunnel sont les suivants :

   • Lorsque le saut suivant composite VPN de couche 3 est désactivé : adresse source et de destination, chaîne d’encapsulation et étiquette VPN.

   • Lorsque le saut suivant composite VPN de couche 3 et l’attribution d’étiquettes VPN par préfixe sont activés : adresse source, adresse de destination et chaîne d’encapsulation.

   • Lorsque le saut suivant composite VPN de couche 3 est activé et que l’attribution d’étiquette VPN par préfixe est désactivée : adresse source, adresse de destination et chaîne d’encapsulation. Dans ce cas, la route est ajoutée à l’autre table d’instances VRF avec une route secondaire.

2. Les équipements PE (Provider Edge) sont interconnectés via une session IBGP. Le tronçon suivant de la route IBGP vers un voisin BGP distant est le tronçon suivant du protocole, qui est résolu à l’aide de la route du masque de tunnel avec le tronçon suivant du tunnel.

3. Une fois que le tronçon suivant du protocole est résolu sur le tronçon suivant composite du tunnel, des tronçons suivants indirects avec transfert de tronçons suivants sont créés.

4. Le prochain saut composite du tunnel est utilisé pour transférer les sauts suivants des sauts suivants indirects.

Voir Exemple : Configuration de tunnels dynamiques MPLS-sur-UDP basés sur le saut suivant et Exemple : Configuration de tunnels dynamiques IP-sur-IP basés sur le saut suivant