GRE - Keepalives Tunnel

Présentation au sujet: "GRE - Keepalives Tunnel"— Transcription de la présentation:

1 GRE - Keepalives Tunnel
ccnp_cch ccnp_cch

2 Sommaire  Introduction  Mécanisme de Keepalive Tunnel GRE
- Tunnels GRE - Mécanismes de keepalive communs Keepalives Ethernet - Keepalives HDLC - Keepalives Tunnel GRE - Comment fonctionnent les keepalives Tunnel  IPSec et keepalives GRE Tunnels GRE avec IPSec - Problèmes avec les keepalives quand vous combinez IPSec et GRE ccnp_cch

3 Mécanisme de Keepalive Tunnel GRE
Introduction Ce document explique ce que sont les "keepalives" GRE et comment ils fonctionnent. La documentation GRE (Generic Routing Encapsulation) Tunnel Keepalive statue que les "keepalives" Tunnel GRE ne sont pas supportés en conjonction avec la commande tunnel protection ipsec profile. Ce document traite de ce problème et du cas où ces fonctionnalités sont combinées. Mécanisme de Keepalive Tunnel GRE Tunnels GRE Les tunnels GRE sont conçus pour être totalement sans état. Cela signifie que chaque extrémité du tunnel ne garde pas d'information sur l'état ou la disponibilité de l'extré- mité distante du tunnel. Une conséquence de cela est que l'extrémité locale du tunnel n'a pas la capacité de passer le protocole de liaison du tunnel GRE à l'état inactif si l'extrémité distante du tunnel est inaccessible. La capacité de capacité de marquer une interface hors-service quand l'extrémité de la liaison est inaccessible est utilisée pour retirer toute route (spécifiquement les routes statiques) de la table de routage, qui uti- lise cette interface comme interface sortante. Spécifiquement si un protocole de liaison pour une interface passe hors service alors toute route statique qui pointe en sortie sur cette interface est retirée de la table de routage. Ceci permet l'installation d'une route statique alternative (flottante) ou pour PBR (Policy-Based Routing) de sélection- ner un autre prochain saut ou interface. Normalement une interface tunnel GRE passe opérationnelle dès qu'elle est configurée et elle reste dans cet état tant qu'il y a une adresse tunnel source valide ou une inter- face active. L'adresse destination du tunnel doit être routable. cela est vrai même si l'autre extrémité du tunnel n'a pas été configurée. Cela signifie qu'une route statique ou l'acheminement PBR des paquets vers l'interface tunnel GRE reste opérationnel même si les paquets tunnel GRE n'atteignent pas l'autre extrémité du tunnel. Avant que les keepalives GRE soient implémentés, il y avait uniquement trois raisons pour qu'un tunnel GRE soit inactif:  Il n'y a pas de route vers l'adresse destination du tunnel  L'interface d'ancrage du tunnel source n'est pas active  La route vers le tunnel destination est à travers le tunnel lui-même Ces trois règles (route manquante, interface inactive, tunnel destination mal routé) sont des problèmes locaux au routeur aux extrémités du tunnel et ne couvrent pas les pro- blèmes dans le réseau intermédiaire. Par exemples ces règles ne couvrent pas le cas où les paquets GRE tunnelisés sont acheminés avec succès mais sont perdus avant d'at- teindre l'autre extrémité du tunnel. Cela entraine que les paquets de données qui pas- sent par le tunnel GRE sont perdus bien qu'une route alternative qui utilise PBR ou une route statique flottante via une autre interface soit potentiellement disponible. Les keepalive sur l'interface tunnel GRE sont utilisés pour résoudre ce problème de la mê- me manière que les keepalives qui sont utilisés sur les interfaces physiques. ccnp_cch

