Migração forçada de DMVPN para FlexVPN nos mesmos dispositivos

Introduction

Este documento fornece informações sobre como migrar da rede DMVPN existente para FlexVPN nos mesmos dispositivos.

As configurações das duas estruturas coexistirão nos dispositivos.

Neste documento, somente o cenário mais comum é mostrado: DMVPN usando chave pré-compartilhada para autenticação e EIGRP como protocolo de roteamento.

Este documento demonstra a migração para o BGP (protocolo de roteamento recomendado) e para o EIGRP menos desejável.

Prerequisites

Requirements

Este documento pressupõe que o leitor conheça os conceitos básicos de DMVPN e FlexVPN.

Componentes Utilizados

Observe que nem todos os softwares e hardwares suportam IKEv2. Consulte o Cisco Feature Navigator para obter informações. Idealmente, as versões de software a serem usadas são:

• ISR - 15.2(4)M1 ou mais recente

• ASR1k - versão 3.6.2 15.2(2)S2 ou mais recente

Entre as vantagens da plataforma e do software mais novos está a possibilidade de usar a criptografia de última geração, por exemplo, AES GCM para criptografia em IPsec. Isso é discutido no RFC 4106.

O AES GCM permite alcançar uma velocidade de criptografia muito mais rápida em algum hardware.

Para ver as recomendações da Cisco sobre como usar e migrar para a criptografia de última geração, consulte:

http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Procedimento de Migração

Atualmente, a maneira recomendada de migrar de DMVPN para FlexVPN é que as duas estruturas não operem ao mesmo tempo.

Essa limitação será removida devido aos novos recursos de migração a serem introduzidos na versão ASR 3.10, rastreados sob várias solicitações de aprimoramento sob o lado da Cisco, incluindo CSCuc08066. Esses recursos devem estar disponíveis no final de junho de 2013.

Uma migração em que ambas as estruturas coexistem e operam ao mesmo tempo nos mesmos dispositivos será chamada de migração suave, o que indica impacto mínimo e failover suave de uma estrutura para outra.

Uma migração em que a configuração de ambas as estruturas coexiste, mas não opera ao mesmo tempo, é chamada de migração forçada. Isso indica que um switchover de uma estrutura para outra significa uma falta de comunicação via VPN, mesmo que mínima.

Migração forçada para os mesmos dispositivos

Neste documento, a migração de uma rede DMVPN existente para uma nova rede FlexVPN nos mesmos dispositivos é discutida.

Essa migração exige que ambas as estruturas não operem ao mesmo tempo nos dispositivos, basicamente exigindo que a funcionalidade DMVPN seja desabilitada em toda a placa antes de habilitar o FlexVPN.

Até que o novo recurso de migração esteja disponível, a maneira de executar migrações usando os mesmos dispositivos é:

1. Verifique a conectividade via DMVPN.

2. Adicione a configuração FlexVPN no lugar e desligue as interfaces de túnel e modelo virtual que pertencem à nova configuração.

3. (Durante uma janela de manutenção) Desligue todas as interfaces de túnel DMVPN em todos os spokes e hubs antes de passar para a etapa 4.

4. Desfeche as interfaces de túnel FlexVPN.

5. Verifique a conectividade do spoke com o hub.

6. Verifique a conectividade de spoke para spoke.

7. Se a verificação nos pontos 5 ou 6 não for revertida corretamente para DMVPN, desligando a interface FlexVPN e desligando as interfaces DMVPN.

8. Verifique a comunicação do spoke com o hub.

9. Verifique a comunicação de spoke para spoke.

Abordagem personalizada

Se, devido à sua complexidade de rede ou roteamento, a abordagem não for a melhor ideia para você, inicie uma discussão com seu representante da Cisco antes de migrar. A melhor pessoa para discutir um processo de migração personalizado é o engenheiro de sistemas ou o engenheiro de serviços avançados.

Topologia de rede

Topologia da rede de transporte

