Begrijp GRE Tunnel Keepalives

Inleiding

In dit document wordt beschreven wat Generic Routing Encapsulation (GRE)-levenden zijn en hoe ze werken.

GRE-tunnels

Een GRE-tunnel is een logische interface op een router die een manier biedt om netwerkprotocolpakketten in een transportprotocol in te kapselen. Het is een mechanisme om netwerkverkeer via een point-to-point-inkapselingssysteem te vervoeren.

GRE-tunnels zijn ontworpen om volledig staatloos te zijn. Dit betekent dat elk tunneleindpunt geen informatie bijhoudt over de status of beschikbaarheid van het externe tunneleindpunt. Een gevolg hiervan is dat de router voor het eindpunt van de lokale tunnel niet in staat is om het lijnprotocol van de GRE Tunnel-interface naar beneden te brengen als het externe uiteinde van de tunnel onbereikbaar is. De mogelijkheid om een interface te markeren als down wanneer het externe uiteinde van de link niet beschikbaar is, wordt gebruikt om routes (met name statische routes) in de routeringstabel te verwijderen die die interface gebruiken als de uitgaande interface. Specifiek, als het lijnprotocol voor een interface wordt gewijzigd in down, worden statische routes die erop wijzen dat de interface wordt verwijderd uit de routeringstabel. Dit maakt de installatie van een alternatieve (zwevende) statische route of voor Policy Based Routing (PBR) mogelijk om een alternatieve next-hop of interface te selecteren.

Normaal gesproken komt een GRE Tunnel-interface naar boven zodra deze is geconfigureerd en blijft deze omhoog zolang er een geldig tunnelbronadres of een tunnelbroninterface is die zich in een up-status bevindt. Het IP-adres van de tunnelbestemming moet ook routeerbaar zijn. Dit is zelfs het geval als de andere kant van de tunnel niet is geconfigureerd. Dit betekent dat een statische route of PBR-verzending van pakketten via de GRE-tunnelinterface van kracht blijft, ook al kunnen de GRE-tunnelpakketten het andere uiteinde van de tunnel niet bereiken.

Voordat GRE keepalives werden geïmplementeerd, waren er alleen manieren om een tunnelinterface neer te halen vanwege lokale problemen op de router, en niet vanwege problemen in het transportnetwerk. Bijvoorbeeld het geval waarin de GRE-tunnelpakketten met succes worden doorgestuurd, maar verloren gaan voordat ze het andere uiteinde van de tunnel bereiken. Dergelijke scenario's zouden ertoe leiden dat gegevenspakketten die door de GRE-tunnel gaan "zwarte gaten" zijn, hoewel een alternatieve route die PBR gebruikt of een zwevende statische route via een andere interface beschikbaar is. Keepalives op de GRE-tunnelinterface worden gebruikt om dit probleem op dezelfde manier op te lossen als keepalives worden gebruikt op fysieke interfaces.

Opmerking: GRE keepalives worden in geen geval ondersteund in combinatie met IPsec-tunnelbescherming. In dit document wordt deze kwestie besproken.

Hoe Tunnel Keepalives werkt

Het GRE-tunnelkeepalive-mechanisme is vergelijkbaar met PPP keepalives, omdat het de mogelijkheid biedt voor één zijde om keepalive-pakketten van en naar een externe router te ontvangen, zelfs als de externe router GRE keepalives niet ondersteunt. Aangezien GRE een pakkettunnelmechanisme is voor het tunnelen van IP binnen IP, kan een GRE IP-tunnelpakket worden gebouwd in een ander GRE IP-tunnelpakket. Voor GRE keepalives bouwt de afzender het keepalive-antwoordpakket vooraf op in het oorspronkelijke keepalive-verzoekpakket, zodat het externe einde alleen de standaard GRE-decapsulatie van de buitenste GRE IP-header hoeft te doen en vervolgens het binnenste IP GRE-pakket naar de afzender terugstuurt. Deze pakketten illustreren de IP tunneling concepten waarbij GRE het inkapselingsprotocol is en IP het transportprotocol. Het passagiersprotocol is ook IP (hoewel het een ander protocol kan zijn zoals NHRP ).

Normaal pakket:

IP-header

TCP-header

Telnet

Pakket met tunnel:

GRE IP-header

GRE

IP-header TCP-header Telnet

• IP is het transportprotocol.
• GRE is het inkapselingsprotocol.
• IP is het passagiersprotocol.

