IP : Encapsulamento de Roteamento Genérico (GRE)

Keepalives do túnel GRE

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


Índice


Introdução

Este documento explica o que as manutenções de atividade de GRE são e como funcionam. O Keepalives do túnel GRE não é apoiado conjuntamente com o comando tunnel protection ipsec profile. Este documento discute esta edição.

Nota:  As manutenções de atividade de GRE não são apoiadas junto com a proteção do túnel de IPsec em qualquer circunstância.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Mecanismo keepalive do túnel GRE

Túneis GRE

Os túneis GRE são projetados ser completamente apátridas. Isto significa que cada valor-limite do túnel não mantém nenhuma informação sobre o estado ou Disponibilidade do valor-limite remoto do túnel. Uma consequência desta é que o roteador local do valor-limite do túnel não tem a capacidade para derrubar o protocolo de linha da interface do túnel GRE se a extremidade remota do túnel é inacessível. A capacidade para marcar uma relação como quando a extremidade remota do link não está disponível é usada para baixo a fim remover todas as rotas (especificamente rotas estáticas) na tabela de roteamento que usarem essa relação como a interface externa. Especificamente, se o protocolo de linha para uma relação é mudado a para baixo, a seguir algumas rotas estáticas que indicarem que a relação está removida da tabela de roteamento. Isto permite a instalação de uma rota estática (de flutuação) alternativa ou o Policy Based Routing (PBR) selecionar um salto seguinte ou uma relação alternativa.

Normalmente, uma interface do túnel GRE vem acima assim que estiver configurada e ficar acima enquanto há um endereço ou uma relação válida de origem de túnel que estejam acima. O endereço IP de destino de túnel deve igualmente ser roteável. Isto é verdadeiro mesmo se o outro lado do túnel não foi configurado. Isto significa que uma rota estática ou um encaminhamento PBR de pacotes através da interface do túnel GRE permanecem de fato mesmo que os pacotes de túnel GRE não alcancem a outra extremidade do túnel.

Antes que as manutenções de atividade de GRE estiveram executadas, houve somente três razões para que um túnel GRE feche:

  • Não há nenhuma rota ao endereço de destino de túnel.

  • A relação que ancora o origem de túnel está para baixo.

  • A rota ao endereço de destino de túnel é através do túnel próprio.

Estas três regras (rota de falta, relação para baixo e destino de túnel MIS-roteado) são problemas locais ao roteador nos pontos finais de túnel e não cobrem problemas na rede de intervenção. Por exemplo, estas regras não cobrem o caso em que os pacotes tunelado de GRE são enviados com sucesso, mas são perdidas antes que alcancem a outra extremidade do túnel. Isto causa os pacotes de dados que atravessam o túnel GRE ser “preto furado”, mesmo que uma rota alternativa que se use PBR ou uma Rota estática flutuante através de uma outra relação esteja potencialmente disponível. O Keepalives na interface do túnel GRE está usado a fim resolver da mesma forma esta edição enquanto o Keepalives é usado em interfaces física.

Com Software Release 12.2(8)T de Cisco IOS�, é possível configurar o Keepalives em uma interface do túnel GRE ponto a ponto. Com esta mudança, a interface de túnel fechou dinamicamente se o Keepalives falha por um determinado período de tempo. A fim compreender melhor como o Keepalives do túnel GRE trabalha, estas seções discutem alguns outros mecanismos keepalive comuns.

Mecanismos keepalive comuns

Os mensagens de keepalive são enviados por um dispositivo de rede através de um exame ou de uns circuitos virtuais para informar ainda um outro dispositivo de rede esse o circuito entre eles funções. O intervalo keepalive é o período de tempo entre cada mensagem de keepalive que é enviado por um dispositivo de rede. 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 a relação esteja derrubada.

Keepalives dos Ethernet

Em meios de transmissão como um Ethernet, o Keepalives é levemente diferente. 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.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-a.gif

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, cada roteador mantém-se a par dos pacotes keepalive enviados e reconhecidos. Desta maneira, os roteadores remotos olham cada outro Keepalives e trilha se o Keepalives que envia é recebido.

