Dois circuitos, um router. DMVPN dual-cloud que usa as duas ligações

A maioria das filiais com dois circuitos WAN usa apenas um deles. O segundo fica como reserva, pago todos os meses e exercitado apenas quando o primeiro falha, que é também a primeira vez que alguém descobre se o failover funciona mesmo. Com DMVPN e BGP é possível usar os dois circuitos em permanência, fazer failover entre eles sem pensar nisso, e provar que ambos transportam tráfego. Eis o método.

Uma breve revisão do DMVPN

Corremos BGP sobre DMVPN (mGRE, NHRP, IPsec), para que acrescentar ou perder um site seja um evento de encaminhamento e não uma reconfiguração.

O desenho habitual para redundância são dois hubs numa única cloud. Isso protege contra a falha de um hub. Não faz nada por um spoke com dois circuitos, porque a única interface de túnel do spoke tem origem num deles.

O desenho dual-cloud

A solução é uma segunda cloud DMVPN, independente, com origem no segundo circuito. A objeção habitual é que isso implica novos endereços públicos, novas regras de firewall e nova configuração do hub. Não tem de ser assim, se separar as clouds com uma tunnel key. O GRE transporta a key no seu cabeçalho, pelo que o hub consegue terminar dois túneis multipoint na mesma interface física e no mesmo endereço público e ainda assim distingui-los.

No hub, a segunda cloud é uma cópia da primeira com a sua própria sub-rede de túnel, NHRP network ID e key:

interface Tunnel1
 ip address 10.10.1.1 255.255.255.0
 ip nhrp network-id 1
 ip nhrp authentication <secret>
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile DMVPN-PROF shared
!
interface Tunnel2
 ip address 10.10.2.1 255.255.255.0
 ip nhrp network-id 2
 ip nhrp authentication <secret>
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 2
 tunnel protection ipsec profile DMVPN-PROF shared

A palavra-chave shared no protection profile é importante quando dois túneis partilham a origem: sem ela, as security associations IPsec dos dois túneis colidem.

No spoke, o Tunnel1 tem origem no primeiro circuito e o Tunnel2 no segundo, cada um a apontar para o mesmo endereço do hub com a sua própria key. Nada muda para qualquer outro spoke.

Faça o encaminhamento usar os dois

Dois túneis dão duas sessões BGP para o hub e, portanto, dois caminhos para cada destino. Por omissão, o BGP continua a escolher um. Duas definições mudam isso:

router bgp 65010
 address-family ipv4
  maximum-paths 2
  maximum-paths ibgp 2

As duas sessões devem cair na mesma tabela de encaminhamento para que os caminhos sejam genuinamente iguais. Depois, garanta que o hash de forwarding distribui fluxos e não pares inteiros de origem e destino. Um hash que inclui as portas de camada 4 coloca fluxos paralelos entre os mesmos dois hosts em circuitos diferentes, que é o que se pretende para backups e replicação:

ip cef load-sharing algorithm include-ports source destination

Prove-o, não o presuma

Um show ip route que lista dois next hops prova que o multipath está configurado. Não prova que o tráfego está a usar os dois circuitos. A única prova aceitável é um teste de throughput com vários fluxos paralelos que atinge, em cada sentido, mais do que qualquer um dos circuitos conseguiria transportar sozinho, enquanto observa os contadores das duas interfaces físicas a subir em conjunto:

iperf3 -c <far-end> -P 8 -t 60
iperf3 -c <far-end> -P 8 -t 60 -R
show interfaces GigabitEthernet0/0/1 | include rate
show interfaces GigabitEthernet0/0/2 | include rate

Se uma interface faz todo o trabalho, veja o hash e se os dois caminhos BGP estão realmente instalados.

Dimensione pelo crypto engine, não pela licença

Todos os routers têm um valor de throughput licenciado e um teto real de encriptação, e os dois não são a mesma coisa. O teto depende do hardware de criptografia, dos tamanhos de pacote e de quanto mais o router está a fazer. Meça-o com tráfego realista, não com o tamanho de pacote ideal de um datasheet, e dimensione com base no que mediu.

No nosso backbone, esse valor medido é de cerca de 11 Gbit/s de tráfego encriptado por hub. Quando um cliente precisa de mais entre sites, não esperamos por uma caixa maior: distribuímos o tráfego por vários hubs com equal-cost multipath, o que leva a capacidade encriptada para 30 a 40 Gbit/s. O mesmo princípio que faz uma filial usar os seus dois circuitos faz um backbone usar todos os seus hubs.

Usamos routers virtuais para sites tranquilos e routers de hardware para os mais ocupados.

Hubs redundantes que não atrapalham

Um hub standby deve ficar calado até ser necessário. Dê-lhe o seu próprio AS BGP ou uma despreferência de saída deliberada para que os spokes prefiram o primário, e use BFD nos túneis para que um primário morto seja detetado em segundos e não ao fim do hold timer do BGP. Os spokes fazem então failover apenas por encaminhamento. Ninguém toca num router de filial porque um hub mudou.

Uma lista de verificação para a sua WAN

• Todos os sites com dois circuitos usam ambos, e consegue demonstrá-lo com um teste de throughput?
• As duas clouds estão separadas por tunnel key, com proteção IPsec shared?
• O BGP multipath está ativo e o hash de forwarding inclui as portas?
• O BFD corre em todos os túneis?
• Conhece o seu teto de encriptação medido por hub, e não o licenciado?
• Uma falha de hub obrigaria a tocar num único spoke?

Operamos este desenho nos nossos datacenters em Atenas, Amesterdão e Toronto, com hubs redundantes em cada um, e construímos o mesmo para clientes que querem os seus próprios escritórios ligados à sua plataforma. Se quiser ajuda a desenhar a sua, teremos todo o gosto em conversar.

Fale com um engenheiro

Related

Relacionados: Backbone encriptado multi-site: a mesh DMVPN · Conectividade privada: VPN gateways e linhas dedicadas · Monitorização de rede e evidências