Hier is een voorbeeld van een keepalive-pakket dat afkomstig is van Router A en bestemd is voor Router B. De keepalive-reactie die Router B terugkeert naar Router A bevindt zich al in de Inner IP-header. Router B decapsuleert eenvoudig het keepalive-pakket en stuurt het terug naar de fysieke interface (S2). Het verwerkt het GRE keepalive-pakket net als elk ander GRE IP-gegevenspakket.

GRE Keepalives:

GRE IP-header		GRE	IP-header GRE Bron B Bestemming A  PT=0
Bron A	Bestemming B	PT=IP

Dit mechanisme zorgt ervoor dat de keepalive-respons wordt doorgestuurd naar de fysieke interface in plaats van de tunnelinterface. Dit betekent dat het GRE keepalive-responspakket niet wordt beïnvloed door outputfuncties op de tunnelinterface, zoals "tunnelbescherming ..." QoS, Virtual Routing and Forwarding (VRF), enzovoort.

Opmerking: Als een inkomende toegangscontrolelijst (ACL) op de GRE-tunnelinterface is geconfigureerd, moet het GRE-tunnelpakket dat het tegenovergestelde apparaat verzendt, actief blijven. Als dat niet het geval is, wordt het tegenovergestelde apparaat GRE-tunnel neergehaald. (toegangslijst <nummer> GRE-host <tunnel-source> host <tunnel-destination>toestaan)

Een ander kenmerk van GRE tunnel keepalives is dat de keepalive timers aan elke kant onafhankelijk zijn en niet hoeven te matchen, vergelijkbaar met PPP keepalives.

Tip: Het probleem met de configuratie van keepalives aan slechts één kant van de tunnel is dat alleen de router die keepalives heeft geconfigureerd zijn tunnelinterface markeert als down als de keepalive-timer verloopt. De GRE-tunnelinterface aan de andere kant, waar keepalives niet zijn geconfigureerd, blijft omhoog, zelfs als de andere kant van de tunnel naar beneden is. De tunnel kan een zwart gat worden voor pakketten die vanaf de zijkant naar de tunnel worden geleid en die geen levendgeborenen hadden geconfigureerd.

Tip: In een groot hub-and-spoke GRE-tunnelnetwerk kan het passend zijn om alleen GRE-keepalives aan de spaakzijde en niet aan de hubzijde te configureren. Dit komt omdat het vaak belangrijker is voor de spreker om te ontdekken dat de hub onbereikbaar is en daarom switch is naar een back-uppad, bijvoorbeeld met behulp van een mobiele back-upinterface.

GRE Tunnel Keepalives

Met Cisco IOS^® Software Release 12.2(8)T is het mogelijk om keepalives te configureren op een point-to-point GRE-tunnelinterface. Met deze verandering wordt de tunnelinterface dynamisch afgesloten als de keepalives gedurende een bepaalde periode uitvallen.

Voor meer informatie over hoe andere vormen van keepalives werken, raadpleegt u Overzicht van Keepalive Mechanisms op Cisco IOS.

Opmerking: GRE tunnel keepalives worden alleen ondersteund op point-to-point GRE tunnels. Tunnel keepalives zijn configureerbaar op multipoint GRE (mGRE) tunnels, maar hebben geen effect.

Opmerking: Over het algemeen kunnen tunnelkleven niet werken wanneer VRF's worden gebruikt op de tunnelinterface en de fVRF (tunnel vrf ...) en iVRF (ip vrf forwarding ... op tunnelinterface) niet overeenkomen. Dit is van cruciaal belang voor het tunneleindpunt dat de reanimatie naar de aanvrager weergeeft. Wanneer het keepalive-verzoek is ontvangen, wordt het ontvangen in de fVRF en gedecapsuleerd. Dit onthult het vooraf gemaakte keepalive-antwoord, dat vervolgens moet worden teruggestuurd naar de afzender, MAAR dat doorsturen gebeurt in de context van de iVRF op de tunnelinterface. Daarom, als de iVRF en de fVRF niet overeenkomen, wordt het keepalive-antwoordpakket niet teruggestuurd naar de afzender. Dit geldt zelfs als u iVRF en/of fVRF vervangt door globale.

Deze uitvoer toont de opdrachten die u gebruikt om keepalives te configureren in GRE-tunnels.

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.

Om beter te begrijpen hoe het tunnelkeepalive-mechanisme werkt, kunt u dit voorbeeld van tunneltopologie en -configuratie bekijken:

Router A:

interface loopback 0
  ip address 192.168.1.1 255.255.255.255