Este diagrama mostra uma topologia típica de conexões de hosts na Internet. Neste documento, o endereço IP do hub de loopback0 (172.25.1.1) é usado para encerrar a sessão IPsec.

Topologia de rede sobreposta

Este diagrama de topologia mostra duas nuvens separadas usadas para sobreposição: Conexões DMVPN (conexões verdes) e FlexVPN.

Os prefixos da rede local são mostrados para os lados correspondentes.

A sub-rede 10.1.1.0/24 não representa uma sub-rede real em termos de endereçamento de interface, mas sim um pedaço de espaço IP dedicado à nuvem FlexVPN. O motivo por trás é discutido posteriormente na seção Configuração de FlexVPN.

Configuração

Configuração de DMVPN

Esta seção contém a configuração básica de hub e spoke DMVPN.

A chave pré-compartilhada (PSK) é usada para autenticação IKEv1.

Depois que o IPsec é estabelecido, o registro de NHRP é executado de spoke para hub, para que o hub possa aprender dinamicamente o endereçamento NBMA dos spokes.

Quando o NHRP executa o registro no spoke e no hub, a adjacência de roteamento pode estabelecer e rotear trocados. Neste exemplo, o EIGRP é usado como protocolo de roteamento básico para a rede de sobreposição.

Configuração de Spoke DMVPN

Este é um exemplo básico de configuração de DMVPN com autenticação de chave pré-compartilhada e EIGRP como protocolo de roteamento.

crypto isakmp policy 10
  encr aes
  authentication pre-share
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 30 5
crypto isakmp profile DMVPN_IKEv1
  keyring DMVPN_IKEv1
  match identity address 0.0.0.0
crypto ipsec transform-set IKEv1 esp-aes esp-sha-hmac 
  mode transport
crypto ipsec profile DMVPN_IKEv1
  set transform-set IKEv1 
  set isakmp-profile DMVPN_IKEv1
interface Tunnel0
ip address 10.0.0.101 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map 10.0.0.1 172.25.1.1
 ip nhrp map multicast 172.25.1.1
 ip nhrp network-id 1
 ip nhrp holdtime 900
 ip nhrp nhs 10.0.0.1
 ip nhrp shortcut
 ip tcp adjust-mss 1360
 tunnel source Ethernet0/0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IKEv1
router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.102.0
 passive-interface default
 no passive-interface Tunnel0

configuração de DMVPN de hub

Na configuração do hub, o túnel é originado do loopback0 com um endereço IP 172.25.1.1.

O restante é a implantação padrão do hub DMVPN com EIGRP como protocolo de roteamento.

crypto isakmp policy 10
 encr aes
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0
crypto ipsec transform-set IKEv1 esp-aes esp-sha-hmac 
 mode transport
crypto ipsec profile DMVPN_IKEv1
 set transform-set IKEv1
 interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp holdtime 900
 ip nhrp server-only
 ip nhrp redirect
 ip summary-address eigrp 100 192.168.0.0 255.255.0.0
 ip tcp adjust-mss 1360
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel protection ipsec profile DMVPN_IKEv1
router eigrp 100
 network 10.0.0.0 0.0.0.255
 network 192.168.0.0 0.0.255.255
 passive-interface default
 no passive-interface Tunnel0

configuração FlexVPN

O FlexVPN é baseado nas mesmas tecnologias fundamentais:

• IPSEC: Ao contrário do padrão em DMVPN, IKEv2 é usado em vez de IKEv1 para negociar SAs IPsec. O IKEv2 oferece melhorias sobre o IKEv1, começando com a resiliência e terminando com quantas mensagens são necessárias para estabelecer um canal de dados protegido.

• GRE : Diferentemente do DMVPN, as interfaces ponto a ponto estáticas e dinâmicas são usadas, e não apenas em interfaces GRE multiponto estáticas. Essa configuração permite maior flexibilidade, especialmente para comportamento por spoke/por hub.

• NHRP: No FlexVPN, o NHRP é usado principalmente para estabelecer comunicação spoke to spoke. Os spokes não se registram no hub.

