Minha jornada até o CCIE RS — DMVPN 3

E aí colegas, belezinha?

Vamos continuar esta série de artigos compartilhando quase 400 páginas de anotações e informações acumuladas que considero importantes ao trabalhar com Routing and Switching. Espero que possam ajudar no dia-a-dia de outros network engineers como eu a lidar com infraestrutura de redes.

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” e “DMVPN — Parte 2”.

DMVPNs podem ser implantadas de 1001 formas. Portanto, para chegarmos ao ponto em como DMVPNs são utilizadas hoje, precisamos explicar pontos básicos. Recomendo muito que leiam os artigos anteriores (DMVPN — Parte 1 e DMVPN — Parte 2) onde exploramos os pontos-chave sobre IPsec VPN.

Hoje enfim exploraremos DMVPN focando nos conceitos e no próximo artigo finalizamos analisando a parte de configuração. Sair configurando DMVPN sem conhecer as etapas e PHASES que desejamos é só dor de cabeça.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

Dynamic Multipoint VPN (DMVPN)

Principais pontos:

• PHASE 1
• PHASE 2
• PHASE 3
• Routing over DMVPN

O que é DMVPN?

• DMVPN é uma VPN ponto-multiponto Layer 3 overlay. Resumindo “Layer 3 overlay tunnel”.
• Do ponto de vista lógico, apresenta topologia HUB-and-spoke, mas também suporta tráfego direto spoke-to-spoke.
• Spoke-to-spoke é uma grande diferença de ATM e Frame-relay onde o serviço deve ser provisionado pelo ISP.

A tecnologia é HUB-and-spoke mas o tráfego pode ocorrer de forma spoke-to-spoke, evitando que o HUB se torne um gargalo limitando a escalabilidade. Tudo depende do design da DMVPN e cenários de roteamento suportados.

Como DMVPN funciona?

• DMVPN permite um full-mesh de túneis on-demad com configuração mínima através do uso de:
• — Túneis Multipoint GRE (mGRE)
• — Next Hop Resolution Protocol (NHRP)
• — IPsec Crypto Profiles
• — Routing

mGRE permite implementar uma interface túnel GRE com múltiplos destinos, ao contrário do túnel normal P2P.

OBS: DMVPN também implica criptografia dentro do túnel, mas não é uma necessidade.

*Por que usar DMVPN?*

• A principal razão é por ser independente (flexibilidade) do método de acesso fornecido pelo ISP. Único requerimento é conectividade L3 entre os sites (não necessariamente conectividade com Internet). Permite mix de quaisquer tecnologias: ADSL, metro, etc.
• Isso permite flexibilidade de tecnologia e ISP.
• Política de roteamento não é mais ditada pelo SP (ex: restrições MPLS L3VPN ou necessidade de rodar protocolos de roteamento específicos). Por ser uma tecnologia overlay pode rodar o protocolo que quiser e não há necessidade de alterar o protocolo já utilizado (outro ex: diferentes plataformas como edge-routers do SP, como Cisco x Juniper).
• Altamente escalável através de designs corretos (ex: 5 mil peers). Principal gargalo é o HUB responsável pelo control-plane. Quanto control-plane o HUB aguenta? (ex: túneis IPsec e roteamento, etc).
• Reduz necessidade de n(n-1)/2 (full-mesh) túneis estáticos.
• — Usa apenas uma interface mGRE para todas as conexões.
• — Túneis são criados on-demand entre peers.
• — Criptografia é opcional.
• Isso torna a implementação e a manutenção muito mais simples que as demais tecnologias.
• Teoricamente permite criação de túneis full-mesh, porém por ser on-demand os túneis só são criados conforme necessidade.

OBS: Principal desvantagem é que DMVPN é proprietáro Cisco.

• Túneis on-demand entre nodes:
• — Mesh inicial utiliza túneis HUB-to-spoke que permanecem sempre ativos e utilizados para manter o control-plane da rede. Túneis são iniciados dos spokes para o HUB e estabelecer adjacência L3 com o HUB.
• — Topologia pode iniciar túneis spoke-to-spoke conforme necessidade.
• — Esse comportamento resolve problema de escalabilidade do gerenciamento.
• Túneis são mantidos baseados no tráfego:
• — Túneis spoke-to-spoke são on-demand.
• — Lifetime do túnel é baseada no tráfego.