!
interface tunnel 0
  ip address 10.10.10.1 255.255.255.252
  tunnel source loopback0
  tunnel destination 192.168.1.2
  keepalive 5 4

Router B:

interface loopback 0
  ip address 192.168.1.2 255.255.255.255
!
interface tunnel 0
  ip address 10.10.10.2 255.255.255.252
  tunnel source loopback0
  tunnel destination 192.168.1.1
  keepalive 5 4 

In dit scenario voert router A de volgende stappen uit:

• • De bron is ingesteld als de lokale tunnelbestemming, die 192.168.1.2 is
  • De bestemming wordt ingesteld als de lokale tunnelbron, die 192.168.1.1 is, en 
  • Construeert de binnenste IP-header elke vijf seconden wanneer een GRE-header wordt toegevoegd met een protocoltype (PT) van 0.
  
  Pakket gegenereerd door router A maar niet verzonden:
  

  IP-header		GRE
  Bron: 192 168 1 2	Bestemming: 192 168 1 1 1	PT=0

  
  
  

Verzendt dat pakket uit de tunnelinterface, wat resulteert in de inkapseling van het pakket met de buitenste IP-header waarbij:

• De bron is ingesteld als de lokale tunnelbron, die 192.168.1.1 is
• De bestemming is ingesteld als de lokale tunnelbestemming, die 192.168.1.2 is, en
• Er wordt een GRE-header toegevoegd met PT = IP.
  
  Pakket verzonden van router A naar router B:

GRE IP-header		GRE	IP-header GRE Bron: 192 168 1 2 Bestemming: 192 168 1 1 1  PT=0
Bron: 192 168 1 1 1	Bestemming: 192 168 1 2	PT=IP

• Verhoogt de tunnel om de teller één voor één levend te houden.
• Met de veronderstelling dat er een manier is om het verre eindtunneleindpunt te bereiken en het tunnellijnprotocol niet is uitgeschakeld vanwege andere redenen, komt het pakket aan op Router B. Het wordt vervolgens vergeleken met Tunnel 0, wordt ontkapseld en doorgestuurd naar het IP-adres van de bestemming, het IP-adres van de tunnelbron op router A.
  
  Verzonden van router B naar router A:
  

  IP-header		GRE
  Bron: 192 168 1 2	Bestemming: 192 168 1 1 1	PT=0

  
  
  
• Bij aankomst op router A wordt het pakket ontkapseld en de controle van de PT resulteert in 0. Dit betekent dat dit een keepalive-pakket is. De teller van de tunnelbewaarder wordt dan teruggezet op 0 en het pakket wordt weggegooid.

Als Router B onbereikbaar is, blijft Router A keepalive-pakketten en normaal verkeer maken en verzenden. Als de keepalives niet terugkomen, blijft het tunnellijnprotocol overeind zolang de tunnel keepalive-teller kleiner is dan het aantal pogingen, dat in dit geval vier is. Als die voorwaarde niet waar is, wordt de volgende keer dat Router A probeert een keepalive naar Router B te sturen, het lijnprotocol naar beneden gehaald.

Opmerking: In de up/down-toestand stuurt of verwerkt de tunnel geen dataverkeer door. Het blijft echter keepalive-pakketten verzenden. Op de ontvangst van een keepalive-reactie, met de implicatie dat het tunneleindpunt weer bereikbaar is, wordt de tunnel keepalive-teller gereset naar 0 en komt het lijnprotocol op de tunnel naar boven.

Om keepalives in actie te zien, schakelt u debug tunnel en debug tunnel keepalive in.

Voorbeeldfouten van router A:

debug tunnel keepalive
        Tunnel keepalive debugging is on
        01:19:16.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=15
        01:19:21.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=16
        01:19:26.019: Tunnel0: sending keepalive, 192.168.1.1->192.168.1.2
        (len=24 ttl=0), counter=17

GRE Keepalives en Unicast Reverse Path Forwarding

Unicast RPF (Unicast Reverse Path Forwarding) is een beveiligingsfunctie die helpt bij het detecteren en laten vallen van vervalst IP-verkeer met een validatie van het pakketbronadres tegen de routeringstabel. Wanneer Unicast RPF in de strikte modus wordt uitgevoerd (ip verifieert unicast-bron bereikbaar via rx), moet het pakket worden ontvangen op de interface die de router zou gebruiken om het retourpakket door te sturen. Als de strikte modus of de losse modus Unicast RPF is ingeschakeld op de tunnelinterface van de router die de GRE-pakketten ontvangt, worden de keepalives-pakketten na tunneldecapsulatie door RPF gedropt omdat de route naar het bronadres van het pakket (eigen tunnelbronadres van de router) niet via de tunnelinterface loopt. RPF-pakketdruppels kunnen als volgt worden waargenomen in de uitvoer van het weergegeven ip-verkeer:

