Dit document beschrijft de verschillende beheermechanismen op Cisco IOS®.
Levende berichten worden verzonden door een netwerkapparaat via een fysiek of virtueel circuit om een ander netwerkapparaat te informeren dat het circuit tussen hen nog steeds functioneert. Voor keepaliven om te werken zijn er twee essentiële factoren:
Op uitzendmedia zoals een Ethernet zijn keepalives iets uniek. Omdat er veel mogelijke buren op Ethernet zijn, is het keeplevend niet ontworpen om te bepalen of het pad naar een bepaalde buurman op de draad beschikbaar is. Het is uitsluitend ontworpen om te controleren of het lokale systeem toegang tot de Ethernet-draad zelf heeft gelezen en geschreven. De router produceert een Ethernet-pakket met zichzelf als bron en bestemming MAC-adres en een speciale Ethernet-type code van 0x9000. De Ethernet hardware stuurt dit pakket naar de Ethernet-draad en ontvangt dan onmiddellijk dit pakket opnieuw. Dit controleert de verzendende en ontvangende hardware op de Ethernet-adapter en de basisintegriteit van de draad.
De seriële interfaces kunnen verschillende types van insluitingen hebben en elk insluitingstype bepaalt het soort keepalives dat zal worden gebruikt.
Voer de opdracht keeplevend in de interface-configuratiemodus in om de frequentie in te stellen waarmee een router ECHOREQ-pakketten naar zijn peer stuurt:
Een ander bekend houdmechanisme is seriële keepalives voor HDLC. Seriële keepalives worden heen en weer verzonden tussen twee routers en de keepalives worden erkend. Met het gebruik van sequentienummers om elke keeplive te volgen, kan elk apparaat bevestigen of het HDLC peer de verzonden keeplevorming heeft ontvangen. Voor HDLC-insluiting zorgen drie genegeerde keepalives ervoor dat de interface wordt verlaagd.
Schakel het opdracht debug seriële interface in voor een HDLC-verbinding om de gebruiker toe te staan keepalives te zien die gegenereerd en verzonden worden:
Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
HDLC-keepalives bevatten drie stukken om te bepalen dat het werkt:
Aangezien HDLC-keepalives ECHOREQ-type keepalives zijn, is de frequentie van het behouden van de dieren belangrijk en wordt aanbevolen deze aan beide zijden exact op elkaar af te stemmen. Als de timers niet zijn gesynchroniseerd, beginnen de sequentienummers uit orde te raken. Bijvoorbeeld, als je de ene kant op 10 seconden instelt en de andere op 25 seconden, dan zal de interface blijven bestaan zolang het verschil in frequentie niet voldoende is om de sequentienummers met een verschil van drie uit te zetten.
Als illustratie van hoe HDLC het werk in stand houdt, worden router 1 en router 2 direct aangesloten via respectievelijk Seriële0/0 en Serial2/0. Om aan te geven hoe de defecte HDCL-keepalives worden gebruikt om de interfacestaten te volgen, zal Seriële 0/0 op Router 1 worden uitgeschakeld.
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 keepalives zijn een beetje anders dan HDLC-keepalives. In tegenstelling tot HDLC lijken PPP-keepalives meer op pings. Beide kanten kunnen elkaar in hun vrije tijd pingelen. De juiste stap in de onderhandelingen is om ALTIJD te reageren op deze ‘ping'. Dus voor PPP keepalives zijn de frequentie of de timer waarde slechts lokaal relevant en hebben deze geen impact op de andere kant. Zelfs als de ene kant de keepalives uitzet, zal het nog steeds reageren op die echo-verzoeken van de kant die een sluitingtimer hebben. Maar het zal nooit een eigen initiatief nemen.
Schakel het opdracht debug ppp voor een PPP-verbinding in om de gebruiker in staat te stellen de PPP-toetsen te zien die worden verzonden:
17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325
en ontvangen reacties:
17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D
PPP keepalives bevatten drie stukken:
Voor PPP-insluiting zorgen vijf genegeerde keepalives ervoor dat de interface wordt verlaagd
Het GRE-tunnelbeheermechanisme is iets anders dan voor Ethernet- of seriële interfaces. Het geeft de mogelijkheid voor één kant om levendige pakketten aan en van een verre router te produceren en te ontvangen zelfs als de afstandsrouter geen GRE keepalives ondersteunt. Aangezien GRE een pakkettunnelmechanisme is voor het tunnelen van IP in IP, kan een GRE IP-tunnelpakket in een ander GRE IP-tunnelpakket worden gebouwd. Voor GRE keepalives bouwt de afzender het pakket van de keeplevende reactie binnen het originele pakket van de keeplevende om te vragen zodat het verre eind slechts standaard GRE decapsulation van de buitenste GRE IP header moet uitvoeren en dan het binnenste IP GRE-pakket door sturen. Dit mechanisme veroorzaakt de aanhoudende respons om de fysieke interface uit te sturen in plaats van de tunnelinterface. Voor meer informatie over het werken van GRE-tunneleigenschappen, zie hoe GRE Keepalives werkt.
De keepalives van Internet Key Exchange (IKE) zijn een mechanisme dat wordt gebruikt om te bepalen of een VPN-peer 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 rug worden aangesloten, zodat de interface keepalives niet genoeg informatie over staat van de VPN peer verstrekken.
Op Cisco IOS-apparaten worden IKE-keepalives geactiveerd door het gebruik van een eigen methode die Dead Peer Detection (DPD) wordt genoemd. Om de gateway toe te staan om DPDs naar de peer te verzenden, voer deze opdracht in globale configuratiewijze:
crypto isakmp keepalive seconds [retry-seconds] [ periodic | on-demand ]
Gebruik het "nee" formulier van deze opdracht om keepalives uit te schakelen. Voor meer informatie over wat elk sleutelwoord in deze opdracht doet, zie crypto isakmp keeplevend. Voor een grotere granulariteit kunnen de keepalives ook worden geconfigureerd onder het ISAKMP-profiel. Zie ISAKMP Profile - Overzicht [Cisco IOS IPsec] voor meer informatie.
In geval van scenario's waar één VPN-peer achter een Network adresomzetting (NAT) zit, wordt NAT-Traversal gebruikt voor encryptie. Tijdens stationaire periodes is het echter mogelijk dat het NAT-punt op het upstream-apparaat uitvalt. Dit kan problemen veroorzaken als je de tunnel omhoog brengt en NAT is niet tweerichtings. NAT-keepalives zijn ingeschakeld om de dynamische NAT-omzetting levend te houden tijdens een verbinding tussen twee peers. NAT-keepalives zijn UDP-pakketten met een niet-versleutelde lading van één byte. Hoewel de huidige DPD-implementatie gelijk is aan NAT-keepalives, is er een klein verschil - DPD wordt gebruikt om peer status te detecteren terwijl NAT-keepalives worden verzonden als de IPsec-entiteit het pakket niet op een bepaalde tijd heeft verzonden of ontvangen. Het geldige bereik ligt tussen 5 en 3600 seconden.
Zie IPsec NAT Transparency voor meer informatie over deze optie.