Implementar o design de várias sub-redes da fase 3 do DMVPN

Introduction

Este documento descreve as considerações de roteamento em um projeto de várias sub-redes da fase 3 do DMVPN para garantir que os túneis spoke-to-spoke diretos sejam construídos corretamente. 

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Conhecimento básico de VPN multiponto dinâmica (DMVPN)
• Conhecimento básico do Next-Hop Resolution Protocol (NHRP)

Componentes Utilizados

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

As implementações de DMVPN fase 2 e fase 3 permitem que um dispositivo spoke crie um túnel spoke-to-spoke direto e não precise passar pelo hub. No entanto, a fase 3 do DMVPN fornece uma escalabilidade muito melhor com o mecanismo de redirecionamento de NHRP para que o spoke descubra dinamicamente as redes remotas por meio do NHRP e, subsequentemente, instale rotas NHRP (H) na tabela de roteamento. Isso remove a restrição da fase 2 de exigir que cada spoke tenha prefixos de rede específicos para as redes remotas em sua tabela de roteamento. Com a fase 3, a resposta de resolução NHRP do spoke de destino (ponto de saída NBMA) deve passar pelo túnel spoke-to-spoke direto. No entanto, deve-se dar atenção especial a um projeto de fase 3 de várias sub-redes para que o túnel spoke-to-spoke possa ser construído corretamente. Este artigo discute esses requisitos em detalhes.

Problema

A fase 3 do DMVPN pode ser implementada em uma única sobreposição de sub-rede ou em várias sub-redes. Em uma topologia de sobreposição de uma única sub-rede, o hub e todos os endereços de túnel do roteador spoke são alocados de uma única sub-rede IP lógica; enquanto em um projeto de várias sub-redes, o túnel spoke-to-spoke precisa ser construído para spokes com seus endereços de túnel em diferentes sub-redes IP. Este último é um cenário comum usado em um projeto DMVPN hierárquico mostrado na imagem abaixo.

Topologia de várias sub-redes da Fase3 do DMVPN

Detalhes do problema

Com a fase 3 do DMVPN, geralmente se entende que quando a Solicitação de Resolução NHRP é recebida, o spoke de destino inicia o túnel IPsec para o spoke de origem e, subsequentemente, envia a Resposta de Resolução por esse túnel. No entanto, esse é apenas o caso com uma única sobreposição de sub-rede. Quando as interfaces de túnel dos spokes estão em sub-redes lógicas de IP diferentes, os pacotes de controle do NHRP podem passar pelo caminho spoke-hub-spoke em vez de pelo túnel spoke-to-spoke direto. Esta é a sequência de eventos quando Spoke1 envia uma Solicitação de Resolução para Spoke2 após receber um redirecionamento NHRP de Hub1:

1. Spoke2 recebe solicitação de resolução
   
   

   *Feb  7 20:57:22.272: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 144
   *Feb  7 20:57:22.272:  (F) afn: AF_IP(1), type: IP(800), hop: 252, ver: 1
   *Feb  7 20:57:22.272:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.272:      pktsz: 144 extoff: 52
   *Feb  7 20:57:22.272:  (M) flags: "router auth src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.272:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.272:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.272:  (C-1) code: no error(0)
   *Feb  7 20:57:22.272:        prefix: 32, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.272:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
   