4 Avec l'IOS Cisco release 12
Avec l'IOS Cisco release 12.2(8)T il est possible de configurer des keepalive sur une in- terface tunnel GRE point à point. Avec ce changement, l'interface tunnel passe inactive de manière dynamique si les keepalive échouent après une certaine période de temps. Pour mieux comprendre comment les keepalive tunnel GRE fonctionnent, ces sections traitent quelques problèmes communs des mécanismes keepalive. Mécanismes de keepalive communs Les messages keepalive sont transmis par un équipement réseau via un circuit physi- que ou virtuel pour informer un autre équipement réseau que le circuit entre les deux équipements fonctionne toujours. L'intervalle keepalive est la période de temps entre chaque message keepalive qui est transmis par un équipement de réseau. Les tentatives keepalive sont le nombre de fois que l'équipement a transmis des paquets keepalive sans recevoir de réponse avant que l'interface soit passée inactive. Keepalives Ethernet Sur les médias de type broadcast comme Ethernet, les keepalives sont légèrement diffé- rents. comme il y a plusieurs voisins possibles sur Ethernet, le keepalive n'est pas con- çu pour déterminer si le chemin vers un voisin particulier est disponible. Il est unique- ment conçu pour vérifier que le système local a un accès en émission et en réception au câble Ethernet lui-même. Le routeur produit une trame Ethernet avec lui-même comme adresse comme adresse MAC source et destination et un type Ethernet spécial codé 0x9000. Le matériel Ethernet transmet ce paquet sur le support Ethernet et reçoit ce paquet immédiatement en retour. Cela vérifie le matériel émission et réception de l'adaptateur Ethernet et l'intégrité de base du support physique. Keepalives HDLC Un autre mécanisme keepalive bien connu est le keepalive série pour HDLC. Les keep- alives série sont transmis en retour aux keepalives reçus et les keepalives sont acquit- tés. De cette manière, les routeurs distants voient les keepalives l'un de l'autre et voient si les keepalives qu'ils transmettent sont reçus. Pour illustrer le fonctionnement des keepalives, Routeur1 et Routeur2 sont directement connectés respectivement via Serial 0/0 et Serial 2/0. Dans la sortie pour le Routeur1, Serial0/0 est désactivée volontairement. Cela entraine que Routeur2 perd trois keepali- ves pour illustrer comment cette défaillance entraine que Routeur 2 bloque l'interface Serial 2/0 lorsque les keepalives sont perdus. Ceci est un extrait de la sortie de la commande debug serial interface pour une conne- xion HDLC quand les keepalives sont validés. Quand la différence entre les valeurs des champs myseq et mineseen dépasse 3 sur le Routeur2, la liaison passe à l'état "down" et l'interface est réinitialisée. ccnp_cch

5 ccnp_cch Routeur1 Routeur2
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 Routeur2 *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 ccnp_cch

6 ccnp_cch Keepalives Tunnel GRE
Le mécanisme de keepalive tunnel GRE est légèrement différent de celui d'Ethernet ou de celui des interfaces série. Il donne la possibilité à une extrémité de générer et de re- cevoir des paquets keepalives de et vers le routeur distant même si le routeur distant ne supporte pas les keepalives GRE. Comme GRE est un mécanisme de tunnel pour tunnéliser IP dans IP, un paquet IP tunnel GRE peut être construit dans un autre pa- quet IP tunnel GRE. Pour les keepalives GRE, le transmetteur prépare un paquet de réponse keepalive à l'intérieur de la requête keepalive originale pour que l'extrémité distante ait seulement besoin de faire une désencapsulation GRE standard de l'en-tête IP la plus externe et ensuite achemine le paquet IP GRE encapsulé. Ce mécanisme en- traine que la réponse keepalive est acheminée sur l'interface physique au lieu de l'in- terface tunnel. Cela signifie que le paquet de réponse keepalive GRE n'est affecté par aucune des fonctionnalités de l'interface tunnel telle que "tunnel protection", la QoS, etc…S'il y a une ACL en entrée sur l'interface tunnel GRE, elle doit permettre le paquet keepalive tunnel GRE en retour. (access−list <number> permit gre host <tunnel−source> host <tunnel−destination>). Un autre attribut des keepalives Tunnel GRE est que les timers keepalives à chaque extrémité sont indépendants et n'ont pas besoin de correspondre. Le problème avec la configuration des keepalives sur un seul côté du tunnel est que le routeur qui a des keepalives configurés marque sont interface tunnel "down" si le timer keepalive expire. L'interface tunnel GRE de l'autre extrémité, sur laquelle les keepalives ne sont pas con- figurés reste opérationnelle même si l'autre extrémité du tunnel est "down". Le tunnel peut devenir un "trou noir" pour les paquets dirigés dans le tunnel à partir de l'extré- mité qui n'a pas les keepalives configurés. Dans un grand réseau tunnel GRE en étoile, il serait plus approprié de configurer les keepalives GRE uniquement sur les extrémités et non sur le site central. C'est parce qu'il est plus important pour l'extrémité de décou- vrir que le site central est inaccessible et par conséquent commuter vers un chemin de secours. Comment fonctionnent les keepalives tunnel Un tunnel GRE est une interface logique sur un routeur Cisco qui fournit un moyen pour encapsuler des paquet dans un protocole de transport. C'est une architecture conçue pour fournir des services pour implémenter un système d'encapsulation point à point. Ces paquets illustrent les concepts de tunnel IP où GRE est le protocole d'encapsula- tion et IP est le protocole de transport. Le protocole passager est également IP (cela peut être un autre protocole). Paquet normal IP TCP Paquet Paquet Tunnel IP GRE TCP Paquet ccnp_cch

