IP : Encapsulation de routage générique (GRE)

Keepalives de tunnel GRE

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document explique ce que sont les keepalives GRE et comment ils fonctionnent. Les keepalives de tunnel GRE ne sont pas pris en charge en même temps que la commande tunnel protection ipsec profile. Ce document traite de ce problème.

Remarque:  Les keepalives GRE ne sont en aucun cas pris en charge avec la protection de tunnel IPsec.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Mécanisme keepalive de tunnel GRE

Tunnels GRE

Les tunnels GRE sont conçus pour être totalement sans état. Cela signifie que chaque point de terminaison de tunnel ne conserve aucune information sur l'état ou la disponibilité du point de terminaison de tunnel distant. L'une des conséquences est que le routeur de point de terminaison du tunnel local n'a pas la capacité à désactiver le protocole de ligne de l'interface de tunnel GRE si l'extrémité distante du tunnel est inaccessible. La capacité à marquer une interface comme désactivée quand l'extrémité distante de la liaison n'est pas disponible est utilisée afin de supprimer toutes les routes (spécifiquement les routes statiques) dans la table de routage qui utilisent cette interface comme interface de sortie. Spécifiquement, si le protocole de ligne pour une interface est modifié comme étant désactivé, toutes les routes statiques qui pointent vers cette interface sont supprimées de la table de routage. Ceci autorise l'installation d'une route statique alternative (flottante) ou permet au routage PBR (Policy Based Routing) de sélectionner un autre saut successif ou une autre interface.

Normalement, une interface de tunnel GRE est activée dès qu'elle est configurée et elle le reste tant qu'il y a une adresse source de tunnel valide ou une interface activée. L'adresse IP de destination du tunnel doit également être routable. Ceci est vrai même si l'autre côté du tunnel n'a pas été configuré. Cela signifie qu'une route statique ou le transfert PBR des paquets par l'intermédiaire de l'interface de tunnel GRE demeure effectif même si les paquets de tunnel GRE n'atteignent pas l'autre extrémité du tunnel.

Avant que les keepalives GRE ne soient implémentés, il y avait seulement trois raisons pour qu'un tunnel GRE s'arrête :

  • Il n'y a aucune route à l'adresse de destination du tunnel.

  • L'interface qui ancre la source de tunnel est désactivée.

  • La route à l'adresse de destination du tunnel passe par le tunnel lui-même.

Ces trois règles (route manquante, interface désactivée et destination de tunnel mal acheminée) sont des problèmes locaux au routeur aux extrémités du tunnel ; elles ne concernent pas les problèmes au niveau du réseau intervenant. Par exemple, ces règles ne couvrent pas le cas dans lequel les paquets tunnelés GRE sont transférés avec succès, mais sont perdus avant d'atteindre l'autre extrémité du tunnel. Ceci provoque la chute des paquets de données qui passent par le tunnel GRE dans un « trou noir », bien qu'une route alternative qui utilise PBR ou une route statique flottante via une autre interface soit potentiellement disponible. Les keepalives sur l'interface de tunnel GRE servent à résoudre ce problème de la même manière que les keepalives sont utilisés sur des interfaces physiques.

Avec la version de logiciel 12.2(8)T de Cisco IOSÝ, il est possible de configurer le Keepalives sur une interface de tunnel du Point à point GRE. Avec cette modification, l'interface du tunnel s'arrête de manière dynamique si les keepalives échouent pendant une certaine durée. Afin de mieux comprendre le fonctionnement des keepalives de tunnel GRE, ces sections traitent de quelques autres mécanismes de keepalive courants.

Mécanismes keepalive courants

Les messages keepalive sont envoyés par un périphérique réseau par l'intermédiaire d'un circuit virtuel ou physique pour informer un autre périphérique réseau que le circuit entre eux fonctionne toujours. L'intervalle keepalive est la durée qui s'écoule entre chaque message keepalive envoyé par un périphérique réseau. Les nouvelles tentatives de keepalive correspondent au nombre de fois que le périphérique continue à envoyer des paquets keepalives sans réponse avant que l'interface soit désactivée.

