Rede de conteúdo : Keepalives

Vista geral dos mecanismos keepalive no Cisco IOS

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

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

Contribuído por Atri Basu e por Michael Sullenberger, engenheiros de TAC da Cisco.

Informações de Apoio

Os mensagens de keepalive são enviados por um dispositivo de rede através de um exame ou de uns circuitos virtuais a fim informar ainda um outro dispositivo de rede esse o circuito entre eles funções. Para que o Keepalives trabalhe há dois fatores essenciais:

  • O intervalo keepalive é o período de tempo entre cada mensagem de keepalive que é enviado por um dispositivo de rede. Isto é sempre configurável.
  • As novas tentativas do keepalive são o número de vezes que o dispositivo continua a enviar a pacotes keepalive sem resposta antes que o estado esteja mudado a “para baixo”. Para alguns tipos de Keepalives isto é configurável, quando para outro houver um valor padrão que não possa ser mudado.

Mecanismos do keepalive de interface

Interfaces de Ethernet

Em meios de transmissão tais como um Ethernet, o Keepalives é levemente original. Desde que há muitos possíveis vizinhos nos Ethernet, o keepalive não está projetado determinar se o trajeto a qualquer um vizinho específico no fio está disponível. Projeta-se somente certificar-se do sistema local tenha o acesso de leitura e gravação ao fio dos Ethernet próprio. O roteador produz um pacote de Ethernet com se como o endereço MAC de origem e de destino e um código tipo de Ethernet especial de 0x9000. O hardware de Ethernet envia este pacote no fio dos Ethernet e então recebe imediatamente esta parte traseira do pacote outra vez. Isto verifica o hardware de emissão e de recepção no adaptador do Ethernet e a integridade básica do fio.

Interfaces seriais

As interfaces serial podem ter tipos diferentes de encapsulamentos e cada tipo de encapsulamento determina o tipo do Keepalives que será usado.

Inscreva o comando keepalive no modo de configuração da interface a fim ajustar a frequência em que um roteador envia pacotes ECHOREQ a seu par:

  • A fim restaurar o sistema ao intervalo keepalive do padrão dos segundos 10, inscreva o comando keepalive com nenhuma palavra-chave.
  • A fim desabilitar o Keepalives, inscreva o comando disable do keepalive.

Nota: keepalive O comando aplica-se às interfaces serial que usam o link de dados de nível elevado Contol (HDLC) ou o encapsulamento PPP. Não se aplica às interfaces serial que usam o Encapsulamento frame relay.

Nota: Para o PPP e os tipos do encapsulamento de HDLC, um keepalive de zero desabilita o Keepalives e é relatado no comando show running-config output como o desabilitação do keepalive.

Manutenções de atividade de HDLC

Um outro mecanismo keepalive conhecido é manutenções de atividade serial para o HDLC. As manutenções de atividade serial são enviadas para a frente e para trás entre dois Roteadores e o Keepalives são reconhecidos. Com o uso dos números de sequência seguir cada keepalive, cada dispositivo pode confirmar se é par HDLC recebeu o keepalive que enviou. Para o encapsulamento de HDLC, três Keepalives ignorados fazem com que a relação seja derrubada.

Permita o comando debug serial interface para uma conexão de HDLC a fim permitir que o usuário ver o Keepalives que é gerado e enviado:

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

As manutenções de atividade de HDLC contêm três partes a fim determiná-lo trabalham:

  • O “myseq” que é nosso próprio número de incremento.
  • O “mineseen” que é realmente um reconhecimento do outro lado (incrementado) que diz que espera este número de nós.
  • “Yourseen” que é nosso reconhecimento ao outro lado.

Nota: Quando a diferença nos valores nos campos do myseq e do mineseen excede três no roteador2, a linha vai para baixo e a relação é restaurada.

Desde que as manutenções de atividade de HDLC são tipo Keepalives ECHOREQ, a frequência de keepalive é importante e recomenda-se que combinam acima exatamente em ambos os lados.  Se os temporizadores são fora da sincronização, os números de sequência começam sair da ordem. Por exemplo, se você ajusta um lado aos segundos 10 e o outro a 25 segundos, ainda permitirá a relação permaneça acima enquanto a diferença na frequência não é suficiente para fazer com que os números de sequência estejam por uma diferença de três.

Como uma ilustração de como as manutenções de atividade de HDLC trabalham, o roteador1 e o roteador2 são conectados diretamente através do Serial0/0 e do Serial2/0 respectivamente. A fim ilustrar como o Keepalives falhado HDCL é usado para seguir os estados da relação, o Serial0/0 será fechado no roteador1.

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

Manutenções de atividade de PPP