2. Spoke2 adiciona uma entrada de cache NHRP implícita para 10.0.1.101 rastreando o pacote de solicitação de resolução.
3. Spoke2 adiciona uma adjacência para 10.0.1.101 para Tunnel0 com o endereço NBMA de Spoke1.
4. Spoke2 responde com Resolution Reply (Resposta de resolução). Observe que neste ponto, a rota para o endereço de túnel spoke solicitante aponta para o Hub2:
   
   

   Spoke2#show ip route 10.0.1.101
   Routing entry for 10.0.1.0/24
     Known via "eigrp 1", distance 90, metric 3609600, type internal
     Redistributing via eigrp 1
     Last update from 10.0.2.1 on Tunnel0, 00:17:44 ago
     Routing Descriptor Blocks:
     * 10.0.2.1, from 10.0.2.1, 00:17:44 ago, via Tunnel0
         Route metric is 3609600, traffic share count is 1
         Total delay is 41000 microseconds, minimum bandwidth is 1000 Kbit
         Reliability 255/255, minimum MTU 1400 bytes
         Loading 1/255, Hops 3
   Spoke2#
   Spoke2#
   Spoke2#show ip cef 10.0.1.101
   10.0.1.0/24
     nexthop 10.0.2.1 Tunnel0
   

   Como o pacote de controle NHRP é encaminhado ao longo do caminho roteado, ele é enviado para o Hub2 em vez do túnel spoke to spoke recém-criado para Spoke1:
   
   

   *Feb  7 20:57:22.360: NHRP: Send Resolution Reply via Tunnel0 vrf global(0x0), packet size: 172
   *Feb  7 20:57:22.360:  src: 10.0.2.101, dst: 10.0.1.101
   *Feb  7 20:57:22.360:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
   *Feb  7 20:57:22.360:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.360:      pktsz: 172 extoff: 60
   *Feb  7 20:57:22.360:  (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.360:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.360:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.360:  (C-1) code: no error(0)
   *Feb  7 20:57:22.360:        prefix: 24, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.360:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
   *Feb  7 20:57:22.360:        client NBMA: 172.16.2.1
   *Feb  7 20:57:22.360:        client protocol: 10.0.2.101
   *Feb  7 20:57:22.360: NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 172.17.0.5

Teoricamente, enquanto todos os hubs intermediários puderem rotear o pacote de controle NHRP de volta para o túnel de Spoke1, tudo ainda deverá funcionar. Mas isso nem sempre é necessariamente o caso. Se a Resolution Reply não puder ser encaminhada de volta para Spoke1, o túnel spoke-to-spoke direto não poderá ser criado. 

Com uma única sobreposição de sub-rede, isso não é um problema porque cada spoke tem uma rota diretamente conectada à rede de túnel. Isso resulta em uma pesquisa de adjacência para o endereço de túnel spoke solicitante antes que a Resposta de resolução seja enviada de volta. Em uma rede de sobreposição de várias sub-redes, como os endereços de túnel dos spokes não estão na mesma sub-rede IP, não há garantia de que o pacote Resolution Reply seja enviado pelo túnel spoke direto para spoke.

Solução

Para um projeto de DMVPN de várias sub-redes da fase 3, recomenda-se que um spoke tenha uma entrada de roteamento que aponte a interface de túnel para qualquer sub-rede de túnel spoke remoto para a qual ele precise criar um túnel spoke-to-spoke direto. Por exemplo:

Spoke2#show run | in ip route
ip route 10.0.101.0 255.255.255.0 Tunnel0

Isso permite que o spoke tente resolver a adjacência para o endereço do túnel spoke solicitante e, subsequentemente, envie a Resposta de resolução pelo túnel spoke para spoke. 

Como alternativa, a resposta de resolução pode atravessar os túneis spoke-hub-spoke. Nesse caso, todos os hubs intermediários devem ter uma rota para a sub-rede de túnel spoke solicitante para garantir que os pacotes de controle NHRP possam ser entregues fim a fim.

Observação: um aprimoramento de bug foi aberto para explorar opções para que a resposta de resolução fosse enviada pelo túnel direto, mesmo sem uma rota estática explícita. ID de bug da Cisco CSCvo02022 - Aprimoramento: o NHRP deve enviar resposta de resolução sobre túnel spoke para túnel spoke para DMVPN de várias sub-redes.

Observação: somente clientes Cisco registrados podem acessar informações e ferramentas internas de bug da Cisco.

Informações Relacionadas

• Suporte técnico e downloads da Cisco