Keepalives Ethernet

Sur des supports de diffusion comme Ethernet, les keepalives sont légèrement différents. Puisqu'il y a beaucoup de voisins possibles sur Ethernet, le keepalive n'est pas conçu pour déterminer si le chemin à un voisin quelconque sur le câble est disponible. Il est conçu uniquement pour vérifier que le système local a un accès en lecture et en écriture au câble Ethernet lui-même. Le routeur produit un paquet Ethernet avec lui-même comme adresse MAC source et de destination et un code de type Ethernet spécial de 0x9000. Le matériel Ethernet envoie ce paquet sur le câble Ethernet, puis reçoit immédiatement ce paquet. Cela permet de vérifier le matériel d'envoi et de réception sur la carte Ethernet et l'intégrité de base du câble.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-a.gif

Keepalives HDLC

Un autre mécanisme keepalive bien connu est le keepalive séquentiel pour HDLC. Les keepalives séquentiels sont envoyés entre deux routeurs et font l'objet d'un accusé de réception. Avec l'utilisation de numéros de séquence, chaque routeur assure le suivi des paquets keepalive envoyés et reçus. De cette façon, les routeurs distants examinent leurs keepalives respectifs et contrôlent si les keepalives qu'ils envoient sont reçus.

En guise d'illustration du fonctionnement des keepalives séquentiels, Routeur 1 et Routeur 2 sont connectés directement, respectivement par l'intermédiaire de Serial0/0 et Serial2/0. Dans la sortie de Routeur 1, Serial 0/0 est arrêté de manière intentionnelle. Routeur 2 manque ainsi trois keepalives, ce qui permet d'illustrer comment cette échec provoque l'arrêt, par Routeur 2, de Serial2/0 quand des keepalives sont manqués.

Voici un exemple de sortie de la commande debug serial interface pour une connexion HDLC quand les keepalives sont activés. Quand la différence entre les valeurs des champs myseq et mineseen dépasse 3 sur Routeur 2, la ligne est désactivée et l'interface est réinitialisée.

Routeur 1
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up 
17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
Router1 (config-if)#shut
17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state 
to administratively down

17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, 
changed state to down

Routeur 2
*Sep 24 17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up 
*Sep 24 17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up 
*Sep 24 17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up 
*Sep 24 17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up 
*Sep 24 17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up 
*Sep 24 17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up 
*Sep 24 17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up 
*Sep 24 17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up 
*Sep 24 17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up 
*Sep 24 17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up 
*Sep 24 17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up 
*Sep 24 17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:05.153: HD(0): Reset from 0x203758
*Sep 24 17:23:05.153: HD(0): Asserting DTR 
*Sep 24 17:23:05.153: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:15.173: HD(0): Reset from 0x203758
*Sep 24 17:23:15.173: HD(0): Asserting DTR 
*Sep 24 17:23:15.173: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down 
17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0, 
changed state to down
Router2#
17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down

Keepalives de tunnel GRE

Le mécanisme keepalive de tunnel GRE diffère légèrement de celui des interfaces Ethernet ou série. Il permet à une extrémité d'envoyer et de recevoir des paquets keepalives vers et en provenance d'un routeur distant même si ce dernier ne prend pas en charge les keepalives GRE. Puisque GRE est un mécanisme de transmission tunnel de paquet pour la transmission tunnel IP à l'intérieur d'IP, un paquet de tunnel IP GRE peut être construit à l'intérieur d'un autre paquet de tunnel IP GRE. Pour les keepalives GRE, l'expéditeur préconstruit le paquet de réponse keepalive à l'intérieur du paquet de requête keepalive initial de sorte que l'extrémité distante ait uniquement besoin d'effectuer une désencapsulation GRE standard de l'en-tête IP GRE externe puis de transférer le paquet IP GRE interne. Ce mécanisme fait en sorte que la réponse keepalive transfère l'interface physique plutôt que l'interface du tunnel. Cela signifie que le paquet de réponse keepalive GRE n'est affecté par aucune fonctionnalité de sortie sur l'interface du tunnel, telle que « tunnel protection… », QoS, et ainsi de suite .