Router#show ip traffic | section Drop 
 Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
 0 no route, 156 unicast RPF, 0 forced drop
 0 options denied 

Als gevolg hiervan haalt de initiatiefnemer van de tunnel keepalives de tunnel naar beneden vanwege gemiste keepalives-retourpakketten. Dus Unicast RPF mag niet worden geconfigureerd in strikte of losse modus voor GRE tunnel houdt levenden om te werken. Voor meer informatie over Unicast RPF, zie Inzicht in Unicast omgekeerde pad doorsturen.

IPsec en GRE Keepalives

GRE-tunnels met IPsec

GRE-tunnels worden soms gecombineerd met IPsec omdat IPsec geen IP-multicastpakketten ondersteunt. Hierdoor kunnen dynamische routeringsprotocollen niet succesvol worden uitgevoerd via een IPsec VPN-netwerk. Aangezien GRE-tunnels IP-multicast ondersteunen, kan een dynamisch routeringsprotocol over een GRE-tunnel worden uitgevoerd. De GRE IP-unicastpakketten die daaruit voortvloeien, kunnen worden gecodeerd door IPsec.

Er zijn twee verschillende manieren waarop IPsec GRE-pakketten kan coderen:

• Een manier is met het gebruik van een crypto-kaart. Wanneer een cryptografische kaart wordt gebruikt, wordt deze toegepast op de uitgaande fysieke interface(s) voor de GRE-tunnelpakketten. In dit geval is de volgorde van de stappen als volgt:
  
  
  1. Gecodeerde pakketten bereiken de fysieke interface.
  2. Pakket wordt gedecodeerd en doorgestuurd naar de tunnelinterface.
  3. Pakket wordt gedecapsuleerd en vervolgens doorgestuurd naar de IP-bestemming in duidelijke tekst.
  
  
  
• De andere manier is om tunnelbescherming te gebruiken. Wanneer tunnelbeveiliging wordt gebruikt, wordt deze geconfigureerd op de GRE-tunnelinterface. Het tunnelbeveiligingscommando is beschikbaar gekomen in Cisco IOS Software Release 12.2(13)T. In dit geval is de volgorde van de stappen als volgt:
  
  
  1. Gecodeerde pakketten bereiken fysieke interface.
  2. Het pakket wordt doorgestuurd naar de tunnelinterface.
  3. Pakket wordt ontcijferd en gedecapsuleerd en vervolgens in duidelijke tekst doorgestuurd naar de IP-bestemming.

Beide methoden specificeren dat IPsec-codering wordt uitgevoerd na de toevoeging van de GRE-inkapseling. Er zijn twee belangrijke verschillen tussen wanneer u een cryptografische kaart gebruikt en wanneer u tunnelbescherming gebruikt:

• De IPsec crypto map is gekoppeld aan de fysieke interface en wordt gecontroleerd als pakketten worden doorgestuurd naar de fysieke interface. De GRE-tunnel heeft het pakket al ingekapseld door dit punt.
• De tunnelbescherming verbindt de coderingsfunctionaliteit met de GRE-tunnel en wordt gecontroleerd nadat het pakket is ingekapseld, maar voordat het pakket wordt overgedragen aan de fysieke interface.

Problemen met Keepalives wanneer u IPsec en GRE combineert

Gezien de twee manieren om encryptie toe te voegen aan GRE-tunnels, zijn er drie verschillende manieren om een gecodeerde GRE-tunnel in te stellen:

1. Peer A heeft tunnelbeveiliging geconfigureerd op de tunnelinterface, terwijl Peer B een cryptografische kaart heeft geconfigureerd op de fysieke interface.
2. Peer A heeft een cryptografische kaart geconfigureerd op de fysieke interface, terwijl Peer B tunnelbescherming heeft geconfigureerd op de tunnelinterface.
3. Beide Peers hebben tunnelbeveiliging geconfigureerd op de tunnelinterface.

De configuratie beschreven in scenario's 1 en 2 wordt vaak gedaan in een hub-and-spoke ontwerp. De tunnelbeveiliging is geconfigureerd op de hub-router om de configuratie te verkleinen en op elke spaak wordt een statische cryptografische kaart gebruikt.

