Visão geral dos mecanismos de manutenção de atividade no Cisco IOS

Introdução

Este documento descreve os vários mecanismos de keepalive no Cisco IOS^®.

Informações de Apoio

As mensagens de manutenção de atividade são enviadas por um dispositivo de rede através de um circuito físico ou virtual para informar a outro dispositivo de rede que o circuito entre eles ainda funciona. Para que os keepalives funcionem, há dois fatores essenciais:

• O intervalo de keepalive é o período de tempo entre cada mensagem de keepalive enviada por um dispositivo de rede. Isso é sempre configurável.
• As tentativas de keepalive são o número de vezes em que o dispositivo continua a enviar pacotes de keepalive sem resposta antes de o estado ser alterado para "down". Para alguns tipos de keepalives, isso é configurável, enquanto para outros há um valor padrão que não pode ser alterado.

Mecanismos de manutenção de atividade da interface

Interfaces de Ethernet

Em meios de transmissão como uma Ethernet, os keepalives são ligeiramente exclusivos. Como há muitos vizinhos possíveis na Ethernet, o keepalive não é projetado para determinar se o caminho para qualquer vizinho específico no fio está disponível. Ele foi projetado apenas para verificar se o sistema local tem acesso de leitura e gravação ao próprio fio Ethernet. O roteador produz um pacote Ethernet com ele mesmo como o endereço MAC origem e destino e um código de tipo Ethernet especial de 0x9000. O hardware Ethernet envia esse pacote para o fio Ethernet e, em seguida, recebe imediatamente esse pacote de volta. Isso verifica o hardware de envio e recebimento no adaptador Ethernet e a integridade básica do fio.

Interfaces seriais

As interfaces seriais podem ter diferentes tipos de encapsulamentos e cada tipo de encapsulamento determina o tipo de keepalives que será usado.

Insira o comando keepalive no modo de configuração de interface para definir a frequência na qual um roteador envia pacotes ECHOREQ para seu peer:

• Para restaurar o sistema para o intervalo de keepalive padrão de 10 segundos, insira o comando keepalive com a palavra-chave no.
• Para desabilitar keepalives, insira o comando keepalive disable.

Note: O keepalive comando aplica-se às interfaces seriais que usam o HDLC (High-Level Data Link Control) ou o encapsulamento PPP. Ele não se aplica a interfaces seriais que usam encapsulamento Frame Relay.

Note: Para os tipos de encapsulamento PPP e HDLC, um keepalive de zero desabilita keepalives e é relatado na saída do comando show running-config como keepalive disable.

Keepalives HDLC

Outro mecanismo keepalive bem conhecido é o keepalives serial para HDLC. Os keepalives seriais são enviados para frente e para trás entre dois roteadores e os keepalives são reconhecidos. Com o uso de números de sequência para rastrear cada keepalive, cada dispositivo é capaz de confirmar se o peer HDLC recebeu o keepalive que enviou. Para o encapsulamento HDLC, três manutenções de atividades ignoradas fazem com que a interface seja desativada.

Ative o comando debug serial interface para uma conexão HDLC para permitir que o usuário veja manutenções de atividades geradas e enviadas:

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

Os keepalives HDLC contêm três partes para determinar se funcionam:

• O "myseq", que é nosso número crescente.
• O "mineseen" que é na verdade um reconhecimento do outro lado (incrementado) que diz que eles esperam este número de nós.
• O "yourseen", que é o nosso reconhecimento ao outro lado.

Note: Quando a diferença nos valores nos campos myseq e mineseen excede três no Roteador 2, a linha fica inativa e a interface é redefinida.

Como as manutenções de atividade HDLC são manutenções de atividade do tipo ECHOREQ, a frequência de manutenção de atividade é importante e é recomendável que elas correspondam exatamente em ambos os lados.  Se os temporizadores estiverem fora de sincronia, os números de sequência começarão a ficar fora de ordem. Por exemplo, se você definir um lado como 10 segundos e o outro como 25 segundos, ele ainda permitirá que a interface permaneça ativa, desde que a diferença de frequência não seja suficiente para fazer com que os números de sequência fiquem desativados por uma diferença de três.

Como uma ilustração de como os keepalives HDLC funcionam, o Roteador 1 e o Roteador 2 são conectados diretamente via Serial0/0 e Serial2/0, respectivamente. Para ilustrar como as manutenções de atividades HDCL com falha são usadas para rastrear os estados da interface, a serial 0/0 será desativada no roteador 1.

Roteador 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

