Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Encapsulation de routage générique (GRE)

En savoir plus sur GRE, la tunnelisation GRE, l’encapsulation et la déencapsulation, et la configuration de GRE.

L’encapsulation de routage générique (GRE) est une liaison virtuelle point à point qui encapsule le trafic de données dans un tunnel. Les rubriques ci-dessous traitent de la tunnelisation des GRE, du processus d’encapsulation et de décapsulation, de la configuration des GRE et de la vérification du fonctionnement des GRE.

Présentation du GRE

GRE fournit un chemin privé pour le transport des paquets via un réseau autrement public en encapsulant (ou en créant une tunnelisation) des paquets.

GRE encapsule les paquets de données et les redirige vers un périphérique qui les déencapsule et les achemine jusqu’à leur destination finale. Cela permet aux commutateurs source et de destination de fonctionner comme s’ils avaient une connexion point à point virtuelle l’un avec l’autre (car l’en-tête externe appliqué par GRE est transparent pour le paquet de charge utile encapsulé). Par exemple, les tunnels GRE permettent à des protocoles de routage tels que RIP et OSPF de transférer des paquets de données d’un commutateur à un autre sur Internet. En outre, les tunnels GRE peuvent encapsuler des flux de données multicast pour les transmettre sur Internet.

Le GRE est décrit dans la RFC 2784 (anciennes RFC 1701 et 1702 obsolètes). Les commutateurs prennent en charge la norme RFC 2784, mais pas complètement.

En tant que routeur source de tunnel, le commutateur encapsule un paquet de charge utile que le transport via le tunnel vers un réseau de destination. Le paquet de la charge utile est d’abord encapsulé dans un paquet GRE, puis le paquet GRE est encapsulé dans un protocole de livraison. Le commutateur jouant le rôle d’un routeur distant à base de tunnel extrait le paquet tunnelisé et le transmet à sa destination. Notez que vous pouvez utiliser un terme de pare-feu pour mettre fin à plusieurs tunnels GRE sur un commutateur QFX5100.

Consultez la section Comportement GRE spécifique à la plate-forme pour obtenir des notes relatives à votre plateforme.

Tunnelisation GRE

Les données sont acheminées par le système vers le point de terminaison GRE via des routes établies dans la table de routage. (Ces routes peuvent être configurées de manière statique ou apprises dynamiquement par des protocoles de routage tels que RIP ou OSPF.) Lorsqu’un paquet de données est reçu par le point de terminaison GRE, il est déencapsulé et acheminé à nouveau vers son adresse de destination.

Les tunnels GRE sont sans état, c’est-à-dire que le point de terminaison du tunnel ne contient aucune information sur l’état ou la disponibilité du point de terminaison du tunnel distant. Par conséquent, le commutateur fonctionnant comme un routeur source de tunnel ne peut pas modifier l’état de l’interface de tunnel GRE sur down si le point de terminaison distant est inaccessible.

Pour plus de détails sur la tunnelisation GRE, consultez :

Encapsulation et déencapsulation sur le commutateur

Encapsulation : un commutateur fonctionnant comme un routeur source de tunnel encapsule et transfère les paquets GRE comme suit :

  1. Lorsqu’un commutateur reçoit un paquet de données (charge utile) à tunneliser, il envoie le paquet à l’interface du tunnel.

  2. L’interface de tunnel encapsule les données dans un paquet GRE et ajoute un en-tête IP externe.

  3. Le paquet IP est transféré sur la base de l’adresse de destination dans l’en-tête IP externe.

Déencapsulation : un commutateur fonctionnant comme un routeur distant de tunnel gère les paquets GRE comme suit :

  1. Lorsque le commutateur de destination reçoit le paquet IP de l’interface de tunnel, l’en-tête IP externe et l’en-tête GRE sont supprimés.

  2. Le paquet est routé en fonction de l’en-tête IP interne.

Classe de service sur les tunnels GRE

Lorsqu’un réseau subit une congestion et des retards, certains paquets peuvent être perdus. La classe de service (CoS) de Junos OS divise le trafic en classes auxquelles vous pouvez appliquer différents niveaux de débit et de perte de paquets en cas de congestion et ainsi définir des règles de perte de paquets. Pour plus de détails sur le CoS, voir Présentation du CoS de Junos OS pour les commutateurs EX Series.

