Descripción General de los Mecanismos Keepalive en Cisco IOS

Introducción

Este documento describe los diversos mecanismos de keepalive en Cisco IOS^®.

Antecedentes

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 aún funciona. Para que las señales de mantenimiento funcionen, existen dos factores esenciales:

• El intervalo de keepalive es el período de tiempo entre cada mensaje de keepalive enviado por un dispositivo de red. Esto siempre se puede configurar.
• Los reintentos de keepalive son el número de veces que el dispositivo continúa enviando paquetes keepalive sin respuesta antes de que el estado cambie a "down". Para algunos tipos de señales de mantenimiento esto es configurable, mientras que para otros hay un valor predeterminado que no se puede cambiar.

Mecanismos Keepalive de Interfaz

Interfaces Ethernet

En los medios de difusión como Ethernet, las señales de mantenimiento son ligeramente únicas. Debido a que hay muchos vecinos posibles en la Ethernet, la señal de mantenimiento no está diseñada para determinar si la trayectoria a cualquier vecino particular en el cable está disponible. Sólo está diseñado para comprobar que el sistema local tiene acceso de lectura y escritura al propio cable Ethernet. El router produce un paquete Ethernet con sí mismo como 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.

Interfaces en serie

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 interfaz para establecer la frecuencia en la que un router envía paquetes ECHOREQ a su par:

• Para restaurar el sistema al intervalo predeterminado de keepalive de 10 segundos, ingrese el comando keepalive con la palabra clave no.
• Para inhabilitar keepalives, ingrese el comando keepalive disable.

Nota: El keepalive comando se aplica a las interfaces seriales que utilizan el High-Level Data Link Control (HDLC) o la encapsulación PPP. No se aplica a las interfaces seriales que utilizan encapsulación Frame Relay.

Nota: Para ambos tipos de encapsulación PPP y HDLC, un keepalive de cero inhabilita los keepalives y se informa en el resultado del comando show running-config como keepalive disable.

Keepalives HDLC

Otro mecanismo conocido de keepalive son los keepalives seriales para HDLC. Los keepalives seriales se envían de ida y vuelta entre dos routers y se reconocen los keepalives. Con el uso de números de secuencia para rastrear cada señal de mantenimiento, cada dispositivo puede confirmar si su par HDLC recibió la señal de mantenimiento que envió. Para la encapsulación HDLC, tres señales de mantenimiento ignoradas hacen que la interfaz se desactive.

Habilite el comando debug serial interface para una conexión HDLC para permitir que el usuario vea señales de mantenimiento que se generan y envían:

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

Los keepalives HDLC contienen tres partes para determinar su funcionamiento:

• El "myseq" que es nuestro propio número creciente.
• El "mineseen" que es en realidad un reconocimiento del otro lado (incrementado) que dice que esperan este número de nosotros.
• El "yourseen" que es nuestro reconocimiento al otro lado.

Nota: Cuando la diferencia en los valores de los campos myseq y mineseen excede tres en el Router 2, la línea se desactiva y la interfaz se reinicia.

Dado que los keepalives HDLC son keepalives 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 comienzan a desordenarse. Por ejemplo, si configura un lado en 10 segundos y el otro en 25 segundos, aún permitirá que la interfaz permanezca activa mientras la diferencia de frecuencia no sea suficiente para hacer 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, los routers 1 y 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 rastrear 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

Keepalives PPP

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 son más parecidas a pings. Ambas partes pueden hacer ping entre ellas cuando lo deseen. El movimiento negociado adecuado 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 a nivel local y no tienen impacto en el otro lado. Incluso si un lado desactiva las señales de mantenimiento, responderá a las solicitudes de eco del lado que tiene un temporizador de señal de mantenimiento. Sin embargo, nunca iniciará ninguno de los suyos.

Habilite el comando debug ppp packet para una conexión PPP para permitir que el usuario vea los keepalives PPP que se envían:

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

y las 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:

• Número de ID: se utiliza para identificar a qué ECHOREQ responde el par.
• Tipo de keepalive: ECHOREQ son keepalives enviados por el dispositivo de origen y ECHOREP son respuestas enviadas por el peer.
• Números mágicos: las notificaciones incluyen los números mágicos tanto del servidor como del cliente remoto. El par valida el número mágico en el paquete de solicitud de eco LCP y transmite el paquete de respuesta de eco LCP correspondiente que contiene el número mágico negociado por el router.

Para la encapsulación PPP, cinco señales de mantenimiento ignoradas hacen que la interfaz se desactive

Interfaces de túnel GRE

El mecanismo de señal de mantenimiento del túnel GRE es ligeramente diferente al de las interfaces Ethernet o seriales. Ofrece a un lado la capacidad de originar y recibir paquetes keepalive hacia y desde un router remoto incluso si el router remoto no admite keepalives GRE. Dado que GRE es un mecanismo de tunelización de paquetes para tunelizar IP dentro de IP, se puede construir un paquete de túnel IP GRE dentro de otro paquete de túnel IP GRE. Para las señales de mantenimiento GRE, el remitente preconstruye el paquete de respuesta de señal de mantenimiento dentro del paquete de solicitud de señal de mantenimiento original de modo que el extremo remoto solo necesita realizar una desencapsulación GRE estándar del encabezado IP GRE externo y luego reenviar el paquete GRE IP interno. Este mecanismo hace que la respuesta de keepalive reenvíe fuera de la interfaz física en lugar de la interfaz de túnel. Para obtener más detalles sobre el funcionamiento de los keepalives de túnel GRE, vea Cómo funcionan los keepalives de GRE.

Keepalives de criptografía

Keepalives IKE

Las señales de mantenimiento de Intercambio de claves de Internet (IKE) son un mecanismo que se utiliza para determinar si un par VPN está activo y puede recibir tráfico cifrado. Se requieren señales de mantenimiento de criptografía separadas además de señales de mantenimiento de interfaz porque los pares VPN generalmente nunca se conectan uno tras otro, por lo que las señales de mantenimiento de 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 patentado denominado Dead Peer Detection (DPD). Para permitir que el gateway envíe DPD al peer, ingrese este comando en el modo de configuración global:

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

Para inhabilitar los keepalives, utilice la forma "no" de este comando. Para obtener más información sobre qué hace cada palabra clave de este comando, vea crypto isakmp keepalive. Para mayor granularidad, las señales de mantenimiento también se pueden configurar bajo el perfil ISAKMP. Para obtener más detalles, vea Descripción general del perfil ISAKMP [Cisco IOS IPsec].

Keepalives de NAT

En el caso de escenarios donde un par VPN está detrás de una traducción de direcciones de red (NAT), NAT-Traversal se utiliza para el cifrado. Sin embargo, durante los períodos de inactividad es posible que la entrada NAT en el dispositivo ascendente agote el tiempo de espera. Esto puede causar problemas cuando se activa el túnel y NAT no es bidireccional. Los keepalives de NAT están habilitados para mantener el mapping dinámico de NAT activo durante una conexión entre dos peers. Los keepalives NAT son paquetes UDP con una carga útil no encriptada de un byte. Aunque la implementación de DPD actual es similar a los keepalives NAT, hay una pequeña diferencia: DPD se utiliza para detectar el estado del peer mientras que los keepalives NAT se envían si la entidad IPsec no envió o recibió el paquete en un período de tiempo especificado. El intervalo válido es de 5 a 3600 segundos.