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

• Tunnels basés sur l’interface (gr, lt et ip) : vous pouvez configurer des tunnels basés sur une interface 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 une interface pour 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 redirigé vers le même moteur de transfert de paquets pour une deuxième recherche. Le paquet réintroduit dans le pipeline entrant via l’interface de bouclage, qui dispose d’une bande passante limitée à 400G. Le paquet encapsulé est ensuite transféré à la destination.

  La déencapsulation des tunnels GRE est implémentée par terminaison de tunnel inline et n’utilise pas le flux de bouclage. Toutefois, les performances globales des paquets du moteur de transfert de paquets sont affectées par des sauts de fabric supplémentaires lorsque le flux de trafic passe 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 implémenter :

  • 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 du bouclage, les performances des paquets sont réduites en raison de la recherche supplémentaire après une encapsulation ou une déencapsulation.

• 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éencapsulation 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’encapsulation et l’encapsulation 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 ont lieu au niveau du moteur de transfert de paquets, qui traite le filtre. Les routeurs MX Series prennent en charge les filtres de pare-feu dans les domaines suivants :

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

  • Niveau de l’interface à la sortie (exécutée sur le moteur de transfert de paquets de sortie)

  • Au niveau de la table de transfert (avant ou après la recherche de route). 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 encapsulation. En cas de déencapsulation, les performances des paquets sont réduites en raison de la configuration du filtre.

Interfaces de tunnel sur PTX10001-36MR, PTX10004, PTX10008 et PTX10016 Présentation

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 les tunnels basés sur FTI pour implémenter :

  • 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éencapsulation GRE, UDP ET IP-IP. La réduction des performances des paquets dépend de l’option d’encapsulation. L’encapsulation prend en charge une 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 [edit interfaces fti0 unit unit-number family (inet | inet6)] hiérarchie, les tunnels sont terminés sur l’interface WAN avant que toute autre action, telle que l’échantillonnage, la mise en miroir des ports ou le filtrage, ne soit appliquée.

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

  Sur un FTI, après encapsulation du tunnel, le trafic est envoyé dans l’interface de bouclage (sur le moteur de transfert de paquets entrant) et plus tard vers la destination finale. Les destinations peuvent inclure celles qui se cachent derrière les prochains sauts SR-TE (Segment Routing-Traffic Engineered). 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 de 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 permet au tunnel-termination tunnel de décapsuler le tunnel uniquement 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 de variable sur l’adresse source n’est pas autorisée

    Lorsque vous configurez un filtre de pare-feu pour la déencapsulation, le filtre frewall déencapsule les paquets en fonction des conditions de correspondance et de l’action configurées. Ensuite, les paquets désencapsulés sont recirculés dans le bloc entrant pour effectuer une recherche d’en-tête interne, puis transférés en conséquence. Cependant, la terminaison du tunnel est effectuée en un seul passage de traitement des paquets, ce qui améliore les performances par rapport au processus basé sur des filtres.

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

    L’adresse source peut être exclue, ce qui indique que le tunnel se termine à l’adresse de destination configurée. La facultative tunnel-routing-instance indique qu’après la déencapsulation, la recherche 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, plus besoin de recherche de source 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 arrêté.

    Lorsque vous activez l’instruction tunnel-termination 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 des ports ou le filtrage, ne soit appliquée.

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

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

  • Fabrics IP.

  • 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éencapsulation. À la place, vous pouvez utiliser des tunnels FTI statiques pour la déencapsulation, sans spécifier l’adresse de destination. Les tunnels sont configurés avec l’option de déencapsulation 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 les sauts suivants pour résoudre la route de destination du tunnel. Vous pouvez également utiliser le contrôle des stratégies 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-over-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 une fabric IP. Nous préférons cette option lorsque nous devons atteindre des destinations de tunnel via IP. Ces tunnels prennent en charge :

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

  • Options de déencapsulation 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 pendant 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 pendant l’encapsulation en raison de la recherche supplémentaire.

Mise en miroir des 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 diffusion pas de paquets vers tous les ports de l’équipement de destination. La mise en miroir des ports envoie des copies de tous les paquets ou échantillons 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 PE (Provider Edge) à 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 des ports 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 périphériques client (CE), 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 saut suivant, définissez un filtre de pare-feu qui référence le groupe de saut suivant 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.

Voir 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 basé sur une interface de tunnel flexible (FTI), le routeur envoie le paquet de sortie avec l’encapsulation du tunnel. Vous pouvez configurer une configuration qui met en miroir le paquet d’origine ainsi que le paquet avec toutes les encapsulations à la sortie de l’interface.

Pour activer la mise en miroir basée sur un filtre installé sur le FTI :

• Vous marquez les paquets pour la mise en miroir à l’aide de l’action de stratégie au 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.

• Vous demandez au logiciel d’intercepter les paquets qui correspondent à la stratégie spécifique du côté du WAN de sortie et de lancer 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 des 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. Les technologies de transport overlay telles que MPLS-over-GRE ou MPLS-over-UDP font partie de la conception d’un datacenter. Les routes hôtes sont communiquées à la passerelle du datacenter à partir du contrôleur SDN et importées dans des contextes VRF (Virtual Routing and Forwarding) ou Internet. Les serveurs du centre de données sont accessibles via des tunnels dynamiques basés sur le saut suivant. Des tunnels sont établis sur les serveurs dans le cadre du processus de résolution de saut suivant du protocole de routage BGP.

Comme décrit dans la norme RFC 5549, le trafic IPv4 est tunnelisé des appareils CPE vers les passerelles IPv4 sur IPv6. Ces passerelles sont annoncées aux équipements CPE par le biais d’adresses anycast. Les passerelles créent ensuite des tunnels IPv4 sur IPv6 dynamiques vers des équipements CPE distants et annoncent des routes agrégées 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 un protocole BGP interne (IBGP) à des routeurs de passerelle, qui annoncent les adresses IPv4 des routes hôtes avec les adresses IPv6 comme saut suivant.

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

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

   Les attributs de saut suivant composite de tunnel sont les suivants :

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

   • Lorsque l’attribution d’étiquettes VPN composites de type VPN de couche 3 et par préfixe est activée : 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’étiquettes 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’instance VRF avec une route secondaire.

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

3. Une fois que le saut suivant de protocole est résolu sur le saut suivant composite de tunnel, des sauts suivants indirects avec transfert de sauts suivants sont créés.

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

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