DMVPN requer uso de 2 IGPs: Underlying and Overlay

• Requer 2 IGPs IPv4 ou 2 IGPs IPv6.
• Underlay (conectividade, externo ao túnel) (ex: BGP)
• Overlay (interno ao túnel) (ex: OSPF, EIGRP, BGP).

HUB and Spokes (HUB-to-Spokes)

Dois principais componentes:

• DMVPN HUB / NHRP Server (NHS)
• DMVPN Spokes / NHRP clients (NHC)

Spokes/Clients se registram com HUB/Server dinamicamente.

1. Spokes especificam manualmente o endereço do HUB.
2. Encaminham “NHRP Registration Request”.
3. HUB aprende dinamicamente os endereços VPN dos spokes e os endereços NBMA.
4. Spokes estabelecem túneis com o HUB.

• — Ocorre troca de informação de roteamento com o HUB através do túnel.

Função do NHRP é resolver o endereço underlay para o endereço overlay. mGRE não sabe o destino do túnel previamente porque a resolução é dinâmica. Qual é o endereço de destino do túnel GRE?

Spoke-to-Spoke

1. Spoke 1 sabe a rota para Spoke 2 via IGP.

• — Rota aprendida via túnel para o HUB.
• — Next-hop é o IP da VPN do Spoke 2 para DMVPN PHASE 2.
• — Next-hop é o IP da VPN do HUB para DMVPN PHASE 3.

2. Spoke 1 solicita endereço real do Spoke 2.

• — Mapeia IP (VPN) do next-hop para IP (NBMA) de origem do túnel.
• — Enviado via NHRP Resolution Request.

3. Túnel Spoke-to-Spoke está formado.

• — HUB é usado apenas para troca de control-plane.
• — Data-plane Spoke-to-Spoke pode fluir inicialmente através do HUB.

Padrão do tráfego depende da PHASE:

• PHASE 1 — Todo tráfego entre Spokes deve passar pelo HUB. Neste cenário o HUB se torna o gargalo do control-plane e também do data-plane.
• PHASE 2 e 3 — Spoke solicita o endereço IP (NBMA) através de NHRP request para o HUB e ativa um túnel direto com este spoke apenas para data-plane, mas não para control-plane (não estabelece adjacência).

NHRP — Mensagens importantes

• Registration Request
• — Spokes registram seu endereço IP VPN e NBMA no NHS.
• — Requerido para subir túneis spoke-to-HUB.
• Resolution Request
• — Spoke solicita mapeamento NBMA-to-VPN de outros spokes.
• — Requerido para subir túneis spoke-to-spoke porque spokes não se conhecem.
• Redirect
• — NHS utiliza mensagem Redirect para responder um pacote de data-plane spoke-to-spoke.
• — Similar a um IP redirect quando a interface IN e OUT é a mesma.
• — Usado somente durante a PHASE 3 para ativar túneis spoke-to-spoke.

DMVPN e IPsec

• DMVPN geralmente implica o uso de IPsec, mas não é obrigatório
• Ordem de operação:

1. — IPsec
2. — GRE/NHRP
3. — IGP

• mGRE e NHRP
• — Gerencia estabelecimento do tunnel.
• — Não oferece criptografia.
• IPsec LAN-to-LAN usava crypto-maps
• — Requeria peer manual e definições de ACL.
• — Afetava propósito de escalabilidade dos túneis porque DMVPN deve ser dinâmica.
• — Crypto maps não são escaláveis porque precisam especificar proxy ACLs e peers estaticamente.
• — Solução é IPsec Crypto Profile.
• Mesma forma de implementação que IPsec over GRE porém parece mais com GRE over IPsec (pelo crypto-map que forma).
• Configurado como IPsec Profile no tunnel, com a diferença que os túneis são spoke-to-spoke.
• Qualquer informação referente ao IPsec está relacionada ao IP NBMA.
• — A key ISAKMP está relacionada ao endereço NBMA, porque o IPsec ocorre antes de tudo (antes do registro no NHS, etc).
• — Debugs também <debu crypto condition peer ipv4 X.X.X.X> (IP NBMA)

