Keepalives de Túneis GRE Índice Introdução Pré-requisitos Requisitos Componentes Utilizados Convenções Mecanismo de Keepalive de Túneis GRE Túneis GRE Mecanismos Comuns de Keepalive Keepalives de Ethernet Keepalives de HDLC Keepalives de Túneis GRE Como os Keepalives de Túneis Funcionam Keepalives IPsec e GRE Túneis GRE com IPSec Problemas com Keepalives ao Combinar IPSec e GRE Introdução Este documento explica o que são keepalives GRE e como eles funcionam. A documentação Keepalives de Túneis Generic Router Encapsulation (GRE) afirma que não há suporte a keepalives de túneis GRE em conjunto com o comando tunnel protection ipsec profile. Este documento discute esse problema e um caso em que esses recursos funcionam em conjunto. 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 documentos, consulte as Convenções de Dicas Técnicas da Cisco. Mecanismo de Keepalive de Túneis GRE Túneis GRE Os túneis GRE foram desenvolvidos para serem completamente livres de estados. Isso significa que cada ponto de extremidade de um túnel não mantém informação alguma sobre o estado ou a disponibilidade do ponto de extremidade remoto do túnel. Uma consequência desse fato é que o roteador do ponto de extremidade local do túnel não é capaz de desativar o protocolo de linha da interface do túnel GRE quando a extremidade remota do túnel está inacessível. A capacidade de marcar uma interface como desativada quando a extremidade remota do link não está disponível é usada para remover quaisquer rotas (especificamente rotas estáticas) na tabela de roteamento que usam a interface como interface de saída. Especificamente, se o protocolo de linha para uma interface é desativado, todas as rotas estáticas que apontam para essa interface são removidas da tabela de roteamento. Isso permite a instalação de uma rota estática alternativa (flutuante) ou do roteamento com base em políticas (PBR) para selecionar um próximo salto ou interface alternativos. Normalmente, uma interface de túnel GRE é ativada assim que é configurada e permanece ativa enquanto há um endereço de origem de túnel válido ou uma interface ativa. O endereço IP de destino do túnel também deve ser roteável. Isso é verdade mesmo quando o outro lado do túnel não foi configurado. Isso significa que uma rota estática ou o encaminhamento PRB de pacotes via interface do túnel GRE permanece em vigor mesmo quando os pacotes do túnel GRE não chegam até a outra extremidade do túnel.
Antes dos keepalives GRE serem implementados, havia apenas três motivos para encerrar um túnel GRE: Não há rota para o endereço de destino do túnel. A interface que ancora a origem do túnel está desativada. A rota para o endereço de destino do túnel é pelo túnel em si. Essas três regras (rota ausente, interface desativada e destino do túnel roteado incorretamente) são problemas locais do roteador nos pontos de extremidade e não abrangem os problemas na rede subjacente. Por exemplo, elas não abordam o caso em que os pacotes são encaminhados com êxito no túnel GRE mas são perdidos antes de chegarem até a outra extremidade do túnel. Isso faz com que os pacotes de dados que atravessam o túnel GRE caiam em um "buraco negro", mesmo quando uma rota alternativa que usa PBR ou uma rota estática flutuante via outra interface está potencialmente disponível. Os keepalives na interface do túnel GRE são usados para resolver esse problema da mesma forma que são usados nas interfaces físicas. Com o Cisco IOS Software Release 12.2(8)T, é possível configurar keepalives em uma interface de túnel GRE ponto a ponto. Com essa alteração, a interface do túnel é encerrada dinamicamente quando os keepalives falham por um determinado período de tempo. Para proporcionar um melhor entendimento de como os keepalives de túneis GRE funcionam, as seções a seguir discutem alguns outros mecanismos comuns de keepalive. Mecanismos Comuns de Keepalive As mensagens de keepalive são enviadas por um dispositivo de rede através de um circuito físico ou virtual para informar a outro dispositivo que o circuito entre eles ainda funciona. O intervalo de keepalive é o período de tempo entre cada mensagem de keepalive enviada por um dispositivo de rede. As repetições de keepalive são o número de vezes que o dispositivo continua a enviar pacotes de keepalive sem obter resposta antes que a interface seja desativada. Keepalives de Ethernet Em uma mídia de broadcast como a Ethernet, os keepalives são ligeiramente diferentes. Como há vários possíveis vizinhos na Ethernet, o keepalive não foi criado para determinar se o caminho para qualquer vizinho específico no cabo está disponível. Ele foi desenvolvido para verificar se o sistema local possui acesso de leitura e gravação no cabo Ethernet em si. O roteador produz um pacote Ethernet usando ele mesmo como os endereços MAC de origem e destino e um código de tipo Ethernet especial 0x9000. O hardware Ethernet envia este pacote no cabo Ethernet e o recebe de volta imediatamente. Esse processo verifica o hardware de envio e recebimento no adaptador Ethernet e a integridade básica do cabo. Keepalives de HDLC Os keepalives seriais de HDLC são outro mecanismo de keepalive muito conhecido. Keepalives seriais são enviados e recebidos entre dois roteadores e todos são confirmados. Com a utilização de números de sequência, cada roteador faz o acompanhamento dos pacotes de keepalive enviados e confirmados. Dessa forma, os roteadores remotos observam os keepalives um do outro e identificam se seus keepalives enviados são recebidos. Para ilustrar como os keepalives em série funcionam, Roteador 1 e Roteador 2 estão conectados diretamente via Serial0/0 e Serial2/0, respectivamente. Na saída de Roteador 1, Serial 0/0 é desativada de propósito. Isso faz com que Roteador 2 perca três keepalives para demonstrar como essa falha faz com que Roteador 2 desative Serial2/0 quando os keepalives são perdidos. Esta é a saída de exemplo do comando debug serial interface para uma conexão de HDLC quando os keepalives estão habilitados. Quando a diferença entre os valores dos campos myseq e mineseen excede 3 em Roteador 2, a linha é desativada e a interface é redefinida. 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 de Túneis GRE O mecanismo de keepalive de túneis GRE é ligeiramente diferente dos de interfaces Ethernet e seriais. Ele permite que um dos lados gere e receba pacotes de keepalive para e de um roteador remoto mesmo quando o roteador remoto não oferece suporte a keepalives GRE. Como o GRE é um mecanismo de tunelamento de pacotes para encapsular IP em IP, um pacote de túnel IP GRE pode ser criado em outro pacote de túnel IP GRE. Para os keepalives GRE, o remetente cria previamente o pacote de resposta de keepalive dentro do pacote de solicitação de keepalive original para que a extremidade remota precise somente desencapsular o cabeçalho IP GRE externo e encaminhar o pacote IP GRE interno. Esse mecanismo faz com que a resposta de keepalive faça o encaminhamento da interface física em vez da interface do túnel. Isso significa que o pacote de resposta de keepalive GRE não é afetado por nenhum recurso de saída na interface do túnel, como proteção de túneis, QoS e assim por diante. Se houver uma ACL de entrada na interface do túnel GRE, ela deverá permitir o pacote de keepalive do túnel GRE de retorno (accesslist <number> permit gre host <tunnel-source> host <tunnel-destination>). Outro atributo dos keepalives de túneis GRE é que os temporizadores de keepalive em cada lado são independentes e não precisam coincidir. O problema com a configuração de keepalives em apenas um dos lados do túnel é que somente o roteador que possui os keepalives configurados marca sua interface como desativada se o temporizador expira. A interface do túnel GRE no outro lado, onde os keepalives não estão configurados, permanece ativa mesmo quando o outro lado do túnel está desativado. O túnel pode se tornar um buraco negro para os pacotes direcionados ao túnel pelo lado que não possui os keepalives configurados. Em uma rede com túnel GRE hub and spoke de grande porte, talvez seja adequado configurar somente os keepalives no lado do spoke e não no hub. A razão para isso é que, frequentemente, é mais importante para o spoke descobrir que o hub não pode ser atingido e, consequentemente, alternar para um caminho de backup (backup de discagem, por exemplo). Como os Keepalives de Túneis Funcionam Um túnel GRE é uma interface lógica em um roteador Cisco que oferece um modo de encapsular pacotes passageiros em um protocolo de transporte. Trata-se de uma arquitetura desenvolvida para fornecer os serviços necessários para implementar um esquema de encapsulamento ponto a ponto. Esses pacotes ilustram os conceitos de tunelamento IP em que o GRE é o protocolo de encapsulamento e IP é o protocolo de transporte. O protocolo de passageiro também é o IP (embora ele possa ser outro protocolo, como Decnet, IPX ou Appletalk). IP é o protocolo de transporte. GRE é o protocolo de encapsulamento. IP é o protocolo de passageiro. Para entender melhor como o mecanismo de keepalive de túneis funciona, considere este exemplo de topologia e configuração de túnel. As interfaces físicas de Roteador A e Roteador B são S1 e S2, respectivamente. As interfaces do túnel são chamadas Tu0. Há uma rede backbone IP entre os dois roteadores pontos de extremidade do túnel GRE.
Este é um exemplo de pacote de keepalive proveniente de Roteador A com destino a Roteador B. A resposta de keepalive devolvida por Roteador B a Roteador A já está contida no cabeçalho IP interno. Roteador B simplesmente desencapsula o pacote de keepalive e o envia de volta pela interface física (S2). Ele processa o pacote de keepalive GRE da mesma forma que qualquer outro pacote de dados IP GRE. Esta saída mostra os comandos que devem ser usados para configurar keepalives em túneis GRE. Router# configure terminal Router(config)#interface tunnel0 Router(config-if)#keepalive 5 4!--- A sintaxe deste comando é keepalive [seconds [retries]].!--- Os keepalives são enviados a cada 5 segundos e 4 novas tentativas.!--- Os keepalives devem ser perdidos para que o túnel seja desativado.!--- Os valores padrão são 10 segundos para o intervalo e 3 novas tentativas. Nota: Há suporte aos keepalives de túneis GRE somente em túneis GRE ponto a ponto. Os keepalives de túneis podem ser configurados em túneis GRE multiponto (mgre), mas não possuem efeito algum. Esta tabela mostra a configuração de Roteador A e Roteador B com tunnel keepalive configurado em ambos os roteadores. Hostname Roteador-A 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 Hostname Roteador-B 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 os keepalives são habilitados no ponto de extremidade do túnel de Roteador A, o roteador constrói o cabeçalho IP interno e o cabeçalho GRE com um tipo de protocolo (PT) igual a 0 a cada intervalo <período>. Em seguida, ele envia esse pacote pela sua interface do túnel, o que resulta no encapsulamento do pacote com o cabeçalho IP externo e um cabeçalho GRE com PT = IP. Roteador A incrementa o contador de keepalives do túnel em um. Supondo que há uma forma de alcançar o ponto de extremidade do final do túnel e que o protocolo de linha do túnel não está desativado por algum outro motivo, o pacote chega em Roteador B. Ele é então comparado com Túnel 0, é desencapsulado e é encaminhado para o IP de destino, o qual é o endereço IP da origem do túnel em Roteador A. Ao chegar em Roteador A, o pacote é desencapsulado e a verificação de PT resulta em 0. Isso significa que esse é um pacote de keepalive. O contador de keepalives do túnel é redefinido para 0 e o pacote é descartado. Se Roteador B estiver inacessível, Roteador A continuará a construir e enviar pacotes de keepalive, bem como tráfego normal. Se os keepalives não retornarem, o protocolo de linha do túnel permanecerá ativo enquanto o contador de keepalives do túnel for inferior ao número de <repetições>. Se essa condição não for verdadeira, na próxima vez que Roteador A tentar enviar um keepalive para Roteador B, o protocolo de linha será desativado. No estado ativo/desativado, o túnel não encaminha ou processa nenhum tráfego de dados. No entanto, ele não continua a enviar pacotes de keepalive. Mediante recepção de uma resposta de keepalive, com a implicação que o ponto de extremidade do túnel pode ser alcançado novamente, o contador de keepalives do túnel é redefinido para 0 e o protocolo de linha no túnel é ativado normalmente. Este diagrama mostra cenário de exemplo do que acontece quando Roteador A envia um keepalive GRE para Roteador B:
Este diagrama mostra cenário de exemplo do que acontece quando Roteador B envia um keepalive GRE para Roteador A: Keepalives IPsec e GRE Túneis GRE com IPSec Os túneis GRE são algumas vezes combinados com o IPses porque o IPsec não oferece suporte a pacotes IP multicast. Isso impede que os protocolos de roteamento dinâmico sejam executados com êxito em uma rede VPN IPsec. Como os túneis GRE não oferecem suporte ao multicast de IP, um protocolo de roteamento dinâmico pode ser executado em um túnel GRE. Assim, é possível criptografar os pacotes unicast IP GRE usando o IPsec. Há duas formas diferentes do IPsec criptografar pacotes GRE. Uma forma é usar um mapa de criptografia e a outra é usar a proteção de túneis. Ambos os métodos especificam que a criptografia IPsec seja executada após a adição do encapsulamento GRE. Quando um mapa de criptografia é usado, ele é aplicado às interfaces físicas de saída dos pacotes do túnel GRE. Quando a proteção de túneis é usada, ela é configurada na interface do túnel GRE. O comando de proteção de túneis tunnel protection se tornou disponível no Cisco IOS Software Release 12.2(13)T. Este diagrama mostra os pacotes criptografados que entram em um roteador por uma interface de túnel GRE. O roteador possui um mapa de criptografia aplicado à interface física. Assim que os pacotes são descriptografados e desencapsulados, eles prosseguem para seus destinos IP na forma de texto simples.
Este diagrama mostra o que acontece quando você configura a proteção de túneis na interface do túnel GRE. Os pacotes entram no roteador criptografados pela interface do túnel e são descriptografados e desencapsulados antes que possam prosseguir para o destino na forma de texto simples. Há duas diferenças importantes entre o uso de um mapa de criptografia e da proteção de túneis: O mapa de criptografia IPsec é vinculado à interface física e é examinado à medida que os pacotes são encaminhados pela interface física. Nota: Nesse ponto, o túnel GRE já encapsulou o pacote com o GRE. A proteção de túneis vincula a funcionalidade de criptografia ao túnel GRE e é examinada após o pacote ser encapsulado pelo GRE, mas antes de ele ser enviado para a interface física. Problemas com Keepalives ao Combinar IPSec e GRE Há um problema quando um mapa de criptografia é usado (configurado na interface física) em um lado de um túnel IPsec GRE e a proteção de túneis está configurada do outro lado. A proteção de túneis é configurada somente na interface do túnel (e não na física). Esse tipo de configuração poderia ser feito em um design de hub and spoke. A proteção de túneis é configurada no roteador do hub para reduzir o tamanho da configuração e um mapa de criptografia estático é usado em cada spoke. Quando o keepalive do túnel GRE é configurado no spoke nesse cenário, o keepalive falha. Isso ocorre porque o keepalive de retorno do hub cruza a interface física que não possui mapa de criptografia configurado. Assim, o keepalive de retorno não é criptografado e o roteador recebedor (que originalmente enviou o pacote de keepalive) descarta a resposta de keepalive porque ela não estava protegida pelo IPsec (criptografada). Este diagrama mostra uma ilustração do problema:
É possível evitar esse problema e também poderá ser benéfico se o keepalive GRE for configurado no roteador em que a proteção de túneis está configurada. Esse ponto é ilustrado neste diagrama: Se o hub usar mapas de criptografia dinâmicos e o roteador do spoke usar a proteção de túneis, você poderá configurar os keepalives GRE no roteador do spoke para poder acionar uma interface de backup que disque para o hub se a interface do túnel for desativada no spoke. Embora a interface do túnel GRE no hub permaneça ativada, o vizinho de roteamento e as rotas através do túnel são perdidas e uma rota alternativa pode ser estabelecida. No spoke, o fato de que a interface do túnel foi desativada pode acioná-lo para ativar uma interface de discador e ligar de volta para o hub (ou para outro roteador no hub) e estabelecer uma nova conexão. Se ambos os roteadores forem configurados com mapas de criptografia, os keepalives do túnel conseguiriam atravessar em ambas as direções e as interfaces do túnel GRE poderiam ser encerradas em uma ou ambas as direções e acionar uma conexão de backup. Essa é a opção mais flexível. 1992-2014 Cisco Systems Inc. Todos os direitos reservados. Data da Geração do PDF: 1 Julho 2009 http://www.cisco.com/cisco/web/support/br/106/1067/1067683_gre-tunnel-keepalive.html