• Roteamento: Como os spokes não executam o registro de NHRP no hub, você precisa confiar em outros mecanismos para garantir que o hub e os spokes possam se comunicar bidirecionalmente. Da mesma forma que DMVPN, os protocolos de roteamento dinâmico podem ser usados. No entanto, o FlexVPN permite usar o IPsec para apresentar informações de roteamento. O padrão é introduzir como rota /32 para o endereço IP no outro lado do túnel, o que permitirá a comunicação direta de spoke para hub.

Na migração forçada de DMVPN para FlexVPN, as duas estruturas não funcionam ao mesmo tempo nos mesmos dispositivos. No entanto, recomenda-se mantê-los separados.

Separe-os em vários níveis:

• NHRP - Use diferentes IDs de rede NHRP (recomendado).

• Roteamento - Use processos de roteamento separados (recomendado).

• VRF - A separação de VRF pode permitir maior flexibilidade, mas não será discutida aqui (opcional).

Configuração de Spoke FlexVPN

Uma das diferenças na configuração de spoke em FlexVPN em comparação com DMVPN é que você tem duas interfaces potenciais.

Há um túnel necessário para comunicação de spoke para hub e um túnel opcional para túneis spoke para spoke para spoke. Se você optar por não ter túnel spoke dinâmico para spoke e preferir que tudo passe pelo dispositivo hub, você poderá remover a interface de modelo virtual e a comutação de atalho NHRP da interface de túnel.

Você também observará que a interface de túnel estático tem um endereço IP recebido com base na negociação. Isso permite que o hub forneça IP de interface de túnel para spoke dinamicamente sem a necessidade de criar endereçamento estático na nuvem FlexVPN.

aaa new-model
aaa authorization network default local
aaa session-id common

crypto ikev2 profile Flex_IKEv2
 match identity remote fqdn domain cisco.com
 authentication remote rsa-sig
 authentication local rsa-sig
 aaa authorization group cert list default default
 virtual-template 1
crypto ikev2 dpd 30 5 on-demand

A Cisco recomenda o uso do AES GCM em hardware que o suporte.

crypto ipsec transform-set IKEv2 esp-gcm
    mode transport
crypto ipsec profile default
 set ikev2-profile Flex_IKEv2
! set transform-set IKEv2
interface Tunnel1
 ip address negotiated
 ip mtu 1400
 ip nhrp network-id 2
 ip nhrp shortcut virtual-template 1
 ip nhrp redirect
 ip tcp adjust-mss 1360
 shutdown
 tunnel source Ethernet0/0
 tunnel destination 172.25.1.1
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default
interface Virtual-Template1 type tunnel
 ip unnumbered Tunnel1
 ip mtu 1400
 ip nhrp network-id 2
 ip nhrp shortcut virtual-template 1
 ip nhrp redirect
 ip tcp adjust-mss 1360
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default

PKI é a maneira recomendada de executar autenticação em larga escala em IKEv2.

No entanto, você ainda pode usar a chave pré-compartilhada, desde que esteja ciente das limitações dela.

Aqui está um exemplo de configuração usando "cisco" como PSK:

crypto ikev2 keyring Flex_key
 peer Spokes
 address 0.0.0.0 0.0.0.0
 pre-shared-key local cisco
 pre-shared-key remote cisco
crypto ikev2 profile Flex_IKEv2
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local Flex_key
 aaa authorization group psk list default default

Configuração do FlexVPN Hub

Normalmente, um hub terminará somente os túneis spoke-to-hub dinâmicos. É por isso que, na configuração do hub, você não encontrará uma interface de túnel estático para o FlexVPN, em vez disso, uma interface de modelo virtual é usada. Isso gerará uma interface de acesso virtual para cada conexão.

Observe que no lado do hub você precisa apontar os endereços do pool a serem atribuídos aos spokes.

Os endereços desse pool serão adicionados posteriormente na tabela de roteamento como rotas /32 para cada spoke.

aaa new-model
aaa authorization network default local
aaa session-id common
crypto ikev2 authorization policy default
 pool FlexSpokes