Como uma ilustração de como as manutenções de atividade serial trabalham, o roteador1 e o roteador2 são conectados diretamente através do Serial0/0 e do Serial2/0 respectivamente. Na saída do roteador1, o Serial0/0 é fechado propositadamente. Isto faz com o roteador2 falte três Keepalives a fim ilustrar como esta falha faz com que o roteador2 feche o Serial2/0 quando o Keepalives é faltado.

Este é exemplo de saída do comando debug serial interface para uma conexão de HDLC quando o Keepalives é permitido. Quando a diferença nos valores nos campos do myseq e do mineseen excede 3 no roteador2, a linha vai para baixo e a relação é restaurada.

Roteador 1
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
*Sep 24 17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up 
*Sep 24 17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up 
*Sep 24 17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up 
*Sep 24 17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up 
*Sep 24 17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up 
*Sep 24 17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up 
*Sep 24 17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up 
*Sep 24 17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up 
*Sep 24 17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up 
*Sep 24 17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up 
*Sep 24 17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up 
*Sep 24 17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:05.153: HD(0): Reset from 0x203758
*Sep 24 17:23:05.153: HD(0): Asserting DTR 
*Sep 24 17:23:05.153: HD(0): Asserting DTR and RTS 
*Sep 24 17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up 
*Sep 24 17:23:15.173: HD(0): Reset from 0x203758
*Sep 24 17:23:15.173: HD(0): Asserting DTR 
*Sep 24 17:23:15.173: HD(0): Asserting DTR and RTS 
*Sep 24 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 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. Isto significa que o pacote de resposta do GRE keepalive não está afetado por nenhuns recursos de emissor na interface de túnel, tal como do “a proteção túnel…”, QoS, e assim por diante. ).

Nota: Se um ACL de entrada na interface do túnel GRE é configurado, a seguir o pacote keepalive do túnel GRE que o dispositivo oposto envia deve ser permitido. Se não, o túnel GRE do dispositivo oposto estará para baixo. (<tunnel-destination> do host do <tunnel-source> do host do gre da licença do <number> da lista de acesso)

Um outro atributo do Keepalives do túnel GRE é que os temporizadores de keepalive em cada lado são independentes e não têm que combinar. O problema com a configuração do Keepalives somente em um lado do túnel é que somente o roteador que tem o Keepalives configurado marca sua interface de túnel como para baixo se o temporizador de keepalive expira. A interface do túnel GRE no outro lado, onde o Keepalives não é configurado, permanece acima mesmo se o outro lado do túnel está para baixo. O túnel pode assentar bem em um buraco negro para os pacotes dirigidos no túnel do lado que não teve o Keepalives configurado. Em uma grande rede do túnel GRE do Hub-and-Spoke, pôde ser apropriado configurar somente manutenções de atividade de GRE no lado de raio e não no lado de hub. Isto é porque é frequentemente mais importante para falou para descobrir que o hub é inacessível e comuta consequentemente a um caminho backup (Dial backup por exemplo).

Como os keepalives de túnel trabalham

Um túnel GRE é uma interface lógica em um roteador Cisco que forneça uma maneira de encapsular pacotes de passageiro dentro de um protocolo de transporte. É uma arquitetura projetada proporcionar os serviços para executar um esquema do encapsulamento de Point-to-Point.

Estes pacotes ilustram os conceitos de Tunelamento IP onde o GRE é o protocolo de encapsulamento e o IP é o protocolo de transporte. O protocolo de passageiro é igualmente IP (embora pode ser um outro protocolo como o DECNet, o IPX ou o APPLETALK).

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-b.gif

  • O IP é o protocolo de transporte.

  • O GRE é o protocolo de encapsulamento.

  • O IP é o protocolo de passageiro.

A fim compreender melhor como os trabalhos do mecanismo do keepalive de túnel, consideram estes exemplo de topologia de túnel e configuração. As interfaces física do roteador A e do roteador B são S1 e S2 respectivamente e as interfaces de túnel são chamadas Tu0. Há uma rede de backbone IP entre os dois roteadores de ponto finais do túnel GRE.

Este é um exemplo de um pacote keepalive que origine do roteador A e é destinado para o roteador B. A resposta de keepalive que o roteador B retorna ao roteador A é já dentro do cabeçalho IP interno. Os decapsulates do roteador B simplesmente o pacote keepalive e enviam-lhe para trás para fora a interface física (S2). Processa o pacote do GRE keepalive apenas como todo o outro pacote de dados IP GRE.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-1.gif

