Overzicht van Keepalive Mechanisms op Cisco IOS

Inleiding

Dit document beschrijft de verschillende keepalive-mechanismen op Cisco IOS^®.

Achtergrondinformatie

Keepalive-berichten worden door een netwerkapparaat via een fysiek of virtueel circuit verzonden om een ander netwerkapparaat te informeren dat het circuit tussen hen nog steeds functioneert. Voor keepalives om te werken zijn er twee essentiële factoren:

• Het keepalive-interval is de tijdsperiode tussen elk keepalive-bericht dat door een netwerkapparaat wordt verzonden. Dit is altijd configureerbaar.
• De keepalive-herhalingen is het aantal keren dat het apparaat blijft keepalive-pakketten verzenden zonder reactie voordat de toestand wordt gewijzigd in "down". Voor sommige soorten keepalives is dit configureerbaar, terwijl voor andere een standaardwaarde is die niet kan worden gewijzigd.

Interface Keepalive-mechanismen

Ethernet-interfaces

Op uitzendmedia zoals een Ethernet zijn keepalives enigszins uniek. Omdat er veel mogelijke buren op het Ethernet zijn, is de keepalive niet ontworpen om te bepalen of het pad naar een bepaalde buur op de draad beschikbaar is. Het is alleen ontworpen om te controleren of het lokale systeem lees- en schrijftoegang heeft tot de Ethernet-kabel zelf. De router produceert een Ethernet-pakket met zichzelf als bron- en bestemmings-MAC-adres en een speciale Ethernet-code van 0x9000. De Ethernet-hardware stuurt dit pakket naar de Ethernet-draad en ontvangt dit pakket vervolgens onmiddellijk weer terug. Hiermee worden de verzend- en ontvangsthardware op de Ethernet-adapter en de basisintegriteit van de kabel gecontroleerd.

Seriële interfaces

Seriële interfaces kunnen verschillende soorten inkapselingen hebben en elk inkapselingstype bepaalt het soort keepalives dat wordt gebruikt.

Voer de opdracht keepalive in de interfaceconfiguratiemodus in om de frequentie in te stellen waarmee een router ECHOREQ-pakketten naar zijn peer verzendt:

• Als u het systeem wilt terugzetten naar het standaardinterval van 10 seconden om het systeem in leven te houden, voert u de opdracht KeepAlive in met het trefwoord geen.
• Om keepalives uit te schakelen, voert u de opdracht keepalive disable in.

Opmerking: De opdracht keepalive is van toepassing op seriële interfaces die gebruikmaken van High-Level Data Link Control (HDLC) of PPP-inkapseling. Het is niet van toepassing op seriële interfaces die Frame Relay-inkapseling gebruiken.

Opmerking: voor zowel PPP- als HDLC-inkapselingstypen schakelt een keepalive van nul keepalives uit en wordt in de show running-config command output gerapporteerd als keepalive disable.

HDLC Keepalives

Een ander bekend keepalive-mechanisme is seriële keepalives voor HDLC. Seriële keepalives worden heen en weer gestuurd tussen twee routers en de keepalives worden erkend. Met het gebruik van volgnummers om elke keepalive te volgen, kan elk apparaat bevestigen of het HDLC-peer de keepalive heeft ontvangen die het heeft verzonden. Voor HDLC-inkapseling zorgt drie genegeerde keepalives ervoor dat de interface naar beneden wordt gehaald.

Schakel de opdracht voor de foutopsporingsinterface voor een HDLC-verbinding in zodat de gebruiker de levenden kan zien die worden gegenereerd en verzonden:

Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up

HDLC keepalives bevatten drie onderdelen om te bepalen of het werkt:

• De "myseq" is ons eigen oplopende aantal.
• De "minessee" die eigenlijk een erkenning is van de andere kant (verhoogd) die zegt dat ze dit aantal van ons verwachten.
• Het "jouwe zien" is onze erkenning aan de andere kant.

Opmerking: Wanneer het verschil in de waarden in de velden myseq en minesen groter is dan drie op Router 2, gaat de lijn omlaag en wordt de interface gereset.

Aangezien HDLC keepalives van het ECHOREQ-type keepalives zijn, is de keepalive-frequentie belangrijk en wordt aanbevolen dat ze precies aan beide zijden overeenkomen.  Als de timers niet synchroon lopen, beginnen de volgnummers uit de orde te raken. Als u bijvoorbeeld de ene zijde instelt op 10 seconden en de andere op 25 seconden, blijft de interface omhoog staan zolang het frequentieverschil niet voldoende is om de volgnummers met een verschil van drie te laten afwijken.

Ter illustratie van hoe HDLC-keepalives werken, zijn Router 1 en Router 2 rechtstreeks verbonden via respectievelijk Serial0/0 en Serial2/0. Om te illustreren hoe mislukte HDCL-keepalives worden gebruikt om de interfacestatus te volgen, wordt Serial 0/0 afgesloten op Router 1.

Router 1

Router1#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.1/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
    [output is omited]

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

Router 2