crypto ikev2 profile Flex_IKEv2
 match identity remote fqdn domain cisco.com
 authentication remote rsa-sig
 authentication local rsa-sig
 aaa authorization group cert list default default
 virtual-template 1
crypto ikev2 dpd 30 5 on-demand

A Cisco recomenda o uso do AES GCM em hardware que o suporte.

crypto ipsec transform-set IKEv2 esp-gcm
 mode transport

Observe que na configuração abaixo a operação do AES GCM foi comentada.

crypto ipsec profile default
 set ikev2-profile Flex_IKEv2
! set transform-set IKEv2
interface Loopback0
 description DMVPN termination
 ip address 172.25.1.1 255.255.255.255
interface Loopback100
 ip address 10.1.1.1 255.255.255.255
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback100
 ip nhrp network-id 2
 ip nhrp redirect
 shutdown
 tunnel path-mtu-discovery
 tunnel protection ipsec profile default
ip local pool FlexSpokes 10.1.1.100 10.1.1.254

Com a autenticação em IKEv2, o mesmo princípio se aplica no hub como no spoke.

Para escalabilidade e flexibilidade, use certificados. No entanto, você pode reutilizar a mesma configuração para PSK do spoke.

Observação: o IKEv2 oferece flexibilidade em termos de autenticação. Um lado pode autenticar usando PSK enquanto o outro RSA-SIG.

Migração de tráfego

Migração para o BGP como protocolo de roteamento de sobreposição [recomendado]

O BGP é um protocolo de roteamento baseado na troca unicast. Devido às suas características, ele tem sido o melhor protocolo de dimensionamento em redes DMVPN.

Neste exemplo, o iBGP é usado.

configuração de Spoke BGP

A migração de spoke consiste em duas partes. Ativando o BGP como roteamento dinâmico.

router bgp 65001
 bgp log-neighbor-changes
 network 192.168.101.0
 neighbor 10.1.1.1 remote-as 65001

Depois que o vizinho BGP for ativado (consulte a configuração do BGP do hub nesta seção de migração) e novos prefixos sobre BGP forem aprendidos, você poderá alternar o tráfego da nuvem DMVPN existente para a nova nuvem FlexVPN.

configuração de BGP de hub

No hub para evitar manter a configuração de vizinhança para cada spoke separadamente, os ouvintes dinâmicos são configurados.

Nesta configuração, o BGP não iniciará novas conexões, mas aceitará a conexão do pool de endereços IP fornecido. Nesse caso, o pool mencionado é 10.1.1.0/24, que é todos os endereços na nova nuvem FlexVPN.

router bgp 65001
 network 192.168.0.0
 bgp log-neighbor-changes
 bgp listen range 10.1.1.0/24 peer-group Spokes
 aggregate-address 192.168.0.0 255.255.0.0 summary-only
 neighbor Spokes peer-group
 neighbor Spokes remote-as 65001

Migração de tráfego para FlexVPN

Como mencionado antes, a migração precisa ser feita desligando a funcionalidade DMVPN e ativando o FlexVPN.

Este procedimento garante um impacto mínimo.

1. Em todos os spokes:

   interface tunnel 0
      shut

2. No hub:

   interface tunnel 0
     shut

   Neste ponto, certifique-se de que não há sessões IKEv1 estabelecidas para este hub a partir de spokes.

   Isso pode ser verificado verificando a saída do comando show crypto isakmp sa e monitorando mensagens de syslog geradas pela sessão de registro de criptografia.

   Depois que isso for confirmado, você poderá continuar a ativar o FlexVPN.

3. Continuando no hub:

   interface Virtual-template 1
    no shut

4. Em spokes:

   interface tunnel 1
      no shut

Etapas de verificação

estabilidade de IPsec

A melhor maneira de avaliar a estabilidade do IPsec é monitorando sylogs com este comando de configuração ativado:

crypto logging session

Se você vir sessões ativadas e desativadas, isso pode indicar um problema no nível IKEv2/FlexVPN que precisa ser corrigido antes que a migração possa começar.