7 ccnp_cch  IP est le protocole de transport
 GRE est le protocole d'encapsulation  IP est le protocole passager Pour mieux comprendre comment le mécanisme de keepalive tunnel fonctionne, consi- dérez cet exemple de topologie de tunnel et la configuration. Les interfaces physiques des routeurs A et B sont respectivement S1 et S2 et les interfaces tunnel sont appelées Tu0. Il y a un réseau IP backbone entre les deux routeurs d'extrémité de tunnel GRE. Ceci est un exemple de paquet keepalive qui est généré par le routeur A et destiné au routeur B . La réponse keepalive que le routeur B retourne au routeur A est déjà dans le paquet IP interne. Le routeur B désencapsule simplement le paquet keepalive et le transmet en arrière sur l'interface physique S2. Il traite le paquet keepalive GRE com- me n'importe quel paquet IP GRE de données. Tu0 Backbone IP Routeur A Routeur B S1 S2 Tunnel GRE Lo0: Lo0: IP GRE externe IP GRE interne IP IP SRC IP DEST GRE PT=IP PT=0 Cet exemple montre les commandes à utiliser pour configurer les keepalives sur les tunnels GRE. Router# configure terminal Router(config)#interface tunnel0 Router(config−if)#keepalive 5 4 !−−− La syntaxe de la commande est keepalive [seconds [retires]]. !−−− Les keepalives sont transmis toutes les 5 secondes et 4 essais. !−−− Les keepalives doivent être perdus avant que le tunnel passe "down". !−−− Les valeurs par défaut sont 10 secondes pour l'intervalle et 3 essais. Note: Les keepalives tunnel GRE sont uniquement supportés sur les tunnels GRE point à point. Les keepalives tunnel GRE sont configurables sur GRE multipoint (mGRE) mais sont sans effet. ccnp_cch