Esta saída mostra os comandos que você se usa a fim configurar o Keepalives em túneis GRE.

Router# configure terminal
Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].



!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.

Nota: O Keepalives do túnel GRE é apoiado somente em túneis GRE pontos a ponto. Os keepalives de túnel são configuráveis em túneis multipontos GRE (mGRE) mas não têm nenhum efeito.

Esta tabela mostra a configuração do roteador A e o roteador B com o keepalive de túnel configurado em ambo o Roteadores.

Roteador-A do hostname Router-b do hostname
interface loopback 0
  ip address 129.9.9.9 255.255.255.255
interface tunnel 0
  ip address 1.1.1.1 255.255.255.240
  tunnel source loopback0
  tunnel destination 128.8.8.8
  keepalive 5 4
interface loopback 0
  ip address 128.8.8.8 255.255.255.255
interface tunnel 0
  ip address 1.1.1.2 255.255.255.240
  tunnel source loopback0
  tunnel destination 129.9.9.9
  keepalive 5 4 

Quando você permite o Keepalives no ponto final de túnel do roteador A, o roteador em cada intervalo do <period> constrói o cabeçalho IP e o cabeçalho de GRE internos com um tipo de protocolo (PT) de 0. Envia então a esse pacote para fora sua interface de túnel, que conduzem ao encapsulamento do pacote com o cabeçalho IP exterior e um cabeçalho de GRE com o PT = o IP. O roteador A incrementa o contador do keepalive de túnel por um. Com a suposição que há uma maneira de alcançar o ponto final de túnel da ponta oposta e o protocolo de linha do túnel não é abaixo de devido a outras razões, o pacote chega no roteador B. É combinado contra o tunnel0, transforma-se o descapsulado, e é enviado então ao IP de destino que é o endereço IP de Um ou Mais Servidores Cisco ICM NT do origem de túnel na chegada de A. Em cima do roteador no roteador A, o pacote transforma-se descapsulado e a verificação dos resultados PT em 0. Isto significa que este é um pacote keepalive. O contador do keepalive de túnel é restaurado então a 0 e o pacote é rejeitado.

No caso quando o roteador B é inacessível, o roteador A continua a construir e enviar pacotes keepalive assim como o tráfego normal. Se o Keepalives não volta, o protocolo de linha do túnel fica acima enquanto o contador do keepalive de túnel é menos do que o número de <retries>. Se essa circunstância não é verdadeira, a seguir a próxima vez que o roteador A tenta enviar um keepalive ao roteador B, o protocolo de linha está derrubado.

No estado up/down, o túnel não envia nem processa nenhum tráfego de dados. Contudo, continua a enviar pacotes keepalive. Na recepção de uma resposta de keepalive, com a implicação que o ponto final de túnel é outra vez alcançável, o contador do keepalive de túnel é restaurado a 0 e o protocolo de linha no túnel vem acima.

Nota: Se devido a uma gota do keepalive o túnel vai ao estado up/down, permite debuga o túnel e debuga o keepalive de túnel.

Esta tabela mostra que o exemplo de saída de debuga o keepalive de túnel no roteador A:

Roteador-A do hostname
debug tunnel keepalive
        Tunnel keepalive debugging is on
        *Mar  1 01:19:16.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=15
        *Mar  1 01:19:21.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=16
        *Mar  1 01:19:26.019: Tunnel0: sending keepalive, 128.8.8.8->129.9.9.9 (len=24 ttl=0), counter=17

Este diagrama mostra um exemplo de cenário do que acontece quando o roteador A envia um GRE keepalive ao roteador B:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-2.gif

Este diagrama mostra um exemplo de cenário do que acontece quando o roteador B envia um GRE keepalive ao roteador A:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-3.gif

IPsec e manutenções de atividade de GRE

Túneis GRE com IPsec

Os túneis GRE são combinados às vezes com o IPsec porque o IPsec não apoia pacotes do Protocolo IP multicast. Isto impede que os protocolos de roteamento dinâmico sejam executado com sucesso sobre uma rede do IPSec VPN. Desde que os túneis GRE apoiam o Protocolo IP multicast, um protocolo de roteamento dinâmico pode ser executado sobre um túnel GRE. Então, você pode cifrar os pacotes do unicast IP GRE pelo IPsec.