informações de BGP preenchidas

Se o IPsec for estável, certifique-se de que a tabela BGP seja preenchida com entradas de spokes (no hub) e resumo do hub (em spokes).

No caso do BGP, isso pode ser visto executando:

show bgp 
! or
show bgp ipv4 unicast 
! or
show ip bgp summary

Exemplo de informações corretas do hub:

Hub#show bgp
BGP router identifier 172.25.1.1, local AS number 65001
(...omitted...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.1.1.101 4 65001 83 82 13 0 0 01:10:46 1
*10.1.1.102 4 65001 7 7 13 0 0 00:00:44 1

Você pode ver que o hub aprendeu que 1 prefixo de cada um dos spokes e ambos os spokes são dinâmicos (marcados com o sinal de asterisco (*)).

Exemplo de informações semelhantes do spoke:

Spoke1#show ip bgp summary
BGP router identifier 192.168.101.1, local AS number 65001
(...omitted...)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.1.1 4 65001 11 11 6 0 0 00:03:43 1

Spoke recebeu um prefixo do hub. No caso dessa configuração, esse prefixo deve ser o resumo anunciado no hub.

Migrando para novos túneis usando o EIGRP

O EIGRP é uma escolha popular em redes DMVPN devido à sua implantação relativamente simples e rápida convergência.

No entanto, ela será escalada pior que o BGP e não oferece muitos dos mecanismos avançados que podem ser usados pelo BGP diretamente da caixa.

Esta próxima seção descreve uma das maneiras de mover para FlexVPN usando um novo processo EIGRP.

Configuração de spoke atualizada

Neste exemplo, um novo AS é adicionado com um processo EIGRP separado.

router eigrp 200
 network 10.1.1.0 0.0.0.255
 network 192.168.101.0
 passive-interface default
 no passive-interface Tunnel1

Observação: você deve evitar estabelecer adjacência de protocolo de roteamento sobre túneis spoke para spoke, portanto, somente tornar a interface de tunnel1 (spoke para hub) não passiva.

Configuração do hub atualizada

Da mesma forma no hub, a DMVPN deve continuar sendo a maneira preferida de trocar tráfego. No entanto, o FlexVPN já deve anunciar e aprender os mesmos prefixos.

router eigrp 200
 network 10.1.1.0 0.0.0.255

Há duas maneiras de fornecer resumo para o spoke.

• Redistribuindo uma rota estática apontando para null0 (Opção preferencial).

  ip route 192.168.0.0 255.255.0.0 null 0
  ip access-list standard EIGRP_SUMMARY
   permit 192.168.0.0 0.0.255.255
  router eigrp 200
   distribute-list EIGRP_SUMMARY out Virtual-Template1
   redistribute static metric 1500 10 10 1 1500

  Essa opção permite ter controle sobre resumo e redistribuição sem tocar na configuração de VT do hub.

• Ou você pode configurar um endereço de resumo no estilo DMVPN no modelo virtual. Esta configuração não é recomendada devido ao processamento interno e à replicação do referido resumo para cada acesso virtual. Ele é mostrado aqui para referência:

  interface Virtual-Template1 type tunnel
   ip summary-address eigrp 200 172.16.1.0 255.255.255.0
   ip summary-address eigrp 200 192.168.0.0 255.255.0.0
   delay 2000
  

Migração de tráfego para FlexVPN

A migração precisa ser feita desligando a funcionalidade DMVPN e ativando o FlexVPN.

O procedimento a seguir garante um impacto mínimo.

1. Em todos os spokes:

   interface tunnel 0
      shut

2. No hub:

   interface tunnel 0
     shut

   Neste ponto, certifique-se de que não há sessões IKEv1 estabelecidas para este hub a partir de spokes.

   Isso pode ser verificado verificando a saída do comando show crypto isakmp sa e monitorando mensagens de syslog geradas pela sessão de registro de criptografia.

   Depois que isso for confirmado, você poderá continuar a ativar o FlexVPN.

3. Continuando no hub:

   interface Virtual-template 1
    no shut

4. Em todos os spokes:

   interface tunnel 1
      no shut

Etapas de verificação

estabilidade de IPsec

Como no caso do BGP, você precisa avaliar se o IPsec é estável. A melhor maneira de fazer isso é monitorando sylogs com este comando de configuração ativado:

crypto logging session

Se você vir sessões ativadas e desativadas, isso pode indicar um problema no nível IKEv2/FlexVPN que precisa ser corrigido antes que a migração possa começar.

Informações do EIGRP na tabela de topologia

Certifique-se de que a sua tabela de topologia EIGRP esteja preenchida com entradas de LAN de raio no hub e resumo em spokes. Isso pode ser verificado com a emissão desse comando em hub(s) e spoke(s).

show ip eigrp topology

Exemplo de saída apropriada do spoke:

Spoke1#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.101.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status
(...omitted as output related to DMVPN cloud ...)
EIGRP-IPv4 Topology Table for AS(200)/ID(192.168.101.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status

P 10.1.1.1/32, 1 successors, FD is 26112000
 via Rstatic (26112000/0)


P 192.168.101.0/24, 1 successors, FD is 281600
 via Connected, Ethernet1/0


P 192.168.0.0/16, 1 successors, FD is 26114560
 via 10.1.1.1 (26114560/1709056), Tunnel1


P 10.1.1.107/32, 1 successors, FD is 26112000
 via Connected, Tunnel1

Você notará que o spoke sabe sobre sua sub-rede de LAN (em itálico) e os resumos para esses (em negrito).

Exemplo de saída apropriada do hub.

Hub#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(172.25.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status
(...omitted, related to DMVPN...) 
EIGRP-IPv4 Topology Table for AS(200)/ID(172.25.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status

P 10.1.1.1/32, 1 successors, FD is 128256
 via Connected, Loopback100


P 192.168.101.0/24, 1 successors, FD is 1561600
 via 10.1.1.107 (1561600/281600), Virtual-Access1


P 192.168.0.0/16, 1 successors, FD is 1709056
 via Rstatic (1709056/0)

P 10.1.1.107/32, 1 successors, FD is 1709056
 via Rstatic (1709056/0)


P 10.1.1.106/32, 1 successors, FD is 1709056
 via Rstatic (1709056/0)


P 0.0.0.0/0, 1 successors, FD is 1709056
 via Rstatic (1709056/0)

P 192.168.102.0/24, 1 successors, FD is 1561600
 via 10.1.1.106 (1561600/281600), Virtual-Access2

Você observará que o hub sabe sobre as sub-redes LAN dos spokes (em itálico), o prefixo de resumo que está anunciando (em negrito) e o endereço IP atribuído a cada spoke via negociação.

Considerações adicionais

Túneis spoke para spoke existentes

Como o desligamento da interface de túnel DMVPN faz com que as entradas NHRP sejam removidas, os túneis spoke to spoke existentes serão desmontados.

Limpando entradas NHRP

Como mencionado anteriormente, um hub FlexVPN não dependerá do processo de registro de NHRP do spoke para saber como rotear o tráfego de volta. No entanto, os túneis spoke to spoke dinâmicos dependem de entradas NHRP.

Em DMVPN, onde limpar o NHRP no hub poderia ter resultado em problemas de conectividade de vida curta.

Em FlexVPN limpando o NHRP em spokes, a sessão FlexVPN IPsec, relacionada aos túneis spoke to spoke, será destruída. Ao limpar o NHRP, nenhum hub terá um efeito na sessão FlexVPN.

Isso se deve ao fato de que no FlexVPN, por padrão:

• Os spokes não se registram em hubs.

• Os hubs funcionam apenas como redirecionador NHRP e não instalam entradas NHRP.

• As entradas de atalho NHRP são instaladas em spokes para túneis spoke-to-spoke e são dinâmicas.

Caveats conhecidos

O tráfego de spoke para spoke pode ser afetado pelo CSCub07382.

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems