Due circuiti, un router. DMVPN dual-cloud che usa entrambi i collegamenti

La maggior parte delle sedi periferiche con due circuiti WAN ne usa uno. Il secondo sta lì come riserva, pagato ogni mese ed esercitato solo quando il primo si guasta, che è anche la prima volta in cui qualcuno scopre se il failover funziona davvero. Con DMVPN e BGP potete far girare entrambi i circuiti in permanenza, passare dall'uno all'altro senza pensarci, e dimostrare che entrambi trasportano traffico. Ecco il metodo.

Un rapido ripasso su DMVPN

Facciamo girare BGP sopra DMVPN (mGRE, NHRP, IPsec), così aggiungere o perdere una sede è un evento di routing e non una riconfigurazione.

Il design comune per la ridondanza è due hub su un cloud. Questo protegge dal guasto di un hub. Non fa nulla per uno spoke con due circuiti, perché la singola interfaccia tunnel dello spoke ha come sorgente uno solo di essi.

Il design dual-cloud

La soluzione è un secondo cloud DMVPN indipendente, con sorgente sul secondo circuito. L'obiezione abituale è che significa nuovi indirizzi pubblici, nuove regole firewall e nuova configurazione sugli hub. Non è necessario, se separate i cloud con una tunnel key. GRE trasporta la chiave nel suo header, quindi l'hub può terminare due tunnel multipoint sulla stessa interfaccia fisica e sullo stesso indirizzo pubblico e distinguerli comunque.

Sull'hub, il secondo cloud è una copia del primo con la propria subnet di tunnel, il proprio NHRP network ID e la propria chiave:

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

La parola chiave shared sul profilo di protezione conta quando due tunnel condividono una sorgente: senza di essa le security association IPsec dei due tunnel collidono.

Sullo spoke, Tunnel1 ha come sorgente il primo circuito e Tunnel2 il secondo, ciascuno puntato allo stesso indirizzo dell'hub con la propria chiave. Per ogni altro spoke non cambia nulla.

Fate in modo che il routing li usi entrambi

Due tunnel vi danno due sessioni BGP verso l'hub, e quindi due percorsi verso ogni destinazione. Per default BGP ne sceglie comunque uno. Due impostazioni cambiano le cose:

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

Entrambe le sessioni devono finire nella stessa tabella di routing, così i percorsi sono davvero equivalenti. Poi assicuratevi che l'hash di forwarding distribuisca i flussi e non intere coppie sorgente-destinazione. Un hash che include le porte di livello 4 mette flussi paralleli tra gli stessi due host su circuiti diversi, che è ciò che volete per backup e replica:

ip cef load-sharing algorithm include-ports source destination

Dimostratelo, non datelo per scontato

show ip route che elenca due next hop dimostra che il multipath è configurato. Non dimostra che il traffico stia usando entrambi i circuiti. L'unica prova accettabile è un test di throughput con diversi flussi paralleli che ottenga in ciascuna direzione più di quanto un singolo circuito potrebbe trasportare da solo, mentre guardate i contatori di entrambe le interfacce fisiche salire insieme:

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 un'interfaccia fa tutto il lavoro, guardate l'hash e verificate se entrambi i percorsi BGP sono davvero installati.

Dimensionate dal crypto engine, non dalla licenza

Ogni router ha un valore di throughput licenziato e un tetto reale di cifratura, e i due non coincidono. Il tetto dipende dall'hardware crittografico, dalle dimensioni dei pacchetti e da quanto altro il router sta facendo. Misuratelo con traffico realistico, non con la dimensione di pacchetto più favorevole di una scheda tecnica, e dimensionate su ciò che avete misurato.

Sul nostro backbone quel valore misurato è di circa 11 Gbit/s di traffico cifrato per hub. Quando un cliente ha bisogno di più tra le sedi, non aspettiamo una macchina più grande: distribuiamo il traffico su più hub con equal-cost multipath, che porta la capacità cifrata a 30 o 40 Gbit/s. Lo stesso principio che fa usare a una sede entrambi i suoi circuiti fa usare a un backbone tutti i suoi hub.

Usiamo router virtuali per le sedi tranquille e router hardware per quelle trafficate.

Hub ridondanti che restano in disparte

Un hub di standby deve restare silenzioso finché non serve. Dategli un proprio AS BGP o una de-preferenza in uscita deliberata, così gli spoke preferiscono il primario, e usate BFD sui tunnel in modo che un primario morto venga rilevato in secondi e non all'hold timer di BGP. Gli spoke passano allora al secondario con il solo routing. Nessuno tocca il router di una sede perché un hub è cambiato.

Una checklist per la vostra WAN

• Ogni sede con due circuiti li usa entrambi, e potete dimostrarlo con un test di throughput?
• I due cloud sono separati da tunnel key, con protezione IPsec condivisa?
• Il multipath BGP è attivo e l'hash di forwarding include le porte?
• BFD gira su ogni tunnel?
• Conoscete il vostro tetto di cifratura misurato per hub, non quello licenziato?
• Il guasto di un hub vi costringerebbe a toccare anche un solo spoke?

Facciamo girare questo design tra i nostri datacenter di Atene, Amsterdam e Toronto, con hub ridondanti in ciascuno, e costruiamo la stessa cosa per i clienti che vogliono collegare i propri uffici alla propria piattaforma. Se desiderate aiuto per progettare la vostra, parliamone volentieri.

Parla con un ingegnere

Related

Correlati: Backbone cifrato multi-sito: la mesh DMVPN · Connettività privata: gateway VPN e linee dedicate · Monitoraggio di rete ed evidenze