Les composants CoS suivants sont disponibles sur un commutateur fonctionnant en tant que routeur source GRE tunnel ou GRE tunnel routeur distant :

  • À la source du tunnel GRE : sur un commutateur fonctionnant comme un routeur source de tunnel, vous pouvez appliquer des classificateurs CoS sur un port entrant ou sur un port GRE, avec les résultats suivants sur la prise en charge des composants CoS sur les paquets tunnelisés :

    • Planificateurs uniquement : en vous basant sur la classification CoS du port entrant, vous pouvez appliquer des planificateurs CoS sur un port GRE du commutateur pour définir des files d’attente de sortie et contrôler la transmission des paquets via le tunnel après l’encapsulation GRE. Toutefois, vous ne pouvez pas appliquer de règles de réécriture CoS à ces paquets.

    • Planificateurs et règles de réécriture : selon la classification CoS sur le port GRE, vous pouvez appliquer des planificateurs et des règles de réécriture aux paquets encapsulés transmis via le tunnel.

    Vous ne pouvez pas configurer les classificateurs BA sur gr- les interfaces. Vous devez classer le trafic sur gr- les interfaces à l’aide de filtres de pare-feu (classificateurs multichamps).

  • Au point de terminaison du tunnel GRE : lorsque le commutateur est un routeur distant du tunnel, vous pouvez appliquer des classificateurs CoS sur le port GRE et les planificateurs. Vous pouvez également réécrire des règles sur le port de sortie pour contrôler la transmission d’un paquet GRE déencapsulé à partir du port de sortie.

Application de filtres de pare-feu au trafic GRE

Les filtres de pare-feu fournissent des règles qui définissent s’il faut autoriser, refuser ou transférer les paquets qui transitent par une interface sur un commutateur. (Pour plus de détails, voir Présentation des filtres de pare-feu pour les commutateurs EX Series.) En raison de l’encapsulation et de la désencapsulation effectuées par GRE, vous êtes limité quant à l’endroit où appliquer un filtre de pare-feu pour filtrer les paquets tunnelisés et quel en-tête sera affecté. Le Tableau 1 identifie ces contraintes.

Tableau 1 : points d’application du filtre de pare-feu pour les paquets tunnelisés
Type de point de terminaison Interface entrante Interface de sortie

Source (encapsulation)

En-tête intérieur

En-tête extérieur

Distant (déencapsulation)

Impossible de filtrer les paquets sur l’interface entrante

En-tête intérieur

Utiliser un filtre de pare-feu pour déencapsuler le trafic GRE

Vous pouvez également utiliser un filtre de pare-feu pour déencapsuler le trafic GRE sur les commutateurs. Cette fonctionnalité offre des avantages significatifs en termes d'évolutivité, de performances et de flexibilité, car vous n'avez pas besoin de créer une interface de tunnel pour effectuer la déencapsulation. Par exemple, vous pouvez résilier plusieurs tunnels à partir de plusieurs adresses IP sources avec un seul terme de pare-feu. Voir Configuration d’un filtre de pare-feu pour déencapsuler le trafic GRE pour plus d’informations sur la configuration d’un filtre de pare-feu à cette fin.

Configurer la tunnelisation GRE (Generic Routing Encapsulation)

L’encapsulation de routage générique (GRE) fournit un chemin privé pour le transport des paquets via un réseau autrement public en encapsulant (ou en tunnelisant) les paquets. La tunnelisation GRE est réalisée par le biais de points de terminaison de tunnel qui encapsulent ou déencapsulent le trafic.

Utilisez GRE pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

Vous pouvez également utiliser un filtre de pare-feu pour déencapsuler le trafic GRE. Cette fonctionnalité offre des avantages significatifs en termes d'évolutivité, de performances et de flexibilité, car vous n'avez pas besoin de créer une interface de tunnel pour effectuer la déencapsulation. Par exemple, vous pouvez résilier plusieurs tunnels à partir de plusieurs adresses IP sources avec un seul terme de pare-feu. Pour plus d’informations sur cette fonctionnalité, consultez Configuration d’un filtre de pare-feu pour déencapsuler le trafic GRE.

Pour configurer un port de tunnel GRE sur un commutateur :

  1. Déterminez le port réseau ou le port de liaison montante de votre commutateur à convertir en port de tunnel GRE.

  2. Configurez le port en tant que port de tunnel pour les services de tunnel GRE :

Pour QFX10000, l’interface gr-0/0/0 est créée par défaut. De plus, vous n’avez pas besoin de configurer l’instruction set fpc slot pic pic-number tunnel-port port-number tunnel-services.

Cette rubrique décrit :

Configurer un tunnel GRE

Pour configurer une interface de tunnel GRE :

  1. Créez une interface GRE avec un numéro d’unité et une adresse :

    Le nom de base de l’interface doit être gr-0/0/0.

    Il s’agit d’une pseudo-interface, et l’adresse que vous spécifiez peut être n’importe quelle adresse IP. La table de routage doit spécifier gr-0/0/0.x comme interface sortante tous les paquets qui seront tunnelisés.

    Si vous configurez une interface GRE sur un commutateur QFX5100 membre d’un Virtual Chassis et que vous modifiez ultérieurement le numéro de membre Virtual Chassis du commutateur, le nom de l’interface GRE ne change en aucune façon (car il s’agit d’une pseudo-interface). Par exemple, si vous modifiez le numéro de membre de 0 à 5, le nom de l’interface GRE ne passe pas de gr-0/0/0.x à gr-5/0/0.x.

  2. Spécifiez l’adresse source du tunnel pour l’interface logique :
  3. Spécifiez l’adresse de destination :

    L’adresse de destination doit être accessible via un routage statique ou dynamique. Si vous utilisez le routage statique, vous devez obtenir l’adresse MAC de destination (par exemple, à l’aide de ping) avant que le trafic utilisateur puisse être transféré dans le tunnel.