Há duas maneiras diferentes que o IPsec pode cifrar pacotes GRE. Uma maneira é com o uso de um mapa cript. e a outro é usar a proteção do túnel. Ambos os métodos especificam que a criptografia IPSec está executada após a adição do encapsulamento de GRE. Quando um mapa cript. é usado, está aplicado à interface física de partida para os pacotes de túnel GRE. Quando a proteção do túnel é usada, está configurada na interface do túnel GRE. O comando tunnel protection tornou-se disponível no Cisco IOS Software Release 12.2(13)T.

Nota: As manutenções de atividade de GRE não são compatíveis com proteção do túnel.

Este diagrama mostra os pacotes criptografado que entram um roteador através de uma interface do túnel GRE. O roteador tem um mapa cript. aplicado na interface física. Uma vez que os pacotes são decifrados e desencapsulados, continuam sobre a seu destino IP como a minuta.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-4.gif

Este diagrama mostra o que acontece quando você configura a proteção do túnel na interface do túnel GRE. Os pacotes entram o roteador cifrado através da interface de túnel e são decifrados e de-capsulated antes que continuem para seu destino como a minuta.

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-5.gif

Há duas diferenças chave entre quando você usa um mapa cript. e quando você usa a proteção do túnel:

  • O mapa cript. do IPsec está amarrado à interface física e verificado enquanto os pacotes são enviados para fora a interface física.

    Nota: O túnel GRE tem já o GRE encapsulou o pacote por este ponto.

  • A proteção do túnel amarra a funcionalidade de criptografia ao túnel GRE e está verificada depois que o pacote é GRE encapsulado mas antes que o pacote esteja entregado à interface física.

Problemas com Keepalives quando você combinar o IPsec e o GRE

Um problema ocorre se um crypto map está usado (configurado na interface física) em um lado de um túnel de IPsec GRE e proteção do túnel está configurado no outro lado. A proteção do túnel é configurada na interface de túnel somente (não o exame). O este tipo de configuração pôde ser feito em um projeto do hub and spoke. A proteção do túnel é configurada no roteador de hub a fim reduzir o tamanho da configuração e um mapa estático de criptografia é usado em cada spoke. Quando você configura o keepalive do túnel GRE no spoke nesta encenação, o keepalive falha. Isto é porque o keepalive do retorno do HUB atravessa a interface física que não tem nenhum mapa cript. configurado. Consequentemente, o keepalive do retorno não obtém cifrado e o roteador de recepção (que enviou originalmente o pacote keepalive) deixa cair a resposta de keepalive porque não era IPsec protegido (cifrado).

Este diagrama mostra uma ilustração do problema:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-9.gif

Você pode evitar este problema e pode haver um benefício se o GRE keepalive é configurado no roteador onde a proteção do túnel está configurada. Este ponto é ilustrado neste diagrama:

http://www.cisco.com/c/dam/en/us/support/docs/ip/generic-routing-encapsulation-gre/64565-gre-tunnel-keepalive-10.gif

Se o hub usa mapas cripto dinâmico e os usos do roteador do spoke escavam um túnel a proteção, a seguir você pode configurar manutenções de atividade de GRE no roteador do spoke assim que você pode provocar uma Interface de backup para discar o hub se a interface de túnel fechou no spoke.

Embora a interface do túnel GRE no hub permaneça acima, o vizinho de roteamento e as rotas através do túnel são perdidos e a rota alternativa pode ser estabelecida. No spoke, o fato de que a interface de túnel foi para baixo pode provocá-la para trazer acima uma interface do discador e um retorno de chamada ao hub (ou a um outro roteador no hub), a seguir estabelece uma nova conexão.

Se ambo o Roteadores é configurado com mapas cript., os keepalives de túnel podem obter completamente nos ambos sentidos e as interfaces do túnel GRE podem fechar em qualquer um ou em ambos sentidos, e provocam uma conexão de backup a ser feita. Esta é a maioria de opção flexível.

Se ambo o Roteadores é configurado com proteção do túnel então os keeaplives do túnel GRE não podem ser usados em um ou outro sentido. Neste caso você deve usar o protocolo de roteamento ou o outro mecanismo, tal como o Service Assurance Agent, para descobrir que o túnel não é funcional.

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.


Informações Relacionadas


Document ID: 64565