Overweeg elk van deze scenario's met GRE-keepalives ingeschakeld op Peer B (spoke) en waar de tunnelmodus wordt gebruikt voor codering.

Scenario 1

Configuratie:

• Peer A maakt gebruik van tunnelbescherming.
• Peer B maakt gebruik van Crypto Maps.
• Keepalives zijn ingeschakeld op Peer B.
• IPsec-codering wordt uitgevoerd in de tunnelmodus.

In dit scenario, aangezien de GRE-keepalives zijn geconfigureerd op Peer B, zijn de sequentiegebeurtenissen wanneer een keepalive wordt gegenereerd als volgt:

1. Peer B genereert een keepalive-pakket dat GRE ingekapseld is en vervolgens wordt doorgestuurd naar de fysieke interface waar het wordt gecodeerd en doorgestuurd naar de tunnelbestemming, Peer A.
   
   Pakket verzonden van peer B naar peer A:
   

   IP-header	ESP-koptekst	GRE IP-header		GRE-koptekst	IP-header GRE Bron A Bestemming B PT=0	ESP-aanhangwagen
   Bron B	Bestemming A	Bron B	Bestemming A	PT=IP

   
   
   
2. Bij Peer A wordt de GRE keepalive ontcijferd:
   

   GRE IP-header		GRE	IP-header GRE Bron A Bestemming B  PT=0
   Bron B	Bestemming A	PT=IP

   
   
   Ontkapseld:
   

   IP-header		GRE
   Bron A	Bestemming B	PT=0

   
   
   Vervolgens wordt het binnenste GRE keepalive-antwoordpakket gerouteerd op basis van het bestemmingsadres dat Peer B is. Dat betekent dat op Peer A, het pakket onmiddellijk wordt gerouteerd terug uit de fysieke interface naar Peer B. Aangezien Peer A tunnelbescherming gebruikt op de tunnelinterface, is het keepalive-pakket niet gecodeerd.
   
   Daarom wordt het pakket verzonden van Peer A naar Peer B:
   

   IP-header		GRE
   Bron A	Bestemming B	PT=0

   
   

   Opmerking: de keepalive is niet gecodeerd.

3. Peer B ontvangt nu een GRE-keepalive-respons die niet is gecodeerd op zijn fysieke interface, maar vanwege de crypto-kaart die is geconfigureerd op de fysieke interface, verwacht het een gecodeerd pakket en laat het dus vallen.

Daarom, hoewel de Peer A reageert op de keepalives en de router Peer B de antwoorden ontvangt, verwerkt het ze nooit en verandert het uiteindelijk het lijnprotocol van de tunnelinterface in de staat down.

Resultaat:

Keepalives ingeschakeld op Peer B omdat de tunnelstatus op Peer B verandert in omhoog/omlaag.

Scenario 2

Configuratie:

• Peer A maakt gebruik van Crypto Maps.
• Peer B maakt gebruik van tunnelbescherming.
• Keepalives zijn ingeschakeld op Peer B.
• IPsec-codering wordt uitgevoerd in de tunnelmodus.

In dit scenario, aangezien de GRE-keepalives zijn geconfigureerd op Peer B, zijn de sequentiegebeurtenissen wanneer een keepalive wordt gegenereerd als volgt:

1. Peer B genereert een keepalive-pakket dat GRE ingekapseld en vervolgens gecodeerd door de tunnelbescherming op de tunnelinterface en vervolgens doorgestuurd naar de fysieke interface.
   
   Pakket verzonden van peer B naar peer A:
   

   IP-header	ESP-koptekst	GRE IP-header	GRE-koptekst	IP-header GRE Bron A Bestemming B PT=0	ESP-aanhangwagen
   Bron B	Bestemming A	Bron B	Bestemming A	PT=IP

   
   
   
2. Bij Peer A wordt de GRE keepalive ontcijferd:
   

   GRE IP-header		GRE	IP-header GRE Bron A Bestemming B  PT=0
   Bron B	Bestemming A	PT=IP

   
   
   Ontkapseld:
   

   IP-header		GRE
   Bron A	Bestemming B	PT=0

   
   
   Vervolgens wordt het binnenste GRE keepalive-antwoordpakket gerouteerd op basis van het bestemmingsadres dat Peer B is. Dat betekent dat op Peer A, het pakket onmiddellijk wordt gerouteerd terug uit de fysieke interface naar Peer B. Omdat peer A cryptografische kaarten op de fysieke interface gebruikt, codeert het eerst dit pakket voordat het het doorstuurt.
   
   Daarom wordt het pakket verzonden van Peer A naar Peer B:
   

   IP-header		ESP-koptekst	IP-header GRE Bron A Bestemming B PT=0	ESP-aanhangwagen
   Bron B	Bestemming A

   
   

   Opmerking: de keepalive-respons is gecodeerd.