Sur les commutateurs QFX10002 et QFX10008, si vous configurez la tunnelisation GRE avec le saut suivant ECMP sous-jacent au lieu du saut suivant unicast, l’encapsulation du tunnel GRE échoue et le trafic réseau est abandonné.

Les sauts suivants de sortie indirecte ne sont actuellement pas pris en charge dans l’implémentation GRE pour les commutateurs QFX10000.

Vérifiez que le tunneling d’encapsulation de routage générique fonctionne correctement

But

Vérifiez que l’interface GRE (Generic Routing Encapsulation) envoie du trafic tunnelisé.

Action

Affichez les informations d’état de l’interface GRE spécifiée à l’aide de la commande show interfaces .

Signification

La sortie indique que l’interface GRE gr-0/0/0 est active. La sortie affiche le nom de l’interface physique et les statistiques de trafic de cette interface---le nombre et la vitesse à laquelle les octets d’entrée et de sortie et les paquets sont reçus et transmis sur l’interface physique.

Comportement GRE spécifique à la plate-forme

Utilisez l’encapsulation de routage générique (GRE) pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.

Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme :

Différence de plate-forme
Commutateurs QFX Series
  • Sur les commutateurs QFX10002, QFX10008 et QFX5K Series qui prennent en charge GRE, si vous configurez le tunneling GRE avec le prochain saut ECMP sous-jacent au lieu d’un saut suivant Unicast, l’encapsulation du tunnel GRE échoue. Cela entraîne une baisse du trafic réseau.

  • Les commutateurs QFX Series qui prennent en charge GRE ne configurent pas l’interface GRE et l’interface source du tunnel dans des instances de routage distinctes. Cette configuration provoque une erreur de validation.

  • Les commutateurs QFX5100 Series qui prennent en charge GRE peuvent prendre en charge un total de 512 tunnels, y compris les tunnels créés avec un filtre de pare-feu. entre les commutateurs transmettant des paquets de charge utile IPv4 ou IPv6 via GRE. Si un protocole passager en plus d’IPv4 et IPv6 est utilisé, vous pouvez configurer jusqu’à 333 tunnels GRE entre les commutateurs.

  • Les commutateurs QFX Series qui prennent en charge GRE ne prennent pas en charge les fonctionnalités suivantes :

    • MPLS sur tunnels GRE

    • Keepalives GRE

    • Clés GRE, fragmentation des paquets de charge utile et numéros de séquence des paquets fragmentés

    • Tunnels dynamiques BGP

    • L’adresse IP externe doit être IPv4

Commutateurs EX Series

Commutateurs EX Series prenant en charge GRE :

  • Peut prendre en charge jusqu’à 500 tunnels GRE entre des commutateurs transmettant des paquets de charge utile IPv4 ou IPv6 sur GRE. Si un protocole passager en plus d’IPv4 et IPv6 est utilisé, vous pouvez configurer jusqu’à 333 tunnels GRE entre les commutateurs.
  • Un maximum de 20 adresses IP sources de tunnel peuvent être configurées, et chaque IP source de tunnel peut être configurée avec un maximum de 20 adresses IP de destination sur un deuxième commutateur. Par conséquent, les deux commutateurs connectés peuvent avoir un maximum de 400 tunnels GRE. Si le premier commutateur est également connecté à un troisième commutateur, le nombre maximal de tunnels possible est de 500.

  • Les fonctionnalités suivantes ne prennent pas en charge :

    • MPLS sur tunnels GRE

    • Keepalives GRE

    • Clés GRE, fragmentation des paquets de charge utile et numéros de séquence des paquets fragmentés

    • Tunnels dynamiques BGP

    • L’adresse IP externe doit être IPv4

    • Protocole BFD (Bidirectional Forwarding Detection) sur le mode distribué GRE

    • Limitation d’OSPF : l’activation d’OSPF sur une interface GRE crée deux routes à coût égal vers la destination : l’une via le réseau Ethernet ou l’interface de liaison montante et l’autre via l’interface de tunnel. Si les données sont acheminées via l’interface du tunnel, le tunnel peut tomber en panne. Pour que l’interface reste opérationnelle, nous vous recommandons d’utiliser une route statique, de désactiver OSPF sur l’interface de tunnel ou de configurer l’homologue pour qu’il n’annonce pas la destination du tunnel sur l’interface de tunnel.