Roteador 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 de PPP

Os keepalives PPP são um pouco diferentes dos keepalives HDLC. Diferentemente do HDLC, os keepalives PPP são mais parecidos com pings. Ambos os lados podem fazer ping entre si a seu próprio tempo. A ação negociada apropriada é SEMPRE responder a esse "ping". Portanto, para manutenções de atividade do PPP, a frequência ou o valor do temporizador são apenas localmente relevantes e não têm impacto no outro lado. Mesmo que um lado desative os keepalives, ele ainda RESPONDERÁ às solicitações de eco do lado que tem um temporizador keepalive. No entanto, ele nunca iniciará nenhum por conta própria.

Ative o comando debug ppp packet para uma conexão PPP para permitir que o usuário veja os keepalives PPP que são enviados:

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

e respostas que são recebidas:

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

Os keepalives PPP contêm três partes:

• Número de ID - usado para identificar a qual ECHOREQ o peer responde.
• Tipo de manutenção de atividade - ECHOREQ são manutenções de atividade enviadas pelo dispositivo de origem e ECHOREP são respostas enviadas pelo peer.
• Magic numbers - as notificações incluem os magic numbers do servidor e do cliente remoto. O peer valida o número mágico no pacote LCP Echo-Request e transmite o pacote LCP Echo-Reply correspondente que contém o número mágico negociado pelo roteador.

Para o encapsulamento PPP, cinco keepalives ignorados fazem com que a interface seja desativada

Interfaces de túnel GRE

O mecanismo de keepalive de túnel GRE é ligeiramente diferente do usado para interfaces Ethernet ou seriais. Ele permite que um lado origine e receba pacotes de keepalive de e para um roteador remoto, mesmo que o roteador remoto não suporte keepalives de GRE. Como o GRE é um mecanismo de tunelamento de pacotes para tunelamento de IP dentro do IP, um pacote de túnel IP do GRE pode ser criado dentro de outro pacote de túnel IP do GRE. Para keepalives de GRE, o remetente pré-compila o pacote de resposta de keepalive dentro do pacote de solicitação de keepalive original, de modo que a extremidade remota só precise fazer o desencapsulamento de GRE padrão do cabeçalho IP de GRE externo e, em seguida, encaminhar o pacote de GRE IP interno. Esse mecanismo faz com que a resposta de keepalive encaminhe a interface física em vez da interface de túnel. Para obter mais detalhes sobre o funcionamento de keepalives de túnel GRE, consulte Como funcionam os keepalives de GRE.

Keepalives de criptografia

Keepalives de IKE

As manutenções de atividades de Internet Key Exchange (IKE) são um mecanismo usado para determinar se um peer de VPN está ativo e é capaz de receber tráfego criptografado. Manutenções de atividade de criptografia separadas são necessárias além das manutenções de atividade de interface, pois os pares de VPN geralmente nunca são conectados back-to-back, portanto as manutenções de atividade de interface não fornecem informações suficientes sobre o estado do par de VPN.

Em dispositivos Cisco IOS, os keepalives IKE são ativados pelo uso de um método proprietário chamado Dead Peer Detection (DPD). Para permitir que o gateway envie DPDs ao peer, insira este comando no modo de configuração global:

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

Para desabilitar keepalives, use a forma "no" desse comando. Para obter mais informações sobre o que cada palavra-chave neste comando faz, consulte crypto isakmp keepalive. Para obter mais granularidade, os keepalives também podem ser configurados no perfil ISAKMP. Para obter mais detalhes, consulte Visão geral do perfil ISAKMP [Cisco IOS IPsec].

Keepalives de NAT

No caso de cenários em que um peer de VPN está por trás de uma conversão de endereço de rede (NAT), o NAT-Traversal é usado para criptografia. No entanto, durante os períodos de inatividade, é possível que a entrada NAT no dispositivo upstream possa expirar. Isso pode causar problemas quando você ativar o túnel e o NAT não for bidirecional. Os keepalives de NAT são ativados para manter o mapeamento de NAT dinâmico ativo durante uma conexão entre dois peers. Os keepalives de NAT são pacotes UDP com um payload não criptografado de um byte. Embora a implementação atual de DPD seja semelhante a manutenções de atividades de NAT, há uma pequena diferença - o DPD é usado para detectar o status do peer enquanto manutenções de atividades de NAT são enviadas se a entidade IPsec não enviou ou recebeu o pacote em um período de tempo especificado. O intervalo válido é de 5 a 3600 segundos.