Remarque: Si une liste de contrôle d'accès entrante sur l'interface de tunnel GRE est configurée, le paquet keepalive de tunnel GRE envoyé par le périphérique opposé doit être autorité. Sinon, le tunnel GRE du périphérique opposé sera désactivé. (access-list <numéro> permit gre host <source_tunnel> host <destination_tunnel>)

Un autre attribut des keepalives de tunnel GRE est que les minuteurs de keepalive de chaque extrémité sont indépendants et ne sont pas obligés de correspondre. Le problème lié à la configuration des keepalives d'un seul côté du tunnel est que seul le routeur pour lequel les keepalives sont configurés marque son interface de tunnel comme désactivée si le minuteur de keepalive expire. L'interface de tunnel GRE à l'autre extrémité, où les keepalives ne sont pas configurés, demeure active même si l'autre extrémité du tunnel est désactivée. Le tunnel peut devenir un trou noir pour les paquets dirigés dans le tunnel depuis l'extrémité où les keepalives n'ont pas été configurés. Dans un grand réseau de tunnel GRE en étoile, il peut être préférable de configurer seulement les keepalives GRE du côté des rayons et non du côté du concentrateur. En effet, il est souvent plus important que le rayon détecte que le concentrateur est inaccessible et puisse basculer vers un chemin de secours (enregistrement d'appel, par exemple).

Fonctionnement des keepalives de tunnel

Un tunnel GRE est une interface logique sur un routeur Cisco qui fournit une méthode d'encapsulation de paquets passagers au sein d'un protocole de transport. C'est une architecture conçue pour fournir les services destinés à mettre en application un plan d'encapsulation point à point.

Ces paquets illustrent les concepts de transmission tunnel IP dans lesquels GRE est le protocole d'encapsulation et IP est le protocole de transport. Le protocole passager est également IP (bien qu'il puisse s'agir d'un autre protocole comme DECNet, IPX ou AppleTalk).

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-b.gif

  • IP est le protocole de transport.

  • GRE est le protocole d'encapsulation.

  • IP est le protocole passager.

Afin de mieux comprendre le fonctionnement du mécanisme keepalive de tunnel, observez cet exemple de topologie et de configuration de tunnel. Les interfaces physiques de Routeur A et de Routeur B sont respectivement S1 et S2 et les interfaces du tunnel se nomment Tu0. Il y a un réseau principal IP entre les deux routeurs de point de terminaison de tunnel GRE.

Voici un exemple de paquet keepalive provenant de Routeur A et destiné à Routeur B. La réponse de keepalive renvoyée par Routeur B à Routeur A est déjà à l'intérieur de l'en-tête IP interne. Routeur B désencapsule simplement le paquet keepalive et le renvoie par le biais de l'interface physique (S2). Il traite le paquet keepalive GRE comme n'importe quel autre paquet de données IP GRE.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-1.gif

Cette sortie montre les commandes que vous utilisez afin de configurer des keepalives sur des tunnels GRE.

Router# configure terminal
Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].



!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.

Remarque: les keepalives de tunnel GRE sont seulement pris en charge sur les tunnels GRE point à point. Les keepalives de tunnel sont configurables sur les tunnels multipoints GRE (mGRE) mais n'ont aucun effet.

Ce tableau montre la configuration de Routeur A et de Routeur B avec le keepalive de tunnel configuré sur les deux routeurs.

Nom d'hôte Routeur-A Nom d'hôte Routeur-B
interface loopback 0
  ip address 129.9.9.9 255.255.255.255
interface tunnel 0
  ip address 1.1.1.1 255.255.255.240
  tunnel source loopback0
  tunnel destination 128.8.8.8
  keepalive 5 4
interface loopback 0
  ip address 128.8.8.8 255.255.255.255
interface tunnel 0
  ip address 1.1.1.2 255.255.255.240
  tunnel source loopback0
  tunnel destination 129.9.9.9
  keepalive 5 4 

