Este documento describe los diversos mecanismos de keepalive en Cisco IOS®.
Los mensajes de señal de mantenimiento son enviados por un dispositivo de red a través de un circuito físico o virtual para informar a otro dispositivo de red que el circuito entre ellos todavía funciona. Para que las señales de mantenimiento funcionen, hay dos factores esenciales:
En los medios de difusión como Ethernet, las señales de mantenimiento son ligeramente únicas. Dado que hay muchos vecinos posibles en la Ethernet, la señal de mantenimiento no está diseñada para determinar si la trayectoria a un vecino en particular en el cable está disponible. Sólo está diseñado para verificar que el sistema local tenga acceso de lectura y escritura al propio cable Ethernet. El router produce un paquete Ethernet consigo mismo como la dirección MAC de origen y destino y un código de tipo Ethernet especial de 0x9000. El hardware Ethernet envía este paquete al cable Ethernet y, a continuación, recibe inmediatamente este paquete de nuevo. Esto verifica el hardware de envío y recepción en el adaptador Ethernet y la integridad básica del cable.
Las interfaces seriales pueden tener diferentes tipos de encapsulaciones y cada tipo de encapsulación determina el tipo de señales de mantenimiento que se utilizarán.
Ingrese el comando keepalive en el modo de configuración de la interfaz para establecer la frecuencia con la que un router envía paquetes ECHOREQ a su peer:
Otro mecanismo de keepalive conocido es keepalives seriales para HDLC. Las señales de mantenimiento seriales se envían de ida y vuelta entre dos routers y se reconocen las señales de mantenimiento. Con el uso de números de secuencia para realizar el seguimiento de cada señal de mantenimiento, cada dispositivo puede confirmar si su par HDLC recibió la señal de mantenimiento enviada. Para la encapsulación HDLC, tres keepalives ignoradas hacen que la interfaz se desactive.
Habilite el comando debug serial interface para una conexión HDLC para permitir al usuario ver señales de mantenimiento que se generan y se envían:
Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
Las señales de mantenimiento HDLC contienen tres partes para determinar que funcionan:
Dado que las señales de mantenimiento HDLC son señales de mantenimiento del tipo ECHOREQ, la frecuencia de keepalive es importante y se recomienda que coincidan exactamente en ambos lados. Si los temporizadores no están sincronizados, los números de secuencia empiezan a desordenarse. Por ejemplo, si configura un lado en 10 segundos y el otro en 25 segundos, seguirá permitiendo que la interfaz permanezca activa siempre y cuando la diferencia de frecuencia no sea suficiente para que los números de secuencia se desactiven por una diferencia de tres.
Como ilustración de cómo funcionan las señales de mantenimiento HDLC, el router 1 y el router 2 están conectados directamente a través de Serial0/0 y Serial2/0 respectivamente. Para ilustrar cómo se utilizan los keepalives HDCL fallidos para realizar el seguimiento de los estados de la interfaz, el Serial 0/0 se apagará en el 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
Las señales de mantenimiento PPP son un poco diferentes de las señales de mantenimiento HDLC. A diferencia de HDLC, las señales de mantenimiento PPP se parecen más a los pings. Ambas partes pueden hacer ping entre ellas a su gusto. La acción negociada adecuada es responder SIEMPRE a este "ping". Por lo tanto, para las señales de mantenimiento PPP, la frecuencia o el valor del temporizador son sólo relevantes localmente y no tienen impacto en el otro lado. Incluso si un lado apaga las señales de mantenimiento, seguirá RESPONDIENDO a esas solicitudes de eco del lado que tiene un temporizador de keepalive. Sin embargo, nunca iniciará ninguna de las suyas.
Habilite el comando debug ppp packet para una conexión PPP para permitir que el usuario vea las señales de mantenimiento PPP que se envían:
17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325
y respuestas recibidas:
17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D
Las señales de mantenimiento PPP contienen tres partes:
Para la encapsulación PPP, cinco keepalives ignoradas hacen que la interfaz se desactive
El mecanismo de señal de mantenimiento del túnel GRE es ligeramente diferente al de las interfaces Ethernet o seriales. Ofrece la capacidad de que un lado origine y reciba paquetes keepalive hacia y desde un router remoto incluso si el router remoto no soporta keepalives GRE. Dado que GRE es un mecanismo de tunelización de paquetes para tunelizar IP dentro de IP, un paquete de túnel IP GRE se puede construir dentro de otro paquete de túnel IP GRE. Para señales de mantenimiento GRE, el remitente genera previamente el paquete de respuesta de keepalive dentro del paquete de solicitud de keepalive original, de modo que el extremo remoto sólo necesita hacer la desencapsulación GRE estándar del encabezado IP GRE externo y luego reenviar el paquete IP GRE interno. Este mecanismo hace que la respuesta de keepalive reenvíe la interfaz física en lugar de la interfaz de túnel. Para obtener más detalles sobre el funcionamiento de señales de mantenimiento de túnel GRE, vea Cómo funcionan las señales de mantenimiento GRE.
Las señales de mantenimiento de Internet Key Exchange (IKE) son un mecanismo utilizado para determinar si un par VPN está activo y puede recibir tráfico cifrado. Se requieren señales de mantenimiento criptográficas independientes además de señales de mantenimiento de la interfaz porque los peers VPN generalmente nunca se conectan de nuevo a la parte posterior, por lo que las señales de mantenimiento de la interfaz no proporcionan suficiente información sobre el estado del par VPN.
En los dispositivos Cisco IOS, las señales de mantenimiento IKE se habilitan mediante el uso de un método propietario denominado Dead Peer Detection (DPD). Para permitir que el gateway envíe DPDs al par, ingrese este comando en el modo de configuración global:
crypto isakmp keepalive seconds [retry-seconds] [ periodic | on-demand ]
Para inhabilitar keepalives, utilice la forma "no" de este comando. Para obtener más información sobre lo que hace cada palabra clave en este comando, vea crypto isakmp keepalive. Para obtener más granularidad, las señales de mantenimiento también se pueden configurar en el perfil ISAKMP. Para obtener más detalles, vea Descripción General del Perfil ISAKMP [Cisco IOS IPsec].
En el caso de situaciones en las que un par VPN se encuentra detrás de una traducción de direcciones de red (NAT), NAT-Traversal se utiliza para el cifrado. Sin embargo, durante los períodos inactivos es posible que la entrada NAT en el dispositivo ascendente se agote el tiempo de espera. Esto puede causar problemas cuando se activa el túnel y NAT no es bidireccional. Las señales de mantenimiento NAT se habilitan para mantener la asignación NAT dinámica activa durante una conexión entre dos peers. Las señales de mantenimiento NAT son paquetes UDP con una carga útil no cifrada de un byte. Aunque la implementación de DPD actual es similar a las señales de mantenimiento de NAT, hay una ligera diferencia - DPD se utiliza para detectar el estado de peer mientras se envían señales de mantenimiento de NAT si la entidad de IPsec no envió o recibió el paquete en un período de tiempo especificado. El intervalo válido es de 5 a 3600 segundos.
Para obtener más información sobre esta función, vea Transparencia NAT IPSec.