As manutenções de atividade de PPP são um pouco diferentes das manutenções de atividade de HDLC. Ao contrário do HDLC, as manutenções de atividade de PPP são mais como sibilos. Os ambos os lados podem sibilar-se em seu lazer. O movimento negociado apropriado é responder SEMPRE a este “sibilo”. Assim para manutenções de atividade de PPP, a frequência ou o valor de temporizador são somente localmente relevante e não têm nenhum impacto no outro lado. Mesmo se um lado desliga o Keepalives, ainda RESPONDERÁ 2 aquelas requisições de eco do lado que tem um temporizador de keepalive. Contudo, nunca iniciará alguma do seus próprios.

Permita o comando debug ppp packet para uma conexão PPP a fim permitir que o usuário ver as manutenções de atividade de PPP que são enviadas:

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

As manutenções de atividade de PPP contêm três partes:

  • Número de ID - usado para identificar a que o ECHOREQ o par responde.
  • Tipo keepalive - O ECHOREQ é Keepalives enviado pelo dispositivo de origem e o ECHOREP é respostas enviadas pelo par.
  • Números mágicos - as notificações incluem os números mágicos do server e do cliente remoto. O par valida o número mágico no pacote de requisição de eco LCP, e transmite o pacote de resposta de eco correspondente LCP que contém o número mágico negociado pelo roteador.

Para o encapsulamento PPP, cinco Keepalives ignorados fazem com que a relação seja derrubada

Interfaces do túnel GRE

O mecanismo keepalive do túnel GRE é levemente diferente do que para Ethernet ou interfaces serial. Dá a capacidade para que um lado origine e receba pacotes keepalive a e de um roteador remoto mesmo se o roteador remoto não apoia manutenções de atividade de GRE. Desde que o GRE é um mecanismo de tunelamento do pacote para escavar um túnel o IP dentro do IP, um pacote do túnel IP GRE pode ser construído dentro de um outro pacote do túnel IP GRE. Para manutenções de atividade de GRE, as PRE-construções do remetente o pacote da resposta de keepalive dentro do pacote de requisição do keepalive original de modo que as necessidades da extremidade remota somente de fazer o desencapsulamento GRE padrão do cabeçalho IP exterior GRE e enviam então o pacote GRE interno IP. Este mecanismo faz com que a resposta de keepalive envie para fora a interface física um pouco do que a interface de túnel. Para mais detalhes ao trabalhar do Keepalives do túnel GRE, veja como as manutenções de atividade de GRE trabalham.

Keepalives cripto

Keepalives de IKE

O Keepalives do Internet Key Exchange (IKE) é um mecanismo usado para determinar se um par VPN pode ascendente e receber o tráfego criptografado. O Keepalives cripto separado é exigido além do que keepalives de interface porque os pares VPN geralmente são conectados nunca de volta à parte traseira, assim que os keepalives de interface não fornecem bastante informação sobre o estado do par VPN.

Em dispositivos IOS Cisco, os keepalives de IKE são permitidos pelo uso de um método proprietário chamado o Dead Peer Detection (DPD). A fim permitir que o gateway envie DPD ao par, incorpore este comando ao modo de configuração global:

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

A fim desabilitar o Keepalives, use “não” o formulário deste comando. Para obter mais informações sobre do que cada palavra-chave neste comando faz, veja o keepalive cripto do isakmp. Para mais granularidade, o Keepalives pode igualmente ser configurado sob o perfil ISAKMP. Para mais detalhes, veja o [Cisco IOS IPsec] da vista geral do perfil ISAKMP.

Keepalives NAT

Em caso das encenações onde um par VPN está atrás de um Network Address Translation (NAT), NAT-Traversal é usado para a criptografia. Contudo, durante períodos ociosos é possível que a entrada NAT no dispositivo ascendente pôde cronometrar para fora. Isto pode causar problemas quando você traz acima o túnel e o NAT não é bidirecional. O Keepalives NAT é permitido a fim manter o traço dinâmico NAT vivo durante uma conexão entre dois pares. O Keepalives NAT é pacotes de UDP com um payload unencrypted de um byte. Embora a aplicação atual DPD seja similar ao Keepalives NAT, há uma pequena diferença - o DPD está usado para detectar o status de peer quando o Keepalives NAT for enviado se a entidade do IPsec não enviou nem recebeu o pacote em um período de tempo especificado. O intervalo válido está entre 5 a 3600 segundos.

Dica: Se o Keepalives NAT está permitido (através do comando keepalive nat do isamkp cripto), os usuários devem assegurar-se de que o valor inativo seja mais curto do que o tempo de expiração do mapeamento NAT de 20 segundos.

Para obter mais informações sobre desta característica, veja a transparência de NAT do IPsec.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 118390