Best practive usar transform-set da DMVPN em modo transport porque já existe um cabeçalho GRE redundante.

OBS: Na DMVPN, IPsec PHASE 1 (ISAKMP) permanece igual a IPsec LAN-to-LAN. Somente a PHASE 2 altera através do uso de Crypto Profile.

DMVPN PHASES

• PHASE 1 — não suporta túneis dinâmicos spoke-to-spoke
• PHASE 2 — suporta túneis dinâmicos spoke-to-spoke
• PHASE 3 — oferece melhor escalabilidade (ex: sumarização)
• A PHASE afeta:
• — padrões de tráfego spoke-to-spoke
• — designs de roteamento suportados
• — escalabilidade

PHASE 1 (obsoleta)

• mGRE no HUB e P2P-GRE nos spokes
• — NHRP ainda é necessário para registro do spoke no HUB.
• — Não suporta túneis dinâmicos spoke-to-spoke, tornando o HUB o gargalo do control-plane e data-plane.
• Roteamento
• — Permite rota default/sumanização no HUB.
• — Next-hop nos spokes é sempre o HUB (igual a Frelay HUB-and-spoke).
• Basicamente o Spoke se registra no HUB através de NHRP e estabelece as adjacências IGP.

PHASE 2 (também obsoleta)

• mGRE aplicados no HUB-and-Spoke
• — NHRP necessário para registro do Spoke no HUB.
• — NHRP necessário para resolução Spoke-to-Spoke.
• — Túnel spoke-to-spoke é ativado dinamicamente pelo spoke.
• Roteamento
• — Não permite rota default/sumanização no HUB.
• — Next-hop nos spokes é sempre preservado pelo HUB (limitando implementação e configuração dos protocolos).
• — Hierarquia multi-nível requer HUB “daisy chaining” (limita escalabilidade de grandes cenários).

PHASE 3

• mGRE aplicado no HUB e spokes
• — NHRP necessário para registro do spoke no HUB
• — NHRP necessário para resolução spoke-to-spoke
• NHRP Redirects (diferença entre PHASE 2 e PHASE 3)
• — Quando o HUB recebe e encaminha um pacote pela mesma interface, ele envia uma mensagem NHRP redirect para o router de origem.
• — Pacote original é encaminhado para o spoke de destino via RIB.
• Roteamento (tópico confuso)
• — Permite rota default/sumanização no HUB.
• — O resultado são rotas NHRP (H) para túneis spoke-to-spoke.
• — Sem sumarização (no-summary), NHO (next-hop override) é executado para túneis spoke-to-spoke.
• — — Next-hop é alterado do IP do HUB para IP do Spoke.
• — Next-hop nos spokes é sempre alterado pelo HUB.
• — — Por causa disso, resolução NHRP é ativada pelo HUB.
• Hierarquia multi-nível trabalha sem “daisy chaining”.

DOC: DMVPN Dynamic Tunnels Between Spokes Behind a NAT Device — Mostra DMVPN através do NAT.

OBS: Registro NHRP é dinâmico. Isto significa que podemos utilizar DMVPN sobre IPs dinâmicos (ex: ADSL chulé caseiro). O único que precisa de endereço fixo é o HUB.

OBS: Para utilizar DMVPN com firewall as necessidades são sempre as mesmas. O firewall deve permitir:

• UDP 500 (ISAKMP para IPsec PHASE 1) (control plane)
• Protocolo IP 51 (ESP para IPsec PHASE 2) (data plane)

No próximo artigo finalizamos está série sobre DMVPN analisando a parte de configuração das PHASES ;)

O que achou deste artigo sobre DMVPN? Esse artigo te ajudará no dia-a-dia? Fala pra gente nos comentários?

Se gostou do conteúdo, peço para 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