3. Peer B ontvangt nu een versleutelde GRE keepalive-respons waarvan de bestemming wordt doorgestuurd naar de tunnelinterface waar deze wordt gedecodeerd:
   

   IP-header		GRE
   Bron A	Bestemming B	PT=0

   
   Omdat Protocal Type is ingesteld op 0, weet Peer B dat dit een keepalive-reactie is en verwerkt het als zodanig.

Resultaat:

Keepalives ingeschakeld op Peer B bepalen met succes wat de tunnelstatus kan zijn op basis van de beschikbaarheid van de tunnelbestemming.

Scenario 3

Configuratie:

• Beide peers maken gebruik van tunnelbescherming.
• Keepalives zijn ingeschakeld op Peer B.
• IPsec-codering wordt uitgevoerd in de tunnelmodus.

Dit scenario is vergelijkbaar met Scenario 1 in die zin dat wanneer Peer A de gecodeerde keepalive ontvangt, deze wordt ontcijferd en gedecapsuleerd. Wanneer het antwoord echter weer wordt doorgestuurd, wordt het niet gecodeerd omdat Peer A tunnelbescherming gebruikt op de tunnelinterface. Peer B laat dus de niet-versleutelde keepalive-respons vallen en verwerkt deze niet.

Resultaat:

Keepalives ingeschakeld op Peer B omdat de tunnelstatus op Peer B verandert in omhoog/omlaag.

Tijdelijke oplossing

In dergelijke situaties waarin de GRE-pakketten moeten worden gecodeerd, zijn er drie mogelijke oplossingen:

1. Gebruik een cryptografische kaart op Peer A, tunnelbescherming op Peer B en schakel keepalives in op Peer B.
   
   Aangezien dit type configuratie meestal wordt gebruikt in hub-and-spoke-opstellingen en omdat het in dergelijke opstellingen belangrijker is dat de spreker zich bewust is van de bereikbaarheid van de hubs, is de oplossing om een dynamische cryptomap op de hub (Peer A) en tunnelbescherming op de spoke (Peer B) te gebruiken en GRE-keepalives op de spoke in te schakelen. Op deze manier, hoewel de GRE-tunnelinterface op de hub omhoog blijft, gaan de routeringsbuur en de routes door de tunnel verloren en kan de alternatieve route worden vastgesteld. Op de spaak kan het feit dat de tunnelinterface naar beneden is gegaan, deze activeren om een dialerinterface op te roepen en terug te bellen naar de hub (of een andere router op de hub) en vervolgens een nieuwe verbinding tot stand te brengen.
   
   
2. Gebruik iets anders dan GRE-keepalives om de bereikbaarheid van collega's te bepalen.
   
   Als beide routers zijn geconfigureerd met tunnelbeveiliging, kunnen GRE-tunnelklemmen niet in beide richtingen worden gebruikt. In dit geval is de enige optie om het routeringsprotocol of een ander mechanisme te gebruiken, zoals de Service Assurance Agent, om te ontdekken of de peer bereikbaar is of niet.
   
   
3. Gebruik cryptografische kaarten op Peer A en Peer B.
   
   Als beide routers zijn geconfigureerd met cryptografische kaarten, kan de tunnel keepalives in beide richtingen doorkomen en kunnen de GRE-tunnelinterfaces in beide of beide richtingen worden uitgeschakeld en een back-upverbinding maken. Dit is de meest flexibele optie.

Gerelateerde informatie

• RFC 1701: Generic Router Encapsulation (GRE)
• RFC 2890: Key and Sequence Number Extensions to GRE
• Generic Routing Encapsulation (GRE) Tunnel Keepalive
• IP-fragmentatie en PMTUD
• Overzicht van Keepalive Mechanisms op Cisco IOS
• Technische ondersteuning – Cisco Systems

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
4.0	15-Jun-2026	hercertificering
3.0	18-Apr-2025	Opmaak bijgewerkt en enkele grammatica- en spellingsfouten gecorrigeerd.
2.0	19-Dec-2022	Alt-tekst toegevoegd. Bijgewerkte inleiding, achtergronden, stijlvereisten en opmaak.
1.0	31-Oct-2014	Eerste vrijgave