8 Ce tableau montre les configurations des routeurs A et B avec les keepalives tunnel
configurés sur les deux routeurs. Routeur A Routeur B interface loopback 0 ip address interface tunnel 0 ip address tunnel source loopback0 tunnel destination keepalive 5 4 ip address ip address tunnel destination Quand vous validez les keepalives sur l'extrémité tunnel du routeur A, le routeur à cha- que période construit l'en-tête IP interne et l'en-tête GRE avec Protocole Type (PT) égal à zéro. Il transmet ensuite ce paquet sur sont interface tunnel ce qui donne une encap- sulation du paquet avec l'en-tête IP externe et un en-tête GRE avec PT=IP. Le routeur A incrémente le compteur de keepalive tunnel de 1. En supposant qu'il y a moyen de join- dre l'extrémité distante du tunnel et que le protocole de liaison du tunnel est opération- nel, le paquet arrive au routeur B. Il est ensuite comparé à Tunnel0, est désencapsulé et il est réacheminé vers l'adresse IP destination qui l'adresse IP source du tunnel du routeur A. A son arrivée sur le routeur A, le paquet est désencapsulé et les test de PT donne 0. Cela signifie que c'est un paquet keepalive. Le compteur de keepalive est remis à zéro et le paquet est éliminé. Dans le cas ou le routeur B est inaccessible, le routeur A continue de construire et de transmettre des paquets keepalive comme le trafic normal. Si les keepalives ne revien- nent pas, le protocole de liaison du tunnel reste opérationnel tant que le compteur de keepalive est inférieur ou égal au nombre de tentatives configurées. Si cette condition n'est plus vraie, la prochaine fois que le routeur A tente de transmettre un keepalive vers le routeur B, le protocole de liaison passera à l'état "down". Dans l'état "up/down", le tunnel n'achemine ou ne traite aucun paquet de données. Ce- pendant il continue de transmettre les paquets keepalive. Sur réception d'une réponse keepalive ce qui implique que l'extrémité du tunnel est de nouveau accessible, le comp- teur keepalive est remis à zéro et le protocole de liaison tunnel est de nouveau opéra- tionnel. Le schéma suivant montre un exemple de scénario sur ce qui se passe quand le routeur A transmet un keepalive GRE au routeur B. ccnp_cch

9 ccnp_cch Tu0 Backbone IP Routeur A Routeur B S1 S2 Tunnel GRE
Lo0: Lo0: IP IP SRC IP DEST GRE PT=IP PT=0 1 Le Routeur A transmet un paquet keepalive GRE au routeur B, PT=IP. 2 Le Routeur B désencapsule le paquet GRE externe et achemine le paquet GRE interne sur l'interface physique du routeur A. IP IP SRC IP DEST GRE PT=0 3 Le Routeur A désencapsule le paquet GRE et voit PT=0 , ce qui correspond à une réponse keepalive. Il élimine le paquet GRE et remet à zéro le compteur de keepalive tunnel GRE. GRE PT=0 ccnp_cch

10 IPSec et keepalives GRE
Le schéma suivant montre un exemple de scénario sur ce qui se passe quand le routeur B transmet un keepalive GRE au routeur BA. Tu0 Backbone IP Routeur A Routeur B S1 S2 Tunnel GRE Lo0: Lo0: IP IP SRC IP DEST GRE PT=IP PT=0 1 Le Routeur B transmet un paquet keepalive GRE au routeur A, PT=IP. 2 Le Routeur A désencapsule le paquet GRE externe et achemine le paquet GRE interne sur l'interface physique du routeur B. IP IP SRC IP DEST GRE PT=0 3 Le Routeur B désencapsule le paquet GRE et voit PT=0 , ce qui correspond à une réponse keepalive. Il élimine le paquet GRE et remet à zéro le compteur de keepalive tunnel GRE. GRE PT=0 IPSec et keepalives GRE Tunnels GRE avec IPSec Les tunnels GRE sont quelquefois combinés avec IPSec car IPSec ne supporte pas les paquets IP multicast. Cela empêche les protocoles de routage dynamiques d'opérer sur un réseau VPN IPSec. Comme les tunnels GRE supportent IP multicast, un protocole de routage dynamique opère sur un tunnel GRE. Ensuite vous pouvez crypter les pa- quets IP GRE unicast avec IPSec. Il y a deux méthodes différentes pour IPSec pour crypter les paquets GRE. Une des mé- thodes est d'utiliser la commande crypto-map l'autre est d'utiliser la commande tunnel protection. Les deux méthodes spécifient que le cryptage IPSec est fait après l'ajout de l'encapsulation GRE. Quand une crypto map est générée, elle est appliquée aux l'inter- faces physiques pour les paquets tunnel GRE. Quand la commande tunnel protection est utilisée, elle est configurée sur l'interface tunnel GRE. La commande tunnel protection est disponible depuis la release 12.2(13)T de l'IOS Cisco. - Problèmes avec les keepalives quand vous combinez IPSec et GRE ccnp_cch