Quand vous activez les keepalives sur le point de terminaison du tunnel de Routeur A, le routeur situé à chaque intervalle <period> construit l'en-tête IP interne et l'en-tête GRE avec un type de protocole (PT) de 0. Il envoie ensuite ce paquet par le biais de son interface de tunnel, ce qui a comme conséquence l'encapsulation du paquet avec l'en-tête IP externe et un en-tête GRE avec PT = IP. Routeur A incrémente le nombre de keepalives de tunnel d'une unité. En supposant qu'il y a une façon d'atteindre le point de terminaison du tunnel lointain et que le protocole de ligne de tunnel n'est pas désactivé pour d'autres raisons, le paquet parvient au Routeur B. Il est alors comparé au Tunnel 0, devient désencapsulé, puis est transféré à l'adresse IP de destination qui est l'adresse IP source de tunnel sur Routeur A. À son arrivée sur Routeur A, le paquet devient désencapsulé et le contrôle du type de paquet (PT) donne la valeur 0. Cela signifie qu'il s'agit d'un paquet keepalive. Le compteur de keepalives de tunnel est alors réinitialisé à 0 et le paquet est ignoré.

Dans le cas où Routeur B est inaccessible, Routeur A continue à construire et à envoyer des paquets keepalives en plus du trafic normal. Si les keepalives ne reviennent pas, le protocole de ligne de tunnel reste actif tant que le compteur de keepalives de tunnel est inférieur au nombre de <retries>. Si cette condition n'est pas remplie, la prochaine fois que Routeur A tente d'envoyer un keepalive à Routeur B, le protocole de ligne est désactivé.

À l'état actif/inactif, le tunnel ne transfère ou ne traite aucun trafic de données. Cependant, il continue à envoyer des paquets keepalives. Lors de la réception d'une réponse de keepalive, avec l'implication que le point de terminaison du tunnel est de nouveau accessible, le compteur de keepalives de tunnel est réinitialisé à 0 et le protocole de ligne sur le tunnel est activé.

Remarque: Si en raison d'une baisse de keepalive que le tunnel va à l'état haut/bas, l'enable mettent au point le tunnel et mettent au point la keepalive de tunnel.

Cette table affiche que la sortie témoin de mettent au point la keepalive de tunnel sur le routeur A :

Nom d'hôte Routeur-A
debug tunnel keepalive
        Tunnel keepalive debugging is on
        *Mar  1 01:19:16.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=15
        *Mar  1 01:19:21.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=16
        *Mar  1 01:19:26.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=17

Ce schéma montre un exemple de scénario de ce qui se produit quand Routeur A envoie un keepalive GRE à Routeur B :

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-2.gif

Ce schéma montre un exemple de scénario de ce qui se produit quand Routeur B envoie un keepalive GRE à Routeur A :

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-3.gif

IPSec et keepalives GRE

Tunnels GRE avec IPSec

Les tunnels GRE sont parfois combinés avec IPSec car IPSec ne prend pas en charge les paquets multicast IP. Ceci empêche les protocoles de routage dynamique de s'exécuter avec succès sur un réseau VPN IPSec. Puisque les tunnels GRE prennent en charge Multicast IP, un protocole de routage dynamique peut être exécuté sur un tunnel GRE. Ensuite, vous pouvez chiffrer les paquets de monodiffusion IP GRE par IPSec.

Il y a deux manières différentes pour IPSec de chiffrer des paquets GRE. L'une consiste à utiliser une carte de chiffrement et l'autre consiste à utiliser la protection de tunnel. Les deux méthodes spécifient que le chiffrement IPSec est effectué après l'ajout de l'encapsulation GRE. Quand une carte de chiffrement est utilisée, elle est appliquée à l'interface physique sortante pour les paquets de tunnel GRE. Quand la protection de tunnel est utilisée, elle est configurée sur l'interface de tunnel GRE. La commande tunnel protection est devenue disponible dans le logiciel Cisco IOS version 12.2(13)T.