Router2#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.2/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
    [output is omited]


17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up 
17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up 
17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up 
17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up 
17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up 
17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up 
17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up 
17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up 
17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up 
17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up 
17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up 
17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up 
17:23:05.153: HD(0): Reset from 0x203758
17:23:05.153: HD(0): Asserting DTR 
17:23:05.153: HD(0): Asserting DTR and RTS 
17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up 
17:23:15.173: HD(0): Reset from 0x203758
17:23:15.173: HD(0): Asserting DTR 
17:23:15.173: HD(0): Asserting DTR and RTS 
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

PPP houdt levens

PPP keepalives zijn een beetje anders dan HDLC keepalives. In tegenstelling tot HDLC, PPP keepalives zijn meer als pings. Beide partijen kunnen elkaar op hun gemak pingen. De juiste onderhandelde stap is om ALTIJD te reageren op deze "ping". Dus voor PPP-levenden zijn de frequentie of de timerwaarde alleen lokaal relevant en hebben ze geen invloed op de andere kant. Zelfs als één kant de keepalives uitschakelt, reageert deze nog steeds op die echoverzoeken van de kant die wel een keepalive-timer heeft. Het zal echter nooit een eigen initiatief nemen.

Schakel de opdracht PPP-pakket debuggen in voor een PPP-verbinding zodat de gebruiker de PPP-alives kan zien die worden verzonden:

17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325

en de ontvangen antwoorden:

17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D

Gewasbeschermingsmiddelen bevatten drie onderdelen:

• ID-nummer - gebruikt om te bepalen op welke ECHOREQ de peer reageert.
• Keepalive type - ECHOREQ zijn keepalives verzonden door het oorspronkelijke apparaat en ECHOREP zijn antwoorden verzonden door de peer.
• Magische nummers - de meldingen bevatten de magische nummers van zowel de server als de externe client. De peer valideert het magische nummer in het LCP Echo-Request-pakket en verzendt het bijbehorende LCP Echo-Reply-pakket dat het magische nummer bevat dat door de router is overeengekomen.

Voor PPP-inkapseling zorgt vijf genegeerde keepalives ervoor dat de interface naar beneden wordt gehaald

GRE-tunnelinterfaces

Het GRE tunnel keepalive-mechanisme is iets anders dan voor Ethernet- of seriële interfaces. Het geeft de mogelijkheid voor één kant om te beginnen en ontvangen keepalive pakketten van en naar een externe router, zelfs als de externe router geen ondersteuning GRE keepalives. 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 in het originele 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 doorstuurt. Dit mechanisme zorgt ervoor dat de keepalive-reactie de fysieke interface doorstuurt in plaats van de tunnelinterface. Voor meer informatie over de werking van GRE tunnel keepalives, zie Hoe GRE Keepalives werken.

Crypto Keepalives

IKE Keepalives

Internet Key Exchange (IKE) keepalives zijn een mechanisme dat wordt gebruikt om te bepalen of een VPN-peer actief is en in staat is om versleuteld verkeer te ontvangen. Afzonderlijke crypto-keepalives zijn vereist naast interface-keepalives omdat VPN-peers over het algemeen nooit terug naar achter zijn verbonden, dus interface-keepalives bieden niet genoeg informatie over de status van de VPN-peer.

Op Cisco IOS-apparaten worden IKE keepalives ingeschakeld door het gebruik van een eigen methode genaamd Dead Peer Detection (DPD). Als u wilt dat de gateway DPD's naar de peer verzendt, voert u deze opdracht in de globale configuratiemodus in:

crypto isakmp keepalive seconds  [retry-seconds]  [ periodic | on-demand ]

Om keepalives uit te schakelen, gebruikt u de vorm "nee" van dit commando. Voor meer informatie over wat elk zoekwoord in deze opdracht doet, zie crypto isakmp keepalive. Voor meer granulariteit kunnen de keepalives ook worden geconfigureerd onder het ISAKMP-profiel. Zie ISAKMP-profieloverzicht [Cisco IOS IPsec] voor meer informatie.

NAT Keepalives

In het geval van scenario's waarbij één VPN-peer achter een Network Address Translation (NAT) zit, wordt NAT-Traversal gebruikt voor codering. Tijdens inactieve perioden is het echter mogelijk dat de NAT-vermelding op het upstream-apparaat een time-out kan veroorzaken. Dit kan problemen veroorzaken wanneer u de tunnel omhoog brengt en NAT niet bidirectioneel is. NAT-keepalives zijn ingeschakeld om de dynamische NAT-mapping levend te houden tijdens een verbinding tussen twee peers. NAT-keepalives zijn UDP-pakketten met een niet-versleutelde payload van één byte. Hoewel de huidige DPD-implementatie vergelijkbaar is met NAT-keepalives, is er een klein verschil - DPD wordt gebruikt om de peer-status te detecteren terwijl NAT-keepalives worden verzonden als de IPsec-entiteit het pakket niet op een bepaalde periode heeft verzonden of ontvangen. Het geldige bereik ligt tussen 5 en 3600 seconden.