11 Ce schéma montre les paquets cryptés qui entrent dans un routeur via une interface
tunnel GRE. Le routeur a une crypto-map appliquée sur l'interface physique. Une fois que les paquets sont décryptés et désencapsulés, ils sont acheminés en clair vers leur destination. Interface physique Interface physique crypto-map Paquets cryptés Paquets en clair Interface Tunnel Ce schéma montre ce qui se passe quand vous configurez la commande tunnel-protec- tion sur l'interface tunnel GRE. Les paquets cryptés arrivent dans le routeur via l'inter- face tunnel, sont décryptés et désencapsulés avant qu'ils soient acheminés en clair vers leur destination. Interface physique Interface physique crypto-map Paquets cryptés Tunnel protection Paquets en clair Interface Tunnel Il y a deux différences clés entre l'utilisation d'une crypto-map et de la commande tunnel protection.  La crypto-map IPSec est reliée à l'interface physique et elle est vérifiée quand les pa- quets sont acheminés en sortie sur l'interface physique Note: Le tunnel GRE a déjà encapsulé le paquet à ce point  Tunnel protection lie la fonctionnalité de cryptage au tunnel GRE et elle est vérifiée après l'encapsulation GRE mais avant que le paquet soit placé sur l'interface physi- que. ccnp_cch

12 Problèmes avec les keepalives quand vous combinez IPSec et GRE
Un problème survient si une crypto-map est utilisée (configurée sur l'interface physi- que) sur une extrémité d'un tunnel GRE IPSec et que la commande tunnel protection est configurée sur l'interface tunnel uniquement. Ce type de configuration pourrait être fait dans une architecture en étoile. Tunnel protection est configuré sur le routeur cen- tral pour réduire la taille de la configuration et une crypto-map statique est utilisée sur chaque extrémité distante. Quand vous configurez le keepalive tunnel GRE sur l'extré- mité distante dans ce scénario, le keepalive échoue. Ceci est du au fait que le keepali- ve retour venant du routeur central passe par l'interface physique qui n'a pas de crypto map configurée. Par conséquent le keepalive en retour n'est pas crypté et le routeur re- ceveur (qui a l'origine a transmis le paquet keepalive) rejette le keepalive de réponse car il n'est pas protégé par IPSec (crypté). Ce schéma est une illustration de ce problème. Interface physique Interface physique Interface Tunnel Cryptage Tunnel protection crypto-map Interface Tunnel Texte clair Keepalive Tunnel Vous pouvez éviter ce problème et cela peut être un avantage si le keepalive GRE est configuré sur le routeur où tunnel protection est configuré. Ce point est illustré par le schéma suivant. Interface physique Interface physique Interface Tunnel Tunnel protection crypto-map Interface Tunnel Cryptage Keepalive Tunnel ccnp_cch

13 Si le routeur central utilise des crypto-map dynamiques et le routeur d'extrémité utilise
tunnel protection alors vous pouvez configurer les keepalives tunnel GRE sur le routeur d'extrémité ainsi vous pourrez déclencher l'utilisation d'une interface de secours vers le site central si l'interface tunnel GRE n'est plus opérationnelle. Bien que l'interface tunnel GRE sur le site central reste opérationnelle, le voisin de rou- tage et les routes à travers ce tunnel sont perdues et une route alternative peut être éta- blie . Sur le routeur d'extrémité le fait que l'interface tunnel passe "down" peut déclen- cher une interface de secours pour établir une nouvelle connexion vers le site central. Si les deux routeurs sont configurés avec des crypto-map, les keepalives tunnel pour- ront être utilisés dans les deux sens et les interfaces tunnel GRE pourront passer à l'état "down" dans une des deux directions et provoquer le basculement sur liaison de secours si nécessaire. C'est la solution la plus flexible et la plus efficace. ccnp_cch