Remarque: les keepalives GRE ne sont pas compatibles avec la protection de tunnel.

Ce schéma montre les paquets chiffrés qui entrent dans un routeur par l'intermédiaire d'une interface de tunnel GRE. Le routeur a une carte de chiffrement appliquée sur l'interface physique. Une fois les paquets déchiffrés et désencapsulés, ils poursuivent leur chemin jusqu'à leur destination IP en texte clair.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-4.gif

Ce schéma montre ce qui se produit quand vous configurez la protection de tunnel sur l'interface de tunnel GRE. Les paquets entrent dans le routeur chiffrés par l'intermédiaire de l'interface du tunnel et sont déchiffrés et désencapsulés avant de continuer vers leur destination en texte clair.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-5.gif

Il y a deux différences principales entre l'utilisation d'une carte de chiffrement et l'utilisation de la protection de tunnel :

  • La carte de chiffrement IPSec est liée à l'interface physique et est vérifiée à mesure que des paquets sont transférés par le biais de l'interface physique.

    Remarque: à ce stade, le tunnel GRE a déjà effectué une encapsulation GRE du paquet.

  • La protection de tunnel lie la fonctionnalité de chiffrement au tunnel GRE et est vérifiée après l'encapsulation GRE du paquet mais avant que le paquet soit remis à l'interface physique.

Problèmes avec des keepalives quand vous combinez IPSec et GRE

Un problème se pose si une carte de chiffrement est utilisée (configurée sur l'interface physique) d'un côté d'un tunnel IPsec GRE et que la protection de tunnel est configurée de l'autre côté. La protection de tunnel est configurée seulement sur l'interface du tunnel (et pas sur l'interface physique). Ce type de configuration peut se présenter dans une conception de réseau en étoile. La protection de tunnel est configurée sur le routeur concentrateur afin de réduire la taille de la configuration et une carte de chiffrement statique est utilisée sur chaque rayon. Quand vous configurez le keepalive de tunnel GRE sur le rayon dans ce scénario, le keepalive échoue. Ceci est dû au fait que le keepalive de retour envoyé par le concentrateur traverse l'interface physique, sur laquelle aucune carte de chiffrement n'est configurée. Par conséquent, le keepalive de retour n'est pas chiffré et le routeur récepteur (qui a initialement envoyé le paquet keepalive) ignore la réponse keepalive car elle n'est pas protégée (chiffrée) par IPSec.

Ce schéma montre une illustration du problème :

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-9.gif

Vous pouvez éviter ce problème et vous pouvez en tirer un avantage si le keepalive GRE est configuré sur le routeur où la protection de tunnel est configurée. Ce point est illustré par ce schéma :

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-10.gif

Si le concentrateur utilise des cartes de chiffrement dynamiques et que le routeur en étoile utilise la protection de tunnel, vous pouvez configurer les keepalives GRE sur le routeur en étoile de manière à pouvoir déclencher une interface de sauvegarde pour appeler le concentrateur si l'interface du tunnel s'arrête sur le rayon.

Bien que l'interface de tunnel GRE sur le concentrateur demeure active, le voisin de routage et les routes par le tunnel sont perdus et la route alternative peut être établie. Sur le rayon, le fait que l'interface du tunnel a été désactivée peut provoquer l'appel d'une interface de numérotation et un rappel au concentrateur (ou à un routeur différent au concentrateur), puis l'établissement d'une nouvelle connexion.

Si les deux routeurs sont configurés avec des cartes de chiffrement, les keepalives de tunnel peuvent passer dans les deux directions et les interfaces de tunnel GRE peuvent s'arrêter dans l'une ou l'autre direction et déclencher l'établissement d'une connexion de sauvegarde. Il s'agit de l'option la plus flexible.

Si les deux routeurs sont configurés avec la protection de tunnel, les keepalives de tunnel GRE ne peuvent être utilisés dans aucune direction. Dans ce cas, vous devez employer le protocole de routage ou tout autre mécanisme, tel que Service Assurance Agent, pour détecter que le tunnel n'est pas opérationnel.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 64565