Minha jornada até o CCIE RS — DMVPN 4
E aí pessoal, tudo bem?
Continuamos percorrendo esta série de artigos compartilhando quase centenas de páginas de notas e informações acumuladas que considero importantes ao trabalhar com Routing and Switching. Acredito que possam ajudar a lidar com infraestrutura de redes no dia-a-dia de outros network engineers como eu.
Para quem não leu os artigos anteriores da série, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF”, “BGP” e “Redistribuição”, “MPLS”, “DMVPN — Parte 1”, “DMVPN — Parte 2” e “DMVPN — Parte 3”.
Já dissemos que DMVPNs podem ser implantadas de 1001 formas. Recomendo muito que leiam os artigos anteriores (DMVPN — Parte 1, DMVPN — Parte 2 e DMVPN — Parte 3) onde exploramos os pontos-chave sobre IPsec VPN e conceitos de DMVPN.
Hoje enfim exploraremos as configurações de DMVPN!!!
Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a dar “claps” no artigo e compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)
DMVPN — Configuração
Normalmente se configura a DMVPN iniciando pelo IPsec, começando por config PHASE 1 ISAKMP, PHASE 2 IPsec e aí vai…
- Definir opções PHASE 1 ISAKMP
- Definir IPsec Transform set
- Definir IPsec Profile
- <crypto ipsec profile>
- <set transform-set>
4. Túneis no HUB e Spokes
- <tunnel mode gre multipoint> default seria P2P
- <tunnel source> public address (conhecido como NBMA)
- <ip address>
- <tunnel key> (opcional) quando há múltiplos túneis
5. Parâmetros NHRP compartilhados
- <ip nhrp network-id X>
- <ip nhrp authentication> (opcional)
DOC: Dynamic Multipoint VPN Configuration Guide -> Dynamic Multipoint VPN — Exemplos de DMVPN são completos e suficientes.
No túnel mGRE o endereço de destino não é especificado porque é aprendido dinamicamente através do NHRP.
Spokes não estabelecem adjacência IGP entre si porque o único endereço multicast mapeado é o do HUB e, portanto, os pacotes multicast (incluindo hellos) só são encaminhados para o HUB. O HUB precisa habilitar mapeamento multicast dinâmico para realizar replicação de pacotes através de unicast (pseudo broadcast)(como em Frelay).
Boa prática: Ajustar o MTU para 1400 e TCP MSS para 1360 quando utilizar IPsec, seja com P2P ou DMVPN. Evitando que o router realize fragmentação e deixando este problema para os end hosts.
Parâmetros utilizados quando temos múltiplos túneis:
- <nhrp authentication>
- <nhrp network-id>
- <tunnel key> tag que vai no pacote (data-plane)
Do ponto de vista final, mGRE forma um túnel GRE P2P cujo endereço de destino foi aprendido dinamicamente.
DMVPN PHASE 1
- Define normalmente um túnel GRE P2P, porém adicionando os parâmetros NHRP.
- No caso de DMVPN, o NHRP map realiza o mapeamento (similar a DLCI, circuit, etc).
- Assim como Frelay, é necessário desabilitar Split-horizon no HUB para os IGPs que usam (ex: RIP).
- Lembrando, na PHASE 1 o HUB é o gargalo para control-plane e data-plane.
Spokes possuem apenas túnel GRE P2P para o HUB e estabelecem adj IGP somente com ele. Todas as rotas apontam como nest-hop para o HUB. Por fim, spokes só possuem mapeamento NHRP para o HUB (óbvio).
Não é possível configurar mais de uma PHASE.
- GRE — protocolo 47
- ESP — protocolo 51
- GRE P2P — precisa de destino configurado.
- mGRE — aprende destino dinamicamente.
OBS: Usando qualquer túnel é possível criar erro de recursividade e por isso mesmo é recomendado usar dois protocolos distintos para underlay e overlay.
DMVPN e Crypto Profiles
Profile criptografa todo tráfego roteado através do túnel.
- Ambos control-plane e data-plane;
- Tráfego NHRP;
- Essencialmente um crypto map dinâmico simplificado;
- Contém somente parâmetros IPsec PHASE 2 (ex: transform set);
- Não contém endereço do peer ou Proxy ACL, porque estas informações são derivadas da cache NHRP quando o túnel é estabelecido.
- — mGRE não sabe o endereço do destino do pacote. Na hora do envio esta informação é derivada do mapeamento NHRP (similar a Frelay e DLCI).
PHASE 1 (ISAKMP) ainda é necessária (como sempre).
- DMVPN usa wildcard PSK ou CA.
Relembrando ISAKMP (PHASE 1)
- Criptografia
- Autenticação — PSK ou CA
- Hashing — sha ou MD5
- DH group — entropia da key para PHASE 2
Relembrando IPsec (PHASE 2)
- Who? — NHRP*
- What? — GRE*
- — *OBS: Na prática Crypto Profile é um Crypto Map que deriva estes parâmetros automaticamente.
- How? — Crypto Profile (transform-set)
OBS: 99% das vezes, DMVPN é configurada com IPsec transport-mode.
OBS: Do ponto de vista de configuração, os parâmetros ISAKMP não importam muito. Eles precisam apenas ser iguais. Do ponto de vista real (de produção) DMPVN, os parâmetros são muito importantes dependendo principalmente das limitações de recursos da plataforma do HUB, porque IPsec faz uso intenso de CPU (imagine o HUB com milhares de túneis encriptados).
PSK com wildcards
Em alguns momentos (ex: lab) podemos usar wildcards para as PSK para simplificar, mas em ambientes de produção é diferente:
- Se não usarmos wildcards, as PSK devem ser mantidas separadamente por peer e isso não escala.
- Se usarmos wildcards e uma chave do grupo for comprometida, teoricamente todo o grupo está comprometido.
- Recomendação é sempre usar certificados (CA).
DOC: DMVPN Design Guide — Must read para implementação de DMVPN em produção.
- Em produção se implementa melhores práticas, como dividir o peso do control-plane em duas caixas, uma para IPsec (criptografia) e outra para DMVPN (NHRP e roteamento).
Distance vector e DMVPN
É necessário desabilitar todo split-horizon no HUB para todo IGP distance vector (RIP, EIGRP…) de forma que o HUB repasse tráfego recebido através da mesma interface túnel mGRE.
OBS: Flappar o túnel no spoke reinicia o registro NHRP e estabelecimento do túnel IPsec, assim como adj IGP. Portanto, sempre que houver algum problema, primeiro tente shut/no shut no spoke. NUNCA fazer isso no HUB porque ele precisará gerar novas chaves para todos os peers e todas as adjacências (CPU pode ir a 100%).
ISAKMP
Peers negociam parâmetros ISAKMP enquanto estão no estado Main Mode. Ao passar para Quick Mode as informações já estão encriptadas e se inicia a PHASE 2 (pode ser visto no PCAP). Quick Mode significa que o túnel temporário (para negociar PHASE 2) está formado.
DICA: Nos labs para CCIE é interessante estabelecer os túneis primeiro sem criptografia para se certificar de que tudo está OK e somente depois implementar criptografia sobre a DMVPN. Dessa forma isolamos o problema caso seja um engano no IPsec.
Fácil perceber na DMPVN PHASE 1 que os túneis estão estabelecidos somente entre spokes e HUB porque todo next-hop L3 aponta para o HUB (um spoke nem solicita informação sobre outro spoke). Se trata de design de roteamento.
Na prática:
- IPsec PHASE 1
— 1. ISAKMP + KEY
2. IPsec PHASE 2
— 1. Transform-set
— 2. Crypto Profile
— 3. Tunnel protection
- <sh crypto isa sa>
- <sh crypto ip sa | in local|remote>
Diferenças entre as DMVPN PHASES
- Quais são as principais diferenças?
- Quando usar uma ou outra?
- Designs de roteamento?
Configurações devem ser realizadas em formato de template de forma que se possa simplesmente replicar para todos os peers.
DMVPN PHASE 1 (obsoleta)
- mGRE no HUB e P2P GRE nos spokes.
- — NHRP é requerido para registro nos spokes no HUB.
- — Não há túneis spoke-to-spoke.
- Roteamento:
- — Sumarização e rota default no HUB são permitidas e devem ser realizados sempre que possível!!!
- — Next-hop nos spokes é sempre alterado pelo HUB.
- — O endereço do next-hop sempre será o HUB, o que significa que o spoke nunca precisará realizar resolução NHRP porque o HUB já possui mapeamento NHRP estático.
OSPF
- PHASE 1 suporta OSPF broadcast, non-broadcast e point-to-multipoint.
- Por default, o modo OSPF é P2P para túneis e precisa ser alterado. P2P permite apenas uma adj e fica reiniciando infinitamente quando há múltiplos peers.
- Se Spokes usarem P2P, alterar os default timers ou não forma adj.
- Se utilizar eleição, por ser HUB-and-spoke, o HUB sempre deve ser o DR, com priority 0 nos spokes.
- —OBS: Modos OSPF não precisam ser iguais. Precisam ser compatíveis.
- O HUB e todos os spokes precisam estar na mesma área OSPF porque o HUB se comunica com todos os Spokes através da mesma interface. Este é um dos principais motivos para OSPF não ser uma boa escolha para DMVPN porque não permite sumarização entre os spokes!!!
- — OBS: Solução simples é usar EIGRP ou até BGP porque permitem hierarquia arbitrária.
Para DMVPN de produção, OSPF não é tão escalável porque só permite dois níveis de hierarquia (área 0 e todas as demais). Como todos os spokes e HUB precisam estar na mesma área, todos possuem a mesma DB. Se houver alteração de rota envolvendo um spoke, todos os spokes e HUB devem rodar SPF novamente (imagine 1000 peers com ADSL !!!).
Protocolos link-state utilizam uma cópia completa da DB com todos os links e nodes de uma determinada área.
Mesmo aplicando distribute-list que aceite somente determinadas rotas, o problema não é resolvido porque distribute-list não bloqueia inserção do SLA na DB, ele apenas bloqueia a inserção das rotas da DB na RIB. A DB continua populada e rodando SPF para qualquer alteração do mesmo jeito.
BGP
- Por default, os neighbors BGP devem ser especificados estaticamente.
- BGP permite configuração de peer de forma dinâmica através da feature BGP Dynamic Neighbors <bgp listen range>.
- PHASE 1 — Podemos apenas divulgar rota-default visto que o next-hop de todos os spokes será o HUB.
- — OBS: Mesmo que não utilize <next-hop-self> ao propagar rotas para os spokes, os spokes conseguem se comunicar através do túnel porque mesmo que utilizem endereço de destino de outros spokes, o destino default do túnel é o HUB, que acaba roteando corretamente.
OBS: Para PHASE 1 A sumarização “HUB -> spokes” deve ser realizada sempre que possível visto que todo tráfego passa pelo HUB de qualquer maneira. Obviamente o HUB deve conhecer todas as rotas dos spokes.
Não há problema nenhum em utilizar iBGP apenas entre edge routers para DMVPN (… porque iBGP internamente como IGP é uma merda …) e redistribuir mutualmente entre iBGP e IGP. Como BGP é super escalável, é tranquilo de escalar DMVPN em produção.
- OBS: Não esqueça <bgp redistribute-internal>.
Se o padrão de tráfego principal é Spoke->HUB (ex: site remoto -> DC) a PHASE não importa (tanto faz). Só faz diferença utilizar PHASE 2 ou 3 se o padrão de tráfego é spoke-to-spoke. O padrão de tráfego determina tudo!
DMVPN PHASE 2 (também obsoleta)
- mGRE é utilizado no HUB e Spokes (não se usa mais P2P GRE).
- — NHRP é necessário para registro de Spoke no HUB.
- — NHRP é necessário para resolução Spoke-to-Spoke.
- — Tunnel spoke-to-spoke é ativado pelos spokes on-demand.
- Roteamento:
- — Sumarização e rota default no HUB não são permitidas.
- — Next-hop nos spokes é sempre preservado pelo HUB.
- — Hierarquia multi-nível requer HUB daisy-chaining.
Túneis nos spokes não possuem destino configurado de forma que confiam no NHRP para definir o end-point. O HUB é o único que deve ser mapeado estaticamente no NHRP e com multicast habilitado (permitindo hellos IGP).
OSPF
Somente modos broadcast e non-broadcast mantêm os endereços de next-hop de forma a permitir que os spokes se comuniquem diretamente entre si. Modos P2P e P2M sempre alteram o next-hop de forma que os spokes sempre teriam o HUB como next-hop e portanto não estabelecem túneis spoke-to-spoke.
Como os únicos modos aceitos são broadcast e non-broadcast é necessário garantir que o HUB seja sempre o DR porque o DR precisa ter adjacência L2 com todos os neighbors para que estes recebam o flooding. Aqueles que não forem adjacentes ao DR não recebem flooding (LSA) e, portanto, não possuem rotas.
- OBS: Garantir priority 0 nos spokes.
Sendo uma topologia HUB-and-Spoke, o modo OSPF ideal seria point-to-multipoint (sem eleição). Porém se usar P2M, o HUB não mantém os next-hops originais dos spokes e portanto impede criação de túneis spoke-to-spoke.
EIGRP
- <no ip next-hop-self eigrp X> no túnel para que os next-hops das rotas sejam mantidos.
- <no ip split-horizon eigrp>
Spokes podem estabelecer túneis entre si para troca de mensagens unicast, mas não multicast. Por isso, os spokes não podem estabelecer adj IGP entre si.
Túneis spoke-to-spoke aparecem como:
- <sh dmvpn> atributo D (dynamic)
- <sh ip nhrp> type: dynamic
Apesar do HUB ser o NHRP server, ele não responde a solicitação (request) de um spoke. Ele encaminha a solicitação do spoke A para o spoke de destino B, de forma que o spoke B inicia um túnel dinâmico com spoke A e responde o NHRP request. Ao final do processo os spokes estabeleceram um túnel dinâmico entre si e popularam o mapeamento NHRP um do outro.
Ao usar PHASE 2 ou 3, o mGRE precisa de pre-shared keys configuradas entre os spokes e não somente entre spokes e HUB. Se não houver PSK permitida entre os spokes, eles não se autenticam. Esse ponto mostra novamente que não é escalável manter PSK nos spokes em ambiente de produção… Em lab podemos usar wildcards!
IGPs
Ordem de preferência de IGP para DMVPN é BGP -> EIGRP -> OSPF.
- OBS: Podemos utilizar OSPF em ambiente de testes (ex: lab CCIE) mas realmente devemos evitar em DMVPN em produção porque todos os spokes devem estar na mesma área e cada spoke afeta todos os outros (não é estável).
O grande problema da PHASE 2 é não poder usar sumarização ou rota default no HUB porque altera o next-hop. Alterando os next-hops, o HUB impede formação de túneis entre os spokes. Portanto, os spokes precisam ter full-routing mas isso se torna outro grande problema em escala quando houver muitos spokes.
Cenários possíveis com IGP — PHASE 2
- BGP — HUB é RR (caso iBGP). Pode-se usar adjacência dinâmica.
- EIGRP — HUB com <no ip next-ho-self>
- OSPF — HUB é DR. Spokes com priority 0.
- — Modo broadcast
- — Modo non-broadcast
- RIPv2
PHASE 3
- mGRE é utilizado no HUB e nos spokes.
- — NHRP é necessário para registro dos spokes no HUB
- — NHRP é necessário para resolução spoke-to-spoke
- Quando o HUB recebe e encaminha um pacote através da mesma interface:
- — 1. Encaminha uma mensagem NHRP redirect de volta para o spoke de origem.
- — 2. Encaminha o pacote original para o spoke de destino via RIB.
- Roteamento:
- — Sumarização e rota default são permitidas no HUB.
- — — Resulta em rotas NHRP para túneis spoke-to-spoke on-demand (NHRP redirect / NHRP shortcut)
- — Next-hop nos spokes é sempre alterado pelo HUB. Por causa disso, a resolução NHRP é sempre disparada pelo HUB.
- — Hierarquia multi-nível funciona sem daisy-chaining.
OBS: Lembrando que sem uso de sumarização, NHO (next hop override) é executado para túneis spoke-to-spoke e next-hop é alterado do IP do HUB para IP do Spoke.
Data-plane e Control-plane On-Demanda
Quando o HUB recebe tráfego encaminhado entre spokes ele recebe e encaminha através do próprio túnel. Ao mesmo tempo o HUB retorna para o spoke de origem um NHRP redirect informando o mapeamento do spoke de destino. O spoke de origem então estabelece um túnel dinâmico com o spoke de destino que também popula o mapeamento NHRP para o spoke de origem.
O processo de Mapeamento NHRP ocorre por rotas, de forma que o HUB precisa ter full-routing enquanto os spokes populam a tabela de roteamento de forma dinâmica (rotas H).
O resultado final e principal diferença entre PHASE 2 e PHASE 3 é que na PHASE 3 não somente o data-plane é on-demand (túneis) como o control-plane (roteamento) também é on-demand. Cada spoke possui a tabela de roteamento que precisa.
OBS: O spoke só transiciona o tráfego para outro spoke através do túnel dinâmico quando todo o processo se completa. Enquanto isso não ocorre, os pacotes são encaminhados através do HUB de forma que não há perda de pacotes entre os spokes.
Todo o processo on-demand utiliza rotas NHRP (H) e mapeamento NHRP (private -> NBMA).
- <sh ip route > e <sh ip nhrp>
- Distância (DA) do NHRP é 250.
OBS: A troca de mensagens NHRP para executar o mapeamento entre spokes não é simples, mas o resultado é.
OBS: Sempre suba a DMVPN toda sem IPsec. Somente depois de testar aplique o crypto profile, isolando o problema caso esteja relacionado a IPsec.
Rotas NHRP possuem timeout de forma que o túnel só é descartado por inatividade (permanece enquanto houver tráfego). Mesmo que ocorra uma falha entre spokes e HUB, o tráfego spoke-to-spoke não é interrompido porque o HUB não faz mais parte do data-plane. A não ser que o túnel seja descartado por inatividade, nesse caso um novo túnel não pode ser estabelecido sem o HUB.
OBS: Spokes com <nhrp shortcut> instalam rotas diretamente para outros spokes e encaminham através do túnel dinâmico. Spokes sem <nhrp shortcut> não instalam rotas e encaminham pacotes para outros spokes através do HUB, mesmo que o túnel dinâmico esteja ativo (causando roteamento assimétrico).
OBS: DMVPN Design Guide fala quantidade de túneis suportados por plataforma.
Comandos Show para VPN
ISAKMP e IPsec
- sh cry isa key — pre-shared keys para autenticação
- sh cry isa po — PHASE 1 Policies
- sh cry isa sa — Status PHASE 1
- sh cry isa sa det
- sh cry isa peer
- sh cry map [int] — config final do crypto map
- — OBS: informa se a config está incompleta.
- sh cry ip pro
- sh cry ip trans — PHASE 2 Policies
- sh cry ip sa — Status PHASE 2 — Mostra SA in e SA out.
- sh cry ip sa | in ident|caps
- sh cry ip sa | in ident|esp|spi
- sh cry debug condition — filtros de debug (geralmente usado por peer)
- debug cry isa
- debug cry ipsec
- debug crypto condition peer ipv4 X.X.X.X
- <debug dmvpn all> basicamente a combinação de <debug nhrp> e <debug crypto>
Mostram o resultado das negociações:
- sh cry isa sa
- sh cry ip sa
Mostram exatamente o que houve de errado e precisa saber interpretar:
- debug cry isa
- debug cry ipsec
NHRP
- sh ip nh bri
- sh ip nh det
- sh ip nh multi
- sh ip nh nhs det
- sh ip nh sum
- sh ip nh tra
- sh ip nh vrf ABC
- sh dm
- sh dm det
- sh ip route vrf ABC
- sh ip route vrf *
O que achou desta série de artigos sobre DMVPN?
Este tópico te ajudará no dia-a-dia?
Fala pra gente nos comentários?
Se gostou do conteúdo, peço para dar palmas para o artigo e compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)
Sobre o autor:
Giuliano Barros é Network Engineer & Founder da Control Plane — Network Services.
Graduado em Ciência da Computação, certificado CCIE RS e Cisco Champion pela Cisco Systems, trabalha há 15 anos como Network Engineer em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros
